Ember, PLSM2 patch and PageUpdate

Discusion continued from here

The problem with the "PageUpdate" method as I understand if is that it seems it cannot handle multiple changed pages (if you edit a height point that borders on four pages for example).

Ember uses it's own copy of the PLSM2 manager ( http://purple.worldforge.org/cvs/forge/ ... neManager/ ), since I needed to patch it to fix
1) ray queries on the terrain not having the distance set, so that they cannot be eaily sorted ( http://purple.worldforge.org/cvs/forge/ ... eQuery.cpp , line 111)
2) since we don't know anything about the terrain until it is sent from the server, there's a big probability for tiles that are uninitialized (with the height of 0). Since these unilitialized tiles borders on tiles that are initialized, and which might have arbitrary heights, this will make almost all of these bordering tiles having max LOD all the time. Thus I added a check for the absolute 0 value in the algorithm and skipped those cases ( http://purple.worldforge.org/cvs/forge/ ... erable.cpp line 936).

The problem with the "PageUpdate" method as I understand if is that it seems it cannot handle multiple changed pages (if you edit a height point that borders on four pages for example)
I have hard time understanding the problem... you cannot update 4 pages at once ? or you need a method to give you how many pages are affected by a changes ?



On patches :

1) done. soon in cvs and next plsm2 SDK


2) seems a bit too specific to you case to be in core... Cannot you fill with neigbour values (non-zero and lod neutral) instead ?

I have hard time understanding the problem... you cannot update 4 pages at once ? or you need a method to give you how many pages are affected by a changes ?

That was me not really testing the method. It works as it should even with multiple pages. However, just setting "PageUpdate" will only update the underlying data, so the update won't be shown until the page is unloaded and reloaded again (for example when the camera culls it and it is then brough into the frustrum again). Since I want to see the change instantly I have to also call Page::unload() and Page::load() on the page, after setting "PageUpdate".

About number 2, would it work for you if the LOD calculation methods were moved to a LODCalculation-class, which would be a stateless object contained in the RenderableManager, with virtual methods? Thus you could let users provide their own LOD algorithms if they so wanted.

However, just setting "PageUpdate" will only update the underlying data, so the update won't be shown until the page is unloaded and reloaded again (for example when the camera culls it and it is then brough into the frustrum again). Since I want to see the change instantly I have to also call Page::unload() and Page::load() on the page, after setting "PageUpdate".
Looks like a bug to me, page update should make renderables to reload.
I'll add that bug to my bug todo list.

About number 2, would it work for you if the LOD calculation methods were moved to a LODCalculation-class, which would be a stateless object contained in the RenderableManager, with virtual methods? Thus you could let users provide their own LOD algorithms if they so wanted.
I intend to add Lod delegates to do the trick user side if needed in PLSM3. Could backport that.