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 Guay [email protected]
http://www.cm-labs.com/
http://whitestar02.webhop.org/
_______________________________________________
osg-users mailing list
[email protected]
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
