Scenegraph Refactor?

[greebo 61]

It looks like the branch is pretty stable now, I will do some tests with large maps and will start to merge the changes back into the trunk.

 

edit: Merged.

[greebo 61]

I'm another step closer to figuring out the scenegraph and I could finally track down the algorithm of node insertions, instantiation, map loading and such.

 

Currently, each node can (theoretically) have more than one instance, but this is never the case, actually. Is this a needed feature? It seems to complicate things a bit, and it might be that other game engines than Doom 3 have such scenegraphs models, I don't know. It's definitely unused at the moment and there are some unnecessary loops and callbacks involved, imo.

 

If I ever get to refactor that kind of stuff, should we keep this possibility of multiple instances per node? It doesn't seem to be practical.

 

What I still don't get is why models disappear when turning on regioning, given that every node has exactly one instance. It would've been logical if models having the same .ase or .lwo are just instances of the same node, but this is definitely not the case. So this puzzles me a bit, maybe I can figure that out.

[OrbWeaver 637]

If I ever get to refactor that kind of stuff, should we keep this possibility of multiple instances per node? It doesn't seem to be practical.

 

If it's not used, it can be scrapped. No point in maintaining cruft for the sake of it.

 

What I still don't get is why models disappear when turning on regioning, given that every node has exactly one instance. It would've been logical if models having the same .ase or .lwo are just instances of the same node, but this is definitely not the case. So this puzzles me a bit, maybe I can figure that out.

 

Models with the same path share a PicoModel but they have different PicoModelNodes, as far as I can recall.

[greebo 61]

From what I know, models are actually encapsulated within Doom3Group nodes. These are nasty hybrid classes that reflect the same ambiguity as Doom3's func_statics. Assign a model key to them (!= name) and the class behaves completely different because of tons of IF statements, it's not pleasant to work with.

 

It makes of course sense to have model resources shared by different model nodes, I think that's handled by the referencecache, isn't it?

 

I'll have to look how the models are incorporated into the Doom3Group, maybe there is some weirdness going on as well.

[greebo 61]

I was wrong, there are cases with more than one instance per node, so the disappearing models on regioning make sense again. This makes it harder of course to move, I was hoping that the InstanceSet could have been ditched...

[greebo 61]

Well, I take everything back: I though I got a grip of the scenegraph, but the things going on with the Doom3GroupNodes and their InstanceSets are creeping me out.

 

If I duplicate a model, another node gets created, which is fine. Each node has its own InstanceSet (not a reference, the actual class). The weird thing is, that after duplication, both the InstanceSet of the new node as well as the one of the existing Doom3GroupNode get an Instance inserted, so basically two references to an instance are floating around now. The best thing is that I don't have the faintest clue how the existing (completely unrelated) InstanceSet gets notified about the new Instance.

 

I mean, it's nice that instancing works, but at least a tiny comment somewhere in the code would be nice so that anybody else than the one who wrote it (SPoG?) can understand what's going on without spending the whole afternoon looking at this. Argh!

[greebo 61]

Hm, as it seems, some objects are actually instantiated multiple times. This is really a mess, I still don't know how this happens. Additional to that, my scons is not working anymore in Linux (it doesn't detect any file changes any longer - it always states "." is up to date).

 

I guess this section can't be refactored this easily and might have to be done in a single large sweep, so I'll leave it for now, before I get too demotivated. Given that this instancing causes problems with regions, I wonder if the multiple-instances approach is worth the hassle and shouldn't be replaced entirely by a simple one node - one instance approach. Models could still be cached, that's probably not a concern.

[greebo 61]

I continued working on the scenegraph and could finally figure out how the Model instancing is handled and why the InstanceSet can actually contain more than one Instance. I had to use several sheets of paper to get an overview over what actually happens, but I could gain some understanding why things are set up this way.

 

For starters, I'll now try to remove the scene::Instantiable::Observer abstract base class, as the GlobalScenegraph is the only class implementing it. Currently, the pointer to the scenegraph is passed throughout the entire instance tree, but it's always pointing at the same class, which is unnecessary overhead. The InstanceSet even used this Observer* pointer as key in the InstanceMap - whatever the intention was, it's certainly not necessary for the Doom3 scenegraph and only complicates things.