Collision primitives treated as mesh.
by The Guv · in Torque 3D Professional · 02/20/2012 (2:27 pm) · 5 replies
T3D 1.2
In the art primer it states that the most efficient collision is set up using primitives. ie. spheres, boxes, capsules and named correctly they'll be used as math primitives giving large gains. In all tests I've completed over the last few days I'm not sure this is correct. Yes, if you use a sphere primitive as a collision volume, you will collide with it, but if you increase the mesh density of the primitive the engine slows down when you collide with it suggesting that it's not a true maths primitive.
To recreate:
export an object with a sphere primitive as collision, mark it ColSphere etc. to tell the engine it's a primitive, give it 8 segments or something, runs fine.
export the above with a few hundred segments, watch the engine struggle.
If true primitives were being used the engine should only care about the position and radius of the sphere, which is why primitives are so great for collision as far as I'm aware.
In the art primer it states that the most efficient collision is set up using primitives. ie. spheres, boxes, capsules and named correctly they'll be used as math primitives giving large gains. In all tests I've completed over the last few days I'm not sure this is correct. Yes, if you use a sphere primitive as a collision volume, you will collide with it, but if you increase the mesh density of the primitive the engine slows down when you collide with it suggesting that it's not a true maths primitive.
To recreate:
export an object with a sphere primitive as collision, mark it ColSphere etc. to tell the engine it's a primitive, give it 8 segments or something, runs fine.
export the above with a few hundred segments, watch the engine struggle.
If true primitives were being used the engine should only care about the position and radius of the sphere, which is why primitives are so great for collision as far as I'm aware.
#2
02/20/2012 (6:15 pm)
Doesn't matter where the mesh is created, but the collision performance benefit is only gained when using PhysX. Stock T3D collision detection does not have support for primitives so will treat all collision geometry as triangular meshes.
#3
This engine has so much potential, but it's so wonki-tudified-o-rama.
@GG, PAY CHRIS ALOT to fix everything!!!!!! thx!
02/20/2012 (6:40 pm)
1. that collision creation in the shape editor was a waste of a dev's time and 2. the col-generator-tool-panel in the shape ed. doesn't reset properly/aka:broken..it's a 1 and done until reset, thing.This engine has so much potential, but it's so wonki-tudified-o-rama.
@GG, PAY CHRIS ALOT to fix everything!!!!!! thx!
#4
I agree, GGs, PLEASE get this either fixed, implemented, or the docs changed to state all collision is meshes only *ouch* That's a BIG blow from my point of view if that's true...
Maybe getting all collision calculations running on a separate core or something will make up for it ....LOL !....
02/22/2012 (11:41 am)
Yes, I've been running more tests, and no matter how I try I cannot get a primitive to be used as a true math primitive...I've looked into the shape editor oojimeflipy thingy too with no positive results...Crazy thing is we went through every asset of my last Torque title to change all collision to primitives from meshes at a cost of a couple of weeks hard graft and bleeding eyeballs for this exact reason !!, it seems that would have given us no gain whatsoever...How mad is that? ...I feel cheated and dirty... 8)I agree, GGs, PLEASE get this either fixed, implemented, or the docs changed to state all collision is meshes only *ouch* That's a BIG blow from my point of view if that's true...
Maybe getting all collision calculations running on a separate core or something will make up for it ....LOL !....
#5
02/22/2012 (1:20 pm)
you best save your energy for development Guv. They won't care no matter how wrong they are. 
Associate Steve Acaster
[YorkshireRifles.com]