Re: [osg-users] PagedLOD preprocessing
Paul Martz napsal(a): [...] The naïve approach -- just let OSG load it -- appears to cause a guaranteed frame rate hit. I imagine you could break the texture up into smaller chunks and let OSG page each in incrementally as it comes into range. Yes, breaking the texture into the smaller ones looks like necessary. I made already some measurements of glTexImage2D. 32 0,040,52 64 0,060,61 128 0,170,82 256 0,421,6 512 1,8 4,8 102411,317,9 204842 69 4096170 6500 The first column is texture size, second time in milliseconds for GF 6600 and the last column is time for ATI 1950. You may notice driver bug for 4096 ATI textures. Anyway, loading a large scene for preprocessing seems not trivial - hacks to OSG plugin will be probably necessary. John ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] PagedLOD preprocessing
On 9/10/07, Paul Martz [EMAIL PROTECTED] wrote: Hi Robert -- Assuming you've massaged your database so that the highest res textures only get loaded/displayed at close ranges, how would you use OSG to avoid the (seemingly inevitable) cost of loading the large texture from disk and sending it over the bus to the graphics card when it is time to be rendered? The naïve approach -- just let OSG load it -- appears to cause a guaranteed frame rate hit. I imagine you could break the texture up into smaller chunks and let OSG page each in incrementally as it comes into range. Or, you could preload all textures onto all displays at startup with the GLObjectsVisitor, though this could tax system RAM for large datasets. Could PROXY_TEXTURE help? At least it would tell OpenGL hey, some big data is coming, eventually but there would still be the disk access and bus transmission cost, so I imagine it's not a solution. Robert, your thoughts please. We don't have a texture manage at present, but one could in theory develop one to load balance memory on the GPU. With GPU memory sizes going up all the time this is probably getting less of a problem. W.r.t loading incrementally and compiling OpenGL data. In 2.1.x and SVN there is support for using a background compile context - this is a pbuffer per graphics window that is shared with the graphics context and has its own graphics thread that runs the compile and object clean up. One can enable compile contexts via: osgviewer mydata.ive --cc Also see osg::GraphicsContext::createCompileContext(..) function. Robert. ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
[osg-users] PagedLOD preprocessing
Hi, advanced problem: Is there a chance to preprocess scene by OSG to use PagedLOD? The scene contains 3GB of textures (or any higher number). My idea was to make PagedLOD scene that would load high-resolution textures only for the most close scene parts to the camera. The problem is clear: OSG would probably freeze the computer during preprocessing when loading all the textures. In Inventor, it seemd simple: just to override the texture type and make the implementation not to load texture data. Any chance for solution in OSG? John ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] PagedLOD preprocessing
Hi John, On 9/10/07, PCJohn [EMAIL PROTECTED] wrote: Is there a chance to preprocess scene by OSG to use PagedLOD? Yes, but you'll need to write the database conversion yourself. The osgpagelod example may help a bit as this converts LODs to PagedLODs. The scene contains 3GB of textures (or any higher number). My idea was to make PagedLOD scene that would load high-resolution textures only for the most close scene parts to the camera. 3GB is not overly large, and the reason for PageLOD existance is helping handle this and much large scenes. The problem is clear: OSG would probably freeze the computer during preprocessing when loading all the textures. In Inventor, it seemd simple: just to override the texture type and make the implementation not to load texture data. Any chance for solution in OSG? There every chance of a solution in the OSG, first up you load the data, for instance do it incrementally, and then to generate the LOD levels as required. This is a tasks for you to work out though - the OSG is a scene graph rather than a modelling tool. Robert. ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] PagedLOD preprocessing
The scene contains 3GB of textures (or any higher number). My idea was to make PagedLOD scene that would load high-resolution textures only for the most close scene parts to the camera. 3GB is not overly large, and the reason for PageLOD existance is helping handle this and much large scenes. Cool! I am looking forward to test it on much larger data sets. The problem is clear: OSG would probably freeze the computer during preprocessing when loading all the textures. In Inventor, it seemd simple: just to override the texture type and make the implementation not to load texture data. Any chance for solution in OSG? There every chance of a solution in the OSG, first up you load the data, for instance do it incrementally, and then to generate the LOD levels as required. This is a tasks for you to work out though - the OSG is a scene graph rather than a modelling tool. Surely, I already started on algorithms by myself. But what are the possibilities of loading the scene data to not burn all free memory? I am guessing there are two approaches: - You mentioned incremental loading - but I do not see any possibility to break in to the load-at-once algorithms of osgDB::Registry, ReaderWriterOSG, and their friends - override of loading algorithms of PluginOSG for Texture class, although I am not sure if it is possible to do so John ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] PagedLOD preprocessing
The problem is clear: OSG would probably freeze the computer during preprocessing when loading all the textures. In Inventor, it seemd simple: just to override the texture type and make the implementation not to load texture data. Any chance for solution in OSG? There every chance of a solution in the OSG, first up you load the data, for instance do it incrementally, and then to generate the LOD levels as required. This is a tasks for you to work out though - the OSG is a scene graph rather than a modelling tool. Hi Robert -- Assuming you've massaged your database so that the highest res textures only get loaded/displayed at close ranges, how would you use OSG to avoid the (seemingly inevitable) cost of loading the large texture from disk and sending it over the bus to the graphics card when it is time to be rendered? The naïve approach -- just let OSG load it -- appears to cause a guaranteed frame rate hit. I imagine you could break the texture up into smaller chunks and let OSG page each in incrementally as it comes into range. Or, you could preload all textures onto all displays at startup with the GLObjectsVisitor, though this could tax system RAM for large datasets. Could PROXY_TEXTURE help? At least it would tell OpenGL hey, some big data is coming, eventually but there would still be the disk access and bus transmission cost, so I imagine it's not a solution. Robert, your thoughts please. Paul Martz Skew Matrix Software LLC http://www.skew-matrix.com 303 859 9466 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
