I've been testing a bit with 2.10-rc.2, and I have some noticed some changes with regards to point rendering.
First: I've noticed that points now are rendered as squares, unless the point-smooth style is specified. Is this the intended behavior? If it is, what is the rationale for that? Performance?
Second: Sometimes the bounding volume of the points seems to be incorrect, making the points not render when the center of the point exits the viewport. This seems to apply to both points and texts. This image shows what I mean:
I modified a earth-file in the tests to generate that gif. The content of my earth file was:
Yes, that's the intended behavior, and the rationale is to replicate GL's FFP point rendering defaults.
Regarding the culling: I'm pretty sure that OSG will cull points based on their center point as well, so this is consistent with OSG. That said I agree that it should take the size into account so I will create a github issue for this.
If i am correct, the osg culling shall be disabled on all drawables that are rendered in screespacelayout (setCullingActive(false)).
This is because screenspacelayout objects will be transformed in the screen space (PixelOffset for example) during the screenspacelayout pass. Osg during its cull traversal cannot be able to compute those transformations.
setCullingActive(false) corected the issue on my version, however it has to be noticed that performance will be impacted when the scene contains a lot of screenspacelayout objects.
(Performance issue comes, at least, from the fact that the decluttering calculation is done on all screenspacelayout objects even if out of the viewport. A calculation shall compute the view cull after the transformation calculation but before the decluttering calculation ).
osgEarth does not disable culling because it would impact performance (as you point out). The developer has the option of doing so (in code) of course. The decluttering calculation will operate on all geometries that pass the cull stage, just like anything else.
Thank you for the precisions. IIRC It is a new behaviour of osgearth, previous versions desactivated the osg culling to avoid
the kind of problems pointed in this thread.
Also, even if the bbox is rightly computed, the transformations that are defined in screenspacelayoutdata will not be taken into account because they are not osg standard transformation. For example if a label is defined (through earth file for example ) with a pixel offset of 100, 0 it will not disappear when touching the viewport border, but 100 pixels before...
Am i wrong?