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
[email protected]
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
_______________________________________________
osg-users mailing list
[email protected]
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
_______________________________________________
osg-users mailing list
[email protected]
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
