Re: Postprocessing - binding shader variables

Quoting Pedro Arthur <[email protected]>:

> I'm refactoring the texture allocation and the shader variable setup, as
> the reusable textures will be shared, them I moved the texture allocation
> to iPostEffectManager. So iPostEffectManager can share textures between
> iPostEffetc's. The iPostEffects only request N textures, assign it to each
> layer and link  a layer output to others layers input. When I tried to
> setup these inputs I did it in the "manual" way but it seems to not work
> properly.

Is there a reason you use N textures? Basically 2 sets of textures  
should be enough (layer 1 outputs to set 1 which is used as input by  
layer 2 outputting to set 2 which is used as input by layer 3  
outputting to set 1 ...).

> So if iShader is derived from iShaderVariableContext why the layer have
> both iShader and iShaderVariableContext? this implies that an  iShader can
> have/use multiple iShaderVariableContext? and how iShader knows which
> context to use?

As res already stated those SV contexts are pushed on a SV stack in  
some order which specifies which context takes priority over another  
for conflicts. This stack then contains the final set of SVs and their  
values which is passed to the shader when getting a ticket, activating  
passes, etc. The reason a shader itself is a SV context is that there  
may be variables defined in the shader itself as fallback in case they  
weren't specified somewhere else.

>
> 2013/7/1 res <[email protected]>
>
>> On 01.07.2013 02:56, Pedro Arthur wrote:
>> > I'm trying to properly bind the input textures to the posteffect's
>> > layer's shader, and I have some questions:
>> > What's the correct way to do that?
>>
>> See below.
>>
>> > What csShaderVariableStack does?
>>
>> This is a helper class to build the set of shader variables used for
>> rendering meshes:
>> Conceptually, you start off with an empty stack, and merge other
>> contexts onto the “front” or “back” of the stack. (Merging onto the
>> front means that an SV is used if no other is used yet; Merging onto the
>> back means a previously set SV is replaced.)
>> This system is used to implement the “order of preference” stated here:
>> http://crystalspace3d.org/docs/online/manual/Shader-System-Overview.html#9
>>
>> AFAICS in the post effects system there's a method that uses such a
>> stack is used to combine the SVs attached to a layer with other SVs that
>> provide input textures (PostEffect::GetLayerRenderSVs()), but apparently
>> this method is only used by the HDR stuff.
>>
>> The collection of SVs for “generic” post-effect rendering is done by
>> DimensionData::UpdateSVContexts(). There, the layer SV context is used
>> as a base for an “overlay” SV context (a special implementation that
>> adds SVs on top of the base SV without modifying it), and the automatic
>> inputs are “overlaid”.
>>
>> That said,
>> - You could add your SV to the layer SV context. (Note however this SV
>> context is mainly intended for user-provided SVs, overriding these with
>> predefined/automatic SVs isn't that nice.)
>> - You could add your SVs “manually” the same way as done in
>> UpdateSVContexts().
>>
>> Note that piling more SVs onto the end of UpdateSVContexts() probably
>> wouldn't improve it's readability. Also, it's a bit unfortunate that
>> both GetLayerRenderSVs() and UpdateSVContexts() seem to have some
>> overlapping functionality. Maybe you can find time for a little
>> refactoring here...
>>
>> -f.r.
>>
>>
>>
>> ------------------------------------------------------------------------------
>> This SF.net email is sponsored by Windows:
>>
>> Build for Windows Store.
>>
>> http://p.sf.net/sfu/windows-dev2dev
>> _______________________________________________
>> Crystal-develop mailing list
>> [email protected]
>> https://lists.sourceforge.net/lists/listinfo/crystal-develop
>>
>>




------------------------------------------------------------------------------
This SF.net email is sponsored by Windows:

Build for Windows Store.

http://p.sf.net/sfu/windows-dev2dev
_______________________________________________
Crystal-develop mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/crystal-develop