Using multiple PRIMITIVE collision shapes

#1 I think you're talking about the difference of what you want; rigid body physics via shape-math and what you're using; the collision-mesh system.

2 different things in Torque, but treated as the same by other engines.

#2 In my experience, Torque has always based the collision mesh as faces, and so it would matter if you use a more complex shape. This is why I am currently trying to figure out a very quick way of making collision meshes because I hate making them. Currently I will just copy the model and delete the texture to it and name it Collision_1 before exporting it for quick tests of the building tree, or rock. I have noticed it will run a tad slower when doing this but of course this is only temporary to run tests before creating a proper collision mesh.
Also sometimes characters will get stuck on certain model collision meshes because Torque does not like certain angles and so the collision mesh will need to be remade.

#3 From the documentation at Artist Guide > Primer > Torque Art Primer, about a third of the way down:

Quote:
The name of the collision mesh for a given detail level can give a hint to the Torque engine about what type of geometry to use. This allows for significant performance improvement in the case of the box, sphere and capsule primitives, or for non-convex geometry to be used for collision detection. Any mesh that does not match one of the names below will be interpreted as a generic convex hull (i.e. the same as ColConvex). In this case, the vertices of the mesh are used to construct a convex hull when the shape is loaded.

ColBox
This will be converted to a box primitive (that bounds the mesh) when the shape is loaded.
ColSphere
This will be converted to a true sphere primitive (that bounds the mesh) when the shape is loaded.
ColCapsule
This will be converted to a true capsule primitive (that bounds the mesh) when the shape is loaded.
ColConvex
A generic convex mesh, converted to a true convex hull when the shape is loaded.
ColMesh
A generic triangular mesh that does not need to be convex. This type of geometry is the most expensive for collision testing, and should be kept as simple (fewest triangles) as possible.

So, it looks to me like you're naming them "colsphere" when they might want to be named "ColSphere" - Though, like TorqueScript, they may be case-insensitive. Additionally, the documentation uses an underscore for the numbering, so the dash might not work - e.g. ColSphere_1 instead of ColSphere-1.

Hope that is helpful!

#4 Richard may have nailed the issue with the bit at the end.

"Additionally, the documentation uses an underscore for the numbering, so the dash might not work - e.g. ColSphere_1 instead of ColSphere-1."

I noticed that using "-" in any name space can create issues with modeling period. Use "_" instead and you will notice that many of the issues with modeling will go away.

#5 Okay, cool...Cheers guys. I'll look into this over the weekend....

Thanks so much yet again for the feedback, it's really appreciated as always, I'll look into the naming tonight and see if that does it......I'm determined to nail the art pipeline so that I'm working in as efficient a manner as possible, which is why I'm looking into collision primitives, texture sharing, instancing etc. etc. at this stage rather than having to redo stuff in an optimising pass this time next year or something...I'll let you know how I get on....It's great to see that the forums are still as helpful as always.

#6 Okay, no different....If I export the right model the game runs okay, If we export the left it runs at about 1 frame every 5 seconds when we get within about 10 meters of the rock. Now you may say just use the right one, but all we're illustrating here is that it's using the verts of these sphere primitives for the objects collision not the settings of the primitive. In theory I guess my sphere can have 1,000,000 verts, the engine shouldn't care, it should just say oh it's a sphere, where's it located, what's it's radius...and in my experience, the ONLY real way of having great, optimised collision is if you set just about everything up using primitives.


I guess it's just us not naming this correctly somehow, I've followed what you guys have suggested as you can see...Any more ideas?

Thanks again....

#7

+-base01
  +-start01
    +-Torso                   Object Torso with details: 256 64 32
    +-Head                    Object Head with details: 256 64 32
    +-Armor                   Object Armor with details: 256 64
    +-ColBox                  Object ColBox with details: -1

Looks like collision detail is child of start01. So, perhaps ColSphere_1 and ColSphere_2 should be children of start01.

I'm really just poking around here - I haven't tried any of this. It just occurred to me that I could open Jill from the Bravetree GirlPack (yeah, I still have it somewhere....) and check.

#8 The Guv, that concept ONLY works with PhysX singleactors/multiActors(possibly with the Bullet stuff as well but you would have to declare it as a Physicshape to try the bullet physics type).

I think PhysX in T3D was stripped down in 1.2 to only have a multiactor and no longer have the single, but I could be wrong. ..check the source on that. :P

Also, you have to keep the shapetype as a primitive mesh, it can NOT be an editable poly/nurb/etc if you expect the math-shape to be used. The PhysX pipe in T3D was only made for Max so I can not say if your cad tool would suffice as I have not fully read this thread..but rather; skimmed it.

Anyhow, THAT is what you're looking for. ..anything else uses the mesh.


P.S. if this is any use to you; My Physit! tool for PhysX stuff in T3D, will support max 2010/2011/2012, to be released in early march. You can make complex physX T3D Data via automated tasks with it. I thought you may want to know that since you're seeking Physics stuff in T3D and you're a max user. ;) email me if you have questions.

#9 Hey All. Just tried attaching the ColSpheres to the start node, same issue I'm afraid.

@G.A.S Thanks for the info. Yes, the shapes are primitives, unscaled, pivots at zero. One thing I am desperate to crack is no meshes as collision, all primitives are seen as primitives math shapes for all collision...

So, just to try and get my head around this...If I try and export traditional static objects etc. and use primitives as collision, named ColSphere we still think that the primitives will be used as though they are editable meshes?

BUT, if I set up all of the objects as though they are PhysX Objects, just with one state so they are only used to collide with, we think that these primitives will then be seen as mash-shapes?

Does that sound like I've got the right end of the stick?

Also, as for Physit, sounds cool! I've not got max myself (stuck with milkshape/blender for now)but I'm helping my brother in law who's doing a degree in animation, so it'll be through his studenty max version, I guess it'll still suffice though?

As for automating physx setup, that sounds like a great idea, One thing he's looking into is a big rockfall with lots of objects which is one reason why he's desperate to have the collision really optimised...

I guess my next step is to add this model through a physX script and see if it sees the primitives correctly?

Once again, thanks for any feedback chaps!

#10 "Does that sound like I've got the right end of the stick?"
- Yes, so long as the collision volumes you create are kept as "primitive meshes" in max, they will be used as "math primitives" by T3D when a PhysX Actor setup is used(possibly bullet does this too). sphere,capsule,box, and I think cone may have been on that list too but I can't remember tbh. PhysX shapes in T3D can also use 'custom mesh collision' volumes as well as 'grouped primitive mesh' setups.
So..the physX system in T3D will work as you need..in fact, the PhysXActors(physX) & possibly the PhysicsShapes(bullet), work for that scenario.

Rocks falling;
make many rocks, probably 10, in a physx file setup..and then duplicate it as needed regarding performance restraints for ideal target usage. I wouldn't go and make a physX setup with 100 rocks as it would be hard to hit a precise target ratio of performance vs. appearance. PhysX objects never get culled iirc.


As long as the Sutdent version of max accepts plugins,(which it should), you would be good to go. Physit! for max 2010,2011,2012 will be available in early march. Check out the videos when you have time..it can save you days of work..literally. [ not trying to sales pitch here, it is simply the Sh!t whether I made it or not. ;) ]

Good luck.

#11 Thanks, right, so it sounds like really good news, and exactly what we wanted to hear with PhysX objects. I'm going to get this all sorted out, and I'll get him a copy of your 'My Physit' when it's ready too, sounds like a life saver!

One very last thing then. So, the rest of the objects in T3D missions, things that you need to collide with but don't need to break apart etc. they're literally indestructible, ie. static objects, walls, buildings etc....Do you know of any way these can be set up with primitives collision working correctly? Is it crazy talk to think these can be static PhysX objects? Again, talking from an optimising point of view, I'd love to have 100's of objects in shot at any one time because I've been really careful with the setup rather than a couple of dozen because I wasn't as savvy as I could have been....

I would have thought this would be one of the fundamental basic first steps in the art side of the tutorials really...ie. To create an inexpensive set of assets in your game, ideally they should share textures wherever possible, LOD your stuff, make sure models have primitives for collision wherever possible, if they're under 300 verts when in engine they'll automatically instance, don't use multi-sub materials as each I.D. is like rendering the mesh again, dds textures will improve loading times and be smaller on the graphics card than other formats (but aren't ideal for normal maps as the 3D info is not great when compressed), etc. etc. It's taken me a couple of weeks of trial and error and spamming the forums to get this info. so far...

When I'm done, and I have the most engine efficient art pipeline completely sorted as far as I can make out, I'll write a blog about it I think...It's been more difficult than I think it should have been, I'm sure it can help someone out in the future...

#12 ..it's nice to see someone else really push the thought patterns needed to sort through the ideal situation to squeeze all 'juices from each possible frame' within regard to our levels of knowledge. Of course there are many of us here that do this, but it's always great to see someone new & eager to hit that proverbial sweet spot! ..welcome!

Here is where life stands in 2011 for engines that are accessible to people with less than BIG BUCKS HERE..static geometry uses a collision mimic of the visible mesh or low poly geo, the dynamic objects receive the math-primitive/rigid-body specific collision.
Is it silly to think that all levels can be built from math-shape collisions ? ..no. BUT; within regards to how T3D handles the objects and without altering source code, your best bet is to optimize static collision meshes and use the math-primitives on dynamic objects. If you or anyone can think of a better solution with Vanilla T3D, I welcome you to the table to talk..I'll even get some coffee for you. ;)

I'd say you're on the right path and only you can judge what is acceptable for performance for your scene setups vs. marketability/personal-use. I'm sure you'll love Physit!, I'm excited to have it for 2010 thru 2012..VERY EXCITED!

ttyl

#13 Okay, cool...Understood. To be honest, as long as I know that having really low poly meshes is the best we can expect for static objects collision then that's fine, as long as I know I'm creating assets in the very best way possible then I'm happy...I'm looking at all of this from an art perspective by the way. I have no programming background, I've worked for over a decade on AAA stuff but as an artist which is why I'm so obsessed with trying to get the best pipeline myself. Usually I can turn around to a technical artist or grab a small document that will tell me, as an artist, exactly how I need to set things up and why to keep rendering overhead and collision detection to an absolute minimum. I know this info. is scattered accross the forums, and withing the documents too, but realistically a one pager for anyone else in the future would really help I think....I'd also suggest that being able to set your static models up using primitives as collision, working with the gains you get from primitives would be a pretty exciting thing to see T3D take up in a future release...Surely this would help anyone making a game that has 3D assets in there? I've no idea what that would involve though...AS far as I can understand, in the art primer it IS saying this is the case..I'm not convinced it's working though, they're just being seen as meshes I think...Maybe it's a bug? Or I've got document blindness from going around in circles for a few days 8)

Anyway, huge thanks, I'll keep digging and see how much we can squeeze out of it...Just as a sidenote though, the engine is incredible for the price, we're getting some really nice results so far...

#14 send me a link to the art primer you speak of. thx

\\edit: nevermind, I see the link in Richard's post above. bbl with more chat

#15 ok, checked things out..

it's mesh/vertex prims, physx has math/calc prims.
T3D's shape editor was the key to this but it breaks so often I had to restart 5 times to test a single mesh with these types of collisions they claim to be "true primitive" without claiming mesh/vertex-volume or math/true rigid body. No one's fault I suppose..I think they rush the docs..being more scientific would be awesome of them.

- You'll find that many things are broken and ill-documented, but if you don't mind banging your head against the wall for a few years(cue list of people who would heavily agree), you'll be one of the few dozen that can claim they tackled Torque to a great level of understanding.

btw, I don't think it's your fault for reading those docs as you did..nor do I blame GG, what I see here is Autodesk's 3dsMax uses math to create primitives while using meshes to visualize them,
- hence; these 2 concepts converge and become one, to most.

Anyhow;
- If Torque3d was cross platform like Shiva3D, I'd still be using it.

P.S.
AAA art eh ? me too but not for 10 years?! Send me over an email and I'll share my IM name with you as I don't mind helping you guys out..aka:those who are already "on the level". ;)
"eb 78 98 @ g mail . com"