Interest Management

[karivatj]

Interest management functionality ported to newest Tundra core which filters out unnecessary network messages based on which updates are interesting to which user. Contains functionality for EA3, A3 and normal Euclidean distance filtering. EA3 filters updates based on what the user sees while A3 relies on basic Euclidean distance. Lots of bugs has been fixed.

One improvement would be to modify OgreRenderingModule to allow raycasting using a basic bounding box based solution instead of raycasting to polygon level. The accuracy is high enough with bounding box approach and is much cheaper way to raycast so it would be a nice feature. I have my own custom raycasting method implemented but I will not include it into this pull request because it alters OgreRenderingModule.

Anyways this should be fully working piece of code which is disabled by default. If you want this enabled it can be done via IM configuration dialog. Just run with --config imDialog.xml to enable the configuration dialog. No future modifications to this pullrequest is planned to be done so I hope this will do.

-Kari Vatjus-Anttila

[karivatj]

Let see if this pullrequest is good to go. Additions atleast consist only from my own work. Added ability to supply im parameters via commandline with --im swiitch. If for example you want to enable EA3 algorithm you would write --im 'EA3;10;50;250;250' where 10 is the critical area, 50 is the maximum distance for relevance filtering, 250 is the raycasting interval and the second 250 is the entity update interval. A3 is enabled via 'A3;10;50;250' and Euclidean distance 'Euclidean;50' where 50 is the range of the critical area.

-Kari

[cadaver]

I will get to reviewing the new version next week. What is important is that when it's disabled, there should be no significant CPU cost added to the network sync, and no extra network bandwidth used.

[karivatj]

Yeah, the interest manager does not exist by default, one have to enable it via commandline or from the configuration dialog. Only then the IM object is created and starts to alter the network traffic. So yeah, no extra burden should exist if the im is not enabled.

[Stinkfist0]

@karivatj Are any of these filtering techniques usable in a headless server, i.e. when running a real life production usage server?

[karivatj]

Only the EA3 algorithm cannot work currently in headless mode because AFAIK raycasting cannot be done in these situations. The other two (A3 and Euclidean) can be used as is in headless mode. If EA3 is attempted to be used in headless mode the situation is handled and fallback to normal A3 algorithm is done instead.

[Stinkfist0]

Ok, great!

[jonnenauha]

@Stinkfist0 is there any possibility that this and your work could somehow co exist and merged cleanly together?

I think the ideal would be to have a interface for interest management. During runtime then anything could go to framework/syncmanager and set its own implementation to be used. I think this was what we dicussed in core dev meetings with Jarkko ja Jukka a while ago when this pull request was under review.

I'm just thinking this kind of design would be great now as @Stinkfist0 has also done some IM work and it might be hard for them to co exist without doing a system like this. In an ideal case IInterestManagement would be provided by Framework and any implementing code would be a optional Tundra plugin separated from Framework.

Edit: After looking at the code a bit, I think it would be easy for us to change src/Core/TundraProtocolModule/InterestManager.h into a interface to TundraProtocolModule. Move all the *Filter.h/.cpp out to a separate plugin. This IInterestManagement would be null, if no 3rd party plugin sets it to its own implementation. This would give full control of interest management, not just for the filter that is used. I'm not saying this needs to be done by @karivatj but we can do it in core if this gets merged. I think it makes sense as @Stinkfist0 will put his own stuff in at some point. Additionally @Stinkfist0s needs can modify what the IInterestManagement should look like.

Any takers? :)

[Stinkfist0]

@jonnenauha Yes, seems fairly easy to merge - one of my main goals has been to keep the implementation simple and straightforward. Probably we end up combining the best parts of both this and my implementation to the future Tundra interest management functionality. And yes, as I mentioned earlier, IIRC, some kind of modular way to provide and test different kind of IM functinalities would be great, and even somewhat easily doable.

[Stinkfist0]

@karivatj Can you provide any measurements whatsoever regarding your implementation?

[karivatj]

Yeah sure. Heres a couple presenting a real-time bandwidth graph and a CPU load graph. The test scene contained two corridors where the avatars were moving in two lines. The center wall had holes in it so time to time every avatar saw each other. Thats why there is a clear fluctuation in EA3 results in both graphs. Oh and during these experiments the server was hosting 30 avatars.

Bandwidth: https://dl.dropbox.com/u/22820793/Kuvat/Bandwidth-graph.png CPU: https://dl.dropbox.com/u/22820793/Kuvat/CPU_Load.png.png

-Kari

[cadaver]

Done very preliminary testing. Merged cleanly and there was no problems when running with IM off. Source files needed adding #include "StableHeaders.h" on Windows.

[Stinkfist0]

I'll be adding some observation comments soon to this pull request Nothing critical that couldn't be resolved later on. I will probably take care of doing some cleanup for this code and moving it to its own Tundra plug-in as discussed in the near future, as were very interested to give this a go here at Admino with @jonnenauha .

[cadaver]

There seems to be a bug with the camera updates in the following case:

• Load avatar scene to a headful server
• Enable IM from the settings, for example Euclidean mode with defaults
• Join with client
• When client gets to the "edge" of the scene, updates of his own avatar stop

[cadaver]

Fixed that one. But marked a few issues which will be necessary for serious use of the IM functionality (they don't prevent merging this now, however)

• Simply forgetting that a non-relevant attribute should be dirty for a particular client will lead to missed updates, if it does not change in the future
• If the purpose of the 2000ms initial wait for the initial camera update is to ensure that the client avatar has been created, it is not foolproof, as a heavy scene might take longer to load.