[osg-users] --tile-terrain-size in VPB

[Guy]

So maybe it should be decided by a flag from the user, or by the tile
size... if it fits in short, use it for performance, else use int?

 

Guy.

 

________________________________

 

Hi Martins,

Good catch.  Use of DrawElementUint will provide better scalability in
terms of tile size, but DrawElementUShort will still be preferred by
default as it'll provide better performance.  Also small tiles sizes are
to be preferred for other performance aspects.

Robert.

On Tue, Mar 24, 2009 at 7:14 PM, Martins Innus <minnus at ccr.buffalo.edu>
wrote:

Robert,

       It seems that this issue is caused by the use of
DrawElementsUShort and "unsigned short" indexes in "osg::Node*
DestinationTile::createPolygonal()".  Such that each level can only have
a maximum of 65536 vertexes.  And I do see that a terrain-tile size of
256x256 works, yet 512x12 doesn't, which makes sense.

       Is this something you'd accept a change for to be included in
VPB?  Not sure what the performance implications would be, or how
extensive the changes would need to be.

Martins



Martins Innus wrote:

Robert,
   What fun would it be if people didn't abuse your code :)  I agree
that in general VPB does a great job with default settings, I've used it
several times to generate 100 GB databases over large areas.

   In this case though I'm trying to generate terrain at the resolution
of the source data for a very small area in as few tiles as possible. I
realize this is not the intended purpose, but I was trying to see if
anyone had done this successfully.

   It doesn't seem to be a display issue, becase I can generate the
model with default options and load all the highest resolution tiles
directly into osgviewer and it runs fine, about 4 million vertices.

   Going down to 512x512 causes the same problem.

   I'll keep digging if no one has run into this before.

Martins

Robert Osfield wrote:

Hi Martins,

Jikes, some days I regret making osgdem quite so flexible...

A 1024x1204 grid weights in at million vertices, and near two million
triangles.  Normally graphics cards should be able to handle this,
but... it would seem that your's doesn't, perhaps it just doesn't have
the memory to handle such a big geometry.  The other chance might be
that numerical precision is becoming an issue, although I'd be surprised
by this one.

I really would very strongly recommend that you stick to defaults unless
you really know what you are doing, the defaults are chosen for a good
performance and scalability.

Robert.

2009/3/23 Martins Innus <minnus at ccr.buffalo.edu
<mailto:minnus at ccr.buffalo.edu>>

   Hello,
          I'm using the --tile-image-size and --tile-terrain-size
   options to tweak the generation of the dataset.  The image option
   works great, but when I try to use the terrain option I get the
   results attached.

          If I zoom in, it seems like a lot of overlapping geometry
   like the y-coordinate is not being updated properly, but I dug
   through the code and could see any obvious causes.

   I'm using the following command-line:

   osgdem --tile-image-size 4096 --tile-terrain-size 1024 -t
   ../input_ims/ -d ../input_terrain/ -e 1065536 1043840 8192 8192 -o
   output/vpb_out.ive

   I even added --no-terrain-simplification to see if that was the
   problem, but no help there.

          I'm not using the --TERRAIN option, since I need to
   post-process the geometry using an existing tool.

   Thanks

   Martins

   _______________________________________________
   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.or
g



------------------------------------------------------------------------

_______________________________________________
osg-users mailing list
osg-users at lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.or
g

_______________________________________________
osg-users mailing list
osg-users at lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.or
g

_______________________________________________
osg-users mailing list
osg-users at lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.or
g

 

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