Horde3D

Hey all.

I'm calling castRay, which eventually gets into MeshNode::checkIntersection.

So the ray I'm firing hits the bounding box of a test mesh just fine, but fails to actually intersect any of the triangles of the node. So I get into debugging it and it appears the issue is that the ray is transformed into mesh space to do the intersection test. But the problem with that is that the vertices that are being checked against look like they are pre-transformed into the geometry resource. Of course this only happens when a given mesh node has a transform on it (most of my meshes in my world as it happens).

Can anyone else confirm this to be the case? Basically you need to just create a collada file with a plane and a box (and have the box translated from the origin a bit) and then try and do a hittest against the world and see if you can actually hit the box.

I really dont want to have to "bake" all of the transforms. So I'm looking for an alternative. But I'd like to know I'm not just being stupid here.

Just to follow up with myself. I checked it further. The vertices in the geoRes are definitely pre-transformed. I took out the code that did the transformation of the rayOrig and rayDir to object space and it performed as expected. Unfortunately I'm not sure this is the right fix, because now I have some issues with animated characters. I think basically there is a need for the transform into object space for animated meshes, because the meshes are not pre-transformed but instead are transformed on the fly. I'm trying to figure out a way to determine which case to use so I can fix for the case where objects are just transformed but not animated.

I might also sidestep the issue by reimplementing PhysX support into my engine and use their raycast code to do hit detection.

Without taking a look at your or Horde's actual problem this
is the right solution anyway, in case we're taking about a more than 1000 vertices in your scene...
We used bullet for collision detection only, but PhysX support should be equally easy to implement.
You could have a look at the GameEngine of Horde which also has bullet support.

The basic outline is:
- get geometry resource of your model node
- extract vertices and triangles (distinguish between 16/32 bit indices) - use h3dMapResStream
- create phyiscs proxy with the triangles just extracted
- apply the model's node absolute transformation to the physics proxy (do this whenever your model's transformation changes)
- raycast against physics proxy

Good luck.

I've been back and forth with the whole physics engine issue. I had originally had Bullet working, but the bullet raycasts were too slow for my scenes. I switched away from them to physx, which was better, but I didnt like the need for phsyx drivers. I ripped it out to try havok in there, but I didnt like the idea of being windows only. So I went for my own implementation using a hacked up castRay (added some simple stuff like masks and gross culling). But the game design has changed to the point where physx makes sense again.

The only major downside to physx aside from the drivers issue, is the toolset for 3dsmax not being anywhere near as good as Havoks. I really like Havoks ragdoll tools.

Ah well, time to make a new branch I guess.

I did a quick test setup as you described (plane and box) and could not reproduce the problem. The box mesh node had a non-identity transformation. After that I merged the plane and the box into a single mesh (I guess that's similar to what you mean with pre-transformed vertices?) and that worked as well. I also don't see at the moment why the algorithm shouldn't work. Are you using the latest unmodified code?

I'm not up to date I dont think. That could definitely be part of it.

I'll merge over the next week or so and see if it stays the same.

The main issue is that my 3ds max scene has several meshes (boxes, planes), each has thier own transform which offsets them from the origin. The intersection code applies the inverse of the transform to the raycast and then checks against the mesh triangles. But the mesh triangles have already had the transform applied (so the mesh is in post transform space and the ray is in pre transformed space).

I suspect its my out of date code. I'll verify by the end of next week.

Phil.

Not sure if I get you correctly but if the transformation is already baked into the vertices then the mesh node will have an identity transformation, otherwise the rendering would be wrong as well.


Please let us know if something is still broken so that we can do further investigations.