mirror of
https://github.com/kaosat-dev/Blender_bevy_components_workflow.git
synced 2024-11-22 20:00:53 +00:00
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
53 lines
3.0 KiB
Markdown
53 lines
3.0 KiB
Markdown
- [x] seperate "spawn velocity" into a seperate (optional) component
|
|
- [x] try dynamically spawned entities with save & load
|
|
- [ ] fix issues with multiple entites having the same name ??
|
|
- [ ] fix issues with system ordering
|
|
- [x] add sets for proxy-replacements
|
|
- [x] 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
|
|
|
|
- [x] 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 |