Re: [osg-users] Problem using Bones
Hi, I will make some debug in a few daysmany thanks for now :D Thank you! Cheers, Dario -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=62972#62972 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] OpenSceneGraph-3.3.6 dev release tagged
Hi Zhuwan, On 6 March 2015 at 13:24, webmaster webmas...@3dvri.com wrote: But,the code which i downloaded is OpenSceneGraph-3.3.5.zip??? Oopps, Copy and Paste Anti-Pattern strikes! Thanks for testing and spotting this error. I thought I had update all the links on the webpage before I copied it into my notification post, but alas it's now clear that I didn't do it properly. I have now fixed the downloads webpage. Hopefully everything shoudl be correct now. *O**pen**SceneGraph-3.3.6, **released on 5th March **2015*, key deliverables in this dev release are: - Resutructed osgPresentation headers and source to remove experimental but unused classes. - Fix to handling of the GLSL #version under Windows when #pragma(tic) shader composition is being used. *source package :* OpenSceneGraph-3.3.6.zip http://www.openscenegraph.org/downloads/developer_releases/OpenSceneGraph-3.3.6.zip *svn tag:* svn co http://svn.openscenegraph.org/osg/OpenSceneGraph/tags/OpenSceneGraph-3.3.6 OpenSceneGraph ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] #pragma(tic) shader composition support now checked into svn/trunk
Hi Michael, On 6 March 2015 at 14:42, michael kapelko korn...@gmail.com wrote: First, I'm all for new #pragma(tic) approach, because I use uniforms for the same reason currently.Thanks for an easier way to do the same thing! Second, I'd like to clarify that I understand it correctly: #pragma is OSG specific and thus works with OpenGL2, right? It should work with all versions of GLSL, so OpenGL 2, 3.x, 4.x and OpenGL ES 2 and 3, as the #pragma feature of GLSL that the new shader composition leverage has been their since the inception of GLSL. Which rather begs the question why did it take so long to spot this approach... funny how coming at a problem afresh can provide new ways of thinking about problems and how to solve them. Happy to just have finally got their... :-) Robert. ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] #pragma(tic) shader composition support now checked into svn/trunk
Hi. First, I'm all for new #pragma(tic) approach, because I use uniforms for the same reason currently.Thanks for an easier way to do the same thing! Second, I'd like to clarify that I understand it correctly: #pragma is OSG specific and thus works with OpenGL2, right? Thanks. 2015-03-05 18:39 GMT+07:00 Robert Osfield robert.osfi...@gmail.com: Hi Robert (Miharcic for those trying to follow this thread), I have reviewed your shader composition changes. My first reaction is WOW. Second reaction much the same ;-) I can't pretend that I actually understand all the changes but have started to get inkling about parts. The range of changes and complexity of what problem is being tackled is pretty daunting to take in. I get the sense that your changes pick up where my original work on osg::ShaderComposition left off, coming much close to completing the journey. Right now my focus is getting OSG-3.4 out the door and given the changes are so extensive and the problem so complex I won't have time to look at integrating the changes. The general approach I took with osg::ShaderComposition is something I no longer feel provides a good tradeoff between functionality and ease of use, here I feel the tradeoff with #pragma(tic) shader composition is much better - you don't get all functionality of osg::ShaderComposition but it is far easier for the average developer to pick and use. Longer term I feel that features of the old osg::ShaderComposition would be best step by step integrated into a method that extends the #pragmat(tic) shader approach. If there are small modifications to the core OSG in svn/trunk that would help make it easier to add your own shader composition work ontop of the OSG-3.4 let me know. Things like making a method virtual, or adding an extra option etc. are things that would not be too intrusive and risky w.r.t the OSG-3.4 release. Cheers 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] OpenSceneGraph-3.3.6 dev release tagged
hi Robert, But,the code which i downloaded is OpenSceneGraph-3.3.5.zip??? regards zhuwan 03,06,2015 在2015-3-6 4:00:59，Robert Osfield robert.osfi...@gmail.com 写道: -原始邮件- 发件人: Robert Osfield robert.osfi...@gmail.com 发送时间: 2015-3-6 4:00:59 收件人: OpenSceneGraph Users osg-users@lists.openscenegraph.org 主题: [osg-users] OpenSceneGraph-3.3.6 dev release tagged Hi All, I have tagged the next dev release. 3.3.6. I have upped the rate of dev releases as we are now very close to the making the OSG-3.4 branch and embarking on the 3.4.0 release candidate series. OpenSceneGraph-3.3.6, released on 5th March 2015, key deliverables in this dev release are: Resutructed osgPresentation headers and source to remove experimental but unused classes. Fix to handling of the GLSL #version under Windows when #pragma(tic) shader composition is being used. source package : OpenSceneGraph-3.3.6.zip svn tag: svn co http://svn.openscenegraph.org/osg/OpenSceneGraph/tags/OpenSceneGraph-3.3.6 OpenSceneGraph Thanks in advance for testing, it's now very important as we are now just weeks away from making the OSG-3.4 stable release, so if there might be problems it's crucial we find them as soon as possible. Cheers, Robert -- ChangeLog since 3.3.5: 2015-03-05 10:53 robert * src/osg/Shader.cpp: Added check for newline at end of version line, and of it's not add a '\n' 2015-03-04 18:39 robert * CMakeLists.txt: Updated SO_VERSION after changes to osgPresentation 2015-03-04 18:36 robert * applications/present3D/CMakeLists.txt, applications/present3D/Cluster.cpp, applications/present3D/Cluster.h, applications/present3D/ExportHTML.cpp, applications/present3D/ExportHTML.h, applications/present3D/PointsEventHandler.cpp, applications/present3D/PointsEventHandler.h, applications/present3D/ReadShowFile.cpp, applications/present3D/ReadShowFile.h, applications/present3D/SDLIntegration.cpp, applications/present3D/SDLIntegration.h, applications/present3D/ShowEventHandler.cpp, applications/present3D/ShowEventHandler.h, applications/present3D/SpellChecker.cpp, applications/present3D/SpellChecker.h, applications/present3D/deprecated, applications/present3D/present3D.cpp, include/osgPresentation/AnimationMaterial, include/osgPresentation/CompileSlideCallback, include/osgPresentation/KeyEventHandler, include/osgPresentation/PickEventHandler, include/osgPresentation/PropertyManager, include/osgPresentation/SlideEventHandler, include/osgPresentation/SlideShowConstructor, include/osgPresentation/Timeout, include/osgPresentation/deprecated/AnimationMaterial, include/osgPresentation/deprecated/CompileSlideCallback, include/osgPresentation/deprecated/KeyEventHandler, include/osgPresentation/deprecated/PickEventHandler, include/osgPresentation/deprecated/PropertyManager, include/osgPresentation/deprecated/SlideEventHandler, include/osgPresentation/deprecated/SlideShowConstructor, include/osgPresentation/deprecated/Timeout, src/osgPlugins/osc/OscReceivingDevice.cpp, src/osgPlugins/osc/ReaderWriterOscDevice.cpp, src/osgPlugins/p3d/ReaderWriterP3D.cpp, src/osgPlugins/p3d/ReaderWriterPaths.cpp, src/osgPresentation/AnimationMaterial.cpp, src/osgPresentation/CMakeLists.txt, src/osgPresentation/CompileSlideCallback.cpp, src/osgPresentation/KeyEventHandler.cpp, src/osgPresentation/PickEventHandler.cpp, src/osgPresentation/PropertyManager.cpp, src/osgPresentation/SlideEventHandler.cpp, src/osgPresentation/SlideShowConstructor.cpp, src/osgPresentation/Timeout.cpp, src/osgPresentation/deprecated/AnimationMaterial.cpp, src/osgPresentation/deprecated/CompileSlideCallback.cpp, src/osgPresentation/deprecated/KeyEventHandler.cpp, src/osgPresentation/deprecated/PickEventHandler.cpp, src/osgPresentation/deprecated/PropertyManager.cpp, src/osgPresentation/deprecated/SlideEventHandler.cpp, src/osgPresentation/deprecated/SlideShowConstructor.cpp, src/osgPresentation/deprecated/Timeout.cpp: Restructed the osgPresentation and present3D directories back to the structure that was present in OSG-3.2 2015-03-04 17:42 robert * examples/CMakeLists.txt, include/osgDB/ClassInterface, include/osgPresentation/Action, include/osgPresentation/Audio, include/osgPresentation/Element, include/osgPresentation/Group, include/osgPresentation/Image, include/osgPresentation/Layer, include/osgPresentation/Model, include/osgPresentation/Movie, include/osgPresentation/Presentation, include/osgPresentation/PresentationInterface, include/osgPresentation/Section, include/osgPresentation/Show, include/osgPresentation/Slide,
Re: [osg-users] GL error line 2255: invalid operation
Thanks Sebastian. I have to switch to my Windows machine :-) Cheers, Nick On Fri, Mar 6, 2015 at 8:47 AM, Sebastian Messerschmidt sebastian.messerschm...@gmx.de wrote: Hi Nick, Try geDebugger [1] etc.. Under visual studio they even integrate into the GUI, so you will be able to debug the offending line which causes the error. [1] http://developer.amd.com/tools-and-sdks/archive/amd-gdebugger/ Cheers Sebastian suddenly OSG_GL_ERROR_CHECKING=ON is not verbose at all for this error still the same :-/ Nick On Thu, Mar 5, 2015 at 11:16 PM, Trajce Nikolov NICK trajce.nikolov.n...@gmail.com wrote: Thanks Bjorn. I will start debugging Nick On Thu, Mar 5, 2015 at 11:21 PM, Björn Blissing bjorn.bliss...@vti.se wrote: Hi Nick, I got a couple of this while doing the Oculus integration (mostly due to Oculus driver injection). But the procedure I usually use is this: 1. Enabled OpenGL debugging in OpenSceneGraph by setting the environment variable: OSG_GL_ERROR_CHECKING=ON This will give you more information of which class that triggered the GL error. (Although this is not always true, there are some caveats). 2. Once I found which class that is the probable offender I usually add some debug printouts in that OSG class, printing out the name of the node, attribute or whatever classtype is triggering the error. The caveats: This process usually finds you the offending call. But you cannot trust it 100%. This is due to the fact that to clear the error flag you have to call glGetError(), and since OSG cannot have glGetError() calls after every single one of its OpenGL calls, sometimes the wrong class gets reported. So if you suspects that OSG is pointing the finger on the wrong class. Start by adding a glGetError() call as first OpenGL call in that class. Otherwise you might chase an error that actually exists in another class. Good luck on you bug hunting! Björn -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=62968#62968 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org -- trajce nikolov nick -- trajce nikolov nick ___ osg-users mailing listosg-users@lists.openscenegraph.orghttp://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 -- trajce nikolov nick ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] GL error line 2255: invalid operation
Am 06.03.2015 um 10:34 schrieb Trajce Nikolov NICK: Thanks Sebastian. I have to switch to my Windows machine :-) Maybe some of the Unix-users here can drop in and tell us if there is some tool on Unix to debug OpenGL calls. Cheers Sebastian Cheers, Nick On Fri, Mar 6, 2015 at 8:47 AM, Sebastian Messerschmidt sebastian.messerschm...@gmx.de mailto:sebastian.messerschm...@gmx.de wrote: Hi Nick, Try geDebugger [1] etc.. Under visual studio they even integrate into the GUI, so you will be able to debug the offending line which causes the error. [1] http://developer.amd.com/tools-and-sdks/archive/amd-gdebugger/ Cheers Sebastian suddenly OSG_GL_ERROR_CHECKING=ON is not verbose at all for this error still the same :-/ Nick On Thu, Mar 5, 2015 at 11:16 PM, Trajce Nikolov NICK trajce.nikolov.n...@gmail.com mailto:trajce.nikolov.n...@gmail.com wrote: Thanks Bjorn. I will start debugging Nick On Thu, Mar 5, 2015 at 11:21 PM, Björn Blissing bjorn.bliss...@vti.se mailto:bjorn.bliss...@vti.se wrote: Hi Nick, I got a couple of this while doing the Oculus integration (mostly due to Oculus driver injection). But the procedure I usually use is this: 1. Enabled OpenGL debugging in OpenSceneGraph by setting the environment variable: OSG_GL_ERROR_CHECKING=ON This will give you more information of which class that triggered the GL error. (Although this is not always true, there are some caveats). 2. Once I found which class that is the probable offender I usually add some debug printouts in that OSG class, printing out the name of the node, attribute or whatever classtype is triggering the error. The caveats: This process usually finds you the offending call. But you cannot trust it 100%. This is due to the fact that to clear the error flag you have to call glGetError(), and since OSG cannot have glGetError() calls after every single one of its OpenGL calls, sometimes the wrong class gets reported. So if you suspects that OSG is pointing the finger on the wrong class. Start by adding a glGetError() call as first OpenGL call in that class. Otherwise you might chase an error that actually exists in another class. Good luck on you bug hunting! Björn -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=62968#62968 ___ osg-users mailing list osg-users@lists.openscenegraph.org mailto:osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org -- trajce nikolov nick -- trajce nikolov nick ___ osg-users mailing list osg-users@lists.openscenegraph.org mailto:osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org ___ osg-users mailing list osg-users@lists.openscenegraph.org mailto:osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org -- trajce nikolov nick ___ 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] Texture2D subload woes
I have need for some custom code to run after the Texture2D::applyTexImage2D_subload function is called. (I am reading back the image from OpenGL, which might have been compressed by the graphics card, and saving it to disk.) So I have been using a subloadCallback to put the custom code in place. This works, but I don't require any custom code for the Texture2D::applyTexImage2D_load function. But since the subloadCallback requires me to implement both the load and the subload I must do both. But I can't replicate the code in Texture2D::apply in my subloadCallback because there are lots of mutable members in Texture2D and getting them from the subloadCallback doesn't make them mutable for me, so I get lots of errors of losing constness and qualifiers if I try this path. So I am wondering how best to proceed from here. Should I derive a class from Texture2D so I can intercept calls to apply(), then call the base class version and do my custom processing from there, or can we add a hook to call a custom callback after the Texture2D::applyTexImage2D_load and/or the Texture2D::applyTexImage2D_subload functions? Or is there a better way to read the texture back from the graphics card that is independent of the Texture2D::apply function? Of course this will need to be done in the draw thread. Any help will be appreciated.. Eric ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Texture2D subload woes
Hi Eric, It's a long time since I looked at the subload callback. Having the load and subload methods available in osg::Texture2D seems like a sensible option. However, it might be that you don't need the callback at all. Have you looked at the osg::Image::Image::readImageFromCurrentTexture(..) method? Robert. On 6 March 2015 at 19:50, Eric Sokolowsky e...@byu.net wrote: I have need for some custom code to run after the Texture2D::applyTexImage2D_subload function is called. (I am reading back the image from OpenGL, which might have been compressed by the graphics card, and saving it to disk.) So I have been using a subloadCallback to put the custom code in place. This works, but I don't require any custom code for the Texture2D::applyTexImage2D_load function. But since the subloadCallback requires me to implement both the load and the subload I must do both. But I can't replicate the code in Texture2D::apply in my subloadCallback because there are lots of mutable members in Texture2D and getting them from the subloadCallback doesn't make them mutable for me, so I get lots of errors of losing constness and qualifiers if I try this path. So I am wondering how best to proceed from here. Should I derive a class from Texture2D so I can intercept calls to apply(), then call the base class version and do my custom processing from there, or can we add a hook to call a custom callback after the Texture2D::applyTexImage2D_load and/or the Texture2D::applyTexImage2D_subload functions? Or is there a better way to read the texture back from the graphics card that is independent of the Texture2D::apply function? Of course this will need to be done in the draw thread. Any help will be appreciated.. Eric ___ 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] Texture2D subload woes
Hi Robert, I am using that function to get the image from the texture in my custom subload callback. The problem is how or when do I call that? It must be in the draw thread, so that's why I was using a subload callback, but I no longer want to override the default processing found in Texture2D::apply(), so I don't want to use a subload callback any more. Eric On Fri, Mar 6, 2015 at 3:45 PM, Robert Osfield robert.osfi...@gmail.com wrote: Hi Eric, It's a long time since I looked at the subload callback. Having the load and subload methods available in osg::Texture2D seems like a sensible option. However, it might be that you don't need the callback at all. Have you looked at the osg::Image::Image::readImageFromCurrentTexture(..) method? Robert. On 6 March 2015 at 19:50, Eric Sokolowsky e...@byu.net wrote: I have need for some custom code to run after the Texture2D::applyTexImage2D_subload function is called. (I am reading back the image from OpenGL, which might have been compressed by the graphics card, and saving it to disk.) So I have been using a subloadCallback to put the custom code in place. This works, but I don't require any custom code for the Texture2D::applyTexImage2D_load function. But since the subloadCallback requires me to implement both the load and the subload I must do both. But I can't replicate the code in Texture2D::apply in my subloadCallback because there are lots of mutable members in Texture2D and getting them from the subloadCallback doesn't make them mutable for me, so I get lots of errors of losing constness and qualifiers if I try this path. So I am wondering how best to proceed from here. Should I derive a class from Texture2D so I can intercept calls to apply(), then call the base class version and do my custom processing from there, or can we add a hook to call a custom callback after the Texture2D::applyTexImage2D_load and/or the Texture2D::applyTexImage2D_subload functions? Or is there a better way to read the texture back from the graphics card that is independent of the Texture2D::apply function? Of course this will need to be done in the draw thread. Any help will be appreciated.. Eric ___ 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] Texture2D subload woes
I subclassed Texture2D and implemented apply(), and it now works very well, without duplicating code. I'm not sure if there's a better solution but I'm happy with this one. Eric On Fri, Mar 6, 2015 at 3:52 PM, Eric Sokolowsky e...@byu.net wrote: Hi Robert, I am using that function to get the image from the texture in my custom subload callback. The problem is how or when do I call that? It must be in the draw thread, so that's why I was using a subload callback, but I no longer want to override the default processing found in Texture2D::apply(), so I don't want to use a subload callback any more. Eric On Fri, Mar 6, 2015 at 3:45 PM, Robert Osfield robert.osfi...@gmail.com wrote: Hi Eric, It's a long time since I looked at the subload callback. Having the load and subload methods available in osg::Texture2D seems like a sensible option. However, it might be that you don't need the callback at all. Have you looked at the osg::Image::Image::readImageFromCurrentTexture(..) method? Robert. On 6 March 2015 at 19:50, Eric Sokolowsky e...@byu.net wrote: I have need for some custom code to run after the Texture2D::applyTexImage2D_subload function is called. (I am reading back the image from OpenGL, which might have been compressed by the graphics card, and saving it to disk.) So I have been using a subloadCallback to put the custom code in place. This works, but I don't require any custom code for the Texture2D::applyTexImage2D_load function. But since the subloadCallback requires me to implement both the load and the subload I must do both. But I can't replicate the code in Texture2D::apply in my subloadCallback because there are lots of mutable members in Texture2D and getting them from the subloadCallback doesn't make them mutable for me, so I get lots of errors of losing constness and qualifiers if I try this path. So I am wondering how best to proceed from here. Should I derive a class from Texture2D so I can intercept calls to apply(), then call the base class version and do my custom processing from there, or can we add a hook to call a custom callback after the Texture2D::applyTexImage2D_load and/or the Texture2D::applyTexImage2D_subload functions? Or is there a better way to read the texture back from the graphics card that is independent of the Texture2D::apply function? Of course this will need to be done in the draw thread. Any help will be appreciated.. Eric ___ 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
