Shared Track Objects

[alex25]

Current wip parameters(commented out ones are optional):

Code:

[body.foo]
texture = diffuse.png
model = body.joe
#clampuv = 0
#mipmap = true
#skybox = false
#nolighting = false
#transparent = false
#isashadow = false
#collideable = false
#surface = 0
#mass = 0 # mass, to be implemented
#size = 1, 1, 1 # axis aligned bounding box, to be implemented

[node.bla]
body = foo
#position = 0, 0, 0
#rotation = 0, 0, 0

you left out double-sided (currently it is implemented as transparent = 2 as documented in vdrift-trackeditor/listedit/format.txt). we don't want to lose support for that.

--alex--

[NaN]

OK.

I am parsing transparency as a number. The above parameter description is incorrect.

[alex25]

it would probably make more sense to have a double-sided parameter as it doesn't have anything to do with transparency. when it got implemented i re-used the transparency flag because we didn't want to add an extra flag.

also, i always wandered if it is possible (from an openGL point a view) to have a double-sided transparent blended texture. with the current implementation there is no possibility of specifying that (and i know textures where this would be useful).

--alex--

[NaN]

double-sided parameter

Sounds good.

Joe is doing the graphics maybe he can comment on the other stuff and give some info about the features, parameters of the new renderer.

[joevenzon]

i always wandered if it is possible (from an openGL point a view) to have a double-sided transparent blended texture

Yep, nothing at all stopping that.

Joe is doing the graphics maybe he can comment on the other stuff and give some info about the features, parameters of the new renderer.

The GL3 renderer supports arbitrarily named textures and uniforms (variables) that get passed to the shader. I'm not sure if we want to expose that in the track or car formats, or use the DRAWABLE as an abstraction layer. At the moment the DRAWABLE provides abstraction, so you call DRAWABLE::SetColor(), and it sets the "colorTint" uniform that gets sent to the shader.

[alex25]

so i guess we should then implement a new double-sided flag, separate from the transparency one in the new objects.txt.

--alex--

[NaN]

As we are going to have mesh instanced I've been looking how to fit it into the simulation.

Current setup is limited by car simulation and wheel rays (sweep broadphase, single track object vs car)

Code:

Profiling: Root (total running time: 0.990 ms) ---
0 -- stepSimulation (99.70 %) :: 0.987 ms / frame (1 calls)
Unaccounted: (0.303 %) :: 0.003 ms
...----------------------------------
...Profiling: stepSimulation (total running time: 0.987 ms) ---
...0 -- synchronizeMotionStates (0.41 %) :: 0.004 ms / frame (1 calls)
...1 -- internalSingleStepSimulation (98.78 %) :: 0.975 ms / frame (1 calls)
...Unaccounted: (0.811 %) :: 0.008 ms
......----------------------------------
......Profiling: internalSingleStepSimulation (total running time: 0.975 ms) ---
......0 -- updateActivationState (0.10 %) :: 0.001 ms / frame (1 calls)
......1 -- updateActions (87.49 %) :: 0.853 ms / frame (1 calls)
......2 -- integrateTransforms (0.51 %) :: 0.005 ms / frame (1 calls)
......3 -- solveConstraints (2.87 %) :: 0.028 ms / frame (1 calls)
......4 -- calculateSimulationIslands (0.41 %) :: 0.004 ms / frame (1 calls)
......5 -- performDiscreteCollisionDetection (6.36 %) :: 0.062 ms / frame (1 calls)
......6 -- predictUnconstraintMotion (1.33 %) :: 0.013 ms / frame (1 calls)
......Unaccounted: (0.923 %) :: 0.009 ms
.........----------------------------------
.........Profiling: solveConstraints (total running time: 0.028 ms) ---
.........0 -- solveGroup (39.29 %) :: 0.011 ms / frame (1 calls)
.........1 -- processIslands (21.43 %) :: 0.006 ms / frame (1 calls)
.........2 -- islandUnionFindAndQuickSort (10.71 %) :: 0.003 ms / frame (1 calls)
.........Unaccounted: (28.571 %) :: 0.008 ms
............----------------------------------
............Profiling: solveGroup (total running time: 0.011 ms) ---
............0 -- solveGroupCacheFriendlyIterations (18.18 %) :: 0.002 ms / frame (1 calls)
............1 -- solveGroupCacheFriendlySetup (45.45 %) :: 0.005 ms / frame (1 calls)
............Unaccounted: (36.364 %) :: 0.004 ms
.........----------------------------------
.........Profiling: performDiscreteCollisionDetection (total running time: 0.062 ms) ---
.........0 -- dispatchAllCollisionPairs (64.52 %) :: 0.040 ms / frame (1 calls)
.........1 -- calculateOverlappingPairs (1.61 %) :: 0.001 ms / frame (1 calls)
.........2 -- updateAabbs (27.42 %) :: 0.017 ms / frame (1 calls)
.........Unaccounted: (6.452 %) :: 0.004 ms

Switching to another acceleration structure turns out to be a bit faster (dynamic bvt broadphase, single track object vs car)

Code:

Profiling: Root (total running time: 0.880 ms) ---
0 -- stepSimulation (99.77 %) :: 0.878 ms / frame (1 calls)
Unaccounted: (0.227 %) :: 0.002 ms
...----------------------------------
...Profiling: stepSimulation (total running time: 0.878 ms) ---
...0 -- synchronizeMotionStates (0.34 %) :: 0.003 ms / frame (1 calls)
...1 -- internalSingleStepSimulation (98.97 %) :: 0.869 ms / frame (1 calls)
...Unaccounted: (0.683 %) :: 0.006 ms
......----------------------------------
......Profiling: internalSingleStepSimulation (total running time: 0.869 ms) ---
......0 -- updateActivationState (0.12 %) :: 0.001 ms / frame (1 calls)
......1 -- updateActions (90.68 %) :: 0.788 ms / frame (1 calls)
......2 -- integrateTransforms (0.46 %) :: 0.004 ms / frame (1 calls)
......3 -- solveConstraints (2.53 %) :: 0.022 ms / frame (1 calls)
......4 -- calculateSimulationIslands (0.35 %) :: 0.003 ms / frame (1 calls)
......5 -- performDiscreteCollisionDetection (4.37 %) :: 0.038 ms / frame (1 calls)
......6 -- predictUnconstraintMotion (0.58 %) :: 0.005 ms / frame (1 calls)
......Unaccounted: (0.921 %) :: 0.008 ms
.........----------------------------------
.........Profiling: solveConstraints (total running time: 0.022 ms) ---
.........0 -- solveGroup (45.45 %) :: 0.010 ms / frame (1 calls)
.........1 -- processIslands (18.18 %) :: 0.004 ms / frame (1 calls)
.........2 -- islandUnionFindAndQuickSort (9.09 %) :: 0.002 ms / frame (1 calls)
.........Unaccounted: (27.273 %) :: 0.006 ms
............----------------------------------
............Profiling: solveGroup (total running time: 0.010 ms) ---
............0 -- solveGroupCacheFriendlyIterations (20.00 %) :: 0.002 ms / frame (1 calls)
............1 -- solveGroupCacheFriendlySetup (40.00 %) :: 0.004 ms / frame (1 calls)
............Unaccounted: (40.000 %) :: 0.004 ms
.........----------------------------------
.........Profiling: performDiscreteCollisionDetection (total running time: 0.038 ms) ---
.........0 -- dispatchAllCollisionPairs (60.53 %) :: 0.023 ms / frame (1 calls)
.........1 -- calculateOverlappingPairs (7.89 %) :: 0.003 ms / frame (1 calls)
.........2 -- updateAabbs (21.05 %) :: 0.008 ms / frame (1 calls)
.........Unaccounted: (10.526 %) :: 0.004 ms

Treating each object as a static collision object to support instances will slow down the simulation by a factor of two (dynamic bvt broadphase, ~500 objects vs car):

Code:

Profiling: Root (total running time: 1.944 ms) ---
0 -- stepSimulation (99.85 %) :: 1.941 ms / frame (1 calls)
Unaccounted: (0.154 %) :: 0.003 ms
...----------------------------------
...Profiling: stepSimulation (total running time: 1.941 ms) ---
...0 -- synchronizeMotionStates (0.21 %) :: 0.004 ms / frame (1 calls)
...1 -- internalSingleStepSimulation (98.20 %) :: 1.906 ms / frame (1 calls)
...Unaccounted: (1.597 %) :: 0.031 ms
......----------------------------------
......Profiling: internalSingleStepSimulation (total running time: 1.906 ms) ---
......0 -- updateActivationState (0.05 %) :: 0.001 ms / frame (1 calls)
......1 -- updateActions (50.21 %) :: 0.957 ms / frame (1 calls)
......2 -- integrateTransforms (0.21 %) :: 0.004 ms / frame (1 calls)
......3 -- solveConstraints (1.57 %) :: 0.030 ms / frame (1 calls)
......4 -- calculateSimulationIslands (2.83 %) :: 0.054 ms / frame (1 calls)
......5 -- performDiscreteCollisionDetection (44.44 %) :: 0.847 ms / frame (1 calls)
......6 -- predictUnconstraintMotion (0.21 %) :: 0.004 ms / frame (1 calls)
......Unaccounted: (0.472 %) :: 0.009 ms
.........----------------------------------
.........Profiling: solveConstraints (total running time: 0.030 ms) ---
.........0 -- solveGroup (30.00 %) :: 0.009 ms / frame (1 calls)
.........1 -- processIslands (33.33 %) :: 0.010 ms / frame (1 calls)
.........2 -- islandUnionFindAndQuickSort (13.33 %) :: 0.004 ms / frame (1 calls)
.........Unaccounted: (23.333 %) :: 0.007 ms
............----------------------------------
............Profiling: solveGroup (total running time: 0.009 ms) ---
............0 -- solveGroupCacheFriendlyIterations (22.22 %) :: 0.002 ms / frame (1 calls)
............1 -- solveGroupCacheFriendlySetup (44.44 %) :: 0.004 ms / frame (1 calls)
............Unaccounted: (33.333 %) :: 0.003 ms
.........----------------------------------
.........Profiling: performDiscreteCollisionDetection (total running time: 0.847 ms) ---
.........0 -- dispatchAllCollisionPairs (9.56 %) :: 0.081 ms / frame (1 calls)
.........1 -- calculateOverlappingPairs (1.06 %) :: 0.009 ms / frame (1 calls)
.........2 -- updateAabbs (88.90 %) :: 0.753 ms / frame (1 calls)
.........Unaccounted: (0.472 %) :: 0.004 ms

I'd prefer the latter setup. It keeps the code simple, supports efficient object insertion and removal and frustum culling. Will see if there is a way to speed it up a bit.

[joevenzon]

If it's 1 ms versus 2 ms, and the latter method simplifies things, then I'm totally fine with it. 2 ms is still really fast.

[NaN]

The problem is that the time spent in the broadphase goes up with the number of static objects. The time is wasted in updateAabbs although there is only one object moving.

ring2007, release compile, 1 car:
single batched object 0.375ms / frame, this is spent essentially in car simulation
2400 objects 2.542 ms / frame

On the other side the docs say that the broadphase should be rather good in handling large numbers of moving objects.

[joevenzon]

How does it perform on lemans?

[NaN]

Sorry for not replying.

I've modified bullet to speedup ray queries for compound objects. Haven't used them before because they are freaking slow at ray tests. The speed now should be close to batched geometry we were using.

Should I wait till the patch is accepted by bullet guys or patch our version?

Edit:
debug build, ring2007, 2426 objects, 1 car
old(batch): 2.491 ms
current(objects): 12.607 ms
new(compound): 3.961 ms

[joevenzon]

I'm still curious about performance on lemans, because if I remember right it has something like 9000 objects.

[NaN]

lemans, 6412 collidable objects, 1 car

batch(old): 1.954 ms
objects(current): 27.871 ms, should be better theoretically, has dbvt for static objects
compound(new): 2.774 ms
compound(unpatched): 184.218 ms, O(rays*objects)

[joevenzon]

Sounds good. I say go ahead and patch our bullet and make the change.

[NaN]

Wow, that was fast. The patch has been accepted. I'll update bullet to the latest svn.

I wonder if I should leave a fallback(the code is there) for the FEDORA guys and anyone compiling against their system bullet? Something like a NOCOMPOUND compile flag? Do we want to support it?