Point rendering in 2.10-rc.2

classic Classic list List threaded Threaded
6 messages Options
freber freber
Reply | Threaded
Open this post in threaded view
|

Point rendering in 2.10-rc.2

This post was updated on .
Hello,

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:

<map name="Feature Geometry Demo" type="projected" version="2">
    <options>
        <profile 
            srs="+proj=tmerc +lat_0=0 +lon_0=18 +k=1 +x_0=150000 +y_0=0 +ellps=GRS80 +towgs84=0,0,0,0,0,0,0 +units=m +no_defs"
            xmin="125000" xmax="135000"
            ymin="6633000" ymax="6642000"
            num_tiles_wide_at_lod_0="1"
            num_tiles_high_at_lod_0="1"
        />
        <terrain lighting="false" color="#007700FF" visible="false" />      
    </options>
    <feature_source name="city-data" driver="ogr">
        <url>../data/cities.gpkg</url>
    </feature_source>    
    <feature_model name="cities" feature_source="city-data">        
        <feature_indexing enabled="false"/>
        <styles>
            <selector class="cities">
                <query><expr><![CDATA[name == "Uppsala"]]></expr></query>
            </selector>
            <style type="text/css">              
                cities {
                    point-size:     100.0;
                    point-fill:     #ff00ff;
                    point-smooth:   true;
                    text-content:   "A text label";
                    text-encoding:  utf-8;
                    text-priority:  [rank_max];
                    text-align:     center-bottom;
                    text-halo:      #1f1f1f;
                    text-size:      6+2*[rank_max];
                    altitude-offset:    10.0;
                    altitude-clamping: terrain;
                    altitude-technique: scene;
                }     
            </style>
        </styles>
    </feature_model> 
</map>
gwaldron gwaldron
Reply | Threaded
Open this post in threaded view
|

Re: Point rendering in 2.10-rc.2

Fredrik,

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.
Glenn Waldron / Pelican Mapping
JD JD
Reply | Threaded
Open this post in threaded view
|

Re: Point rendering in 2.10-rc.2

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 ).
JD
gwaldron gwaldron
Reply | Threaded
Open this post in threaded view
|

Re: Point rendering in 2.10-rc.2

JD,
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.
Glenn Waldron / Pelican Mapping
JD JD
Reply | Threaded
Open this post in threaded view
|

Re: Point rendering in 2.10-rc.2

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?
gwaldron gwaldron
Reply | Threaded
Open this post in threaded view
|

Re: Point rendering in 2.10-rc.2

JD, you are correct on all counts. :)
Glenn Waldron / Pelican Mapping