west moth
The function WithSharedComponentFilter generates the lambda code that calls SetSharedComponentFilter, but if my shared component is not a value type at all levels then I need to use SetSharedComponentFilterManaged. Which implies there should be a WithSharedComponentFilterManaged function that I could use.
Until then is there a way to change generated code?
gleaming rock
The function WithSharedComponentFilter generates the lambda code that calls SetS...
SharedComponent is always a "by value check"
managed shared have to implement IEquatable
for that
west moth
It's the unmanaged keyword vs struct, both versions of set filter require equateable
west moth
Just to be clear this is a new codegen issue. With 0.5 we didn't distinguish between managed and unmanaged shared component data. With the introduction of managed versions of all the shared component function we also need a managed version of WithSharedComponentFilter.
gleaming rock
Just to be clear this is a new codegen issue. With 0.5 we didn't distinguish bet...
doesn't normal one work?
west moth
Not any more. The new version use the "unmanaged" keyword in the type information instead of "struct. The versions with struct have the "Managed" word added to the function name.
This is the new error
CS8377 C# The type 'T' must be a non-nullable value type, along with all fields at any level of nesting, in order to use it as parameter in the generic type or method
gleaming rock
ah, I see
mellow timber
are we talking about entities.foreach? and if so, are you aware that it destroys your compilation time?
(it is 4x slower to compile than idiomatic foreach or ijobentity)
(this is why we have tried to push people toward the latter two things, and tried not to add much to EFE)
west moth
are we talking about entities.foreach?
Yes
are you aware that it destroys your compilation time?
No. And I feel like I've been following ECS pretty closely...
It's not trivial changing these over but I'll take a look.
mellow timber
It was too late to deprecate it for 1.0 by the time we decided we couldn’t make it compile quickly
light juniper
Btw, you should note, while @mellow timber 's comment is true - EFE won't go anywhere in a while, because its in 1.0 you'll still get continued support and improvements on the feature (after-all the point of a 1.0 is stability and support!). It's simply something we would encourage users to take it easy with, as it does tank compile time, which we likely can't fix due to the nature of how the feature works! - It also doesn't fit nicely with our other features like SystemAPI.Query and IJobEntity as they are both built for support in ISystem and SystemBase. where EFE is only SystemBase. SystemAPI.Query gives you a simpler API than EFE, and IJobEntity is well suited for customization, write one-place, use many places, and LOD-able API design.
LOD-able, not being a word. but idea being you can use IJobEntity, get a profiler out, see "wait this job is slow", look at it and say, well, I can do some of this work on a whole chunk at a time. Lemme turn my IJobEntity into an IJobChunk with minimal effort, and do my chunk stuff. Oh wait, now I want more control, lemme make it an IJobFor, and so, IJobChunk easily goes to IJobFor. This is what I mean by LOD-able, the effort to move up and down the stack. SystemAPI is built for this, first you did SystemAPI.GetComponent, then, you wanted SystemAPI.GetComponentLookup, then you wanted the manual state.GetComponentLookup. Every step of that way, not blocking you from going down.
All in all, EFE is not gone. We just have better alternatives, we whole heartily recommend 😄
west moth
Should I make a feature request or a bug for EFE support for managed component filters. Really seems like a trivial change. In the meantime is there a way to change generated code?
west moth
Is there any example of this? SystemAPI.Query doesn't have a managed version of the filter either.
gleaming rock
Is there any example of this? SystemAPI.Query doesn't have a managed version of ...
it should have, I think. But if I'm wrong - you cane use IJobEntity
And specify query yourself
west moth
Still can't figure this out I've attached a cs with all the different ways to implement shared component and filters. Idiomatic ijobentity, efe, and a brute force way. Just bake a RenderMeshAuthoring and use the defines to turn on off implementation styles.
mellow timber
@light juniper are we perhaps missing WithSharedComponentFilterManaged on SystemAPI.Query
to be clear, talking about Mesh and Material objects directly is never going to be burst compatible until we make versions of them that are, which we haven't started working on yet
i believe stuff like this is related to why BatchRendererGroup exists
west moth
I used mesh just as an example, should have picked something else. I have a managed class that contains value types I want to use in jobs etc. I just want to filter on the managed type.
if EFE isn't going to be deprecated any time soon it would be good to have WithSharedComponentFilterManaged for that as well.
light juniper
<@119921520968466432> are we perhaps missing WithSharedComponentFilterManaged on...
Missing on both Query and EFE, yes 😅
mellow timber
in the next release we exposed a way to get the shared component index of a managed shared component, and if you use ijobchunk you can look at the shared component indices for the chunk, i believe
west moth
I tried to log a bug but it won't get past QA unless it has some kind of crash repo steps. I really would like to track this.
IN-39524
serene lodge