Hi Sebastian,
Personally I'd subclass from osgTerrain::GeometryTechnique and pass a
FloatArray as a vertex attrib array or tex coord array and store the
heights there.
Robert.
On 4 December 2013 13:23, Sebastian Messerschmidt
sebastian.messerschm...@gmx.de wrote:
Hi,
I have a osgDEM
Sabastian,
osgEarth does more or less what Robert describes. We encode each vert's
height value (and unit vector) in a vertex attribute.
On Dec 6, 2013 5:43 AM, Robert Osfield robert.osfi...@gmail.com wrote:
Hi Sebastian,
Personally I'd subclass from osgTerrain::GeometryTechnique and pass a
Am 06.12.2013 13:14, schrieb Glenn Waldron:
Sabastian,
osgEarth does more or less what Robert describes. We encode each
vert's height value (and unit vector) in a vertex attribute.
Thank you Glenn. Are the vertices relative to the Ellipsoid?
Or can you point me to the sources where I can
Hi Robert,
Hi Sebastian,
Personally I'd subclass from osgTerrain::GeometryTechnique and pass a
FloatArray as a vertex attrib array or tex coord array and store the
heights there.
Okay, that would double the data then. I'm a bit nervous about adding
more vertex attributes as I already have a
Hi,
I'm facing the same problem, and I can't pre-compute vertex attributes on CPU
because my vertex are moved by the shader him-self (displacement mapping).
I've tried to use double matrices, but these leads to a lot of compatibility
problem.
Since the precision problem is in the temporary
The heights are relative to the ellipsoid, yes. I can send you a code link
when I get back (in on the road atm).
On Dec 6, 2013 7:55 AM, Sebastian Messerschmidt
sebastian.messerschm...@gmx.de wrote:
Am 06.12.2013 13:14, schrieb Glenn Waldron:
Sabastian,
osgEarth does more or less what
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
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...
HI Wojciech,
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
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
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
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
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
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
14 matches
Mail list logo
