Hi Robert,
On 20 February 2015 at 11:27, Robert Milharcic <robert.milhar...@ib-caddy.si
> wrote:
> One could keep together related stuff, like lighting uniforms for lighting
> define, textures and uniforms if it happens to be texture define... Then,
> at the apply, one could for example multiply uniform with state's model
> view matrix or use any other information that osg::State has to offer. For
> example:
>
> class MaterialShaderDefine : public ShaderDefine
> {
> ...
};
>
This would no longer be a shader define, it'd be a whole separate
infrastructure. Shader define's are low level constructs like Uniforms
that provide a way of passing in data and controlling shaders.
What you are proposing is high level management of shader defines and
uniforms together.
>
> With old shader composer it is possible to do this by sub-classing
> ShaderAttribute. I also think that with ShaderDefine the define API would
> then be more consitent with other StateSet APIs:
>
> stateset->addUniform(Uniform*, StateAttribute::OverrideValue)
> stateset->setAttribute(StateAttribute*, StateAttribute::OverrideValue)
> stateset->setDefine(ShaderDefine*, StateAttribute::OverrideValue)
>
> BTW, I'm not suggesting here that ShaderDefine* should be internally keyed
> by pointer. Anyway, ShaderDefine is just an idea to be considered and
> nothing more.
>
I believe what you are looking forward is a way of wrapping up each the
setUniform/setAttribute/setDefine()'s required via a single object. It
might be that having a ShaderDefine class might be appropriate for
replacing the current using of std::pair's and std::maps, but it's rather
different beast than this combine state management.
It could be that ShaderAttribute/ShaderComponet still have a roll to play
in this high level management.
>
> 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.
>>>
>>
>> Perhaps osg::Program itself could be adapted to allow it to be easily
>> subclassed so that the shader selection, compilation and linking and
>> uniform/attribute setup could be managed by end users that wish to
>> subclass
>> from osg::Program. Another approach would be to defer this work to a
>> helper object that gets assigned to osg::State. Perhaps the
>> PerContexProgram/PerContextShader classes could have a role here in some
>> way.
>>
>> What I'd really need is a concrete example in front of me that illustrates
>> what functionality is needed but isn't possible. An example based on the
>> old osg::ShaderComposition would be fine.
>>
>> Unfortunately, I don't have short example that can illustrate what isn't
> possible. I'm attaching a complex example that shows old shader composer in
> action. The sources are for SVN revision 13962. Also, OSG_EXPERIMENTAL must
> be enabled in cmake. The point of interest is probably
> examples/osgshadercomposerhelper/ShaderComposer.cpp.
I have just unpacked the zip file, but am not sure yet what I'm going to be
looking at. These are mods that provide what functionality, what should I
be expecting the example to do?
Robert.
_______________________________________________
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
