Horde3D

Next-Generation Graphics Engine
It is currently 19.03.2024, 03:59

All times are UTC + 1 hour




Post new topic Reply to topic  [ 5 posts ] 
Author Message
PostPosted: 18.05.2010, 23:34 
Offline

Joined: 22.11.2007, 17:05
Posts: 707
Location: Boston, MA
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]


Top
 Profile  
Reply with quote  
PostPosted: 19.05.2010, 01:54 
Offline

Joined: 08.11.2006, 03:10
Posts: 384
Location: Australia
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 :wink:

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).


Top
 Profile  
Reply with quote  
PostPosted: 19.05.2010, 03:12 
Offline

Joined: 22.11.2007, 17:05
Posts: 707
Location: Boston, MA
DarkAngel wrote:
There was a bit of a discussion about this previously: viewtopic.php?f=2&t=1014
Thanks - I missed that.
Quote:
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...
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 :wink:).
Quote:
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).
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]


Top
 Profile  
Reply with quote  
PostPosted: 19.05.2010, 19:45 
Offline

Joined: 22.11.2007, 17:05
Posts: 707
Location: Boston, MA
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]


Top
 Profile  
Reply with quote  
PostPosted: 20.05.2010, 21:49 
Offline
Engine Developer

Joined: 10.09.2006, 15:52
Posts: 1217
DarkAngel wrote:
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).

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 ;)).

swiftcoder wrote:
Comments, criticisms, suggestions?

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.


Top
 Profile  
Reply with quote  
Display posts from previous:  Sort by  
Post new topic Reply to topic  [ 5 posts ] 

All times are UTC + 1 hour


Who is online

Users browsing this forum: No registered users and 3 guests


You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot post attachments in this forum

Search for:
Jump to:  
cron
Powered by phpBB® Forum Software © phpBB Group