Feature Request ChangeFilters on Client (proof of concept)

I really like what Unity is trying to do with NetCode but I have an issue with the fact it triggers ChangeFilter on Clients continuously. ChangeFilters are my favourite feature of Entities and I've been doing a lot of work recently on extreme scale performance (100,000,000 entities 2ms per frame) and static archetypes and ChangeFitlers are paramount to the ability to scale to extremes.

Is this a topic Unity is planning on addressing at some point?

I've done a lot of experimentation for future projects recently and decided to dig into seeing if I could make NetCode respect change filters to allow me to build an architecture I want that will scale for my needs.

Anyway I have a proof of concept working up here: https://github.com/tertle/com.unity.netcode

Before you consider using it, it's currently only setup to work on IComponent changes via CopySnapshot. I have not done IBufferElement, Child elements or PredictionBackup. It's purely a proof of concept.

My test is just incrementing a value every ~5 seconds on server and listening to this change via ChangeFilter on Client.

Before:

After:

Note the far right values - the number of times this method was called on client for each value.
The times are backwards because I forgot to record before and reverted code changes and recorded it after

It's a pretty simple change, instead of just opening the chunk component with RW it opens with RO and does a MemCmp afterwards to see if it's changed and then manually bumps the Change Version. Now this is obviously a little more overhead but I've found MemCmp to be really fast. Personally I think the benefit of potential user code improvements will greatly outweigh this cost.

The code:
Original

Code (CSharp):

1. var compData = (byte*)chunk.GetDynamicComponentDataArrayReinterpret<byte>(ghostChunkComponentTypesPtr[compIdx], compSize).GetUnsafeReadOnlyPtr();
2. deserializerState.SendToOwner = GhostComponentCollection[serializerIdx].SendToOwner;
3. for (var rangeIdx = 0; rangeIdx < entityRange.Length; ++rangeIdx)
4. {
5.     var range = entityRange[rangeIdx];
6.     var snapshotData = (byte*)dataAtTick.GetUnsafeReadOnlyPtr();
7.     snapshotData += snapshotDataAtTickSize * range.x;
8.     GhostComponentCollection[serializerIdx].CopyFromSnapshot.Ptr.Invoke((System.IntPtr)UnsafeUtility.AddressOf(ref deserializerState), (System.IntPtr)snapshotData, snapshotOffset, snapshotDataAtTickSize, (System.IntPtr)(compData + range.x*compSize), compSize, range.y-range.x);
9. }
10. snapshotOffset += snapshotSize;

Proof of Concept

Code (CSharp):

1.  
2. var data = chunk.GetDynamicComponentDataArrayReinterpretRO<byte>(ghostChunkComponentTypesPtr[compIdx], compSize); // Changed to RO
3. var compData = (byte*)data.GetUnsafePtr();
4. m_chunkBuffer.CopyFrom(data);
5. deserializerState.SendToOwner = GhostComponentCollection[serializerIdx].SendToOwner;
6. for (var rangeIdx = 0; rangeIdx < entityRange.Length; ++rangeIdx)
7. {
8.     var range = entityRange[rangeIdx];
9.     var snapshotData = (byte*)dataAtTick.GetUnsafeReadOnlyPtr();
10.     snapshotData += snapshotDataAtTickSize * range.x;
11.     GhostComponentCollection[serializerIdx].CopyFromSnapshot.Ptr.Invoke((System.IntPtr)UnsafeUtility.AddressOf(ref deserializerState), (System.IntPtr)snapshotData, snapshotOffset, snapshotDataAtTickSize, (System.IntPtr)(compData + range.x*compSize), compSize, range.y-range.x);
12. }
13. if (UnsafeUtility.MemCmp(compData, m_chunkBuffer.GetUnsafeReadOnlyPtr(), data.Length) != 0)
14. {
15.     chunk.SetChangeFilter(ghostChunkComponentTypesPtr[compIdx]); // Manually trigger change filter only if there's a change
16. }
17. snapshotOffset += snapshotSize;

The Simple Test

Code (CSharp):

1.     [UpdateInWorld(TargetWorld.Client)]
2.     public partial class TestClientSystem : SystemBase
3.     {
4.         private EntityQuery query;
5.  
6.         protected override void OnCreate()
7.         {
8.             this.query = this.GetEntityQuery(ComponentType.ReadOnly<TestComponent>());
9.             this.query.SetChangedVersionFilter(typeof(TestComponent));
10.         }
11.  
12.         protected override void OnUpdate()
13.         {
14.             if (!this.query.IsEmpty)
15.                 Debug.Log($"New value on client {this.query.GetSingleton<TestComponent>().Test}");
16.         }
17.     }

Alternative Way
While I was looking at a way to do this I thought of an alternative approach if I was willing to touch the codegen that might work better with how NetCode has been built as a lot of the components in the chunks wouldn't be touched in the snapshot.
This alternate way would be to add a change check into the code generated by PortableFunctionPointer<RestoreFromBackupDelegate> RestoreFromBackup and make it return a bool. It would look something like this (completely theoretical and untested.)

Code (CSharp):

1.  
2. var compData = (byte*)chunk.GetDynamicComponentDataArrayReinterpretRO<byte>(ghostChunkComponentTypesPtr[compIdx], compSize).GetUnsafeReadOnlyPtr(); // Changed to RO
3. deserializerState.SendToOwner = GhostComponentCollection[serializerIdx].SendToOwner;
4. bool changed = false;
5. for (var rangeIdx = 0; rangeIdx < entityRange.Length; ++rangeIdx)
6. {
7.     var range = entityRange[rangeIdx];
8.     var snapshotData = (byte*)dataAtTick.GetUnsafeReadOnlyPtr();
9.     snapshotData += snapshotDataAtTickSize * range.x;
10.     changed |= GhostComponentCollection[serializerIdx].CopyFromSnapshot.Ptr.Invoke((System.IntPtr)UnsafeUtility.AddressOf(ref deserializerState), (System.IntPtr)snapshotData, snapshotOffset, snapshotDataAtTickSize, (System.IntPtr)(compData + range.x*compSize), compSize, range.y-range.x);
11. }
12. if (changed)
13. {
14.     chunk.SetChangeFilter(ghostChunkComponentTypesPtr[compIdx]); // Manually trigger change filter only if there's a change
15. }
16. snapshotOffset += snapshotSize;
17.  
18.  

Anyway really just posting my thoughts and a proof of concept of something I would REALLY like to be supported. I do not expect Unity to implement this exact solution and I just wanted to prove to myself a proof of concept was possible to ease any concerns I might have before embarking in a project. There might well be a much better way to do this as I'm much less familiar with the NetCode package than I am with Entities. This was just a 30min brain storm using some concepts I developed recently from a high performance library.

If this is not something Unity intends to support there is a good chance I fork and flesh this out properly at some point as it's something I consider mandatory for future work I want to do.

Again before anyone uses it, it's purely a proof of concept without any thorough testing to see consequences

 

Big +1!

It's been a long time I've done anything with Netcode. Will get back to it eventually.
When working with it this was a huge problem for me. Change filters are great(!) and that functionality is thrown out the window with the current Netcode implementation. I struggled with some systems hard because I was expecting Netcode to respect change filtering and didn't want systems to run all the time when there are no changes. Often it's hard to code systems to work properly, when you don't expect them to run. Then you need lots of additional branching and other synced values to keep some form of state.

Having a better understanding now, mainly through working the stuff out with tertle, I know it's doable and would make writing systems a lot more clean instead of relying on some synced fields or queries with structural changes.

 

How's the current progress now? Which exp.x version will get this feature?

 

I ended up running this in my project (just on components not buffers as it's a lot less overhead) since this post without ever running into an issue. It ended up being amazing for workflow and reacting to server updates.

-edit-

i should say i haven't tried to implement it in 1.0 yet, other things to focus on.

 

Oh no. Then I still need to stick with ugly if check current and previous components to update UI for long time.

 

if you really need it I've updated my proof of concept in the repo for 1.0 as I was curious.

Before


After


Please note: I am not actively working with netcode at the moment so will not be thoroughly testing this.

There is an odd behavior on ghost spawn as it triggers a few times so something is definitely up however, I don't have time to investigate why as I have too many projects that need finishing.

I can not recommend using it unless you are willing to investigate this yourself. The risk is yours.

-edit-

yeah after leaving it a bit longer there are weird periods where it triggers when it shouldn't
it'd still provide significantly fewer updates but you could not rely on it to be accurate.



(I have a pretty good idea why from my glimpse at the code but again, will not investigate further. Wait for an official implementation.)

 

That's why to this day I fail to understand how to use this feature efficiently.
But now that in 1.0 the enable/disable feature forced a 128 entity cap on Chunk capacity. Could a similar approach be used to Provide per entity change filter ?

 

My entire project is built around change filters. It's how I can scale to 100 million entities for testing (I hit memory limits at this point) and still execute frame in 20ms. Change filters are extremely efficient when setup properly.

IMO they are the most powerful feature in ECS if your goal is scale, you should investigate them more!

 

I agree, I just can't wrap my head around it.
From what I understand, as soon as you declare a read/write acces to a component in a job, the version is bumped even if you don't actually write to any of the component. So any other job that uses a change filter will be triggered even if nothing actually changed...

And I fail to see how to write to a component without declaring it read/write or using EntityManager/ECB...

Something obvious probably eludes me.
I'll need to make a sample project only for that and experiment with all the read / write positbilites to understand what workls and what doesn't.
I just haven't had the time to invest in this and keep putting it off because there is always something else to learn

 

I have not touched this for 2-3 years, but I think this is still valid. was always my do to resource back in the days, “the missing manual”

https://gametorrahod.com/designing-an-efficient-system-with-version-numbers/

 

Thanks, I'll have to read that carefully

 

It's that time of the month again, where I decide to add netcode support to one of my libraries and I'm dying for some change filter support... so again I've added support back to the latest netcode (pre.15) and this time I also added support for buffers.
https://github.com/tertle/com.unity.netcode

Before:


After:

 

Woo thanks Niki! So excited.

If anyone is interested in why I was originally looking into this or wants inspiration for change filter uses, I started this thread because I wanted to efficiently watch changes to a bit fields coming from server for a clustering/fracturing system.

(This video is from back in 0.51)
The red planks are ghosts, the rest are client only simulated (the full boards are also ghosts before they are fractured)

Now i could have totally worked around not having change filters on client, but it's a lot nicer that I can run the exact same system with the same checks on both client/server and don't need separate code paths.

 

I think I need change filter support for owner prediced ghost to update UI.

 

These are working awesome btw, thanks a bunch. I know there was a bit of discussion in here about some users wanting to look at using change filters and one of biggest issues you can have with them is after you've setup your work flow, months later accidentally triggering them every frame and not realizing.

Had this issue happen to me after updating netcode and testing my filters again and one of them was busted, so I wrote a tool to track my change filters and notify me if I've broken them!

Just chunk an attribute on your component you want to protect

Code (CSharp):

1. [ChangeFilterTracking]
2. public struct FractureShardsDirty : IComponentData

And it'll notify if you ever go above 85% chunk activation over 600 frames (I'll allow customization of these values some point in the future) as well as appear in my new change filter window.



As always available in my core library, it's in master but I recommend the 0.13 branch as I just significantly improved performance of the window https://gitlab.com/tertle/com.bovin...3/BovineLabs.Core.Editor/ChangeFilterTracking

 

Most of these components (all the bottom stuff except navmesh) don't even exist on my client so probably should have shown server view, but I have no good way of separating them at the moment.

My normal change rate for all of the above is 0% (as is my objective for performance), I had to specifically spam a sequence of operations to actually have any % show up ^_^'.

As for predicted, I haven't tested that yet unfortunately as apart from a couple of temporary predicted spawns which switch to interpolated, I currently I only have 1 predicted ghost in this project which isn't relying on any change filters at this time. I guess I'll find out if I have any problems when I work on that area more in the future.

 

Any updates on when this might be available (or is it in 1.2 already)?
Also is there any good way to track the release of features like this? The roadmap doesn't seem to be granular enough