> do these nodes all have a specific type of NodeCore, i.e. all have
> Billboard cores ? In that case you could register a different function
> with the RenderAction for that type of NodeCore.
the attachment contains a node with a transform core and this in turn a child
with a geometry core. i just realize that it is probably more practical to just
exchange the cores of the existing nodes (the transform core is not really
necessary, i could apply it to the geometry directly).
for registerEnterFunction, do i have to define my own NodeCore class with the
enter function as member? i do not yet see clearly through all these functor
templates...
i tried with a standalone function, but it fails to compile...
Action::ResultE myEnter(NodePtr& node) { return Action::Continue; }
void init()
{
...
renderAction = RenderAction::create();
renderAction->registerEnterFunction(Geometry::getClassType(),
osgTypedFunctionFunctor1CPtrRef<Action::ResultE, NodePtr>(myEnter));
...
}
>> is it the best way to derive from RenderAction? which method do i need to
>> override?
>
> The behaviour of the RenderAction is mostly inside the callbacks for the
> different NodeCore types (look in the NodeCores directory, the
> registration with the RenderAction usually happens inside initMethod).
> If you can not find a way to make use of the NodeCore type dispatch, I
> think you have no choice but to override Action::apply() and reimplement
> the behavior of Action::recurse (to which apply basically forwards) with
> your custom additions.
thanks,
simon
-------------------------------------------------------------------------
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT & business topics through brief surveys - and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
_______________________________________________
Opensg-users mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/opensg-users
