Irrlicht Engine

I don't want to limit my engine to 2D; I just want to be able to make it run in only two dimensions if desired.

So there's no magic to do with detecting and correcting penetrations in the collision callback? I'll tinker with it a bit, but if that's not a normal solution for this kind of thing I'll ...

intworld:

I tried bumping my time step to 20ms and still was able to get stuck and saw boxes penetrating my mesh if friction < dInfinity.

I'm not doing anything checking on the penetration depth of a given collision. Is that off? I was under the impression that if they'd already penetrated each ...

I'm pretty surprised that boxes don't work in trimeshes. I didn't see that in the documentation for ODE, and you guys say it like it's a given for any physics engine, but hey, capsules do seem to work much better. I can still get them stuck in some more complex geometry, but I don't aim to have ...

I've been grasping for solutions with a problem for a while now. I've been using ODE for physics in my game, and am using a trimesh for my world and a box for my actor.

My box keeps getting stuck in the trimesh. The problem is aggravated by high speeds, but it happens often enough at low speeds ...

Thanks, I failed to notice there was a second page on this :P.

That does seem to be the standard way to do it with Newton. What I'm doing, (so far as I can tell) matches what is normally done to get meshes into ODE/Physx, or any other physics engine's mesh creation function via vertex and indices ...

Well, heck. Looks like there's nothing wrong with my mesh, then. I'll go back to staring at my code. Thanks, guys .

Oh, damn. I'm used to seeing faces defined in counter-clockwise order, so figured that was correct. Is this a known issue with ms3d-generated files? Anyone have an idea for an app that could save out a simple cube model with the correct vertices order? I'll try creating something with Blender and ...

Does vertex order matter here? I've noticed that some of my faces appear to be defined in counter-clockwise order while others are defined in clockwise order. That said, the top of my box is all defined counter-clockwise, so I may just have gotten cross-eyed halfway through this. And if the top's ...

I swear I'd typed that they looked fine to me after a cursory glance, but that's definitely not anywhere in the post. I'll take a closer look at it the next chance I get, though.

My main hope in posting this was that it was a common (but something I failed searching for) issue and that there would ...

I am copying my indices data into an array and passing it along to
ODE_API void dGeomTriMeshDataBuildSimple(dTriMeshDataID g,
const dReal* Vertices, int VertexCount,
const dTriIndex* Indices, int IndexCount);

a dTriIndex is a typedef of a uint32, so I figured all was right in my copying of ...

I think you may be misreading it. It's just iterating through the members of theBufferVertices from 0 to theMeshbuff->getVertexCount().

theVertices is a float* with a length of 3 * the total vertex count, and I'm sticking the x,y, and z coords each into sequential indices of theVertices. The values ...

Thanks hybrid.

I guess the problem is that I'm taking this data to represent a trimesh when in fact it doesn't?

For example, the vertices
Vertex 6: (119.868, 4.03141, -14.4375)
Vertex 7: (119.868, 0.949764, -14.4375)
Vertex 8: (119.868, 4.03141, -14.4375)
don't make a face, but show up ...

I'm trying to get the vertex data out of a MeshNode generated from a .ms3d file for use as a collision geom for ODE. Since my mesh collisions weren't looking too accurate, I decided to step through the vertices and found that my 8 vertex test box's mesh node had 24 vertices, many of which simply ...