Horde3D http://horde3d.org/forums/ |
|
Extend picking function to find texture coordinates http://horde3d.org/forums/viewtopic.php?f=8&t=1164 |
Page 1 of 1 |
Author: | swiftcoder [ 18.05.2010, 23:34 ] |
Post subject: | Extend picking function to find texture coordinates |
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? |
Author: | DarkAngel [ 19.05.2010, 01:54 ] |
Post subject: | Re: Extend picking function to find texture coordinates |
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). |
Author: | swiftcoder [ 19.05.2010, 03:12 ] |
Post subject: | Re: Extend picking function to find texture coordinates |
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 ![]() 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. |
Author: | swiftcoder [ 19.05.2010, 19:45 ] |
Post subject: | Re: Extend picking function to find texture coordinates |
All right, the proposed changes:
Comments, criticisms, suggestions? |
Author: | marciano [ 20.05.2010, 21:49 ] |
Post subject: | Re: Extend picking function to find texture coordinates |
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. |
Page 1 of 1 | All times are UTC + 1 hour |
Powered by phpBB® Forum Software © phpBB Group https://www.phpbb.com/ |