Re: [osg-users] GraphicsWindowCocoa Sample
Hi Stephan, Thanks a lot to your reply and your help! Now I am able to run a sample. My fail reason is didn't call graphic context' realize function. The GraphicsWindowEmbedded approach you mentioned, is that the way used example_viewerCocoa? The code is: osgViewer::GraphicsWindowEmbedded* graphicsWindow = theViewer-setUpViewerAsEmbeddedInWindow(0,0,740,650); Could you advice on how to use dragdrop or mouse handlers to created NSView from GraphicsWindowCocoa usage? Is subclass or delegate view controller will work? I am trying to port example_viewerCocoa to use GraphicsWindowCocoa. Thank you! Cheers, Yu -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=59886#59886 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
[osg-users] OS X 10.9 Mavericks shaders problem
Hi. I get the following errors when running my OSG app on OS X which runs perfectly fine on Linux: FRAGMENT glCompileShader FAILED FRAGMENT Shader infolog: ERROR: 0:67: Incompatible types (vec4 and float) in assignment (and no available implicit conversion ) glLinkProgram FAILED Program infolog: ERROR: One or more attached shaders not successfully compiled VERTEX glCompileShader pass1VS FAILED VERTEX Shader pass1VS infolog: ERROR: 0:24: GLSL 110 does not allow sub- or super-matrix constructors ERROR: 0:27: Incompatible types (vec3 and vec4) in assignment (and no available implicit conversion) ERROR: 0:29: Use of undeclared identifier 'modelMatrix3x3' ERROR: 0:31: Use of undeclared identifier 'modelMatrix3x3' glLinkProgram pass1 FAILED Program pass1 infolog: ERROR: One or more attached shaders not successfully compiled FRAGMENT glCompileShader pass2FS FAILED FRAGMENT Shader pass2FS infolog: ERROR: 0:24: '/' does not operate on 'vec3' and 'int' ERROR: 0:49: '==' does not operate on 'float' and 'int' glLinkProgram pass2 FAILED Program pass2 infolog: ERROR: One or more attached shaders not successfully compiled I have the following info from osg::GL2Extensions: gl version: 2.1 NVIDIA-8.16.74 310.40.00.10f02 vendor: NVIDIA Corporation renderer: NVIDIA GeForce GTX 560 OpenGL Engine glsl version: 1.20 pass1VS: http://goo.gl/sT7m7n pass2FS: http://goo.gl/9qX1H1 I tried to update shaders to fix those errors, and I got almost correct results (normal mapping is doesn't work somehow). Why does OSG try GLSL 110 in the first place? Do I need to request some other GL version to fix it? How do I do it? What special steps do I need to make OSG run on OS X? Thanks. ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] [ANN]OSGWARES 1.0 Beta Release notes(a gift for Robert and osg community)!
On Fri, Jun 20, 2014 at 5:59 PM, LearningOSG LearningOSG learning...@gmail.com wrote: ,can run OSG in Opengl and D3D mode Wait, what?? Can someone explain this, because i think I'm still hung over from being in Nevada. -- Chris 'Xenon' Hanson, omo sanza lettere. xe...@alphapixel.com http://www.alphapixel.com/ Training • Consulting • Contracting 3D • Scene Graphs (Open Scene Graph/OSG) • OpenGL 2 • OpenGL 3 • OpenGL 4 • GLSL • OpenGL ES 1 • OpenGL ES 2 • OpenCL Digital Imaging • GIS • GPS • osgEarth • Terrain • Telemetry • Cryptography • Digital Audio • LIDAR • Kinect • Embedded • Mobile • iPhone/iPad/iOS • Android @alphapixel https://twitter.com/alphapixel facebook.com/alphapixel (775) 623-PIXL [7495] ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
[osg-users] newbie issues using GLES 2.0
We are putting together an mapping application targeted for the imx6 hardware. The drivers support GLES 2.0, with no fallback/support for previous versions. We have models and other resources in osgb files, and load them at run-time, attaching them to our scene graph as necessary. On our dev platforms (win7 and linux on x86) things render without issue, but when cross-compiled and deployed to our imx6 hardware, these osgb resources did not show. We traced it to bad shaders, and found on these forums that the reason is that ShaderGen.cpp was generating (fallback?) shaders which are not compatible with GLES 2.0. My first naive step was to modify the vertex and fragment shaders in ShaderGen to enable them to compile in our GLES GPU. We had to remove references to the fixed-function pipeline, and that included references to gl_Color (et al), which was how each vertex got it's starting material color. So... we could see our geometry on-screen, but the material colors as stored in the osgb file were unavailable. I then dug around GLSL 2.0 enough to tentatively conclude that the new method of supplying those vertex colors to the shader code is to declare vertex attributes in the vertex shader and then bind an array of attributes. But, and this is my question, how do we use the generalized approach of reading in osg::nodes from osgb files, attach them to the scenegraph and still bind attributes to them? It seems that we would either need to create a unique osg::program per osg::node we load and then somehow glean the vertex color information from the osg::node, load it into an array and bind that array to the shader program. Can anyone shed any light on this? I thing I'm missing something fairly fundamental. Many thanks in advance! Mike -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=59905#59905 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
[osg-users] newbie issues using GLES 2.0
Hi Mike, yes, the question confuses when one starts to work with pure shader environments. the approach is to have a custom format and custom materials which are not so far implemented in core of osg. I found one osg compatible approach for materials see https://code.google.com/p/hogbox/ while the code has nice materials class https://code.google.com/p/hogbox/source/browse/trunk/src/hogbox/HogBoxMaterial.cpp the code provided lacks loader, another example format for shader-only based osg is internal format for http://osgjs.org/ there is though one catch - it is possible to save to this format from osg, but load only in osgjs, but it might shed light on how to proceed with own custom format https://github.com/cedricpinson/osg/tree/master/src/osgPlugins/osgjs also there is a split plugin which is needed if there is hardware limitation on vertex count https://github.com/cedricpinson/osg/tree/master/src/osgPlugins/split Regards Sergey On Thu, Jun 26, 2014 at 12:24 AM, Mike Metcalf metcalfnos...@mac.com wrote: We are putting together an mapping application targeted for the imx6 hardware. The drivers support GLES 2.0, with no fallback/support for previous versions. We have models and other resources in osgb files, and load them at run-time, attaching them to our scene graph as necessary. On our dev platforms (win7 and linux on x86) things render without issue, but when cross-compiled and deployed to our imx6 hardware, these osgb resources did not show. We traced it to bad shaders, and found on these forums that the reason is that ShaderGen.cpp was generating (fallback?) shaders which are not compatible with GLES 2.0. My first naive step was to modify the vertex and fragment shaders in ShaderGen to enable them to compile in our GLES GPU. We had to remove references to the fixed-function pipeline, and that included references to gl_Color (et al), which was how each vertex got it's starting material color. So... we could see our geometry on-screen, but the material colors as stored in the osgb file were unavailable. I then dug around GLSL 2.0 enough to tentatively conclude that the new method of supplying those vertex colors to the shader code is to declare vertex attributes in the vertex shader and then bind an array of attributes. But, and this is my question, how do we use the generalized approach of reading in osg::nodes from osgb files, attach them to the scenegraph and still bind attributes to them? It seems that we would either need to create a unique osg::program per osg::node we load and then somehow glean the vertex color information from the osg::node, load it into an array and bind that array to the shader program. Can anyone shed any light on this? I thing I'm missing something fairly fundamental. Many thanks in advance! Mike -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=59905#59905 ___ 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] newbie issues using GLES 2.0
Hi Mike. a little update to previous reply somehow I overlooked that hogbox has in fact plugin, which can serve as inspiration for you own https://code.google.com/p/hogbox/source/browse/trunk/src/#src%2FhogboxXmlPlugins%2FhogboxPlugin Regards Sergey On Thu, Jun 26, 2014 at 1:53 AM, Sergey Kurdakov sergey.fo...@gmail.com wrote: Hi Mike, yes, the question confuses when one starts to work with pure shader environments. the approach is to have a custom format and custom materials which are not so far implemented in core of osg. I found one osg compatible approach for materials see https://code.google.com/p/hogbox/ while the code has nice materials class https://code.google.com/p/hogbox/source/browse/trunk/src/hogbox/HogBoxMaterial.cpp the code provided lacks loader, another example format for shader-only based osg is internal format for http://osgjs.org/ there is though one catch - it is possible to save to this format from osg, but load only in osgjs, but it might shed light on how to proceed with own custom format https://github.com/cedricpinson/osg/tree/master/src/osgPlugins/osgjs also there is a split plugin which is needed if there is hardware limitation on vertex count https://github.com/cedricpinson/osg/tree/master/src/osgPlugins/split Regards Sergey On Thu, Jun 26, 2014 at 12:24 AM, Mike Metcalf metcalfnos...@mac.com wrote: We are putting together an mapping application targeted for the imx6 hardware. The drivers support GLES 2.0, with no fallback/support for previous versions. We have models and other resources in osgb files, and load them at run-time, attaching them to our scene graph as necessary. On our dev platforms (win7 and linux on x86) things render without issue, but when cross-compiled and deployed to our imx6 hardware, these osgb resources did not show. We traced it to bad shaders, and found on these forums that the reason is that ShaderGen.cpp was generating (fallback?) shaders which are not compatible with GLES 2.0. My first naive step was to modify the vertex and fragment shaders in ShaderGen to enable them to compile in our GLES GPU. We had to remove references to the fixed-function pipeline, and that included references to gl_Color (et al), which was how each vertex got it's starting material color. So... we could see our geometry on-screen, but the material colors as stored in the osgb file were unavailable. I then dug around GLSL 2.0 enough to tentatively conclude that the new method of supplying those vertex colors to the shader code is to declare vertex attributes in the vertex shader and then bind an array of attributes. But, and this is my question, how do we use the generalized approach of reading in osg::nodes from osgb files, attach them to the scenegraph and still bind attributes to them? It seems that we would either need to create a unique osg::program per osg::node we load and then somehow glean the vertex color information from the osg::node, load it into an array and bind that array to the shader program. Can anyone shed any light on this? I thing I'm missing something fairly fundamental. Many thanks in advance! Mike -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=59905#59905 ___ 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] newbie issues using GLES 2.0
Sergey, Many thanks for your suggestions. As you might understand, since you've provided quite a bit of material, it may take me a bit of time to look through it. I will post again once I've made some progress. Thanks again! -Mike -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=59908#59908 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
