Hi Sebastion,
when you deal with geocentric data, the precision is an issue even if it is
not on the GPU. The way how TerraVista (you have heard of it, right) was
solving this was by introducing a matrix of doubles for the origin or the
center of the tile and all the math was then with floats locally to the
tile, in other words, all terrain tiles resides in their local floats
coordinate system with doubles matrix on top. It is still possible to work
with floats this way - that is how I did the geocentric whole earth
terrapage - well, Robert pointed me to this trick. My two cents.
Nick
On Thu, Dec 5, 2013 at 8:28 PM, Sebastian Messerschmidt <
sebastian.messerschm...@gmx.de> wrote:
> Hi Wojciech,
>
> Hi Sebastian,
>
> Just an extra thought that came to me. Terrain LOD paging may cause the
> elevation jumps too. When LODs change meshes get denser or less dense - new
> vertices show up or excess vertices hide and that may also bring lot of
> surprises.
>
> You're correct. But it seems to happen mostly if get close to the mesh,
> where the LOD should not change anymore.
> Right now I'm trying to live with it. But I'm sure there might be clever
> tricks to make it nicer ;-)
> I'm trying to get some info from the osgEarth guys, they surely know how
> to handle those floating point beasts.
>
> cheers
> Sebastian
>
>
> Cheers,
> Wojtek
>
>
>
>
>
>
> 2013/12/5 Wojciech Lewandowski <w.p.lewandow...@gmail.com>
>
>> Hi Sebastian,
>>
>> Perhaps your GPU can use doubles ? Many of them can these days. You may
>> also try to refactor the code to use pairs of floats (as base and offset)
>> which in theory may be almost as precise as double. It may be however very
>> tricky for such non-linear math as geographic projections...
>>
>> Cheers,
>> Wojtek
>>
>>
>> 2013/12/5 Sebastian Messerschmidt <sebastian.messerschm...@gmx.de>
>>
>>> Hi,
>>>
>>> I managed to get the local heights.
>>> After realizing, that the osg_ViewMatrix * gl_ModelViewMatrix will bring
>>> me into world space I was able to use a XYZ_to_latlonheight function in the
>>> vertex shader.
>>> There is only one catch with this: precision. It seems that the float
>>> matrices will simply cut away to much precision so I get massive flickering.
>>> Anyone any idea how to solve, improve this? In the end I simply want to
>>> draw a water surface where the height of the geometry is below a certain
>>> threshold. My problem here are the fragment where the height is almost
>>> equal to the threshold.
>>>
>>> I also tried to move the LLH-calculation to the fragment shader, but it
>>> didn't help.
>>>
>>> example:
>>>
>>> vertex-shader:
>>>
>>> out vec3 lat_lon_height;
>>>
>>> vec3 XYZ_to_llh(vec3 ws_pos)
>>> {
>>> //from osgEarth
>>> float X = xyz.x;
>>> float Y = xyz.y;
>>> float Z = xyz.z;
>>> float _radiusEquator = 6378137.0;
>>> float _radiusPolar = 6356752.3142;
>>> float flattening = (_radiusEquator-_radiusPolar)/_radiusEquator;
>>> float _eccentricitySquared = 2*flattening - flattening*flattening;
>>> float p = sqrt(X*X + Y*Y);
>>> float theta = atan(Z*_radiusEquator , (p*_radiusPolar));
>>> float eDashSquared = (_radiusEquator*_radiusEquator -
>>> _radiusPolar*_radiusPolar)/(_radiusPolar*_radiusPolar);
>>> float sin_theta = sin(theta);
>>> float cos_theta = cos(theta);
>>>
>>> float latitude = atan( (Z +
>>> eDashSquared*_radiusPolar*sin_theta*sin_theta*sin_theta), (p -
>>> _eccentricitySquared*_radiusEquator*cos_theta*cos_theta*cos_theta) );
>>> float longitude = atan(Y,X);
>>> float sin_latitude = sin(latitude);
>>> float N = _radiusEquator / sqrt( 1.0 -
>>> _eccentricitySquared*sin_latitude*sin_latitude);
>>> float height = p/cos(latitude) - N;
>>> return vec3(longitude, latitude, height);
>>> }
>>>
>>> void main()
>>> {
>>> vec3 ws_pos = osg_ViewMatrix * osg_ModelViewMatrix * gl_Vertex;
>>> llh = XYZ_to_llh(ws_pos);
>>> ...
>>> }
>>>
>>> fragment:
>>>
>>> void main()
>>> {
>>> if (llh.z < 10.0)
>>> {
>>> gl_FragColor = vec4(1,0,0,1);
>>> }
>>> else
>>> {
>>> gl_FragColor = color;
>>>
>>> }
>>> }
>>>
>>>
>>> Hi,
>>>>
>>>> I have a osgDEM produced geocentric database.
>>>> I looked into the geometryTechnique implementation to see if I somehow
>>>> can access the height of the vertices above the ellipsoid in the vertex
>>>> shader.
>>>> Unfortunately I don't have any idea how to calculate this from the give
>>>> matrices. Is this information somehow available at all?
>>>> My plan is to overwrite some of the functionality in the
>>>> geometryTechnique to pass the appropriate matrices to the shader.
>>>> Anyone having an idea?
>>>>
>>>>
>>>> _______________________________________________
>>>> osg-users mailing list
>>>> osg-users@lists.openscenegraph.org
>>>>
>>>> http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
>>>>
>>>
>>> _______________________________________________
>>> osg-users mailing list
>>> osg-users@lists.openscenegraph.org
>>> http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
>>>
>>
>>
>
>
> _______________________________________________
> osg-users mailing
> listosg-users@lists.openscenegraph.orghttp://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
>
>
>
> _______________________________________________
> osg-users mailing list
> osg-users@lists.openscenegraph.org
> http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
>
>
--
trajce nikolov nick
_______________________________________________
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
