NokiMo
DORFteam
DORFteam

patreon


End of February Update - More Lighting Shenanigans

Hello everyone,  

As mentioned in the last post, this month was mostly spent trying to port over tons of older assets to work within the parameters of the new rendering engine. While I had not gotten as many new assets in as I'd hoped, we did manage to further optimize the game engine, as the new rendering techniques and the large sprite sheets they required were massively increasing the game's load time.

Specifically, the older system simply had a singular types of sprite, which are displayed ingame as they appear on their sprite sheet, while the new system requires not only the obvious colored sprites (diffuse sprites), but tangent-space normal sprites and Z-depth sprites as well, effectively tripling the amount of sprites needed. We also needed to finally move to PNG files, replacing the extremely outdated SHP files (an absolutely ancient Westwood format that I simply used for temporary convenience). While the diffuse and Z-depth sprites are indexed, massively reducing their harddrive space footprint, these do present a problem in that, when the game initially boots, it must take every single sprite graphic in the game and place them into one gigantic sprite sheet. Initially, this system was not super optimized, and would not remove blank space from sprite sheets, meaning this megatexture could get absolutely bloated filling up with tons of wasted space.  

Thankfully, Gustas was quick to alter the sprite loader to account for sprites which have been "packed" (basically sprite sheets that have all the blank space chopped out), and updated DORF's utility tool to allow the game's sprite sheets to be embedded with metadata that determines the positioning of every sprite frame that has been packed within a sprite sheet. This data comes from a comercially-available tool we use called TexturePacker.

Now, if you want to see why all this might be necessary, here's a sprite with every potential frame of animation for the basic Imperial infantryman:



As you may gather, this massively trims down on sheet bloat; without this packing method, this sprite sheet was originally about 50,000 x 10,000 pixels in resolution. Obviously, not optimal at all.

I've also spent a lot of time altering the original infantry unit 3D scene to optimize it so that new infantry units can be rapidly created. Originally, I simply used separate 3D scenes in Maya Autodesk for every infantry unit type I needed to make, however given the massive amount of animation needed for every one, I seriously needed to make a more efficient method of doing this. So, I have spent time creating a generic animation template that accounts for the new rendering system (ie: needing to also render Z-depth and tangent-space normal sprites). This template also accounts for every possible animation type every infantry could use (standing, walking, running, attacking, attacking while prone, prone, crawling, various death animations, just to name a few...). It also standardizes certain things, such as walking animations always being 16 frames per rotation, firing animations being 8 frames, idle animations being 40 frames, etc. Previously, there was no standardization, so every infantry unit had its own complex web of different frame sequences that was a gigantic pain to deal wwith. With this system, I can basically just apply old animations to new infantry types, and just slightly tweak certain animations if the generic ones do not fit the new infantry units. Of course, most units will still at least need certain unique animations, such as specific attacking animations or idle animations.  

This is still a very, very lengthy process, and there is still a massive amount of work to be done. Now, for those that do want to see something a little more tangible, some work was also done on bringing most of the civilian buildings into the new system (see the attached video in the header).  More work still needs to be done to get things like the shadowing and positional light systems working; hopefully these will be done sometime in March.

More updates to come, and thank you all for sticking with us for this long.

Comments

Yes, that's essentially how all graphics in the game are made.

Henske

So do you mean you create the units as 3D models in Maya and from there convert them into sprites?

Harrison Varley

All data relevant to DORF is regularly backed up to an iDrive account every day at 6pm.

Henske

Tiene todo guardado en casó de que algo malo pase verdad?

Eduardo De Alba Cejudo


Related Creators