Right now, the toolchain requiring specific versions of blender, running a separate add-on, "prone to crashing when creating materials" to export a *.glb file that contains references to but doesn't contain the texture(s) used is very difficult to work with. Frequent crashes and export errors without error feedback make the entire process unreliable and frustrating, as well as slowing down iteration time.
An ideal solution might be a separate, in-editor asset that references the generic model (*.obj, *.fbx, *.glb, etc formats supported) and the texture(s) to be sampled, as well as the user-selected settings that would guide the microcode generation, analogous to the Fast-64 settings. The visuals would be simulated in-editor, giving users a version of what will appear in-game. Then, during build, the microcode would be generated and used in the ROM.
I'm aware this is a pretty large ask, but after wrestling with Blender and Fast-64, it feels like a stumbling block in the engine's design.
Right now, the toolchain requiring specific versions of blender, running a separate add-on, "prone to crashing when creating materials" to export a *.glb file that contains references to but doesn't contain the texture(s) used is very difficult to work with. Frequent crashes and export errors without error feedback make the entire process unreliable and frustrating, as well as slowing down iteration time.
An ideal solution might be a separate, in-editor asset that references the generic model (*.obj, *.fbx, *.glb, etc formats supported) and the texture(s) to be sampled, as well as the user-selected settings that would guide the microcode generation, analogous to the Fast-64 settings. The visuals would be simulated in-editor, giving users a version of what will appear in-game. Then, during build, the microcode would be generated and used in the ROM.
I'm aware this is a pretty large ask, but after wrestling with Blender and Fast-64, it feels like a stumbling block in the engine's design.