OpenGLContext.visitor
Traversal objects for Contexts and scenegraphs
Functions
find(
sg
,
desiredTypes
= ()
)
Get list of node-paths to instances of desiredTypes
- desiredTypes
- sequence of desired base types
returns node-paths for each node in the scenegraph
of the given types
Note:
The traversal is the same as that used by the
rendering procedure, so is quite possible for
non-rendering nodes to be missed by the search.
Classes
Traverse a scenegraph looking for bindable nodes
This is a simple implementation of a scenegraph-search
which looks for all nodes which are instances of any of
a given set of classes/types.
Attributes:
result -- the resulting set of node-paths
desiredTypes -- the node-types being searched for
See the find function for the normal usage API
Extremely basic visitor/traversal object for scenegraphs
The "visitor" does not actually follow the classic visitor
pattern (where the nodes dispatch the visitor to their
children). Instead, it is a traversal mechanism that has
four major points of customisation:
- vmethods
- virtual methods which are applied to a node during traversal. Each applicable vmethod (is registered as a method for one of the node's parent classes) is applied _in turn_, so it is possible to have large numbers of vmethods called for any given node. Return values are callable tokens which perform any state-resetting required
See: buildVMethods
- preVisit
- called for _every_ node before visiting, if it returns a false value, then the node's vmethods and children are _not_ processed.
- postVisit
- called for _every_ node where preVisit returned a true value as the last customisation point before the visitor finished processing the node.
Note: For the purposes of the visitor, a Context is just a
node like any other. It produces a single "child" node which
is either a scenegraph or a special node which calls the Context's
Render method.
There is a log associated with the visitors which will log the
particular nodes, their vmethods, and any finalisation tokens
being run. By default this log is set to WARN level. You can
set it to INFO to see the verbose trace (warning, this will
seriously slow down your rendering on many systems!) The
logging calls are eliminated (regardless of the logging setting)
under a python -O or python -OO run.
__init__(
self
)
Initialise the visitor object
calls self.buildVMethods() then builds the current
stack.
Attributes:
currentStack -- nodepath describing the current
processing stack for this visitor
- _vmethods
- mapping from class/superclass to methods to be applied on entry to any instance of the class, see the vmethods method, (multiple match)
buildVMethods(
self
)
Customization point: Create application-specific type:method-name mapping
Basically this lets you call a named method for each
class/base-class in a node's __mro__. Override this (calling
the base implementation and modifying the resulting dictionary)
to register your particular virtual methods.
Format is:
class-pointer: string-method-name
The dictionary is stored as self._vmethods
children(
self
,
node
,
types
= (<class 'vrml.vrml97.nodetypes.Traversable'>, <class 'vrml.vrml97.nodetypes.Children'>, <class 'vrml.node.PrototypedNode'>, <class 'vrml.vrml97.nodetypes.Rendering'>)
)
Get children to visit for a node
Determine the set of children to be visited for
a given node in the node graph. If the node
has a method renderedChildren, it will be called
with types as an argument and the result returned
as the sequence of children.
visit(
self
,
node
)
Visit an individual node, dispatch to methods as necessary
The visiting algorithm is fairly involved compared
to the classic computer science Visitor algorithm.
First we call self.preVisit( node ), and if the
result of that is true, we continue processing.
This allows you to use preVisit to do such things
as processing every node in the scenegraph.
If we are visiting the node: (preVisit returned true)
- add the node to self.currentStack
- retrieve the "vmethods" for the node
- call each vmethod with the node as argument o if the vmethod returns a finalization token we store that token for finalization
- we determine the children to visit for the node
- for each child, we call visit recursively
- during finalization (after children are finished processing) o if we have any finalization tokens, we call those tokens o we call self.postVisit( node ) o we restore the previous self.currentStack
Note: this is the "production" version of visit
which only logs errors, not "info" level traces,
this avoids the 100's of 1000's of calls generated
by the huge number of iterations.