DMD ver2 (post Beta4)
<i>This post was originally made by <b>danij</b> on the dengDevs blog. It was posted under the category: Engine.</i>
Currently the biggest issue I have with models in Doomsday is the problem of "vertex swimming" with animated models (caused by the vertex coords being reduced to bytes when saving a model in the DMD/MD2 format).
It is due to this inaccuracy that creating good model animations becomes almost impossible with the DMD/MD2 model formats. Good examples would be the idle animations for any of HUD models in jDRP1.01 which suffer badly because of this.
Ideally I would love to see full MD3 support in Doomsday, making use of tags for animation and intergrating Quake3 style "shaders" but I understand that there is a huge amount of work involved, something which is not really practical atm.
I would like to propose an interim solution that would solve the immediate problem of "vertex swimming".
As Doomsday already converts the vertex coords to floating point when reading the model formats for internal use, all we really need to eliminate this problem is a new DMD version 2 format which stores the vertexes in floats. There should be only minor changes needed to Doomsday for this.
The other requirement to make this happen is the ability for md2tool to read another model format (which stores the vertex coords in floats obviously) and then output the model to this newer DMD ver2 format. MD3 would make the most sense I suppose but instead of honouring the built-in vertex tags - md2tool would simply concatenate the tagged geometry into one set of verts per frame (as in the exisiting DMD/MD2 formats).
What are your thoughts on this?
Currently the biggest issue I have with models in Doomsday is the problem of "vertex swimming" with animated models (caused by the vertex coords being reduced to bytes when saving a model in the DMD/MD2 format).
It is due to this inaccuracy that creating good model animations becomes almost impossible with the DMD/MD2 model formats. Good examples would be the idle animations for any of HUD models in jDRP1.01 which suffer badly because of this.
Ideally I would love to see full MD3 support in Doomsday, making use of tags for animation and intergrating Quake3 style "shaders" but I understand that there is a huge amount of work involved, something which is not really practical atm.
I would like to propose an interim solution that would solve the immediate problem of "vertex swimming".
As Doomsday already converts the vertex coords to floating point when reading the model formats for internal use, all we really need to eliminate this problem is a new DMD version 2 format which stores the vertexes in floats. There should be only minor changes needed to Doomsday for this.
The other requirement to make this happen is the ability for md2tool to read another model format (which stores the vertex coords in floats obviously) and then output the model to this newer DMD ver2 format. MD3 would make the most sense I suppose but instead of honouring the built-in vertex tags - md2tool would simply concatenate the tagged geometry into one set of verts per frame (as in the exisiting DMD/MD2 formats).
What are your thoughts on this?
Comments
I have been thinking that when we have model decorations, it will become absolutely necessary to let the GPU handle most of the work of rendering the models. Thus I think we should move to a vertex shader + fragment shader combo that gives us GPU-powered animations and per-pixel lighting for all the models (and who knows, maybe skeletal animation, too, one day).
This should be discussed in more detail once Beta 4 is out of the way and we can decide what we want to do with Beta 5. When it comes to the betas, though, we should concentrate on the disruptive features only (like the savegames). Model rendering is a feature internal to the engine and thus can be dealt with in post-1.9.0 releases, and not the 1.9.0 betas.
Certainly, offloading most of the transform work onto the GPU would definetly help address the balance (given that Doomsday is currently very much CPU powered) and make better use of modern systems.