Graphics Abstractions

I am not really sure how to start this but lets talk tonight about useful graphics abstractions; meaning lets run over lots of different ways you could groups items.

- Geometry buffers and index sets into a geometry buffer.
- A geometry buffer mixed with some sort of material system would give you something you could see, lets call it a geometry object.
- Anything with some 3d transform information you could call a node.
- Out of these node objects you can produce a scene graph.
- Take a subgraph of these meant to represent a single entity (like a person) and you have a model.
- For a given model there will be a set of animations that are meant to be applied to it, a model w/ possible animations you would call...what? Perhaps a character?
- A large scene graph possibly containing groups of models you could call a new model.
- For a given model it may make sense to have several given states the model could be in. Perhaps with armor or without, perhaps glowing or perhaps without.
- This includes the larger scene graph, thus you have groups of models, each given model has several states and most likely lots of animations you can apply to it.

This is all talking about immediate mode things, or I guess you could call them instance level things. But really any given model would perhaps have a canonical form along with an instance level form. You can really have several levels of instancing, perhaps with a master state that the other states reference and just change bits of.

Oh, by the way, the actual set of properties on a given object is not well defined. They can change. At runtime.

Now lets look at this from a difference perspective....

Lets say you have a given state of an object. Normally in a 3d environment there is a relatively high repetition of various assets, thus you have a bunch of chairs that all look identical or very similar.

So you introduce various different levels of master-instance relationships. Really what is happening is that you have different representations of a given object that you can write things to and read from. This may get too vague to follow quickly but in a product I am currently working with we have:

schema -> defines default properties
Library -> Defines some changes to defaults
State -> Defines some changes to the library, contains animation systems
Scene graph -> Appends some properties to some objects (like global transform).
Scripting -> Changes the final result of stuff and sets properties.
Render engine -> Renders the result of the pipeline.

Thus the processing pipeline for an arbitrary property on an object looks like:

schema -> library -> state -> animation -> scene graph -> scripting -> render engine.

Capiche? Lots going on here. Now, to get a various property you need to know which stage you care about looking at it.

By the way, the state->library section can be repeated; thus you have multiple states both in series and as siblings in some sort of 3d object state graph.

The point is that we are thinking about writing a giant object abstraction that takes all of these details into account. This will be a behemoth of an object database system, completely custom to what we are doing. We will be making huge abstractions and bundling them up into simple, minimal interfaces.

Now comes the good part; why is this important?

Because people think in abstractions and symbols. They like to design things in abstractions and symbols. Plus they like to take an object, use it but change it slightly. So there are two large abstractions we are supporting generically.

The first is to allow arbitrary groupings of objects and to name these groupings. Then you should be able to use them as a distinct unit. A set of animations bundled into an animation group could define a running movement where you are animating a lot of things.

Sets of these groupings could be used to mark the set of animations that are explicitly used for a given model, which is itself a grouping mechanism for various other details.

Given a model (ignoring animation for a moment) and you may want it in different states where it is blue or red or perhaps armored as I said before or perhaps otherwise.

Building these large hierarchies of abstractions is what allows us as feeble humans to actually achieve very large things; it is important that our software recognizes and reflects this paradigm.

Next we like templates, or prototypes that we can then use and change without changing the source data. We like instancing things from master relationships. I am not certain how we like all these things to work out yet in my head but I am just now beginning to see what the next step in 3d graphics composition and application design really is.

Chris