Horde3D

Hey, its me again

After taking a long break, I have returned with more enthusiasm than ever. In the meantime I dropped out of college, prepared for a new one and got admitted in... wait for it... Architecture!

Now to business. I have to cast in the game world a ray and get the exact point of intersection with the intersected mesh. Like, let's say, I shoot a wall(a quad made up of just 2 triangles, which has an arbitrary rotation; it also has planar mapping and the full uv space is mapped to the quad) and want to know where to exactly place the gunshot decals using values from uvs (maybe?). Can I do that with Horde? Or is there another technique i can use?

_________________
Paul

A programming architect, congratulations!

Concerning your intersection problem. Is h3dCastRay together with h3dGetCastRayResult sufficient for your needs?

Thanks Now I will use Horde3D doing arch vis work for school :p

From what I know those return only the intersected nodes.. Do they return the exact position on the object where the ray intersects with the node? How will I know where on the wall to place the decal?

_________________
Paul

h3dGetCastRayResult can tell you the intersection position (in world space), but not the texture coordinates.

A friend advised me to use the barycentric coordinates of the intersection point in regard to the triangle that hosted the intersection.
But the intersection triangle is not returned by the function.

Horde does the intersections by checking against the triangles, right? So this information is there and should only be exposed.

Anyone willing to help? I'm having no luck with the internals

_________________
Paul

I think i've got it. This is what i want to do:

-egScene.h: modify the CastRayResult struct by adding variables to hold the uv data.
-egAnimatables.cpp: modify MeshNode::checkIntersection's for loop. When it registers a hit in a certain triangle compute the barycentric coords using the vertexes' position and the intersection position. Then download the uvs for the vertexes(GeometryResource::getVertStaticData) and using the barycentric coords computed earlier find out what are the uvs for the intersection point
-egMain.cpp: then finally edit the h3dGetCastRayResult to also return the uvs


Can I overload these items in an extension? Or do I have to patch the engine?

_________________
Paul

First thanks for sharing your solution. You could implement it in an extension, although that might be some kind of an overkill. Maybe it would make sense to add the triangle data to the public interface?

It's about time I started giving something in return


Because CastRayResult was already full with data that you might use or not, I was thinking not to bloat it even more with data that is or not need.
There for the idea was to have a an alternate version of the ray cast/get result functions in an extension and use them only when needed.
It would be nice if Horde's system allowed for a dynamic creation of CastRayResult and choose what elements to be stored. (ex: return only the position, or only the node)


Uhm.. I'm not sure I understand this. You mean exporting the position and uv data as the collision result? Wouldn't this make CastRayResult even heavier?

_________________
Paul

In other engines that I've used, the ray-cast function usually takes a bit-mask, which specifies the attributes to be returned.
e.g.
h3dCastRay( node, x,y,z, dx,dy,dz, 1, h3dRayPosition | h3dRayUV );

If you *don't* specify the "get UVs" flag, then they won't be computed and "h3dGetCastRayResult" would fail (or return default data) if you ask it for UVs afterwards.

So the procedure would be to call h3dCastRay with the flags for the data you want to compute, then call h3dGetCastRayResult to retrieve ONLY the data that you asked for.

[edit]I like the more generic suggestion below

Another way would be to store in CastRayResult an int for the triangle index and 3 floats for the barycentric coords (not the uvs anymore) and then compute the uvs outside the engine.
This way it doesn't specialize in doing a single thing (computing the uvs). Using the barycentric coords and the triangle's attributes you can interpolate more per-vertex attributes than uvs.

LE:or even better, to store only the triangle index in CastRayResult. Then use the interface's resource api for an external barycentric calculation. This way the change to Horde is minimal

_________________
Paul

This is a good idea. Another strong argument for doing it that way is that not all vertex data is necessarily available to horde. Texture coordinates are a good example for data that resides exclusively in VRAM (not accessible from CPU on most platforms) and is usually not required in main memory (to reduce memory consumption).

I would suggest to return the triangle index and two barycentric coordinates u and v since these are computed by the intersection algorithm anyway. The intersection position for example could then be reconstructed by intsPoint = vert0 + edge1 * u + edge2 * v where edge1 = vert1-vert0 and edge2 = vert2-vert0

If there are used only 2, in regard to what reference system are they computed? The u and v you mention are the texture space uvs?

I was thinking about 3, one in regard to each of the vertexes that form the triangle.

_________________
Paul

The parameters are relative to two edges (see formula in my previous post). Having 3 parameters relative to the vertices would probably be a bit clearer for users but the other representation is already available from the intersection algorithm.