Is this a smart engine design?

Okay, so I’m working on writing a fairly simple jogl engine that will allow me to still use GL commands but provide more structure, somewhat reminiscent of a scene graph.

The basic design consists of a set of interfaces, GLStateModifier, GLDrawer, and GLVisitor:

GLVisitor have an arrive and depart method that are called when added, or removed to my renderer. There main purpose is to be used
for initialization of textures, display lists, and VBO’s and other server side things.
GLDrawers just perform drawing code in there draw method.
GLStateModifiers
modify the state on a modify() call and then restores any of the modified state variables in a restore() call.

The renderer basically calls arrive() on any new GLVisitor, applies all the GLStateModifier’s, draws all the GLDrawers, and then restores the GLStateModifiers. There is then a node class which has the exact same functionality of the renderer without support for GLVisitor’s and it is a GLDrawer. This allows for tree structures to be built that would be very similar to a scene graph (if not an actual scene graph).

I have also created utility implementations of these interfaces for lights, fog, common drawing properties, materials, textures, view/camera, and transformations. I intend to also implement drawers that take positioned objects and act like BSP’s or octrees and eventually shaders. Just using these, you could accomplish a fair amount. I like the structure and it works for my personal use, but I’m a little worried about the caveats required when writing new GLDrawer’s, visitors and StateModifiers.

These caveats include that the GLDrawer should leave the state unchanged after its draw() is finished, and stateModifiers should leave the state unchanged after its restore() call.

So finally, my main question, is this a bad idea, or not? [sry for the long post]

i like the visitor pattern angle. it is one i hadn’t considered. i just started a thread that is basically asking a similar question: that is, how to decouple the GL portion of the implementation from the drawers so that you can plug in new elements and expand as you go. right?

i’m going to read up on the visitor pattern a little bit more. i hadn’t considered this structure. that’s what’s cool about software; there are an infinite number of machines you can build, an infinite number of ways to skin a cat. that’s also what makes it tough. lol.

cheers

maybe you can take a look at the c++ irrlicht engine (http://irrlicht.sourceforge.net/) which has imho a very good and not to difficult design. this helped me a lot.