Development Diary #000: Status of Exporter Development

[StjerneIdioten]

Hi there!

This is going to be the first entry in (hopefully) a series of development diaries, where I try to give a little bit of insight into features I am currently working on and the state of the exporter.

I've never tried to write anything like this before, but as I already keep track of these things, I thought I might share some of my thoughts with you guys as well. And give anyone the chance to provide input on the development process 😉

Rework of Exporter

So you might have been wondering "what's been going on with the exporter?" or you might not. New feature additions have been sparse for a while and this has partly been caused by me being busy (and vacations), but it is also due to a conscious decision to take a step back and look at the bigger picture of the exporter.

For a long time the development of the exporter has been chugging along smoothly and I've gotten to cover a lot of the basics and even some more advanced features (Like the shader-picker). As I've been implementing new stuff it is clear to me that a "technical debt" has started to grow and more and more workarounds have had to be implemented to facilitate new features. This stems mostly from the fact that the whole exporter project is "learning by doing" in more than one way. I've been learning how to use Blender, program Blender addons, advanced Python features, development processes (CI, documentation etc.) and most importantly how FS modding works in general. In particular I've had to figure out how i3d is structured and how things like mergegroups and skinned meshes work, since they weren't available in the original exporter (and thus it couldn't be used for inspiration for these features)

I am now at a point where I think it gives diminishing returns to continue working on the exporter with it current architecture and thus I've initiated a rework of the "core". This means that I've sat down and thought long and hard about how to restructure everything, to make it as easy to work with going forward.

This isn't the first time that a rework is made, the first time around was back in summer 2020, where I laid the foundation for the current architecture. It took the exporter from being a series of highly-coupled (experimental) python scripts to a more modular object-oriented approach. This time around I wish to reorganize the code into units that makes more sense and decouple the last few classes that are still a bit too bloated.

There has also been an increased interest for collaboration from different people, which further necessitates a proper documentation. As I do the rework I will update (or create) the documentation as I go along, to hopefully make it easier for anyone who wishes to help out. Just because everything is opensource and freely available to read, does not mean that it is easy to figure out if you aren't me 😉 And I wish to change this.

Plans

I don't have a timeline planned for this project yet, but it will take me a while to get everything put together in working order again. I do have the intention of updating the current version of the exporter with hotfixes if anything truly breaking gets discovered, but I won't implement any new features until I get this thing sorted out.

The following list is a short overview of some of the things I have planned for the rework, I won't go into too much detail in this developer diary, but rather save that for future ones:

• Decouple Blender from the Exporter Core code
  • To make support for multiple Blender and FS versions easier
  • It is a goal to still maintain the speed that the current implementation has
• Class diagrams and other software artifacts
  • To help with understanding of the code
  • To ease collaboration, if anyone are so inclined
• Unittests
  • To not accidentally break stuff all the time and make contributions easier with automated tests.

And as a little teaser I can show you the current state of the architectural documentation for the current non-reworked version. I had to make this diagram to give myself an overview of the whole project and it carries a few "custom" conventions that I invented myself to make it clearer and work well with the Python code. Most of it probably makes good sense if you are used to python, but might stick out like a sore thumb if you are used to class diagrams being simple and for communicating things during the design process 😆 Everything in red is variables/functions that I still need to draw dependency arrows for.

The image can be clicked to get a higher resolution version, where everything is clearly visible.
And I promise that any documentation for the new version will be less convoluted and more for actual collaboration purposes 😉

Next Time

For my next developer diary I will delve deeper into what progress I have made with this so far (Overviews of current architecture) and also go into more detail with how I am going to solve the problems I outlined, for the next iteration of the exporter.

That's my little update for anyone who might stumble in here and read this 😉 Hope you are understanding of where I am coming from and I am looking forward to try my best at making the best possible exporter for you guys 😄