feat(Blenvy):

* added some material helpers (wip)
 * copied over old docs & images from old add-ons
This commit is contained in:
kaosat.dev 2024-06-10 13:58:30 +02:00
parent 2f7f3024d9
commit 763a520b32
66 changed files with 900 additions and 1 deletions

View File

@ -0,0 +1,277 @@
# gltf_auto_export
This [Blender addon](./)
- automatically exports your level/world from Blender to gltf whenever you save your Blend file.
- in Blueprints mode (highly recommended !) :
- supports automatic exports of used collections as [Gltf blueprints](../../crates/bevy_gltf_blueprints/README.md)
- supports any number of main/level scenes
- Blender scenes where you define your levels, and all collection instances are replaced with "pointers" to other gltf files (all automatic)
- supports any number of library scenes
- Blender scenes where you define the assets that you use in your levels, in the form of collections
- automatic export of **changed** objects & collections only ! a sort of "incremental export", where only the changed collections (if in use)
get exported when you save your blend file
## Installation:
* grab the latest release zip file
![blender addon install](./docs/blender_addon_install_zip.png)
* in Blender go to edit => preferences => install
![blender addon install](./docs/blender_addon_install.png)
* choose the path where ```gltf_auto_export.zip``` is stored
![blender addon install](./docs/blender_addon_install2.png)
## Usage:
> ***IMPORTANT***
if you have used a version of this add-on prior to v0.9, there was an issue that kept generating orphan (junk) data on every save !
You can easilly clean up that data
- go to orphan data:
![purge orphan data](./docs/purge_orphan1_data1.png)
- click on purge
![purge orphan data](./docs/purge_orphan1_data2.png)
- validate
![purge orphan data](./docs/purge_orphan1_data3.png)
This issue has been resolved in v0.9.
### Basics
* before it can automatically save to gltf, you need to configure it
* go to file => export => gltf auto export
![blender addon use](./docs/blender_addon_use.png)
* set the autoexport parameters in the **auto export** panel:
![blender addon use3](./docs/blender_addon_use3.png)
- export folder: root folder to export models too
- export scene settings: exports "global"/scene settings like ambient color, bloom, ao, etc
This automatically generates additional components at the scene level
- pick your main (level) scenes and/or library scenes (see the chapter about [Blueprints](#blueprints) and [multiple Blend filles workflow](#multiple-blend-file-workflow) below)
- click in the scene picker & select your scene
![select scene](./docs/blender_addon_add_scene.png)
- click on the "+" icon
![select scene2](./docs/blender_addon_add_scene2.png)
- your scene is added to the list
![select scene3](./docs/blender_addon_add_scene3.png)
- export blueprints: check this if you want to automatically export blueprints (default: True)
- blueprints path: the path to export blueprints to , relative to the main **export folder** (default: library)
- collection instances: select which option you want to use to deal with collection instances (aka combine mode) (both inside blueprint collections & main collections)
* split (default, highly recomended) : the addon will 'split out' any nested collections/ blueprints & export them
* embed: choose this option if you want to keep everything inside a gltf file (less efficient, not recomended)
* embedExternal: this will embed ONLY collection instances whose collections have not been found inside the current blend file
These options can also be **overridden** on a per collection instance basis: (if you want to split out most collection instances, but keep a few specific ones embeded
inside your gltf file)
![combine override](./docs/combine_override.png)
- simply add a custom property called **_combine** to the collection instance, and set it to one of the options above
please read the dedicated [section](#collection-instances--nested-blueprints) below for more information
- Export dynamic and static objects seperatly : For MAIN scenes only (aka levels), toggle this to generate 2 files per level:
- one with all dynamic data: collection or instances marked as dynamic (aka saveable)
- one with all static data: anything else that is NOT marked as dynamic, the file name will have the suffix **_dynamic**
Ie if you add a "Dynamic" custom property/ component to either your collection instances or your blueprint, you get a clean seperation between
- your static level data (anything that will never change during the lifetime of your Bevy app)
- your dynamic objects (anything that will change during the lifetime of your Bevy app, that can be saved & reloaded in save files for example)
- export materials library: check this if you want to automatically export material libraries (default: False)
please read the dedicated [section](#materials) below for more information
> This only works together with blueprints !
- materials path: where to export materials to
* and your standard gltf export parameters in the **gltf** panel
![blender addon use2](./docs/blender_addon_use2.png)
* click on "apply settings"
* now next time you save your blend file you will get an automatically exported gltf file (or more than one, depending on your settings, see below)
### Blueprints
You can enable this option to automatically replace all the **collection instances** inside your main scene with blueprints
- whenever you change your main scene (or your library scene , if that option is enabled), all your collection instances
* will be replaced with empties (this will not be visible to you)
* those empties will have additional custom properties / components : ```BlueprintName``` & ```SpawnHere```
* your main scene/ level will be exported to a much more trimmed down gltf file (see next point)
* all the original collections (that you used to create the instances) will be exported as **seperate gltf files** into the "library" folder
- this means you will have
* one small main gltf file (your level/world)
* as many gltf files as you have used collections in the main scene , in the library path you specified :
for the included [basic](../../examples/bevy_gltf_blueprints/basic/) example's [assets](../../examples/bevy_gltf_blueprints/basic/assets/), it looks something like this:
![library](./docs/exported_library_files.png)
the .blend file that they are generated from can be found [here](../../examples/bevy_gltf_blueprints/basic/assets/advanced.blend)
- the above only applies to collections that have **instances** in your main scene!
if you want a specific collection in your library to always get exported regardless of its use, you need to add
a **COLLECTION** (boolean) custom property called ```AutoExport``` set to true
> not at the object level ! the collection level !
![force-export](./docs/force_export.jpg)
It will get automatically exported like any of the "in-use" collections.
- you can also get an overview of all the exported collections in the export menu
![exported collections](./docs/exported_collections.png)
- there are some workflow specificities for multi blend file [workflows](#multiple-blend-file-workflow)
#### Collection instances & Nested blueprints
To maximise reuse of meshes/components etc, you can also nest ***collections instances*** inside collections (as normally in Blender), but also export each nested Blueprint as a seperate blueprints.
> Don't forget to choose the relevant option in the exporter settings (aka **"split"**)
> This replaces the previous "export nested blueprints" checkbox/ option
![instance combine mode](./docs/blender_addon_use4.png)
- To make things clearer:
![nested-blueprints](./docs/nested_blueprints.png)
- **Player2** & **Enemy** both use the **Humanoid_cactus** nested collection/blueprint, so **Humanoid_cactus** gets exported as a Blueprint for re-use ...but
- **Humanoid_cactus** is also made up of a main mesh & two instances of **Hand** , so **Hand** gets exported as a Blueprint for re-use ...but
- **Hand** is also made up of a main mesh & three instances of **Finger**, so **Finger** gets exported as a Blueprint for re-use
- The exported models in this case end up being:
![nested_blueprints2](./docs/nested_blueprints2.png)
- Note how **Player2.glb** is tiny, because most of its data is actually sotred in **Humanoid_cactus.glb**
- **Enemy.glb** is slightly bigger because that blueprints contains additional meshes
- All the intermediary blueprints got exported automatically, and all instances have been replaced with "empties" (see explanation in the **Process section** ) to minimize file size
- Compare this to the output **WITHOUT** the nested export option:
![nested_blueprints3](./docs/nested_blueprints3.png)
- less blueprints as the sub collections that are not in use somewhere directly are not exported
- **Player2.glb** & **Enemy.glb** are significantly larger
TLDR: smaller, more reuseable blueprints which can share sub-parts with other entities !
### Materials
You can enable this option to automatically generate a **material library** file that combines all the materials in use in your blueprints.
![material_library](./docs/blender_addon_materials2.png)
Since each blueprint is normally a completely independant gltf file, without this option, if you have a material with a large texture for example,
**ALL** of your blueprints using that material will embed that large texture, leading to **significant bloat & memory use**.
- When this option is enabled, you get a single material library per Blender project, and a **MaterialInfo** component is inserted into each object using a material.
- The correct material will then be inserted on the Bevy side (that loads any number of material libraries that you need) into the correct mesh (see the configuration
options in **bevy_gltf_blueprints** for more information on that)
- Only one material per object is supported at this stage, ie the last material slot's material is the one that is going to be used
![material_library](./docs/blender_addon_materials.png)
TLDR: Use this option to make sure that each blueprint file does not contain a copy of the same materials
### Multiple blend file workflow
If you want to use multiple blend files, use Blender's asset library etc, we got you coverred too !
There are only a few things to keep in mind
#### Assets/library/blueprints files
- mark your library scenes as specified above, but **do NOT** specify a **main** scene
- mark any collection in your scenes as "assets" (more convenient) or add the "AutoExport" custom property to the collection
- choose "split" for the combine mode (as you want your gltf blueprints to be saved for external use)
- do your Blender things as normal
- anytime you save your file, it will automatically export any relevant collections/blueprints
- (optional) activate the **material library** option, so you only have one set of material per asset library (recomended)
#### Level/world files
- mark your main scenes as specified above, but **do NOT** specify a **library** scene
- configure your asset libraries as you would usually do , I recomend using the "link" mode so that any changes to asset files are reflected correctly
- drag & drop any assets from the blueprints library (as you would normally do in Blender as well)
- choose "split" for the combine mode (as you want your gltf blueprints to be external usually & use the gltf files generated from your assets library)
- do your Blender things as normal
- anytime you save your file, it will automatically export your level(s)
Take a look at the [relevant](../../examples/bevy_gltf_blueprints/multiple_levels_multiple_blendfiles/) example for more [details](../../examples/bevy_gltf_blueprints/multiple_levels_multiple_blendfiles/art/)
### Internal Process overview
This is the internal logic of the export process with blueprints (simplified)
![process](./docs/process.svg)
ie this is an example scene...
![](./docs/workflow_original.jpg)
and what actually gets exported for the main scene/world/level
![](./docs/workflow_empties.jpg)
all collections instances replaced with empties, and all those collections exported to gltf files as seen above
## Development
- since the code has now been split up into multiple modules, to make your life easier, I highly recomend (if you are using vscode like me) to use
[this](https://marketplace.visualstudio.com/items?itemName=JacquesLucke.blender-development) excellent extension , works easilly and fast , even for the latest
versions of Blender (v4.0 as of this writing)
- this [article](https://polynook.com/learn/set-up-blender-addon-development-environment-in-windows) might also help out
(easy enough to get it working on linux too)
## License
This tool, all its code, contents & assets is Dual-licensed under either of
- Apache License, Version 2.0, ([LICENSE-APACHE](../LICENSE_APACHE.md) or https://www.apache.org/licenses/LICENSE-2.0)
- MIT license ([LICENSE-MIT](../LICENSE_MIT.md) or https://opensource.org/licenses/MIT)

View File

@ -0,0 +1,297 @@
# Bevy components
This [Blender addon](https://github.com/kaosat-dev/Blender_bevy_components_workflow/tree/main/tools/bevy_components) gives you an easy to use UI to add and configure your [Bevy](https://bevyengine.org/) components inside Blender !
- **automatically generates a simple UI** to add/configure components based on a **registry schema** file (an export of all your Bevy components's information, generated)
by the [bevy_registry_export](https://crates.io/crates/bevy_registry_export) crate/plugin
- no more need to specify components manually using custom_properties, with error prone naming etc
- adds **metadata** to objects containing information about what components it uses + some extra information
- uses Blender's **PropertyGroups** to generate custom UIs & connects those groups with the custom properties so that no matter the complexity
of your Bevy components you get a nicely packed custom_property to use with ...
- the ideal companion to the [gltf_auto_export](https://github.com/kaosat-dev/Blender_bevy_components_workflow/tree/main/tools/gltf_auto_export) to embed your Bevy components inside your gltf files
<!-- - adds the ability to **toggle components** on/off without having to remove the component from the object -->
> Important:
the tooling is still in the early stages, even if it is feature complete : use with caution!.
> IMPORTANT !! if you have previously used v0.1 , v0.2 had a breaking change, please see [this](#regenerate-ui-values) section on how to upgrade your data to v0.2.\
This problem should not be present going forward
> IMPORTANT !! if you have previously used v0.2 , v0.3 had a breaking change, please see [this](#regenerate-custom-property-values) section on how to upgrade your data to v0.3.
## Installation:
* grab the latest release zip file from the releases tab (choose the bevy_components releases !)
<!--![blender addon install](./docs/blender_addon_install_zip.png)-->
* in Blender go to edit => preferences => install
![blender addon install](./docs/blender_addon_install.png)
* choose the path where ```bevy_components.zip``` is stored
![blender addon install](./docs/blender_addon_install2.png)
## Configuration & overview
Before you can use the add-on you need to configure it
### Bevy side
- setup [bevy_registry_export](https://crates.io/crates/bevy_registry_export) for your project (see the crate's documentation for that), and compile/run it to get the ```registry.json``` file
### Blender side
- Go to the new Bevy Components tab in the 3D view
![configuration](./docs/configuration.png)
- click on the button to select your registry.json file (in the "configuration" panel)
![configuration 2](./docs/configuration2.png)
- the list of available components will appear
![configuration 3](./docs/configuration3.png)
#### registry file polling
* by default, the add-on will check for changes in your registry file every second, and refresh the UI accordingly
* you can set the polling frequency or turn it off if you do not want auto-refresh
![registry file polling](./docs/registry_polling.png)
## Use
### Existing components & custom properties
* If you already have components defined manualy in Blender inside **custom properties** you will need to define them again using the UI!
* avoid mixing & matching: if you change the values of **custom properties** that also have a component, the custom property will be **overriden** every time
you change the component's value
* you can of course still use non component custom properties as always, this add-on will only impact those that have corresponding Bevy components
### adding components
- to add a component, select an object and then select the component from the components list: (the full type information will be displayed as tooltip)
![components list](./docs/components_list.png)
- click on the dropdown to get the full list of available components
![components list](./docs/components_list2.png)
- you can also filter components by name for convenience
![filter components](./docs/filter_components.png)
- add a component by clicking on the "add component" button once you have selected your desired component
it will appear in the component list for that object
![add component](./docs/add_component.png)
### edit components
- to edit a component's value just use the UI:
![edit component](./docs/edit_component.png)
it will automatically update the value of the corresponding custom property
![edit component](./docs/edit_component2.png)
### Create components from custom properties
- IF you have a valid component type and the correct corresponding RON string in the custom_property value (this button will not appear if not), this add-on can automatically
generate the corresponding component for you:
- Fill/check your custom property (here for Aabb)
![generate_components 2](./docs/generate_components2.png)
- click on the button
![generate_components](./docs/generate_components.png)
-voila !
![generate_components 3](./docs/generate_components3.png)
### copy & pasting
- you can also copy & paste components between objects
- click on the "copy component button" of the component you want to copy
![copy component](./docs/copy_component.png)
- then select the object you want to copy the component (& its value) to, and click on the paste button.
It will add the component to the select object
![paste component](./docs/paste_component.png)
> if the target object already has the same component, its values will be overwritten
## Additional components UI features
- for large/ complex components you can toggle the details of that component:
![toggle details](./docs/toggle_details.png)
## Supported components
- normally (minus any bugs, please report those!) all components using **registered** types should be useable and editable
- this includes (non exhaustive list):
* enums (even complex ones !)
![enums](./docs/enums.png)
![enums](./docs/enums2.png)
* complex structs, with various types of fields (including nested ones)
![complex](./docs/complex_components2.png)
* lists/ vecs (here a vec of tuples)
![lists](./docs/vecs_lists.png)
* etc !
## Unregistered types & error handling
- non registered types can be viewed in this panel : (can be practical to see if you have any missing registrations too!)
![unregistered types](./docs/unregistered_types.png)
- if you have a component made up of unregistered structs/enums etc, you will get visual feedback & the component will be deactivated
![invalid component](./docs/invalid_components.png)
> see [here](#invalidunregistered-type-renaming--conversion) for ways to convert invalid / unregistered components to other types.
- if you are encountering this type of view: don't panic your component data is not gone ! It just means you need to reload the registry data by clicking on the relevant button
![missing registry data](./docs/missing_registry_data.png)
## Advanced Tools
In this section you will find various additional more advanced tooling
### Invalid/unregistered type renaming / conversion
If you have components that are
* invalid : ie some error was diagnosed
* unregistered: a custom property is present on the object, but there is no matching type in the registry
Here you will get an overview, of ALL invalid and unregistered components in your Blender project, so you can find them, rename/convert them,
or delete them, also in bulk
![component rename overview](./docs/component_rename_overview2.png)
* you can click on the button to select the object in your outliner (this also works across scenes, so you will be taken to the scene where the
given object is located)
![update custom properties](./docs/component_rename_object_select.png)
#### Single object component renaming/ conversion
- to rename/convert a single component for a single object:
* go to the row of the object you want to convert the component of
* in the dropdown menu, choose the target component
* click on the button with the magic wand to convert the component
![single rename](./docs/component_rename_single.png)
> the tool will attempt to automatically convert the source component, including the field names/values, if the target component has the same ones
If it fails to do the conversion, you will get an error message, and you will either have to change the custom property yourself, or you can simply
change the values in the UI, which will automatically generate the custom property value
- to delete a single component for a single object:
* go to the row of the object you want to remove the component from
* click on the button with the "x" to remove the component
![single delete](./docs/component_remove_single.png)
#### Bulk component renaming/ conversion
- use this method if you want to convert ALL components of a given type of ALL objects
* click on this button to pick your source component
![bulk convert remove](./docs/component_rename_remove_bulk.png)
* for conversion: in the dropdown menu, choose the target component & click apply to convert all matching components
* for deletion: clic on the "x" to remove all matching components
![bulk convert remove](./docs/component_rename_remove_bulk2.png)
### For conversion between custom properties & components & vice-versa
#### regenerate custom property values
- "update custom properties of current object" : will go over **all components** that you have defined for the **currently selected object**, and re-generate the
corresponding custom property values
![update custom properties](./docs/other_options.png)
- "update custom properties of ALL objects" : same as above but it will do so for the **ALL objects in your blend file** (so can be slow!), and re-generate the
corresponding custom property values
![update custom properties for all](./docs/other_options2.png)
> IMPORTANT !! use this if you have previously used v0.1 or v0.2 , as v0.3 had a breaking change, that makes it **necessary** to use this **once** to upgrade components data
You should also re-export your gltf files , otherwise you might run into issues
#### regenerate component/ UI values
- since v0.2, you have the option to regenerate (for the selected object or all objects, as above) to regenerate your UI values from the custom property values
![update UI FROM custom properties](./docs/update_ui_from_custom_properties.png)
> IMPORTANT !! use this if you have previously used v0.1 , as v0.2 had a breaking change, that makes it **necessary** to use this **once** to upgrade the UI data
> Note: the legacy mode support has been removed since version
## Examples
you can find an example [here](https://github.com/kaosat-dev/Blender_bevy_components_workflow/tree/main/examples/bevy_registry_export/)
## Known issues & limitations:
* **Range** data (ie ```Range<f32>``` etc) are not handled at this time (issue seems to be on the Bevy side)
* **Entity** structs are always set to 0 (setting entity values on the Blender side at this time does not make much sense anyway)
## License
This tool, all its code, contents & assets is Dual-licensed under either of
- Apache License, Version 2.0, ([LICENSE-APACHE](../LICENSE_APACHE.md) or https://www.apache.org/licenses/LICENSE-2.0)
- MIT license ([LICENSE-MIT](../LICENSE_MIT.md) or https://opensource.org/licenses/MIT)

View File

@ -0,0 +1,69 @@
- investigate remove_blueprints_list_from_main_scene (could be a case of changes to bpy.data not being applied immediatly)
- investigate clearing of changed_objects_per_scene
- it seems bevy_components does not trigger updates
- undo redo is ignored: ie save, do something, undo it, you still get changes
- [ ] serialize scene
- [ ] for collection instances:
* [ ] blueprints export should also take the split/embed mode into account: if a nested collection changes AND embed is active, its container collection should also be exported
* [ ] level exports should do the same
- [ ] add tests for the above
- [ ] look into caching for serialize scene
- [ ] replace field name based logic with type base logic
- [ ] to make things easier overall we need a mapping of Blueprints/Collections to
- [x] their instances
- [x] their objects/sub collections instances etc
- [ ] a mapping of objects to the blueprints they belong to
- [ ] things to alter/remove using the new & improved Blueprints/collections scanning and mapping
- [x] get_sub_collections => remove , but rewrite how BlueprintsList are generated
- [x] get_used_collections => remove , but rewrite how BlueprintsList are generated
- [x] get_exportable_collections => remove , but replace with new function to get exportable blueprints
- [x] get_collections_per_scene
- [x] get_collections_in_library
- [ ] traverse_tree => keep, used
- [x] find_layer_collection_recursive => remove, unused
- [ ] recurLayerCollection => unclear, analyse
- [x] find_collection_ascendant_target_collection => remove, double check
- [x] set_active_collection => keep, used
- [x] get_source_scene => remove, unused
- [x] assets_list["BlueprintsList"]
BLUEPRINTS LIST {'Blueprint1': [], 'Blueprint6_animated': [], 'Blueprint4_nested': ['Blueprint3'], 'Blueprint3': [], 'Blueprint7_hierarchy': [], 'External_blueprint': [], 'External_blueprint2': ['External_blueprint3'], 'External_blueprint3': [], 'Blueprint8_animated_no_bones': []}
- [x] internal_collections => replace with "internal_collections" or "local_collections"
- [x] fix COMBINE MODE passed as int instead of enum value
=> comes from our custom logic for add_on prefs
- [ ] double check compares to "None" values
- [ ] add tests for relative/absolute paths
- [x] move all things that alter data "permanently" to pre-save
- [x] lighting/ scene components injection
- [x] blueprintNames ?
- [x] or more simple: just remove them after save as we do for others: lighting_components
- [ ] if we want the blueprintsList / future paths of blueprints to be present inside external assets, we are going to need to keep them around, ie: inject them in pre-save & not remove them
- [ ] update cleanup_materials
- [x] remove legacy mode
- [x] from auto_export
- [x] from rust code
- [x] from examples
- [x] added notes & workaround information in docs
- [ ] remove bulk of tracker related code
- [ ] clean up
- [x] split up change detection in settings to its own panel
Change storage of 'blueprint' assets : (from BlueprintsList)
- store at the SCENE level: a list/map of assets
- asset name + asset path
- the asset PATH is determined by the export output folder parameters
- make asset storage generic enough to allow adding additional asset types
- get inspired by bevy_asset_loader ?

View File

@ -0,0 +1,229 @@
Basics
- [x] add panel
- [x] add a "create blueprint" button
- [x] when clicked:
- [x] create collection
- [x] add an empty inside collection and name it <COLLECTION_NAME>_components
- [x] add a **AutoExport** Boolean property to collection
- [x] add name imput(popup for name input ?)
- [x] add a list of existing components/custom properties
- [x] add an "edit blueprint" section
- [x] only filled when there is ONE selection, and that selection is a collection
- [x] add a dropdown of possible components
- [x] add a checkbox for enabling disabling a component (enabled by default)
- [x] add a button for copying a component
- [x] add a button for pasting a component
UI:
- [x] filterable list of components to DISPLAY for selection : ComponentDefinitionsList
- Filter out invalid objects for components that have no _components suffix ? (that is too limiting I think)
- -[x] How to deal with pre-existing custom properties that have NO metadata
* if there is one without metadata: find if there is an available component with the same name & type ?
* if there is , insert metadata
* otherwise, mark it in some way visually ?
- [x] for OBJECT enums: add two ui pieces
- [x] one for selecting the TYPE to choose (ie normal enum)
- [x] one for setting the VALUE inside that
- [x] vecs => (not vec2, vec3 etc) more complex UI to add items in a list
- [x] generate contained CollectionGroup
- [x] CollectionProperty => type = the above
- [x] find ways to "collapse" the different levels of nested data of structs/tupples into a single custom property (ideally on the fly, but we can do without)
- [x] for single tupple components that represent a single unit type, re_use the base type's UIPropertyGroup instead of creating specific ones (ie TuppleTestF32_ui...) => will not work, would cause overriden "update callback"
- [x] pre_generate default values/values for each main type
- [x] fix issues with vec2 etc not having the correct number of items
- [x] fix bad defaults in ui group
- [x] fix object enums handling on updates (??)
- [x] fix issues with lambads in loops
- [x] object enum should be <EntryName>(params)
ie *Collider:
* Cuboid(Vec3)
* Sphere(radius)
- [x] deal with enums variants that do not have any data: ex {
"long_name": "Mesh"
}
- [x] remove / change use of ComponentDefinitionsList
- when filling the list, use the long_name as index ie items.append((str(index), item.name, item.long_name)) => items.append((item.long_name, item.name, item.long_name))
- [x] when removing a component, reset the value of the attribute in the property group (or not ? could be a feature)
- [x] deal correctly with fields of types that are NOT in the schema.json (for ex PlayingAnimation in AnimationPlayer)
- [ ] deal correctly with complex types
CascadeShadowConfig: has an array/list
ClusterConfig: one of the enum variants is an object
- [ ] possibly allow Color to be an enum as it should be ?
- [x] for sub items , the update functions "Name" should be the one of the root object
- [x] fix copy & pasting
- it actually works, but the value of the custom property are not copied back to the UI, need to implement property_group_value_from_custom_property_value
- [ ] we need a notion of "root propertyGroup" =?
- [x] notify user of missing entries in schema (ie , unregistered data types)
- [x] clarify propgroup_ui vs named nested fields
- [x] fix basic enums handling
- [x] add a list of not found components to the registry, add to them on the fly
- [x] add configuration panel (open the first time, closed on further user once configured)
- [x] add limits to ixxx types vs utypes
- [x] only display the "generate components xx" when relevant ie:
- go through list of custom properties in current object
- if one does not have metadata and / or propgroup:
break
- [x] remove custom property of disabled component ? => NOpe, as we need custom properties to iterate over
- [x] what to do with components with n/a fields ? perhaps disable the component ? add a "invalid" field to meta ?
- [x] format output as correct RON
- [x] fix issue with empty strings
- [x] change custom property => propGroup to convert RON => Json first => obsolete
- [x] cleanup process_lists
- [x] fix issues with enum variants with only a long_name
- [x] display single item enums inline, others in a seperate row
- [x] add button to "apply all" (in configuration), to apply/update all custom properties to ALL objects where relevant
- [x] add button to "apply to current" to do the same with current
- [x] add warning sign to the above
- [x] what about metadata ?
- [x] only upgrade custom properties to metadata when asked/relevant
- [x] implement move list up/down
- [ ] change property_group_value_from_custom_property_value => just disregard it for now, its point is very limited (helping people with old custom properties by attempting to generate real values)
and give the change to a real ron format, it is too limiting
- [x] fix reload registry clearing list of missing types
- [x] clean up metadata module, a lot of repeated code
- [x] some fields when original is 0 or 0.0 are not copyable ? (seems like a bad boolean check )
- [x] fix issues with object variants in enums (see clusterconfig)
- perhaps directly export default values within the schema.json ?
- for most types , it is straighforward, but others, not so much: like the default color in Bevy , etc
- [x] change default schema.json to registry.json
- [x] pasted components do not get updated value in custom_property
- [x] finish documentation
- [x] add storage of registry path
- [x] save after setting the data (browse for)
- [x] load after each reload ?
# Additional
- [x] check if output "string" in custom properties are correct
- gltf_auto_export
- [x] add support for "enabled" flag
- [ ] add special components
- "AutoExport" => Needed
- "Dynamic" ? naah wait that should be exported by the Bevy side
- [x] filter out Components_meta ??
- [x] add legacy mode to the persisted parameters
- bevy_gltf_components:
- [x] first release patch for current issues
- [x] make configurable
- [x] add "compatibility mode" and deprecation warnings for the current hack-ish conversion of fake ron
- [x] update docs to show we need to use ComponentsFromGltfPlugin::default
- bevy_gltf_blueprints
- [x] update dependency
- [x] update version
- [x] add ability to set legacy mode for bevy_gltf_components ?
- [x] release all versions
- [x] update main documentation, add compatibility version grid
## Phase 2
- [x] fix handling of long component names
- [x] fix nesting level handling issue for new system : ie basic component DOES NOT work, but nestedLevel2 does
- add goddam tests !
- [ ] verify some weird prop => custom property values (Calculated Clip for example)
- [x] fix "reload registry" not clearing all previous data (reloading registry does not seem to account for added/removed components in the registry )
- add file watcher for registry
- [x] have the watcher work as expected
- [ ] add handling of removed registry file
- [ ] clear & reset handler when the file browser for the registry is used
- [ ] re-enable watcher
- tests
clear && pytest -svv --blender-executable <path_to_blender>/blender/blender-4.0.2-linux-x64/blender
- [x] load registry
- just check list of components vs lists in registry
- [x] try adding all components
- [x] select an object
- [x] call the add_component operator
- [x] change params
- use field names + component definitions to set values
- [x] find a way to shuffle params of ALL components based on a reliable, repeatable seed
- [x] test propgroup values => custom property values
- [x] test custom property value => propgroup value
- check if all went well
- [x] fix issues with incorect custom_property generation
- [x] fix issue with object variants for enums
- [ ] add handling for core::ops::Range<f32> & other ranges
- [x] add handling for alloc::borrow::Cow<str>
- [x] add handling of isize
- [x] indirection level
- currently
- short_name +_"ui => direct lookup
- problem : max 64 chars for propertyGroupNames
- possible solution
- propertyGroupName storage: simple , incremented INT (call it propGroupId for ex)
- lookup shortName => propGroupId
- do a first pass, by replacing manual propGroupNames creation with a function
- in a second pass, replace the innards
- add button to regenerate cutom prop values from custom properties (allows us to sidestep any future issues with internals changing)
- [x] fix lists
- [x] fix enums (see Clusterconfig)
- [x] need an example with one tupple one struct
- [x] projection
- [x] additionalmassproperties
- [x] fix tupleStructs (see TupleVecF32F32) => always the same problem of having us pre-parse data without knowing what we have inside
- find a way to only split by level 0 (highest level) nesting "," seperators, ignoring any level of nesting until we dig one level deeper
- solve nesting level use issues
- [x] remove metadata when deleting components
- [x] add try catch around custom_prop => propGroup
- [x] enhance the GenerateComponent_From_custom_property_Operator to use the new system to actually generate the stuff
- coherence in operators:
- component_name vs component_type
- [x] delete => remove
- [x] clean up reloading of registry settings
- [x] clean up file watcher
=========================================
Restructuring of storage of components
- [x] marking of invalid root propgroups/components should be based on long name
- [x] overhaul & check each prop group type's use of short names => long names
- [x] lists
- [x] property_name = short_name in process enum: will likely require to use another indirection helper to keep the propery names short
- [x] in conversions from propgroups
component_name = definition["short_name"]
- [ ] fix is_component_valid that is used in gltf_auto_export
- [x] update all tests
- Hashmap Support
- [x] fix parsing of keys's type either on Bevy side (prefered) or on the Blender side
- [x] fix weird issue with missing "0" property when adding new entry in empty hashmap => happens only if the values for the "setter" have never been set
- [ ] handle missing types in registry for keys & values
- [ ] Add correct upgrade handling from individual component to bevy_components

View File

Before

Width:  |  Height:  |  Size: 9.8 KiB

After

Width:  |  Height:  |  Size: 9.8 KiB

View File

Before

Width:  |  Height:  |  Size: 12 KiB

After

Width:  |  Height:  |  Size: 12 KiB

View File

Before

Width:  |  Height:  |  Size: 10 KiB

After

Width:  |  Height:  |  Size: 10 KiB

View File

Before

Width:  |  Height:  |  Size: 13 KiB

After

Width:  |  Height:  |  Size: 13 KiB

View File

Before

Width:  |  Height:  |  Size: 16 KiB

After

Width:  |  Height:  |  Size: 16 KiB

View File

Before

Width:  |  Height:  |  Size: 8.8 KiB

After

Width:  |  Height:  |  Size: 8.8 KiB

View File

Before

Width:  |  Height:  |  Size: 5.3 KiB

After

Width:  |  Height:  |  Size: 5.3 KiB

View File

Before

Width:  |  Height:  |  Size: 20 KiB

After

Width:  |  Height:  |  Size: 20 KiB

View File

Before

Width:  |  Height:  |  Size: 43 KiB

After

Width:  |  Height:  |  Size: 43 KiB

View File

Before

Width:  |  Height:  |  Size: 20 KiB

After

Width:  |  Height:  |  Size: 20 KiB

View File

Before

Width:  |  Height:  |  Size: 17 KiB

After

Width:  |  Height:  |  Size: 17 KiB

View File

Before

Width:  |  Height:  |  Size: 4.2 KiB

After

Width:  |  Height:  |  Size: 4.2 KiB

View File

Before

Width:  |  Height:  |  Size: 2.7 KiB

After

Width:  |  Height:  |  Size: 2.7 KiB

View File

Before

Width:  |  Height:  |  Size: 9.0 KiB

After

Width:  |  Height:  |  Size: 9.0 KiB

View File

Before

Width:  |  Height:  |  Size: 4.6 KiB

After

Width:  |  Height:  |  Size: 4.6 KiB

View File

Before

Width:  |  Height:  |  Size: 44 KiB

After

Width:  |  Height:  |  Size: 44 KiB

View File

Before

Width:  |  Height:  |  Size: 85 KiB

After

Width:  |  Height:  |  Size: 85 KiB

View File

Before

Width:  |  Height:  |  Size: 29 KiB

After

Width:  |  Height:  |  Size: 29 KiB

View File

Before

Width:  |  Height:  |  Size: 23 KiB

After

Width:  |  Height:  |  Size: 23 KiB

View File

Before

Width:  |  Height:  |  Size: 51 KiB

After

Width:  |  Height:  |  Size: 51 KiB

View File

Before

Width:  |  Height:  |  Size: 38 KiB

After

Width:  |  Height:  |  Size: 38 KiB

View File

Before

Width:  |  Height:  |  Size: 8.2 KiB

After

Width:  |  Height:  |  Size: 8.2 KiB

View File

Before

Width:  |  Height:  |  Size: 3.9 KiB

After

Width:  |  Height:  |  Size: 3.9 KiB

View File

Before

Width:  |  Height:  |  Size: 5.5 KiB

After

Width:  |  Height:  |  Size: 5.5 KiB

View File

Before

Width:  |  Height:  |  Size: 35 KiB

After

Width:  |  Height:  |  Size: 35 KiB

View File

Before

Width:  |  Height:  |  Size: 41 KiB

After

Width:  |  Height:  |  Size: 41 KiB

Binary file not shown.

After

Width:  |  Height:  |  Size: 19 KiB

Binary file not shown.

After

Width:  |  Height:  |  Size: 12 KiB

Binary file not shown.

After

Width:  |  Height:  |  Size: 5.0 KiB

Binary file not shown.

After

Width:  |  Height:  |  Size: 2.8 KiB

Binary file not shown.

After

Width:  |  Height:  |  Size: 23 KiB

Binary file not shown.

After

Width:  |  Height:  |  Size: 2.5 KiB

Binary file not shown.

After

Width:  |  Height:  |  Size: 26 KiB

Binary file not shown.

After

Width:  |  Height:  |  Size: 18 KiB

Binary file not shown.

After

Width:  |  Height:  |  Size: 2.4 KiB

Binary file not shown.

After

Width:  |  Height:  |  Size: 16 KiB

Binary file not shown.

After

Width:  |  Height:  |  Size: 2.5 KiB

Binary file not shown.

After

Width:  |  Height:  |  Size: 16 KiB

Binary file not shown.

After

Width:  |  Height:  |  Size: 35 KiB

Binary file not shown.

After

Width:  |  Height:  |  Size: 25 KiB

Binary file not shown.

After

Width:  |  Height:  |  Size: 26 KiB

Binary file not shown.

After

Width:  |  Height:  |  Size: 16 KiB

Binary file not shown.

After

Width:  |  Height:  |  Size: 34 KiB

Binary file not shown.

After

Width:  |  Height:  |  Size: 21 KiB

Binary file not shown.

After

Width:  |  Height:  |  Size: 14 KiB

Binary file not shown.

After

Width:  |  Height:  |  Size: 25 KiB

Binary file not shown.

After

Width:  |  Height:  |  Size: 19 KiB

Binary file not shown.

After

Width:  |  Height:  |  Size: 14 KiB

Binary file not shown.

After

Width:  |  Height:  |  Size: 3.3 KiB

Binary file not shown.

After

Width:  |  Height:  |  Size: 2.5 KiB

Binary file not shown.

After

Width:  |  Height:  |  Size: 2.4 KiB

Binary file not shown.

After

Width:  |  Height:  |  Size: 14 KiB

Binary file not shown.

After

Width:  |  Height:  |  Size: 16 KiB

Binary file not shown.

After

Width:  |  Height:  |  Size: 14 KiB

Binary file not shown.

After

Width:  |  Height:  |  Size: 4.5 KiB

Binary file not shown.

After

Width:  |  Height:  |  Size: 39 KiB

Binary file not shown.

After

Width:  |  Height:  |  Size: 2.3 KiB

Binary file not shown.

After

Width:  |  Height:  |  Size: 22 KiB

Binary file not shown.

After

Width:  |  Height:  |  Size: 18 KiB

Binary file not shown.

After

Width:  |  Height:  |  Size: 4.4 KiB

Binary file not shown.

After

Width:  |  Height:  |  Size: 21 KiB

View File

@ -43,4 +43,31 @@ def add_material_info_to_objects(materials_per_object, settings):
material = materials_per_object[object]
# TODO: switch to using actual components ?
materials_exported_path = os.path.join(materials_path, f"{materials_library_name}{export_gltf_extension}")
object['MaterialInfo'] = f'(name: "{material.name}", path: "{materials_exported_path}")'
object['MaterialInfo'] = f'(name: "{material.name}", path: "{materials_exported_path}")'
# get all the materials of all objects in a given scene
def get_scene_materials(scene):
used_material_names = []
materials_per_object = {}
root_collection = scene.collection
for cur_collection in traverse_tree(root_collection):
for object in cur_collection.all_objects:
used_material_names = used_material_names + get_materials(object, materials_per_object)
# we only want unique names
used_material_names = list(set(used_material_names))
return (used_material_names, materials_per_object)
# get all the materials of all objects used by a given blueprint
def get_blueprint_materials(blueprint):
materials_per_object = {}
used_material_names = []
for object in blueprint.collection.all_objects:
used_material_names = used_material_names + get_materials(object, materials_per_object)
# we only want unique names
used_material_names = list(set(used_material_names))
return (used_material_names, materials_per_object)