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 <min...@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 <min...@ccr.buffalo.edu <mailto: >>> min...@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@lists.openscenegraph.org >>> <mailto:osg-users@lists.openscenegraph.org> >>> >>> http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org >>> >>> >>> >>> ------------------------------------------------------------------------ >>> >>> _______________________________________________ >>> osg-users mailing list >>> osg-users@lists.openscenegraph.org >>> http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org >>> >> _______________________________________________ >> osg-users mailing list >> osg-users@lists.openscenegraph.org >> http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org >> > _______________________________________________ > osg-users mailing list > osg-users@lists.openscenegraph.org > http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org >
_______________________________________________ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
