[osg-users] visual c++ 2008 EX. forms
Hi!!! greetings to all! is possible, integrating OSG, a windows form application? I'm using VSC + + 2008 EXPRESS and thus find it easier to use, why not have experience with QT4. Thanks for your help! ShadowLord :) -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=29318#29318 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] cross axes
if you are doing it thru ortho camera, then you have to change the camera settings to fit your new window size on resize -Nick On Fri, Jun 25, 2010 at 11:50 AM, Gianni Ambrosio ga...@vi-grade.comwrote: Another question. Now the axes works fine in the left bottom corner but if I resize the viewer window (I use QT embedding the viewer inside) the cross axes object is deformed accordingly. How can I prevent that? I mean, I agree to resize the axes but in a homogeneous way for every axis. Regards Gianni -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=29405#29405 ___ 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] Fwd: [osg-submissions] Missing file ShaderComposer.cpp
Hi Mourad, Adrian, et. al, Sorry about the missing ShaderComposer.cpp, I checked in the rest of the new files but obviously missed doing a svn add src/osg/ShaderComposer.cpp when doing my check-in. I've now fixed this a ShaderComposer.cpp is now checked into svn/trunk. Cheers, Robert. ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Shader composition, OpenGL modes and custom modes
Hi Mathias, 2010/6/25 Mathias Fröhlich m.froehl...@science-computing.de: With that proposal - espcially the StateAttribute::compose call working directly on the osg::State - I conclude that we need to relink during draw: * we will probably loose state sorting for the shader combinations * shaders need to be at least relinked on every state change which will have some runtime (drawtime) overhead. The plan I have wouldn't affect state sorting, and lazy state updating of the composed shader programs would be utilized, and caching of the composed shader programs would be used once it has been composed. Only when you change modes will you need to go look for a new composed shader program, and only when you can't find an already cached one for the current set of enabled modes will you have to compose an new shader program. At least this is what I have in, and believe it'll be essential. The OSG's existing state sorting and lazy state management for modes and attributes will all work as is, we shouldn't need to modify it at all, so this will all happen automatically during cull as it builds up the rendering graphs and state graphs in the rendering backend. The only thing that will change will be what happen different will be internally in osg::State during the draw traversal, the rest of the draw will actually be identical. I'm expecting all the hardwork over the next few weeks to happen in osg::State, in the new shader composer classes and eventually in the various subclasses of osg::StateAttribute to provide the shader versions of the fixed function pipeline. The rest of the OSG is likely to remain pretty well untouched, and hopefully this will apply to end user applications as well - unless they want to leverage the new features that is :-) Robert. ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Shader composition, OpenGL modes and custom modes
Hi Johannes, I don't believe VirtualProgram is sufficiently sophisticated for our purposes, I agree about linking existing osg::Shader rather than composing these on the fly like in Roland's implementation. However we still have to inject code into the main for each of the vertex, geometry and fragment programs, the alternative would to have massing main functions that contain all the possible variations and then using uniforms to switch between the different parts. I don't believe the later approach is at all suitable for performance or for practicality. Right now I think keeping the bulk of the code in osg::Shader functions, and then composing the mains on demand and caching these main osg::Shader will be both the most flexible and the best performing solution. One could look at it as a bit of tacking the best bits from Roland approach and the best bits of VirtualProgram, and then mixing in a means of extending the existing fixed function StateAttribute in a way that provides a pretty seamless support for shader composition. At least that's my hope... Robert. On Fri, Jun 25, 2010 at 1:14 PM, Johannes Maier ver...@gmx.de wrote: Hi, as I mentioned somewhere else, we are also thinking about a shader composition concept. After some consideration we came to the conclusion, that shader linking is probably the most time-effective approach. So we would go with Wojtek and use his VirtualProgram - extending and implementing it. In combination with a clean shader implementation of the FFP you can activate/deactivate FFP-functionality by linking an empty dummy-function or a fully implemented function. These FFP-functionalities could also be used in own shadercode - just use the (ie osg_fog-)function in your own code. OSG will link it, when fog is activated and unlink (read: link empty function), when fog is deactivated. The linking itself should be much faster than generating some shadercode on runtime (even with caching). Using empty functions as not-active-dummys may sound like overhead, but calling a (empty) function didn't cost any measurable time when we tested it. Linking/Unlinking and updating needed uniforms could be implemented in osg::State ie through the mentioned shadercompositor-interface. ... Cheers, Johannes -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=29409#29409 ___ 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] Shader composition, OpenGL modes and custom modes
Hi Tim, On Fri, Jun 25, 2010 at 8:37 AM, Tim Moore timoor...@gmail.com wrote: Is it fair to say that the major interest in shader generation is in porting existing OSG apps to OpenGL ES 2.0, which doesn't have any fixed pipeline? I wouldn't agree with this statement. It's not about GLES 2.0 and it's not about shader generation relating to just fixed function pipeline. First up, the phrase shader generation is possible not too helpful though in the way that Wojtek phrased it - i.e. relating to just fixed function mapping. I believe it's better to think of doing shader composition as mainly linking shaders with a tiny amount of generation of shader mains, something that applies applies as much to the fixed function pipeline mapping as it does shader composition which is entirely user created. It's also not just about GLES 2.0, as OpenGL 3.x and OpenGL 4.x are also like OpenGL ES 2.0, once we drop the fixed function support than OpenGL provides we have to provide out own equivalent support or require application developers to roll their own shaders for everything, even just viewing something a simple as cow.osg. It's also worth mentioning that all our plugins target the fixed function StateAttributes, right now under GL3./GL4/GLES2 you have to do you own mapping from these StateAttribute to your own custom shaders. I think right now you go it alone with all shader scene graphs, and build all your own scene graphs accordingly and ignore all the NodeKits and Plugins that the OSG provides, but it really won't be productive for most applications. Until we have a credible way for mapping fixed function StateAttribute and associated modes to shaders most application developers will have to stick with GL2. I also believe that once we get going with shader composition we'll be mixing and matching lots of different StateAttribute, some provided by the core OSG, some custom one from applications or 3rd party libraries, and sometime just overriding the standard shaders providing by the built ins. If we continue to think about fixed function pipeline vs shader pipeline as two separate things, and that then I think we've lost something really important in understanding of the problem domain, both right now and going forward. Robert. ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
[osg-users] First pass on 3D virtualization using osg
Hi, I'm from Spain and I would like to know how to use osg to create virtual maps from tga files. I have seen all the examples but I don't know how to use de terrain library to this project. I need help to begin de project. Thanks! -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=29424#29424 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Shader composition, OpenGL modes and custom modes
On Sat, Jun 26, 2010 at 12:30 PM, Robert Osfield robert.osfi...@gmail.comwrote: Hi Tim, On Fri, Jun 25, 2010 at 8:37 AM, Tim Moore timoor...@gmail.com wrote: Is it fair to say that the major interest in shader generation is in porting existing OSG apps to OpenGL ES 2.0, which doesn't have any fixed pipeline? I wouldn't agree with this statement. It's not about GLES 2.0 and it's not about shader generation relating to just fixed function pipeline. First up, the phrase shader generation is possible not too helpful though in the way that Wojtek phrased it - i.e. relating to just fixed function mapping. I believe it's better to think of doing shader composition as mainly linking shaders with a tiny amount of generation of shader mains, something that applies applies as much to the fixed function pipeline mapping as it does shader composition which is entirely user created. OK, so the shader generation or fixed function emulation provides more shaders that might be linked or combined by shader composition, and the shader candidate functions are controlled by existing OSG state attributes? It's also not just about GLES 2.0, as OpenGL 3.x and OpenGL 4.x are also like OpenGL ES 2.0, once we drop the fixed function support than OpenGL provides we have to provide out own equivalent support or require application developers to roll their own shaders for everything, even just viewing something a simple as cow.osg. It's also worth mentioning that all our plugins target the fixed function StateAttributes, right now under GL3./GL4/GLES2 you have to do you own mapping from these StateAttribute to your own custom shaders. Right; I'm not personally doing core OpenGL 3.3 or 4.0 programming, but my impression was that the compatibility profile was going to be with us for a long, long time. Are a significant number of OSG users working with the core profiles? I think right now you go it alone with all shader scene graphs, and build all your own scene graphs accordingly and ignore all the NodeKits and Plugins that the OSG provides, but it really won't be productive for most applications. Until we have a credible way for mapping fixed function StateAttribute and associated modes to shaders most application developers will have to stick with GL2. Many users are effectively stuck at GL1.1 + hundreds of extensions, including ones that implement the capabilities of OpenGL 3.3 and 4.0. I also believe that once we get going with shader composition we'll be mixing and matching lots of different StateAttribute, some provided by the core OSG, some custom one from applications or 3rd party libraries, and sometime just overriding the standard shaders providing by the built ins. If we continue to think about fixed function pipeline vs shader pipeline as two separate things, and that then I think we've lost something really important in understanding of the problem domain, both right now and going forward. I can't argue with that, just wondering if the fixed function emulation via shaders is vital problem to solve at the moment. Tim ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
