You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Allow assets to be defined within a prototype file rather than outside of it, using a Schematic-like approach.
While this probably won't be useful for large assets or those that make no sense in a text-based format, it should be great for assets defined in code.
For example, we should be able to define a prototype like:
In the example above, we define a a prototype, Sphere, which contains a schematic for the MaterialMeshBundle<StandardMaterial> (aka a PbrBundle). This schematic contains the definitions for two assets that are normally defined in code:
We create a primitive UvSphere mesh
We create a StandardMaterial with a given color
This is powerful because it means users can play around with an asset's values without needing to rebuild the entire application.
Implementation
This should be powered by a new trait: AssetSchematic.
The AssetSchematic trait should work very similar to a normal Schematic. It should be derivable (for Asset types) and have convenient attributes for handling common scenarios.
It should also support defining an AssetSchematic to build an asset not owned by the user. The intention here is that users should be able to define their own schemas for Bevy-owned assets (e.g. adding their own primitive shapes for a Mesh asset).
Lastly, an AssetSchematic should properly handle overwriting itself. This is important because it means that existing references to the asset will automatically receive the changes. This is consistent with regular Bevy assets: there cannot be two versions of an asset referred to by the same path/handle. However, this feature should be optional (though, on by default) and configurable via an attribute in the derive macro.
Considerations
While I haven't really looked at the changes proposed in bevyengine/bevy#8624, I understand that it might change how a feature like AssetSchematic works. In fact, there's a possibility that it breaks it completely.
However, that work is still in draft mode and I'm unsure of when it is planned to actually be released. So for the time being, I plan on proceeding with this feature, along with the understanding that it may require refactoring/removal down the line.
The text was updated successfully, but these errors were encountered:
Objective
Allow assets to be defined within a prototype file rather than outside of it, using a
Schematic
-like approach.While this probably won't be useful for large assets or those that make no sense in a text-based format, it should be great for assets defined in code.
For example, we should be able to define a prototype like:
In the example above, we define a a prototype,
Sphere
, which contains a schematic for theMaterialMeshBundle<StandardMaterial>
(aka aPbrBundle
). This schematic contains the definitions for two assets that are normally defined in code:UvSphere
meshStandardMaterial
with a given colorThis is powerful because it means users can play around with an asset's values without needing to rebuild the entire application.
Implementation
This should be powered by a new trait:
AssetSchematic
.The
AssetSchematic
trait should work very similar to a normalSchematic
. It should be derivable (forAsset
types) and have convenient attributes for handling common scenarios.It should also support defining an
AssetSchematic
to build an asset not owned by the user. The intention here is that users should be able to define their own schemas for Bevy-owned assets (e.g. adding their own primitive shapes for aMesh
asset).Lastly, an
AssetSchematic
should properly handle overwriting itself. This is important because it means that existing references to the asset will automatically receive the changes. This is consistent with regular Bevy assets: there cannot be two versions of an asset referred to by the same path/handle. However, this feature should be optional (though, on by default) and configurable via an attribute in the derive macro.Considerations
While I haven't really looked at the changes proposed in bevyengine/bevy#8624, I understand that it might change how a feature like
AssetSchematic
works. In fact, there's a possibility that it breaks it completely.However, that work is still in draft mode and I'm unsure of when it is planned to actually be released. So for the time being, I plan on proceeding with this feature, along with the understanding that it may require refactoring/removal down the line.
The text was updated successfully, but these errors were encountered: