next »

[horati]

Any objection if I add a NodeVisitor interface and some final (inlined) methods to visit nodes?

Since it is such a fundamental class, I thought I should ask first.  It should be pretty non-invasive.

[horati]

Implementing in my local copy, I see that a visitor pattern was sorta implemented.  My version will do mostly what GroupNode.findAll() does without creating any objects.

[horati]

Nevermind, I found GroupNode.traverse(TraversalCallback) and can subclass TraversalCallback.  I think we could optimize this a bit so fewer nodes are traversed.  Before I found that code, here was my version of TraversalCallback.

Code:

/**
 * Provides a means by which non-library code can traverse a scenegraph.
 *
 * Note: To promote inlining, visitation is implemented as final methods
 * on GroupNode and Leaf WITHOUT an abstract method in Node even though
 * it belongs there conceptually.
 *
 * @param T is the type you want to visit.
 *
 * @author Kevin Finley (aka Horati)
 * @see GroupNode#seekVisitation
 * @see Leaf#seekVisitation
 */
public interface NodeVisitor< T extends Node >
{
    /**
     * Tell the visitation implementation what class interests you; i.e.,
     * you want to visit all Shape3D instances, only Quads, or all GroupNodes.
     * Implementations cannot return null. 
     */
    Class< T > getVisitationInterest();

    /**
     * Should the visitation include scenegraph nodes not currently displayed
     * to the user.  Normally, this should be false so that LOD nodes and
     * switch nodes only visit visible children.
     */
    boolean isInterestedInInvisibleNodes();

    /**
     * Visit nodes of the requested type.
     *
     * @param node is the node to visit, never null.
     */
    void visit( T node );
}

[Marvin Fröhlich]

The current traversal code is pretty slow. If your's is faster, feel free to replace it. Maybe you'll find some nice features in my code and you can merge the two together .

Marvin

[horati]

Sorry it took me so long to respond.  Very shortly after this post, my hard drive crashed.  Sadly, I was unable to recover anything from the drive and did not have a recent backup.  I spent most of this past week rebuilding my personal and work lives because of it

I'll have a look at it when I get some time.  Before your response, I assumed you had a specific reason for that amount of flexibility.  I was thinking of a more specific approach that should hopefully perform a bit faster at the expense of a tiny bit of flexibility.  Part of the idea is to move the decisions from the visit (implementers of the interface) up to the visitor (the classes doing the traversal).  This should cull the number of visits through code that cannot be inlined.  Right now, non-inlined code has to visit then decide to do nothing.

Is there a way for me to query

• if a node is within range of the camera?
• only the children of (LOD) switch groups that are currently visible?

I did not see any branches in the existing code to specifically do either of these.  If it is possible, it would obviously be a huge savings.  Those queries make sense for my code for short lived traversals -- only a few frames.  There should probably be a full traversal option to accommodate the existing functionality that focuses on things like updating materials.

[Marvin Fröhlich]

The traversal code belongs to my earlier work. I didn't know anything about inlining. Actually I even tried to do the whole frustum culling through a traversal implementation. But it was incredibly slow. I searched for the reason and then discovered the inlining stuff.

I thought, having that much flexibility would be a great thing and that it wouldn't be expensive. But since it actually is, and I don't think anybody uses that high amount of flexibility, we can certainly live with a lower amount.

You will find code to decide the being-inside-the-camera's-view thing inside the FrustumCuller code. But I don't think, this should be done twice. You should add some kind of a callback, that applies the traversal to the list of Nodes, that survived the FrustumCuller. Maybe it is a good idea to never invoke the traversal directly, but always do it as a callback. This way you could add a flag to the parameters, that decides, whether to do a full traversal or do it after the FrustumCuller.

Marvin