One yhing don't forget MIP maps on your textures you need a to times by 4 then divide by 3 to your total texture usage below to add in the mip map requirments of your textures
But that does not expand you usage too much... Best Regards Gordon __________________________________________________________ Gordon Tomlinson Email : gordon.tomlinson @ overwatch.com YIM/AIM: Gordon3dBrit MSN IM : Gordon3dBrit @ 3dSceneGraph.com __________________________________________________________ "Self defence is not a function of learning tricks but is a function of how quickly and intensely one can arouse one's instinct for survival" - Master Tambo Tetsura -----Original Message----- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Behalf Of [EMAIL PROTECTED] Sent: Tuesday, January 23, 2007 12:20 PM To: osg users Subject: Re: [osg-users] Performance drops when using 4 or more cameranodes (RTT) Hi, First, to answer Anders' question, my general specs are: Windows XP Pro nVidia 7800 GTX (512MB) As for how much texture memory that I'm using, I simplified my application to only load the cow model. I have seven other textures loading: texN is width x height (internal format, source format, source type) tex0 is 512x512 (GL_RGBA16F_ARB, GL_RGBA, GL_UNSIGNED_BYTE) tex1 is 512x512 (GL_LUMINANCE, GL_LUMINANCE, GL_FLOAT) tex2-5 are all 512x512 (GL_RGBA16F_ARB, GL_RGBA, GL_FLOAT) tex6 is 512x512 (GL_RGBA, GL_RGBA, GL_FLOAT) Unless I'm misunderstanding how texture memory works, seven 512x512 textures in the worst case scenario would take up: (512*512) * 4bytes (RGBA) * 4bytes (32-bit) * 7 textures = 28MB The second "4bytes (32-bit)" is assuming GL_FLOAT uses 32-bits per RGBA. I realize that this calculation is wrong in the sense that not all textures are using the same internal formats, source types, or source formats; but I would assume that this is the worst it could ever be for these textures. With that in mind, it would appear that I should have plenty of texture memory available. I'm wondering if there is some limit to the amount of texture memory that can be associated with FBOs. The same number of FBOs using texture formats of (GL_RGBA, GL_RGBA, GL_UNSIGNED_BYTE) works great, so I'm assuming that I haven't hit a limit as far as the number of FBOs is concerned. If there is a limit on the overall texture memory that can be associated with FBOs, is there a relatively painless way of determining what that maximum texture memory size is? Thanks, Brian On Tue, 23 Jan 2007 08:50:39 +0000, "Robert Osfield" <[EMAIL PROTECTED]> wrote : > Hi Brian, > > I'd check to see if you graphics card has sufficient memory for what > you are trying to do > > Robert. > > On 22 Jan 2007 23:27:35 -0000, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote: > > Hi, > > > > I'm using floating point textures as my targets for multipass RTT. In my > > tests I have noticed that if three or less camera nodes are set up using > > GL_RGBA16F_ARB internal format textures, the frame rate stays at a constant > > 75FPS when only the texture is rendered to the screen (i.e. the texture is > > rendered over the full window). > > > > If I add an additional camera node, the frame rate drops to 15 FPS. Five > > nodes yields 8FPS, and 5FPS are achieved with six nodes. Also, if I set > > the texture to render to 1/4 of the screen and position the main camera so > > that the actual scene being rendered to texture is visible, I'll get 25FPS > > for the three camera node implementation. > > > > I'm setting up my textures with internal formats of GL_RGBA16F_ARB, a > > source type of GL_FLOAT, and a source format of GL_RGBA. > > > > The FBO is set up like: > > fbo->setAttachment(GL_COLOR_ATTACHMENT0_EXT, > > osg::FrameBufferAttachment(texture)); > > > > fbo->setAttachment(GL_DEPTH_ATTACHMENT_EXT, > > osg::FrameBufferAttachment(new osg::RenderBuffer(512, 512, > > GL_DEPTH_COMPONENT24))); > > > > My min/max filters are set up as NEAREST. > > > > If I change my textures to internal formats of GL_RGBA and the source type > > as GL_UNSIGNED_BYTE, my performance is great. > > > > Any thoughts? > > > > Thanks, > > Brian > > _______________________________________________ > > osg-users mailing list > > [email protected] > > http://openscenegraph.net/mailman/listinfo/osg-users > > http://www.openscenegraph.org/ > > > _______________________________________________ > osg-users mailing list > [email protected] > http://openscenegraph.net/mailman/listinfo/osg-users > http://www.openscenegraph.org/ > > > _______________________________________________ osg-users mailing list [email protected] http://openscenegraph.net/mailman/listinfo/osg-users http://www.openscenegraph.org/ _______________________________________________ osg-users mailing list [email protected] http://openscenegraph.net/mailman/listinfo/osg-users http://www.openscenegraph.org/
