Re: [osg-users] Transformation nodes with shaders
Hi Robert, Thanks for the tips and I set the UseModelViewAndProjectionUniforms flag on the Viewer-Camera-GraphicsContext-State object. However when I do this then absolutely nothing shows up on screen. Basically what I've had to do is manually append the view matrix onto each light's model transformation each frame and that gives the expected transformation. I'm not really sure why the OSG way isn't working but will have to debug it later. Chris On Mon, May 16, 2011 at 9:50 AM, Robert Osfield robert.osfi...@gmail.com wrote: Hi Chris, On Sun, May 15, 2011 at 9:45 AM, SkullCheck csklu...@gmail.com wrote: I've dug into the OSG source code a bit and found the following: - special osg_* uniforms are maintained in the State class, the ones of interest are osg_ModelViewProjectionMatrix, osg_Vertex, etc This are drop in replacements for the traditional gl_ variables that are provided in OpenGL 2.x's GLSL. These replaements are required for GL3+ (with backwards compatibility) and GLES 2 as neither provide the gl_ varaibles. For a GL 2.x app it's safe to just target the gl_ variables. - the updating of these uniforms during draw traversal must be enabled by calling State::setUseModelViewAndProjectionUniforms(true) I'm not quite sure where to set this though since States are used in multiple places, I've tried the following: osgViewer::Viewer * viewer = new osgViewer::Viewer; osgViewer::Renderer * renderer = dynamic_castosgViewer::Renderer *(viewer-getCamera()-getRenderer()); osgUtil::SceneView * sceneView = renderer-getSceneView(0); // Do this also for 2nd sceneview sceneView-setActiveUniforms( osgUtil::SceneView::ALL_UNIFORMS ); sceneView-getState()-setUseModelViewAndProjectionUniforms(true); The osg::State object is held by the GraphicsContext, you don't need to go chasing up internal implementation details like SceneView. If you have just one master camera that maintains the only one graphics context the code is simply: osg::State* state = viewer.getCamera()-getGraphicsContext()-getState(); For the GL3 and GLES2 profiles the OSG automaitcally setUseModelViewAndProjectionUniforms(true); - Modify the shader source to use the special osg_* built-in uniforms: osg::ref_ptrosg::State state = new osg::State; state-convertVertexShaderSourceToOsgBuiltIns( srcString ); shader-setShaderSource(srcString); (Couldn't osg::State::convertVertexShaderSourceToOsgBuiltIns() be a static method or free function?) This method is called when required, you never need to call it yourself. This method is purely there to help with backwards compatibility between GL 2.x and GL3/GLES2 apps. But when I do this, then nothing appears. What am I doing wrong or are there other things I should be doing? It does sound rather like you might be putting too much effort in, you may well be able to just use the standard gl_ built-ins. 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] Transformation nodes with shaders
Hi, I'm working on implementing some lighting effects with shaders and I've run into the problem that vertex positions are passed to the shader in local coordinates. This means that if there are any transformation nodes in the scenegraph underneath where the shader is active, the lighting calculations won't be transformed correctly. I've dug into the OSG source code a bit and found the following: - special osg_* uniforms are maintained in the State class, the ones of interest are osg_ModelViewProjectionMatrix, osg_Vertex, etc - the updating of these uniforms during draw traversal must be enabled by calling State::setUseModelViewAndProjectionUniforms(true) I'm not quite sure where to set this though since States are used in multiple places, I've tried the following: osgViewer::Viewer * viewer = new osgViewer::Viewer; osgViewer::Renderer * renderer = dynamic_castosgViewer::Renderer *(viewer-getCamera()-getRenderer()); osgUtil::SceneView * sceneView = renderer-getSceneView(0); // Do this also for 2nd sceneview sceneView-setActiveUniforms( osgUtil::SceneView::ALL_UNIFORMS ); sceneView-getState()-setUseModelViewAndProjectionUniforms(true); - Modify the shader source to use the special osg_* built-in uniforms: osg::ref_ptrosg::State state = new osg::State; state-convertVertexShaderSourceToOsgBuiltIns( srcString ); shader-setShaderSource(srcString); (Couldn't osg::State::convertVertexShaderSourceToOsgBuiltIns() be a static method or free function?) But when I do this, then nothing appears. What am I doing wrong or are there other things I should be doing? Thanks, Chris ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Multiple lights in a scene
I've started a separate thread for the transformation problem with subject: Transformation nodes with shaders On Fri, May 13, 2011 at 2:42 PM, SkullCheck csklu...@gmail.com wrote: Hi David, Thank you for your feedback. It looks like we are doing similar things, but a bit differently. I was distracted by another project the past couple of weeks but returned to this one and was given the go ahead to do a complete redesign. I have the UML of the design if you're interested. Basically I try to replicate the interface of osg::Light and osg::LightSource and automate all the uniform updates underneath. Also automated the setup of the shader programs. Unfortunately I need to wrap this all up next week so am not sure if we could've collaborated. But I have am still having one problem though. If there are some transform nodes in the scenegraph under the stateset containing the shader code, the vertex shader receives vertices in the transform node's local coordinates. The screenshot shows an example. There is a green light at the center of the spiral. I've placed a box offset from the center, but the green light from the center is showing up on the box instead of the peachish light that is nearby. Thanks, Chris On Tue, Apr 19, 2011 at 9:42 AM, David Callu led...@gmail.com wrote: Hi Chris, Hi Jean-Sébastien I just ending a similar work for a client and i could provide some advice on the subject. First, I derived from osg::LightSource to osgLighting::LightSource (that could contain many light, not only one as osg::LightSource) and add a cullCallback to do a similar job of osgUtil::CullVisitor::accept(osg::LightSource). I create a osgLighting::LightGroup (not a node) which contain light parameter (ambient, diffuse, position, direction ...) in uniforms arrays, and be shared by all lights I derived from osg::Light to osgLighting::Light that contain an osgLighting::LightGroup to store parameter in it. Shader is handle by a shader generator so I can't help you on this point. But I conclude after some test that per pixel lighting is not a choice. If you want apply shadow per light, you have to combine each light/shadow pair in the pixel shader. you can't compute light in vertex shader, then pass result of each light in pixel shader, and apply shadow on each light result. if you have 40 lights in you scene. you have to pass 40 vec3 from vertex shader to pixel shader ouch!!! according to Real-Time Rendering 3ed, Shader Model 4 have 16 interpolation registre between Vertex and Geometry/Pixel Shader and 32 between Geometry and Pixel Shader. J-S: About deferred shading, this is my first reflex to not pay the Z complexity of the scene. But OpenGL allow only 8 texture target to render in, so 8*4=32 values. We can use 3 for eye position, 3 for normal. This let's us with 26 value to pass light direction/position. That is largely under the need to handle more that 8 lights. I read an article about Unreal Engine that push the 3 nearest lights in RTT, and all others lights are combined in one, so only 4 light is pass to RTT, then computed in deferred shader. I have to dig this way ... Still according to Real Time Rendering 3ed, if you don't write the gl_FragDepth in your shader, recent hardware discard automatically the pixel computation if pixel in frame buffer is front of the incoming pixel. You can use OSG_DEFAULT_BIN_SORT_MODE=SORT_FRONT_TO_BACK to help hardware to do the job. I am in negotiation with my client to put osgLighting and osgGLSL (the shader generator) in OpenSource. But this will not happen before summer I think. Many people to convince that OpenSource is the good way for every body. HTH David Callu 2011/4/19 Jean-Sébastien Guay jean-sebastien.g...@cm-labs.com Hi Chris, First of all, I have to commend you on all the work you've put into doing this. You obviously put a lot of thought and research into your problem, and explored multiple avenues before posting, which I have to admire! I've personally never needed more than the 8 light sources the fixed pipeline gave me, so I've always used the built-in gl_LightSource[i] structure and osg::LightSource+osg::Light to manage my lights. I have a mechanism in place that lets me reuse light IDs when lights get turned on or off (a light turned off frees its light ID, and a light turned on will take the first available light ID), and this uses IDs 0-7, which has been sufficient for me. Add to that the fact that OSG's built-in shadow techniques support casting shadows from only one light, and I've never really had a need (personally or from client requirements) to go further. But that's not to say it won't happen. What I'd say in response to your question is, I think you have a good idea of what is the best solution to your problem (solution 1), but it requires some small changes to OSG itself in order to be feasible. So what prevents you from proposing these changes? Robert hasn't
Re: [osg-users] Multiple lights in a scene
Hi Gordon, I hope those puns were intended, in any case, they brightened my day ;) I did search the archives and found one reference to the osgmanylights tutorial, but unfortunately it is no longer on the site that it was linked to, does anyone have a copy of that tutorial lying around in their archive? The old link was: http://www.fx.clemson.edu/~acnatha/devnull/osg/osgmanylights.tar.gz I was however able to successfully implement pixel-based lighting in a fragment shader with as many lights as desired (up to shader memory limits of course). I basically just defined my own uniform array of gl_LightSourceParameters in the shader program. The values of these custom lights are controlled with uniforms which, when wrapped up in a LightUniforms class provides an API identical to osg::Light. A LightShader class, derived from osg::Shader, provides an interface for setting the number of lights which basically just does a search and replace of a special string (i.e. NUM_LIGHTS) in the shader source and then forces a recompilation of the shader program. This all works fine. The problem comes however in positioning the lights. If I understand correctly, OSG uses a LightSource placed in the scenegraph to modify the position of its associated Light according according to its parent transformation(s). This gets done by the PositionalStateContainer which gets added to the RenderStage during cull traversal in CullVisitor::accept(LightSource) - RenderStage::addPositionedAttribute(). I was thinking about a couple of solutions to this: 1. Derive my own classes from osg::Light and osg::LightSource. This is problematic for a number of reasons: - CullVisitor, being a Visitor class, cannot be expanded (without modifying its interface) to recognize new classes (one of the tradeoffs for the Visitor pattern). So it will not recognize my derived LightSource class, if I understand the Visitor pattern correctly. - Deriving from osg::Light, which calls fixed function opengl lighting calls, causes GLMode errors for light numbers = GL_MAX_LIGHTS. 2. Do not derive my own classes osg::Light and osg::LightSource, but instead make my LightSource-type class subclass from osg::Group directly, override the traverse() method, extract the localtoWorld transform from the visitor object and and based on that set the position and spotdirection on the (non osg derived) Light. However, this has some other side effects: - we have a shadow class, based on osg::ShadowTechnique, which relies on the PositionalStateContainer mechanism described above to position the shadow projectors to coincide with the osg::Light. Not using the osg::Light will not trigger this mechanism. At the moment I'm leaning toward solution 2, but then that would force me to adapt the shadowing class (which I inherited and it isn't pretty). I would like to get solution 1 to work though, but I can't figure out a way to use the osg::Light/LightSource interface and prevent it from calling the opengl fixed function API. It would be nice if all the osg::Light methods were virtual, then I could just derive my LightUniforms based class from osg::Light. I did read in the OSG QSG, page 69: OSG lets you use more light sources than the underlying OpenGL implementation supports, but this is beyond the scope of this book. Is there another resource whose scope this isn't beyond? Does this have to do with multiple RenderStages, which I suspect is in the osgmanylights example? Thanks, Chris On Tue, Nov 18, 2008 at 8:05 PM, Tomlinson, Gordon gtomlin...@overwatch.textron.com wrote: Search the mailing list archive will find many illuminating answers to this type of question Opengl only supports 8 active light sources thus OSG supports one 8 active light sources Also search the Opengl sites for more enlightenment Gordon __ Gordon Tomlinson Product Manager 3D Email : gtomlinson @ overwatch.textron.com __ (C): (+1) 571-265-2612 (W): (+1) 703-437-7651 Self defence is not a function of learning tricks but is a function of how quickly and intensely one can arouse one's instinct for survival - Master Tambo Tetsura From: osg-users-boun...@lists.openscenegraph.org [mailto:osg-users-boun...@lists.openscenegraph.org] On Behalf Of dasari pavan kumar Sent: Tuesday, November 18, 2008 12:50 PM To: osg-users@lists.openscenegraph.org Subject: Re: [osg-users] Multiple lights in a scene Hi, I am relatively new to using Lights in openscenegraph. I would like to have a single light replicated 100 times at different places (The situation is something like this. I need to light all the rooms in an apartment. however every light is of the same ambient and diffuse color). But the lights are not being rendered in the scene. Can anyone help me with this situation ? I have created a LightSource with certain light
Re: [osg-users] Multitexture in Shader
Hi Linda, Did you ever get this to work? I'm seeing the same problem: Specifying multiple textures and then accessing them in the (fragment) shader always returns the data from the first texture. Cheers, Chris On Tue, Mar 15, 2011 at 2:49 PM, Linda Lee zenith...@hotmail.com wrote: Hi, Has anyone encountered this problem where only the first texture at layer 0 seems to successfully passed to the shader code but not the other textures with textureID of 1, 2, ... ? Thank you! Cheers, Linda -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=37622#37622 ___ 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] Forward declarations and ref_ptr members
Would the pimpl algorithm be applicable to your situation if you want
to minimize compile time dependencies?
On Tue, Feb 8, 2011 at 2:50 PM, Jesper D. Thomsen j...@anybodytech.com wrote:
Hi all, I’m trying to prune out the number of includes in my headers, in
order to keep from including OSG in all parts of my application.
I have a couple of places where I would like to forward declare
osg::ref_ptr, but so far I have had no success with that.
Specifically, I would like to forward declare:
osg::ref_ptrosg::Material
And
osg::ref_ptrosg::Node
I tried adding:
namespace osg
{
class Node;
class Material;
template typename T class ref_ptr;
};
To the header file as suggested in the thread titled “Forward declared
classes and ref_ptrs”, but I’m still getting the following error:
error C2079: 'asg::ASGContainer::m_osgroot' uses undefined class
'osg::ref_ptrT'
I searched a bit on the internet and saw that in Boost they had made some
special additions to their reference counted pointer in order to enable
forward declarations.
If osg::ref_ptr doesn’t support forward declarations, I can of course
refactor my classes a bit in order to control which ones include OSG, but I
would prefer using the forward declaration.
Regards, and some forward declared thanks J
Jesper D. Thomsen
AnyBody Technology A/S
___
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
