Hello Marcus,
Marcus Lindblom wrote:
> Carsten Neumann wrote:
>> Marcus Lindblom wrote:
>> 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.
maybe, but having the to-world matrix does seem useful anyway.
>>> (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.
computing the correct hit is probably not a problem for the IA because
it transforms the ray into local coordinates for that computation, and
that part happens while traversing the tree (see
Transform::intersectEnter/Leave).
> 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.
right.
>>> 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.
sorry, it seems I was thinking of the NewAction stuff I had written for
1.x some time ago. There you could register a function that was called
when no type specific function was registered.
>>> 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.
sorry, I meant to say that it makes more sense to have the IA provide
the matrix for the hit object, instead of having it compute/store tex
coords for the hit point. The former can be used to compute all sorts of
useful data, the latter is just what you need right now and I was
worried that that might not scale well.
hm, and seeing Dirks mail he seems to prefer something even more general ;)
>>> 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.
cool!
Cheers,
Carsten
------------------------------------------------------------------------------
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
