Hi,

On Thu, 2007-07-19 at 13:29 +0200, Carsten Neumann wrote:
>       Hi,
> 
> I'm currently trying to understand the details of the
> RenderTraversalAction and a couple of questions have come up:
> 
> 1) RTA::recurceNoNodeCallbacks looks as if it should be used from cores
> that want to traverse the tree below the current node (it basically does
> the same as Action::recurse but does not call callEnter/callLeave on the
> current node).  If that is the intended use then it is broken for the
> case where _newList is used and two or more passes over the subtree are
> required, because the first call to callNewList will destroy the
> contents of _newList.  Is this a known/intended limitation ?  I think
> this can be fixed by introducing a special variant of callNewList that
> swaps the local nodeList with _newList before it returns. [1]

that is half NI as the calling core is expected to control the
newlist. So in one way of viewing it the calling core/element could be
expected to take care of that.

> 2) It looks as if the usage of e.g. Stages can create dependencies
> between partitions, because one draws into a FBO and its contents are
> used as a texture elsewhere.  How can one ensure the correct order ?

On the highest level, the order of the partition creating elements in
the tree. Note that currently this does not take out of order traversals
into account (this is somewhere on my todo list). In general partitions
are executed in the reverse order they are created.


> 3) What are partition groups ?  What is the difference between creating
> multiple partitions with or without surrounded by
> beginPartitionGroup/endPartitionGroup ?

Groups and lists are there to mark which partitions must be moved as a
block in case the partition creating element is shared and as a result
the partition order must be changed.

The difference between group and list is that inside a group the
partitions are executed in the order they are created inside the
list in reverse order.

> 4) How does the sort key generation work, from a high level point of
> view ?  What is the idea behind the various uiKeyGen ?

Currently the sort key is a combination of the chunk id's used for
sorting (currently 3, but I don't like this limitation). Correspondingly
there is a 3 level sorter which uses the chunk id's at the
respective level.

Various uiKeyGen ??. The basic idea behind the variable keyGen is that
the app can decide which of the 3 chunks should be used for sorting. 


> 5) The DataSlot mechanism seems to allow a core to attach additional
> state to the RTAction, right ?  Are there examples where this is used ?

Not necessarily only state, just any information that should be kept
over frame boundaries. IIRC HDR uses it, the shadow engines too. 
Currently this is part of the action but it might not be the final
place.

in general this is still a little bit a moving target so things
might change and pieces of the puzzle are still missing.


regards,
  gerrit



-------------------------------------------------------------------------
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2005.
http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
_______________________________________________
Opensg-core mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/opensg-core

Reply via email to