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
@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).
@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 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?