Hello Marcus,
Marcus Lindblom wrote:
> Dirk Reiners wrote:
>> I would propose to add an optional feature to keep track of the path to the
>> base
>> Action. So whenever a node is pushed/popped the Action keeps track of it, if
>> the
>> application wants it, and just exposes it as a const std::vector<Node*>&. If
>> the
>> tracking is active the IntersectAction would have to copy it on intersect.
>
> This actually seems to be the easiest path. I didn't know that the
> actual Line object inside the IntersectAction was transformed back and
> forth all the time. (I feel numerical precision alarms going off, but it
> doesn't seem to be a big problem...)
hm, so far it did not seem to be a problem, also I'm not sure how
transforming the line compares to multiplying the matrices, precision wise.
> Either one would change that, to have the original line all the time and
> just update the to-world matrix on entering transform cores, or add
> two extra functions that pushes/pops nodes on each node.
>
> Can I do that by just registering extra functions for NodeCore? Or do I
> need to rework the Action itself?
the callbacks are only looked up for the exact type of the core not for
its base classes (and doing so would probably not be a good idea). You
could either add a default functor that is called when no specific one
is registered (you'd also have to change all the specific functors to
push/pop nodes) or integrate it into the traversal code of Action (and
make it optional).
I don't have a strong preference either way.
Cheers,
Carsten
------------------------------------------------------------------------------
Crystal Reports - New Free Runtime and 30 Day Trial
Check out the new simplified licensing option that enables unlimited
royalty-free distribution of the report engine for externally facing
server and web deployment.
http://p.sf.net/sfu/businessobjects
_______________________________________________
Opensg-users mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/opensg-users
