how to do: collision Geometry multiple objects

[fLUnKnhaXYU]

hello me again , I download cool whole city model , BIG (i think) 200 objects , lotsa rooftops , sidewalks , steps , light pole , even the traffic lights could use a box , mail boxes , you want me to go through the whole list ... anyhow , I wish to create collision for lots of it (undetermined) using the shape editor .

as a model with seperate objects the collision-1 detail gets re-written with each successive obj.

as a single combinedinto 1 mesh obj (with 1 milliom verts) it still sitting there "creating collision geometry" when I wake up to see the majic .

its no big surprise I guess the model is a bit large 200 objects buildings , couple simple vehicles , 750,000 verts .

oh yea , Way To Create 200 Col-1 detail for the objects in the model . thank you very much .

so , you know what a brilliant coder I am , Im considering copying/pasting/editing the script output . 0ne object at a time , dont overthink it . TY

if you want to see the model :

[Duion]

Collision type = visible mesh

[fLUnKnhaXYU]

i tried . I about never got my computer un-stuck .

Edited March 2 by fLUnKnhaXYU
bad spell

[Duion]

Why would you ever use anything else than visible mesh on architecture? If it does not work, then make it work, like learn to use blender, import the models clean them up and export again so they work properly.

[fLUnKnhaXYU]

Im sorry Duion , when I  use visible mesh the vehicles always cause some collision-induced calculating difficulties that creates some severe bottleneck of constant  collisions calculations . where input like editor toggle or movement or console toggle , take a very long time to get processed . I dont know I think it is calculating many collisions but this doesn't happen when using collision mesh instead . Ive wanted to use the visible mesh , it is very desirable . I experience the bottleneck even colliiding the cheetah car into the default tree or the station model , those 3 being the demo models . is it me ? man you're freaking me out Sir Duion , Thank You and have a nice day Sir .

[Duion]

That is a bug in vehicle collisions that needs to be fixed not something with collision meshes. If you really want or need a collision mesh, open the model in blender, dublicate the whole thing, remove the materials and call it "col-1" and there you have your collision mesh, it is kind of a botch, but what you are doing is probably even more so a botch.

[fLUnKnhaXYU]

this is as you did instruct mighty lord . the vehicle as well performed fairly well yet , .. it would stall out as it encountered many small collidable  objects , there are many storm drains , litter and sideswipable objects along narrow alleys on the sides of bldgs on the sidewalks etc . of course the player on the other hand seemed to have no problem and this shape appeared to put little to no strain on the ol' tater .

[Duion]

There are several bugs in the engine that never got fixed and the vehicle collisions are one of them, my theory is that complicated collision shapes make the vehicle collisions glitch, I had it with trees for example, there is also this weird collision bug that if you walk towards a tree from the positive Y axis in the world you can run up the tree trunk, maybe those are related, but whatever fixing everything is too much work.

[fLUnKnhaXYU]

well bugs is pretty things I guess ... So , you are saying that it using the visible mesh is preferable to this col-1 mesh , even though , it seems to work a bit with the vehicle ? I find that perculiere . Im sure your logic would be a bit exciting Sir . and , So , I've had the pleasure of playing with this cool thing just a little and consider what you said . a good bit needs to be altered to even remotely be considered optimal for a torque level . In fact its a bit unsettling to consider the amount of work needed if going as far as arranging some interiors . at the same darn time , its intriguing to see what torque3d will comply with and accommodate . you know what Im saying or trying to say ? So , if I may , surely these "bugs" , as you say , have gone unfixed for quite sometime . It doesnt make sense to do so much work on a program with such a lingering collection of flaws and Im sure thats just my perspective . Im sure this is a hard read so Id better like stop now . ty x 2

[marauder2k9]

You are right to use simplified geometry, architecture should never be anything other than simple geometry, mostly boxes for buildings, do not use visible mesh especially on something as dense as this. The collisions work off of gjk which means if you use visible mesh, every vertex, ever edge and every face (triangle) is checked for collisions in that collision geometry, its also tested for penetration depth which you can surely understand will tank performance quite a bit. Almost all physics apis use this too but they split up a triangle mesh collision geomtry into multiple aabbs to narrow down the search. 

Use simple geomtry to get the best performance out of it if you are working with architecture place multiple colbox collision geometry around the ground floor to split things up a bit better and get better collision response but most certainly never use visible mesh for something like this.

We are currently working on completely replacing the physics end of things with a stock physics plugin to address the architectural side of things and put all the physics stuff in one place that makes it more comprehensible to work with. But if you split this mesh up it should work with the collision generator more easily. 

Edited March 3 by marauder2k9

[fLUnKnhaXYU]

This has been excellent .  the quite different perspectives is most interesting and to the same goal in mind essentially the same project . Im wondering how the collision quirkiness persists with the considerations effected upon the devil . with the velocity check more velocity , extra checky and STILL an object can fall through the floor , say a vehicle with too low spring force can prove . simply amazing to imagine that . youve done too much to help for this . please have a nice day . THX THX THX SO MUCH FOR THIS . new archi physics Hulk will smash you know . * i just remembered , that adventure kit stuff would be great in a scenario such as this * .

[fLUnKnhaXYU]

I waited for like 30 min for this model col-1 combo to load into the shape editor . the performance monitor thing showed activity like 70% memory 35% CPU what appeared to be normalish behavior where I think given enough time it would have loaded . I got a little bit P O 'd and just aborted the process I spend enough time waitin; for this clod to do STUUFF! ty U

Edited March 4 by fLUnKnhaXYU
i forgot to say have a good'n

[Duion]

Why would you ever use anything else than visible mesh for architecture, there are just a few exceptions like if you have a metal grid floor you walk on then you obviously do not model the grid, but like use a texture with alpha channel and treat it as a solid surface. I tried once modeling it out and it lagged when walking over it using visible mesh. The other point is it is just too much work to maintain a visible mesh and a collision mesh and even if you do you will face issues in gameplay like trying to shoot around a corner, but the collision mesh is bigger and your grenade bounces back on you hitting that invisible wall which sucks hard.

If you want to make a pure racing game it may be worth a consideration to get around the collision bugs creating simple collision meshes for everything, but in other scenarios it is not worth the effort, the better way is fixing the physics. I wonder how good the bullet physics implementation is now, I remember it being buggy, Torque default physics are very primitive. I remember even registering at NVIDIA to use their proprietary physx but, it is not a good way to go, bullet physics is the only savior we have so you should try implementing that and it may fix and improve many collision based stuff.

[fLUnKnhaXYU]

On 3/3/2025 at 4:02 AM, marauder2k9 said:

The collisions work off of gjk which means if you use visible mesh, every vertex, ever edge and every face (triangle) is checked for collisions in that collision geometry,

you know ? , I read that about three or four times before it finally penetrated my brick and I understood exactly what I think you had implied . Knowing that what in the world is the SirDooey position regarding the visible mesh ? Hes adamant what does it mean ? Sir ? may I please beg of you to release . but I want to take a shot at it and guess that you are saying that the benefit should be trivial enough in relation to the benefit of the tightly wrapped collision matrix of this bustling environment .

and , are you suggesting that the reason that when I try to casually push another wheeled vehicle out of the path of mine and sometimes I manage to  push into and subsequentially completely through the other vehicle , is my fault , and can be corrected through better collision values in the datablock ? or , or even a better approach to modelling the collision shape ? .

another thing , why should bullet be preferred over jolt ? Lord Duion .

I know you've spent enough time on this topic , and as i remeber the reading , native physics is pretty darn good . ty ty ty .

[Azaezel]

2 hours ago, fLUnKnhaXYU said:

and , are you suggesting that the reason that when I try to casually push another wheeled vehicle out of the path of mine and sometimes I manage to  push into and subsequentially completely through the other vehicle , is my fault , and can be corrected through better collision values in the datablock ? or , or even a better approach to modelling the collision shape ? .

Ok, so a few things to clear up. First, you'll want your vehicle meshes to be a convex. This is because those resolve much, much more quickly than checking each and every face and the direction it is facing. (and to be very, *very* clear here: It does not matter what library or engine you use. That will always be the case.). After that, the relevant entries for distance would be https://github.com/Torque3DResources/Cheetah/blob/main/datablocks/vehicles/cheetahCar.tscript#L331-L333
(collisionTol and contactTol. I'd advise not going over an 8 for the integration value)

 

I trust that also makes it clear just what a poor idea making everything a visible mesh is in practice.

 

To avoid sending mixed signals, yes https://github.com/Torque3DResources/testMaps/blob/main/levels/Warren.mis#L66-L67 is using visiblemesh. Because the purpose of testmaps is to actively strain subsystems.

 
It should also be underscored that the physics plugins operate on a layer informed by stock physics. Which means the stock physics runs a simulation and tells the plugins about the world state, then the plugin specific classes (of which there are very few indeed) react to the plugin's side by side simulation. at no point does one replace the other. (There are plans in the works to make that less... *that*)

[fLUnKnhaXYU]

well , ok , for now , but , oh yea , is warrent supposed to fire it up man in 4.03 , I mean with its sub-mis and downforce injected cheetah (cool) . I just stuck thos folders testmap(w/warrent) and the new cheetah DB in a clean 4.03 (the Binary) and warrent mission crashes . So ,...thanks anyway guys you're great  and at least you tried to help but nope , no working  . well ok thx anyways . U

BTW the warrent shape , signal lights and terrain will load into other levels but the Warrent mission/level will not . thx

[Azaezel]

The crash is likely too many probes. One of the things we had to up for 4.1, and are in the process of seeing if we can push beyond the (at time of writing) 340 probe hard limit for head.

The subscenes writeup can be found 

But the general cliffsnotes would be: Think of a trigger that loads and unloads stuff serverside so things don't even exist to cause load unless someone's in the area.

The signal lights are actually tied into the new racing game mode https://github.com/Torque3DResources/racing 

Which ties into the new spawn protocol https://github.com/TorqueGameEngines/Torque3D/pull/1342 to make it simpler for folks to have gameplay from one module, and spawning controllables from another. 

[fLUnKnhaXYU]

took the entire simset of all those probes out -

the level loaded - wouldn't change from load screen to the playgui -

hit f11 to start world editor - editor starts - the scene is editable - world editor will not close . in fact once I attempt to close it it sorta semi-crashed and the file and those options were not available again . no player / vehicle / signal lights the sub mis stuff i guess . probably my slight oversight or or some slight mis-calculation of proper stuff alignment or the like . which means I know Im probably screwing it all up but I just sayin'  and by golly while Im sayin Id just like to say that that you guys are just the greatest and thanks a lot and have a great ol day . btw besides the file and things being unavailable , the editor seems to work pretty fine and the scene plays nicely considering its rather rotund nature . TY OK then ? 

 

[Duion]

@Azaezel

Whats a convex shape? Does this mean it is illegal to build a half pipe in Torque?

 

I hardly find a reason to ever not use the visible mesh for collision, sure for organic stuff like plants I delete the tiny branches for the collision mesh and use a polygon reduced version for the others eventually, but I don't think it makes much difference performance wise. In a shooter game where you interact with the world closeley you get all kinds of weird effects if your collision does not exactly match the world geometry. I'm pretty sure it is common in most video games to have collision be what you also see at least that is my experience.

[JeffR]

A convex shape is a specific type of geometry where there are no angles more than 180 degrees, so everything is angled 'inward'. https://en.wikipedia.org/wiki/Convex_polygon

The ramifications of this is that the math is very, very, very simple, and thus very fast. Given that you need to do a lot of collision calculations, the simpler the better.

While visual mesh/polysoup coliisions are also notionally fast, what you're ultimately doing is a lot of shape or ray/triangle intersection tests. This is also relatively fast, but you do it on EVERY possible triangle.

The more triangles the mesh has, the more tris you have to test as part of the potential collision set. Whereas with convex shapes, you can have one shape to test to cover an entire volume versus each triangle that makes up the visual mesh of the same space.

As the adage goes when it comes to optimization:  The fastest calculation is the one you don't have to make at all.

While individually each triangle is fast to test on visible mesh collisions, you have to ask yourself the question: which is naturally going to be faster? 

1000+ checks, or one check?

The answer is pretty simple.

While there are certainly times and places where visual mesh collision makes sense, it's ultimately a game specific call and you MUST go into using it understanding it will have an overhead performance cost compared to collision meshes because of the above bit.

If that's an acceptable tradeoff for the sake of accuracy of collisions? Then hey, fair enough. But it isn't something you can just handwave away because 1000 checks will *always* be more expensive than 1 check.

As long as that's understood, you can make the design call as needbe for if a single collision mesh vs visible meshes is a worthwhile accuracy-to-cost tradeoff.

For very complex scenes, you'll often find needing to break the meshes up for culling and the like anyways, which gives you more options for where and when to apply what kind of collision geometry.

But remember, as a general rule, you always want to do collision meshes(convex shapes) over visible meshes unless there's no way to handle it with collision meshes.

At which point you would want to optimize down the number of triangles as much as possible to minimize performance overhead of all those triangle tests you'll end up doing.

All part of the process of optimizing things, in the end, but it can have a *big* impact on performance, more than you'd think.

[fLUnKnhaXYU]

Oh , yea ,

i put my other modules i had in the data folder (gameplay , fpsplayer , etc) and the world editor is fine again . this news is just great and eases the concern that I had had  concerning cfreations of hulls (if deemed necessary , of course). I think I got a goood indication of whats gonna get done now and exactly how to make hulls . SUPER Thank you all ! and have a great day .