Change RenderAsset::unload_asset to be called whenever RenderAsset would be dropped#24250
Open
larsraph wants to merge 5 commits into
Open
Change RenderAsset::unload_asset to be called whenever RenderAsset would be dropped#24250larsraph wants to merge 5 commits into
RenderAsset::unload_asset to be called whenever RenderAsset would be dropped#24250larsraph wants to merge 5 commits into
Conversation
…rAsset::unload_asset functionality
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Objective
RenderAsset::unload_asset(internally used only for morph) is called when the source asset is removed from the MainWorld. I beleive this functionality is limiting and should be called whenever theRenderAssetis about to be dropped (but giving ECS access).Solution
selfparamRenderAsset::unload_assetimpl which drops the allocation we just inserted. In order to fix this I stopped keying the RenderMorphTargetsAllocator and stored MorphTargetsImageHandle in RenderMesh.There is not much of a difference between this system and just storing the MorphTargetsImage directly in the RenderMesh. So if the goal in using the RenderMorphTargetsAllocator in the first place was to avoid bloating the RenderMesh with conditional data (RenderMorphTargetsAllocator and the MorphTargetsImage is only actually active when certain features are enabled on the target device) then the new system mostly fails. (although the
Option<Handle>takes 8 bytes vs however many bytes MorphTargetsImage takes)I also want to eventually change RenderMesh to store a handle to MeshAllocator but is unneccecary for this PR and also complicated due to batching.
Testing
Notes
free()taking ownership of the handle. This means we can read from the Handle w/o checking if it has an associated item (it cannot have been freed) and we can free from it w/o worrying abt double free. However I think this pattern might not be suited for a large project such as bevy. I can change it relatively easily to do checked access instead. Going the other direction if we want to double down on this pattern we can do unchecked access instead of an expect("").