Re: [osg-users] --tile-terrain-size in VPB
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 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.or g ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.or g ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.or g ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.or g ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] --tile-terrain-size in VPB
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
Re: [osg-users] --tile-terrain-size in VPB
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.eduwrote: 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
Re: [osg-users] --tile-terrain-size in VPB
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 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 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
Re: [osg-users] --tile-terrain-size in VPB
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
