-
-
Notifications
You must be signed in to change notification settings - Fork 3.5k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Refactor the render instance logic in #9903 so that it's easier for other components to adopt. #10002
Conversation
This is kind of a prerequisite to GI, as that adds a whole bunch of components that need to be mirrored into the render world and I think it'd be ugly to be constantly reinventing this logic. |
89fae8d
to
21e0dae
Compare
…sier for other components to adopt. Currently, the only way for custom components that participate in rendering to opt into the higher-performance extraction method in bevyengine#9903 is to implement the `RenderInstances` data structure and the extraction logic manually. This is inconvenient compared to the `ExtractComponent` API. This commit creates a new `ExtractToRenderInstance` trait that mirrors the existing `ExtractComponent` method but uses the higher-performance approach that bevyengine#9903 uses. This makes high-performance rendering components essentially as easy to write as the existing ones based on component extraction.
21e0dae
to
ce8d88d
Compare
I also want this for gpu driven rendering. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
If the symlink mistakes are fixed then I’ll approve and merge this.
/// This is essentially the same as | ||
/// [`ExtractComponent`](crate::extract_component::ExtractComponent), but | ||
/// higher-performance because it avoids the ECS overhead. | ||
pub trait ExtractToRenderInstance: Component { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I’m wondering if there is a case for a more flexible version where you give it a query, filter, and instance, and a method as a way of mapping from the query to the instance but it isn’t implemented for a single Component. I’m a bit concerned that doing this per component one wants to extract will be detrimental to performance because it will result in more, independent lookups.
Pull request was closed
Ok, I'll close this. |
Head branch was pushed to by a user without write access
Hi, I wanted to try refactor some usage |
Yeah, that's unfortunate. Modern graphics APIs call one of the handles on a particular GPU an 'instance'. We'll have to think about this a bit and rename something. |
…sier for other components to adopt. (bevyengine#10002) # Objective Currently, the only way for custom components that participate in rendering to opt into the higher-performance extraction method in bevyengine#9903 is to implement the `RenderInstances` data structure and the extraction logic manually. This is inconvenient compared to the `ExtractComponent` API. ## Solution This commit creates a new `RenderInstance` trait that mirrors the existing `ExtractComponent` method but uses the higher-performance approach that bevyengine#9903 uses. Additionally, `RenderInstance` is more flexible than `ExtractComponent`, because it can extract multiple components at once. This makes high-performance rendering components essentially as easy to write as the existing ones based on component extraction. --- ## Changelog ### Added A new `RenderInstance` trait is available mirroring `ExtractComponent`, but using a higher-performance method to extract one or more components to the render world. If you have custom components that rendering takes into account, you may consider migration from `ExtractComponent` to `RenderInstance` for higher performance.
…sier for other components to adopt. (bevyengine#10002) # Objective Currently, the only way for custom components that participate in rendering to opt into the higher-performance extraction method in bevyengine#9903 is to implement the `RenderInstances` data structure and the extraction logic manually. This is inconvenient compared to the `ExtractComponent` API. ## Solution This commit creates a new `RenderInstance` trait that mirrors the existing `ExtractComponent` method but uses the higher-performance approach that bevyengine#9903 uses. Additionally, `RenderInstance` is more flexible than `ExtractComponent`, because it can extract multiple components at once. This makes high-performance rendering components essentially as easy to write as the existing ones based on component extraction. --- ## Changelog ### Added A new `RenderInstance` trait is available mirroring `ExtractComponent`, but using a higher-performance method to extract one or more components to the render world. If you have custom components that rendering takes into account, you may consider migration from `ExtractComponent` to `RenderInstance` for higher performance.
…sier for other components to adopt. (bevyengine#10002) # Objective Currently, the only way for custom components that participate in rendering to opt into the higher-performance extraction method in bevyengine#9903 is to implement the `RenderInstances` data structure and the extraction logic manually. This is inconvenient compared to the `ExtractComponent` API. ## Solution This commit creates a new `RenderInstance` trait that mirrors the existing `ExtractComponent` method but uses the higher-performance approach that bevyengine#9903 uses. Additionally, `RenderInstance` is more flexible than `ExtractComponent`, because it can extract multiple components at once. This makes high-performance rendering components essentially as easy to write as the existing ones based on component extraction. --- ## Changelog ### Added A new `RenderInstance` trait is available mirroring `ExtractComponent`, but using a higher-performance method to extract one or more components to the render world. If you have custom components that rendering takes into account, you may consider migration from `ExtractComponent` to `RenderInstance` for higher performance.
Objective
Currently, the only way for custom components that participate in rendering to opt into the higher-performance extraction method in #9903 is to implement the
RenderInstances
data structure and the extraction logic manually. This is inconvenient compared to theExtractComponent
API.Solution
This commit creates a new
RenderInstance
trait that mirrors the existingExtractComponent
method but uses the higher-performance approach that #9903 uses. Additionally,RenderInstance
is more flexible thanExtractComponent
, because it can extract multiple components at once. This makes high-performance rendering components essentially as easy to write as the existing ones based on component extraction.Changelog
Added
A new
RenderInstance
trait is available mirroringExtractComponent
, but using a higher-performance method to extract one or more components to the render world. If you have custom components that rendering takes into account, you may consider migration fromExtractComponent
toRenderInstance
for higher performance.