Revising model defs

The Defs namespace now exists and provides access to DED flag definitions. Now I need to decide what to do with model definitions and the old model renderer.

DEDRegister in libdoomsday is an interesting addition, as it is basically a helper that organizes a set of subrecords in a more complex manner. It wouldn’t be appropriate to put definitions directly in a Record as the members of a record are unordered, and definitions need to preserve their order. However, definitions also need to be quickly looked up via various names/identifiers, and DEDRegister helps with this by constructing and updating a bunch of lookup tables, using Doomsday Script dictionaries. The end result is a data structure that is completely Doomsday Script compatible, while also being efficient for native code to use directly (O(1) indexing, lookups in logarithmic time).

DED flags are a trivial case, as they simply contain an ID and a numerical value. Things get more interesting when considering the more complicated definitions. The current objective is to improve model definitions, so that’s where I’ll be focusing on.

Some of the old DED structs have ownership of Uri instances. In a Doomsday Script data structure, these become plain text strings.

One question is that should the next-gen model defs be completely separate from the old ones (in ded_t), or should the old model defs structure be upgraded to use a DEDRegister?

  • If kept separate, it is at least guaranteed that the old model renderer and its model packs will not regress.

  • If the old ones are upgraded, it is a step toward the ultimate objective of having a single next-gen model renderer doing all the work. This would mean that all code that accesses ded_model_t would need revising.

I’m inclined to leave the old model renderer as a fallback for now, to be used when legacy model packs are encountered. On the other hand, the old model renderer cannot be kept around for too long, as it lacks GL2 compatibility. The ultimate goal is to drop it and render old MD2/DMD models via the new mechanism, too.

Since DMD is a custom Doomsday format (an extension of MD2), it will fall on us to load it and prepare it into a format suitable for GL2 rendering. This shouldn’t be too big a problem, considering that ModelDrawable still only supports skinned models and not vertex animation — when implementing MD2 support, DMD import can be done as well.

I believe I’ll apply a mixed approach:

  • The model definitions will be fully upgraded to use DEDRegister for storage.

  • All next-gen models will use a redesigned format for their defs. Thanks to the flexibility of DEDRegister and Doomsday Script, the next-gen defs can be in the same array and lookup dictionaries, but their contents can be entirely different compared to the old ones. It is still necessary to have the definitions in Defs.models, though, as that is the way the rest of the engine expects the available models to be described.

  • The old renderer will hang around until the new one can draw vertex-animated models (MD2 and DMD).