Re: Postprocessing - binding shader variables

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


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