Fairly Decent Results With Bullet Physics


chris_c

Member
Joined
Jun 25, 2010
Messages
393
Age
56
http://www.youtube.com/watch?v=7RTypuLsgRA

I could probably get a bit more speed by using one tri-strip rather then 6 per cube!

by rough way of comparison the Pandora completely trashes my multi threaded 1ghz eeepc! (because of craptastic intel gfx chip), and it also appears better than a wii where my experiments with bullet were rather dire!

While there have been a number of great ports, I think that when we start to see games etc written specifically for the Pandora we're gonna be in for a right treat!

What a great piece of kit!
 
chris_c said:
http://www.youtube.com/watch?v=7RTypuLsgRA

I could probably get a bit more speed by using one tri-strip rather then 6 per cube!
Try with a tri-list. 24 verts, 12 tris - should exhibit excellent v-cache locality, and will save you all the degeneration from a single tri-strip.
 
Last edited by a moderator:
darkblu said:
chris_c said:
http://www.youtube.com/watch?v=7RTypuLsgRA

I could probably get a bit more speed by using one tri-strip rather then 6 per cube!
Try with a tri-list. 24 verts, 12 tris - should exhibit excellent v-cache locality, and will save you all the degeneration from a single tri-strip.
I've come to the same conclusion, when trying to manually work out what the texture coord's should be for the tri-strip (not as straight forward as you'd think!) Out of interest what degeneration are you talking about?
 
Last edited by a moderator:
Theres a lot more GL talk of late, and chris-r is rocking along. My main project right now I'm building in opengl proper, just to avoid testing annoyances and gles problems (I don't know much gles), but I'll be switchign it back to gles in awhile; but its great fun to watch the experimentation going on, so thanks for that :)

jeff
 
@darkblu I double checked the tri-strip I was using didn't need degenerate verts and theres at least one other way of doing a tri-strip without needing degenerate verts!

however working out the texture coordinates was a ball ache so I decided to be lazy and resort to just triangles (for which you need 36 and not 24 verts! ;) )

with even an inefficient triangle soup for a cube being so small, worrying about cache locality is kinda redundant - but a tri strip is by far the most efficient needing only 14 verts...
 
darkblu said:
chris_c said:
http://www.youtube.com/watch?v=7RTypuLsgRA

I could probably get a bit more speed by using one tri-strip rather then 6 per cube!
Try with a tri-list. 24 verts, 12 tris - should exhibit excellent v-cache locality, and will save you all the degeneration from a single tri-strip.

SGX natively is using tri-strips... in fact,as far as I know, everything you submit is converted by the driver into tri-strips.

Of course, you are right, some models using tri-strips will result in a lot of batches or tons of degenerated tris... personally, I use tri-lists sorted into a tri-strip like order - seems to be a happy medium.


BTW. I wouldn't expect SGX to fold easily displaying a relatively small number of cubes ... I am actually surprised the CPU side of the test ( the bullet library itself) is running so smoothly.
 
Last edited by a moderator:
BTW. I wouldn't expect SGX to fold easily displaying a relatively small number of cubes ... I am actually surprised the CPU side of the test ( the bullet library itself) is running so smoothly.

I would expect a lot more from the sgx too!, even driven via python you can throw out a blistering number of tri's :D, but the reason the physics is running so smoothly is because of bullet itself, take a look at the source! its rather impressive, all the data structures are carefully aligned and a great deal of trouble has been taken with optimisation, on top of that the arm7a is a step up from previous arm processors which when combined with sgx graphics is what makes it such an impressive platform, sure your desktop easily out performs it, but then the pandora is using a tiny fraction of the power even compared with a laptop...

Its worth saying again there should be some amazing games for this platform once enough people start writing *specifically* for it!
 
chris_c said:
@darkblu I double checked the tri-strip I was using didn't need degenerate verts and theres at least one other way of doing a tri-strip without needing degenerate verts!

however working out the texture coordinates was a ball ache so I decided to be lazy and resort to just triangles (for which you need 36 and not 24 verts! ;) )

with even an inefficient triangle soup for a cube being so small, worrying about cache locality is kinda redundant - but a tri strip is by far the most efficient needing only 14 verts...
A proper cube should be 36 indices, 24 vertices - two of the vetices from each face should be reused once. If this is your cube's face in terms of vertices:

Code:
A    B

C    D

your per-face indices go like this: (0, 2, 1), (1, 2, 3), assuming CCW winding. Note that a MRU vertex cache of 2 entries is sufficient to ensure the processing of each vertex just once. Coincidentally, a MRU 2-entry cache is what is needed to do tri-strips. So you can take such a cache facility for granted.


@warmi

Are you sure about the internal stripification? Can you pass on some links?
 
Last edited by a moderator:
darkblu said:
A proper cube should be 36 indices, 24 vertices - two of the vetices from each face should be reused once.
being as an array has no indices then no verts are reused, I've yet to prove it in the real world but I suspect that draw arrays is faster than draw elements....

Are you sure about the internal stripification? Can you pass on some links?
Yeah I love to see a citation for that too...
 
Last edited by a moderator:
I'd looked at Bullet a few months ago but decided a port wasn't something I could spend a lot of time on .. are you planning on releasing your Bullet port so other developers might be able to use it to build games?
 
chris_c said:
being as an array has no indices then no verts are reused, I've yet to prove it in the real world but I suspect that draw arrays is faster than draw elements.....
In the cubes case, that would indicate that the price for the GPU accessing the index buffer is higher than the 33% greater vertex load you'd have to pass through the shader when not using indexed form. I sincerely doubt that.
 
Last edited by a moderator:
@torpor what porting? just include the unmodified source into your project...
 
Wait, wait wait wait. Woah. You saying that bullet physics works that well completely unmodified?
 
of course it does! have you *seen* the length they have gone to to optimise it?
It a very good example of portable code that is well written and optimised
 
Back
Top