The gif above shows the first iteration of hot reloading assets, where for any asset that was originally authored in an external program such as Blender or Photoshop, the registry can dynamically reimport it as soon as the source file (fbx, dds) changes on disk. As an example, a mesh can be placed in the editor, then the source file watching on the asset be toggled, and whenever the fbx is changed on disk the engine reimports it with the same settings on the fly.
In the example we see a physics trigger getting a ScriptComponent referencing the test script asset we authored in the separate script editor. When the block suspended in the air above overlaps with the trigger volume, we change the mesh from a block to the clock mesh, and the green point light in the foreground is toggled off. This was set up to show interactions between a few separate entities, our so called data bindings, and a non-trivial entry point for the script (OnBeginOverlap, instead of a simple Tick for example).
We purposefully serialize our skeletal mesh animations down to our own data formats and run the math using those. Other solutions insteadmake a thin wrapper (or no wrapping at all) around imported assimp scenes, provided they are also working with assimp. I prefer our solutionas it gives us more control in implementing more advanced features such as inverse kinematics now that we’ve split up the logic into clear chunks.