Hi Alan,
On 2/22/07, Alan Harris <[EMAIL PROTECTED]> wrote:
As it appears you are starting to re-factor osgTerrain I have a few
suggestions.
1) DataSet is something of a behemoth (approx 5000 lines) and would
benefit from being broken down into standalone classes (and files). It
already lends itself to that as there are a number of classes.
Indeed DataSet grew and grew and grew, I think Roald Dahl must have
spinkled some magic dust on it from beyond the grave :-)
Eventually I'd expect to see DataSet replaced, but in the first cut of
the code once its moved out of the core OSG would be consider
flattening the classes, so that they sit in their own files and not in
the DataSet scope.
2) My recent submission on osgTerrain building in specific support for
vector data sets should be considered. I should be stronger and say that
height data by default should be considered as vector rather than
raster. The majority of height data from various agencies around the
World are vector data sets.
GDAL incorporates vector data via OGR (I think) but the formats are
fairly limited.
I haven't had a chance to review these changes yet. When you say
vector data, what exactly do you mean? It could cover a huge range of
data usage, do you mean lines? Do you mean clouds of x,y,z point?
3) With the use of vector data an expansion of HeightField might be
useful. I derived a class from HeightField which allows better
definition of the normals at the edge of tiles (you need to expand the
field somehow to get the next point off the tile). I also added direct
Node generation into the class rather than use the Shape / Drawable method.
I am planning to separate out the rendering of height fields into a
proper NodeKit style extension of the core OSG. I don't have an API
for it yet. I do plan to use vertex and fragment shaders extensively.
The height fields would be effectively a displacement map, with the
base mesh typically regular but would support irregular base mesh.
The terrain building tools could then use the height field rendering
or create polygon osg::Geometry meshes as done at present.
4) I have a problem with my derived version of osgTerrain in that it
crashes on my largest test case (20km x 20km at 0.5m resolution aerial
photo). It used to crash on smaller cases, but adding tests where, for
example, new Geodes fail to be created, appeared to cure those. So it
may be a memory problem. It also fails at a different point each time
(usually about 30% of the way through) which is after about 30 minutes.
I have to sort this but it leads to a useful suggestion.
The set up of the database does not take long (about 5% of the total
time). It would make sense to create a file containing the
DestinationTile information at that point. Couple this with updating
(and flushing) the archive index after every file write means that, by
comparing the DestinationFile structure with the files already in the
database, it would be feasible to re-start a database creation from the
point where it failed.
It also allows repair of a database with re-generating the whole thing.
Early in osgTerrain we used to have crashes, but I haven't personally
seen a crash for over a year. Fixing the crash would be certainly be
important, but since you've working with your own extensions to
osgTerrain I can't really comment on what might be the cause.
Allow a build to restart once begun is something that I have planned
for the new terrain building project. The move to place the existing
terrain building code out into its own distribution will be done
first, and osgTerrain will be developed further as a NodeKit dedicated
to rendering terrain, but not building it. The terrain building
project will come later, but I won't actually get to this until April
at the earliest.
Robert.
_______________________________________________
osg-users mailing list
osg-users@openscenegraph.net
http://openscenegraph.net/mailman/listinfo/osg-users
http://www.openscenegraph.org/
