3D model rendering for 2.0
As previously planned, now that the stable 1.15 release has been dealt with, I've been continuing work on the new 3D model renderer. Here's an update on what I've been doing.
In 1.15, it was only possible to use the new model renderer with world objects, i.e., things in the map. Now I've added a new asset type to render player weapon models (psprites). The new renderer handles models at a higher level of abstraction (no longer at the level of individual states) so I had to define some new information to make the engine aware of when the current weapon changes. However, the engine is only given a text string ID that is then used to locate the model asset — nothing else about the weapon or its behavior needs to be provided to the renderer. To define these player weapon IDs I've taken advantage of the old Values DEDs that make it possible to specify free-form text string data. Some of the weapon parameters were already in a Values section called "Weapon Info". I've now added weapon IDs for all games in their Values.
Player weapon models can be animated in the same way as world objects. In other words, you can define which psprite states trigger which animation sequences in the model. You can also specify animation variants, so for instance each attack animation does not have to be exactly the same.
A completely new feature that I added is animation looping. For each triggered animation sequence, you can define whether the sequence should loop or not. Looping also supports variants, so every iteration of the loop may select a different variant of the animation, which can greatly reduce robotic repetitions in walking animations, for instance.
Another new feature is manually defining the rendering passes and order for the meshes in the model. For example, consider a weapon model with the object itself being the first mesh, with a second separate mesh used for flashes and other visual effects. The main mesh should be rendered with normal alpha blending, while the visual effects need to glow so they must be drawn with additive blending. These rendering instructions can now be freely defined in the model asset's metadata, on a per mesh basis. Currently parameters are only offered for blending, however other GL state parameters can easily be added in the future.
Related to the player weapon models, I've also been paying attention to the accuracy of specular highlights. With a model right in front of your face, it is expected that surfaces on the model will more or less accurately reflect lights in the immediate surroundings. There are a few nuts and bolts that need changing under the hood so that light positions can be passed to the model shader, but already the specular highlights are working quite nicely. You can see a brief YouTube video showing what's happening here.
Finally, I've been doing some infrastructure improvements regarding "DED 2.0" (i.e. ScriptedInfo) by slightly simplifying the required syntax (the "group" keyword is no longer required when defining groups), and making it possible to inherit members directly from sibling definitions without having to spell out the complete path of the data. (See the wiki for examples.) Also, a good portion of my time has been spent refactoring and cleaning up the new model renderer to facilitate all the new features listed above.
In 1.15, it was only possible to use the new model renderer with world objects, i.e., things in the map. Now I've added a new asset type to render player weapon models (psprites). The new renderer handles models at a higher level of abstraction (no longer at the level of individual states) so I had to define some new information to make the engine aware of when the current weapon changes. However, the engine is only given a text string ID that is then used to locate the model asset — nothing else about the weapon or its behavior needs to be provided to the renderer. To define these player weapon IDs I've taken advantage of the old Values DEDs that make it possible to specify free-form text string data. Some of the weapon parameters were already in a Values section called "Weapon Info". I've now added weapon IDs for all games in their Values.
Player weapon models can be animated in the same way as world objects. In other words, you can define which psprite states trigger which animation sequences in the model. You can also specify animation variants, so for instance each attack animation does not have to be exactly the same.
A completely new feature that I added is animation looping. For each triggered animation sequence, you can define whether the sequence should loop or not. Looping also supports variants, so every iteration of the loop may select a different variant of the animation, which can greatly reduce robotic repetitions in walking animations, for instance.
Another new feature is manually defining the rendering passes and order for the meshes in the model. For example, consider a weapon model with the object itself being the first mesh, with a second separate mesh used for flashes and other visual effects. The main mesh should be rendered with normal alpha blending, while the visual effects need to glow so they must be drawn with additive blending. These rendering instructions can now be freely defined in the model asset's metadata, on a per mesh basis. Currently parameters are only offered for blending, however other GL state parameters can easily be added in the future.
Related to the player weapon models, I've also been paying attention to the accuracy of specular highlights. With a model right in front of your face, it is expected that surfaces on the model will more or less accurately reflect lights in the immediate surroundings. There are a few nuts and bolts that need changing under the hood so that light positions can be passed to the model shader, but already the specular highlights are working quite nicely. You can see a brief YouTube video showing what's happening here.
Finally, I've been doing some infrastructure improvements regarding "DED 2.0" (i.e. ScriptedInfo) by slightly simplifying the required syntax (the "group" keyword is no longer required when defining groups), and making it possible to inherit members directly from sibling definitions without having to spell out the complete path of the data. (See the wiki for examples.) Also, a good portion of my time has been spent refactoring and cleaning up the new model renderer to facilitate all the new features listed above.