Re: [osg-users] OpenThreads threading bug on creation/deletion (leads to crashes)
Hi Adam, On 9/24/07, Adam Coates [EMAIL PROTECTED] wrote: It looks like there's still a problem with the current setup. The Thread object itself can get deleted before the pthread actually gets to the lock (which, I guess is what you just added). If I understand correctly you are saying that the Thread object is being deleted before the static StartThread function gets called. In this case its rather an awkward problem to solve. Perhaps one could have lock made in the Thread::startThread method that is unlocked by the static StartThread function once it's complete. While it looks like this doesn't cause a crash, the problem is evidenced by valgrind (reports uninitalized memory reads/writes to the lock -- which got freed by the Thread destructor). You seem like you're pretty busy, so if you want, I can take a crack at this -- I think the Thread code is simple enough, but I'll need to think a bit to figure out how to get around this. One (simple) solution is to just join() the thread from the ~Thread() destructor. I expect the valgrind warnings are unrelated to this start problem. Robert. ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] osg-users osgviewerQT
Hi Jim,
I suspect this problem is down to stupid bit of behavior under OSX
that Apple decided was a good idea... basically you have to tell the
OS that you actually want events in your application.
osgViewer::GraphicsWindowCarbon has a call to do this, this must be
missing from QT. The alternative to this call is to provide a
resource file which seems to be the official Apple but still crap
way of doing this.
Robert.
On 9/25/07, James E. Hopper [EMAIL PROTECTED] wrote:
David,
I have an intel mac powerbook. i built using qmake. i created this pro
file:
--
TEMPLATE = app
TARGET =
DEPENDPATH += .
INCLUDEPATH += .
# Input
SOURCES += osgviewerQT.cpp
QT += opengl
DEFINES = USE_QT4
mac {
LIBS = -framework OpenThreads -framework osg -framework osgDB \
-framework osgGA -framework osgViewer -framework osgUtil \
-framework osgText
}
--
then i did
qmake -spec macx-xcode osgviewerQT.pro
this creates an xcode project which i then build and ran.
the window comes up with the model in it. from debugger i know that QT
events are happening and being passed to OSG's GraphicsWindow The timer is
firing and updategl is being called which calls the paint method, which
calls frame(). However nothing is changing in the display. its like its
ignoring the mouse, or the frame() call is doing nothing. So perhaps the
events are not being passed properly?
i notice that there is a graphicswindowcarbon in the osg source, but no
example seems to use it. should it be perhaps used to get proper events to
OSG?
thanks jim
2007/9/24, James E. Hopper james.e.hopper at gmail.com:
David/Robert,
i am on mac. must be a mac issue.
probably.
Other mac-user, have you the same problem?
i have the same problem with the
MDI demo that someone else on the list had posted.
MDI demo work well for me.
Which Qt4 version are you used ?
Can you give more info on you plateform ?
___
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] FBO
Hi Guy, If you destroy a window then all the OpenGL objects associated with it will be removed. If you are using 2.0/osgViewer it should be able to automatically release the OpenGL objects and reallocated them on the new graphics context. Which verison of the OSG/viewer library are you using? Robert. On 9/25/07, [EMAIL PROTECTED] [EMAIL PROTECTED] wrote: Hi Robert, in my application I have the scene graph in some variable, and a camera in another variable, then I attach it to viewer, in multi-document window. After I close the window, the scene graph the camera are still alive. The next time I want to attach them to a new window I get OpenGL error that the frame buffer object is not complete (and nothing is drawn), so I wanted to force the renderstage to re-create it, and achieved this by setting the rendering cache of the existing camera to NULL. I just wanted to know if there is another and better way to deal with this problem, and also if you know why the FBO was defected after the window was closed. thanks, Guy. - Original Message - From: Robert Osfield [EMAIL PROTECTED] To: OpenSceneGraph Users osg-users@lists.openscenegraph.org Sent: Monday, September 24, 2007 3:04 PM Subject: Re: [osg-users] FBO Hi Guy, Have a look at the osgprerender example. You shouldn't need to set anything related to the render cache is this is managed internally. Robert. On 9/24/07, [EMAIL PROTECTED] [EMAIL PROTECTED] wrote: OK, I got over it but I'm not sure that was the best way. What I did was to set the camera rendering cache (for the related contextID) to NULL, so the next time the cull visitor applied on the camera, it recreated the FBO. Any other ideas? thanks, Guy. - Original Message - From: [EMAIL PROTECTED] To: osg-users@lists.openscenegraph.org Sent: Monday, September 24, 2007 1:51 PM Subject: [osg-users] FBO Hi, How do I enforce a camera to recreate FBO attached to the color buffer? thanks, Guy. ___ 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 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] OSG crash in OpenThreads::ScopedLock
Hi Robert, Used the latest SVN. Getting the occasional crash in release now. No crash in debug yet. msvcr71.dll!_lock_fhandle(int fh=4) Line 453 C msvcr71.dll!_close(int fh=) Line 60 + 0x6 C Gert -- Gert van Maren Head of Research Development K2Vi Virtual Reality Software Data Interface Technologies Ltd Phone: +64 21 2855581 Email: [EMAIL PROTECTED] Web: http://www.k2vi.com ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] OpenThreads threading bug on creation/deletion (leads to crashes)
Hi Adamn, On 9/25/07, Robert Osfield [EMAIL PROTECTED] wrote: On 9/24/07, Adam Coates [EMAIL PROTECTED] wrote: It looks like there's still a problem with the current setup. The Thread object itself can get deleted before the pthread actually gets to the lock (which, I guess is what you just added). I have modified osgunittests so it now has a function that tests the creation, start and deletion of a thread, as per code example, you can run it via: osgunittests thread With the yesterdays code it worked fine on my system about 2/3rd of the times that it was run, more if I didn't add the delay (this is now a Thread::microSleep). The tests I did yesterday were done without the delay which is probably why I didn't see any crashes after my first round of fixes yesterday. Armed with a relatively reliable means for recreating the crash I've now set about refactoring the OpenThreads::Thread code so that instead of using a mutex in the start method and destructor it uses a OpenThreads::Block in the Thread::start() method and static StartThread() function such that the thread that calls the thread-startThread() will be held back until the new thread has been successfully started. With this change I'm now able to run the osgunittest thread test 1000 times without error (I use a repeat script to do this). I have also rolled these changes into Windows and IRIX spoc code paths, revert the previous Mutex based code. Could you check out the latest version in SVN and let me know if this problem is now properly fixed. Robert. ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
[osg-users] applying textures
Hi to all!
i'm a newbie of osg and i would share my problem with the
community...
i'm developing a VR application which should load various kind of 3D
models (mainly flt and osg/ive), insert them into an appropriate
environement and allow to modify all the scenegraph at runtime. in fact it
shows the scenegraph and the user can decide to change positions of nodes,
their visibility, etc. When the user chooses to modify the texture of these
models, he searches the disk for a good looking image (bmp, jpg, etc), but
the texture is not mapped correctly (the node selected by the user changes
only its color, texture too big ). otherwise when he applies these
textures onto the environement sphere or the terrain, all look more or less
correct. I use an extended nodevisitor to traverse the scenegraph from the
node choosed by the user in search of geodes. Every time the visitor finds a
geode it does:
int Num = geode.getNumDrawables();
for(int j = 0; j Num; j++) {
osg::StateSet* stateset = geode.getDrawable
(j)-getOrCreateStateSet();
osg::Texture2D* myTexture=new osg::Texture2D;
myTexture-setDataVariance(osg::Object::DYNAMIC);
myTexture-setImage(myImage);
stateset-setTextureAttributeAndModes(0, myTexture,
osg::StateAttribute::OVERRIDE|osg::StateAttribute::ON);
geode.getDrawable(j)-setStateSet(stateset);
}
I'm in trouble understanding texture mapping. I looked at BumpMapping to get
useful hints about texcoordgenerator... but i don't know how to use it.
Having multiple geometries, how to map them correctly or even
approssimatively?
Can anyone help me??
Sorry for my maybe silly question but I'm new to to the computer graphics
world!
I'd be very grateful..
Many thanks in advance..
Enrico
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] FBO
I'm using the OSG 1.2 version, but I have the code of the OSG2.0 to compare with, and the clean up is similar. I also try to keep the questions not specific to the 1.2 implementation I noticed that on the clean_frame, the pass over the scene doesn't get to all the objects for some reason. For example, it releases only one texture object while there suppose to be two, and it gets only to one camera of the pair of RTT and show texture on screen cameras. and I'm now debugging it. Maybe I changed the scene and lose pointers to objects somewhere... Could it be that since one of the camera is pre-render and the other is nested, that the cleanup get only to the nested rendered camera? thanks, Guy. - Original Message - From: Robert Osfield [EMAIL PROTECTED] To: OpenSceneGraph Users osg-users@lists.openscenegraph.org Sent: Tuesday, September 25, 2007 10:10 AM Subject: Re: [osg-users] FBO Hi Guy, If you destroy a window then all the OpenGL objects associated with it will be removed. If you are using 2.0/osgViewer it should be able to automatically release the OpenGL objects and reallocated them on the new graphics context. Which verison of the OSG/viewer library are you using? Robert. On 9/25/07, [EMAIL PROTECTED] [EMAIL PROTECTED] wrote: Hi Robert, in my application I have the scene graph in some variable, and a camera in another variable, then I attach it to viewer, in multi-document window. After I close the window, the scene graph the camera are still alive. The next time I want to attach them to a new window I get OpenGL error that the frame buffer object is not complete (and nothing is drawn), so I wanted to force the renderstage to re-create it, and achieved this by setting the rendering cache of the existing camera to NULL. I just wanted to know if there is another and better way to deal with this problem, and also if you know why the FBO was defected after the window was closed. thanks, Guy. - Original Message - From: Robert Osfield [EMAIL PROTECTED] To: OpenSceneGraph Users osg-users@lists.openscenegraph.org Sent: Monday, September 24, 2007 3:04 PM Subject: Re: [osg-users] FBO Hi Guy, Have a look at the osgprerender example. You shouldn't need to set anything related to the render cache is this is managed internally. Robert. On 9/24/07, [EMAIL PROTECTED] [EMAIL PROTECTED] wrote: OK, I got over it but I'm not sure that was the best way. What I did was to set the camera rendering cache (for the related contextID) to NULL, so the next time the cull visitor applied on the camera, it recreated the FBO. Any other ideas? thanks, Guy. - Original Message - From: [EMAIL PROTECTED] To: osg-users@lists.openscenegraph.org Sent: Monday, September 24, 2007 1:51 PM Subject: [osg-users] FBO Hi, How do I enforce a camera to recreate FBO attached to the color buffer? thanks, Guy. ___ 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 ___ 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] may be some bug in dds plugin
Just to add my 2p, the changes I submitted would only be seen as colour
changes (red/blue swap) on dds write; I didn't do anything with regard to
file sizes.
The image is DXT1 encoded, and includes 6 levels of mipmap. I had a quick
look, and it's falling over in the osgImage.release() method at the end of
the ReadDDSFile method - in particular, the destructor for the mipmaps
vector. My debugging skills are pretty primitive, but heres a stack trace in
case it helps anybody:
msvcr71d.dll!_free_dbg_lk(void * pUserData=0x00239f20, int
nBlockUse=1) Line 1154 + 0x3bC
msvcr71d.dll!_free_dbg(void * pUserData=0x00239f20, int nBlockUse=1)
Line 1070 + 0xdC
msvcr71d.dll!operator delete(void * pUserData=0x00239f20) Line 54 +
0x10C++
osgdb_ddsd.dll!std::allocatorunsigned int::deallocate(unsigned int *
_Ptr=0x00239f20, unsigned int __formal=6) Line 132 + 0x9C++
osgdb_ddsd.dll!std::vectorunsigned int,std::allocatorunsigned int
::_Tidy() Line 797C++
osgdb_ddsd.dll!std::vectorunsigned int,std::allocatorunsigned int
::~vectorunsigned int,std::allocatorunsigned int () Line 389C++
osgdb_ddsd.dll!ReadDDSFile(std::basic_istreamchar,std::char_traitschar
_istream={...}) Line 696 + 0x20C++
osgdb_ddsd.dll!ReaderWriterDDS::readImage(std::basic_istreamchar,std::char_traitschar
fin={...}, const osgDB::ReaderWriter::Options * options=0x)
Line 959 + 0x9C++
osgdb_ddsd.dll!ReaderWriterDDS::readImage(const
std::basic_stringchar,std::char_traitschar,std::allocatorchar
file={...},
I also generated a similarly DXT1 encoded DDS from scratch, with various
levels of mipmap, with and without alpha, and it loaded and displayed fine.
Plus the original (unmipmapped image) should be 2048 bytes (64 x 64, DXT1 =
1 byte per 2 pixels); this and the relative mipmap data positioning, and
total size, of your image, seems OK.
So I'm lost - sorry.
The image is DXT1 encoded; perhaps try writing it uncompressed?
This doesn't help you, but I have noticed that many 3rd party DDS viewing
apps are inconsistent with regards to how they interpret DDS images, so it's
sometimes worth checking a few apps. XnView seems to read the image fine;
ATI's DDS reader (Compressonator) can't read it at all.
David
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] may be some bug in dds plugin
Ah - just noticed. The DDS file you attached claims to have 10 mipmaps, but there is only data for (and it only makes sense to have) 7. So, firstly, something looks broken in whatever wrote the file, in terms of retrieving the number of mipmaps. Setting it to a low value during the image load works; i.e. the file reads fine. As an aside, I just generated a DDS with 128x128, but only data for 5 mipmap levels; on loading, image-getNumMipmapLevels reports 8 (i.e. what you would expect for a fully mipmapped 128x128 image). I haven't tracked this down any further, though (and won't have time to at present). David ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] FBO
Hi Guy, 2.x and 1.2 and substantially different when it comes to management of clean up of graphics contexts. I suggest you upgrade, your problems might be fixed right away, but if not then there is much better chance that others will be able to support you. Robert. On 9/25/07, [EMAIL PROTECTED] [EMAIL PROTECTED] wrote: I'm using the OSG 1.2 version, but I have the code of the OSG2.0 to compare with, and the clean up is similar. I also try to keep the questions not specific to the 1.2 implementation I noticed that on the clean_frame, the pass over the scene doesn't get to all the objects for some reason. For example, it releases only one texture object while there suppose to be two, and it gets only to one camera of the pair of RTT and show texture on screen cameras. and I'm now debugging it. Maybe I changed the scene and lose pointers to objects somewhere... Could it be that since one of the camera is pre-render and the other is nested, that the cleanup get only to the nested rendered camera? thanks, Guy. - Original Message - From: Robert Osfield [EMAIL PROTECTED] To: OpenSceneGraph Users osg-users@lists.openscenegraph.org Sent: Tuesday, September 25, 2007 10:10 AM Subject: Re: [osg-users] FBO Hi Guy, If you destroy a window then all the OpenGL objects associated with it will be removed. If you are using 2.0/osgViewer it should be able to automatically release the OpenGL objects and reallocated them on the new graphics context. Which verison of the OSG/viewer library are you using? Robert. On 9/25/07, [EMAIL PROTECTED] [EMAIL PROTECTED] wrote: Hi Robert, in my application I have the scene graph in some variable, and a camera in another variable, then I attach it to viewer, in multi-document window. After I close the window, the scene graph the camera are still alive. The next time I want to attach them to a new window I get OpenGL error that the frame buffer object is not complete (and nothing is drawn), so I wanted to force the renderstage to re-create it, and achieved this by setting the rendering cache of the existing camera to NULL. I just wanted to know if there is another and better way to deal with this problem, and also if you know why the FBO was defected after the window was closed. thanks, Guy. - Original Message - From: Robert Osfield [EMAIL PROTECTED] To: OpenSceneGraph Users osg-users@lists.openscenegraph.org Sent: Monday, September 24, 2007 3:04 PM Subject: Re: [osg-users] FBO Hi Guy, Have a look at the osgprerender example. You shouldn't need to set anything related to the render cache is this is managed internally. Robert. On 9/24/07, [EMAIL PROTECTED] [EMAIL PROTECTED] wrote: OK, I got over it but I'm not sure that was the best way. What I did was to set the camera rendering cache (for the related contextID) to NULL, so the next time the cull visitor applied on the camera, it recreated the FBO. Any other ideas? thanks, Guy. - Original Message - From: [EMAIL PROTECTED] To: osg-users@lists.openscenegraph.org Sent: Monday, September 24, 2007 1:51 PM Subject: [osg-users] FBO Hi, How do I enforce a camera to recreate FBO attached to the color buffer? thanks, Guy. ___ 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 ___ 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] Problems with the latest registry version
Hi Robert, I have a plugin to read some paged tiles. Our plugins are registered by code and don't use a dll system. It worked fine before the update. But yesterday, I updated my osg svn version and now the registry is saying that can't read the plugin. I debug it and it seems like the registry doesn't search the plugin in the list and searchs it like a library. Did you make some change in the registry recently? I tried to find it in the logs but i didn't found it. Well, i have another bug too. We have a viewer in Java using jogl but recently it crashed when we run in a ATI graphic card. We tried to test the viewer with the osg cow and it worked in ATI too. The bug is when we try to load some paged tiles build with osgTerrain. It crashes in the call compileGLobjects because in the debugger you can see that there isn't a compile context. I can't debug now beacause the other bug don't let me. Have you some ideas? Thaks for all. -- María Ten Rodríguez Instituto de Automática e Informática Industrial http://www.ai2.upv.es Ciudad Politécnica de la Innovación Universidad Politécnica de Valencia ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
[osg-users] pbuffer performance
Hi Guys,
This question is not directly related to OSG, but I hope the OSG users
must have answer to this problem and the reason i am asking this on this
forum is that because the OSG has most number of OpenGL experts.;)
I am transfering data from one pbuffer to other pbuffer using
glCopyPixel and the transfer rate is two slow, 1MB/sec on my Nvidia
Quadro 4600 (512MB) graphics card.
Can some one tell me what can be the problem. The detail description of
what i am doing is given below.
The two pbuffers i have created using glXCreatePbuffer
with GLXFBConfig atributes as mentioned below
int attrib[] =
{
GLX_DOUBLEBUFFER, True,
GLX_RED_SIZE, 8,
GLX_GREEN_SIZE, 8,
GLX_BLUE_SIZE, 8,
GLX_ALPHA_SIZE, 8,
GLX_RENDER_TYPE, GLX_RGBA_BIT,
GLX_DRAWABLE_TYPE, GLX_PBUFFER_BIT,
None
}
The attributes of the pbuufer are
int pbufAttrib[] =
{
GLX_PBUFFER_WIDTH, 512,
GLX_PBUFFER_HEIGHT, 512,
GLX_LARGEST_PBUFFER, True,
GLX_PRESERVED_CONTENTS,True,
None
}
Now i created a context (contx0) and made the context current w.r.t
pbuffer0.
Now using glDrawPixel i draw an image in pbuffer0.
Now using glXMakeContextCurrent(display,pbuufer1(drawable),
pbuffer0(readable), contx0);
i set the context so that pixelBuffer1 is my drawable and pixelBuffer0
is my readable buffer.
Now i am copying tha data from pixelBuffer0 to PixelBufer1 using
glCopyPixel() and that is where i am getting the performace hit.
Since i am transfering data from GPU to GPU the transfer rate should be
very high (GB/sec)
but i am getting aroung 1MB/sec.
Thanks in advance
rj
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Problems with the latest registry version
Hi María, There have been changes to Registry but I don't recall any that should break your usage model. Tracs provides online browsing of changes, the place for Registry.cpp is: http://www.openscenegraph.org/projects/osg/log/OpenSceneGraph/trunk/src/osgDB/Registry.cpp Click on the ChngSt entry to see what the diffs are on each checkin. As for a crash on an ATI card, when used with a Java, this is well beyond what I have access to, experience of. It could be an ATI driver bug, it could be a Java related issue, it could be an OSG that only appears in certain usage models. With so little to go on there is nothing I can do to divine what might be wrong though. Robert. On 9/25/07, María Ten [EMAIL PROTECTED] wrote: Hi Robert, I have a plugin to read some paged tiles. Our plugins are registered by code and don't use a dll system. It worked fine before the update. But yesterday, I updated my osg svn version and now the registry is saying that can't read the plugin. I debug it and it seems like the registry doesn't search the plugin in the list and searchs it like a library. Did you make some change in the registry recently? I tried to find it in the logs but i didn't found it. Well, i have another bug too. We have a viewer in Java using jogl but recently it crashed when we run in a ATI graphic card. We tried to test the viewer with the osg cow and it worked in ATI too. The bug is when we try to load some paged tiles build with osgTerrain. It crashes in the call compileGLobjects because in the debugger you can see that there isn't a compile context. I can't debug now beacause the other bug don't let me. Have you some ideas? Thaks for all. -- María Ten Rodríguez Instituto de Automática e Informática Industrial http://www.ai2.upv.es Ciudad Politécnica de la Innovación Universidad Politécnica de Valencia ___ 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] pbuffer performance
Hi RJ,
glCopyPixels will be doing a round trip to the CPU. You might be able
to help out by using a PixelBuffer object for reading and writing, but
as general advice I have to say absolutely don't code the problem in
the way your are doing as it will be slow. Use FBO to render a
texture and then render a quad screen aligned, don't use glCopyPixels
and glDrawPixels at all.
Robert.
On 9/24/07, Rahul Jain [EMAIL PROTECTED] wrote:
Hi Guys,
This question is not directly related to OSG, but I hope the OSG users
must have answer to this problem and the reason i am asking this on this
forum is that because the OSG has most number of OpenGL experts.;)
I am transfering data from one pbuffer to other pbuffer using
glCopyPixel and the transfer rate is two slow, 1MB/sec on my Nvidia
Quadro 4600 (512MB) graphics card.
Can some one tell me what can be the problem. The detail description of
what i am doing is given below.
The two pbuffers i have created using glXCreatePbuffer
with GLXFBConfig atributes as mentioned below
int attrib[] =
{
GLX_DOUBLEBUFFER, True,
GLX_RED_SIZE, 8,
GLX_GREEN_SIZE, 8,
GLX_BLUE_SIZE, 8,
GLX_ALPHA_SIZE, 8,
GLX_RENDER_TYPE, GLX_RGBA_BIT,
GLX_DRAWABLE_TYPE, GLX_PBUFFER_BIT,
None
}
The attributes of the pbuufer are
int pbufAttrib[] =
{
GLX_PBUFFER_WIDTH, 512,
GLX_PBUFFER_HEIGHT, 512,
GLX_LARGEST_PBUFFER, True,
GLX_PRESERVED_CONTENTS,True,
None
}
Now i created a context (contx0) and made the context current w.r.t
pbuffer0.
Now using glDrawPixel i draw an image in pbuffer0.
Now using glXMakeContextCurrent(display,pbuufer1(drawable),
pbuffer0(readable), contx0);
i set the context so that pixelBuffer1 is my drawable and pixelBuffer0
is my readable buffer.
Now i am copying tha data from pixelBuffer0 to PixelBufer1 using
glCopyPixel() and that is where i am getting the performace hit.
Since i am transfering data from GPU to GPU the transfer rate should be
very high (GB/sec)
but i am getting aroung 1MB/sec.
Thanks in advance
rj
___
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] osgviewerQT
Robert, I agree something is happening with events, but its not the wrapper issue. Well if i understand what you are saying I am building it as an application with proper wrapper. thats why i used qmake which knows how to build a standard universal mac application. In addition i verified that qt events are happening. the data is going to osg, just not being used by osg as far as i can seen. i will look more deeply at GraphicsWindowCarbon to see if there is something else missing. best jim there may be something else in carbon version, but its not the wrapper problem that has been discussed in the past. best jim I suspect this problem is down to stupid bit of behavior under OSX that Apple decided was a good idea... basically you have to tell the OS that you actually want events in your application. osgViewer::GraphicsWindowCarbon has a call to do this, this must be missing from QT. The alternative to this call is to provide a resource file which seems to be the official Apple but still crap way of doing this. ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
[osg-users] osgDotNet : Nodes adding to scene graph outside main() function scope
Hi everyone,
I don't know if I was very clear in my last post. My problem is to implement in
C# small sfx in nodes in the scenegraph...
The fact is that as soon as the Osg.Node (in the example the _root
Osg.PositionAttitudeTransform) that is added to the scene is enterily monitored
by a C# class (and not statically or locally defined in the main loop
function), there seems to occur destruction on that Node being nonetheless
regular in term of OSG reference count (the _root is held by the MySfxInstance,
added to the sceneGraph, and therefore its ref count is 1).
Of course, in osgDotNet (managed code), ref_ptr and
osg::Referenced::ref()/unref() aren't ported.
I'm assuming that reference count managing is done according CLR behaviour (as
long as a reference on your instance is held by someone, the CLR doesn't invoke
Dispose on that instance).
Am I missing something obvious ?
Am I the only one using osgDotNet having this problem ?
{ Hereafter follow the same code I sent on friday, focusing on the important
class and functions and simplified of #regions and unsignicant comments : }
file MySfx.cs
public class MySfx
{
protected Osg.PositionAttitudeTransform _root;
protected Osg.Group _psScene;
public MySfx(float fFar)
{
_root = null;
_psScene = null;
// Sub scenegraph creation
_root = new Osg.PositionAttitudeTransform();
_root.setName(SkyModel_Root);
//_root.setDataVariance(Osg.Object.DataVariance.DYNAMIC);
// Init update callback
_root.setUpdateCallback(new Oktal.OvOsg.MySfxUpdateCallback(this));
}
public void setScene(Osg.Group psScene)
{
if (psScene != null)
{
_psScene = psScene;
_psScene.addChild(_root);
}
}
public void update()
{
// Place update code here
}
}
internal class MySfxUpdateCallback: Osg.NodeCallback
{
protected Oktal.OvOsg.MySfx _mySfx;
public MySfxUpdateCallback(Oktal.OvOsg.MySfx mysfx)
{
_mySfx = mysfx;
}
public override void op_FunctionCall(Osg.Node node, Osg.NodeVisitor nv)
{
if (_mySfx != null)
{
_mySfx.update();
}
traverse(node, nv);
}
}
file Program.cs
static void Main(string[] args)
{
// (...)
// load the data
Osg.Node loadedModel =
OsgViewerExe.OsgDotNetGlobals.osgDBReadNodeFiles(arguments, new
OsgDB.ReaderWriter.Options());
// (...)
// optimize the scene graph, remove redundant nodes and state etc.
OsgUtil.Optimizer optimizer = new OsgUtil.Optimizer();
optimizer.optimize(loadedModel);
// DEDICATED CODE HERE
Osg.Group root = new Osg.Group();
Osg.BoundingSphere info = loadedModel.computeBound();
root.addChild(loadedModel);
Oktal.OvOsg.MySfx sfx = new Oktal.OvOsg.MySfx(info.radius());
sfx.setScene(root); // equals root.addChild(skyModel);
// END DEDICATED CODE
// Comment that (default view is away from the scene) shows the bug
better...
//viewer.getCameraManipulator().setHomePosition(new Osg.Vec3d(0.0, -10.0,
50.0), new Osg.Vec3d(0.0, 0.0, 50.0), new Osg.Vec3d(0.0, 0.0, 1.0));
viewer.setSceneData(root);
viewer.run();
}
Thx for any advice !
--
Christophe Médard
Société OKTAL (http://www.oktal.fr)
2 impasse Boudeville
31100 Toulouse (France)
Tél. : (+33) 5 62 11 50 10
Fax : (+33) 5 62 11 50 29
- Original Message -
From: Christophe Medard
To: osg-users@lists.openscenegraph.org
Sent: Friday, September 21, 2007 5:47 PM
Subject: osgDotNet : Nodes adding to scene graph outside main() function scope
Hi all,
If I can still think straight (after such a long week), there seems to be a
major problem for people that want to code special Effects in osgDotNet in C#
:
If you want to add to your main scenegraph osg::Nodes that are held by (because
created, updated and modified by) an SFX class, you quickly have memory
corruption problems due to the fact that Dispose calls are done on those nodes
whose reference count is greater than 0.
This problem doesn't occur in a similar code written in C++ - using native osg
dlls - in which a destructor is implementable for the SFX class, and
osg::Referenced::ref() (resp. unref()) methods can be called when osg::Nodes
are created (resp. inside SFX class' destructor).
I'm attaching a very short C# example illustrating that.
The application crashes rapidly, in Release or Debug. The shallow Debug trace
is :
I must say to be complete that for instance I'm using version 2.0.0 of OSG and
osgWrappers.
If there's is a way to avoid those Dispose calls on regular Nodes I'm
interested to know !!
(My preceeding attemps of sfx implementation in C# where done roughly entirely
in the main() function, which doesn't raise problems...)
--
Christophe Médard
Société OKTAL (http://www.oktal.fr)
2 impasse Boudeville
31100 Toulouse (France)
Tél. : (+33) 5 62 11 50 10
Fax : (+33) 5 62 11 50 29___
osg-users mailing
Re: [osg-users] using Mesa instead of opengl
Did you use glut on top of Mesa? Does glut support 16 bits/32 bits color channel? If not do you know another toolkit that can be use instead of glut? Thanks Jo On 9/25/07, J.P. Delport [EMAIL PROTECTED] wrote: Hi, we have used it with OSMesa to get float colour channels. jp Jonathan Richard wrote: Hi, did someone try to run open scene graph with Mesa instead of opengl? Is it working? Or is it possible to use 16 bits color channel with opengl instead of 8 bits color channel? Thanks Jo ___ 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. MailScanner thanks Transtec Computers for their support. ___ 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] (no subject)
Hi everybody, I'm new in delveloping with osg and I have a problem with texturing. I created a heightmap composed of triangles. Now I want to texture this plane. My problem is that I don't know how to do that. If I have a 3x3 map I have 16 vertices. As said in the pyramid-example there must be 1 texture coordinate for each vertex. But my 3x3 quads are consisting of two triangles so I have to use three texturecoordinates per triangle. Alltogether 54 of them. If I try to implement the texturing, nothing senceful is displayed. I think this is because of the double use of the vertices. Has anyone an idea how to fix my problem? Thanks a lot, Jan -- Ist Ihr Browser Vista-kompatibel? Jetzt die neuesten Browser-Versionen downloaden: http://www.gmx.net/de/go/browser ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] using Mesa instead of opengl
Hi, we render off-screen to an OSMesa context in CPU memory using OSG's SceneView, so I'm not sure about any support in toolkits or visual displays for 8bits per channel. regards jp Jonathan Richard wrote: Did you use glut on top of Mesa? Does glut support 16 bits/32 bits color channel? If not do you know another toolkit that can be use instead of glut? Thanks Jo On 9/25/07, J.P. Delport [EMAIL PROTECTED] wrote: Hi, we have used it with OSMesa to get float colour channels. jp Jonathan Richard wrote: Hi, did someone try to run open scene graph with Mesa instead of opengl? Is it working? Or is it possible to use 16 bits color channel with opengl instead of 8 bits color channel? Thanks Jo ___ 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. MailScanner thanks Transtec Computers for their support. ___ 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 -- 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. MailScanner thanks Transtec Computers for their support. ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] osgDotNet : Nodes adding to scene graph outside main()function scope
Hi Christophe,
This sounds like a bug that Jason reported where a particle system under a PAT
node gives the same symptoms -
http://www.openscenegraph.org/projects/osgDotNet/ticket/1. I've dug into that
problem some, but only enough to know that it will take quite a bit more time
to track down the root cause.
You're correct about the reference count management; it's intended to be
completely handled by the wrappers and transparent to the C# user. Obviously
something is going wrong in this particular case.
Mike Wittman
[EMAIL PROTECTED] mailto:[EMAIL PROTECTED]
___
Seismic Micro-Technology, Inc.
8584 Katy Freeway, Suite 400 / Houston, Texas 77024
Tel. +1 (713) 464-6188
Fax. +1 (713) 464-6440
Web: www.seismicmicro.com blocked::blocked::http://www.seismicmicro.com
___
CONTACT US TODAY for more information.
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Christophe Medard
Sent: Tuesday, September 25, 2007 7:59 AM
To: osg-users@lists.openscenegraph.org
Subject: [osg-users] osgDotNet : Nodes adding to scene graph outside
main()function scope
Hi everyone,
I don't know if I was very clear in my last post. My problem is to implement in
C# small sfx in nodes in the scenegraph...
The fact is that as soon as the Osg.Node (in the example the _root
Osg.PositionAttitudeTransform) that is added to the scene is enterily monitored
by a C# class (and not statically or locally defined in the main loop
function), there seems to occur destruction on that Node being nonetheless
regular in term of OSG reference count (the _root is held by the MySfxInstance,
added to the sceneGraph, and therefore its ref count is 1).
Of course, in osgDotNet (managed code), ref_ptr and
osg::Referenced::ref()/unref() aren't ported.
I'm assuming that reference count managing is done according CLR behaviour (as
long as a reference on your instance is held by someone, the CLR doesn't invoke
Dispose on that instance).
Am I missing something obvious ?
Am I the only one using osgDotNet having this problem ?
{ Hereafter follow the same code I sent on friday, focusing on the important
class and functions and simplified of #regions and unsignicant comments : }
file MySfx.cs
public class MySfx
{
protected Osg.PositionAttitudeTransform _root;
protected Osg.Group _psScene;
public MySfx(float fFar)
{
_root = null;
_psScene = null;
// Sub scenegraph creation
_root = new Osg.PositionAttitudeTransform();
_root.setName(SkyModel_Root);
//_root.setDataVariance(Osg.Object.DataVariance.DYNAMIC);
// Init update callback
_root.setUpdateCallback(new Oktal.OvOsg.MySfxUpdateCallback(this));
}
public void setScene(Osg.Group psScene)
{
if (psScene != null)
{
_psScene = psScene;
_psScene.addChild(_root);
}
}
public void update()
{
// Place update code here
}
}
internal class MySfxUpdateCallback: Osg.NodeCallback
{
protected Oktal.OvOsg.MySfx _mySfx;
public MySfxUpdateCallback(Oktal.OvOsg.MySfx mysfx)
{
_mySfx = mysfx;
}
public override void op_FunctionCall(Osg.Node node, Osg.NodeVisitor nv)
{
if (_mySfx != null)
{
_mySfx.update();
}
traverse(node, nv);
}
}
file Program.cs
static void Main(string[] args)
{
// (...)
// load the data
Osg.Node loadedModel =
OsgViewerExe.OsgDotNetGlobals.osgDBReadNodeFiles(arguments, new
OsgDB.ReaderWriter.Options());
// (...)
// optimize the scene graph, remove redundant nodes and state etc.
OsgUtil.Optimizer optimizer = new OsgUtil.Optimizer();
optimizer.optimize(loadedModel);
// DEDICATED CODE HERE
Osg.Group root = new Osg.Group();
Osg.BoundingSphere info = loadedModel.computeBound();
root.addChild(loadedModel);
Oktal.OvOsg.MySfx sfx = new Oktal.OvOsg.MySfx(info.radius());
sfx.setScene(root); // equals root.addChild(skyModel);
// END DEDICATED CODE
// Comment that (default view is away from the scene) shows the bug
better...
//viewer.getCameraManipulator().setHomePosition(new Osg.Vec3d(0.0, -10.0,
50.0), new Osg.Vec3d(0.0, 0.0, 50.0), new Osg.Vec3d(0.0, 0.0, 1.0));
viewer.setSceneData(root);
viewer.run();
}
Thx for any advice !
--
Christophe Médard
Société OKTAL (http://www.oktal.fr)
2 impasse Boudeville
31100 Toulouse (France)
Tél. : (+33) 5 62 11 50 10
Fax : (+33) 5 62 11 50 29
- Original Message -
From: Christophe Medard
To: osg-users@lists.openscenegraph.org
Sent: Friday, September 21, 2007 5:47 PM
Subject: osgDotNet : Nodes adding to scene graph outside main() function scope
Hi all,
If I can still think straight (after such a long week), there seems to be a
major problem for people that want to code
[osg-users] MODKEY_CTRL problem
Hi! I still have problems with MODKEY_CTRL modifiers. See http://osgcvs.no-ip.com/osgarchiver/archives/May2007/0203.html. Also another problem I have is that if I switch to another application and then I switch back to my OSG app, it seems that I can't catch key events anymore! Thanks in advance. Panagiotis Papadakos ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] (no subject)
Hi Jan Take a look to the ShapeDrawable::accept(const HeightField field) to see how osg render a height field. Take a look to the osgtexture2d example to know how to enable and render texture. HTH David ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] osgDotNet : Nodes adding to scene graph outsidemain()function scope
Hi Mike, I tried to do some debugging with regards to the PAT issue I added and it has something to do with the finalizer being run a NodeVisitor object, but that's about as far as I got. I couldn't understand why it would be an issue for nodes containing particle systems, but other nodes are fine. I think it has something to do with the adapter pattern being used that allows a user to subclass Nodes in C#, but I haven't gotten any further. Jason On 9/25/07, Christophe Medard [EMAIL PROTECTED] wrote: Hi Mike, Thanks for telling me the same kind of thing was already reported ! I understand passin in OSG 2.1.12 would do no good. Thanks also for confirming the OSG reference count management being done by the wrapper layer in a .NET Managed-fashion... It's quite hard to find the root cause indeed, since it seems to depend on independant factor, like where the camera is -initially- positionned : I only get the problem when letting osgViewer set it away from the scene (no osgViewer.getCameraManipulator().setHomePosition() call in my mainloop). There's something about an intersect visitor apparently (a culling pass ?). One could think it's only where the AccessViolation first occur. I'm not sure : if I initialize the camera close to the scene geometry, not only does my AccessViolation vanish, but I don't have the OSG Notice warning about a possible problem anymore either. That whether I leave space between my point of the scene and scene geometry through manipulator's behaviour afterwards in the run time of my application... Anyway, if anyone happen to lock the root cause, please don't hesitate to post ! -- Christophe Médard Société OKTAL (http://www.oktal.fr) 2 impasse Boudeville 31100 Toulouse (France) Tél. : (+33) 5 62 11 50 10 Fax : (+33) 5 62 11 50 29 - Original Message - *From:* Mike Wittman [EMAIL PROTECTED] *To:* OpenSceneGraph Users osg-users@lists.openscenegraph.org *Sent:* Tuesday, September 25, 2007 3:58 PM *Subject:* Re: [osg-users] osgDotNet : Nodes adding to scene graph outsidemain()function scope Hi Christophe, This sounds like a bug that Jason reported where a particle system under a PAT node gives the same symptoms - http://www.openscenegraph.org/projects/osgDotNet/ticket/1. I've dug into that problem some, but only enough to know that it will take quite a bit more time to track down the root cause. You're correct about the reference count management; it's intended to be completely handled by the wrappers and transparent to the C# user. Obviously something is going wrong in this particular case. *Mike Wittman* [EMAIL PROTECTED] *___* *Seismic Micro-Technology, Inc.* *8584 Katy Freeway, **Suite 400 / Houston, Texas 77024* *Tel. +1 (713) 464-6188* *Fax. +1 (713) 464-6440* *Web: www.seismicmicro.com* *___* *CONTACT US TODAY for more information.* ___ 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] MODKEY_CTRL problem
On Tue, 25 Sep 2007, Panagiotis Papadakos wrote: Also another problem I have is that if I switch to another application and then I switch back to my OSG app, it seems that I can't catch key events anymore! Well the above is probably my problem, because osgkeyboard works! Panagiotis Papadakos ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] MODKEY_CTRL problem
Hi Panagiotis, Which version of the OSG are you using? Robert. On 9/25/07, Panagiotis Papadakos [EMAIL PROTECTED] wrote: Hi! I still have problems with MODKEY_CTRL modifiers. See http://osgcvs.no-ip.com/osgarchiver/archives/May2007/0203.html. Also another problem I have is that if I switch to another application and then I switch back to my OSG app, it seems that I can't catch key events anymore! Thanks in advance. Panagiotis Papadakos ___ 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] osgDotNet : Nodes adding to scene graphoutsidemain()function scope
Hi Christophe, The dependency on camera position is an interesting and potentially important insight. There may be some location-related conditional behavior within the native code that osgDotNet is not handling properly. Can you tell me generally what is contained in the scene graphs of the models that you are loading? That may have some bearing on the problem. -Mike From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Christophe Medard Sent: Tuesday, September 25, 2007 9:43 AM To: OpenSceneGraph Users Subject: Re: [osg-users] osgDotNet : Nodes adding to scene graphoutsidemain()function scope Hi Mike, Thanks for telling me the same kind of thing was already reported ! I understand passin in OSG 2.1.12 would do no good. Thanks also for confirming the OSG reference count management being done by the wrapper layer in a .NET Managed-fashion... It's quite hard to find the root cause indeed, since it seems to depend on independant factor, like where the camera is -initially- positionned : I only get the problem when letting osgViewer set it away from the scene (no osgViewer.getCameraManipulator().setHomePosition() call in my mainloop). There's something about an intersect visitor apparently (a culling pass ?). One could think it's only where the AccessViolation first occur. I'm not sure : if I initialize the camera close to the scene geometry, not only does my AccessViolation vanish, but I don't have the OSG Notice warning about a possible problem anymore either. That whether I leave space between my point of the scene and scene geometry through manipulator's behaviour afterwards in the run time of my application... Anyway, if anyone happen to lock the root cause, please don't hesitate to post ! -- Christophe Médard Société OKTAL (http://www.oktal.fr) 2 impasse Boudeville 31100 Toulouse (France) Tél. : (+33) 5 62 11 50 10 Fax : (+33) 5 62 11 50 29 - Original Message - From: Mike Wittman mailto:[EMAIL PROTECTED] To: OpenSceneGraph Users mailto:osg-users@lists.openscenegraph.org Sent: Tuesday, September 25, 2007 3:58 PM Subject: Re: [osg-users] osgDotNet : Nodes adding to scene graph outsidemain()function scope Hi Christophe, This sounds like a bug that Jason reported where a particle system under a PAT node gives the same symptoms - http://www.openscenegraph.org/projects/osgDotNet/ticket/1. I've dug into that problem some, but only enough to know that it will take quite a bit more time to track down the root cause. You're correct about the reference count management; it's intended to be completely handled by the wrappers and transparent to the C# user. Obviously something is going wrong in this particular case. Mike Wittman [EMAIL PROTECTED] mailto:[EMAIL PROTECTED] ___ Seismic Micro-Technology, Inc. 8584 Katy Freeway, Suite 400 / Houston, Texas 77024 Tel. +1 (713) 464-6188 Fax. +1 (713) 464-6440 Web: www.seismicmicro.com blocked::blocked::http://www.seismicmicro.com ___ CONTACT US TODAY for more information. ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] FBO
Thanks, eventually it was my own bug. doh! sorry for the interruption. I hanged the scene view data according to some condition and didn't set it back to the original that create all the objects. now it works. thanks again, Guy. - Original Message - From: Robert Osfield [EMAIL PROTECTED] To: OpenSceneGraph Users osg-users@lists.openscenegraph.org Sent: Tuesday, September 25, 2007 1:44 PM Subject: Re: [osg-users] FBO Hi Guy, 2.x and 1.2 and substantially different when it comes to management of clean up of graphics contexts. I suggest you upgrade, your problems might be fixed right away, but if not then there is much better chance that others will be able to support you. Robert. On 9/25/07, [EMAIL PROTECTED] [EMAIL PROTECTED] wrote: I'm using the OSG 1.2 version, but I have the code of the OSG2.0 to compare with, and the clean up is similar. I also try to keep the questions not specific to the 1.2 implementation I noticed that on the clean_frame, the pass over the scene doesn't get to all the objects for some reason. For example, it releases only one texture object while there suppose to be two, and it gets only to one camera of the pair of RTT and show texture on screen cameras. and I'm now debugging it. Maybe I changed the scene and lose pointers to objects somewhere... Could it be that since one of the camera is pre-render and the other is nested, that the cleanup get only to the nested rendered camera? thanks, Guy. - Original Message - From: Robert Osfield [EMAIL PROTECTED] To: OpenSceneGraph Users osg-users@lists.openscenegraph.org Sent: Tuesday, September 25, 2007 10:10 AM Subject: Re: [osg-users] FBO Hi Guy, If you destroy a window then all the OpenGL objects associated with it will be removed. If you are using 2.0/osgViewer it should be able to automatically release the OpenGL objects and reallocated them on the new graphics context. Which verison of the OSG/viewer library are you using? Robert. On 9/25/07, [EMAIL PROTECTED] [EMAIL PROTECTED] wrote: Hi Robert, in my application I have the scene graph in some variable, and a camera in another variable, then I attach it to viewer, in multi-document window. After I close the window, the scene graph the camera are still alive. The next time I want to attach them to a new window I get OpenGL error that the frame buffer object is not complete (and nothing is drawn), so I wanted to force the renderstage to re-create it, and achieved this by setting the rendering cache of the existing camera to NULL. I just wanted to know if there is another and better way to deal with this problem, and also if you know why the FBO was defected after the window was closed. thanks, Guy. - Original Message - From: Robert Osfield [EMAIL PROTECTED] To: OpenSceneGraph Users osg-users@lists.openscenegraph.org Sent: Monday, September 24, 2007 3:04 PM Subject: Re: [osg-users] FBO Hi Guy, Have a look at the osgprerender example. You shouldn't need to set anything related to the render cache is this is managed internally. Robert. On 9/24/07, [EMAIL PROTECTED] [EMAIL PROTECTED] wrote: OK, I got over it but I'm not sure that was the best way. What I did was to set the camera rendering cache (for the related contextID) to NULL, so the next time the cull visitor applied on the camera, it recreated the FBO. Any other ideas? thanks, Guy. - Original Message - From: [EMAIL PROTECTED] To: osg-users@lists.openscenegraph.org Sent: Monday, September 24, 2007 1:51 PM Subject: [osg-users] FBO Hi, How do I enforce a camera to recreate FBO attached to the color buffer? thanks, Guy. ___ 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 ___ osg-users mailing list
Re: [osg-users] osgDotNet : Nodes adding to scene graphoutsidemain()function scope
Hi Jason, I expect this is a pretty deep problem related to the way reference counting is handled by osgDotNet. I'd recommend reviewing the RefCount Deletion Statechart diagram in the GeneratedCode.uml file, which gives insight into the (intended) reference counting strategy. Also I found the book CLR via C# extremely helpful in understanding how the CLR GC works. I do intend to look into this more when I have the time, but I'm not sure how soon that will happen. If you figure it out in the mean time I'll be happy to accept a patch. :) -Mike From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Jason Beverage Sent: Tuesday, September 25, 2007 10:06 AM To: OpenSceneGraph Users Subject: Re: [osg-users] osgDotNet : Nodes adding to scene graphoutsidemain()function scope Hi Mike, I tried to do some debugging with regards to the PAT issue I added and it has something to do with the finalizer being run a NodeVisitor object, but that's about as far as I got. I couldn't understand why it would be an issue for nodes containing particle systems, but other nodes are fine. I think it has something to do with the adapter pattern being used that allows a user to subclass Nodes in C#, but I haven't gotten any further. Jason On 9/25/07, Christophe Medard [EMAIL PROTECTED] wrote: Hi Mike, Thanks for telling me the same kind of thing was already reported ! I understand passin in OSG 2.1.12 would do no good. Thanks also for confirming the OSG reference count management being done by the wrapper layer in a .NET Managed-fashion... It's quite hard to find the root cause indeed, since it seems to depend on independant factor, like where the camera is -initially- positionned : I only get the problem when letting osgViewer set it away from the scene (no osgViewer.getCameraManipulator().setHomePosition() call in my mainloop). There's something about an intersect visitor apparently (a culling pass ?). One could think it's only where the AccessViolation first occur. I'm not sure : if I initialize the camera close to the scene geometry, not only does my AccessViolation vanish, but I don't have the OSG Notice warning about a possible problem anymore either. That whether I leave space between my point of the scene and scene geometry through manipulator's behaviour afterwards in the run time of my application... Anyway, if anyone happen to lock the root cause, please don't hesitate to post ! -- Christophe Médard Société OKTAL (http://www.oktal.fr) 2 impasse Boudeville 31100 Toulouse (France) Tél. : (+33) 5 62 11 50 10 Fax : (+33) 5 62 11 50 29 - Original Message - From: Mike Wittman mailto:[EMAIL PROTECTED] To: OpenSceneGraph Users mailto:osg-users@lists.openscenegraph.org Sent: Tuesday, September 25, 2007 3:58 PM Subject: Re: [osg-users] osgDotNet : Nodes adding to scene graph outsidemain()function scope Hi Christophe, This sounds like a bug that Jason reported where a particle system under a PAT node gives the same symptoms - http://www.openscenegraph.org/projects/osgDotNet/ticket/1. I've dug into that problem some, but only enough to know that it will take quite a bit more time to track down the root cause. You're correct about the reference count management; it's intended to be completely handled by the wrappers and transparent to the C# user. Obviously something is going wrong in this particular case. Mike Wittman [EMAIL PROTECTED] mailto:[EMAIL PROTECTED] ___ Seismic Micro-Technology, Inc. 8584 Katy Freeway, Suite 400 / Houston, Texas 77024 Tel. +1 (713) 464-6188 Fax. +1 (713) 464-6440 Web: www.seismicmicro.com ___ CONTACT US TODAY for more information. ___ 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] OpenThread leak ?
On 9/25/07, Adam Coates [EMAIL PROTECTED] wrote: I looked into this a tad more; it looks like it is indeed caused by the thread not being detached. I added the line: pthread_attr_setdetachstate(thread_attr, PTHREAD_CREATE_DETACHED); before the thread creation so that the thread will clean up automatically. This eliminates the memory leak. This is a bad hack, since it will break the join() and detach() functions. However, before I tried this, I tried calling join() and detach() on the Thread object, but that only leads to a segfault (not sure why yet). Just a quick comment, in early days of OpenThreads/OSG development we tried out join() but found problems with it and certain platforms. I can't recall which platforms, nor which combinations of usage, nor the actual symptoms exhibited - its was around 6 years ago. As for a small memory leak on exit from an app, well unix will clean this up for you anyway on exit from the app, so while it'd be good practice to solve it, its not going to make any significance to any application built on the OSG. Given how many other tasks I have on my plate I'll leave this lower priority issue to others to chase up if they fancy :-) Robert. Robert. ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] OpenThread leak ?
Makes sense to me -- but at the least this is now a documented issue in case others are curious and need to solve it for their own reasons. Cheers, AC On 9/25/07, Robert Osfield [EMAIL PROTECTED] wrote: On 9/25/07, Adam Coates [EMAIL PROTECTED] wrote: I looked into this a tad more; it looks like it is indeed caused by the thread not being detached. I added the line: pthread_attr_setdetachstate(thread_attr, PTHREAD_CREATE_DETACHED); before the thread creation so that the thread will clean up automatically. This eliminates the memory leak. This is a bad hack, since it will break the join() and detach() functions. However, before I tried this, I tried calling join() and detach() on the Thread object, but that only leads to a segfault (not sure why yet). Just a quick comment, in early days of OpenThreads/OSG development we tried out join() but found problems with it and certain platforms. I can't recall which platforms, nor which combinations of usage, nor the actual symptoms exhibited - its was around 6 years ago. As for a small memory leak on exit from an app, well unix will clean this up for you anyway on exit from the app, so while it'd be good practice to solve it, its not going to make any significance to any application built on the OSG. Given how many other tasks I have on my plate I'll leave this lower priority issue to others to chase up if they fancy :-) Robert. 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
[osg-users] Question on Node memory management.
Hello,
I am working on converting a project from SGI Performer in C
to OSG, so I am familiar with constructing a scene graph.
For this project I load all the models I plan to use into a
data structure, at a later point in time based on the user
responses I swap out the sub-graphs that I wish displayed.
The problem is the memory manager ends up freeing my nodes.
I know the OSG answer will be to add a switch node as the
parent of each of the sub graphs then toggle those on and
off.
Is there a way to tell OSG that I will let it know when I'm
done with a node?
What should happen in this example snippet is loading two
models which are get swapped in/out by the user pressing 1
or 2.
What ends up happening is the program crashes the 2nd time I
tried to load either model.
Setup in pseudo code based on the Glut example code is
something like ...
osg::ref_ptrosg::Node pNode1;
osg::ref_ptrosg::Node pNode2;
void keyboard( unsigned char key, int /*x*/, int /*y*/ )
{
switch( key )
{
case '1':
viewer-setSceneData( pNode1 );
break;
case '2':
viewer-setSceneData( pNode2 );
break;
// other cases
}
}
main()
{
// some initilization ...
pNode1 = osgDB::readNodeFiles(File1);
pNode2 = osgDB::readNodeFiles(File2);
// more initilization
viewer-setSceneData( pNode1 );
viewer-realize();
glutMainLoop();
}
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
