Hi, Robert,
I am not actively working with any code which would require shader
composition at the moment but I saw few such efforts in various projects in
the past, so I am really glad OSG is going to implement own scheme and
users will not need to invent the wheel anymore ;-). As someone only mildly
interested in the topic at the moment I only briefly looked at new shadow
composition example, and have only one question.
I noticed that we may add/override parts of shader code using setDefine(
"USER_FUNC(args)" ) as in your example:
stateset->setDefine("VERTEX_FUNC(v)" , "vec4(v.x, v.y, v.z *
sin(osg_SimulationTime), v.w)");
But I feel that this solution may be inadequate for large blocks of shader
code which used would want linked instead of being effectively merged with
parent "Ubershader" program. Do you have a method or anticipate that such
method can be added, which would allow to add or override whole shaders in
effective Program applied to OpenGL context ? Something that
ShaderAttribute was supposed to do in former ShaderComposition scheme ? For
example whould this be possible to replace whole lighting.vert shader from
your example with entirely different shader doing own lighting at some
subnode and its StateSet ?
Cheers and Thank you for your Effort,
Wojtek Lewandowski
2015-02-19 11:22 GMT+01:00 Sebastian Messerschmidt <
sebastian.messerschm...@gmx.de>:
> Hi,
>
>> Hi Robert,
>>
>> I was amazed by the simplicity of the new pragmatic shader composition -
>> but yet it is so powerful. Well done! So, I was making good progress
>> porting old shader composition code to pragmatic one until I hit the wall.
>> The problem is, I don't see any obvious way to extend the current pragmatic
>> shader composition API. If I may, I would suggest two things for
>> consideration:
>>
>> 1. Add a new layer of abstraction for StateSet's define API, lets say
>> class object ShaderDefine that we can subclass. The ShaderDefine (or any
>> other suitable name) would contain std:string _defineName, std::string
>> _defineValue and at least a less operator, since you are inserting
>> definition into map, and virtual void apply(State&) const {}. Of course,
>> the apply would then be called from State::applyDefineList() giving the
>> user an opportunity for define's customization. So the new
>> StateSet::setDefine() would look something like this:
>> setDefine(ShaderDefine*, StateAttribute::OverrideValue);. Also, with the
>> proposed abstraction it would be easier to write serialization support.
>>
>> 2. The greatest strength of old shader composer is
>> ShaderComposer::getOrCreateProgram().
>> As others have already mentioned, this is the point where we used to gain
>> control over the program composition. I'm personally using this control
>> point for things like program->addBindAttribLocation/
>> addBindFragDataLocation/addBindUniformBlock and for some other sanity
>> checks. It would be great if we can somehow install a callback or overload
>> some member to regain the control of the program composition.
>>
> I second this, as I've just stumbled upon the same use case. Maybe there
> is some other way around this, but I too need some control over the finally
> created program.
>
>
>
>
>> Robert Milharcic
>> _______________________________________________
>> osg-users mailing list
>> osg-users@lists.openscenegraph.org
>> http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
>>
>
> _______________________________________________
> osg-users mailing list
> osg-users@lists.openscenegraph.org
> http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
>
_______________________________________________
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
