Am 21.05.2015 um 09:37 schrieb Christian Buchner:
As our application will also have to do physical simulations based on
this height field data, I do not want to use external tools to do the
conversion into an OSG model
Okay, but I would not consider it an "external tool" but an extended
part of osg. osgdem saves you the pain of constructing osgTerrain tiles
yourself. This will still won't save you the effort of reading the file,
putting into the correct reference-frame etc.
here's a minimal example for the HeightField / ShapeDrawable method
http://snipplr.com/view/30974/osg-height-field-example/
here's a minimal example for the Delauney method (minus the loading of
the image and texture)
https://github.com/xarray/osgRecipes/blob/master/cookbook/chapter10/ch10_01/delaunay.cpp
I guess I will just try both methods. The only missing piece seems to
be a loading function or plug-in for height field Files in ".asc"
format. But the format is trivially simple.
You can of course try those, but why investing hours of work, if there
is a simple ready to use solution? (getting and compiling osgdem is a
matter of minutes)
If you want me to, I can check if osgdem will compile thes ASCII grid
format (If you can point me to a sample set).
Cheers
Sebastian
2015-05-21 9:26 GMT+02:00 Sebastian Messerschmidt
<[email protected] <mailto:[email protected]>>:
Hi Christian,
Have you checked if osgdem supports it? I think it will happily
convert anything into osgTerrain which can be interpreted as
height data by gdal ...
Hi,
I am currently wondering which is the better way to go from a
simple digital elevation model (ESRI ASCII Grid format) to a
geometry. The model has a very limited area and resolution.
These are the two methods I find feasible with stock OSG features:
Either I could feed all the 3D points on the grid into the
osgUtil::DelaunayTriangulator. However I noticed this class
generates normals that require a BIND_PER_PRIMITIVE - possibly
causing a fallback to the slow rendering path.
Alternatively I could put the data into an osg::HeightField and
use a ShapeDrawable to display it.
Which of the two methods is perferable from a performance
standpoint? What I would like to get is a bit of a simplification
of the geometry, where larger triangles are used in areas with
less surface features. Which of the two methods can provide this?
I do not want to use osgEarth, as it is a bit too big in scope
for my purpose and it has a lot of extra dependencies.
Christian
_______________________________________________
osg-users mailing list
[email protected]
<mailto:[email protected]>
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
_______________________________________________
osg-users mailing list
[email protected]
<mailto:[email protected]>
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
_______________________________________________
osg-users mailing list
[email protected]
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
_______________________________________________
osg-users mailing list
[email protected]
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
