Mixed Mode Modeling

There are two categories of graphics programming that you can do.  One is “immediate mode”.  That’s when you want to draw something, and have it show up immediately.  Like drawing a sinle point:

point(x,y, color)

For fairly simple things, this is exactly what you want.  You might be visualizing ephemeral data, it doesn’t stick around very long, and once it’s displayed, you’ll nevcer show it again.  That’s what live television, without recording, is.  You render a frame, it’s gone, you move on.  Lots of interesting viewing can come out of immediate mode, but nothing lasting.

Then there’s persistent rendering.  A typical game is highly persistent.  The characters and scenes are modeled, and rendered repeatedly.  Changes to the state of the objects in the scene is retained, so that it does not have to be reconstructed from scratch for every single frame.  Only the incremental stuff changes, and the rendering is fairly quick.

The challenge with BanateCAD is to provide a sort of hybrid system.  Some things are persistent, and need to be modeled.  The UI for instance, has buttons and sliders, and whatnot.  Their size and particular attributes are retained in objects, and those objects in turn are held in a graphic object hierarchy.  When it comes time to render, I walk the hierarchy, telling each object to render.  Same goes for the 3D modeled objects.  They each havce state, and that state is rendered.  These two hierarchies are separate though, as the 3D scene is rendered first, and then the 2D ‘scene’ is rendered on top of that as if it were a Heads Up display.

In BanateCAD, the user has the ability to write script to do all this.  So, care must be taken to ensure that immediate and persistent can live together in peaceful harmony.  What’s really going on behind the scenes though is that the immediate mode is talking to the renderer directly, whereas the persistent objects are talking in a delayed fashion.

So, whereas the following will draw a rectangle immediately:

rect(10,10, 100, 100)

If I want a rectangle object, I’ll have to first construct it, and then render:

local arect = Rectangle(10, 10, 100, 100)

arect:Render()

Of course, by constructing the object version, it’s two calls to get something rendered, but I can now render that object anywhere in my code, without having to respecify the coordinates.  In BanateCAD, you can do both.  That makes it a collaboration between something like a raw API such as OpenGL, and a scene graph, such as OpenInventor, with sugar on top.

Another thing to consider in utilizing a text based visualization system, is just how much text you actually have to type by hand.  If I consider for the moment that the files generated for a visualization/design, are just the persistent format of the program, then I’m a bit more free in what I do to create that file in the first place.  There’s no reason in the world I can’t simply use a more visually based modeling tool to construct my designs, and then persist the data in the format BanateCAD expects.  In that way, you can get the pleasures of both worlds.  Those who like to type their designs can get the precision they like, and those who like visual design tools can use their mouse to their heart’s content.

The key is to have an underlying system that is robust and expressive, supporting all the complex design concepts the user cares to utilize.  So, the underlying system has Cubic Surfaces as a primitive, and the user can use those in myriad ways.  The key benefit of having it in text is that they user can modify things slightly by hand, and come up with new routines fairly easily.  Let’s say you want to add a bump map routine that isn’t already there.  Simply add code, and away you go.  Not so easy with a program that does not already support an add-ons module.

And so it goes.  Having the flexibility to program different types of rendering, having retained and immediate, using BanateCAD as a persistent format, makes it all very useful in so many different scenarios.

 

---