Re: [osg-users] Shader composition with multiple function injection

[Robert Osfield]

Hi Hartwig,



On 12 May 2018 at 22:59, Hartwig Wiesmann  wrote:
> In the example code one directional light computation can be injected. What 
> is the best solution if I like to inject 0 to N directional lights where N is 
> runtime dependent?
>
> I could do something like:
>
> Code:
>
> #ifdef LIGHTING0
> directionalLight( 0, gl_Normal.xyz, basecolor);
> #endif
> #ifdef LIGHTING1
> directionalLight( 1, gl_Normal.xyz, basecolor);
> #endif
> #ifdef LIGHTING2
> directionalLight( 2, gl_Normal.xyz, basecolor);
> #endif
> ...
>
> but this is not very elegant. Though I do not see any other possibility. Am I 
> missing a better solution?

You could use the above approach, this kinda what the fixed function
pipeline does with needing to enable/disable GL_LIGHT0, GL_LIGHT1,
GL_LIGHT2 etc.

Another approach is pass in the number of active lights and have a for
loop iterator through the calls to directionalLight(i, gl_Normals,
basecolor);  The number of lights could be a uniform or supplied by
#pragma(tic) shader composition.

Robert.
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org

[osg-users] Shader composition with multiple function injection

[Hartwig Wiesmann]

Hi,

I had a look at the shader composition example. The main shader looks like this:

Code:

#pragma import_defines ( LIGHTING, TEXTURE_2D, VERTEX_FUNC(v) )

#ifdef LIGHTING
// forward declare lighting computation, provided by lighting.vert shader
void directionalLight( int lightNum, vec3 normal, inout vec4 color );
#endif

#ifdef TEXTURE_2D
varying vec2 texcoord;
#endif

#ifdef VERTEX_FUNC
uniform float osg_SimulationTime;
#endif

varying vec4 basecolor;

void main(void)
{
basecolor = gl_Color;

#ifdef LIGHTING
directionalLight( 0, gl_Normal.xyz, basecolor);
#endif

#ifdef TEXTURE_2D
// if we want texturing we need to pass on texture coords
texcoord = gl_MultiTexCoord0.xy;
#endif

#ifdef VERTEX_FUNC
gl_Position   = gl_ModelViewProjectionMatrix * VERTEX_FUNC(gl_Vertex);
#else
gl_Position   = gl_ModelViewProjectionMatrix * gl_Vertex;
#endif

}




In the example code one directional light computation can be injected. What is 
the best solution if I like to inject 0 to N directional lights where N is 
runtime dependent?

I could do something like:

Code:

#ifdef LIGHTING0
directionalLight( 0, gl_Normal.xyz, basecolor);
#endif
#ifdef LIGHTING1
directionalLight( 1, gl_Normal.xyz, basecolor);
#endif
#ifdef LIGHTING2
directionalLight( 2, gl_Normal.xyz, basecolor);
#endif
...




but this is not very elegant. Though I do not see any other possibility. Am I 
missing a better solution?

Thank you!

Cheers,
Hartwig

--
Read this topic online here:
http://forum.openscenegraph.org/viewtopic.php?p=73625#73625





___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org

Re: [osg-users] shader composition

[Robert Osfield]

Hi Nick,

On 28 January 2015 at 23:23, Trajce Nikolov NICK 
trajce.nikolov.n...@gmail.com wrote:


 I read the shader composition code and the used classes - which are really
 without any documentation :-). Can someone give a fast intro into this, the
 sample for example?


ShaderComposition in the core OSG is still experimental, the
osgshadercomposition example is main place to learn about what is supported
so far.

However, I'm currently working on tackling the problem of shader management
from a different direction, if successful it will avoid the need for the
previous ShaderoComposition functionality for a range of usage models.

I'll discuss this new approach in a separate thread.

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

[Robert Milharcic]

On 29.1.2015 0:23, Trajce Nikolov NICK wrote:

I read the shader composition code and the used classes - which are really
without any documentation:-). Can someone give a fast intro into this, the
sample for example?

Thanks a bunch as always


Hi Nick,

I once did some experimental coding on shader composition. The idea was 
to emulte all the FFP attributes with shaders and possibly extend the 
composition with custom shaders. Although the code is working and it 
produces optimal shaders with zero branching or defines, I have never 
had time to polish it up and send it for a review. I could post the 
sample I used for testing, if you are interested. The bad news is that 
it requires some osg core modifications to work properly. I can send 
those, too.


Robert Milharcic

___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org

Re: [osg-users] shader composition

[Trajce Nikolov NICK]

Thanks Robert, Robert,

I will wait for the new code then.

Nick

On Thu, Jan 29, 2015 at 11:54 AM, Robert Milharcic 
robert.milhar...@ib-caddy.si wrote:

 On 29.1.2015 0:23, Trajce Nikolov NICK wrote:

 I read the shader composition code and the used classes - which are really
 without any documentation:-). Can someone give a fast intro into this, the
 sample for example?

 Thanks a bunch as always


 Hi Nick,

 I once did some experimental coding on shader composition. The idea was to
 emulte all the FFP attributes with shaders and possibly extend the
 composition with custom shaders. Although the code is working and it
 produces optimal shaders with zero branching or defines, I have never had
 time to polish it up and send it for a review. I could post the sample I
 used for testing, if you are interested. The bad news is that it requires
 some osg core modifications to work properly. I can send those, too.

 Robert Milharcic

 ___
 osg-users mailing list
 osg-users@lists.openscenegraph.org
 http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org




-- 
trajce nikolov nick
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org

[osg-users] shader composition

[Trajce Nikolov NICK]

Hi Community,

I read the shader composition code and the used classes - which are really
without any documentation :-). Can someone give a fast intro into this, the
sample for example?

Thanks a bunch as always

Nick

-- 
trajce nikolov nick
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org

Re: [osg-users] Shader Composition

[Robert Osfield]

Hi Bo,

ShaderComposer isn't complete, and should be viewed as experimental,
but it's able to do a few composition tasks.  The osgshadercomposition
example is a test bed for this feature, unfortunately I've been
swamped with other work so haven't been able to complete the work on
ShaderComposition functionality.

Robert.

On Tue, Sep 13, 2011 at 8:47 PM, Bo Jiang jb4...@gmail.com wrote:
 Hi All,

 I have a node, and I want to shade it using different effect, i.e. I have 
 several groups of shaders (vertex+geometry+fragment), and each group 
 implements one effect.

 Now I want to combine all the effects together when display the node. I do 
 not know how to achieve it. I searched the forum and it seems that the 
 osg::ShaderComposer class is not finished yet? Or shall I need to use the 
 two-passes effect like class in osgFX?

 Thank you!

 Cheers,
 Bo

 --
 Read this topic online here:
 http://forum.openscenegraph.org/viewtopic.php?p=42723#42723





 ___
 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] Shader Composition

[Bo Jiang]

Hi All,

I have a node, and I want to shade it using different effect, i.e. I have 
several groups of shaders (vertex+geometry+fragment), and each group implements 
one effect.

Now I want to combine all the effects together when display the node. I do not 
know how to achieve it. I searched the forum and it seems that the 
osg::ShaderComposer class is not finished yet? Or shall I need to use the 
two-passes effect like class in osgFX?

Thank you!

Cheers,
Bo

--
Read this topic online here:
http://forum.openscenegraph.org/viewtopic.php?p=42723#42723





___
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

[Robert Osfield]

Hi All,

I've started doing a preliminary implementation the  of the design I
discussed in previous emails.  I've introduced ShaderComponent and now
StateAttribute has a optional ShaderComponent.  I've also fleshed
out a bit more of ShaderComposer with some very simple wiring in
osg::State to invoke this.  I've also checked in the beginnings of a
osgshadercomposition example which will be the initial test bed for
the functionality as it develops.

Whilst fleshing out the ShaderComposer API I created the ShaderMain
and ShaderAssembly classes that I previously proposed but quickly
found that I was creating container class that weren't really needed -
a simple std::map was more than enough to the do the job they were
meant to fulfill.  At least that's my current impression from creating
the required Program and main Shader caches in ShaderComposer.  With
putting together the ShaderComposer and implementing the required
caches I was able to distill down the shader composition step to just
one method:

typedef std::vector const osg::Shader*   Shaders;
virtual osg::Shader* composeMain(const Shaders shaders);

This single method will take a list of Shaders of the same
Shader::Type (VERTEX, GEOMETRY or FRAGMENT) that have been sourced
from the active ShaderComponents, and then create a main shader by
assembling all the code injection details held on each of the shaders.
 It could be that one of the Shaders themselves is a main in which
case the composeMain() should just return a null as there isn't any
need to create a main for it.

I haven't started adding the required code injection API into
osg::Shader yet, or implemented the full ShaderComponent and mode
tracking that will be needed in osg::State so I'm still a couple of
working days away from having basic shader composition working.
However, progress is encouraging, the implementation of the required
classes/methods is hanging together quite naturally so far.

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

[Robert Osfield]

Hi All,

I've been thinking about the various classes and relationships that
we'll need to support both the front end API for shader composition,
and the backend implementation of it, and my current thoughts are:

1) The ShaderSet I've been discussing over my last few post should be renamed,
my current preferred name is ShaderComponent.

2) Rather than ShaderComponent (was ShaderSet) have the details of how to
inject code into the shader main for each of the vertex, geometry
and fragment
mains, I now feel it would be more managable to move injection support into
   osg::Shader.

   This would mean that ShaderComponent would then just have a list of
one or more
   osg::Shader.  These Shaders would then be grouped into ones that affect the
   vertex, geometry and fragment programs.

   The osg::Shader class would have some new API for setting up the inject code,
   this could be empty/inactive in a default constructed osg::Shader,
so wouldn't
   affect how we use osg::Shader/osg::Program right now.  It's only when shader
   composition comes into play will these extra fields be queried.

3) StateAttribute would have a ShaderComponent that implements the
   shader functionality, this ShaderComponent would typically be shared between
   the same type of StateAttribute.  The StateAttribute attribute
would also provide
   osg::Uniform that pass in the values to the associated ShaderComponent, these
   osg::Unfirom will be applied by the existing
StateAttribute::apply(..) method.

   This is approach I've been discussing before (save for the ShaderSet rename.)

4) osg::State will maintain a current list of enabled ShaderComponent's, this
list of pointers will form a key to search for the appropriate osg::Program
to apply to achieve that functionality.  The way that the osg::Program will
be wrapped up and cached is within a ShaderAssembly.   osg::State
would internally manage the creation of ShaderAssembly, and cache of these
and apply the osg::Program they contain.

Lazy state updating in osg::State will seek to minimize the times that
the state is changed between ShaderAssembly.  When the set/list of enabled
ShaderComponent's changes a the appropriate ShaderAssumbly for this set
of ShaderComponent is then lookup in the ShaderAssembly cache.  If
non apporpriate ShaderAssembly is found then the ShaderComposer is
invoked to create a new ShaderAssembly which is then cached and made
current.

 5) A ShaderAssembly is an internal implementation class so not something
 a user would normally worry about, only the ShaderComposer or
 subclasses from it would need to know about it.

 A ShaderAssembly has the final osg::Program that is applied to OpenGL,
 this osg::Program is composed on the osg::Shader's provided by the
 osg::ShaderComponent, and also an automatically created osg::Shader
 main for each of the vertex, geometry and fragment parts osg::Program.

 The automatically generated shader mains are wrapped up in a ShaderMain
 class that has a list of osg::Shader that contribute to it, these
osg::Shader
 are pulled in from the ShaderComponent's that are associated with the
 ShaderAssembly.  The individual osg::Shader that assigned to a ShaderMain
 provide the code injection details that enable the ShaderComposer to create
 the final main() code that gets placed in the ShaderMain's automatically
 generated osg::Shader.

 The ShaderAssembly contains a ShaderMain for each of the vertex, geometry
 and fragment programs.  Pulling all the Shaders, both provided by the
 ShaderComponent and the automatically generated ones in the three
 ShaderMain to create the final osg::Program.

 It will be possible to share ShaderMain between multiple ShaderAssemly, and
 this will be desirable as often we will just enable/disable a
mode that affects
 only the vertex shaders parts, or just the fragment shader parts,
so if we are
 able to share then we only need create a new ShaderMain for the part that
 changes, the rest can be reused from a cache of ShaderMain (that will be
 provided by osg::ShaderComposer).

 Like ShaderAssembly the ShaderMain is an implementation detail that most
 end users need not use directly or worry about.  It's only osg::State and
 osg::ShaderComposer (or subclasses from it) that will directly
deal with them.

 6) ShaderComposer will manage a cache of ShaderAssembly, and access to
 this cache and the automatic creation of new ShaderAssembly when a
 new combination of enabled ShaderComponent is requested.  When a
 a new ShaderAssembly is created the ShaderComposer querries the
 ShaderComponent to work out what ShaderMain it needs to create, and where
 possible to pull these in from a cache of ShaderMain.

 osg::State has a ShaderComposer, and will defer most of the shader
 composition functionality to it.  Users will be able 

Re: [osg-users] Shader composition, OpenGL modes and custom modes

[Christiansen, Brad]

Hi,

Sounding great so far. A lot to digest! I have a couple of questions.

One thing I am not clear on is how the rules for injecting a Shader into a 
ShaderMain would work. This is an area I have had difficulty with in my own 
shader assembly approach. For example, how will it be possible to change the 
order in which shaders are applied? As a contrived example, I might want to use 
the material color of a fragment as the input to my lighting shader, and then 
blend my textures with the result. Alternatively, I might want to first blend 
all my textures, then use this color as the input to the lighting shader. How 
would I specify these kind of rules?

Another area I am not clear on is how (if at all) we will be able to avoid 
doing the same calculations many times for a single vertex or fragment. Say, 
for example, we need the ec position of a vertex as an input to several of our 
vertex Shaders. Would each shader have to recalculate this value independently? 
This shouldn't be a major hit to performance in most cases but it is obviously 
less efficient than just doing the calculation once. Then again, maybe the 
compiler can figure this out for us.

Cheers,

Brad

-Original Message-
From: osg-users-boun...@lists.openscenegraph.org 
[mailto:osg-users-boun...@lists.openscenegraph.org] On Behalf Of Robert Osfield
Sent: Thursday, 1 July 2010 4:30 PM
To: OpenSceneGraph Users
Subject: Re: [osg-users] Shader composition, OpenGL modes and custom modes

Hi All,

I've been thinking about the various classes and relationships that
we'll need to support both the front end API for shader composition,
and the backend implementation of it, and my current thoughts are:

1) The ShaderSet I've been discussing over my last few post should be renamed,
my current preferred name is ShaderComponent.

2) Rather than ShaderComponent (was ShaderSet) have the details of how to
inject code into the shader main for each of the vertex, geometry
and fragment
mains, I now feel it would be more managable to move injection support into
   osg::Shader.

   This would mean that ShaderComponent would then just have a list of
one or more
   osg::Shader.  These Shaders would then be grouped into ones that affect the
   vertex, geometry and fragment programs.

   The osg::Shader class would have some new API for setting up the inject code,
   this could be empty/inactive in a default constructed osg::Shader,
so wouldn't
   affect how we use osg::Shader/osg::Program right now.  It's only when shader
   composition comes into play will these extra fields be queried.

3) StateAttribute would have a ShaderComponent that implements the
   shader functionality, this ShaderComponent would typically be shared between
   the same type of StateAttribute.  The StateAttribute attribute
would also provide
   osg::Uniform that pass in the values to the associated ShaderComponent, these
   osg::Unfirom will be applied by the existing
StateAttribute::apply(..) method.

   This is approach I've been discussing before (save for the ShaderSet rename.)

4) osg::State will maintain a current list of enabled ShaderComponent's, this
list of pointers will form a key to search for the appropriate osg::Program
to apply to achieve that functionality.  The way that the osg::Program will
be wrapped up and cached is within a ShaderAssembly.   osg::State
would internally manage the creation of ShaderAssembly, and cache of these
and apply the osg::Program they contain.

Lazy state updating in osg::State will seek to minimize the times that
the state is changed between ShaderAssembly.  When the set/list of enabled
ShaderComponent's changes a the appropriate ShaderAssumbly for this set
of ShaderComponent is then lookup in the ShaderAssembly cache.  If
non apporpriate ShaderAssembly is found then the ShaderComposer is
invoked to create a new ShaderAssembly which is then cached and made
current.

 5) A ShaderAssembly is an internal implementation class so not something
 a user would normally worry about, only the ShaderComposer or
 subclasses from it would need to know about it.

 A ShaderAssembly has the final osg::Program that is applied to OpenGL,
 this osg::Program is composed on the osg::Shader's provided by the
 osg::ShaderComponent, and also an automatically created osg::Shader
 main for each of the vertex, geometry and fragment parts osg::Program.

 The automatically generated shader mains are wrapped up in a ShaderMain
 class that has a list of osg::Shader that contribute to it, these
osg::Shader
 are pulled in from the ShaderComponent's that are associated with the
 ShaderAssembly.  The individual osg::Shader that assigned to a ShaderMain
 provide the code injection details that enable the ShaderComposer to create
 the final main() code that gets placed in the ShaderMain's automatically
 generated osg::Shader.

 The ShaderAssembly contains

Re: [osg-users] Shader composition, OpenGL modes and custom modes

[Robert Osfield]

Hi Brad,

On Thu, Jul 1, 2010 at 11:18 AM, Christiansen, Brad
brad.christian...@thalesgroup.com.au wrote:
 One thing I am not clear on is how the rules for injecting a Shader into a 
 ShaderMain would work. This is an area I have had difficulty with in my own 
 shader assembly approach. For example, how will it be possible to change the 
 order in which shaders are applied? As a contrived example, I might want to 
 use the material color of a fragment as the input to my lighting shader, and 
 then blend my textures with the result. Alternatively, I might want to first 
 blend all my textures, then use this color as the input to the lighting 
 shader. How would I specify these kind of rules?


These are all very good questions, ones that I'm aware of items we'll
need to formalize and solve.  Just how I don't have an answer to yet.
The reason why I hadn't discussed these particular topics is that
without a clear direction on it yet I don't have too much to say.

Addressing these issue is something I decided to leave till later to
fully resolve.  I'm happy to do this as the high level mechanics,
class design, and implementation is something that we have to
addressed as well - but these I've been able to scope out and find a
design that I feel has promise so I'm more confident about tackling
implementation on them.  I'm also now quite comfortable that the high
level stuff is unlikely to change much with changes to the lower level
details on the shader main generation, so we needn't worry too much
about the rules right away - as long as we can get something basic
working w.r.t main generation they we'll be able to thrash out and
getting working all the high level details.

Once the high level stuff is in place and working we'll have the
framework in place to start testing various approaches to shader main
generation, and we'll also have learnt more about the problem domain
along the way, and also we can dump from our brains all the
complexities of the high level stuff.  I'm away for complexity
overload so being able to tackle this task in stages like this is
something I feel much more comfortable.

 Another area I am not clear on is how (if at all) we will be able to avoid 
 doing the same calculations many times for a single vertex or fragment. Say, 
 for example, we need the ec position of a vertex as an input to several of 
 our vertex Shaders. Would each shader have to recalculate this value 
 independently? This shouldn't be a major hit to performance in most cases but 
 it is obviously less efficient than just doing the calculation once. Then 
 again, maybe the compiler can figure this out for us.

It might be possible to have the shader generation parse the injected
code to look for variables set up that are repeated in other injected
code and use only the first instance.  Using the same variables and
code fragments for this would be required but should be possible with
a little discipline and awareness of other shaders.  Like the ordering
issue I'm happy to not worry about this for now.

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

[Robert Osfield]

Hi Roland,

On Tue, Jun 29, 2010 at 10:22 PM, Roland Smeenk roland.sme...@tno.nl wrote:
 1) Provide a way of encapsulating all the details required to
 contribute a single chunk of functionality that will be combined with other 
 active ShaderSet to provide final composed osg::Program.

 Isn't this what I solved with the ShaderMode class?

I believe ShaderMode and ShaderSet are pretty close in concept, the
fit a similar role and functionality granularity.  Implementation and
usage wise they differ, but they have lots of similarity, i.e. they
are both big cats, but ones a tiger and ones a lion.


 Or is it that you are trying to separate the shader mode associated with a 
 StateAttribute from the part that is responsible for adding of the piece of 
 shader functionality.

My currently thought is that the various StateAttribute subclasses
would provide a standard ShaderSet instance that implements their
functionality, but also make it possible to override this standard
ShaderSet with custom ones.  For instance we might have a standard
implementation of osg::Light, but we also want to enable users to have
their own implementation, by just providing their own
MyCustomPerPixelLightShaderSet.

There might also be cases where a osg::StateAttribute subclass might
dynamically decide which ShaderSet to use depending upon how it's
configured - this would be if we wanted to reduce the number of
uniforms by having more pre-configured shaders.

 In my contribution I implemented a single ShaderMode that implements all 
 fixed function lighting possibilities. For new types of lighting it seems 
 more logical to indeed make a more fine grained breakup of ShaderModes.

 However there's a (minor) advantage to this one size fits all lighting code 
 currently.  To enable or disable lighting you simply can override a single 
 mode. In the case where there are multiple lighting modes (directional, spot 
 etc.) overall disabling of lighting needs to be done per lighting type. It 
 might be needed that multiple ShaderSets implementing the same aspect/feature 
 can be switched on or off all together with a single override. This will also 
 be needed for instance in shadow map creation where in the first pass you 
 would like to render geometry into a shadowmap as cheaply as possible and 
 therefore without lighting.
 Perhaps multiple ShaderSets implement a the same aspect/feature in the final 
 program that need to be disabled or enabled collectively. Again in the case 
 of shadowmap creation you would like to only render geometry, no texturing, 
 no lighting, no fog, but you do want to take into account skinned mesh 
 deformation, wind deflection etc.

I don't yet have any concrete plan on how to manage the case where
multiple GL enums control particular features.  It might be that it'll
be best to map some of the controls to uniforms that enable one to
toggle features on/off such as lighting, but it might also be that we
it could be best to just pass the all modes on the StateAttribute when
asking for the appropriate ShaderSet to use and let it decide what to
use.

This type of issue I expect to fall out of experience with
implementing various fixed function functionality such as Lighting.


 3) The ShaderSet would contain list osg::Shader objects, these osg::Shader 
 objects would target which ever part of the overall program that the 
 ShaderSet effects - be in multiple osg::Shader for vertex programs, one of 
 vertex program one for fragment, or any combination.


 I guess you are more targeting shader linking instead of the code generation 
 that I implemented.

Yes, I believe preferring Shader linking over Shader code generation
will lead to better performance, more reusability and easier
management.

One of my plans will be to come up with a ShaderSet file format that
will be a subset of use the osgDB serializers to provide
.osgt/.osgb/.osg support.  This file format would contain the existing
serialization for osg::Shader objects, and add the small part of code
injection that we'll need.

I also want to be able to map this ShaderSet configuration to a C++
source file as well so we can prepare our ShaderSet just be editing a
configuration file and do quick runtime testing, then when we're happy
with the shaders setup we'd encode this ShaderSet into a .cpp which
then provides the default implementation for a particular
StateAttribute subclass.  I took this approach with the shaders in
osgVolume, being able to edit a file and then re-run the application
we really effective at cutting the time it took to perfect the
shaders.

 The individual osg::Shader objects could also be shared by multiple 
 ShaderSet where appropriate.

 It could, but is this likely to happen?

We'll find out once we start implementing the fixed function pipeline
mapping, but since sharing osg::Shader is already supported in
osg::Program providing this capability will effectively be free ;-)

 5) It might well be that some StateAttribute have unifoms but 

Re: [osg-users] Shader composition, OpenGL modes and custom modes

[Adrian Egli OpenSceneGraph (3D)]

Hi Robert, hi others,

I am currently working on image processing pipelines based on GLSL
shaders. Currently we have many different special effects (shaders)
but all of them work encapsulated. May we should also think on other
topic while overwork the shader composite idea. i review the
osgvirtualprogram example, and i am not sure, but believe - in this
example the whole idea is presented of the new shaders with
virtualprogram. what i am wondering is there also a concept how we can
use different shaders in a pipeline. for example (i am hard working on
Screen Space Ambient Occlusion) and it's all working based on osgFX.
But the pipeline needs different FBO (RTT steps) in a pipeline.
(1) Render the whole scene with depth/normal rendering (RTT 1)
(2) Process the RTT 1 with Ambient Occlusion Filter
(3) Render Shadow into RTT 2 (for example Parallel Split Shadow Map
with 4 Maps == 4 Renderings)
(4) 
(x) Bring all together and so on

In some case we have the same scene (object 2 render) then we can use
virtual program, right? but how can we get the pipeline controled, it
would be nice getting a rendering pipeline functionality in the shader
- render into gpu memory and store it (array) and bring it in last
shader back and blend it. We will have final rendering. Would this be
possible or is this to complex to get osg support in controling it?

/adrian


2010/6/30 Robert Osfield robert.osfi...@gmail.com:
 Hi Roland,

 On Tue, Jun 29, 2010 at 10:22 PM, Roland Smeenk roland.sme...@tno.nl wrote:
 1) Provide a way of encapsulating all the details required to
 contribute a single chunk of functionality that will be combined with other 
 active ShaderSet to provide final composed osg::Program.

 Isn't this what I solved with the ShaderMode class?

 I believe ShaderMode and ShaderSet are pretty close in concept, the
 fit a similar role and functionality granularity.  Implementation and
 usage wise they differ, but they have lots of similarity, i.e. they
 are both big cats, but ones a tiger and ones a lion.


 Or is it that you are trying to separate the shader mode associated with a 
 StateAttribute from the part that is responsible for adding of the piece of 
 shader functionality.

 My currently thought is that the various StateAttribute subclasses
 would provide a standard ShaderSet instance that implements their
 functionality, but also make it possible to override this standard
 ShaderSet with custom ones.  For instance we might have a standard
 implementation of osg::Light, but we also want to enable users to have
 their own implementation, by just providing their own
 MyCustomPerPixelLightShaderSet.

 There might also be cases where a osg::StateAttribute subclass might
 dynamically decide which ShaderSet to use depending upon how it's
 configured - this would be if we wanted to reduce the number of
 uniforms by having more pre-configured shaders.

 In my contribution I implemented a single ShaderMode that implements all 
 fixed function lighting possibilities. For new types of lighting it seems 
 more logical to indeed make a more fine grained breakup of ShaderModes.

 However there's a (minor) advantage to this one size fits all lighting 
 code currently.  To enable or disable lighting you simply can override a 
 single mode. In the case where there are multiple lighting modes 
 (directional, spot etc.) overall disabling of lighting needs to be done per 
 lighting type. It might be needed that multiple ShaderSets implementing the 
 same aspect/feature can be switched on or off all together with a single 
 override. This will also be needed for instance in shadow map creation where 
 in the first pass you would like to render geometry into a shadowmap as 
 cheaply as possible and therefore without lighting.
 Perhaps multiple ShaderSets implement a the same aspect/feature in the final 
 program that need to be disabled or enabled collectively. Again in the case 
 of shadowmap creation you would like to only render geometry, no texturing, 
 no lighting, no fog, but you do want to take into account skinned mesh 
 deformation, wind deflection etc.

 I don't yet have any concrete plan on how to manage the case where
 multiple GL enums control particular features.  It might be that it'll
 be best to map some of the controls to uniforms that enable one to
 toggle features on/off such as lighting, but it might also be that we
 it could be best to just pass the all modes on the StateAttribute when
 asking for the appropriate ShaderSet to use and let it decide what to
 use.

 This type of issue I expect to fall out of experience with
 implementing various fixed function functionality such as Lighting.


 3) The ShaderSet would contain list osg::Shader objects, these osg::Shader 
 objects would target which ever part of the overall program that the 
 ShaderSet effects - be in multiple osg::Shader for vertex programs, one of 
 vertex program one for fragment, or any combination.


 I guess you are more targeting shader 

Re: [osg-users] Shader composition, OpenGL modes and custom modes

[Robert Osfield]

Hi Adrian,

I don't think we need worry about high level algorithms with shader
composition, they should all just work fine.  My expectation is that
only the fine grained management of state needs to tackled with shader
composition, the coarsed grained RenderBin/RenderStage multi-pass
techniques will not be affected.

Shader composition should offer new opportunities for the high level
techniques though, as now you'll be able to break up the shaders and
managed them more flexibly rather than just being wrapped up into a
single osg::Program as we have right now.  How multi-pass techniques
will be able to take advantage of shader composition will be tested
once we look at porting osgShadow, osgVolume, osgFX and osgParticle
across from osg::Program to shader composition.

Right now I think it's best to just focus on the API and the low level
implementation details of shader composition, once this is in place
and working we can open out the testing and debate further.

Robert.

On Wed, Jun 30, 2010 at 7:57 PM, Adrian Egli OpenSceneGraph (3D)
3dh...@gmail.com wrote:
 Hi Robert, hi others,

 I am currently working on image processing pipelines based on GLSL
 shaders. Currently we have many different special effects (shaders)
 but all of them work encapsulated. May we should also think on other
 topic while overwork the shader composite idea. i review the
 osgvirtualprogram example, and i am not sure, but believe - in this
 example the whole idea is presented of the new shaders with
 virtualprogram. what i am wondering is there also a concept how we can
 use different shaders in a pipeline. for example (i am hard working on
 Screen Space Ambient Occlusion) and it's all working based on osgFX.
 But the pipeline needs different FBO (RTT steps) in a pipeline.
 (1) Render the whole scene with depth/normal rendering (RTT 1)
 (2) Process the RTT 1 with Ambient Occlusion Filter
 (3) Render Shadow into RTT 2 (for example Parallel Split Shadow Map
 with 4 Maps == 4 Renderings)
 (4) 
 (x) Bring all together and so on

 In some case we have the same scene (object 2 render) then we can use
 virtual program, right? but how can we get the pipeline controled, it
 would be nice getting a rendering pipeline functionality in the shader
 - render into gpu memory and store it (array) and bring it in last
 shader back and blend it. We will have final rendering. Would this be
 possible or is this to complex to get osg support in controling it?

 /adrian


 2010/6/30 Robert Osfield robert.osfi...@gmail.com:
 Hi Roland,

 On Tue, Jun 29, 2010 at 10:22 PM, Roland Smeenk roland.sme...@tno.nl wrote:
 1) Provide a way of encapsulating all the details required to
 contribute a single chunk of functionality that will be combined with 
 other active ShaderSet to provide final composed osg::Program.

 Isn't this what I solved with the ShaderMode class?

 I believe ShaderMode and ShaderSet are pretty close in concept, the
 fit a similar role and functionality granularity.  Implementation and
 usage wise they differ, but they have lots of similarity, i.e. they
 are both big cats, but ones a tiger and ones a lion.


 Or is it that you are trying to separate the shader mode associated with a 
 StateAttribute from the part that is responsible for adding of the piece of 
 shader functionality.

 My currently thought is that the various StateAttribute subclasses
 would provide a standard ShaderSet instance that implements their
 functionality, but also make it possible to override this standard
 ShaderSet with custom ones.  For instance we might have a standard
 implementation of osg::Light, but we also want to enable users to have
 their own implementation, by just providing their own
 MyCustomPerPixelLightShaderSet.

 There might also be cases where a osg::StateAttribute subclass might
 dynamically decide which ShaderSet to use depending upon how it's
 configured - this would be if we wanted to reduce the number of
 uniforms by having more pre-configured shaders.

 In my contribution I implemented a single ShaderMode that implements all 
 fixed function lighting possibilities. For new types of lighting it seems 
 more logical to indeed make a more fine grained breakup of ShaderModes.

 However there's a (minor) advantage to this one size fits all lighting 
 code currently.  To enable or disable lighting you simply can override a 
 single mode. In the case where there are multiple lighting modes 
 (directional, spot etc.) overall disabling of lighting needs to be done per 
 lighting type. It might be needed that multiple ShaderSets implementing the 
 same aspect/feature can be switched on or off all together with a single 
 override. This will also be needed for instance in shadow map creation 
 where in the first pass you would like to render geometry into a shadowmap 
 as cheaply as possible and therefore without lighting.
 Perhaps multiple ShaderSets implement a the same aspect/feature in the 
 final program that need to be disabled or 

Re: [osg-users] Shader composition, OpenGL modes and custom modes

[Christiansen, Brad]

Hi,

I would just like to comment on this:

 Ooo I hadn't thought about providing a mechanism for computing vertex 
 positions on the CPU, but this would be very very useful for the quandary of 
 using shaders to modify the vertex positions dynamically.
 The mechanism would need to know the uniform state and the ShaderSet that 
 are relevant, so the StateAttribute might be the place to couple this.  Or 
 perhaps the ??IntersectionVisitor etc. could accumulate StateSet's and pick 
 out the StateAttribute that effect the vertex position.

I have recently run into this issue when doing billboarding within a vertex 
shader. To still allow picking I have had to write a custom routine that 
operates on only this section of my scene and mask it out of the general 
picking mechanism. This is quite a painful and time consuming process. I 
believe this issue will become very common as more work is moved into vertex 
and geometry shaders. As such I would be very keen to see this sort of 
functionality incorporated into the core. There is also some danger in doing so 
though, as this could make picking operations much more expensive. After all, I 
moved the billboard calculation from the CPU to the GPU for a reason :  )

Cheers,

Brad

-Original Message-
From: osg-users-boun...@lists.openscenegraph.org 
[mailto:osg-users-boun...@lists.openscenegraph.org] On Behalf Of Robert Osfield
Sent: Wednesday, 30 June 2010 5:05 PM
To: osg-users@lists.openscenegraph.org
Subject: Re: [osg-users] Shader composition, OpenGL modes and custom modes

Hi Roland,

On Tue, Jun 29, 2010 at 10:22 PM, Roland Smeenk roland.sme...@tno.nl wrote:
 1) Provide a way of encapsulating all the details required to
 contribute a single chunk of functionality that will be combined with other 
 active ShaderSet to provide final composed osg::Program.

 Isn't this what I solved with the ShaderMode class?

I believe ShaderMode and ShaderSet are pretty close in concept, the
fit a similar role and functionality granularity.  Implementation and
usage wise they differ, but they have lots of similarity, i.e. they
are both big cats, but ones a tiger and ones a lion.


 Or is it that you are trying to separate the shader mode associated with a 
 StateAttribute from the part that is responsible for adding of the piece of 
 shader functionality.

My currently thought is that the various StateAttribute subclasses
would provide a standard ShaderSet instance that implements their
functionality, but also make it possible to override this standard
ShaderSet with custom ones.  For instance we might have a standard
implementation of osg::Light, but we also want to enable users to have
their own implementation, by just providing their own
MyCustomPerPixelLightShaderSet.

There might also be cases where a osg::StateAttribute subclass might
dynamically decide which ShaderSet to use depending upon how it's
configured - this would be if we wanted to reduce the number of
uniforms by having more pre-configured shaders.

 In my contribution I implemented a single ShaderMode that implements all 
 fixed function lighting possibilities. For new types of lighting it seems 
 more logical to indeed make a more fine grained breakup of ShaderModes.

 However there's a (minor) advantage to this one size fits all lighting code 
 currently.  To enable or disable lighting you simply can override a single 
 mode. In the case where there are multiple lighting modes (directional, spot 
 etc.) overall disabling of lighting needs to be done per lighting type. It 
 might be needed that multiple ShaderSets implementing the same aspect/feature 
 can be switched on or off all together with a single override. This will also 
 be needed for instance in shadow map creation where in the first pass you 
 would like to render geometry into a shadowmap as cheaply as possible and 
 therefore without lighting.
 Perhaps multiple ShaderSets implement a the same aspect/feature in the final 
 program that need to be disabled or enabled collectively. Again in the case 
 of shadowmap creation you would like to only render geometry, no texturing, 
 no lighting, no fog, but you do want to take into account skinned mesh 
 deformation, wind deflection etc.

I don't yet have any concrete plan on how to manage the case where
multiple GL enums control particular features.  It might be that it'll
be best to map some of the controls to uniforms that enable one to
toggle features on/off such as lighting, but it might also be that we
it could be best to just pass the all modes on the StateAttribute when
asking for the appropriate ShaderSet to use and let it decide what to
use.

This type of issue I expect to fall out of experience with
implementing various fixed function functionality such as Lighting.


 3) The ShaderSet would contain list osg::Shader objects, these osg::Shader 
 objects would target which ever part of the overall program that the 
 ShaderSet effects - be in multiple osg::Shader for vertex programs

Re: [osg-users] Shader composition, OpenGL modes and custom modes

[Mathias Fröhlich]

Hi Robert,

On Monday 28 June 2010, Robert Osfield wrote:
 Yes, even if we tweak the API a bit in StateSet any new elements will
 sorted virtue of being in StateSet.  Whatever we do StateSet's will
 remain the container for all things state in the scene graph, and the
 what basis of coarsed grained state sorting and lazy state updating
 that the OSG provides by default.
Ok.

  So in effect you will know the final shader combination for a render leaf
  at cull time.
  Right?

 Yes, once you've traversed down the graph to the osg::Drawable leaves
 you know all the state inheritance and can compute the final program
 and uniform combination that will be required.
Ok.

  Wouldn't it be better to match the final shaders programs at cull time
  instead of draw time?

 The only reason there might be an advantage is that if you draw
 traversal was more CPU limited than the draw.  In general I would
 expect the cost of selecting the appropriate programs during draw will
 be very low relative to the cost of dispatching the data itself.
Yes.

 The only part that might be expensive is the composition of the shader
 mains and then compiling these main shaders, but again the cost of
 composing the main shaders is likely to be much lower than the OpenGL
 side of compiling them, and you have to do the compiling in the draw
 traversal any so the saving again is likely to be be pretty small if
 detectable.
True, compiling is expensive.
But that is exactly what should be better done just once when a new shader 
combination appears. The final program should just be stored and reused once 
it is compiled *and* linked.

I am sure that compiling a shader is expensive. But I am also sure that 
linking is *not* about for free.
I expect that drivers will again do some optimizations once linking happens. 
For example there are GPU's out there which do not have jump instructions. In 
this case, linking must at least do inlining again.
Also there are plenty of optimization opportunities that start to be available 
when the whole program is known. So, I expect that at link time the shader 
optimizer is started again and again improoves the shader code.

So, what I think is that we need minimize shader compilation as well as shader 
*linking* as much as possible. If the implementation you have in mind really 
does this, then fine.
If you intent to relink on about every StateAttribute::compose(osg::State) 
call, I expect to run into problems.

 Doing more work in the cull will mean we'll have to pass more data to
 draw which itself may result in a performance overhead as the extra
 data structures will need to be dynamically allocated/destroyed.
Sure, malloc is to be avoided for real time.
Anyway, I am thinking more about something that computes a probably scalar key 
or pointer to an already existing object that is able to identify the final 
shader program combination in the cull stage and sets that key into the 
render leaf.
On apply this key is taken to apply the opengl shader object containing the 
already finished shader program. May be this key could be the to be cached 
final shader program.
So, no per draw dynamic memory management with this kind of approach.

 Right I want to get things working, the API and the backend are going
 to be new and complex enough that I want to take the route of least
 resistance and not worry to much about small possible optimization.
 Moving more work into cull might be an optimization that would be
 worth doing, but then it could just as easily be worse for
 performance.
Ok.

The only thing that might then turn out problematic is that then there is the 
StateAttribute::compose(State) call which directly operates on the State 
object. Once this is in place, backward compatibility will never make that go 
away. In effect this will make a switch to a 
StateAttribute::compose(CullTimeShaderComposer) call impossible...
That is the reason I am thinking about that current proposal for such a long 
time. May be the State should provide such a 'ShaderCompositon' object as a 
member and you let the state attribute work on this member of the State?
Then this could be moved easier if this turns out to be critical?

So, again the critical thing from my point of view:
If you can make sure that we never relink during draw once no new shader 
combination appears, I believe we are fine.

Greetings

Mathias

-- 
Dr. Mathias Fröhlich, science + computing ag, Software Solutions
Hagellocher Weg 71-75, D-72070 Tuebingen, Germany
Phone: +49 7071 9457-268, Fax: +49 7071 9457-511
-- 
Vorstand/Board of Management:
Dr. Bernd Finkbeiner, Dr. Roland Niemeier, 
Dr. Arno Steitz, Dr. Ingrid Zech
Vorsitzender des Aufsichtsrats/
Chairman of the Supervisory Board:
Michel Lepert
Sitz/Registered Office: Tuebingen
Registergericht/Registration Court: Stuttgart
Registernummer/Commercial Register No.: HRB 382196 


___
osg-users mailing list
osg-users@lists.openscenegraph.org

Re: [osg-users] Shader composition, OpenGL modes and custom modes

[Robert Osfield]

Hi Mathias,

2010/6/29 Mathias Fröhlich m.froehl...@science-computing.de:
 So, what I think is that we need minimize shader compilation as well as shader
 *linking* as much as possible. If the implementation you have in mind really
 does this, then fine.  If you intent to relink on about every
 StateAttribute::compose(osg::State) call, I expect to run into problems.

I think you've mis-understood my intentions.  My plan has been to
cache the osg::Program and main shaders once they are generated,
Roland's implementation also takes the route.  Calls to
StateAttribute::compose(osg::State) or it equivalent would only been
done when a new shader combination is required.


 The only thing that might then turn out problematic is that then there is the
 StateAttribute::compose(State) call which directly operates on the State
 object. Once this is in place, backward compatibility will never make that go
 away. In effect this will make a switch to a
 StateAttribute::compose(CullTimeShaderComposer) call impossible...

I don't think a CullTimeShaderComposer is a good idea, but a subclass
from ShaderComposer is fine, so I don't think there is a tightly
coupling issue at all.  We just need to get the design right so we can
alter subclass from ShaderComposer as well as write our own sets of
shaders.

 That is the reason I am thinking about that current proposal for such a long
 time. May be the State should provide such a 'ShaderCompositon' object as a
 member and you let the state attribute work on this member of the State?

As for the end of last week osg::State already has a ShaderComposer*
get/setShaderComposer method :-)

ShaderComposer is just a placeholder right now.

 Then this could be moved easier if this turns out to be critical?

I think we'll need to be pretty easy going with what the final design
is until we've played with actually implementing the code.  Is pretty
rare for a design to work perfectly once you start trying to solve
real problems with it.  For me the real test will be how well we can
implement the fixed function pipeline within shader composition - if
this works neatly and conveniently then we'll be well on track.

 So, again the critical thing from my point of view:
 If you can make sure that we never relink during draw once no new shader
 combination appears, I believe we are fine.

I believe we'll all be in agreement here.  This is certainly what I'm
aiming for, all the designs I'm working on use a program cache as a
fundamental part of the design, with state changes minimized.  I don't
see it all as much different to what we do know with creating texture
objects, VBO's, display lists, it's just we'll be operating on a
slightly higher level, it should all be the same principle - the OSG
worries about doing things efficiently, and the scene graph developer
just concentrates on composing the scene graph and state classes to
get the result they want.

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

[Robert Osfield]

I've not at the computer full time for the last couple of days so
haven't been able to push the shader composition implementation on
yet.  Design wise I've been doing bits here and there.  My latest
thought is that we probably need to encapsulate the component that
will go to make up shader composition as a single class/object.  This
class would contain a list of required shaders, the list of shader
modes, and the shader main code injection rules.  What to call this
class is a problem... perhaps ShaderSet?  ShaderComponent?
ShaderChunk?  Thoughts?

For my own design doodling I've run with the name ShaderSet for this
class, so will follow this in rest of the email, if we go for
something different later then so be it.  The role of the ShaderSet
would be:

  1) Provide a way of encapsulating all the details required to
contribute a single chunk
 of functionality that will be combined with other active
ShaderSet to provide final
 composed osg::Program.

  2) Provide a convenient mapping of a single ShaderSet representing a single
  implementation that can be shared by multiple osg::StateAttribute objects,
  for instance all osg::Light objects would shader a single
ShaderSet for all
  directional lights, another ShaderSet for all positional lights
etc.  If different
  state attribute objects shader the same ShaderSet then there it
will be easily
  to test whether shaders are the same simply be testing the pointer value,
  we needn't look into the contents.

  This approach works well for the OSG right now with how we manage
  osg::StateSet or the StateAttribute within them, so I'm pretty
comfortable that
  this approach will be useful when doing shader composition and keeping the
  costs of lazy state updating down.

  3) The ShaderSet would contain list osg::Shader objects, these osg::Shader
  objects would target which ever part of the overall program that
the ShaderSet
  effects - be in multiple osg::Shader for vertex programs, one of
vertex program
  one for fragment, or any combination.  The individual
osg::Shader objects could
  also be shared by multiple ShaderSet where appropriate.

   4) The StateAttribute would have a ShaderSet which defines all the shader
  setup required, this ShaderSet would typically be shared by all
instances of
  that type of StateAttribute.   The StateAttribute also have
zero more uniforms
  that pass in values to the shaders in the ShaderSet, these
uniforms wouldn't
  typically be shared, but would be solely owned by each separate
StateAttribute
  object.

  The StateAttribute's ShaderSet would only ever be queried if the
shader modes
   associated with that ShaderSet and hence StateAttribute are enabled, and
   no cached osg::Program for the current configuration of enabled
shader modes
   is available.

   5) It might well be that some StateAttribute have unifoms but no
ShaderSet, it
   might also be appropriate for some StateAttribute to have no uniforms and
   a ShaderSet.  It might even be appropriate for a single
StateAttribute to have
   multiple ShaderSet depending upon what mode it is in - for
instance osg::Light
   might be implemented in such a way that you have one ShaderSet for a
   directional light, and one ShaderSet for position light,
another for spot lights,
   another for per pixel lighting etc, and select the appropriate
one depending
   upon the set up of the osg::Light.

   6) Given osg::StateSet already has support for managing osg::Uniform directly
   perhaps we might even want to make it possible to assign
ShaderSet directly
   along side them rather than nesting them within StateAttribute.  A pure
   shader composition approach could do this, but for seamless
support of existing
   fixed function StateAttribute based scene graph we won't be
able to just this.
   However, have two ways of doing the same thing might just lead
to confusion...
   so it's something I think we just need to implement and test to
see how we get
   on.

Anyway these are my latests thoughts.  I will be out for much of
today, but later in the week should get more time to start
implementing some code to start experimenting with basic shader
composition.

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

[Mathias Fröhlich]

Hi Robert,

On Tuesday 29 June 2010, Robert Osfield wrote:
 I believe we'll all be in agreement here.  This is certainly what I'm
 aiming for, all the designs I'm working on use a program cache as a
 fundamental part of the design, with state changes minimized.  I don't
 see it all as much different to what we do know with creating texture
 objects, VBO's, display lists, it's just we'll be operating on a
 slightly higher level, it should all be the same principle - the OSG
 worries about doing things efficiently, and the scene graph developer
 just concentrates on composing the scene graph and state classes to
 get the result they want.
Fine then.

Greetings

Mathias

-- 
Dr. Mathias Fröhlich, science + computing ag, Software Solutions
Hagellocher Weg 71-75, D-72070 Tuebingen, Germany
Phone: +49 7071 9457-268, Fax: +49 7071 9457-511
-- 
Vorstand/Board of Management:
Dr. Bernd Finkbeiner, Dr. Roland Niemeier, 
Dr. Arno Steitz, Dr. Ingrid Zech
Vorsitzender des Aufsichtsrats/
Chairman of the Supervisory Board:
Michel Lepert
Sitz/Registered Office: Tuebingen
Registergericht/Registration Court: Stuttgart
Registernummer/Commercial Register No.: HRB 382196 


___
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

[Bruce Wheaton]

 
Very excited about the new features Robert, sounds like you're really cracking 
on.

I had two thoughts I hope you'll consider integrating:

One is that GLSL is quite poor for initialization. The main problem with this 
is if you were to enable a shader with, say, 8 uniforms, there wasn't, until 
very recently, a way to initialize them, and the stateset enable calls 
generally are single parameter. So in with the definitions of a new possible 
shader mode, and the attributes/uniforms it needs, we will probably need a way 
to initialize any uniforms that the shader needs, but the user may not 
specifically set. Default values, in essence, but also just non-random values.

Second is that, although your point about trying linking on the fly and then 
seeing what happens is a good one, I'm worried about the fact that different 
GPUs, drivers, OS's etc have very different costs for this, (all of which would 
be too much in some circumstances).

I was thinking that we could maybe build in the ability to use a conditional in 
each shader as a matter of course. That way the program object can be left as 
is, and sorted correctly, and the conditional uniform set instead of 
re-linking. The comparable mechanism to me is the 'dynamic' setting of nodes, 
or the 'useDisplayLists' setting.

So for example, instead of just:

vec4 applyBlur (vec4 inPixel
{
return inPixel;
}

or 

vec4 applyBlur (vec4 inPixel)
{
 vec4 outPixel;
// do costly blur
return outPixel;
}

the non-placeholder version might have:

vec4 applyBlur (vec4 inPixel)
{
if (!blurEnabled)
return inPixel;

 vec4 outPixel;
// do costly blur
return outPixel;
}

I hope you see the advantages - far more shader sharing and less compilation in 
a complex situation.

Bruce
___
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

[Roland Smeenk]

Hi Robert and others,

unfortunately I am experiencing some stressfull time at work which does not 
really allow me to contribute to this thread as much as I would like to. I am 
trying to keep up with the posts, but not all posts are clear to me.


robertosfield wrote:
 
 1) Provide a way of encapsulating all the details required to
 contribute a single chunk of functionality that will be combined with other 
 active ShaderSet to provide final composed osg::Program.
 


Isn't this what I solved with the ShaderMode class? 
Or is it that you are trying to separate the shader mode associated with a 
StateAttribute from the part that is responsible for adding of the piece of 
shader functionality. 


robertosfield wrote:
 
 2) Provide a convenient mapping of a single ShaderSet representing a single 
 implementation that can be shared by multiple osg::StateAttribute objects, 
 for instance all osg::Light objects would share a single
 ShaderSet for all directional lights, another ShaderSet for all positional 
 lights etc.  If different state attribute objects share the same ShaderSet 
 then there it will be easily to test whether shaders are the same simply be 
 testing the pointer value, we needn't look into the contents.
 


In my contribution I implemented a single ShaderMode that implements all fixed 
function lighting possibilities. For new types of lighting it seems more 
logical to indeed make a more fine grained breakup of ShaderModes.

However there's a (minor) advantage to this one size fits all lighting code 
currently.  To enable or disable lighting you simply can override a single 
mode. In the case where there are multiple lighting modes (directional, spot 
etc.) overall disabling of lighting needs to be done per lighting type. It 
might be needed that multiple ShaderSets implementing the same aspect/feature 
can be switched on or off all together with a single override. This will also 
be needed for instance in shadow map creation where in the first pass you would 
like to render geometry into a shadowmap as cheaply as possible and therefore 
without lighting.
Perhaps multiple ShaderSets implement a the same aspect/feature in the final 
program that need to be disabled or enabled collectively. Again in the case of 
shadowmap creation you would like to only render geometry, no texturing, no 
lighting, no fog, but you do want to take into account skinned mesh 
deformation, wind deflection etc.


robertosfield wrote:
 
 3) The ShaderSet would contain list osg::Shader objects, these osg::Shader 
 objects would target which ever part of the overall program that the 
 ShaderSet effects - be in multiple osg::Shader for vertex programs, one of 
 vertex program one for fragment, or any combination.  
 


I guess you are more targeting shader linking instead of the code generation 
that I implemented.


robertosfield wrote:
 
 The individual osg::Shader objects could also be shared by multiple ShaderSet 
 where appropriate.
 


It could, but is this likely to happen?


robertosfield wrote:
 
 5) It might well be that some StateAttribute have unifoms but no ShaderSet,
 


I see no logical use case for this. What need is a uniform if there's no 
ShaderSet using it?


robertosfield wrote:
 
  it might also be appropriate for some StateAttribute to have no uniforms and 
 a ShaderSet.  
 


Like the normalize in the fixed function pipeline?


robertosfield wrote:
 
 It might even be appropriate for a single
 StateAttribute to have multiple ShaderSet depending upon what mode it is in - 
 for instance osg::Light might be implemented in such a way that you have one 
 ShaderSet for a directional light, and one ShaderSet for position light, 
 another for spot lights, another for per pixel lighting etc, and select the 
 appropriate one depending upon the set up of the osg::Light.
 


OK, understandable if you are targetting shader linking and taking into account 
what I wrote above.

Some other notes:

Like I discussed before I still would like to emphasize the need to be able to 
tune performance by balancing between shader program size and number of program 
switches. There is no optimal solution before knowing the actual usage scenario 
and therefore a user or internal OSG balancing system should be able to adapt 
this balance to improve rendering performance.

A thing not solved in my ShaderModes based implementation is support for CPU 
side calculations needed by the simulation or renderer. This includes 
intersection testing and bounding box calculation. When implementing a new 
piece of shader functionality (for instance wind deflection) is typically is 
not hard to implement the same on the CPU side. If there exists a mechanism to 
make the intersection visitor walk through the same ShaderMode tree (or linked 
ShaderSets) it could made be possible to actually intersect a tree swaying in 
the wind.

To clearify the aspect/feature override part mentioned above here's a different 
use case I have in mind. In a 

Re: [osg-users] Shader composition, OpenGL modes and custom modes

[Mathias Fröhlich]

Hi Robert,

On Saturday 26 June 2010, Robert Osfield wrote:
 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.
Yep, I believe too that this is important to essential!

So, ok, we will get state sorting for the fixed function pipline state 
attributes because of these being traditionally sorted in the state graph.
Ok, and the additional non fixed function shader snipets will be sorted 
because of being such state attributes too.
Right?

So in effect you will know the final shader combination for a render leaf at 
cull time.
Right?

Wouldn't it be better to match the final shaders programs at cull time instead 
of draw time?
... which would only possible if the state attributes compose call might not 
work on the State object itself, but on some to be defined object that is 
used by the cull visitor to combine/collect/map/hash the shaders. Once we 
emit a render leaf to the render graph, the final shader program is attached 
to the render leaf and just used during call.
Sure, if a new combination appears this one needs to be compiled/linked first.

What is missing in my picture is the backward compatibility. I am not sure how 
this fits here.

So the final key point is that I would move the caching of the shaders away 
from the state object to some new object that is held in the cull visitor or 
somewhere there.
The render leafs will just reference the finally compiled and linked shader 
open gl objects then. The State would only need to avoid reloading the same 
final shader program twice in a series.

My two cents ...

Greetings

Mathias

-- 
Dr. Mathias Fröhlich, science + computing ag, Software Solutions
Hagellocher Weg 71-75, D-72070 Tuebingen, Germany
Phone: +49 7071 9457-268, Fax: +49 7071 9457-511
-- 
Vorstand/Board of Management:
Dr. Bernd Finkbeiner, Dr. Roland Niemeier, 
Dr. Arno Steitz, Dr. Ingrid Zech
Vorsitzender des Aufsichtsrats/
Chairman of the Supervisory Board:
Michel Lepert
Sitz/Registered Office: Tuebingen
Registergericht/Registration Court: Stuttgart
Registernummer/Commercial Register No.: HRB 382196 


___
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

[Robert Osfield]

Hi Tim,

On Sat, Jun 26, 2010 at 6:05 PM, Tim Moore timoor...@gmail.com 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
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

[Robert Osfield]

Hi Mathias,

2010/6/28 Mathias Fröhlich m.froehl...@science-computing.de:
 So, ok, we will get state sorting for the fixed function pipline state
 attributes because of these being traditionally sorted in the state graph.
 Ok, and the additional non fixed function shader snipets will be sorted
 because of being such state attributes too.
 Right?

Yes, even if we tweak the API a bit in StateSet any new elements will
sorted virtue of being in StateSet.  Whatever we do StateSet's will
remain the container for all things state in the scene graph, and the
what basis of coarsed grained state sorting and lazy state updating
that the OSG provides by default.

 So in effect you will know the final shader combination for a render leaf at
 cull time.
 Right?

Yes, once you've traversed down the graph to the osg::Drawable leaves
you know all the state inheritance and can compute the final program
and uniform combination that will be required.

 Wouldn't it be better to match the final shaders programs at cull time instead
 of draw time?

The only reason there might be an advantage is that if you draw
traversal was more CPU limited than the draw.  In general I would
expect the cost of selecting the appropriate programs during draw will
be very low relative to the cost of dispatching the data itself.

The only part that might be expensive is the composition of the shader
mains and then compiling these main shaders, but again the cost of
composing the main shaders is likely to be much lower than the OpenGL
side of compiling them, and you have to do the compiling in the draw
traversal any so the saving again is likely to be be pretty small if
detectable.

Doing more work in the cull will mean we'll have to pass more data to
draw which itself may result in a performance overhead as the extra
data structures will need to be dynamically allocated/destroyed.

Right I want to get things working, the API and the backend are going
to be new and complex enough that I want to take the route of least
resistance and not worry to much about small possible optimization.
Moving more work into cull might be an optimization that would be
worth doing, but then it could just as easily be worse for
performance.

A more clear cut optimization would be to have a NodeVisitor that we
can run on the scene graph after it's loaded and then work out the
likely shaders that will be combined and from this what shader mains
we'll need to compose during rendering, from this we could populate
the cache and precompile both the user/fixed function emulation
shaders and the newly created shader mains.  The draw traversal would
then just select from this cache.

 ... which would only possible if the state attributes compose call might not
 work on the State object itself, but on some to be defined object that is
 used by the cull visitor to combine/collect/map/hash the shaders. Once we
 emit a render leaf to the render graph, the final shader program is attached
 to the render leaf and just used during call.
 Sure, if a new combination appears this one needs to be compiled/linked first.

We'll once we have a working shader composition API and implementation
checked in you can start experimenting with different back-end
implementations to your hearts content, if you find something useful
then you'll be able to provide nice benchmarks to illustrate it's
value :-)

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

[Robert Osfield]

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

[Robert Osfield]

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

[Robert Osfield]

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

Re: [osg-users] Shader composition, OpenGL modes and custom modes

[Tim Moore]

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

Re: [osg-users] Shader composition, OpenGL modes and custom modes

[Tim Moore]

On Fri, Jun 25, 2010 at 12:25 AM, Wojciech Lewandowski 
lewandow...@ai.com.pl wrote:

 Hi Guys,

 We all seem to agree that the topic actually consists from two subtopics:
 ShaderGeneration and ShaderComposition. Shader generation would be mostly
 used to emulate Fixed Pipeline and replace GL Attributes/Modes with
 generated uniforms and shader pieces. ShaderComposition would allow mixing
 and linking of various shader pieces gathered during cull traversal. Shader
 Generation seems to be the current focus of the discussion.
 ShaderComposition seems to be of a lower priority. I have the felling that
 these two subjects could be addressed together but they also could be
 addressed independently. ShaderComposition is needed to implement
 ShaderGeneration but not the opposite. So wouldn't it be better to first
 implement flexible  ShaderCompositor that at first would only work with
 programmable pipeline in OSG ?. And later build ShaderGenerator on top of
 ShaderCompositor ?

 ...
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?

Tim
___
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

[Robert Osfield]

Hi Wojtek,

I don't really see a strong separation between emulation of the fixed
function pipeline and shader composition.  My current view is that
we'll have StateAttribute's that provide batches of uniforms, any
shaders that are required, and guidance on how into inject support for
them into the vertex/geometry/fragment/main shaders.  The fact that a
StateAttribute might be come from a fixed function pipeline background
won't make any difference to the actual shader composition.  At least
this is what I'm gunning for.

I would also like to make it quite easy to find out what uniforms
various StateAttribute subclasses use and what Shaders they provide.
I really don't want us to end up with black boxes that users either
use without knowing, or ignoring completely because they aren't sure
what they do.  The situation you describe is really what I'm trying to
avoid - I want the community to be able to freely mix and match where
they find each component useful.

For high level techniques such as deferred shading I see it as natural
that you'd happily mix the two.  The first pass rendering the scene to
a depth and colour buffers could happily use a traditional
StateAttribute without any custom shaders if you don't need them, but
then the second pass you'd obvious bring in to play all your custom
shaders.

There are also high level techniques like overlays and shadows where
eye linear texgen is used, here you'd want to leverage the OSG's core
support for eye linear texgen, otherwise you'll end up have to code
lots of your own solutions.

Robert.

On Thu, Jun 24, 2010 at 11:25 PM, Wojciech Lewandowski
lewandow...@ai.com.pl wrote:
 Hi Guys,

 We all seem to agree that the topic actually consists from two subtopics:
 ShaderGeneration and ShaderComposition. Shader generation would be mostly
 used to emulate Fixed Pipeline and replace GL Attributes/Modes with
 generated uniforms and shader pieces. ShaderComposition would allow mixing
 and linking of various shader pieces gathered during cull traversal. Shader
 Generation seems to be the current focus of the discussion.
 ShaderComposition seems to be of a lower priority. I have the felling that
 these two subjects could be addressed together but they also could be
 addressed independently. ShaderComposition is needed to implement
 ShaderGeneration but not the opposite. So wouldn't it be better to first
 implement flexible  ShaderCompositor that at first would only work with
 programmable pipeline in OSG ?. And later build ShaderGenerator on top of
 ShaderCompositor ?

 I believe there is a number of developers interested only in programmable
 pipeline.  They would not mind writing shader chunks  and using their
 uniforms to attain effect that fixed pipeline would also give them. They
 would do this to have clear and consistent shader code. And often they want
 to make transition to fully programmable pipeline as fast as possible
 because they feel thats how the 3D future will look.

 I am ready to make such switch.  I only need working ShaderComposition.
 Personally I'm not interested in fixed pipeline emulation and where possible
 I will try to program shader pipeline myself. Call me short sighted but I am
 afraid that trying to replace programmers with shader generators will make
 this coding more complicated.

 Once ShaderComposition becomes available I am not going to go back to FFP
 and will avoid StateAttributes that exist only in fixed pipeline. I will
 thus indirectly avoid using ShaderGeneration feature as well. In my opinion
 many programmable pipeline concepts are easier to understand than the stuff
 in Fixed Pipeline (take TexEnv or TexMat for example) and I would always
 prefer to have direct control over uniforms  shaders neccessary to
 implement certain feature.  With ShaderGeneration I will never be sure what
 shader code was produced and how uniforms were attached.

 That's my opinion. But I am taking the risk of presenting it because I think
 there are others who share this view and would prefer to make transition to
 fully programmable pipeline as quickly as possible. There is a number of
 algorithms where Fixed pipeline states simply don't  fit. Deffered shading
 for huge number of lights for example. Its better to implement them in fully
 programmable environment than mix fixed and programmable approaches.

 I know there are other users and lots of existing OSG code which relies on
 fixed pipeline. I understand that this existing code will require
 ShaderGeneration but I really feel that the discussion is focusing on second
 step when first one was not made yet.

 Cheers,
 Wojtek Lewandowski
 PS. I won't be able to respond for next 3 days.



 --
 From: Robert Osfield robert.osfi...@gmail.com
 Sent: Thursday, June 24, 2010 4:51 PM
 To: osg-users@lists.openscenegraph.org
 Subject: Re: [osg-users] Shader composition, OpenGL modes and custom modes

 Hi All,

 As another step towards experimenting

Re: [osg-users] Shader composition, OpenGL modes and custom modes

[Johannes Maier]

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

Re: [osg-users] Shader composition, OpenGL modes and custom modes

[Bruce Wheaton]

On Jun 25, 2010, at 6:42 AM, Mathias Fröhlich wrote:

 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.

Actually, I was thinking of something more sophisticated:

Use shader linking and/or conditional compilation/string concatenation for 
shaders that are defined ahead of time.
Use conditional if/then statements for attributes that are declared as dynamic.

That way you can sort on the shader, just set the uniforms (including the ones 
used for conditional switches) per use, and you also minimize re-compilation 
and/or re-linking.

This should probably be selectable back-end behavior, in the same way that 
display lists are now.

Bruce



___
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

[Robert Osfield]

Hi Bruce,

On Wed, Jun 23, 2010 at 9:23 PM, Bruce Wheaton br...@spearmorgan.com wrote:
 So, we would do the same enable calls on state sets with custom made enums, 
 and then also provide a shader function that will be used only if that 
 feature is enabled?

Yes that's the idea.

 It sounds like a great idea... although isn't it maybe sufficiently useful 
 that it deserves it's own enable and set functions, especially if all the 
 enums are custom? Then name collisions won't be a problem.

To support the seamless mapping of the existing fixed function
pipeline based scene graph to shaders we'll need retain support for
the existing setMode(GLenum..) functionality, having another set of
methods for enabling/disabling shaders as well introduce it's own
conflicts - it conceptually would separate custom shaders from fixed
function shaders, but internal implementation wise they'd still have
to be mixed so we'd end up with concepts and API that don't match what
is happening behinds the scenes.  I feel this would be a recipe for
confusion and lots of bugs in OSG and end user code.

My wish to achieve a good level of transparency about how things are
mapped from the scene graph API front end and how the final shaders
are composed in the back end.  Right now engineers are familiar with
the idea of fixed function pipeline and shaders, and the fact that
they are two separate routes in OpenGL, if we get it right way break
down this separating both in implementation and conceptually then
we'll suddenly open out lots of possibilities in people minds.

 The more I think about it though, the more it does seem like enable/disable 
 and set value is a good fit. The there could also be different backend 
 methods to create the final shader - by compilation if there's enough time, 
 or by conditional if the graphics system does it quickly enough...

Having a ShaderComposer that is attached to osg::State that does the
work of taking all the enable modes and generating the final
osg::Shader/osg::Program will be the natural way to implement it.
Roland's implementation already has this in place in the form of an
osg::ShaderGenerator class.

Potentially we could allow users to assign their own custom
ShaderComposor at application start up, or perhaps even allow one to
attach a custom ShaderCompsor to a StateSet and maintain a stack in
osg::State, so the the top of the stack is used to do the shader
composition.  Most application would never need to override the
standard shader composition but I would guess that some advanced users
might relish the opportunity.

For a first pass I want to get something working with just a single
ShaderGenerator attached to osg::State, there is enough complexities
to deal with without making things more complicated at the start.

 One worry might be the implication that every single 'building block' could 
 be dropped in and things will still work. I have a number of shader pieces 
 that only work in the context of a bunch of other shader pieces being active, 
 along with the correct textures etc etc.

Needing to make sure various components are enabled to achieve an
overall effect is something that we all need to manage right now so I
would expect we'll still have to play by these rules - be sensible
about creating scene graphs that work and not expecting the backend to
somehow cope when we throw at it an inconsistent setup.

It has just occurred to me the ShaderComposer itself could output
quite a bit of useful debugging about what modes are enabled, what
shaders are available and what is output is generated - this might be
quite useful for debugging scene graph state.

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

[Robert Osfield]

Hi Roland,

On Wed, Jun 23, 2010 at 11:20 PM, Roland Smeenk roland.sme...@tno.nl wrote:
 I have to dig up the thoughts I had during the period I implemented the 
 shader composition that you reviewed. The goals you mention where also the 
 ones I tried to achieve.

There are lots of parallels with what thoughts I kicked off in this
thread and your submission, I've been toying with the idea of using
modes for the past six months so when I got your submission it was
great to see how you'd gone in a similar direction.  Implementation
wise is a bit different than what I was thinking, but it spookily
close.  A good sign as clearly we've both working on the same goals.



 robertosfield wrote:

 The absolute minimum code changes required in end user apps is none at
 all, might this be possible?  If that is to be achieved then we need
 to be able to use the osg::StateSet::setMode(GLenum,...) and all the
 osg::StateSet::setAttribute(..) and all StateAttributes subclasses
 that we are familiar with.
 As you probably saw in my submission this can be done for StateAttributes 
 that are set and modes that are automatically applied by a StateAttribute. 
 For explicitly setting GL modes I used a lookup map, which did not really 
 feel like an ideal solution.

To provide the mapping of the fixed function pipeline to shader we'll
have to use maps to catch the appropriate modes.  I do wonder if we
might be able to do some of this internally in osg::StateSet when
setting up modes, this would avoid some of the runtime overhead in
sorting out which modes to path through to glEnable/glDisable and
which ones to pass through to the shader composition.  For a first
pass push this map into osg::State feels reasonable, and perhaps long
term it'll remain the best approach.

I was hoping to avoid the need for ShaderMode and it's subclasses.  I
don't know yet whether this is doable or in the end desirable.   I am
toying with the idea that we might be able to push the implementation
of the shaders to use and the hints/rules on how to compose the
shaders into the final main into osg::StateAttribute, perhaps even
right into the base class.

 robertosfield wrote:

 Now some parts of OpenGL state are common
 between the fixed function pipeline and the shader pipeline and live
 on right from GL1 to GL4 and GLES2, these parts needn't change one bit
 which is good news.


 By this you mean the parts of the pipeline that are not (yet) programmable?

I mean modes like enabling and disabling depth test, stencil test,
colour buffers, depth write etc.


 An example of a such a mode is GL_NORMALIZE. It is a mode that doesn't have 
 any additional parameters controlling it and therefore did not need a 
 StateAttribute.
 I tried to solve this with the lookup map I mentioned above. It is the 
 _GLModeShaderModeMap in the osg::State class. It maps modes that are directly 
 set to corresponding ShaderModes.

This is a good point to bring up, if we don't have a separate
ShaderMode scheme like yours how to cope with parts of that have modes
that are enabled/disbable but not actual uniform data associated with
them.   Perhaps a StateAttribute that is non op when running in fixed
function mode, but when still able to provide the Shader/the shader
composition hints/rules.

 Side note:
 In case of shader generation glEnable/glDisable can be implemented in  two 
 ways. We have either the choice to leave out the code of disabled modes and 
 generate a new shader program or disable a piece of shader code in an already 
 existing shader program by wrapping it in an if statement. Both choices 
 should be possible to be able to select the best possible shader program 
 granularity to use at runtime. (big shader program with lot of uniforms for 
 static branching vs. lots of smaller shader programs that are switched during 
 rendering)

I'm inclined to compose only the main() function and leave the bulk of
functionality in shader functions provided by separate osg::Shader
objects.  This main would be composed of all what is required for that
particular mode combination, no if statements, and no uniforms
dictating branches.  This approach makes the assumption that we want
to make the job of drivers GLSL compiler as simple as possible, and
give it the least amount of room to mess up and generate inefficient
code.

 The second half of this approach would be for the 
 osg::StateAttrirbute::apply(..) methods to use uniforms to pass in the state 
 to the shaders rather than their use glFunctionCalls.  Again this is 
 something that should be possible to hide from the set of those 
 StateAttribute subclasses and osg::State. I *think* it should be possible to 
 get something working along these lines.  Implementation will tell us 
 whether it's possible though.


 Do you mean that it should be possible to leave for example TexEnv::apply() 
 unmodified?

No, I'm thinking that TexEnv::apply() etc. would all need to modified
to have the old fixed function glFunctionCalls in 

Re: [osg-users] Shader composition, OpenGL modes and custom modes

[Robert Osfield]

I'm continuing my pondering of shader composition and I'm currently
thinking about extending StateAttribute a little to support shader
composition.  Currently we have two virtual methods in
StateAttribute::getModeUsage(ModeUsage) and
StateAttribute::apply(State) that subclasses override to provide the
specific behavior associated with that attribute.  I'm thinking about
retaining these, but extending their role a little, and adding another
virtual method StateAttribute::compose(osg::State).  As well as this
small addition to StateAttribute we'd need to extend ModeUsage to help
provide more details about the nature of the modes that it supports
w.r.t shader composition.

The roles of these methods would be:

   StateAttribute::getModeUsage(ModeUsage)

Passing information about supported modes that should be used for
glEnable/glDisable, which ones should be mapped to shaders when doing
shader composition.  In the case of custom GLenum that we come up with
ourselves these would never be used for glEnable/glDisable,
just for informing
the shader composer what to enable/disabling when compiling
the shader main()
for each of the vertex, geometry and fragment programs.

Roland's implementation follows this pattern already, although via the
introduction ShadeMode::Type and ShaderModeIndexPair.


   StateAttribute::apply(State)

   Provides two potential code paths - fixed function calls i.e.
glMaterial and
   the shader composition version applying unifoms that are local to that
   StateAttribute and are required for the shaders associated with
that attribute.

   I'm thinking about having a couple of macros to introduce each
of the code
   paths such that for each GL/GLES target we build the OSG to we'll be able
   to enable or disable each path appropriately, either at runtime
or compile
   time.


   StateAttribute::compose(State) / maybe compose(ShaderComposer)

  Pushes the osg::Shader objects required for the functionality (could be
  none to many) and pushes the GLSL code fragments that need to
injected into
  Shader main of the the vertex, geometry and fragment programs.


I'm also wondering about the possibility of having a ShaderAttribute
class that subclasses from StateAttribute and makes it possible to set
up the osg::Shader's associated with the attribute, and the GLSL code
fragments that need to injected, as well as set up the custom type and
modes associated with it.  We could easily have the type settable to
existing fixed function StateAttribute::Type values and GLenum's so
code enable us to override standard fixed function features with
custom shaders, without ever needing us to subclass - we just compose
the ShaderAttribute with how we want it used.

Since the above suggestions are a relatively small change to the
existing API it will be quick to implement the interface and could be
done with breaking any existing functionality or end users
applications.  It's tempting for me to just check these changes in,
and then look at the next part of the equation - the really hard part,
the ShaderComposer interface and implementation.

What I may do is start fleshing out a very basic interface and
implementation for ShaderComposer that does little more than a non op,
and put together a really simple example that enables us to create a
scene graph and see how the wiring works at runtime.

The next step after this would be to get shader composition working
with a custom set of ShaderAttribute that completely ignore the fixed
function pipeline.  Once the mechanics of shader composition and
interface are working we can then looking to step by step mapping the
fixed function features across to having code paths that support
shader composition.

If all this comes together well then the next challenge will be
rewriting the way that NodeKits like osgShadow and osgParticle do
their shaders, rather than having them provide full osg::Program for
their shaders we'd need to convert them across to use ShaderAttribute.

Thoughts? Suggestions?

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

[Robert Osfield]

Hi All,

As another step towards experimenting with shader composition I've
renamed the osgshadercompositor example to osgvirtualprogram as this
example is based around a VirtualProgram class, and I'd like to
differentiate between test beds like this and work to towards the
final shader composition support.

Later I'll add a
osgshadercomposition/osgshadercompositor/osgshadercomposer example
that will be the test bed for the new work on shader composition.

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

[Wojciech Lewandowski]

Hi Guys,

We all seem to agree that the topic actually consists from two subtopics: 
ShaderGeneration and ShaderComposition. Shader generation would be mostly 
used to emulate Fixed Pipeline and replace GL Attributes/Modes with 
generated uniforms and shader pieces. ShaderComposition would allow mixing 
and linking of various shader pieces gathered during cull traversal. Shader 
Generation seems to be the current focus of the discussion. 
ShaderComposition seems to be of a lower priority. I have the felling that 
these two subjects could be addressed together but they also could be 
addressed independently. ShaderComposition is needed to implement 
ShaderGeneration but not the opposite. So wouldn't it be better to first 
implement flexible  ShaderCompositor that at first would only work with 
programmable pipeline in OSG ?. And later build ShaderGenerator on top of 
ShaderCompositor ?


I believe there is a number of developers interested only in programmable 
pipeline.  They would not mind writing shader chunks  and using their 
uniforms to attain effect that fixed pipeline would also give them. They 
would do this to have clear and consistent shader code. And often they want 
to make transition to fully programmable pipeline as fast as possible 
because they feel thats how the 3D future will look.


I am ready to make such switch.  I only need working ShaderComposition. 
Personally I'm not interested in fixed pipeline emulation and where possible 
I will try to program shader pipeline myself. Call me short sighted but I am 
afraid that trying to replace programmers with shader generators will make 
this coding more complicated.


Once ShaderComposition becomes available I am not going to go back to FFP 
and will avoid StateAttributes that exist only in fixed pipeline. I will 
thus indirectly avoid using ShaderGeneration feature as well. In my opinion 
many programmable pipeline concepts are easier to understand than the stuff 
in Fixed Pipeline (take TexEnv or TexMat for example) and I would always 
prefer to have direct control over uniforms  shaders neccessary to 
implement certain feature.  With ShaderGeneration I will never be sure what 
shader code was produced and how uniforms were attached.


That's my opinion. But I am taking the risk of presenting it because I think 
there are others who share this view and would prefer to make transition to 
fully programmable pipeline as quickly as possible. There is a number of 
algorithms where Fixed pipeline states simply don't  fit. Deffered shading 
for huge number of lights for example. Its better to implement them in fully 
programmable environment than mix fixed and programmable approaches.


I know there are other users and lots of existing OSG code which relies on 
fixed pipeline. I understand that this existing code will require 
ShaderGeneration but I really feel that the discussion is focusing on second 
step when first one was not made yet.


Cheers,
Wojtek Lewandowski
PS. I won't be able to respond for next 3 days.



--
From: Robert Osfield robert.osfi...@gmail.com
Sent: Thursday, June 24, 2010 4:51 PM
To: osg-users@lists.openscenegraph.org
Subject: Re: [osg-users] Shader composition, OpenGL modes and custom modes


Hi All,

As another step towards experimenting with shader composition I've
renamed the osgshadercompositor example to osgvirtualprogram as this
example is based around a VirtualProgram class, and I'd like to
differentiate between test beds like this and work to towards the
final shader composition support.

Later I'll add a
osgshadercomposition/osgshadercompositor/osgshadercomposer example
that will be the test bed for the new work on shader composition.

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] Shader composition, OpenGL modes and custom modes

[Robert Osfield]

Hi All,

I'm currently brainstorming on how to support of shader composition in
the OSG, and would like to get some feedback one element of a possible
approach that I'm considering.

Two of my design goals is to provide a good mapping between the fixed
function pipeline and shader based pipelines, and I'd also like to
minimize the number of code changes required by end user applications.
 Whether these are both attainable or not we'll work in the next few
weeks, but I guess few would disagree with that these are worthy
goals.

The absolute minimum code changes required in end user apps is none at
all, might this be possible?  If that is to be achieved then we need
to be able to use the osg::StateSet::setMode(GLenum,...) and all the
osg::StateSet::setAttribute(..) and all StateAttributes subclasses
that we are familiar with.  Now some parts of OpenGL state are common
between the fixed function pipeline and the shader pipeline and live
on right from GL1 to GL4 and GLES2, these parts needn't change one bit
which is good news.

However, the majority of glEnable/glDisable(GLenum) and the associated
glFunctionCalls aren't mapped, for these we'd need to automatically
map these to equivalent glShader/glPrograms and glUniforms.  This
mapping will have to automatically detect these modes and avoid
calling the usual glEnable/glDisable, as well as be redirected into a
current active set of modes that are enabled, this active set of modes
would then map to the appropriate combination of shaders to implement
them.  This mapping of modes is something that osg::State could do for
us without any changes to osg::State.  The second half of this
approach would be for the osg::StateAttrirbute::apply(..) methods to
use uniforms to pass in the state to the shaders rather than their use
glFunctionCalls.  Again this is something that should be possible to
hide from the set of those StateAttribute subclasses and osg::State.
I *think* it should be possible to get something working along these
lines.  Implementation will tell us whether it's possible though.

Now mapping of the fixed function pipeline to shaders conveniently is
only part of the story with shader composition.  We actually want end
users to be able to selectively replace parts of the glProgram without
their own shaders, both replacing the fixed function parts and
composing your own shaders - we'd want a full mix and match, from all
standard fixed function equivalents to all custom shaders.  Now one
element of what makes the current fixed function pipeline so
convenient is that we can enable/disable whole chunks of fixed
function pipeline anywhere in the scene graph, and the one of OSG's
greatest assets over the years has been the decoupling of modes from
attributes making these OpenGL feature really accessible, this asset
would be great to carry over into the new era of shader composition.
Since I'm wanting to a real easy mix/match of the fixed function and
custom shaders then I also want to blurr the distinction when using
modes.  Which leads me to a suggestion that might be controversial...
and the crux for this post...

My thought is to allow users to use osg::StateSet::setMode(GLenum...)
with not just the standard GLenum we know and love, and that are
managed by Khronos, but to allow us to use our own custom mode values
that extend beyond that our gl.h headers provide.  These GLenum values
would down to OSG users to decide when they set up their custom
shaders, and for them to tell the OSG how to map them to shaders when
doing shader composition.   Perhaps we could just ear mark a certain
range of values that we use ourselves, perhaps even tell Khronos about
it so they can advice us to avoid certain ranges that the plan on
using.  Perhaps we just do it informally and pick a pretty distant
range along way from anything that OpenGL uses right now.

Thoughts?
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

[Bruce Wheaton]

So, we would do the same enable calls on state sets with custom made enums, and 
then also provide a shader function that will be used only if that feature is 
enabled?

It sounds like a great idea... although isn't it maybe sufficiently useful that 
it deserves it's own enable and set functions, especially if all the enums are 
custom? Then name collisions won't be a problem.

The more I think about it though, the more it does seem like enable/disable and 
set value is a good fit. The there could also be different backend methods to 
create the final shader - by compilation if there's enough time, or by 
conditional if the graphics system does it quickly enough...

One worry might be the implication that every single 'building block' could be 
dropped in and things will still work. I have a number of shader pieces that 
only work in the context of a bunch of other shader pieces being active, along 
with the correct textures etc etc.

It's definitely intriguing.

Bruce

--
Read this topic online here:
http://forum.openscenegraph.org/viewtopic.php?p=29334#29334





___
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

[Roland Smeenk]

Hi Robert,

I have to dig up the thoughts I had during the period I implemented the shader 
composition that you reviewed. The goals you mention where also the ones I 
tried to achieve.


robertosfield wrote:
 
 The absolute minimum code changes required in end user apps is none at
 all, might this be possible?  If that is to be achieved then we need
 to be able to use the osg::StateSet::setMode(GLenum,...) and all the
 osg::StateSet::setAttribute(..) and all StateAttributes subclasses
 that we are familiar with.


As you probably saw in my submission this can be done for StateAttributes that 
are set and modes that are automatically applied by a StateAttribute. For 
explicitly setting GL modes I used a lookup map, which did not really feel like 
an ideal solution.


robertosfield wrote:
 
 Now some parts of OpenGL state are common
 between the fixed function pipeline and the shader pipeline and live
 on right from GL1 to GL4 and GLES2, these parts needn't change one bit
 which is good news.


By this you mean the parts of the pipeline that are not (yet) programmable?


robertosfield wrote:
 
 However, the majority of glEnable/glDisable(GLenum) and the associated
 glFunctionCalls aren't mapped, for these we'd need to automatically
 map these to equivalent glShader/glPrograms and glUniforms.  This
 mapping will have to automatically detect these modes and avoid
 calling the usual glEnable/glDisable, as well as be redirected into a
 current active set of modes that are enabled, this active set of modes
 would then map to the appropriate combination of shaders to implement
 them.  This mapping of modes is something that osg::State could do for
 us without any changes to osg::State. 
 

An example of a such a mode is GL_NORMALIZE. It is a mode that doesn't have any 
additional parameters controlling it and therefore did not need a 
StateAttribute. 
I tried to solve this with the lookup map I mentioned above. It is the 
_GLModeShaderModeMap in the osg::State class. It maps modes that are directly 
set to corresponding ShaderModes.

Side note:
In case of shader generation glEnable/glDisable can be implemented in  two 
ways. We have either the choice to leave out the code of disabled modes and 
generate a new shader program or disable a piece of shader code in an already 
existing shader program by wrapping it in an if statement. Both choices should 
be possible to be able to select the best possible shader program granularity 
to use at runtime. (big shader program with lot of uniforms for static 
branching vs. lots of smaller shader programs that are switched during 
rendering)


robertosfield wrote:
 
 The second half of this approach would be for the 
 osg::StateAttrirbute::apply(..) methods to use uniforms to pass in the state 
 to the shaders rather than their use glFunctionCalls.  Again this is 
 something that should be possible to hide from the set of those 
 StateAttribute subclasses and osg::State. I *think* it should be possible to 
 get something working along these lines.  Implementation will tell us whether 
 it's possible though. 
 

Do you mean that it should be possible to leave for example TexEnv::apply() 
unmodified?
As you probably saw I modified the implementation of TexEnv::apply() to set the 
needed uniforms needed by the particular piece of shader code implementing 
TexEnv in shader code.


robertosfield wrote:
 
 Now mapping of the fixed function pipeline to shaders conveniently is
 only part of the story with shader composition.  We actually want end
 users to be able to selectively replace parts of the glProgram without
 their own shaders, both replacing the fixed function parts and
 composing your own shaders - we'd want a full mix and match, from all
 standard fixed function equivalents to all custom shaders.  Now one
 element of what makes the current fixed function pipeline so
 convenient is that we can enable/disable whole chunks of fixed
 function pipeline anywhere in the scene graph, and the one of OSG's
 greatest assets over the years has been the decoupling of modes from
 attributes making these OpenGL feature really accessible, this asset
 would be great to carry over into the new era of shader composition.
 Since I'm wanting to a real easy mix/match of the fixed function and
 custom shaders then I also want to blurr the distinction when using
 modes.


This is exactly the holy grail to achieve. Often the actual compositing is done 
by letting the users draw the shader graph with a tool or in some other way 
describing the possible graph layouts. In my implementation I try to 
dynamically connect shader modes. This is currently done in a limited way as it 
only involves string based input and output parameter matching. This is a part 
that needs further attention.


robertosfield wrote:
 
 My thought is to allow users to use osg::StateSet::setMode(GLenum...)
 with not just the standard GLenum we know and love, and that are
 managed by Khronos, but to allow us to use our own 

[osg-users] shader composition (review?experience?)

[Trajce (Nick) Nikolov]

Hi Community,

recently there was submission on osg-submission list with shader
composition. Has anyone done some work on it? What are your thoughts,
experience?

-Nick
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org

[osg-users] Shader Composition - pixel formats

[Bruce Wheaton]

The phrase gets thrown around a lot, and there seems to be an  
assumption that everyone knows exactly what it means in this context.  
I'm new, I don't, and searching doesn't seem to solve the problem.


My presumption is that it's an effort to solve the problem of recent  
'shader only' OpenGL versions, where adding features to a shader is  
the way to affect rendering, as opposed to changing states? And it  
will use the ability to link multiple shaders into each shader stage?


So will there be a standardized naming of functions, so that a master  
shader can 'collate' all the stages? What's the plan?


Main reason I ask - I currently have a 'master fragment shader' and I  
customize it by concatenating a one line main() function at the end  
that calls the right functions. Obviously, installing that will  
subvert a good portion of state that OSG is trying to manage and sort  
for me. I'd also like to break this down myself, and use a more  
flexible approach, that should also require less compiling (although  
more linking).


My stages are something like:

Decode pixel format: converts planar and packed pixel formats into  
RGBA Float 16-bit (HALF) as YUVA data.

Apply brightness/contrast/saturation
Convert to rec.709 colorspace RGBA
Remove transfer function (gamma)

More work

Later I need stages to de-interlace or not, then trilinear scale, re- 
apply transfer functions etc. Be nice to apply lighting here if needed.


Is this the sort of thing shader composition will help with?

Bruce






___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org

Re: [osg-users] Shader Composition - pixel formats

[Jean-Sébastien Guay]

Hi Bruce,


The phrase gets thrown around a lot, and there seems to be an assumption
that everyone knows exactly what it means in this context. I'm new, I
don't, and searching doesn't seem to solve the problem.


You're right, when we talk about shader composition it's what we're 
labeling our attempts to find a way to make the shader-based pipeline of 
newer OpenGL versions react to changes in what used to be OpenGL state, 
and will eventually become OSG state. It's an attempt to keep the nice 
encapsulation of state that OSG gives us through StateSets and 
StateAttributes but make it work on the shader-based OpenGL 3.x+.


The osgshadercompositor example in the current OSG sources shows what 
could be a potential direction for this. It has a new subclass of 
osg::Program, VirtualProgram, and you essentially add prototypes for 
functions along with a shader fragment associated to it, and lower down 
in the graph you might override that prototype with a new shader 
fragment, kind of like virtual functions in object-oriented code.


(there's currently a performance penalty associated with the use of 
VirtualProgram which someone will look into eventually)


Note that the osgshadergen example is totally different, it generates 
one shader from a combination of states instead of linking the right 
shader fragments together. IMHO this is less powerful.


Look at the example and see if you can join the discussion when the time 
comes :-)



Is this the sort of thing shader composition will help with?


I think it definitely can help with your situation. In our case, when we 
talk about it, it's mostly for the goal I explained above, as well as to 
help with nodekits which may specify a default shader that the user then 
needs to completely rewrite for their application (examples are 
osgShadow and osgOcean). Shader composition would help make that process 
easier by defining an interface that the nodekit's shaders expose, and 
then the user's shaders can call functions from that interface to get 
the right results.


Hope that clears things up at least theoretically. Robert has said that 
it's one of his milestones for OSG 3.0 to implement at least a first 
version of shader composition (or some way to make shader-based 
development better integrated into the OSG graph) so I guess he'll start 
a discussion about it eventually.


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] Shader composition

[Robert Osfield]

Hi Chris,

My plan is still to tackle the shader composition prior to 3.0.  I haven't
had a chance to make any more progress on it this yet as I've been hunkered
down with merging submissions/bug fixes/refactors of problematic parts of
the OSG.

To tackle shader composition I really need to hide myself away in a bunker
for a week or two, concentrate 100% on the design as getting it to be
flexible enough and perform as good as the existing fixed function pipeline
will be a big challenge.

While there is still a big submissions backlog it's kinda hard for me to
just turn my back on it, and I can't juggle the two tasks at the same time.
This does put the pressure on whether I can get shader composition done
before the next stable release, or when I have to go back to earning a
living.  I do believe shader composition will be the killer feature for us
going forward, but it has to deliver on flexibility and performance,
compromises on this and we'll not see it adopted.

If someone wants to help fund my efforts on shader composition then feel
free :-)

Robert.

On Thu, Feb 25, 2010 at 2:27 AM, Chris 'Xenon' Hanson
xe...@alphapixel.comwrote:

  One of my clients is headed squarely into a place in their project where
 they need to do
 a lot of sophisticated shader work throughout the whole scenegraph.

  I was reading back along message history from January and I saw some
 mention of shader
 composition coming to OSG in an official manner relatively soon. With the
 stable release
 on the near roadmap, I was wondering if shader composition was now further
 down-road from
 the stable release or what the official plan was.

  I think there might be several people interested in working on this when
 it comes to the
 front of the queue. If anyone wants to register their interest, this might
 be a good time
 to chip in.

 --
 Chris 'Xenon' Hanson, omo sanza lettere  Xenon
 AlphaPixel.com
 PixelSense Landsat processing now available!
 http://www.alphapixel.com/demos/
 There is no Truth. There is only Perception. To Perceive is to Exist. -
 Xen
 ___
 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

[Lilith Bryant]

Robert, Chris, et al,

I highly suggest you do some benchmarking on shader compiling/link times.  We 
investigated this a couple of years ago, and found that we couldn't avoid an 
output glitch (due to compile/link time) whenever we needed a new shader.

GL Drivers may well have improved since then, but I'd hate to see you spend 
weeks getting something together only to find it's unusable in practice.

Lilith

On 2010-02-25 10:02:33 PM, Robert Osfield wrote:
 Hi Chris,
 
 My plan is still to tackle the shader composition prior to 3.0.  I haven't
 had a chance to make any more progress on it this yet as I've been hunkered
 down with merging submissions/bug fixes/refactors of problematic parts of
 the OSG.
 
 To tackle shader composition I really need to hide myself away in a bunker
 for a week or two, concentrate 100% on the design as getting it to be
 flexible enough and perform as good as the existing fixed function pipeline
 will be a big challenge.
 
 While there is still a big submissions backlog it's kinda hard for me to
 just turn my back on it, and I can't juggle the two tasks at the same time.
 This does put the pressure on whether I can get shader composition done
 before the next stable release, or when I have to go back to earning a
 living.  I do believe shader composition will be the killer feature for us
 going forward, but it has to deliver on flexibility and performance,
 compromises on this and we'll not see it adopted.
 
 If someone wants to help fund my efforts on shader composition then feel
 free :-)
 
 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

[Robert Osfield]

Hi Lilith,

On Thu, Feb 25, 2010 at 9:12 AM, Lilith Bryant dark...@gmail.com wrote:

 I highly suggest you do some benchmarking on shader compiling/link times.
  We
 investigated this a couple of years ago, and found that we couldn't avoid
 an
 output glitch (due to compile/link time) whenever we needed a new shader.


I agree that performance is critical.  When ever I make major changes to the
OSG I do lots of benchmarking.

In this specific case compilation, linking and uniform changes all have
their own performance issues to be mindful of.  My expectation for shader
composition was that we'd need to do upfront compilation, and linking as
much as possible and select between complete programs rather than
dynamically doing too much actual shader composition during draw dispatch on
each frame.

Keeping the CPU overhead of doing selection of which program to make active
is also something that I've been pondering about.

Keeping this all in check is why I need to spend the time thinking about the
design so deeply.

Robert.

I
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org

Re: [osg-users] Shader composition

[Chris 'Xenon' Hanson]

On 2/25/2010 2:02 AM, Robert Osfield wrote:
 If someone wants to help fund my efforts on shader composition then feel
 free :-)

  I'll find out where they stand on it.

 Robert.

-- 
Chris 'Xenon' Hanson, omo sanza lettere  Xenon AlphaPixel.com
PixelSense Landsat processing now available! http://www.alphapixel.com/demos/
There is no Truth. There is only Perception. To Perceive is to Exist. - Xen
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org

[osg-users] Shader composition

[Chris 'Xenon' Hanson]

  One of my clients is headed squarely into a place in their project where they 
need to do
a lot of sophisticated shader work throughout the whole scenegraph.

  I was reading back along message history from January and I saw some mention 
of shader
composition coming to OSG in an official manner relatively soon. With the 
stable release
on the near roadmap, I was wondering if shader composition was now further 
down-road from
the stable release or what the official plan was.

  I think there might be several people interested in working on this when it 
comes to the
front of the queue. If anyone wants to register their interest, this might be a 
good time
to chip in.

-- 
Chris 'Xenon' Hanson, omo sanza lettere  Xenon AlphaPixel.com
PixelSense Landsat processing now available! http://www.alphapixel.com/demos/
There is no Truth. There is only Perception. To Perceive is to Exist. - Xen
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org

Re: [osg-users] Shader composition

[Trajce (Nick) Nikolov]

I am interested. At present I built a prototype using the
osgcandidate::VirtualProgram. Works well, but perfromancewise is not so
good, so waiting for the real thing.
-Nick


On Thu, Feb 25, 2010 at 4:27 AM, Chris 'Xenon' Hanson
xe...@alphapixel.comwrote:

  One of my clients is headed squarely into a place in their project where
 they need to do
 a lot of sophisticated shader work throughout the whole scenegraph.

  I was reading back along message history from January and I saw some
 mention of shader
 composition coming to OSG in an official manner relatively soon. With the
 stable release
 on the near roadmap, I was wondering if shader composition was now further
 down-road from
 the stable release or what the official plan was.

  I think there might be several people interested in working on this when
 it comes to the
 front of the queue. If anyone wants to register their interest, this might
 be a good time
 to chip in.

 --
 Chris 'Xenon' Hanson, omo sanza lettere  Xenon
 AlphaPixel.com
 PixelSense Landsat processing now available!
 http://www.alphapixel.com/demos/
 There is no Truth. There is only Perception. To Perceive is to Exist. -
 Xen
 ___
 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

[Robert Osfield]

Hi Nick,

On Sat, Jan 9, 2010 at 7:20 PM, Trajce Nikolov nikolov.tra...@gmail.com wrote:
 while ago you mentioned this is something upcoming. I am talking about
 composition of shaders in the osg core - something like the osg candidate
 virtual program. Any news about this?

I haven't dived back into work on shader composition yet.  Over the
Christmas break I did some pontificating on the issue of managing
large numbers of active light sources + associated shadows, and this
all pointed for the need for collecting lists of light source
contributing to the current view frustum and then dynamically
assigning GLSL programs + uniforms that fit this.  Such as scheme
really requires dynamic shader composition...

My plan is to clear my email back log, get a dev release out, complete
further work on lights+shadows in the OpenSceneGraph-Demos and then
dive back into shader composition.

Robert.
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org

[osg-users] shader composition

[Trajce Nikolov]

Hi Robert,

while ago you mentioned this is something upcoming. I am talking about
composition of shaders in the osg core - something like the osg candidate
virtual program. Any news about this?

Thanks
Nick

http://www.linkedin.com/in/tnick
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org

Re: [osg-users] shader composition

[Paul Martz]

I'm also interested. Just about to start using VirtualProgram intensely, 
with the hope that whatever the final solution is will be an easy port 
from VirtualProgram.


Paul Martz
Skew Matrix Software LLC
_http://www.skew-matrix.com_ http://www.skew-matrix.com/
+1 303 859 9466



Trajce Nikolov wrote:

Hi Robert,

while ago you mentioned this is something upcoming. I am talking about 
composition of shaders in the osg core - something like the osg 
candidate virtual program. Any news about this?


Thanks
Nick

http://www.linkedin.com/in/tnick




___
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