Horde3D

I am implementing a GUI toolkit in 3-dimensional space, and I need the ability to determine the texture coordinates under the mouse, in order to translate input into the GUI-local coordinate space.

The logical approach is to extend the existing picking function, potentially breaking it out into a set of related functions.

Since SceneNode::checkIntersection already determines the point of intersection, it is a fairly trivial step to figure out the texture coordinates of that point: barycentric coordinates from the intersecting triangle for MeshNode, and simple interpolation for TerrainNode.

Apart from my needs for GUI interaction, this feature would be beneficial for anyone making texture-painting/editing functionality. Do you think this feature would be generally useful? And do you thi9nk it would be best to add this information to the existing raycast functions, or to add separate 'detailed ray cast' functions?

_________________
Tristam MacDonald - [swiftcoding]

There was a bit of a discussion about this previously: viewtopic.php?f=2&t=1014

Eventually I am going to need this functionality as well, but I've been putting it off

I'd like it if either the API let you retieve any of the vertex attributes, or have it return enough data for the application to do this itself...

Perhaps model-nodes could also have some kind of bit-mask that specifies which vertex attributes will be kept in RAM (are tex-coords kept around in system ram at the moment? or are they just sent to the GPU?). When performing a ray-cast, you could specify your own bit-mask for the attributes you want to be returned, and data will only be computed for attributes that are set in both bit-masks (the ray's and the model's).

Thanks - I missed that.
At least texture coordinates and normals/tangents - that is enough to implement decals, texture-painting and GUI interaction, not to mention simple collision detection (not that I would recommend doing collision detection in this manner ).
Good idea. I think that texture coordinates are only kept in GPU memory right now - we need something like Ogre's 'shadow' option to keep a copy of a vertex buffer in main memory.

The sticky question is what to do with GPU-skinned models? Either we should not allow raycasts against these, or we must fallback to software skinning for the intersection test - neither or which seems particularly pleasant at this moment.

_________________
Tristam MacDonald - [swiftcoding]

All right, the proposed changes:

• Add an additional parameter, H3DMesh::PickData
  Represents an integer bitmask of the attributes available for picking. May be any combination of NORMAL, TANGENT and TEXCOORD, combined with bitwise OR. When set, the mesh node must ensure that the enabled attributes are available in main memory. Meshes using GPU skinning are free to ignore this, as it would require software fallback. The parameter can be read to determine which attributes are indeed available.
• Add an additional parameter, attributeMask, to h3dCastRay()
  May be any combination of NORMAL, TANGENT and TEXCOORD, combined with bitwise OR.
• Add additional return-by-pointer arguments to h3dGetCastRayResult()
  One each for normal, tangent and texcoord. For each attribute which is enabled in *both* the PickMask and the attributeMask, the matching value will be stored in the pointer passed.

Comments, criticisms, suggestions?

_________________
Tristam MacDonald - [swiftcoding]

At the moment all data is still kept in RAM but obviously this needs to be changed at some point (at least when we get more serious with mobile platforms ).


Basically your proposal is good. But instead of giving too much power to the node intersection/picking function which is actually no real core functionality of a renderer, I would rather opt for extending/improving the general API to retrieve more vertex data and have the intersection function return some sort of barycentric coordinates. This is basically the idea described at the end of the thread DarkAngel mentions.