Thanks for the pointers, Robert. After delving a little into what you said, I have a couple of further questions to see if the osgTerrain route is as potentially fruitful as it looks to me now.
> Adding support for reading from your own formats can be done by > writing your own plugin, one of the image plugins like > src/osgPlugins/rgb might be a good place to look for inspiration. > You can get the plugin to create and osg::Image or an osg::HeightField This makes sense (although osg::HeightField still lives in <Shape> and "Shape.cpp", a little unintuitive). > W.r.t. rendering a height field, the osgTerrain library in 2.0 does > support a mechanism for rendering height fields, this code is still in > development so being added to since 2.0. It can do some of what you > are after but not the inserts. It looks like there are stubs for invalid- or out-of-range-value checking. If osgTerrain supports this well, then the inserts would work (we cut holes in a separate "fuse" step by negating the cut-out values, and not drawing anything at 0 or below [we support "global" vertical offsets for each dem, so we can still draw the ocean floor]). Is this a valid use for those ValidDataOperators? I'm assuming I'd really have to write my own child of GeometryTechnique to do what I'm looking for... On a slightly different note, I'm concerned about the amount of space that terrain looks like it requires. When there's no extra data layers, we've managed to keep our data structure to about 10 bytes per vertex (plus more per row, but I'm looking at the coefficient on the O(n^2) term for space here), which with some data sets already pushes past the limits on some of our older machines. We keep to 10 bytes by generating the x and y coordinates on the fly in a loop and using shorts for the vertex normals. GeometryTechnique appears to require at least 4 times that amount (4 bytes * 6 indexes for each vertex in the element list, plus 4 bytes * 3 normal values, plus 4 bytes for the actual elevation). Did I understand the code right? If so, this strategy would probably be too memory-intensive for our data sets, unless OSG supports paging and I can make use of it. Is there a way to draw an elevation field without explicitly giving the vertex order, or would it make sense to implement something to make that possible? And/Or is there a multi-scale paging mechanism (plugin)? > Another route would be to extend the OSG to do what you want, such as > by encapsulating your current OpenGL drawing code. The osgteapot > example provides an example of extending the Drawable class to do > custom drawing. This is a possibility, but then it's one less reason to use OSG. I already do my own cell-culling on this particular class (only cells that are at least partially in the view frustum get drawn). If OSG does have paging, I think it would be best to avoid this shorter route, and go the longer, more integrated route. Thanks again for your time and direction! Cheers, --Matt P. _______________________________________________ osg-users mailing list osg-users@openscenegraph.net http://openscenegraph.net/mailman/listinfo/osg-users http://www.openscenegraph.org/
