Hi Alan, You can still use osgUtil::SceneView if you wish, it's kept around for backwards compatibility. However, you should be able to get things working with osgViewer by using a shared GraphicsWindowEmbedded. As for gluSaleImage taking time - basically the OSG hasn't change in this respect since 1.2 - both with use gluScaleImage when required and do so from the drawing thread, however, there is lots you are doing at your end that is not usual OSG usage, the best I can do is point you in the right direction, to take you much further will take too much of my overstretched time.
Robert. On Wed, Jun 4, 2008 at 1:49 PM, Alan Ott <[EMAIL PROTECTED]> wrote: > Robert Osfield wrote: > > Hi Alan, > > The memory difference is almost certainly down to the different in > Texture unref after apply which is probably not working because of > your viewer setup. > > > Robert, > > While the unref of course makes me able to use less memory, _not_ using the > unref is where I observed the 4x number. > > Memory usage using the same app, same data, but with different OSG versions: > OSG1 no unref - 223m > OSG2 no unref - 802m > OSG2 with unref - 92m > > I'm wondering if some default setting is different in version 1 vs version > 2. Note that these numbers are from my test application (not embedded in the > external non-OSG app, but embedded in a GLUT window instead. Note also that > these numbers come from running a single viewer instance, so the unref is > working when I request it to. I'm going to put together a small test > program loading these textures to see if I can narrow down the problem. > > Another Issue I saw with OSG2 as opposed to OSG1 is that when loading these > large textures, rendering gets blocked by a call to gluScaleImage() in > Texture.cpp when the texture is bound the first time. I do all my loading on > a separate thread to keep the rendering path clear, but in OSG2 for some > reason, it's spending a lot of time at this gluScaleImage() function in the > main thread. I temporarily got around this by setting the non-resize to > power of two flag, and this seems to work, but I didn't need to do that with > OSG1. In fact, I think I can be sure that it _was_ resizing in OSG1 because > one of my boxes here is an older ATI, and I see debug messages saying that > it's disabling the non-power-of-2 extension for my hardware, which means it > _must_ be resizing in OSG1. I'll check it again. > > It just seems like there are too many weird things happening here for them > to be independent from one another. > > Are you using the GraphicsWindowEmbedded feature? Is each of the > viewers using its own > GraphicsWindowEmbedded? If so make sure they share the same instance > as this will > ensure they both use the same ContextID. > > > Right now, they are separate, as I use the > osgViewer::Viewer::setUpViewerAsEmbeddedInWindow() function. I'll try making > them use the same GraphicsWindowEmbedded. I've done this in another app (it > was using CompositeViewer, though). > > The other approach you could take is to do you own OpenGL rendering in > a pre/post Camera callback, and use CompositeViewer. This will give > plenty more flexibility. > > > I looked at using a CompositeViewer for this, and I do use CompositeViewer > on another project. The problem I have with it on this one is that best I > can tell, CompositeViewer has one frame() function which draws all the Views > at once. Currently, I do two separate draws, and I'm not sure I can do them > both at the same time. > > Some more information: > > In my application, I do this to draw my stuff (this is outside of OSG): > > glPushAttrib(GL_ALL_ATTRIB_BITS); > //glPushClientAttrib(GL_CLIENT_ALL_ATTRIB_BITS); > glMatrixMode(GL_MODELVIEW); > glPushMatrix(); > glMatrixMode(GL_PROJECTION); > glPushMatrix(); > //glMatrixMode(GL_TEXTURE); > //glPushMatrix(); > > digitalMap->draw(); // This is my class which uses OSG. It > contains a Viewer which I call frame() on here. > > //glMatrixMode(GL_TEXTURE); > //glPopMatrix(); > glMatrixMode(GL_PROJECTION); > glPopMatrix(); > glMatrixMode(GL_MODELVIEW); > glPopMatrix(); > //glPopClientAttrib(); > glPopAttrib(); > > Keep in mind that I'm doing this twice, as I have two instances of > DigitalMap. Push()/pop() for Client Attributes is currently disabled. In > OSG1 I needed this, but now in OSG2, if I have the push/pop enabled, only > the geometry which was in the scene before the first frame() actually gets > drawn to the screen. Geometry that gets paged in later will never get drawn. > I'm not sure what glPushClientAttrib() has to do with that, but that seems > to be how it works, even in my simple GLUT test app. > > All this stuff worked beautifully in OSG 1, and was rock solid. In OSG1, of > course, I used the SceneView instead of OsgViewer as this was the > recommended practice at the time. > > Thanks again for all your help, > > Alan. > > Robert. > > On Tue, Jun 3, 2008 at 8:39 PM, Alan Ott <[EMAIL PROTECTED]> wrote: > > > I accidently just sent this to the old openscenegraph.net list address. If > it shows up twice in your inbox, I apologize. > > > Hello, > > I have somewhat of a weird situation. I have an application which uses a > non-osg rendering system. In this application, I have my library which > draws somewhere in the middle of the draw() phase of the external > renderer. I actually draw twice during the external renderer's draw(), > because I draw to two different parts of the screen, and because the > application must draw over the top of my OSG stuff. > > It goes like this: > > external renderer draws some stuff > my first osgViewer::Viewer draws some stuff > external renderer draws more stuff > my second osgViewer::Viewer draws some more stuff > external renderer draws final stuff > > The reason it's like this is because the external renderer needs to draw > over the top of my 3D image, and the two Viewers are drawing separate > scenes. I'm doing this using two osgViewer::Viewer objects. Each OSG > Viewer is unaware of the other. This setup appears to be working fine. > > THE PROBLEM > > The problem is that I have some rather large textures, and would like to > use Texture::setUnRefImageDataAfterApply() to remove texture image data > after it's been pushed to the scene. This works well if I only have one > osgViewer::Viewer instance, but when I have two Viewers, Texture2D won't > ever free the Image data because Texture::areAllTextureObjectsLoaded() > will return false because the textures have not been loaded to _both_ > Viewer's contexts. The reality is that in my application, they > _never_will_ be loaded to both Viewer's contexts because the two viewers > contain completely separate scenes (and thus textures). > > I can't figure out a good way to make Texture2D unref the Image. Does > anyone have any ideas? > > This all came about because I'm in the process of upgrading my software > to use OSG 2.4 from 1.0 (Yeah, it's been a while...). In OSG 2.4 (and > also in 2.2) the application seems to require almost _four_times_ the > system memory to load the same textures as it did in version 1.0. Has > anyone else run into this? I would like to make > setUnRefImageDataAfterApply() work ideally, but I'd also be happy with > the OSG 1.0 amount of ram usage. A solution to either would be very much > appreciated. > > Thank you very much, and thank you for your hard work on OSG. > > Alan. > > > _______________________________________________ > 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
