Interest management

[Stinkfist0]

Diff for commits I accidentally pushed to rex tundra2 already: https://github.com/realXtend/tundra/compare/1fc66ab44fc763c12144d659787b3380cc38e74b...d6add046ca6e20ec8d886bf4017e14e935e5af44 I saw no value in reverting those commits solely for formality reasons so I left them be.

Priority-based IM implemenation I did for my master’s thesis: http://jultika.oulu.fi/Record/nbnfioulu-201411192004 • Original code: https://github.com/LudoCraft/Tundra/tree/InterestManagement • Recent work: https://github.com/Adminotech/tundra/tree/InterestManagement

New Enhancements • Some general code cleanup and minor optimizations. • Client code can register different (C++) interest managers (entity prioritizers) to the system without altering the core Tundra codebase. This allows different types of interest management implementations, depending on the requirements and needs of different types of scenes and applications. It’s also possible to switch between different implementations at runtime. • The size of the ObserverPosition message was reduced from fixed 25 bytes to 10-12 bytes on average

Possible Future Work, To-Dos & Ideas • The next step for the filtering technique would be to define a cut off priority which would be used to remove the most unimportant objects from the client’s view in order to ease the client's rendering workload on large scenes. • ObserverPosition message could be made server-client to tell the initial position, or to force the position, of the observer. • Ideally, the server should be able to define an output per user threshold, which the server could automatically adjust accordingly to the number of concurrent users. • Some other data structure could be used for the dirty object list instead of the current doubly-linked list, for example a min-max heap or other type of priority queue. The min-max heap, for example, would remove the need to sort the list manually, but would make insertions and removals slower, so, profiling advantages and disadvantages of different data structures would be required when seeking the most suitable data structure for the task. • Also, maintaining some kind of priority groups or ranges for objects, instead of every object having its own priority, could make sense as the priorities can be virtually the same for objects within the same area and small changes in the priority don’t have significant effects on the synchronization rate. • Also, factoring in an object’s velocity vector (direction and speed) for the relevancy computation would help refine the priority calculation. • Currently the object priorities are calculated at fixed interval. Server CPU overhead could be observed when the server was computing priorities for many hundreds of objects, especially when number of concurrent users in the world started to grow. Threading the priority computation task could be used as a solution. An alternative approach would be not computing all priorities in a one go, but instead in batches, of say, 100 entities per frame. • A new SetObserver message, containing a scene ID and an entity reference (ID or name) of the desired observer entity could be added to the protocol. This message would allow the server to tell what entity the client must use as the observer when the client joins the server. • A view frustum query –based, or similar, technique for defining client’s interest would be needed for more refined prioritization, meaning incorporating elements of aura-based filtering to the solution.

More documentation and maybe some minor commits to follow in the near future.

[jonnenauha]

We will get to this (with Lasse) later when its relevant in the FICORE project. Thanks for the PR and work.

[Stinkfist0]

@cadaver BTW you gonna merge this, or is the IM work going to be continued solely in Tundra-Urho3D?

[jonnenauha]

@Stinkfist0 did we merge this to admino main branch already? Or did you do this as a separate branch and we waited for it to get here?

[Stinkfist0]

@jonnenauha This was based of rex Tundra and was not merged into Admino Tundra. I think the plan was to pull this to Admino Tundra via rex Tundra.

[cadaver]

There will be some trouble with the dirty entity queue, which was changed to a map to resolve entity parenting ordering. Though this was solved in tundra-urho3d already so it's also solvable here. Could look into merging this now.

EDIT: actually the dirty queue fix is only in AdminoTundra, which is the base for tundra-urho3d's syncmanager code, so this should be a drop-in merge for rex-Tundra.

[cadaver]

Merged. The majority of the work was already in, but now it's up to speed with the code used in tundra-urho3d.