Carsten Neumann wrote: > Hello Marcus, > > Marcus Lindblom wrote: >> So, VisitSubTree works fine, but IntersectAction probably needs some >> work in order to show the correct path. > > "show the correct path"? Is this related to the tex coord code you > posted, that relies on getToWorld() ?
Precisely. > It is a limitation of VisitSubTree that it breaks the parent chain and > therefore can not get the to-world matrix. Yup. I suppose if I got the local hit point instead, I could also work that way. >> (Yes, I know, I'm going down a multiple-parents-per-node path here, >> which OpenSG tries to avoid) >> >> Nevertheless, what I mostly need is the actual to-world transform of the >> intersected node, > > the matrix could be just another element of the "hit record" the IA > holds. However the IA would need its own matrix stack to actually > accumulate transformations along the path it takes - after all > getToWorld() on the node with the hit does not work... ;) It seems to compute a correct hit today (at least it hits the right objects), so I assume the current accumulated to-world is correct. The problem is, it doesn't keep the to-world transform from the time of intersection after the apply() call has run it's course. >> not necessarily the entire path from root to node. >> (Although it might be handy to have as well...) > > Maybe, but then you'd need a stack of Node * as well and make sure every > Node on the path gets pushed/popped, instead of only those that change > the transformation matrix - I guess a suitable default functor could be > used. Hm. I'll have to look into how the Actions work more closely to attempt that. I don't need it know anyhow. >> Does it seem a reasonable thing to fix? > > sure, providing the to-world matrix seems like a better idea than e.g. > computing the tex coords of the hit point (otherwise next month it might > become necessary to compute/store tangent space as well, etc.) No, I still need the tex-coords, as we have separate images to indicate different semantics on various parts of an object. I could of course add this code into IntersectAction to allow the user to compute other interpolated attributes at the intersection point. Just provide the attribute array index and it'll do the rest. >> If so, how should I go about patching that? Either just grab the >> transform and add get-function for it (similar to Point/Object/Normal) >> or is there some better way? > > Sounds reasonable to me. Ok. I'll see what I can cook up. Cheers, /Marcus ------------------------------------------------------------------------------ OpenSolaris 2009.06 is a cutting edge operating system for enterprises looking to deploy the next generation of Solaris that includes the latest innovations from Sun and the OpenSource community. Download a copy and enjoy capabilities such as Networking, Storage and Virtualization. Go to: http://p.sf.net/sfu/opensolaris-get _______________________________________________ Opensg-users mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/opensg-users
