Re: [osg-users] ShaderGen and GL3
Hi Robert, The ftransform function has been removed from the OpenGl 3.2 core profile. Tom Jolley > -Original Message- > From: Robert Osfield [mailto:robert.osfi...@gmail.com] > > Hi Paul, > > Using osg_*Matrix > would preclude the use of the ftransform() convenience > function though. > > Robert. > ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] ShaderGen and GL3
Hi Paul, Thanks for the clarification. If it turns out we can't use gl_ then I think it would be best to standardise on an osg_ModelViewMatrix and osg_ProjectionMatrix etc, for both GL2, GL3 and GL ES2, and for GL2 toggle between use gl*Matrix calls and setting the osg_*Matrix uniform depending upon when shaders are active or not. Using osg_*Matrix would preclude the use of the ftransform() convenience function though. Robert. On Fri, Aug 14, 2009 at 6:07 PM, Paul Martz wrote: > For the record, I was quoting the latest GLSL 1.50 spec, so "gl_" is > reserved, even for current OpenGL 3.2. > > If OSG provides a mechanism that allows the user to specify the names that > matrices are associated with, then OSG could go ahead and violate the spec > and use "gl_" names by default, but apps would still have the flexibility to > be spec compliant and change the names if they desired to do so. > > Paul Martz > Skew Matrix Software LLC > http://www.skew-matrix.com > +1 303 859 9466 > > Jason Daly wrote: > > Robert Osfield wrote: > > If GL3 isn't providing any gl_ uniforms surely they can't be reserved, > you can only reserve something if it might exists. I can see why gl_ > will be reserved for GL2, but I can't see the issue for non backwards > compatible GL3. > > > It doesn't provide uniforms, but there are gl_* identifiers still in use > (gl_Position, for example). > Besides, it doesn't really matter whether we think it's an issue or not. If > the spec says they're illegal, then the GLSL compiler will likely throw an > error any time a shader tries to use one that's not declared by GL itself (I > haven't tried this personally, but that's what I would expect) > > --"J" > > ___ > 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] ShaderGen and GL3
Hi Paul, Hi again, Robert. If you really must use the "gl_" name for matrix uniforms, then perhaps OSG's path forward for GL3 is to use the compatibility profile, which preserves all that old GL1/2 stuff. But it won't be "real" GL3 if you take this approach. I don't think that's a good solution, better we just keep OSG on GL2 if we're going to do that. I personally don't see the problem with using osg_ModelViewMatrix and osg_ProjectionMatrix instead of gl_*... It rather highlights that it's not OpenGL doing that work anymore, but OSG. That's the GL3 philosophy after all. And if we think about it, if we're going to have multiple render back-ends, perhaps even DirectX, does it make sense to have gl_ in the variable names? I think DX is similar to GL3 in that it lets you name the input/output of your shaders however you want, so I would say an osg_* prefix would make sense. If we are indeed going to branch OSG for GL3, then perhaps the best solution is to have the community maintain both branches. Apps on oldOSG would port to newOSG as they see fit, (with changes such as matrix uniform names). I think that's inevitable, see how many people are still on OSG 2.2 or even 1.2, even if the port to recent versions is rather straightforward. People will continue to use OSG 2.x long after OSG 3.x using OpenGL 3.x is out. The community maintenance part might not happen though. Perhaps the 2.x series will continue to have bug fix releases, and perhaps its maintenance could be handed over to someone else, but I doubt the same would happen for the 3.x series. I think Robert will want to keep doing what he's doing now. J-S -- __ Jean-Sebastien Guayjean-sebastien.g...@cm-labs.com http://www.cm-labs.com/ http://whitestar02.webhop.org/ ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] ShaderGen and GL3
Robert Osfield wrote: If GL3 isn't providing any gl_ uniforms surely they can't be reserved, you can only reserve something if it might exists. I can see why gl_ will be reserved for GL2, but I can't see the issue for non backwards compatible GL3. Hi again, Robert. If you really must use the "gl_" name for matrix uniforms, then perhaps OSG's path forward for GL3 is to use the compatibility profile, which preserves all that old GL1/2 stuff. But it won't be "real" GL3 if you take this approach. I know that I personally have clients that are looking to minimize disruption as OSG moves to GL3. On the other hand, GL3 is a new API and it seems like the best way for OSG to move forward is a clean break. If we are indeed going to branch OSG for GL3, then perhaps the best solution is to have the community maintain both branches. Apps on oldOSG would port to newOSG as they see fit, (with changes such as matrix uniform names). The old branch would continue to not just exist but also improve and grow, as long as the community continues to support it. This seems like it would be less work than trying to continue to support all the features deprecated in GL3. -Paul ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] ShaderGen and GL3
Robert Osfield wrote: Now if users want to deviate from standard implementations and do there own funky matrix management then they could define their own uniforms for this. Agreed, users could define their own uniforms for any transformations they need. A callback would be overkill. Paul Martz Skew Matrix Software LLC http://www.skew-matrix.com +1 303 859 9466 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] ShaderGen and GL3
For the record, I was quoting the latest GLSL 1.50 spec, so "gl_" is reserved, even for current OpenGL 3.2. If OSG provides a mechanism that allows the user to specify the names that matrices are associated with, then OSG could go ahead and violate the spec and use "gl_" names by default, but apps would still have the flexibility to be spec compliant and change the names if they desired to do so. Paul Martz Skew Matrix Software LLC http://www.skew-matrix.com +1 303 859 9466 Jason Daly wrote: Robert Osfield wrote: If GL3 isn't providing any gl_ uniforms surely they can't be reserved, you can only reserve something if it might exists. I can see why gl_ will be reserved for GL2, but I can't see the issue for non backwards compatible GL3. It doesn't provide uniforms, but there are gl_* identifiers still in use (gl_Position, for example). Besides, it doesn't really matter whether we think it's an issue or not. If the spec says they're illegal, then the GLSL compiler will likely throw an error any time a shader tries to use one that's not declared by GL itself (I haven't tried this personally, but that's what I would expect) --"J" ___ 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] ShaderGen and GL3
Robert Osfield wrote: If GL3 isn't providing any gl_ uniforms surely they can't be reserved, you can only reserve something if it might exists. I can see why gl_ will be reserved for GL2, but I can't see the issue for non backwards compatible GL3. It doesn't provide uniforms, but there are gl_* identifiers still in use (gl_Position, for example). Besides, it doesn't really matter whether we think it's an issue or not. If the spec says they're illegal, then the GLSL compiler will likely throw an error any time a shader tries to use one that's not declared by GL itself (I haven't tried this personally, but that's what I would expect) --"J" ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] ShaderGen and GL3
Hi Paul, On Fri, Aug 14, 2009 at 5:19 PM, Paul Martz wrote: > I'd caution against reusing the "gl_" names. The GLSL spec, section 3.7, > says: "Identifiers starting with “gl_” are reserved for use by OpenGL, and > may not be declared in a shader as either a variable or a function." I'd > propose a mechanism that allows the application to specify the uniform > variable names these matrices should map to. Then, if the app wants to reuse > the reserved "gl_" names, they are free to do so, but apps that want to > write cleaner code are free to use other names. If GL3 isn't providing any gl_ uniforms surely they can't be reserved, you can only reserve something if it might exists. I can see why gl_ will be reserved for GL2, but I can't see the issue for non backwards compatible GL3. > But I like the idea of setting these uniforms directly in State. Very > efficient solution. >> >> Need for the inverse versions and combinations >> could also be supported via osg::State. >> >> One in theory could name the projection and modelview matrices >> anything you want but personally I think it would be good to stick >> with a standard naming to avoid confusion and the need for extra API >> to set them consistently. >> > > :-) Looks like we disagree. > > While I don't think adding an entry point to let the app specify the matrix > uniform names would be too cumbersome, I'm open to other options for > providing this same flexibility. Could there be a simple API solution such > as a callback that could be executed when one of these matrices change > during draw? This would allow apps to register a callback that would set > matrices for any uniform variable name they desire. This would avoid the > reserved prefix issue without adding too much API entry point bulk. IMHO, a callback would be really cumbersome. If we have to modify the name of the modelview and projection matrix then we should just expose the Uniforms used directly in osg::State, and one would have to have some scene graph API for setting these. It's the later which is where things would get more complicated as we'd have to make sure that the API and assocaited scene graph data is serialized. None of this is really complicated, but it's more complicated for end users than just being able to assume gl_ values are provided by default. > In fact, I think I prefer this latter solution, as it's more in the GL3 > flavor. GL3 does not have a modelview or projection matrix, and apps send to > shaders only whatever matrices they need, or none at all. GL3 might not have a modelview and projection matrix but the vast majority of scene graph applications will still need them, they exist for a good reason - they are darn useful. The OSG itself has special treatment of management of projection and modelview matrices as well, and I fully expect us to be using them in 20 years time except for very specific graphics solutions. > A callback > mechanism that notifies the app when an OSG matrix changes would allow the > app to perform different operations on the matrix and send down only the > data desired. Or apps could emulate the old GL1/2 modelview/projection > paradigm, if they choose to do so. I really don't think a callback would be at all useful in this context, it's really out of keeping with how matrices are currently managed, and would require specialist treatment by far more OSG users than should be required. Standard modelview and projection matrices should be part of the bedrock of what services the OSG provides end users, and should be done in consistent and standard way across GL versions. Performance wise we also want to avoid as many code indirections (such as if's and virtual functions) for very standard features. Now if users want to deviate from standard implementations and do there own funky matrix management then they could define their own uniforms for this. In the case with shaders the only the uniforms that are used by the shaders are bound, the rest are ignored, so if you didn't use the standard uniforms they wouldn't be bound and should safely be ignored. Robert. ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] ShaderGen and GL3
Robert Osfield wrote: Hi Guys, I've been on holiday during this thread, so now just catching up... some brief thoughts on some of the points raised. Thanks for adding to the thread, Robert. I hope your holiday was enjoyable. First up, modelview and projection matrices are something that the OSG can pass to GL3/OpenGLES2 by assigning a standard uniform to each of these matrices and then having osg::State::applyModelViewMatrix(RefMatrix*) and osg::State::applyProjectionMatrix(RefMatrix*) set these uniforms automatically. This will isolate the required changes to just osg::State. I'd suggest that these uniforms target the standard gl_ProjectionMatrix and gl_ModelViewMatrix uniform names for consistency with GL2. I'd caution against reusing the "gl_" names. The GLSL spec, section 3.7, says: "Identifiers starting with “gl_” are reserved for use by OpenGL, and may not be declared in a shader as either a variable or a function." I'd propose a mechanism that allows the application to specify the uniform variable names these matrices should map to. Then, if the app wants to reuse the reserved "gl_" names, they are free to do so, but apps that want to write cleaner code are free to use other names. But I like the idea of setting these uniforms directly in State. Very efficient solution. Need for the inverse versions and combinations could also be supported via osg::State. One in theory could name the projection and modelview matrices anything you want but personally I think it would be good to stick with a standard naming to avoid confusion and the need for extra API to set them consistently. :-) Looks like we disagree. While I don't think adding an entry point to let the app specify the matrix uniform names would be too cumbersome, I'm open to other options for providing this same flexibility. Could there be a simple API solution such as a callback that could be executed when one of these matrices change during draw? This would allow apps to register a callback that would set matrices for any uniform variable name they desire. This would avoid the reserved prefix issue without adding too much API entry point bulk. In fact, I think I prefer this latter solution, as it's more in the GL3 flavor. GL3 does not have a modelview or projection matrix, and apps send to shaders only whatever matrices they need, or none at all. A callback mechanism that notifies the app when an OSG matrix changes would allow the app to perform different operations on the matrix and send down only the data desired. Or apps could emulate the old GL1/2 modelview/projection paradigm, if they choose to do so. -Paul ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] ShaderGen and GL3
Hi Guys, I've been on holiday during this thread, so now just catching up... some brief thoughts on some of the points raised. First up, modelview and projection matrices are something that the OSG can pass to GL3/OpenGLES2 by assigning a standard uniform to each of these matrices and then having osg::State::applyModelViewMatrix(RefMatrix*) and osg::State::applyProjectionMatrix(RefMatrix*) set these uniforms automatically. This will isolate the required changes to just osg::State. I'd suggest that these uniforms target the standard gl_ProjectionMatrix and gl_ModelViewMatrix uniform names for consistency with GL2. Need for the inverse versions and combinations could also be supported via osg::State. One in theory could name the projection and modelview matrices anything you want but personally I think it would be good to stick with a standard naming to avoid confusion and the need for extra API to set them consistently. On the topic of Fixed Function Pipeline fallback such as osg::Fog etc., in the first pass I think we should drop all this state support for the initial GL3 port, and have converters like the ShaderGen visitor map the FFP state attributes to shaders. The class like osg::Fog would effectively just become GL non ops, with their osg::StateAttribute::apply() method doing nothing, they would however still store their data so readers/writers could still load data, and apps would still compile - these loaded scene graph with the GL non op attributes in wouldn't work properly for rendering but would leave the door open to conversion to shaders at runtime. Later down the line once we have runtime shader composition working we can map the likes of osg::Fog etc to uniforms and associated shaders that we can use to compose the final program required by GL3. Once we get to this stage StateAttributes will effectively become containers for uniforms, and the old fixed function GL modes would become toggles for different shaders to be linked into the shader main. Robert. ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] ShaderGen and GL3
Jean-Sébastien Guay wrote: Still, your visitor is interesting, extending it would be good, and testing it by having OSG create a GL3 context (perhaps even GL3.1 so that it errors out when using deprecated functionality) would be even better. I've given this some thought, and tried to write this "GL3-safe OSG" app in such a way that, even if OSG does issue deprecated GL1/2 commands (which it certainly does: glMatrixMode and glLight are always called at least once per frame in current osgViewer apps), that it would not affect the execution of the app. GL calls that generate errors have no effect on OpenGL state, so if the app doesn't depend on those functions working, I'd think that the app should still function on a 3.1 context in spite of OSG continuing to issue GL 1/2 calls. But the 3.1 context would help us track down all OSG code that issues GL 1/2 commands. I am meeting with my client next week, the one who is really interested in future-proofing all their new OSG development from this point forward, and it'll be interesting to discuss the road forward with them. I'm looking forward to getting additional funding from this client to pursue this work, such as GL 3.1 context creation in OSG. But this work needs to be prioritized against other work the client has lined up for me, Cheers, -Paul ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] ShaderGen and GL3
Hi Paul, I think we want to allow for apps that don't specify vertices from host code, and forcing the app to call Geometry::setVertexPointer in such a case would obfuscate the code. If an app wants to use only generic vertex attributes, OSG needs to change to allow this. Sure, but it can allow it while the default usage will be to use setVertexPointer (or some other nomenclature that caters more to flexible vertex formats) to simplify code for users that just want to do rendering quick and easy. This type of usage (Geometry without a vertex pointer) introduces a new issue, which I alluded to in my BOF presentation: How does OSG cull if the Geometry has no vertices, and therefore no bounding box? setInitialBounds could be a solution, disabling culling on the Geometry is another option. I think if the user is creating vertices in a geometry shader or some other way that doesn't include any vertices on the CPU, then the user should think of some way of specifying their own tight bounds so that OSG can cull that geometry efficiently. There is already a ComputeBoundsCallback the user can use for that, in addition to setInitialBounds (if the bounds never change) and disabling culling, as you said. I think that's just a case where the user knows more than OSG does, so the user needs to take control and tell OSG what he/she wants. Once again, graphics programming without a safety net. On one hand, I have clients with large OSG-based apps, and the last thing they want is some kind of disruptive change in OSG. To serve them, I think we really do need to continue to support the old FFP state in GL3. Yep. On the other hand, there's a reason why OpenGL ditched the old FFP feature set: Apps that use *all* the features simultaneously are rare, and testing these features was an O(n^n) problem. Eliminating the features allows for equivalent functionality in much simpler app-specific shaders. If OSG tries to move forward with the old FFP feature set, we will be attempting to do what hardware vendors like ATI and NVIDIA have given up on. As more features are added to OSG, the problem will only get worse. Yep. (We already have such feature mixing issues in OSG. Ever try to use osgText with osgShadow? Both nodekits think they own texture unit 0... I've intended to make the texture unit a configurable option for some time now, but haven't gotten to it.) Well in the past, I've placed text objects outside the osgShadow::ShadowedScene, or put osgText::Text under a Geode that has only such objects and set an empty program on that Geode. Now that last one isn't really an option anymore, but to accomodate GL3 osgText::Text will probably have to have its own shader anyways, so that should work... But I'm sidestepping your point, which is valid. It's an n^n problem, because what if I want text to cast a shadow? What if I want text that casts a shadow under the ocean? (I recently had trouble mixing osgOcean and osgShadow in the same way, so I can extrapolate). That's a problem in general with shaders. Even if we make OSG use shader fragments, how will we test that all fragments can interact well with all other fragments? It's only really at runtime (and visually to boot) that we'll know - we'd need to test all combinations and see if there are rendering problems. If there are subtle shading problems when we add a certain fragment, we might not even notice. I'm currently very interested in researching ways to write apps that use OSG today in such a way that they avoid OSG functionality that is currently implemented on GL 1/2. The idea being, if you write your app this way, then any future changes to OSG aimed at supporting GL3 will be inconsequential. It's an interesting thought, but it may end up being a lot of work (maybe even as much as writing the app in straight GL3) if OSG ends up supporting GL3 in a manner that's transparent (compared to OSG/GL2). That's why I'd like Robert to enter this discussion so that we can figure out a clear direction for OSG sooner rather than later - it will remove much speculation and allow us to future-proof our code in a way we're sure won't be wasted time. Still, your visitor is interesting, extending it would be good, and testing it by having OSG create a GL3 context (perhaps even GL3.1 so that it errors out when using deprecated functionality) would be even better. I agree, interesting discussion. J-S -- __ Jean-Sebastien Guayjean-sebastien.g...@cm-labs.com http://www.cm-labs.com/ http://whitestar02.webhop.org/ ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] ShaderGen and GL3
Jean-Sébastien Guay wrote: I bet it wouldn't be too hard to add apply(osg::Camera& camera) that would set view and projection matrix uniforms, as well as apply(osg::Transform& transform) for the current local-to-world matrix (and perhaps uniforms for model*view, model*view*projection for convenience). Good thought. I've been mulling ways to set local2world, view, normal, and projection matrices in a manner non-intrusive to app code. Unfortunately I need to table this while I work on some other stuff, but hopefully I'll resume this work in the near future. Well I think for the basic functionality (vertex positions, normals, vertex colors, texcoords and the normal matrices) an app should not have to change other than modifying its shaders to use new names. OSG is after all a rendering library, so I think we can assume most apps will use this functionality as a bare minimum. Agreed, OSG is a rendering library. So is OpenGL, but OpenGL 3 allows apps to not specify vertices on the host, and instead procedurally generate clip coordinate positions as output of the vertex shader. In contrast, the current Geometry::drawImplementation is a no-op if the vertex pointer is not set. I think we want to allow for apps that don't specify vertices from host code, and forcing the app to call Geometry::setVertexPointer in such a case would obfuscate the code. If an app wants to use only generic vertex attributes, OSG needs to change to allow this. This type of usage (Geometry without a vertex pointer) introduces a new issue, which I alluded to in my BOF presentation: How does OSG cull if the Geometry has no vertices, and therefore no bounding box? setInitialBounds could be a solution, disabling culling on the Geometry is another option. After that we can decide whether we want to keep the current wrapping of fixed-pipeline state (for example osg::Fog) and have it set uniforms when needed. I flip back and forth on this. On one hand, I have clients with large OSG-based apps, and the last thing they want is some kind of disruptive change in OSG. To serve them, I think we really do need to continue to support the old FFP state in GL3. On the other hand, there's a reason why OpenGL ditched the old FFP feature set: Apps that use all the features simultaneously are rare, and testing these features was an O(n^n) problem. Eliminating the features allows for equivalent functionality in much simpler app-specific shaders. If OSG tries to move forward with the old FFP feature set, we will be attempting to do what hardware vendors like ATI and NVIDIA have given up on. As more features are added to OSG, the problem will only get worse. (We already have such feature mixing issues in OSG. Ever try to use osgText with osgShadow? Both nodekits think they own texture unit 0... I've intended to make the texture unit a configurable option for some time now, but haven't gotten to it.) It seems like a "d*mned if we do, d*mned if we don't" kind of problem. But certainly one worth discussing. So I think we have to answer a basic question before we do any actual work: Do we want OSG to be like it was before, and basically become a GL2 layer over GL3? That would make it easier to use than straight GL3 for beginners, I think, but it would make OpenGL programming less hands-on than straight GL3. Of course, if we do it right we can still expose all the GL3 code paths through a thin layer like was done for GL2, so people who wanted to use all the freedom and generality of GL3 could still do so. But OSG would become a good solution for people who wanted an easier way of doing graphics programming than the "programming without a safety net" model that GL3 offers. I personally think this is a great opportunity for OSG to position itself as a great solution that offers all the power of OpenGL 3 but with a gentler learning curve. Excellent points, and well-said. This really is the question. And as I said above, there is existing code that is counting on the old FFP interface continuing to be supported in OSG. I'm currently very interested in researching ways to write apps that use OSG today in such a way that they avoid OSG functionality that is currently implemented on GL 1/2. The idea being, if you write your app this way, then any future changes to OSG aimed at supporting GL3 will be inconsequential. Good discussion. -Paul ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] ShaderGen and GL3
Hi Paul,
Hi J-S -- Good discussion. Thanks for responding to my OSG BOF pleas to
start discussing GL3 in osg-users. :-)
Heh, I think this kind of discussion is long overdue... OpenGL 3.0 has
been out for a year after all. :-)
I have the start of a NodeVisitor that will change all Geometry classes
to use generic vertex attributes, as well as switch DLs to buffer
objects. See below. I can also set uniform matrix values for the view
and projection matrices in the app main loop.
While this is certainly an incomplete solution, it does allow me to use
GLSL 1.30 shaders without any deprecated functionality. I currently have
a GL3-safe cow running, doing all the transforms, lighting, and texture
coord generation in GLSL 1.30 shaders. (One major piece of missing
functionality is support for any model transforms buried in the scene
graph. But it's a start.)
That's a good start, though it assumes vertices and normals will always
be present and will always go in positions 0 and 1 (that's why you're
discussing attribute array names with Robert in another thread, I realize).
You could also place vertex colors in attribute position 2. You could
probably also check if a texture is currently bound to unit 0+i and then
set texcoords from unit 0+i to attrib position 3+i, etc.
I bet it wouldn't be too hard to add apply(osg::Camera& camera) that
would set view and projection matrix uniforms, as well as
apply(osg::Transform& transform) for the current local-to-world matrix
(and perhaps uniforms for model*view, model*view*projection for
convenience).
Then later we could even extend the visitor so that at each node, it
accumulates and checks all state and sets uniforms for the
StateAttributes we're interested in.
Ideally, OSG apps should not need to change at all to be compatible with
GL3. However, at this point, it's too early to tell whether this will be
the case or not. With that in mind, I feel that exploring ways for
applications to use OSG in a GL3-safe way is a worthwhile endeavor,
especially for new app development. If there are ways for apps to take
responsibility for using vertex attribs and setting their own uniforms,
we need to research this and make the methods known, so that new
development can use these techniques and avoid any porting headaches
that might otherwise arise in the future.
Well I think for the basic functionality (vertex positions, normals,
vertex colors, texcoords and the normal matrices) an app should not have
to change other than modifying its shaders to use new names. OSG is
after all a rendering library, so I think we can assume most apps will
use this functionality as a bare minimum.
After that we can decide whether we want to keep the current wrapping of
fixed-pipeline state (for example osg::Fog) and have it set uniforms
when needed (say int osg_Fog_Type --> FOG_LINEAR, FOG_EXP, FOG_EXP2
which could be defines; float osg_Fog_start, float osg_Fog_end, float
osg_Fog_density, vec4 osg_Fog_color for example), or if we want to do it
some other way. I don't know in what way, but perhaps someone will think
of some more elegant way.
Since GLSL allows you to define your own structs, perhaps we could do
something similar to what GLSL 1.2 did, instead of the above. Something
like:
struct osg_FogParameters {// From glsl_quickref.pdf, s/gl_/osg_/
vec4 color;
float density;
float start;
float end;
float scale;
};
uniform osg_FogParameters osg_Fog;
...
...
vec4 fogColor = osg_Fog.color;
...
...
But as I said above, perhaps someone will have a better idea, as this
would just basically re-do all the features that GL3 removed...
So I think we have to answer a basic question before we do any actual
work: Do we want OSG to be like it was before, and basically become a
GL2 layer over GL3? That would make it easier to use than straight GL3
for beginners, I think, but it would make OpenGL programming less
hands-on than straight GL3. Of course, if we do it right we can still
expose all the GL3 code paths through a thin layer like was done for
GL2, so people who wanted to use all the freedom and generality of GL3
could still do so. But OSG would become a good solution for people who
wanted an easier way of doing graphics programming than the "programming
without a safety net" model that GL3 offers. I personally think this is
a great opportunity for OSG to position itself as a great solution that
offers all the power of OpenGL 3 but with a gentler learning curve.
What do you think?
J-S
--
__
Jean-Sebastien Guayjean-sebastien.g...@cm-labs.com
http://www.cm-labs.com/
http://whitestar02.webhop.org/
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] ShaderGen and GL3
Hi J-S -- Good discussion. Thanks for responding to my OSG BOF pleas to
start discussing GL3 in osg-users. :-)
I have the start of a NodeVisitor that will change all Geometry classes
to use generic vertex attributes, as well as switch DLs to buffer
objects. See below. I can also set uniform matrix values for the view
and projection matrices in the app main loop.
While this is certainly an incomplete solution, it does allow me to use
GLSL 1.30 shaders without any deprecated functionality. I currently
have a GL3-safe cow running, doing all the transforms, lighting, and
texture coord generation in GLSL 1.30 shaders. (One major piece of
missing functionality is support for any model transforms buried in the
scene graph. But it's a start.)
Ideally, OSG apps should not need to change at all to be compatible
with GL3. However, at this point, it's too early to tell whether this
will be the case or not. With that in mind, I feel that exploring ways
for applications to use OSG in a GL3-safe way is a worthwhile endeavor,
especially for new app development. If there are ways for apps to take
responsibility for using vertex attribs and setting their own uniforms,
we need to research this and make the methods known, so that new
development can use these techniques and avoid any porting headaches
that might otherwise arise in the future.
class MakeGeneric : public osg::NodeVisitor
{
public:
MakeGeneric()
: osg::NodeVisitor( osg::NodeVisitor::TRAVERSE_ALL_CHILDREN ) {}
~MakeGeneric() {}
void apply( osg::Geode& geode )
{
unsigned int idx;
for( idx=0; idx
{
osg::Drawable* draw = geode.getDrawable( idx );
draw->setUseDisplayList( false );
draw->setUseVertexBufferObjects( true );
osg::Geometry* geom = draw->asGeometry();
if( geom == NULL ) continue;
geom->setVertexAttribData( 0,
osg::Geometry::ArrayData( geom->getVertexArray(),
osg::Geometry::BIND_PER_VERTEX ) );
geom->setVertexAttribData( 1,
osg::Geometry::ArrayData( geom->getNormalArray(),
osg::Geometry::BIND_PER_VERTEX ) );
}
}
protected:
const osg::Program& _prog;
};
Paul Martz
Skew Matrix Software LLC
http://www.skew-matrix.com
+1 303 859 9466
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] ShaderGen and GL3
Hi Paul, ShaderGen was written for GL2 and OSG-2.x, it doesn't provide a first step at looking towards GL3, but in the context of OSG-2.x, look at it as a first step. Robert. On Sat, Aug 8, 2009 at 9:39 PM, Paul Martz wrote: > Hi all -- I've finally had a chance to review the ShaderGen code. If I > understand correctly, this was added as a step towards eventual support for > OpenGL 3. However, I'm surprised by the OpenGL 2 / GLSL 1.20 nature of the > shader code, specifically the extensive dependency on built-in uniforms and > predefined vertex attributes that were deprecated with OpenGL 3 / GLSL 1.30 > -- even use of ftransform(). > > Was the author assuming the code would be ported to OpenGL 3 / GLSL 1.30 in > the future? Or was the author assuming that the host would set up uniforms > and vertex attributes with names identical to the old GLSL 1.20 uniform and > vertex attribute names (that would be a mistake in my opinion, as uniforms > and vertex attributes starting with "gl_" are reserved)? Or have a simply > misunderstood the point of this code? > > Thanks. > -- > > Paul Martz > Skew Matrix Software LLC > http://www.skew-matrix.com > +1 303 859 9466 > > ___ > 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] ShaderGen and GL3
Skylark wrote: > > http://article.gmane.org/gmane.comp.graphics.openscenegraph.cvs/5005/match=fixed+function+pipeline+glsl+generator > http://thread.gmane.org/gmane.comp.graphics.openscenegraph.cvs/5087 > > Note that the thread seems to have been broken at some point, so the > only way to get all messages might be to search for the title: > > http://search.gmane.org/?query=Fixed+Function+Pipeline+to+GLSL+generator&author=&group=gmane.comp.graphics.openscenegraph.cvs&sort=relevance&DEFAULTOP=and&xP=Zshadergen&xFILTERS=Gcomp.graphics.openscenegraph.cvs---A > > (you might have to stitch the URLs manually if my/your client cuts them > while trying to word wrap...) > Note that we also have a searchable forum where broken threads are fixed by moderators: Fixed function pipeline -> GLSL shaders discussion http://forum.openscenegraph.org/viewtopic.php?t=1600 Fixed Function Pipeline to GLSL generator submission by Maciej Kol http://forum.openscenegraph.org/viewtopic.php?t=1757 kind regards, Roland Smeenk (Forum moderator) -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=16023#16023 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] ShaderGen and GL3
Hi Paul, Hi J-S -- ShaderGen could have avoided the use of deprecated built-in uniforms and deprecated predefined vertex attributes by using custom uniforms and generic vertex attributes. These features are already available in GL2, so testing would not have been an issue, had the author chosen to write ShaderGen in such a manner. Hm, perhaps I'm missing something here, but wouldn't we need to change osg::Geometry itself to make it put vertex attributes (position, normal, color, texcoord) into generic attributes instead of the predefined ones? Also, making custom uniforms for the modelview matrix for example is non-trivial as well, since it would require another traversal and setting it at each osg::Transform we encounter (or modifying osg::Transform itself). These changes will come in as modifications to the OSG core anyways sometime, so changing one example to do it that way seems like a waste of time to me. If you want all new examples to take this route, then we'd be duplicating code everywhere until the changes are made to the core... Once the changes happen, it'll just be a matter of changing variable names... I don't see it as a major hurdle. You may disagree of course. As it currently stands, ShaderGen just looks like new GL2-dependent code. :-( As a community, I'd like to see us all stop contributing new GL2-based code (I realize I have no control over this), and have all new contributions be as GL3-safe as possible. I think if it were possible I would agree wholeheartedly with you, but I don't think it's possible without changing the core to work in a GL3-friendly way too, so there's a dependency there. I think Robert should make a branch for GL3 investigation soon, and on that branch we could start implementing the basic changes needed (GL3 context creation, osg::Geometry setting the attributes the right way, perhaps osg::Transform setting uniforms when it's traversed by the cull visitor?, etc...). Until those basic changes take place I don't think we can make much progress. As I'm currently investigating OSG on OpenGL 3 for a client, I was curious to know: Was ShaderGen a work in progress? Was further work planned on ShaderGen to take us closer to GL3? If so, who's doing it and when can we expect fixes/updates? As a GL3 solution, why is so much of it incomplete? Etc. This will help me gauge and estimate the amount of work I'll need to do for my client. Thanks. I am in no way the original author. I'm just replying because no one else has and I'm interested in the subject. You can already see that even as a shader generator it's very simple. It doesn't translate most fixed-function state, only a few chosen bits. So even if you remove GL3 from the equation, it's largely incomplete and just a proof of concept. Some of the OSG examples are like that: more like tests than real educational examples. But as I said, I think in combination with VirtualProgram it may be a good direction to take. There was discussion about the example on osg-users and osg-submissions. The archives tell the story... The original author of the example was Maciej Krol, see this thread: http://article.gmane.org/gmane.comp.graphics.openscenegraph.cvs/5005/match=fixed+function+pipeline+glsl+generator http://thread.gmane.org/gmane.comp.graphics.openscenegraph.cvs/5087 Note that the thread seems to have been broken at some point, so the only way to get all messages might be to search for the title: http://search.gmane.org/?query=Fixed+Function+Pipeline+to+GLSL+generator&author=&group=gmane.comp.graphics.openscenegraph.cvs&sort=relevance&DEFAULTOP=and&xP=Zshadergen&xFILTERS=Gcomp.graphics.openscenegraph.cvs---A (you might have to stitch the URLs manually if my/your client cuts them while trying to word wrap...) Hope this helps, J-S -- __ Jean-Sebastien Guayjean-sebastien.g...@cm-labs.com http://www.cm-labs.com/ http://whitestar02.webhop.org/ ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] ShaderGen and GL3
Hi J-S -- ShaderGen could have avoided the use of deprecated built-in uniforms and deprecated predefined vertex attributes by using custom uniforms and generic vertex attributes. These features are already available in GL2, so testing would not have been an issue, had the author chosen to write ShaderGen in such a manner. As it currently stands, ShaderGen just looks like new GL2-dependent code. :-( As a community, I'd like to see us all stop contributing new GL2-based code (I realize I have no control over this), and have all new contributions be as GL3-safe as possible. As I'm currently investigating OSG on OpenGL 3 for a client, I was curious to know: Was ShaderGen a work in progress? Was further work planned on ShaderGen to take us closer to GL3? If so, who's doing it and when can we expect fixes/updates? As a GL3 solution, why is so much of it incomplete? Etc. This will help me gauge and estimate the amount of work I'll need to do for my client. Thanks. Paul Martz Skew Matrix Software LLC http://www.skew-matrix.com +1 303 859 9466 Jean-Sébastien Guay wrote: Hi Paul, Hi all -- I've finally had a chance to review the ShaderGen code. If I understand correctly, this was added as a step towards eventual support for OpenGL 3. However, I'm surprised by the OpenGL 2 / GLSL 1.20 nature of the shader code, specifically the extensive dependency on built-in uniforms and predefined vertex attributes that were deprecated with OpenGL 3 / GLSL 1.30 -- even use of ftransform(). Was the author assuming the code would be ported to OpenGL 3 / GLSL 1.30 in the future? Or was the author assuming that the host would set up uniforms and vertex attributes with names identical to the old GLSL 1.20 uniform and vertex attribute names (that would be a mistake in my opinion, as uniforms and vertex attributes starting with "gl_" are reserved)? Or have a simply misunderstood the point of this code? Well, I wonder, if the author had used OpenGL 3 functionality, how would he have tested the code? OSG currently has no way to create an OpenGL 3.x context... It's pretty simple to change uniform names and switch from using ftransform() to using vertex * modelViewProjection... ShaderGen was more a proof of concept of generating shaders from the accumulated state. I think this, along with the VirtualProgram example that Wojtek did, are good steps toward a possible solution for OpenGL 3 support. J-S ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] ShaderGen and GL3
Hi Paul, Hi all -- I've finally had a chance to review the ShaderGen code. If I understand correctly, this was added as a step towards eventual support for OpenGL 3. However, I'm surprised by the OpenGL 2 / GLSL 1.20 nature of the shader code, specifically the extensive dependency on built-in uniforms and predefined vertex attributes that were deprecated with OpenGL 3 / GLSL 1.30 -- even use of ftransform(). Was the author assuming the code would be ported to OpenGL 3 / GLSL 1.30 in the future? Or was the author assuming that the host would set up uniforms and vertex attributes with names identical to the old GLSL 1.20 uniform and vertex attribute names (that would be a mistake in my opinion, as uniforms and vertex attributes starting with "gl_" are reserved)? Or have a simply misunderstood the point of this code? Well, I wonder, if the author had used OpenGL 3 functionality, how would he have tested the code? OSG currently has no way to create an OpenGL 3.x context... It's pretty simple to change uniform names and switch from using ftransform() to using vertex * modelViewProjection... ShaderGen was more a proof of concept of generating shaders from the accumulated state. I think this, along with the VirtualProgram example that Wojtek did, are good steps toward a possible solution for OpenGL 3 support. J-S -- __ Jean-Sebastien Guayjean-sebastien.g...@cm-labs.com http://www.cm-labs.com/ http://whitestar02.webhop.org/ ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
[osg-users] ShaderGen and GL3
Hi all -- I've finally had a chance to review the ShaderGen code. If I understand correctly, this was added as a step towards eventual support for OpenGL 3. However, I'm surprised by the OpenGL 2 / GLSL 1.20 nature of the shader code, specifically the extensive dependency on built-in uniforms and predefined vertex attributes that were deprecated with OpenGL 3 / GLSL 1.30 -- even use of ftransform(). Was the author assuming the code would be ported to OpenGL 3 / GLSL 1.30 in the future? Or was the author assuming that the host would set up uniforms and vertex attributes with names identical to the old GLSL 1.20 uniform and vertex attribute names (that would be a mistake in my opinion, as uniforms and vertex attributes starting with "gl_" are reserved)? Or have a simply misunderstood the point of this code? Thanks. -- Paul Martz Skew Matrix Software LLC http://www.skew-matrix.com +1 303 859 9466 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
