Hi Tim,
On Sat, Jun 26, 2010 at 6:05 PM, Tim Moore <[email protected]> wrote:
> 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?
Our traditional StateAttribute like osg::TexGen or osg::Light etc.
will all provide shaders, uniforms and the rules for injecting there
use into the main's of the vertex, geometry and fragment programs.
This will be exactly the same mechanism as when we'll be providing our
own custom shader, uniforms and rule for use when utilizing shader
composition. At least this is what I'm gunning for in my design work.
The existing StateAttribute subclasses will just be convenience
wrappers for a block of functionality. You might use them entirely,
or ignore them completely and use your own subclasses or
ShaderAttribute objects, or mix and match. It will be possible to
override the shaders and rules of the existing StateAttribute classes
as well.
>> 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?
Currently when you build the OSG specifically against GL3 it does so
with the assumption that you don't use the compatibility layer, it
does it using all shaders. I would like to get to the point when even
using GL2 we can run with using all shaders as well so the transition
between the GL2, GL3, GL4 and GLES2 is pretty seamless.
> Many users are effectively stuck at GL1.1 + hundreds of extensions,
> including ones that implement the capabilities of OpenGL 3.3 and 4.0.
That's fine, right now for the end user it doesn't make much
difference whether you build with GL1.1 with extensions or use GL2/GL3
headers directly, so I don't see any change here. The shader
composition functionality is really just a new way arranging shaders
in a more convenient way, the actual OSG code passing the uniforms,
shaders and programs to OpenGL shouldn't need be touched, save for a
few tweaks for flexibility and performance if needed. The new shader
composition support will naturally support GL1.1 + extensions.
> I can't argue with that, just wondering if the fixed function emulation via
> shaders is vital problem to solve at the moment.
The fixed function emulation It's vital for OSG-3.0, but for the first
steps of shader composition is not required. My current plan is:
1) Come up with a preliminary design approach that looks like it'll support
fixed function emulation and custom shader composition in a way
that minimizes
API changes and maximizes the ease at which different implementations can
be maxed.
2) Come up with a concrete but modest design (a subset of 1) for doing shader
composition using user design shaders, uniforms and rules for
injecting code
into the vertex, geometry and mains.
3) Implement 2, test and debug it, and once the basics work start test more
complex arrangements of shader composition such that these complex
arrangements start approach what we'll need to do with fixed funciton
emulation.
4) This stage we'd be going back to the preliminary design of 1) but using
the knowledge gained in stages 2 & 3 to shape it into something that is
practical. Start implementing fixed function emulation bit by
bit, refactoring
the design as we go to make sure that new and old functionality all mesh.
5) On mass get the community to start implementing the fixed function emulation
for all the remain StateAttribute in the core OSG so we can load
all our models
and visualize them correctly whether using old fixed function code paths or
the new shader composition.
6) Modify the shader codes in osgVolume, osgParticle, osgShader and osgFX
so that they all use shader composition rather than osg::Program.
7) Test, debug, optimize
8) Make 3.0 release.
--
Right now I'm at stage 1, and this week plan to dive into stage 2 and
perhaps even stage 3.
Robert.
_______________________________________________
osg-users mailing list
[email protected]
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
