Models and Instances

[greebo]

Right now each scene::Node has exactly one scene::Instance, but there is one exception: all the Model Nodes, where multiple Instances exist for the same Node.

 

As discussed earlier, the idea behind that was to store the raw Model data only once, which is of course desirable, but I guess this can be solved in another way. Also, there are two complications caused by the multiple-Instance-for-single-Node approach:

 

- Some Models can disappear when Regioning is turned on, because this filters out the single Model Node and all Instances along with it.

 

- The whole InstanceSet stuff is bloating the scene::Nodes with stuff that is unused most of the time (all brushes, patches, lights and whatever only have one instance and don't need to use it). The current Model approach prevents me from removing/simplifying it.

 

Of course it would be nice to have the raw model data cached and stored only once, but I guess this can be solved by removing the entire ModelNode approach and let the Entity Instances to hold the reference to the Model& data themselves.

 

So, to sum this up, right now it's something like this:

 

Doom3GroupNode ("func_static1") has a ModelNode CRATE as child

EClassModelNode ("moveable_crate1") has the same ModelNode CRATE as child

The CRATE ModelNode has two separate Instances.

 

My approach would be this:

Doom3GroupNode ("func_static") holds a reference to an abstract Model& object (whatever this may be, ASE, LWO, NullModel)

EClassModelNode ("moveable_crate1") also hold a reference to the same Model& object.

No ModelNodes, no ModelInstances. The Model object is still an Renderable/OpenGLRenderable object, so that the Doom3Group/EclassModel is not bothered with implementation details needed to render the actual model (plus filtering and skin remappings).

 

It is probably necessary to change the ModelLoader interface and the underlying resource cache a bit, because everything is designed to deliver scene::Nodes when loadModel() is called.

 

Thoughts? Should I go ahead and change this?

[OrbWeaver]

That sounds like an improvement, by all means go ahead although I guess some of this may become obsolete with the scenegraph refactor?

[greebo]

That sounds like an improvement, by all means go ahead although I guess some of this may become obsolete with the scenegraph refactor?

Partially, yes, especially the way the Instances are handled. But anyway, it should make our lives easier when porting the scenegraph over to the new one when this multiple-instances-one-node approach is gone. After that, each scenegraph node is an actual object with only one instance.

 

And model data is not stored in scenegraph objects.

[greebo]

Ok, I changed my mind, I'm not going to start on this. There are too many changes required that would become obsolete with the new scenegraph that it would be a partial waste of time.

 

After a first read through the code, I thought it was "just" reorganising the Model data references, but there's more to it than that. For example, the PicoModelInstance derives from LightCullable, SelectionTestable, SkinnedModel and whatnot. There will be much copying and moving stuff around, which would result in even more bloated Entity classes (an EClassModel would have to derive from all of the aforementioned classes).

 

Part of the problem is that the various Entity classes are a pain to maintain. This will need changing too, it's so tiresome copying stuff around. A unified Entity class would be nice.

 

That's not something I want to do before the other refactor, so I'll leave it at that. We will have to consider this model problem when we are going to layout the new scenegraph.