like what you are "supposed" to do when making games is have some kind of a pipeline of multiple programs set up, so that you are making 3D art in one place, to the art in another place, combining them somehow, loading them into an engine, loading code into the engine, etc etc.

it's not a totally broken approach, and it's very flexible, but it definitely has more friction to it than everything being in one place.

hmm maybe I should investigate building something like what unity has, where it watches asset files for changes and automatically reruns an importer. the amount of friction introduced by needing to hit export in blender and refreshing the engine is surprisingly high.

thinking out loud, and this is just for the web shit i do, it might be a simple as an "asset server" you run locally that watches a bunch of files for changes and runs a command line command to convert them for the web if needed (eg trigger blender GLTF export) and then front-end code that can watch files served by the asset server and run code when it changes to reload the assets live.

@nasser this is pretty much the asset management tool i'm building with Igal

@ivan wait really? aren't you supporting versioning and other advanced stuff? what I'm thinking of is dead simple

@nasser yeah it has a bunch of version control stuff but part of the functionality is defining scripts to automatically export assets when their source files change (blender currently).

@ivan yeah on my mind from my experience it's blender GLTF export and texture packer PNG/JSON export. blender can definitely be figured from the command line.

@nasser Yeah we have a bunch of scripts currently that it runs via headless blender command line, but ya anything that can be run as a command can be used