Hi again,
I've been reading the forum quite frequently and it seems to me that bullet is assuming 20cm - 10m sized objects for optimal performance.
Is it correct to assume this?
I ask because I am currently working on a game where the character (moving AI) objects are ranging from about 50m - 750m in size. When the game runs with about 30 of the mid ranged objects, the physics update can take up to 30+ms (on average about 20ms).
The moving objects consist of a btRigidBody, that consist of 1 or 3 btCompoundShapes (the object has 1 or 3 sections and each have a collision shape), and the btCompoundShape for each section consists of 1 - 30 btConvexHullShapes.
Reading the forum, I'm thinking that the size of the objects may be what is causing the slow performance, but I am not too sure. I have also been reading about the
"BT_USE_DOUBLE_PRECISION", but still not sure how to implement it. Would/Might it even help?
Any help would be greatly appreciated.
Thank you
Large Object Optimization Options (performance help please)
-
duser
- Posts: 16
- Joined: Wed Feb 02, 2011 6:48 pm
-
duser
- Posts: 16
- Joined: Wed Feb 02, 2011 6:48 pm
Re: Large Object Optimization Options (performance help plea
Hi again,
Hoping to clarify.
Basically my questions for the above are:
Does the size of the collision object cause performance issues (large objects)?
If so, is there any way to improve the performance without scaling the objects down?
Do overlapping objects cause performance drops (eg: on object is inside a cubed ghost object)?
Any tips or references to other posts that I may have missed will be greatly helpful.
Thank you.
I would like to add one more question.
I've also noticed that a recommendation to improve performance with thousands of objects (usually static) is to add them to a compound object.
Now does it cause performance issues if the thousand objects are compound objects as well?
eg (basically the hierarchy of each moving object in the game):
RIGID BODY
|
_____________________COMPOUND OBJECT RB______________
/ | \
CHILD COMPOUND OBJECT0 CHILD COMPOUND OBJECT1 CHILD COMPOUND OBJECT2
- child convex hull shape0 - child convex hull shape0 - child convex hull shape0
- child convex hull shape1 - child convex hull shape1
- child convex hull shape2
NOTE: some "CHILD COMPOUND OBJECT"s can have up to 5 child convex hull shapes (to keep within the advised 16 shapes as read in another post)
I am reading on some posts that users have had 3000 objects with a 1-2ms for their physics update in older bullet versions (and some that get up to 14ms, but thats with 3000, I only want maybe 100 of these rigid bodies, and with 30 I hit >20ms with version 2.77).
Little explanation as to why it is set up this way. Each object is a ship, and each ship has 1 - 3 separate sections. Also each section has moving parts that the convex hull shapes are connected to. I also have a ghost object paired with the ship, if it is moving, to be used as its "sight" (as in, the ghost object tells the ship if something is ahead of it and how to avoid it). When I have multiple ships flying at the same time, and have multiple ghost objects detecting other objects in the way, the frame rate drops down substantially (from the average 20ms to sometimes 30+ms). Also note that the size of the ships range from 50m - 750m (in total, summed up as the rigid body's shape).
I have collision filters, custom contact result callbacks, and used btShapeHull (to reduce the number of convex hulls verticies) to speed up the collision detection. Each of these speed up the detection, but it still runs slow. If I can get the time to stay below 3-4ms with 100 of these ships moving, that would be amazing.
Any thoughts?
Thanks
Hoping to clarify.
Basically my questions for the above are:
Does the size of the collision object cause performance issues (large objects)?
If so, is there any way to improve the performance without scaling the objects down?
Do overlapping objects cause performance drops (eg: on object is inside a cubed ghost object)?
Any tips or references to other posts that I may have missed will be greatly helpful.
Thank you.
I would like to add one more question.
I've also noticed that a recommendation to improve performance with thousands of objects (usually static) is to add them to a compound object.
Now does it cause performance issues if the thousand objects are compound objects as well?
eg (basically the hierarchy of each moving object in the game):
RIGID BODY
|
_____________________COMPOUND OBJECT RB______________
/ | \
CHILD COMPOUND OBJECT0 CHILD COMPOUND OBJECT1 CHILD COMPOUND OBJECT2
- child convex hull shape0 - child convex hull shape0 - child convex hull shape0
- child convex hull shape1 - child convex hull shape1
- child convex hull shape2
NOTE: some "CHILD COMPOUND OBJECT"s can have up to 5 child convex hull shapes (to keep within the advised 16 shapes as read in another post)
I am reading on some posts that users have had 3000 objects with a 1-2ms for their physics update in older bullet versions (and some that get up to 14ms, but thats with 3000, I only want maybe 100 of these rigid bodies, and with 30 I hit >20ms with version 2.77).
Little explanation as to why it is set up this way. Each object is a ship, and each ship has 1 - 3 separate sections. Also each section has moving parts that the convex hull shapes are connected to. I also have a ghost object paired with the ship, if it is moving, to be used as its "sight" (as in, the ghost object tells the ship if something is ahead of it and how to avoid it). When I have multiple ships flying at the same time, and have multiple ghost objects detecting other objects in the way, the frame rate drops down substantially (from the average 20ms to sometimes 30+ms). Also note that the size of the ships range from 50m - 750m (in total, summed up as the rigid body's shape).
I have collision filters, custom contact result callbacks, and used btShapeHull (to reduce the number of convex hulls verticies) to speed up the collision detection. Each of these speed up the detection, but it still runs slow. If I can get the time to stay below 3-4ms with 100 of these ships moving, that would be amazing.
Any thoughts?
Thanks
-
Erwin Coumans
- Site Admin
- Posts: 4221
- Joined: Sun Jun 26, 2005 6:43 pm
- Location: California, USA
Re: Large Object Optimization Options (performance help plea
Generally it is best to avoid large btCompoundShape, just rely on the btDbvtBroadphase.
I'm not aware of particular performance issues with large collision shapes. Large size ratios (mixing very big and very small) and large mass ratios (very heavy/very light) can best be avoided for stability/quality reasons.
Use a profiler or use the CProfileManager::dumpAll after a stepSimulation to figure out where the bottleneck is.
Thanks,
Erwin
I'm not aware of particular performance issues with large collision shapes. Large size ratios (mixing very big and very small) and large mass ratios (very heavy/very light) can best be avoided for stability/quality reasons.
Use a profiler or use the CProfileManager::dumpAll after a stepSimulation to figure out where the bottleneck is.
Thanks,
Erwin
-
duser
- Posts: 16
- Joined: Wed Feb 02, 2011 6:48 pm
Re: Large Object Optimization Options (performance help plea
Hi Erwin,
Thank you for your response.
I am using btDbvtBroadphase.
I may have miss read some of the posts, or was thinking the same as the people who posted them, when thinking the large sizes may cause performance issues.
Here is the dump of 20 units at rest and 20 units all moving
20 medium size objects
At Rest
----------------------------------
Profiling: Root (total running time: 0.621 ms) ---
0 -- stepSimulation (98.71 %) :: 0.613 ms / frame (1 calls)
Unaccounted: (1.288 %) :: 0.008 ms
...----------------------------------
...Profiling: stepSimulation (total running time: 0.613 ms) ---
...0 -- synchronizeMotionStates (13.87 %) :: 0.085 ms / frame (4 calls)
...1 -- internalSingleStepSimulation (83.69 %) :: 0.513 ms / frame (4 calls)
...Unaccounted: (2.447 %) :: 0.015 ms
......----------------------------------
......Profiling: internalSingleStepSimulation (total running time: 0.513 ms) ---
......0 -- updateActivationState (1.56 %) :: 0.008 ms / frame (4 calls)
......1 -- updateActions (0.00 %) :: 0.000 ms / frame (4 calls)
......2 -- integrateTransforms (27.68 %) :: 0.142 ms / frame (4 calls)
......3 -- solveConstraints (17.93 %) :: 0.092 ms / frame (4 calls)
......4 -- calculateSimulationIslands (2.73 %) :: 0.014 ms / frame (4 calls)
......5 -- performDiscreteCollisionDetection (27.10 %) :: 0.139 ms / frame (4 ca
lls)
......6 -- predictUnconstraintMotion (21.25 %) :: 0.109 ms / frame (4 calls)
......Unaccounted: (1.754 %) :: 0.009 ms
.........----------------------------------
.........Profiling: solveConstraints (total running time: 0.092 ms) ---
.........0 -- processIslands (67.39 %) :: 0.062 ms / frame (4 calls)
.........1 -- islandUnionFindAndQuickSort (18.48 %) :: 0.017 ms / frame (4 calls
)
.........Unaccounted: (14.130 %) :: 0.013 ms
.........----------------------------------
.........Profiling: performDiscreteCollisionDetection (total running time: 0.139
ms) ---
.........0 -- dispatchAllCollisionPairs (0.72 %) :: 0.001 ms / frame (4 calls)
.........1 -- calculateOverlappingPairs (8.63 %) :: 0.012 ms / frame (4 calls)
.........2 -- updateAabbs (89.93 %) :: 0.125 ms / frame (4 calls)
.........Unaccounted: (0.719 %) :: 0.001 ms
Moving and avoiding each other
----------------------------------
Profiling: Root (total running time: 66.178 ms) ---
0 -- stepSimulation (99.99 %) :: 66.171 ms / frame (1 calls)
Unaccounted: (0.011 %) :: 0.007 ms
...----------------------------------
...Profiling: stepSimulation (total running time: 66.171 ms) ---
...0 -- synchronizeMotionStates (0.14 %) :: 0.093 ms / frame (4 calls)
...1 -- internalSingleStepSimulation (99.83 %) :: 66.059 ms / frame (4 calls)
...Unaccounted: (0.029 %) :: 0.019 ms
......----------------------------------
......Profiling: internalSingleStepSimulation (total running time: 66.059 ms) --
-
......0 -- updateActivationState (0.01 %) :: 0.007 ms / frame (4 calls)
......1 -- updateActions (0.00 %) :: 0.000 ms / frame (4 calls)
......2 -- integrateTransforms (0.24 %) :: 0.157 ms / frame (4 calls)
......3 -- solveConstraints (0.31 %) :: 0.202 ms / frame (4 calls)
......4 -- calculateSimulationIslands (0.05 %) :: 0.034 ms / frame (4 calls)
......5 -- performDiscreteCollisionDetection (99.20 %) :: 65.531 ms / frame (4 c
alls)
......6 -- predictUnconstraintMotion (0.18 %) :: 0.117 ms / frame (4 calls)
......Unaccounted: (0.017 %) :: 0.011 ms
.........----------------------------------
.........Profiling: solveConstraints (total running time: 0.202 ms) ---
.........0 -- processIslands (39.11 %) :: 0.079 ms / frame (4 calls)
.........1 -- islandUnionFindAndQuickSort (52.48 %) :: 0.106 ms / frame (4 calls
)
.........Unaccounted: (8.416 %) :: 0.017 ms
.........----------------------------------
.........Profiling: performDiscreteCollisionDetection (total running time: 65.53
1 ms) ---
.........0 -- dispatchAllCollisionPairs (98.89 %) :: 64.802 ms / frame (4 calls)
.........1 -- calculateOverlappingPairs (0.05 %) :: 0.035 ms / frame (4 calls)
.........2 -- updateAabbs (1.05 %) :: 0.688 ms / frame (4 calls)
.........Unaccounted: (0.009 %) :: 0.006 ms
Thanks again.
Thank you for your response.
I am using btDbvtBroadphase.
I may have miss read some of the posts, or was thinking the same as the people who posted them, when thinking the large sizes may cause performance issues.
Here is the dump of 20 units at rest and 20 units all moving
20 medium size objects
At Rest
----------------------------------
Profiling: Root (total running time: 0.621 ms) ---
0 -- stepSimulation (98.71 %) :: 0.613 ms / frame (1 calls)
Unaccounted: (1.288 %) :: 0.008 ms
...----------------------------------
...Profiling: stepSimulation (total running time: 0.613 ms) ---
...0 -- synchronizeMotionStates (13.87 %) :: 0.085 ms / frame (4 calls)
...1 -- internalSingleStepSimulation (83.69 %) :: 0.513 ms / frame (4 calls)
...Unaccounted: (2.447 %) :: 0.015 ms
......----------------------------------
......Profiling: internalSingleStepSimulation (total running time: 0.513 ms) ---
......0 -- updateActivationState (1.56 %) :: 0.008 ms / frame (4 calls)
......1 -- updateActions (0.00 %) :: 0.000 ms / frame (4 calls)
......2 -- integrateTransforms (27.68 %) :: 0.142 ms / frame (4 calls)
......3 -- solveConstraints (17.93 %) :: 0.092 ms / frame (4 calls)
......4 -- calculateSimulationIslands (2.73 %) :: 0.014 ms / frame (4 calls)
......5 -- performDiscreteCollisionDetection (27.10 %) :: 0.139 ms / frame (4 ca
lls)
......6 -- predictUnconstraintMotion (21.25 %) :: 0.109 ms / frame (4 calls)
......Unaccounted: (1.754 %) :: 0.009 ms
.........----------------------------------
.........Profiling: solveConstraints (total running time: 0.092 ms) ---
.........0 -- processIslands (67.39 %) :: 0.062 ms / frame (4 calls)
.........1 -- islandUnionFindAndQuickSort (18.48 %) :: 0.017 ms / frame (4 calls
)
.........Unaccounted: (14.130 %) :: 0.013 ms
.........----------------------------------
.........Profiling: performDiscreteCollisionDetection (total running time: 0.139
ms) ---
.........0 -- dispatchAllCollisionPairs (0.72 %) :: 0.001 ms / frame (4 calls)
.........1 -- calculateOverlappingPairs (8.63 %) :: 0.012 ms / frame (4 calls)
.........2 -- updateAabbs (89.93 %) :: 0.125 ms / frame (4 calls)
.........Unaccounted: (0.719 %) :: 0.001 ms
Moving and avoiding each other
----------------------------------
Profiling: Root (total running time: 66.178 ms) ---
0 -- stepSimulation (99.99 %) :: 66.171 ms / frame (1 calls)
Unaccounted: (0.011 %) :: 0.007 ms
...----------------------------------
...Profiling: stepSimulation (total running time: 66.171 ms) ---
...0 -- synchronizeMotionStates (0.14 %) :: 0.093 ms / frame (4 calls)
...1 -- internalSingleStepSimulation (99.83 %) :: 66.059 ms / frame (4 calls)
...Unaccounted: (0.029 %) :: 0.019 ms
......----------------------------------
......Profiling: internalSingleStepSimulation (total running time: 66.059 ms) --
-
......0 -- updateActivationState (0.01 %) :: 0.007 ms / frame (4 calls)
......1 -- updateActions (0.00 %) :: 0.000 ms / frame (4 calls)
......2 -- integrateTransforms (0.24 %) :: 0.157 ms / frame (4 calls)
......3 -- solveConstraints (0.31 %) :: 0.202 ms / frame (4 calls)
......4 -- calculateSimulationIslands (0.05 %) :: 0.034 ms / frame (4 calls)
......5 -- performDiscreteCollisionDetection (99.20 %) :: 65.531 ms / frame (4 c
alls)
......6 -- predictUnconstraintMotion (0.18 %) :: 0.117 ms / frame (4 calls)
......Unaccounted: (0.017 %) :: 0.011 ms
.........----------------------------------
.........Profiling: solveConstraints (total running time: 0.202 ms) ---
.........0 -- processIslands (39.11 %) :: 0.079 ms / frame (4 calls)
.........1 -- islandUnionFindAndQuickSort (52.48 %) :: 0.106 ms / frame (4 calls
)
.........Unaccounted: (8.416 %) :: 0.017 ms
.........----------------------------------
.........Profiling: performDiscreteCollisionDetection (total running time: 65.53
1 ms) ---
.........0 -- dispatchAllCollisionPairs (98.89 %) :: 64.802 ms / frame (4 calls)
.........1 -- calculateOverlappingPairs (0.05 %) :: 0.035 ms / frame (4 calls)
.........2 -- updateAabbs (1.05 %) :: 0.688 ms / frame (4 calls)
.........Unaccounted: (0.009 %) :: 0.006 ms
Thanks again.
-
Erwin Coumans
- Site Admin
- Posts: 4221
- Joined: Sun Jun 26, 2005 6:43 pm
- Location: California, USA
Re: Large Object Optimization Options (performance help plea
From the timings it looks like a collision detection (contact generation) bottleneck.
Can you please attach a .bullet file to this topic?
You can easily generate it using
How many vertices do the btConvexHullShape objects contain? Best is to keep that number low (<31 or so).
Thanks,
Erwin
Can you please attach a .bullet file to this topic?
You can easily generate it using
Code: Select all
btDefaultSerializer* serializer = new btDefaultSerializer();
dynamicsWorld->serialize(serializer);
FILE* file = fopen("testFile.bullet","wb");
fwrite(serializer->getBufferPointer(),serializer->getCurrentBufferSize(),1, file);
fclose(file);
Thanks,
Erwin
-
duser
- Posts: 16
- Joined: Wed Feb 02, 2011 6:48 pm
Re: Large Object Optimization Options (performance help plea
Sorry, the data I sent back was in Debug mode.
Yes all of the convex hulls are below 32 verticies (using btShapeHull). Originally some have over 100 verticies, but after the btShapeHull, they drop to 30 or less.
Here is release:
resting
----------------------------------
Profiling: Root (total running time: 0.178 ms) ---
0 -- stepSimulation (94.94 %) :: 0.169 ms / frame (1 calls)
Unaccounted: (5.056 %) :: 0.009 ms
...----------------------------------
...Profiling: stepSimulation (total running time: 0.169 ms) ---
...0 -- synchronizeMotionStates (10.65 %) :: 0.018 ms / frame (4 calls)
...1 -- internalSingleStepSimulation (85.80 %) :: 0.145 ms / frame (4 calls)
...Unaccounted: (3.550 %) :: 0.006 ms
......----------------------------------
......Profiling: internalSingleStepSimulation (total running time: 0.145 ms) ---
......0 -- updateActivationState (0.69 %) :: 0.001 ms / frame (4 calls)
......1 -- updateActions (0.69 %) :: 0.001 ms / frame (4 calls)
......2 -- integrateTransforms (18.62 %) :: 0.027 ms / frame (4 calls)
......3 -- solveConstraints (21.38 %) :: 0.031 ms / frame (4 calls)
......4 -- calculateSimulationIslands (2.07 %) :: 0.003 ms / frame (4 calls)
......5 -- performDiscreteCollisionDetection (32.41 %) :: 0.047 ms / frame (4 ca
lls)
......6 -- predictUnconstraintMotion (21.38 %) :: 0.031 ms / frame (4 calls)
......Unaccounted: (2.759 %) :: 0.004 ms
.........----------------------------------
.........Profiling: solveConstraints (total running time: 0.031 ms) ---
.........0 -- processIslands (70.97 %) :: 0.022 ms / frame (4 calls)
.........1 -- islandUnionFindAndQuickSort (12.90 %) :: 0.004 ms / frame (4 calls
)
.........Unaccounted: (16.129 %) :: 0.005 ms
.........----------------------------------
.........Profiling: performDiscreteCollisionDetection (total running time: 0.047
ms) ---
.........0 -- dispatchAllCollisionPairs (2.13 %) :: 0.001 ms / frame (4 calls)
.........1 -- calculateOverlappingPairs (6.38 %) :: 0.003 ms / frame (4 calls)
.........2 -- updateAabbs (85.11 %) :: 0.040 ms / frame (4 calls)
.........Unaccounted: (6.383 %) :: 0.003 ms
moving
----------------------------------
Profiling: Root (total running time: 16.155 ms) ---
0 -- stepSimulation (99.97 %) :: 16.150 ms / frame (1 calls)
Unaccounted: (0.031 %) :: 0.005 ms
...----------------------------------
...Profiling: stepSimulation (total running time: 16.150 ms) ---
...0 -- synchronizeMotionStates (0.17 %) :: 0.027 ms / frame (4 calls)
...1 -- internalSingleStepSimulation (99.80 %) :: 16.117 ms / frame (4 calls)
...Unaccounted: (0.037 %) :: 0.006 ms
......----------------------------------
......Profiling: internalSingleStepSimulation (total running time: 16.117 ms) --
-
......0 -- updateActivationState (0.02 %) :: 0.003 ms / frame (4 calls)
......1 -- updateActions (0.00 %) :: 0.000 ms / frame (4 calls)
......2 -- integrateTransforms (0.22 %) :: 0.035 ms / frame (4 calls)
......3 -- solveConstraints (0.40 %) :: 0.064 ms / frame (4 calls)
......4 -- calculateSimulationIslands (0.04 %) :: 0.006 ms / frame (4 calls)
......5 -- performDiscreteCollisionDetection (99.06 %) :: 15.966 ms / frame (4 c
alls)
......6 -- predictUnconstraintMotion (0.24 %) :: 0.038 ms / frame (4 calls)
......Unaccounted: (0.031 %) :: 0.005 ms
.........----------------------------------
.........Profiling: solveConstraints (total running time: 0.064 ms) ---
.........0 -- processIslands (46.88 %) :: 0.030 ms / frame (4 calls)
.........1 -- islandUnionFindAndQuickSort (42.19 %) :: 0.027 ms / frame (4 calls
)
.........Unaccounted: (10.937 %) :: 0.007 ms
.........----------------------------------
.........Profiling: performDiscreteCollisionDetection (total running time: 15.96
6 ms) ---
.........0 -- dispatchAllCollisionPairs (98.99 %) :: 15.804 ms / frame (4 calls)
.........1 -- calculateOverlappingPairs (0.03 %) :: 0.005 ms / frame (4 calls)
.........2 -- updateAabbs (0.96 %) :: 0.154 ms / frame (4 calls)
.........Unaccounted: (0.019 %) :: 0.003 ms
Also I have the testfile.bullet file attached.
Thanks
Yes all of the convex hulls are below 32 verticies (using btShapeHull). Originally some have over 100 verticies, but after the btShapeHull, they drop to 30 or less.
Here is release:
resting
----------------------------------
Profiling: Root (total running time: 0.178 ms) ---
0 -- stepSimulation (94.94 %) :: 0.169 ms / frame (1 calls)
Unaccounted: (5.056 %) :: 0.009 ms
...----------------------------------
...Profiling: stepSimulation (total running time: 0.169 ms) ---
...0 -- synchronizeMotionStates (10.65 %) :: 0.018 ms / frame (4 calls)
...1 -- internalSingleStepSimulation (85.80 %) :: 0.145 ms / frame (4 calls)
...Unaccounted: (3.550 %) :: 0.006 ms
......----------------------------------
......Profiling: internalSingleStepSimulation (total running time: 0.145 ms) ---
......0 -- updateActivationState (0.69 %) :: 0.001 ms / frame (4 calls)
......1 -- updateActions (0.69 %) :: 0.001 ms / frame (4 calls)
......2 -- integrateTransforms (18.62 %) :: 0.027 ms / frame (4 calls)
......3 -- solveConstraints (21.38 %) :: 0.031 ms / frame (4 calls)
......4 -- calculateSimulationIslands (2.07 %) :: 0.003 ms / frame (4 calls)
......5 -- performDiscreteCollisionDetection (32.41 %) :: 0.047 ms / frame (4 ca
lls)
......6 -- predictUnconstraintMotion (21.38 %) :: 0.031 ms / frame (4 calls)
......Unaccounted: (2.759 %) :: 0.004 ms
.........----------------------------------
.........Profiling: solveConstraints (total running time: 0.031 ms) ---
.........0 -- processIslands (70.97 %) :: 0.022 ms / frame (4 calls)
.........1 -- islandUnionFindAndQuickSort (12.90 %) :: 0.004 ms / frame (4 calls
)
.........Unaccounted: (16.129 %) :: 0.005 ms
.........----------------------------------
.........Profiling: performDiscreteCollisionDetection (total running time: 0.047
ms) ---
.........0 -- dispatchAllCollisionPairs (2.13 %) :: 0.001 ms / frame (4 calls)
.........1 -- calculateOverlappingPairs (6.38 %) :: 0.003 ms / frame (4 calls)
.........2 -- updateAabbs (85.11 %) :: 0.040 ms / frame (4 calls)
.........Unaccounted: (6.383 %) :: 0.003 ms
moving
----------------------------------
Profiling: Root (total running time: 16.155 ms) ---
0 -- stepSimulation (99.97 %) :: 16.150 ms / frame (1 calls)
Unaccounted: (0.031 %) :: 0.005 ms
...----------------------------------
...Profiling: stepSimulation (total running time: 16.150 ms) ---
...0 -- synchronizeMotionStates (0.17 %) :: 0.027 ms / frame (4 calls)
...1 -- internalSingleStepSimulation (99.80 %) :: 16.117 ms / frame (4 calls)
...Unaccounted: (0.037 %) :: 0.006 ms
......----------------------------------
......Profiling: internalSingleStepSimulation (total running time: 16.117 ms) --
-
......0 -- updateActivationState (0.02 %) :: 0.003 ms / frame (4 calls)
......1 -- updateActions (0.00 %) :: 0.000 ms / frame (4 calls)
......2 -- integrateTransforms (0.22 %) :: 0.035 ms / frame (4 calls)
......3 -- solveConstraints (0.40 %) :: 0.064 ms / frame (4 calls)
......4 -- calculateSimulationIslands (0.04 %) :: 0.006 ms / frame (4 calls)
......5 -- performDiscreteCollisionDetection (99.06 %) :: 15.966 ms / frame (4 c
alls)
......6 -- predictUnconstraintMotion (0.24 %) :: 0.038 ms / frame (4 calls)
......Unaccounted: (0.031 %) :: 0.005 ms
.........----------------------------------
.........Profiling: solveConstraints (total running time: 0.064 ms) ---
.........0 -- processIslands (46.88 %) :: 0.030 ms / frame (4 calls)
.........1 -- islandUnionFindAndQuickSort (42.19 %) :: 0.027 ms / frame (4 calls
)
.........Unaccounted: (10.937 %) :: 0.007 ms
.........----------------------------------
.........Profiling: performDiscreteCollisionDetection (total running time: 15.96
6 ms) ---
.........0 -- dispatchAllCollisionPairs (98.99 %) :: 15.804 ms / frame (4 calls)
.........1 -- calculateOverlappingPairs (0.03 %) :: 0.005 ms / frame (4 calls)
.........2 -- updateAabbs (0.96 %) :: 0.154 ms / frame (4 calls)
.........Unaccounted: (0.019 %) :: 0.003 ms
Also I have the testfile.bullet file attached.
Thanks
You do not have the required permissions to view the files attached to this post.
-
duser
- Posts: 16
- Joined: Wed Feb 02, 2011 6:48 pm
Re: Large Object Optimization Options (performance help plea
I'm going to assume that the partial cause was that some of the objects contained more than 31 verticies (like I said, I used btShapeHull to reduce the number but it may not have been enough).
I changed the variables in the ModelConvexDecomposition program (reduces the regular high poly mesh to a low poly mesh) enough to get half of the verticies out than what was before (eg: if originally I would get 64 verts, with the changes I would get 29 verts). I then used the btShapeHull to reduce it once more.
The time has greatly reduced, but still not where I'm hoping:
20 SHIPS
----------------------------------
Profiling: Root (total running time: 3.133 ms) ---
0 -- stepSimulation (99.78 %) :: 3.126 ms / frame (1 calls)
Unaccounted: (0.223 %) :: 0.007 ms
...----------------------------------
...Profiling: stepSimulation (total running time: 3.126 ms) ---
...0 -- synchronizeMotionStates (0.19 %) :: 0.006 ms / frame (1 calls)
...1 -- internalSingleStepSimulation (99.58 %) :: 3.113 ms / frame (1 calls)
...Unaccounted: (0.224 %) :: 0.007 ms
......----------------------------------
......Profiling: internalSingleStepSimulation (total running time: 3.113 ms) ---
......0 -- updateActivationState (0.00 %) :: 0.000 ms / frame (1 calls)
......1 -- updateActions (0.00 %) :: 0.000 ms / frame (1 calls)
......2 -- integrateTransforms (0.29 %) :: 0.009 ms / frame (1 calls)
......3 -- solveConstraints (0.51 %) :: 0.016 ms / frame (1 calls)
......4 -- calculateSimulationIslands (0.10 %) :: 0.003 ms / frame (1 calls)
......5 -- performDiscreteCollisionDetection (98.55 %) :: 3.068 ms / frame (1 ca
lls)
......6 -- predictUnconstraintMotion (0.48 %) :: 0.015 ms / frame (1 calls)
......Unaccounted: (0.064 %) :: 0.002 ms
.........----------------------------------
.........Profiling: solveConstraints (total running time: 0.016 ms) ---
.........0 -- processIslands (56.25 %) :: 0.009 ms / frame (1 calls)
.........1 -- islandUnionFindAndQuickSort (31.25 %) :: 0.005 ms / frame (1 calls
)
.........Unaccounted: (12.500 %) :: 0.002 ms
.........----------------------------------
.........Profiling: performDiscreteCollisionDetection (total running time: 3.068
ms) ---
.........0 -- dispatchAllCollisionPairs (97.98 %) :: 3.006 ms / frame (1 calls)
.........1 -- calculateOverlappingPairs (0.07 %) :: 0.002 ms / frame (1 calls)
.........2 -- updateAabbs (1.92 %) :: 0.059 ms / frame (1 calls)
.........Unaccounted: (0.033 %) :: 0.001 ms
Still not as fast as I'd like (still is pretty high for 50 ships and I'm hoping to get at least 100)
50 SHIPS
----------------------------------
Profiling: Root (total running time: 18.139 ms) ---
0 -- stepSimulation (99.96 %) :: 18.132 ms / frame (1 calls)
Unaccounted: (0.039 %) :: 0.007 ms
...----------------------------------
...Profiling: stepSimulation (total running time: 18.132 ms) ---
...0 -- synchronizeMotionStates (0.08 %) :: 0.015 ms / frame (1 calls)
...1 -- internalSingleStepSimulation (99.84 %) :: 18.103 ms / frame (1 calls)
...Unaccounted: (0.077 %) :: 0.014 ms
......----------------------------------
......Profiling: internalSingleStepSimulation (total running time: 18.103 ms) --
-
......0 -- updateActivationState (0.01 %) :: 0.002 ms / frame (1 calls)
......1 -- updateActions (0.00 %) :: 0.000 ms / frame (1 calls)
......2 -- integrateTransforms (0.14 %) :: 0.025 ms / frame (1 calls)
......3 -- solveConstraints (0.31 %) :: 0.057 ms / frame (1 calls)
......4 -- calculateSimulationIslands (0.03 %) :: 0.006 ms / frame (1 calls)
......5 -- performDiscreteCollisionDetection (99.33 %) :: 17.981 ms / frame (1 c
alls)
......6 -- predictUnconstraintMotion (0.17 %) :: 0.030 ms / frame (1 calls)
......Unaccounted: (0.011 %) :: 0.002 ms
.........----------------------------------
.........Profiling: solveConstraints (total running time: 0.057 ms) ---
.........0 -- processIslands (40.35 %) :: 0.023 ms / frame (1 calls)
.........1 -- islandUnionFindAndQuickSort (47.37 %) :: 0.027 ms / frame (1 calls
)
.........Unaccounted: (12.281 %) :: 0.007 ms
.........----------------------------------
.........Profiling: performDiscreteCollisionDetection (total running time: 17.98
1 ms) ---
.........0 -- dispatchAllCollisionPairs (99.18 %) :: 17.833 ms / frame (1 calls)
.........1 -- calculateOverlappingPairs (0.02 %) :: 0.003 ms / frame (1 calls)
.........2 -- updateAabbs (0.80 %) :: 0.144 ms / frame (1 calls)
.........Unaccounted: (0.006 %) :: 0.001 ms
I plan to keep playing with the number verticies, but if you find anything else the .bullet file or have any other tips, please let me know.
Thanks again for you help.
I changed the variables in the ModelConvexDecomposition program (reduces the regular high poly mesh to a low poly mesh) enough to get half of the verticies out than what was before (eg: if originally I would get 64 verts, with the changes I would get 29 verts). I then used the btShapeHull to reduce it once more.
The time has greatly reduced, but still not where I'm hoping:
20 SHIPS
----------------------------------
Profiling: Root (total running time: 3.133 ms) ---
0 -- stepSimulation (99.78 %) :: 3.126 ms / frame (1 calls)
Unaccounted: (0.223 %) :: 0.007 ms
...----------------------------------
...Profiling: stepSimulation (total running time: 3.126 ms) ---
...0 -- synchronizeMotionStates (0.19 %) :: 0.006 ms / frame (1 calls)
...1 -- internalSingleStepSimulation (99.58 %) :: 3.113 ms / frame (1 calls)
...Unaccounted: (0.224 %) :: 0.007 ms
......----------------------------------
......Profiling: internalSingleStepSimulation (total running time: 3.113 ms) ---
......0 -- updateActivationState (0.00 %) :: 0.000 ms / frame (1 calls)
......1 -- updateActions (0.00 %) :: 0.000 ms / frame (1 calls)
......2 -- integrateTransforms (0.29 %) :: 0.009 ms / frame (1 calls)
......3 -- solveConstraints (0.51 %) :: 0.016 ms / frame (1 calls)
......4 -- calculateSimulationIslands (0.10 %) :: 0.003 ms / frame (1 calls)
......5 -- performDiscreteCollisionDetection (98.55 %) :: 3.068 ms / frame (1 ca
lls)
......6 -- predictUnconstraintMotion (0.48 %) :: 0.015 ms / frame (1 calls)
......Unaccounted: (0.064 %) :: 0.002 ms
.........----------------------------------
.........Profiling: solveConstraints (total running time: 0.016 ms) ---
.........0 -- processIslands (56.25 %) :: 0.009 ms / frame (1 calls)
.........1 -- islandUnionFindAndQuickSort (31.25 %) :: 0.005 ms / frame (1 calls
)
.........Unaccounted: (12.500 %) :: 0.002 ms
.........----------------------------------
.........Profiling: performDiscreteCollisionDetection (total running time: 3.068
ms) ---
.........0 -- dispatchAllCollisionPairs (97.98 %) :: 3.006 ms / frame (1 calls)
.........1 -- calculateOverlappingPairs (0.07 %) :: 0.002 ms / frame (1 calls)
.........2 -- updateAabbs (1.92 %) :: 0.059 ms / frame (1 calls)
.........Unaccounted: (0.033 %) :: 0.001 ms
Still not as fast as I'd like (still is pretty high for 50 ships and I'm hoping to get at least 100)
50 SHIPS
----------------------------------
Profiling: Root (total running time: 18.139 ms) ---
0 -- stepSimulation (99.96 %) :: 18.132 ms / frame (1 calls)
Unaccounted: (0.039 %) :: 0.007 ms
...----------------------------------
...Profiling: stepSimulation (total running time: 18.132 ms) ---
...0 -- synchronizeMotionStates (0.08 %) :: 0.015 ms / frame (1 calls)
...1 -- internalSingleStepSimulation (99.84 %) :: 18.103 ms / frame (1 calls)
...Unaccounted: (0.077 %) :: 0.014 ms
......----------------------------------
......Profiling: internalSingleStepSimulation (total running time: 18.103 ms) --
-
......0 -- updateActivationState (0.01 %) :: 0.002 ms / frame (1 calls)
......1 -- updateActions (0.00 %) :: 0.000 ms / frame (1 calls)
......2 -- integrateTransforms (0.14 %) :: 0.025 ms / frame (1 calls)
......3 -- solveConstraints (0.31 %) :: 0.057 ms / frame (1 calls)
......4 -- calculateSimulationIslands (0.03 %) :: 0.006 ms / frame (1 calls)
......5 -- performDiscreteCollisionDetection (99.33 %) :: 17.981 ms / frame (1 c
alls)
......6 -- predictUnconstraintMotion (0.17 %) :: 0.030 ms / frame (1 calls)
......Unaccounted: (0.011 %) :: 0.002 ms
.........----------------------------------
.........Profiling: solveConstraints (total running time: 0.057 ms) ---
.........0 -- processIslands (40.35 %) :: 0.023 ms / frame (1 calls)
.........1 -- islandUnionFindAndQuickSort (47.37 %) :: 0.027 ms / frame (1 calls
)
.........Unaccounted: (12.281 %) :: 0.007 ms
.........----------------------------------
.........Profiling: performDiscreteCollisionDetection (total running time: 17.98
1 ms) ---
.........0 -- dispatchAllCollisionPairs (99.18 %) :: 17.833 ms / frame (1 calls)
.........1 -- calculateOverlappingPairs (0.02 %) :: 0.003 ms / frame (1 calls)
.........2 -- updateAabbs (0.80 %) :: 0.144 ms / frame (1 calls)
.........Unaccounted: (0.006 %) :: 0.001 ms
I plan to keep playing with the number verticies, but if you find anything else the .bullet file or have any other tips, please let me know.
Thanks again for you help.
-
Erwin Coumans
- Site Admin
- Posts: 4221
- Joined: Sun Jun 26, 2005 6:43 pm
- Location: California, USA
Re: Large Object Optimization Options (performance help plea
I had a look at the .bullet file, but the ships are all separate and not colliding with anything: they all just fall down.
Are there any collisions happening during your performance capture (dump)? If so, can you capture the state of such slow frame?
Thanks,
Erwin
Are there any collisions happening during your performance capture (dump)? If so, can you capture the state of such slow frame?
Thanks,
Erwin
-
duser
- Posts: 16
- Joined: Wed Feb 02, 2011 6:48 pm
Re: Large Object Optimization Options (performance help plea
Hi Erwin,
Sorry about that. I generate the .bullet file right after the stepSimulation (not sure if that makes a difference).
The only things that should be colliding are the ships (rigidbodies) with ghost objects (used to determine if there is anything in the ship's path).
Here is the profile dump of the frame the .bullet file was created (in release using 50 ships). Its substantially faster after I reduced the convex hulls' verticies to roughly 20. Still slow with only 50 medium ships. Just curious on if its strictly the verticies count or if something else could cause the drop.
----------------------------------
Profiling: Root (total running time: 16.522 ms) ---
0 -- stepSimulation (99.97 %) :: 16.517 ms / frame (1 calls)
Unaccounted: (0.030 %) :: 0.005 ms
...----------------------------------
...Profiling: stepSimulation (total running time: 16.517 ms) ---
...0 -- synchronizeMotionStates (0.10 %) :: 0.016 ms / frame (1 calls)
...1 -- internalSingleStepSimulation (99.79 %) :: 16.483 ms / frame (1 calls)
...Unaccounted: (0.109 %) :: 0.018 ms
......----------------------------------
......Profiling: internalSingleStepSimulation (total running time: 16.483 ms) --
-
......0 -- updateActivationState (0.01 %) :: 0.001 ms / frame (1 calls)
......1 -- updateActions (0.01 %) :: 0.001 ms / frame (1 calls)
......2 -- integrateTransforms (0.15 %) :: 0.025 ms / frame (1 calls)
......3 -- solveConstraints (0.36 %) :: 0.060 ms / frame (1 calls)
......4 -- calculateSimulationIslands (0.05 %) :: 0.009 ms / frame (1 calls)
......5 -- performDiscreteCollisionDetection (99.22 %) :: 16.354 ms / frame (1 c
alls)
......6 -- predictUnconstraintMotion (0.18 %) :: 0.030 ms / frame (1 calls)
......Unaccounted: (0.018 %) :: 0.003 ms
.........----------------------------------
.........Profiling: solveConstraints (total running time: 0.060 ms) ---
.........0 -- processIslands (21.67 %) :: 0.013 ms / frame (1 calls)
.........1 -- islandUnionFindAndQuickSort (75.00 %) :: 0.045 ms / frame (1 calls
)
.........Unaccounted: (3.333 %) :: 0.002 ms
.........----------------------------------
.........Profiling: performDiscreteCollisionDetection (total running time: 16.35
4 ms) ---
.........0 -- dispatchAllCollisionPairs (98.77 %) :: 16.153 ms / frame (1 calls)
.........1 -- calculateOverlappingPairs (0.02 %) :: 0.004 ms / frame (1 calls)
.........2 -- updateAabbs (1.20 %) :: 0.197 ms / frame (1 calls)
.........Unaccounted: (0.000 %) :: 0.000 ms
Thanks again.
Sorry about that. I generate the .bullet file right after the stepSimulation (not sure if that makes a difference).
The only things that should be colliding are the ships (rigidbodies) with ghost objects (used to determine if there is anything in the ship's path).
Here is the profile dump of the frame the .bullet file was created (in release using 50 ships). Its substantially faster after I reduced the convex hulls' verticies to roughly 20. Still slow with only 50 medium ships. Just curious on if its strictly the verticies count or if something else could cause the drop.
----------------------------------
Profiling: Root (total running time: 16.522 ms) ---
0 -- stepSimulation (99.97 %) :: 16.517 ms / frame (1 calls)
Unaccounted: (0.030 %) :: 0.005 ms
...----------------------------------
...Profiling: stepSimulation (total running time: 16.517 ms) ---
...0 -- synchronizeMotionStates (0.10 %) :: 0.016 ms / frame (1 calls)
...1 -- internalSingleStepSimulation (99.79 %) :: 16.483 ms / frame (1 calls)
...Unaccounted: (0.109 %) :: 0.018 ms
......----------------------------------
......Profiling: internalSingleStepSimulation (total running time: 16.483 ms) --
-
......0 -- updateActivationState (0.01 %) :: 0.001 ms / frame (1 calls)
......1 -- updateActions (0.01 %) :: 0.001 ms / frame (1 calls)
......2 -- integrateTransforms (0.15 %) :: 0.025 ms / frame (1 calls)
......3 -- solveConstraints (0.36 %) :: 0.060 ms / frame (1 calls)
......4 -- calculateSimulationIslands (0.05 %) :: 0.009 ms / frame (1 calls)
......5 -- performDiscreteCollisionDetection (99.22 %) :: 16.354 ms / frame (1 c
alls)
......6 -- predictUnconstraintMotion (0.18 %) :: 0.030 ms / frame (1 calls)
......Unaccounted: (0.018 %) :: 0.003 ms
.........----------------------------------
.........Profiling: solveConstraints (total running time: 0.060 ms) ---
.........0 -- processIslands (21.67 %) :: 0.013 ms / frame (1 calls)
.........1 -- islandUnionFindAndQuickSort (75.00 %) :: 0.045 ms / frame (1 calls
)
.........Unaccounted: (3.333 %) :: 0.002 ms
.........----------------------------------
.........Profiling: performDiscreteCollisionDetection (total running time: 16.35
4 ms) ---
.........0 -- dispatchAllCollisionPairs (98.77 %) :: 16.153 ms / frame (1 calls)
.........1 -- calculateOverlappingPairs (0.02 %) :: 0.004 ms / frame (1 calls)
.........2 -- updateAabbs (1.20 %) :: 0.197 ms / frame (1 calls)
.........Unaccounted: (0.000 %) :: 0.000 ms
Thanks again.
You do not have the required permissions to view the files attached to this post.
-
Erwin Coumans
- Site Admin
- Posts: 4221
- Joined: Sun Jun 26, 2005 6:43 pm
- Location: California, USA
Re: Large Object Optimization Options (performance help plea
Ghost objects are not serialized yet.
What kind of collision shape are you using for the btGhostObject?
If you remove the ghost objects, the performance issue is solver?
You could try using a btConvexSweepTest, using a sphere shape instead, to search for object along the path.
Thanks,
Erwin
What kind of collision shape are you using for the btGhostObject?
If you remove the ghost objects, the performance issue is solver?
You could try using a btConvexSweepTest, using a sphere shape instead, to search for object along the path.
Thanks,
Erwin
-
duser
- Posts: 16
- Joined: Wed Feb 02, 2011 6:48 pm
Re: Large Object Optimization Options (performance help plea
The ghost objects are btPairCachingGhostObject and their collision shapes are btConvexHullShapes of 8 points creating a rectangle. The intention for setting it up this way was to try reduce the cumulative costs of calling convexSweepTests.
Yes the physics update will be faster without the ghost objects once they are removed because without the ghost objects, nothing will be colliding.
I tried this with 60 ships, removed all the ghost objects, and used the convexSweepTests to determine if anything is in a ship's path. Each sweep test ran from 0.11ms to 0.80ms (I would assume depending on the number of collisions objects it encounters). Also to note I am using a custom convexresaultcallback to obtain all of the results so that I can later determine if it is a valid object to avoid. Still on the slowest frame (that I saw so far), it could take 19ms for all 60 test to complete. Since this is once every 3 frames, this should be alright (the other frames are roughly 4-5ms and bullet is < 0.5ms as nothing is colliding in the stepSimulation).
So with using convexSweepTests instead of Ghost Objects and reducing the number of verticies for the collision objects, it does help speed up the frame substantially compared to how it was before.
Is there by any chance a way to run a several convexSweepTest to speed up the time it takes for a large number of tests (like a batched sweep test)?
Does 0.11ms - 0.8ms sound typical for the sweep tests?
Any other advice for doing a large number of sweep tests in a frame?
Thank you very much for your help.
Yes the physics update will be faster without the ghost objects once they are removed because without the ghost objects, nothing will be colliding.
I tried this with 60 ships, removed all the ghost objects, and used the convexSweepTests to determine if anything is in a ship's path. Each sweep test ran from 0.11ms to 0.80ms (I would assume depending on the number of collisions objects it encounters). Also to note I am using a custom convexresaultcallback to obtain all of the results so that I can later determine if it is a valid object to avoid. Still on the slowest frame (that I saw so far), it could take 19ms for all 60 test to complete. Since this is once every 3 frames, this should be alright (the other frames are roughly 4-5ms and bullet is < 0.5ms as nothing is colliding in the stepSimulation).
So with using convexSweepTests instead of Ghost Objects and reducing the number of verticies for the collision objects, it does help speed up the frame substantially compared to how it was before.
Is there by any chance a way to run a several convexSweepTest to speed up the time it takes for a large number of tests (like a batched sweep test)?
Does 0.11ms - 0.8ms sound typical for the sweep tests?
Any other advice for doing a large number of sweep tests in a frame?
Thank you very much for your help.
-
duser
- Posts: 16
- Joined: Wed Feb 02, 2011 6:48 pm
Re: Large Object Optimization Options (performance help plea
Another question for this topic.
What are the pros and cons of a convexSweepTest vs a contactTest?
My new problem is that I need contact points on the object in the world. I would also like to use a frustum as my shape to view what is ahead of the ship.
What happens is:
A) if I use a frustum collision shape in a convexSweepTest (shift the transform ahead 1 m), the time is really fast, but if a ship is inside the volume, it does not get detected.
B) if I use a sphere collision shape in a convexSweepTest, it is really slow (test ranges from 1000 - 3500 m travel distance in the forward direction), but it is only one size the whole test (not frustum shape).
C) if I use a frustum collision shape in a contactTest, it gets all the data I need (even ships inside the volume), but it is really slow (it can go up to 3ms a test). With 20 ships, the total of all the contactTests was about 17-25ms.
Is there a difference in speed with the contactTest and convexSweepTest or does a contactTest basically do the same thing except obtain collisions within a volume?
Open opinion, what is better (say for this scenario)?
Is there a way to use a frustum shape (scaled object) in a sweepTest? If so, could this speed up the test?
Is it possible to use a compound object for a sweep test (like 2-3 convexRects to catch anything inside the frustum)?
Thank you again.
What are the pros and cons of a convexSweepTest vs a contactTest?
My new problem is that I need contact points on the object in the world. I would also like to use a frustum as my shape to view what is ahead of the ship.
What happens is:
A) if I use a frustum collision shape in a convexSweepTest (shift the transform ahead 1 m), the time is really fast, but if a ship is inside the volume, it does not get detected.
B) if I use a sphere collision shape in a convexSweepTest, it is really slow (test ranges from 1000 - 3500 m travel distance in the forward direction), but it is only one size the whole test (not frustum shape).
C) if I use a frustum collision shape in a contactTest, it gets all the data I need (even ships inside the volume), but it is really slow (it can go up to 3ms a test). With 20 ships, the total of all the contactTests was about 17-25ms.
Is there a difference in speed with the contactTest and convexSweepTest or does a contactTest basically do the same thing except obtain collisions within a volume?
Open opinion, what is better (say for this scenario)?
Is there a way to use a frustum shape (scaled object) in a sweepTest? If so, could this speed up the test?
Is it possible to use a compound object for a sweep test (like 2-3 convexRects to catch anything inside the frustum)?
Thank you again.