Just gonna post a little progress update on 0.5.X! While the update is not public yet, here's what's been done so far:
- Exporting and rendering ShapeKeys (or morph targets/blendshapes) has been implemented and tested and seems to work well! Note that there are some specific requirements and caveats for exporting them, due to some Blender restrictions
- Support for exporting all UV and color layers for meshes is done
- Various things in the exporter have been fixed/stabilized
- Made it possible to get the current output matrix of a bone, even while pose-caching is active (e.g. Allows characters holding objects in the right place without fully re-calculating the pose)
- A rewrite to how animations are handled is under way
- Made the system write much more useful info to the Blender Console (Window>Toggle System Console) and added the option of writing this info out to a file. This includes some export information (scene scale, left-handed conversion), as well as vertex format info, ShapeKey indices and what has been exported
- Changed the file format a lot. Uh-oh....
What are the caveats related to Shape Keys?
Well, the most major one is that Blender cannot apply modifiers to a mesh with Shape Keys, so I cannot apply modifies to such meshes. The reason seems to be that Blender applies modifiers to an imaginary mesh after applying the shapekeys to the base mesh, so results can vary wildly between Keys. The solution is to just make meshes without modifiers if you intend to use shape keys, though I plan to at least emulate the mirror modifier on export (and perhaps allow it to make mirrored shapekeys separate)
Another important thing to note is that ShapeKeys add more attributes to your vertex formats, so more specific shaders are necessary for each. The vertex formats needed are written to the Blender Console. Because of the need for these extra attributes, meshes can now also have individual vertex formats within a model, to reduce redundant data in meshes that don't use certain info and increase compatibility.
I know in software like Unity or Unreal you wouldn't need to make a shader for every single mesh, but that's because they already kinda do that for you. If the GameMaker IDE gets plugin support (which is looking less and less likely...) I'm considering making a tool that could generate all the shaders you need for your meshes from a base.
Animation re-write?
Yep, I'm changing how animations are handled. They are the main reason this kit exists, and they need an update. It's not a complete re-write, but the fundamentals are changing.
Why the change? As I was working on shape-key support, I realised it would be nice if we could also use animations that target values other than bone and object transforms. I then also realised the way I was writing was rather messy and wrote potentially incorrect values, and that the way they are stored and read could be greatly improved to hopefully improve accuracy, performance and provide more options.
This will basically give us a whole bunch of benefits:
- Animations will be more accurate between Blender and GameMaker
- Animation code should be simplified and easier to maintain
- Automatic caching of some values should be easier, to make animation driving more performant (Even without pose-caching)
- Interpolation Modes of individual keyframes can be written and interpreted, allowing more accurate animation without baking frames (Except bezier, for now)
- Animations that do not affect certain properties of a transform will not reset it.
- Hopefully, this will allow a dual-quaternion skinning mode to be activated, to improve performance, increase bone-count limits and preserve volume (this will be optional, but quite handy - especially on mobile platforms)
This requires a change to both the export, the import and how animations and bones are stored and handled and requires me to update the C++ code as well as the GML. It should be worth it though!
File Format Changes?
As I was working on shapekeys and animations, I realized the way the files were written was fundamentally flawed. It worked for the originally intended purpose, but as I've been adding these features, it became clear that it just wasn't expandable. The new format means that if I need to change or add features, it is far easier and does not require a re-write of any systems. Note that trying to load a new feature into an older MMK thing will abort the import and only load the features written before it.
Luckily, the files have always had a "Version" value written as the first entry, which does mean that the system can detect and load files using the current, soon-to-be-outdated format, they just don't have access to the newer features, and the current version of MMK will be unable to load the newer files (it WILL crash, as I never made it check if the version was 0 or not). Eventually, loading of "Version 0" files will be removed, but for now I will try to keep it working. This is just one of the effects of this being a Beta.
Since this file-format seems more final, too, I can also document it in case anyone wants to load them into other software.
OK! Update over. This is sorta rough since it's just what I'm doing and thoughts about it, but I felt like writing it. Love you bye