Malfunctioning collisions between vehicles and map elements with collision mesh

[ghost]

When I crash into a sign with a collision mesh using a vehicle with a collision mesh, the vehicle somehow wraps part of the body around the sign in a way that you cannot back up to get away. Just noticed, kind of unrealistic at times.

[ohlidalp]

@gigapouch : That's a typical RoR behavior - colliding objects get stuck in each other. This is something that needs to be improved in the physics engine, but it won't be easy.

[DirtGamer301]

The_Wolf once on the main forums told me this is a problem of too many vertices on a too small room, and as a sign has many vertices on a small room this should be the problem I think.

[ohlidalp]

@DirtGamer301 : The problem is general - collision with meshes (3d models) doesn't work very well, the surfaces penetrate each other and get stuck or fall through each other. I've seen multiple complaints on this, including a video of a tricycle entering a bus, falling through the floor and being ran over by the bus. I noticed this behavior myself and yes, it's pretty annoying. I'll craft some solution in time, but it won't be a quick fix.

[ohlidalp]

@TechGiga @DirtGamer301 Can either of you write down a testing scenario ? I mean: what vehicle (link!), which map (link!) and which sign to drive into (preferably with screenshot) Thanks.

[DarthCainRor]

It's pretty bad on Penguinville, with all the light poles, but any collision mesh, that has it's faces too close together will do it. When you drive too close to them, or crash into them, the nodes of the vehicle gets stuck inside of the object. http://www.rigsofrods.com/repository/view/2362. Any vehicle should work.

[DirtGamer301]

About vehicles, try it with the Gavril MV4 or simiar ones: http://www.rigsofrods.com/threads/84411-Gavril-MV4 A vehicle like Adolfo and mine Fiat 127 will just drive through them.

[DarthCainRor]

@above but if you get your wheels close on any vehicle it will eat the wheels too

[ohlidalp]

@DarthCainRor whar exactly do you mean by "faces too close together"? Polygons are always close to each other. Yo mean "too many polygons on small area" or "long, narrow polygons"?

[DirtGamer301]

@only-a-ptr Have a circle with 10 polygons and extrude it to make a cylinder. It's now got any size. Make the cylinder always 2 meters high. Scale it to have a radius of 5 centimeters and put it ingame with the collision mesh and visible mesh being the exact same. Crash into it a few times, you'll see That your car will get grabbed. Now scale the cylinder to have a radius of 1 meter, put it ingame with the visible mesh being the collision mesh again and try to crash it, your car won't get grabbed.

I don't exactly know what you mean with "long, narrow polygons", as polygons are only points without any size. Connected with other polygons they'll make a face which you can see (not in real life, as there's no thickness). A polygon itself doesn't have any shape, so there can't be long or narrow polygons.

[mikadou]

Polygons are not points. A polygon is basically the same as a face. It is made of several points which are connected by edges. The enclosed area is the face.

[DirtGamer301]

@mikadou Oh, I thought a polygon is like a vert in Blender? Sorry then, I was pretty sure about this.

[mikadou]

@DirtGamer301 Nevermind, I think it became still pretty clear what you were describing. Also I did not intend to sound harsh, I was just quickly writing from my mobile.

[ohlidalp]

I strongly suspect the problem here is using OGRE meshes for collision. OGRE meshes are designed for hardware rendering and they may easily have duplicate vertices and disjoint edges. Please read: http://www.rigsofrods.com/threads/120868-3D-modelling-Beware-of-automatic-vertex-splitting

[fidoj]

when you make a vehicle and submesh it the nodes (vertices) are joined together, roreditor (the program i still use today (injunction with np++). the error comes from physics step in node precision. lifter tried to fix this by adding extra rules to submesh http://www.rigsofrods.com/wiki/pages/Truck_Description_File#Submesh also tdev tried to fix this by haxoring in a way to prevent the contactor getting close enough to "slip" through and into the object. by adding an air layer that is configurable (i cant find the item to link atm). but the easiest way to prevent this is remove duplicate vertices in blender, do this on the contactable mesh and dont submesh it. even with all this nodes will still stick into a object due to physics step's resulting to node precision's that lock a node inside an object. ror isnt the only game that faces these problems ksp does as well https://www.youtube.com/watch?v=i0I-wFTMBCk

[ohlidalp]

@fidoj Thanks a lot for the info.

Precision is a problem here indeed.

I investigated this in the code. Collision meshes on map objects are loaded as OGRE's .mesh files, but then converted into a set of individual collision triangles. Thus, "remove doubles" in Blender should have no effect unless the user manually moved the duplicated verts apart.

I might have missed something, but it seems to me vehicle's collcab triangles are not taken into account when doing map-collisions. I need to take another look. There's a lot of commented-out code and never-reached code (deadcode). I'll also check whether the lifter's options have any effect at all.

[fidoj]

i can ask lifter if he attempted to do anything to solve the issue, and no the submesh has no effect on the collision with an item, its only use full when contacting a contactor, ive noticed with some mesh's you can slip nodes in between faces (happens when crawling over poorly made rocks), but its not the case with all, i have manually edited the contact mesh and removed double verts and the problem has gone away, what i suspect with beam is they have enabled submesh contact with other submesh to get a higher precision. i know a lot of people have tried different approaches to fix issues like these, and just comment with "game engine limitation" i dont think ogre is so "closed" that there is no possible solution, just never an easy road. but if you wish i can message lifter and ask if he tried anything?

[ohlidalp]

if you wish i can message lifter and ask if he tried anything?

Please do.

[L-Tec]

Hi,

this is a known problem. Things get stuck in structures because a node with collision abilities pierce thru an colliding surface when hitting it. its a simple problem of simulations moving in cycles, it may always happen, that a collision attempts "too late". If the structure is small multilayered like a vertical tube, the node gets trapped inside. This is based on the way how nodes are stopped by surfaces while colliding, just looked into the code.

There was a simple attempt to solve this, but i never coded it though....

So here is the (maybe working solution):

Instead of implementing a huge counter force to the node colliding ( this is 6 year old knowledge, might have changed meanwhile), which may in some attempts resolve in trapped nodes because they punched thru the surface, collision on surfaces has to be one way only. To provide accurate collision and solving the trapped node issue, the colliding face has to be generated with a "normal" defined like a mesh triangle by the vertices order, which defines the direction of the collision. Just think of it like the visibility normals of meshes. If the nodes moving vector is opposite of the normal ( vector and normal face each other) collision is applied normally. if the nodes moving vector is in the same direction then the normal, the node can move out free. With the normal, you can even provide a position to place the node correctly in front of the colliding mesh after collision has appeared, cause you know on which side of the mesh it has to be then.

Use the anglebetween vectors function, if the result is maller then 90 a collision has to appear, if its bigger let the node move free. Should work.

For real collision you have to calculate the nodes impact point, reset the nodes position and let things happen. This works, i used it here in a very simple form for wheel nodes, the code just resets wheelnodes with negative height ( in relation to the flat surface ) back on the surface instead of trying to push them out of the ground with extreme force (not sure if i ever uploaded that one to repo though):

https://www.bing.com/videos/search?q=ror+wheel+collision+youtube&view=detail&mid=66A9270BA08D02FD7A3766A9270BA08D02FD7A37&FORM=VIRE1

just look at the wheels, you can see the difference quite easy. With the "original" collision the wheels tend to sink into the ground surface massively, with the "testcode" they roll on the surface.

It was a very simple and dirty coded attempt, it worked not perfect but at least quite well. And these colliding nodes were moving extrem fast :D

Better would be a precalculation of an upcomming collision in the next cycle and calculate the nodes collision position in advanced. Tried that too with the wheels, result where a supersmooth ride, never loaded it up into the repo though. That should be the perfect solution then. Instead of applying forces reset nodes position, the beams do the forces themselves then. :)

So thats it guys, have fun coding. Greetings to all peeps that miss me and also to those that do not...lol.

Lifter

[ohlidalp]

@L-Tec Hi Lifter, thanks for stopping by.

Regarding the one-way collision faces: I actually thought of this, too. Currently, map-object collision triangles are generated by traversing an OGRE .mesh and generating triangles incl. worldspace->trispace conversion matrix. I'm not sure whether the matrix respects the .mesh face normal at the moment, but that can be fixed.

Anyway, me and Ulteq both think the problem lies in nodes[i].collTestTimer>0.005 condition which limits collision test to happen 1x in 10 physics frames. According to Ulteq's tests, lowering the timeout has low additional overhead and improves accuracy signifficantly.

[ulteq]

@L-Tec Try this, you will like it: https://github.com/RigsOfRods/rigs-of-rods/pull/626