refactor: improvements to visiblity system #948
Conversation
… all current systems and only implements the interest manager that will auto check if any systems are added if not just use all current players on server to send data. Much faster and there is no need to do checks. Next step will be to implement different systems people may need or use. Signed-off-by: dragonslaya <dragonslaya.ss@gmail.com>
…esting branch and not get spammed. Signed-off-by: dragonslaya <dragonslaya.ss@gmail.com>
…stem. Signed-off-by: dragonslaya <dragonslaya.ss@gmail.com>
Signed-off-by: dragonslaya <dragonslaya.ss@gmail.com>
Signed-off-by: dragonslaya <dragonslaya.ss@gmail.com>
|
|
||
| namespace Mirage.InterestManagement | ||
| { | ||
| public readonly struct ObserverData |
There was a problem hiding this comment.
Does this need to be a struct? doesn't seem like it is created in hot path?
| /// </summary> | ||
| /// <param name="identity">The identity of the object we want to check if player's can see it or not.</param> | ||
| /// <returns></returns> | ||
| internal HashSet<INetworkPlayer> Observers(NetworkIdentity identity) |
There was a problem hiding this comment.
The way this looks atm it will be called once for every send call, which will likely become very expensive compared to a field that we use now
There was a problem hiding this comment.
We use a field in network identity. That field gets updated by current visibility systems through update method. Its almost exact same thing. This is now a central system versus network identity holding and updating info of visibility which it never should be doing. Open to suggestions but its almost identical to current system.
Also let's measure it. i am not sure how to measure current system since things are all over the place in many locations. I can currently measure performance just in Interest Manager.
changed loop to break out. Signed-off-by: dragonslaya <dragonslaya.ss@gmail.com>
Signed-off-by: dragonslaya <dragonslaya.ss@gmail.com>
Signed-off-by: dragonslaya <dragonslaya.ss@gmail.com>
Signed-off-by: dragonslaya <dragonslaya.ss@gmail.com>
Signed-off-by: dragonslaya <dragonslaya.ss@gmail.com>
Signed-off-by: dragonslaya <dragonslaya.ss@gmail.com>
…erestManagement
|
Some files from old PR to try here |
… octree version Signed-off-by: dragonslaya <dragonslaya.ss@gmail.com>
Missed few files for the sample scene.
…erestManagement # Conflicts: # Assets/Mirage/Components/NetworkMatchChecker.cs # Assets/Mirage/Components/NetworkSceneChecker.cs # Assets/Mirage/Runtime/NetworkIdentity.cs # Assets/Mirage/Runtime/ServerObjectManager.cs # Assets/Mirage/Samples~/InterestManagement/Scenes/AOI.unity # Assets/Mirage/Samples~/Tanks/Scenes/Scene.unity # Assets/Tests/Performance/Runtime/HeadlessBenchmark/Scenes/Scene.unity
dragonslaya84
added
keep-open
done |
Only implements the interest manager that will auto check if any systems are added if not just use all current players on server to send data. Much faster and there is no need to do checks.
Next step will be to implement different systems people may need or use.
Please test and comment. All users using mirage what type of systems do you think you will need.? I only want to implement what end users are using or implement as end users need them.
Implementing there own system is very easy as creating a new class and overriding the NetworkVisibility system. That creates a pure C# system that interest manager finds. If you require showing the information in inspector you need to create a 2nd file that inherits from BaseVisibilityInspector.
I found it better this way for full control. You would implement both there is a single override that you only need to do and its the Start method of unity and implement anything inside there. The system will auto register itself using the base class.
Signed-off-by: dragonslaya dragonslaya.ss@gmail.com