Hello Gerrit,
thanks for the explanations.
Gerrit Voß wrote:
> On Wed, 2010-01-27 at 18:42 -0600, Carsten Neumann wrote:
>> Anyway, given the 'limitations' of the SVarChunk I now have a bit of
>> trouble seeing what it is good for, i.e. when would it make sense to use
>> one instead of keeping the variables directly on the SProgChunk?
>
> hmm if you want to have the same shader with different variable values,
> e.g. you have some fancy shader and want to color some objects red and
> some green. If you have hundreds of these you don't want to create a new
> shader object for each instance but reuse the same shader object with
> different variable values (ok for those that don't come down through
> OpenGL).
yes, essentially the "shader change" should be a bunch of glUniform
calls that update variable values. Not sure if the scenario is overly
common and the more I understand this the more I get the impression that
supporting uniform buffers is the better solution in this case anyway.
>> Ah, we can not have variables on the SProgChunk only on the
>> ShaderProgram objects, why is that?
>>
>> Would it make more sense to allow variables on SProgChunk (and SProgram)
>
> ?? I kept the variables with the individual programs, e.g. ShaderProgram
> contains a variable store and the interface to set/get uniform
> variables. So you collect them with the program and not with the chunk.
yes, they are in the ShaderProgram, but if I have a vertex and a
fragment shader that both access the same uniform, do I have to set it
either on both ShaderPrograms? For that case it would make more sense to
me if I could just set it on the ShaderProgramChunk that holds the two
programs.
Or does the merging imply that I only have to set a uniform on one
ShaderProgram and it is available to all others that get linked into the
same ShaderProgramChunk? Example:
vp = ShaderProgram::createVertexShader();
fp = ShaderProgram::createFragmentShader();
sh = ShaderProgramChunk::create();
// set code for vp/fp
vp->addUniformVariable("sunPos", Vec3f(x,y,z));
sh->addShader(vp);
sh->addShader(fp);
// does fp have access to sunPos?
// or do I need this:
fp->addUniformVariable("sunPos", Vec3f(x,y,z));
> They are merged as the programs are merged. Argg I still have to fix the
> override strategies that might also be the reason why they aren't in the
> chunk.
hm, fixing the overrides would be awesome :)
>> At least that would avoid the pitfall of attempting to share SVarChunks.
>
> Yes, the problem is that in 1.x it was clear due to the direct
> ShaderChunk reference inside SVarChunk. As an optimization I took this
> out (1.x tended to activated the shader twice IIRC) this connection
> is less clear.
>
> Let me see if I can change things so that the SVarChunk works in
> both scenarios.
to be clear, this was just something I stumbled upon, it's not critical
for anything here. So if there is a choice between fixing this and the
override behaviour, the overrides get my vote ;) ;)
Cheers,
Carsten
------------------------------------------------------------------------------
The Planet: dedicated and managed hosting, cloud storage, colocation
Stay online with enterprise data centers and the best network in the business
Choose flexible plans and management services without long-term contracts
Personal 24x7 support from experience hosting pros just a phone call away.
http://p.sf.net/sfu/theplanet-com
_______________________________________________
Opensg-core mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/opensg-core
