[osg-users] Generate geometry from a digital elevation model

Sebastian Messerschmidt sebastian.messerschmidt at gmx.de
Thu May 21 01:11:35 PDT 2015


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 
> <sebastian.messerschmidt at gmx.de <mailto:sebastian.messerschmidt at gmx.de>>:
>
>     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
>>     osg-users at lists.openscenegraph.org  <mailto:osg-users at lists.openscenegraph.org>
>>     http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
>
>
>     _______________________________________________
>     osg-users mailing list
>     osg-users at lists.openscenegraph.org
>     <mailto:osg-users at lists.openscenegraph.org>
>     http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
>
>
>
>
> _______________________________________________
> osg-users mailing list
> osg-users at lists.openscenegraph.org
> http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openscenegraph.org/pipermail/osg-users-openscenegraph.org/attachments/20150521/95b50f84/attachment-0003.htm>


More information about the osg-users mailing list