Mod Support - Development Part 63

Video shows the summary, text shows the technical!

This week:

• Mod Support Plan Execution

• FBX Importer

Mod Support Plan Execution

So, mod support, one of the biggest cans of worms one can open for a game.

I have a very specific plan for what I will be supporting upon its first iteration. Given that I have 1 month to implement this feature, MyRobot's mod support will be for replacing models. This means that custom maps, scripts, etc. will be for much later!

So, models, this involves being able to change any body part of the robot. The goal is that you still need to "build" the robot, the parts are now just tailored visually to your liking.

So that's the plan for this month. In relation to Steam Workshop, I want to support it for the final build of the game (which is around the end of the year). This means that Workshop support won't be released this month and all community development mods etc. will be hosted entirely in the discord to gather feedback. It's better to make sure it works before launching a Workshop.

FBX Importer

So the best format I settled to create and share models for the game is .fbx. This is because you can convert many models (MMD, VRChat, whatever) and export as fbx, and you won't be tied down to Blender, you can even use Maya since it's a platform agnostic file type. It can include textures and everything a model needs to look good, minus shaders of course.

Importing FBXs at runtime is not natively supported by Unity so I had to roll out my own solution. There were tons of 'aha' moments and headaches overcame to produce a fast, easy, and near instant (27ms to spawn) algorithm that is multithreaded and doesn't explode memory.

There's still some boilerplate work needed including handling memory cleanup and some further optimizations but in general I can spawn skinned or static meshes in whichever hierarchy needed.

Now of course since I'm replacing robot body part models, the incoming models that will be imported will need to follow a strict set of rules (more on this next week), to properly replace a part. But the short gist of it is that the fbx will also include physics definitions and attributes to produce colliders and even dynamic wiggly jiggle bones for hair!

Into the Weeds:

The biggest pains of creating your own FBX importer is spreading workload across threads to reduce stuttering and also minding the memory handling gaps. The majority of the optimizations done with my importer was merely reducing the number of array copy calls. Many array copies were required since at some point you are working with a NativeArray that is thrown around multiple jobs. This involved doing pointers in C# (yuck) and sometimes marshalling objects to point and write to existing Unity functions. Overall just reducing copy calls amounted to 80% less time to process a model in the main thread for a Miku model that has 35k triangles and 450 bones.

Also, an FBX import is not the best format for immediate runtime gameplay. There will be a final FBX -> MyRobotFile that is more optimized for immediate spawning which will further reduce the 27ms stuttering and processing.

Stay tuned!