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.
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
@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
@ivan what I want is also specifically meant to reload assets live in a running browser session, again same as unity. what I gather is that that's not a goal of what you are building?
@nasser ah yah its just for asset export the import on whatever the engine side would be handled on the engine side. But would be interesting to have a system for generic hooks to trigger running apps. Tho they can just watch the exported asset files
@ivan @nasser What triggers the build here? I'm curious because so far every live-reload thing I've built used inotify to watch for file updates, or Tup's FUSE overlay which does the same, only the "frontend" needed extra scripting so it didn't lose wipe its mutable state, there was no live-reload specific scripting in the asset editors.
@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.