528e13a250
* feat(bevy_gltf_components): * create crate * added SystemSet (GltfComponentsSet) to run process_loaded_scenes (where components are injected) in a specific systemset & allow ordering other systems relative to it * feat(bevy_gltf_blueprints): * created crate * made the blueprint library path configurable * added BluePrintBundle helper * added SystemSet (GltfBlueprintsSet) for better system ordering * integrated into advanced demo * feat(tools-blender-auto-export): * renamed blender tool to gltf_auto_export * rewritten auto_export * added blueprint / prefab support * creates scene with empties with BlueprintName components in the scene * export of the main scene now exports this scene instead of real main scene * changes collection stand in names in original scene & sets them back after export to have correctly named collection instance exports * also added an additional 'SpawnHere' component to not conflate BlueprintNames & spawning requests * toggling & blueprint library output parameters added * added correct handling/ restoring of saved selection when using blueprints * feat(examples): * added advanced example * general example renamed to "basic", and cleaned up * feat(various): a lot of experiments with saving & loading etc * chore(assets): updated blend & generated assets * fix(examples-advanced): disabling hot reloading as it messes up scenes in experiments with save & loading * docs(): * added & fleshing out docs for the various crates & main README * added process doc image & tweaks to README * added missing licence info where relevant * fixed broken links * clarified some aspects * added updated screenshots where relevant * added tweaks & improvements etc
3.0 KiB
-
seperate "spawn velocity" into a seperate (optional) component
-
try dynamically spawned entities with save & load
-
fix issues with multiple entites having the same name ??
-
fix issues with system ordering
- add sets for proxy-replacements
-
annoying camera movement : camera should be saveable as well => we need to be able to only save the camera position (and name)
-
only spawn "new level" stuff when transitioning from menu to game ? - [ ] put more thoughts into this
-
rework how save-loading is triggered - [ ] no hardcoded keypresses - [ ] ability to choose what save to load ? - [ ] take a look at bevy_moonshine_save - [ ] move to system pipelines
-
split Blueprints into a seperate crate: perhaps bevy_gltf_blueprints - [x] how to deal with states that are not defined as part of the plugin/crate ? - [x] same issue for the assets
-
support multiple main scenes in the blender plugin ?
-
study possibilities of expanding the bevy & blender tooling side to define UIS - likely using the blender data only as a placeholder/ directly replace in Python
-
system ordering ? load level => inject components => spawn blueprint entities/rehydrate => (loading) => replace proxies OR load level => inject components => (loading) => spawn blueprint entities/rehydrate => replace proxies
-
perhaps it does make more sense to save ALL entities and not just the dynamic ones? mostly as we have the blueprints anyway, which should cut down on needed data ?
-
different approaches for dealing with saving/loading in particular the problem of entites that are defined as part of the level but can be despawned (items that get picked up etc)
Bevy side
-
var 1 : spawn all entities completely, despawn those saveables that are not actually present in the save data but that have been spawned * problems: needs correct ordering of systems otherwise the diffing above will not work * pros: minimal save files, only bevy boilerplate * cons: requires spawning potentially huge gltf files just to "peek" inside of them to know if they are saveable
-
var 2 : save both saveables & unsaveables but only save the absolute minimal data for unsaveables * problems: how to combine different filters into a single save file ? * pros: easier diffing, more homogeneous handling * cons: a lot bigger save file with mostly useless data
Blender side
- var 3 => CHOSEN OPTION : mark INSTANCES in advance as static/dynamic (ie saveable or not), thus this data would be present in the world/level and not inside the gltf data * problems: would require adding custom properties to each instance in Blender (COULD be automated by 'peeking' inside the collection) * pros: simpler, and this might be more "editor-like" where you would mark each item as static or not * cons: potentially a lot of manual work / error prone
-