[osg-users] osgdem --terrain vs polygon count?
Hi all, I admit I don't know what causes osgdem --terrain to take so little time to generate the same terrain that would take hours without that option. I suspect that's part of the answer to my question. But I'd like to know a few of the details if possible. I was wondering why, when I generate a database with the --terrain option, the geometry is a uniform grid (not simplified)? I would suspect this would affect the run time speed on large terrain and where the rest of the scene (other than the terrain) is complex? So are we trading a (very large) increase in build speed for a slowdown in run time speed on slower video cards? What is the magnitude of that slowdown in practice (assuming it actually exists)? Thanks, J-S -- __ Jean-Sebastien Guay[EMAIL PROTECTED] http://www.cm-labs.com/ http://whitestar02.webhop.org/ ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] osgdem --terrain vs polygon count?
Hi J-S, The main speed up with using --terrain in the osgdem/vpbmaster build is that the tile geometry doesn't need to simplified - it can just be aquired from the source DEM's as grids and then output as grids. At runtime there will typically many more triangles being rendered with an --terrain (osgTerrain) scene than one with standard paged database with osg::Geometry, the delta between the two depends upon how flat the region is, and the error metric used in the simplification, and the SampleRatio used in osgTerrain at runtime. The key thing to remember with --terrain databases is that since the triangulation is done dynamically on load you do load balancing - you can set the Terrain::setSampleRatio() according to the hardware that you have, so low level hardware you can set a very low ratio to cull lots of geometry, while high end hardware may even be able to handle a ratio of 1.0. You can't do this type of geometry complexity load balancing with a polygonal paged database, the best you can do is change the Camera's LODScale which affects LOD selection and hence which Nodes, Textures and Geometry that will be selected. Robert. On Mon, Sep 29, 2008 at 3:50 PM, Jean-Sébastien Guay [EMAIL PROTECTED] wrote: Hi all, I admit I don't know what causes osgdem --terrain to take so little time to generate the same terrain that would take hours without that option. I suspect that's part of the answer to my question. But I'd like to know a few of the details if possible. I was wondering why, when I generate a database with the --terrain option, the geometry is a uniform grid (not simplified)? I would suspect this would affect the run time speed on large terrain and where the rest of the scene (other than the terrain) is complex? So are we trading a (very large) increase in build speed for a slowdown in run time speed on slower video cards? What is the magnitude of that slowdown in practice (assuming it actually exists)? Thanks, J-S -- __ Jean-Sebastien Guay[EMAIL PROTECTED] http://www.cm-labs.com/ http://whitestar02.webhop.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] osgdem --terrain vs polygon count?
Hi Robert, The main speed up with using --terrain in the osgdem/vpbmaster build is that the tile geometry doesn't need to simplified - it can just be aquired from the source DEM's as grids and then output as grids. [...] The key thing to remember with --terrain databases is that since the triangulation is done dynamically on load you do load balancing - you can set the Terrain::setSampleRatio() according to the hardware that you have Ok, so in order to get --terrain databases to work optimally on all machines I would have to expose this setting in my software's config files (for example) so that it can be tweaked according to each machine's hardware, is that right? I would suspect that on relatively flat terrain, the terrain database using simplified geometry might run fast enough on all machines (or all reasonably fast machines) without losing any relevant detail, whereas the --terrain database would be too slow on older machines, which would require that we lower the sampleRatio, and thus lose some detail? Is that possible? In that case, if we need to support a large number of different hardware configurations, we might be willing to accept the longer build times of not using --terrain in exchange for not needing to tweak sampleRatio and not losing any detail. Thanks, J-S -- __ Jean-Sebastien Guay[EMAIL PROTECTED] http://www.cm-labs.com/ http://whitestar02.webhop.org/ ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] osgdem --terrain vs polygon count?
Hi J-S, You need to decide what you want to do, but personally I'd recommend using --terrain and then in your app decide how much detail you want, you can make this user definable, provide reasonable defaults for different classes of hardware 0 they key is it's under your control and even after the app is deployed you can still tweak things to better fit the hardware. --terrain also provide much greater opportunities for compressing the tiles on disk. More work will go into this in the future, so tiles with --terrain will end up being more compact despite have more geometry detail available when you need it. Robert. On Mon, Sep 29, 2008 at 4:20 PM, Jean-Sébastien Guay [EMAIL PROTECTED] wrote: Hi Robert, The main speed up with using --terrain in the osgdem/vpbmaster build is that the tile geometry doesn't need to simplified - it can just be aquired from the source DEM's as grids and then output as grids. [...] The key thing to remember with --terrain databases is that since the triangulation is done dynamically on load you do load balancing - you can set the Terrain::setSampleRatio() according to the hardware that you have Ok, so in order to get --terrain databases to work optimally on all machines I would have to expose this setting in my software's config files (for example) so that it can be tweaked according to each machine's hardware, is that right? I would suspect that on relatively flat terrain, the terrain database using simplified geometry might run fast enough on all machines (or all reasonably fast machines) without losing any relevant detail, whereas the --terrain database would be too slow on older machines, which would require that we lower the sampleRatio, and thus lose some detail? Is that possible? In that case, if we need to support a large number of different hardware configurations, we might be willing to accept the longer build times of not using --terrain in exchange for not needing to tweak sampleRatio and not losing any detail. Thanks, J-S -- __ Jean-Sebastien Guay[EMAIL PROTECTED] http://www.cm-labs.com/ http://whitestar02.webhop.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