Hi Nick,
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.
I'm aware of the concept. In fact this is how OSG renders the geocentric
data. The only difference is, that the View and ModelViewMatrices are
pulled down to float precision in the shader.
So in the ModelViewMatrix the precision is good, as it is kept double
precision all the way through the graph. Essentially view and model
matrices are canceling out here.
My problem is the float precision product (ModelView) and ViewInverse to
get the ModelMatrix again. *sigh*
Maybe I can install an update callback of some kind to push a float
precision ModelMatrix for the terrain tiles and use it directly.
Thank you for the hint anyways :-)
cheers
Sebastain
Nick
On Thu, Dec 5, 2013 at 8:28 PM, Sebastian Messerschmidt
<sebastian.messerschm...@gmx.de
<mailto: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
<mailto: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
<mailto: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
<mailto:osg-users@lists.openscenegraph.org>
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
_______________________________________________
osg-users mailing list
osg-users@lists.openscenegraph.org
<mailto:osg-users@lists.openscenegraph.org>
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
_______________________________________________
osg-users mailing list
osg-users@lists.openscenegraph.org
<mailto:osg-users@lists.openscenegraph.org>
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
_______________________________________________
osg-users mailing list
osg-users@lists.openscenegraph.org
<mailto: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
_______________________________________________
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
