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.
@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
@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 wait really? aren't you supporting versioning and other advanced stuff? what I'm thinking of is dead simple