Re: Postprocessing - binding shader variables

Thanks for the reply, the explanation for the N textures are
here<http://pedrossouza.blogspot.com.br/>,
in short it is because can be interdependence between posteffect's layers.


2013/7/1 Matthieu Kraus <[email protected]>

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

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