JV-ODE collision question
Blitz3D Forums/Blitz3D Userlibs/JV-ODE collision question
| ||
| I'm interested in purchasing the full Blitz3d JV-ODE DLL, but I've got a couple questions about it first and was hoping someone in this forum can answer them. Can JV-ODE's collisions run purely off arranged shapes (spheres, boxes, capsules), or can it also perform polygon-to-shape collisions, like a platformer game map, or a detailed terrain? I hope someone out there has an answer for me! |
| ||
| Polygon-to-primitive collisions use a primitive (sphere, box, capsule etc.) and a trimesh (a physics hull defined by an arbitrary mesh's triangles). So this "trimesh" is what you will use for levels. JV-ODE seems to be a good product and the author is still "alive". There's also BlitzBullet: http://www.blitzbasic.com/Community/posts.php?topic=95713 I can't attest for its quality or for any support you'll be given. It's just another option. |
| ||
| It's worth pointing out that while it can to shape-to-trimesh collisions, most of the time you should try to use shape-to-shape anyway. It'll be both faster and a lot more robust. I would stay well clear of trimeshes for something like a platformer. A heightmap terrain is probably one of the few situations where they'd actually be useful though. A rule that's worth repeating ad-nauseam is that you shouldn't attempt to use your render mesh for collision purposes (just in case you were thinking of doing that). Instead, build a nice even, simplified, low-poly version where you absolutely need meshes, and stack logical boxes together where you don't; and use that secondary construct. You don't need (or want) fine details on a collision mesh, but you do want high performance, even surfaces, and reliably solid floors. |
| ||
| I second what Yasha has said. Combining an optimized, tweaked trimesh along with various shapes is much more economical in memory and performance than just using a trimesh from the original level mesh used for rendering, and it also allows you to include 'support' polygons such as invisible walls etc. so that the player doesn't get stuck in corners or complex structures, and doesn't climb on spots and cheat the level (as seen here: http://www.youtube.com/watch?v=CzV8Ob7DuU4&t=26m). |
| ||
| Okay, I'm seriously about to lose my sh*t. I pay $20 for a physics engine, and end up with the same ***damn problem. If the "world" mesh is even remotely bigger than a claustrophobic island, the collision for its edges won't do jack-sh*t. I'm seriously considering quiting Blitz3d because of this, 'cause there's always some sort of f***ing problem that f*cks everything up. |
| ||
| Chill man. Secondly, the most important thing you paid for with JV-ODE is support. If you can't get it working by yourself, give the developer a message and see if he can explain what's going wrong. I don't know how "live" it is in that respect nowadays but it certainly used to be very well supported indeed, VIP3R always happy to answer sensible questions. Firstly though... how big is "big"? Are you running up against the limits of floating-point precision? If so you might be able to solve the problem by chopping your world up into smaller sections and either disabling physics for distant objects, or using a scaled LOD-physics system for large items that still need to be simulated at long range. (Consider the Elder Scrolls for a good example of how to disable areas that are out of range: the "world" is only a couple of hundred metres across at any given time, but centred in a scaled LOD-world that represents a larger space around it, and when you go near to a boundary, the point of origin is moved and you enter a second world space seamlessly matched up to the one you were just in.) Single-precision floating point only has 2^23 points of precision to play in. Once you consider that objects move in steps hundredths of their size per-frame (for smooth movement), you can only have a reliable world space a few tens of thousands of times the radius of an object. (Assuming that precision is the problem, you could also fix this issue by using an engine that supports double-precision collisions, but I would seriously question whether you need to be simulating every penny that drops a hundred kilometres away - it's just a waste of power.) It's also worth pointing out that trimeshes are inherently unreliable as colliders, because their nature as an infinitely-thin 2D surface means that some high-speed collisions can leave the engine not knowing exactly what side of the polygon a collider is supposed to be, because it has no depth. JV-ODE has written a lot of code around this problem to make it work in more situations, but this is one reason why purely logical "shape" colliders are so much more reliable (and faster) - they have a well-defined "inside". |
| ||
| 1) Send a polite e-mail to the author asking for support on JV-ODE, with a thorough description of your problem and the context of the scene (its layout etc.) and a clear screenshot of the problem ( support at deviouscodeworks.co.uk ). 2) While you're waiting for his reply, test if the distance is the cause of the problem. Before starting the level, position the island in a way so that one of the island's edges, that you know is showing the problem, becomes located close to the world's origin [0,0,0]. You need to move the mesh of the island as described above by using PositionMesh, not Move or PositionEntity; only then do you create the tri-mesh of the island. |
| ||
| I still visit the forums frequently (even though I don't post much these days). Describe the problem in detail, or even better provide an example showing the issue and I'll see if I can identify the problem for you. |
| ||
| Dang VIP3R lives ! |
   |