Beta5 Bug - Collision and the player

#1 Further examples :




That wall there with the little passageway, as well as the platform there in front of the doorway, just a bit above the water, connecting the two sides of the sewer, is a separate model. I want a "cap" for my sewer part, so I can connect pieces together.

So it's a separate model overlapping the sewer one. I should maybe mention that both the base sewer mesh and the cap have been scaled up by about 20x, since Max keeps exporting my meshes tiny.

Now, it looks like you should be able to step off the sewer mesh onto the little platform, right? Not a chance, the player mesh cannot cross that dividing line, he gets totally stuck.

Ok, I scale it up a bit further (you can see the doorway was too small). Now he crosses over onto the platform fine.


But! I cross to the other side of the sewer, using the platform as a bridge, and attempt to walk back the other way. And am stopped dead at the invisible line where the cap mesh platform would be passing under the player's feet.


Oh, and I get stuck passing that little block there 9 times out of 10. It has my ankle, aaagh!!

#2 a clipping model comes to mind:

These stairs have a clip-model RAMP over them.

Create a bright blue image and make it very see-through, yet very noticeable. Create a clipping model for your level geometry. Use the blue image on the geometry until you verify it works as needed and then replace it with a 32x32 texture that goes invisible in T3D.

I short handed that but I am sure you get the idea.

#3 I get the idea, but I still think the collision detection has flaws. This isn't just that the player is having trouble stepping. He literally gets stuck, I can't just back up and go around. He is unable to move from that collision point once the collision occurs.

Look at the last two pictures I posted. The player avatar isn't near enough to any complex geometry to be considered in collision with it.

In the one screen he is walking along a flat plane, next to a box. In the other he is simply walking along a plane, far from both the wall and the edge of the platform. The intersecting lower platform runs UNDER the plane he is standing on.

The collision detection HAS to be robust enough to handle these two scenarios or it isn't good enough. So it's one of 3 things : A code bug, something wonky with my model, or something wonky with the Gideon model. I'd be happy to send my model for testing, but I didn't do anything particularly clever, it's some flat planes and some chamfered edges.

#4 Yeah, I kinda went past the point you were trying to make...my bad.
I agree, the collision is not 'good' right now.

#5 No worries, appreciate the suggestion regardless :)

#6 Logged as THREED-684

#7 @Gareth,
change the colission to capsule, not box, and give it a try. (its in the code already, take a look)

#8 @Deepscratch : Sadly, the same thing happens.

#9 The distinction of capsule/box only makes any difference if you are using the physx module. Stock torque physics does not have the concept of capsules.

#10 Torque 3D's static mesh collision is built entirely on top of the OPCODE Collision Library which is basically as good as it gets for "polysoup" (arbitrary geometry) collisions.

When you are having problematic collisions, you really need to build a simpler, separate collision mesh over top of the problem geometry (like in eb's picture). This is a very common practice for all game engines (some attempt to automate the generation of this simpler geometry).

Perhaps now everyone will have an appreciation of why Torque stuck with closed convex collision meshes for so long =)

#11 That's the reason I've been wondering why everyone is raving about polsoup collision. It's a great feature and can be perfect in some situations, but with things like interiors it's worthless (or near enough) when your character collision is a box. Polysoup character collision could clean up some issues, but it would cause even more problems and takes a lot of processing.

#12 Anyway, I think the collision system is in dire need of spheres and capsules, which aren't supported because right now convexes must be a collection of planes, edges and points.

A capsule and some overlap-correction would allow the player to navigate even the most intricate geometries (performance issues aside).

#13 The polysoup collisions are not optimized for dynamic collisions:

"OPCODE is not very well-suited to dynamic trees.It can work, but it probably won't be efficient."
Pierre Terdiman

Gareth, please e-mail your model to me. I think I know what the problem is and need to test something.

#14 "When you are having problematic collisions, you really need to build a simpler, separate collision mesh over top of the problem geometry (like in eb's picture). This is a very common practice for all game engines (some attempt to automate the generation of this simpler geometry)."

Ok, I suppose that is fair enough. And it works, I built simpler meshes and no sticking.

Thanks guys, and sorry eb for dismissing your solution. :)

Picasso, I'll mail you that model for testing anyway.

#15 No worries.
- Sometimes industry standard workarounds/solutions are not what people want to hear. I do completely understand that...as perhaps there is a holy grail of excellence waiting to be utilized.

..and we'll never know unless we ask. ;)