Re: [osg-users] Problem with corrupted textures when sharing instances of models loaded from IVE format.
Hi all I'm gonna add my 5 cents on this topic. I was having similar problems in app which recreates viewer in runtime (there are preview window and viewer created when widget shows up), using osg version 3.0(?). In my case problem was not only with textures - i was getting corrupted vertex arrays after viewer re-creation. I tried some voodoo magic with osgDB::Registry and caching settings, tried to clear gl objects with osg::deleteAllGLObjects() osg::flushAllDeletedGLObjects() etc, but without any luck. I've had different graphics context ids after viewer recreation. In my case problem was solved when using vertex buffer objects instead of display lists, i didnt dig any further after that. IIRC problem was showing itself only on windows, but i cant say for sure now. Cheers 14.01.2012, 14:58, Robert Osfield robert.osfi...@gmail.com: Hi Chris, On 14 January 2012 09:30, Chris Denham c.m.den...@gmail.com wrote: Hi Robert, To answer your question about how I manage the graphics contexts. I just create a new one for the window handle provided by each instance of my browser plugin e.g Code: traits-inheritedWindowData = new WindowData(hWnd); gc = osg::GraphicsContext::createGraphicsContext(traits); After gc is assigned check the value of gc-getState()-getContextID() for each of the contexts created. In theory for multiple contexts they should read 0,1,2,etc. Robert. ___ 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] Problem with corrupted textures when sharing instances of models loaded from IVE format.
Hi Robert, Yep, I can confirm the return value of gc-getState()-getContextID() is increasing as you describe for each brower plugin instance created. Does that mean I should be ok sharing scengraph between viewers? It certainly seems ok now I've disabled the unref images after apply flag on the textures. Chris Denham. robertosfield wrote: Hi Chris, On 14 January 2012 09:30, Chris Denham wrote: Hi Robert, To answer your question about how I manage the graphics contexts. I just create a new one for the window handle provided by each instance of my browser plugin e.g Code: traits-inheritedWindowData = new WindowData(hWnd); gc = osg::GraphicsContext::createGraphicsContext(traits); After gc is assigned check the value of gc-getState()-getContextID() for each of the contexts created. In theory for multiple contexts they should read 0,1,2,etc. Robert. ___ osg-users mailing list http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org -- Post generated by Mail2Forum -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=44855#44855 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Problem with corrupted textures when sharing instances of models loaded from IVE format.
Hi Hybr, Corrupted vertex arrays? Do you mean the OpenSceneGraph geometry data, or a problem with the OGL compiled display list? I've not seen that, and I hope I don't. ;-) I'll keep an eye out for trouble though. Cheers, Chris. hybr wrote: Hi all I'm gonna add my 5 cents on this topic. I was having similar problems in app which recreates viewer in runtime (there are preview window and viewer created when widget shows up), using osg version 3.0(?). In my case problem was not only with textures - i was getting corrupted vertex arrays after viewer re-creation. I tried some voodoo magic with osgDB::Registry and caching settings, tried to clear gl objects with osg::deleteAllGLObjects() osg::flushAllDeletedGLObjects() etc, but without any luck. I've had different graphics context ids after viewer recreation. In my case problem was solved when using vertex buffer objects instead of display lists, i didnt dig any further after that. IIRC problem was showing itself only on windows, but i cant say for sure now. Cheers -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=44857#44857 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Problem with corrupted textures when sharing instances of models loaded from IVE format.
I've destroyed complete scene with viewer and graphics context, and recreated it all with reading new models from files with disabled cache etc. On first run all was ok, and on next runs mesh would look all distorted (some vertices of mesh randomly displaced etc). Dont know if it problem with display lists or geometry data arrays in osg, but display lists should be brand new each time, because i've deleted all opengl objects before shutting down graphics context, and new context have different id, also object cache disabled, cleared and model reloaded each time from file, so there shouldn't be problem with osg data arrays. I have no idea what goes wrong. Cheers 16.01.2012, 14:52, Chris Denham c.m.den...@gmail.com: Hi Hybr, Corrupted vertex arrays? Do you mean the OpenSceneGraph geometry data, or a problem with the OGL compiled display list? I've not seen that, and I hope I don't. ;-) I'll keep an eye out for trouble though. Cheers, Chris. hybr wrote: Hi all I'm gonna add my 5 cents on this topic. I was having similar problems in app which recreates viewer in runtime (there are preview window and viewer created when widget shows up), using osg version 3.0(?). In my case problem was not only with textures - i was getting corrupted vertex arrays after viewer re-creation. I tried some voodoo magic with osgDB::Registry and caching settings, tried to clear gl objects with osg::deleteAllGLObjects() osg::flushAllDeletedGLObjects() etc, but without any luck. I've had different graphics context ids after viewer recreation. In my case problem was solved when using vertex buffer objects instead of display lists, i didnt dig any further after that. IIRC problem was showing itself only on windows, but i cant say for sure now. Cheers -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=44857#44857 ___ 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] Problem with corrupted textures when sharing instances of models loaded from IVE format.
Hi Chris, On 16 January 2012 10:39, Chris Denham c.m.den...@gmail.com wrote: Yep, I can confirm the return value of gc-getState()-getContextID() is increasing as you describe for each brower plugin instance created. Does that mean I should be ok sharing scengraph between viewers? It should be OK. osgViewer hasn't been designed for using of multiple viewers running in a parallel, but is designed for scene graphs to be shared between multiple contexts, so as long as the ContextID's a mapped correctly, as it sounds like they are. It certainly seems ok now I've disabled the unref images after apply flag on the textures. If this is the case then the max number of contexts that the unref scheme is using is obviously not high enough. osgViewer will look at the number of contexts that are active and then using this as a limit. Is it that you are creating one viewer and context then drawing frames, then later creating a new context and draw more frames. In the later case I can certainly see that if the first frames draw will release the osg::Image resources assigned to osg::Texture if they are set up to unref the images, so disabling the unref of images makes sense. Robert. ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Problem with corrupted textures when sharing instances of models loaded from IVE format.
Hi Sergey, 2012/1/16 Sergey Polischuk pol...@yandex.ru: I've destroyed complete scene with viewer and graphics context, and recreated it all with reading new models from files with disabled cache etc. On first run all was ok, and on next runs mesh would look all distorted (some vertices of mesh randomly displaced etc). Dont know if it problem with display lists or geometry data arrays in osg, but display lists should be brand new each time, because i've deleted all opengl objects before shutting down graphics context, and new context have different id, also object cache disabled, cleared and model reloaded each time from file, so there shouldn't be problem with osg data arrays. I have no idea what goes wrong. If you are bypassing much of osgViewer's context management then it's possible to get the GL obejct caches that the OSG uses out of sync with what you are doing. osgViewer does a range of operations to clean up contexts and make sure the the GL object caches that the OSG uses are flushed. If you are manually managing your own contexts then you'll need to call releaseGLObjects() on your scene graph and call osg::flushAllDeletedGLObjects(contextID) prior to closing the context, if it this is outwith your control then calling discardAllGLObjects(contextID) enables the discarding of all the GL object caches. In the OSG the GL object caches are used to avoid problems with deleting OpenGL objects in other threads than the graphics contexts ones - as scene graphs can be deleted in any thread you need to cache, the cache is also used to enable reuse of OpenGL objects like texture objects and vbo's where possible, this is something that is very useful for paging performance. Robert. ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Problem with corrupted textures when sharing instances of models loaded from IVE format.
Hi, Robert If it'll help to understand where problem might be - there are some details: I dont use any opengl functions directly, so i think osg management of opengl objects should be ok. Here some code i used to setup viewer on creation: On viewer init : graphicsWindow = new osgViewer::GraphicsWindowEmbedded(0,0,width(),height()); viewer-getCamera()-setViewport(new osg::Viewport(0,0,width(),height())); viewer-getCamera()-setGraphicsContext(graphicsWindow); viewer-setThreadingModel(osgViewer::Viewer::SingleThreaded); prior to destructing viewer i used next piece of code (which wasn't there initially, i added this when was trying to fight issue with model corruption, and it actually didnt make any difference): unsigned id = m_Ui.viewer-getCamera()-getGraphicsContext()-getState()-getContextID(); m_Ui.viewer-m_GraphicsWindow-makeCurrent(); osg::deleteAllGLObjects(id); osg::flushAllDeletedGLObjects(id); osg::discardAllGLObjects(id); osgDB::Registry::instance()-clearObjectCache(); osgDB::Registry::instance()-clearArchiveCache(); Scene recreated (without reusing old objects) each time new viewer created. 16.01.2012, 15:35, Robert Osfield robert.osfi...@gmail.com: Hi Sergey, 2012/1/16 Sergey Polischuk pol...@yandex.ru: I've destroyed complete scene with viewer and graphics context, and recreated it all with reading new models from files with disabled cache etc. On first run all was ok, and on next runs mesh would look all distorted (some vertices of mesh randomly displaced etc). Dont know if it problem with display lists or geometry data arrays in osg, but display lists should be brand new each time, because i've deleted all opengl objects before shutting down graphics context, and new context have different id, also object cache disabled, cleared and model reloaded each time from file, so there shouldn't be problem with osg data arrays. I have no idea what goes wrong. If you are bypassing much of osgViewer's context management then it's possible to get the GL obejct caches that the OSG uses out of sync with what you are doing. osgViewer does a range of operations to clean up contexts and make sure the the GL object caches that the OSG uses are flushed. If you are manually managing your own contexts then you'll need to call releaseGLObjects() on your scene graph and call osg::flushAllDeletedGLObjects(contextID) prior to closing the context, if it this is outwith your control then calling discardAllGLObjects(contextID) enables the discarding of all the GL object caches. In the OSG the GL object caches are used to avoid problems with deleting OpenGL objects in other threads than the graphics contexts ones - as scene graphs can be deleted in any thread you need to cache, the cache is also used to enable reuse of OpenGL objects like texture objects and vbo's where possible, this is something that is very useful for paging performance. Robert. ___ 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] Problem with corrupted textures when sharing instances of models loaded from IVE format.
Hi Robert, robertosfield wrote: Is it that you are creating one viewer and context then drawing frames, then later creating a new context and draw more frames. In the later case I can certainly see that if the first frames draw will release the osg::Image resources assigned to osg::Texture if they are set up to unref the images, so disabling the unref of images makes sense. Yes, that's correct, other instances of the viewer may be created after an instance of the viewer has rendered a model, and those later instances may in turn need to render the same cached models. So, mystery solved I think. :-) Thanks. Chris Denham. -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=44866#44866 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Problem with corrupted textures when sharing instances of models loaded from IVE format.
Hi, On 13/01/2012 18:37, Chris Denham wrote: Ah ha, Another interesting experiment doing the round trip from osg to ive and back. e.g. osgconv -O noTexturesInIVEFile cow.osg cow.ive osgconv cow.ive cow2.osg cow2.osg has the same problem and cow.ive, and on comparison on cow.osg and cow2.osg I noticed the image definition has grown an unRefImageDataAfterApply TRUE I get the same texture problem when I load cow2.osg, and it behaves normally again when I set the 'unRefImageDataAfterApply' flag to false. So my guess is that the image data may getting released before the other viewer instance has finished with it? Yes, I think so. See here for changing the unref setting after load: http://article.gmane.org/gmane.comp.graphics.openscenegraph.user/52034 http://thread.gmane.org/gmane.comp.graphics.openscenegraph.user/71893 rgds jp Chris Denham -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=44816#44816 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org -- This message is subject to the CSIR's copyright terms and conditions, e-mail legal notice, and implemented Open Document Format (ODF) standard. The full disclaimer details can be found at http://www.csir.co.za/disclaimer.html. This message has been scanned for viruses and dangerous content by MailScanner, and is believed to be clean. ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Problem with corrupted textures when sharing instances of models loaded from IVE format.
Hi Jp, Thanks for this info. I wrote a node visitor to change the texture setting after load by calling texture-setUnRefImageDataAfterApply(false); and that does indeed seem to fix the problem, so I'm pleased others have come up with the same fix. Though I'm now wondering if I still need to consider the potential problems sharing of opengl objectids between contexts that Robert suggested might have been the problem. i.e. is sharing scene graph data between viewers running on different threads intrinsically safe? It seems stable for me, but I'm wondering if it would be better to implement my own per viewer object cache instead of using the shared one that results from using the cache provided by osg registry singleton. Regards. Chris. J.P. Delport wrote: Hi, On 13/01/2012 18:37, Chris Denham wrote: Ah ha, Another interesting experiment doing the round trip from osg to ive and back. e.g. osgconv -O noTexturesInIVEFile cow.osg cow.ive osgconv cow.ive cow2.osg cow2.osg has the same problem and cow.ive, and on comparison on cow.osg and cow2.osg I noticed the image definition has grown an unRefImageDataAfterApply TRUE I get the same texture problem when I load cow2.osg, and it behaves normally again when I set the 'unRefImageDataAfterApply' flag to false. So my guess is that the image data may getting released before the other viewer instance has finished with it? Yes, I think so. See here for changing the unref setting after load: http://article.gmane.org/gmane.comp.graphics.openscenegraph.user/52034 http://thread.gmane.org/gmane.comp.graphics.openscenegraph.user/71893 rgds jp Chris Denham -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=44816#44816 ___ osg-users mailing list http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org -- This message is subject to the CSIR's copyright terms and conditions, e-mail legal notice, and implemented Open Document Format (ODF) standard. The full disclaimer details can be found at http://www.csir.co.za/disclaimer.html. This message has been scanned for viruses and dangerous content by MailScanner, and is believed to be clean. ___ osg-users mailing list http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org -- Post generated by Mail2Forum -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=44828#44828 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Problem with corrupted textures when sharing instances of models loaded from IVE format.
Hi Robert, To answer your question about how I manage the graphics contexts. I just create a new one for the window handle provided by each instance of my browser plugin e.g Code: traits-inheritedWindowData = new WindowData(hWnd); gc = osg::GraphicsContext::createGraphicsContext(traits); Regards, Chris Denham. robertosfield wrote: Hi Chris, Um... in this type of usage it may well be the easier to have multiple viewers. When you are doing your browser plugin how to you manage the graphics contexts? I suspect the problem may well be down to the OpenGL object ID's for the texture objects being shared inappropriately in your application. The is designed to use a different osg::State::ContextID value for each context, if different contexts use the same value for ContextID then they will share the same OpenGL object ID's which will introduce errors like you've seen. It's not the only way to create the errors, so it's only a hunch on my part. Anyway I don't think there is anything particularly wrong with .ive plugin or the models, all they will be doing is providing us with hints as to what is wrong at a higher level. Robert. ___ osg-users mailing list http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org -- Post generated by Mail2Forum -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=44829#44829 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Problem with corrupted textures when sharing instances of models loaded from IVE format.
Hi Chris, On 14 January 2012 09:30, Chris Denham c.m.den...@gmail.com wrote: Hi Robert, To answer your question about how I manage the graphics contexts. I just create a new one for the window handle provided by each instance of my browser plugin e.g Code: traits-inheritedWindowData = new WindowData(hWnd); gc = osg::GraphicsContext::createGraphicsContext(traits); After gc is assigned check the value of gc-getState()-getContextID() for each of the contexts created. In theory for multiple contexts they should read 0,1,2,etc. Robert. ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
[osg-users] Problem with corrupted textures when sharing instances of models loaded from IVE format.
I'm having some problems connected with the use of textures embedded within IVE
files. The problem arises when I use the same IVE model instance from within
two instances of osgViewer::Viewer which results in unpredictable rendering of
textures in one of the viewer instances, usually the texture goes white when I
delete one viewer instance. If the embedded textures were also compressed, then
I also get some GL errors, typically:
Warning: detected OpenGL error 'invalid enumerant' at after
RenderBin::draw(..)
To be honest, I'm not surprised that this sharing of scene graph data between
osg Viewer instances causes a problem. In fact, I’m surprised that more things
don’t break. However, the reason this scenario crops up is that my osg viewer
is running inside a web based plugin, and hence I get an osg viewer instance
within each instance of the plugin that the web browser creates. You might
now be wondering why the browser plugin instances share any scene graph data,
and in fact I was a bit surprised that they were. I didn’t want them to share
data! It turns out that the reason the browser plugin instances share data is
because of the cache provided by the osg Registry singleton. It would have been
nice if each browser plugin instance ended up with their own osg Registry
singleton, but they don’t!
(I don’t really want to get on my hobby horse about all the pains that the
singleton pattern can cause, but this is certainly one to add to my list)
So, my questions boil down to :
If viewer instance 1 caches “cow.ive” in Registry singleton, how do I prevent
viewer instance 2 from using it?
If it does use the cached version, why does cause a problem (seemingly only
with textures that were embedded in IVE)?
Is there a way to “tweak” the IVE embedded textures so they can be shared
successfully in this scenario?
I have reduced the problem down to a simple example (20 lines or so) that
exhibits the same symptoms:
Code:
static osg::ref_ptrosg::Node model = NULL;
class ViewerThread : public OpenThreads::Thread
{
public:
ViewerThread(int x, int y) : x(x), y(y) { }
void run()
{
osgViewer::Viewer viewer;
viewer.setUpViewInWindow(x, y, 400, 300);
viewer.setSceneData(model);
viewer.run();
}
int x, y;
};
int main(int argc, char* argv[])
{
model = osgDB::readNodeFile(cow.ive);
ViewerThread* thread1 = new ViewerThread(100, 100);
thread1-start();
ViewerThread* thread2 = new ViewerThread(500, 100);
thread2-start();
while(true);
return 0;
}
Chris Denham
--
Read this topic online here:
http://forum.openscenegraph.org/viewtopic.php?p=44810#44810
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Problem with corrupted textures when sharing instances of models loaded from IVE format.
Hi Chris,
Using two independent viewers in an application is not normal or
recommended. I would recommend that you use a single CompositeViewer
with two Views. See the osgcompositeviewer example.
Robert.
On 13 January 2012 14:18, Chris Denham c.m.den...@gmail.com wrote:
I'm having some problems connected with the use of textures embedded within
IVE files. The problem arises when I use the same IVE model instance from
within two instances of osgViewer::Viewer which results in unpredictable
rendering of textures in one of the viewer instances, usually the texture
goes white when I delete one viewer instance. If the embedded textures were
also compressed, then I also get some GL errors, typically:
Warning: detected OpenGL error 'invalid enumerant' at after
RenderBin::draw(..)
To be honest, I'm not surprised that this sharing of scene graph data between
osg Viewer instances causes a problem. In fact, I’m surprised that more
things don’t break. However, the reason this scenario crops up is that my
osg viewer is running inside a web based plugin, and hence I get an osg
viewer instance within each instance of the plugin that the web browser
creates. You might now be wondering why the browser plugin instances share
any scene graph data, and in fact I was a bit surprised that they were. I
didn’t want them to share data! It turns out that the reason the browser
plugin instances share data is because of the cache provided by the osg
Registry singleton. It would have been nice if each browser plugin instance
ended up with their own osg Registry singleton, but they don’t!
(I don’t really want to get on my hobby horse about all the pains that the
singleton pattern can cause, but this is certainly one to add to my list)
So, my questions boil down to :
If viewer instance 1 caches “cow.ive” in Registry singleton, how do I prevent
viewer instance 2 from using it?
If it does use the cached version, why does cause a problem (seemingly only
with textures that were embedded in IVE)?
Is there a way to “tweak” the IVE embedded textures so they can be shared
successfully in this scenario?
I have reduced the problem down to a simple example (20 lines or so) that
exhibits the same symptoms:
Code:
static osg::ref_ptrosg::Node model = NULL;
class ViewerThread : public OpenThreads::Thread
{
public:
ViewerThread(int x, int y) : x(x), y(y) { }
void run()
{
osgViewer::Viewer viewer;
viewer.setUpViewInWindow(x, y, 400, 300);
viewer.setSceneData(model);
viewer.run();
}
int x, y;
};
int main(int argc, char* argv[])
{
model = osgDB::readNodeFile(cow.ive);
ViewerThread* thread1 = new ViewerThread(100, 100);
thread1-start();
ViewerThread* thread2 = new ViewerThread(500, 100);
thread2-start();
while(true);
return 0;
}
Chris Denham
--
Read this topic online here:
http://forum.openscenegraph.org/viewtopic.php?p=44810#44810
___
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] Problem with corrupted textures when sharing instances of models loaded from IVE format.
Hi Robert,
My example code was only meant to show the symtoms of the problem I get it in
my real world code. How can I use a composite viewer to implement views
within multiple browser plugin instances, potentially on different web pages?
Would I have to make the composite viewer a singleton that holds references to
the embedded windows created for each plugin instance? It's never gonna fly!
Interesting update to the problem though; it seems not related to the embedding
of the textures within the IVE, but more to do with the way IVE reader creates
images. The reason being that if I convert cow.osg using osgconv -O
noTexturesInIVEFile cow.osg cow.ive I still get the problem, but if I load
cow.osg into my example, it seems fine.
Chris Denham.
robertosfield wrote:
Hi Chris,
Using two independent viewers in an application is not normal or
recommended. I would recommend that you use a single CompositeViewer
with two Views. See the osgcompositeviewer example.
Robert.
On 13 January 2012 14:18, Chris Denham wrote:
I'm having some problems connected with the use of textures embedded within
IVE files. The problem arises when I use the same IVE model instance from
within two instances of osgViewer::Viewer which results in unpredictable
rendering of textures in one of the viewer instances, usually the texture
goes white when I delete one viewer instance. If the embedded textures were
also compressed, then I also get some GL errors, typically:
Warning: detected OpenGL error 'invalid enumerant' at after
RenderBin::draw(..)
To be honest, I'm not surprised that this sharing of scene graph data
between osg Viewer instances causes a problem. In fact, I’m surprised that
more things don’t break. However, the reason this scenario crops up is that
my osg viewer is running inside a web based plugin, and hence I get an osg
viewer instance within each instance of the plugin that the web browser
creates. You might now be wondering why the browser plugin instances
share any scene graph data, and in fact I was a bit surprised that they
were. I didn’t want them to share data! It turns out that the reason the
browser plugin instances share data is because of the cache provided by the
osg Registry singleton. It would have been nice if each browser plugin
instance ended up with their own osg Registry singleton, but they don’t!
(I don’t really want to get on my hobby horse about all the pains that the
singleton pattern can cause, but this is certainly one to add to my list)
So, my questions boil down to :
If viewer instance 1 caches “cow.ive” in Registry singleton, how do I
prevent viewer instance 2 from using it?
If it does use the cached version, why does cause a problem (seemingly only
with textures that were embedded in IVE)?
Is there a way to “tweak” the IVE embedded textures so they can be shared
successfully in this scenario?
I have reduced the problem down to a simple example (20 lines or so) that
exhibits the same symptoms:
Code:
static osg::ref_ptrosg::Node model = NULL;
class ViewerThread : public OpenThreads::Thread
{
public:
ViewerThread(int x, int y) : x(x), y(y) { }
void run()
{
osgViewer::Viewer viewer;
viewer.setUpViewInWindow(x, y, 400, 300);
viewer.setSceneData(model);
viewer.run();
}
int x, y;
};
int main(int argc, char* argv[])
{
model = osgDB::readNodeFile(cow.ive);
ViewerThread* thread1 = new ViewerThread(100, 100);
thread1-start();
ViewerThread* thread2 = new ViewerThread(500, 100);
thread2-start();
while(true);
return 0;
}
Chris Denham
--
Read this topic online here:
http://forum.openscenegraph.org/viewtopic.php?p=44810#44810
___
osg-users mailing list
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
___
osg-users mailing list
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
--
Post generated by Mail2Forum
--
Read this topic online here:
http://forum.openscenegraph.org/viewtopic.php?p=44813#44813
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Problem with corrupted textures when sharing instances of models loaded from IVE format.
Hi Chris, On 13 January 2012 15:45, Chris Denham c.m.den...@gmail.com wrote: Hi Robert, My example code was only meant to show the symtoms of the problem I get it in my real world code. How can I use a composite viewer to implement views within multiple browser plugin instances, potentially on different web pages? Would I have to make the composite viewer a singleton that holds references to the embedded windows created for each plugin instance? It's never gonna fly! Um... in this type of usage it may well be the easier to have multiple viewers. When you are doing your browser plugin how to you manage the graphics contexts? Interesting update to the problem though; it seems not related to the embedding of the textures within the IVE, but more to do with the way IVE reader creates images. The reason being that if I convert cow.osg using osgconv -O noTexturesInIVEFile cow.osg cow.ive I still get the problem, but if I load cow.osg into my example, it seems fine. I suspect the problem may well be down to the OpenGL object ID's for the texture objects being shared inappropriately in your application. The is designed to use a different osg::State::ContextID value for each context, if different contexts use the same value for ContextID then they will share the same OpenGL object ID's which will introduce errors like you've seen. It's not the only way to create the errors, so it's only a hunch on my part. Anyway I don't think there is anything particularly wrong with .ive plugin or the models, all they will be doing is providing us with hints as to what is wrong at a higher level. Robert. ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Problem with corrupted textures when sharing instances of models loaded from IVE format.
Ah ha, Another interesting experiment doing the round trip from osg to ive and back. e.g. osgconv -O noTexturesInIVEFile cow.osg cow.ive osgconv cow.ive cow2.osg cow2.osg has the same problem and cow.ive, and on comparison on cow.osg and cow2.osg I noticed the image definition has grown an unRefImageDataAfterApply TRUE I get the same texture problem when I load cow2.osg, and it behaves normally again when I set the 'unRefImageDataAfterApply' flag to false. So my guess is that the image data may getting released before the other viewer instance has finished with it? Chris Denham -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=44816#44816 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
