Sometimes, with a very rare occurence, all placenodes "shakes" in a perimeter of 1 pixel (one move per frame).
I tried the snap_pixel option with the same result.
I dont have a scenario to reproduce it as it is very occasional and seems random.
Have you ever had this problem? Any ideas for correcting?
OsgEarth 2.9 with few patches
Unfortunately it is not linked to the tether mode.
I managed to reproduce it with feature_labels example but still not have a scenario.
I am adding traces to understand what is the data that moves (geotransform result? mvp multiplication? ...)
Along with this investigation i am trying to understand another pb in screespacelayout: sometimes the bboxdrawable of a placenode is drawn after the text; it is like it does not fall into the «same parent» branch of the sorting algorithm and then (using depth criteria) z-fighting happens...
- When the placenodes "shake" without any camera movement, i can see that their leaf modelview matrix changes each frame. What I can see in the values is that they change between a "pure" float value with a lot of digits after the comma AND a value that always finishes with '.5'. This '.5' is the result of the "quantize/snaptopixel" calculation. The problem, when occurs, is that the condition "if ( quantize && !camChanged )" passes one in two. The tests show that when the problem occurs the condition camChanged changes its value each frame ! (true, false, true, false, true ...). I didn't find for the moment the reason of why "camVPW != local._lastCamVPW;" does not work... I think that there is an issue in the management of the _perCam map... For my project i simply set snapToPixel to false and it works and i don't see any problems about the characters rendering.
- About the bboxdrawable that is sometimes displayed after the text (then it hides it) I am starting to understand what happens. Globally it is a problem related to the _depth value of the leaves. A first patch must be done in "SortFrontToBackPreservingGeodeTraversalOrder" for the case where sortByPriority is not active. The equality of depth is not tested and if there are many placenodes with exactly the same depth (it can occur!) the sort algorithm can separate the bbox and its associated text (the "same parent" condition will not be systematically evaluated depending on the order the drawables are). The code that is in "SortByPriorityPreservingGeodeTraversalOrder" must be used instead (check traversal order when depth are equal). But even with this patch, the sort algorithm will "fail" in some cases. It is when the depths of bbox and text (or icon and text) are not the same AND if the depth order between both is not the one we expect with the geode order. I did not manage to have a quick fix. Possible fixes i have in mind:
- Merge bbox and text into the same drawable (it will also improve the culling performance but it will not help for placenodes composed of icon and text)
- OR find a way for forcing the depth values of all drawable of a given geode to be the same
- OR Do a first sort based on geode depth and not on drawable, then sort again this list to respect the traversal order under a given geode.
- I noticed also that the placenode always creates a text even if the text symbol is not defined (for only displaying an icon for example). "createTextDrawable" shall be called only when necessary.
I lost some hairs with that investigation!
My intention is to implement a drawable that supports both bbox and text (like OSG does), but i don't have a roadmap for that today.