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.
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 list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
