Effect System
From Entropia
Contents |
[edit] Effect Definition
Effect definition describes how a material is supposed to look like, as well as inputs that are available for rendering it. Best way to get an idea is probably some example :
- Bump mapping
- Possible implementations could be :
- Bump mapping with shadow mapping
- Bump mapping without shadow mapping
- Parallax mapping
- Cone step mapping
- simple texture rendering (fallback for old hardware).
- Variables inputs would be something like :
- World matrix
- View matrix
- Proj matrix
- Texture
- Bump Texture
- Possible implementations could be :
[edit] IEffect and IEffectPass
An IEffect object describes the rendering passes necessary to render geometry. It respects the contract of its associated Effect Definition. It is composed of a list of IEffectPass.
An IEffectPass object executes custom action, typically geometry drawing with a given rendering pipeline (this later case will now be studied, but keep in mind that an IEffectPass can do anything as its functions could be overridden).
IEffectPass are implementation specific : their input variables usually depends of the real programmable pipeline that has been compiled for this pass.
As an example, single texturing would take WorldViewProj matrix and a texture (bound as a shader resource). Shadow mapped bump mapping would generate two IEffectPass, one of them needing WorldView, WorldViewProj, LightWorldViewProj, a shadow map, as well as some fixed float variables.
Of course, one could notice that the main issue would be that IEffectPass are implementation dependant whereas IEffect should fill a given input variables contract. That's why IEffect are also responsible of setting up IEffectPass variables from their own input variables (or any other possible source). They could also assign constants as well as expression to IEffectPass variables.
As a result, programmers manipulates implementation independent geometry while still allowing extensible data-driven inputs, and it will get bound to the right variables in the IEffectPass implementation objects.
[edit] Constant buffers, variable sharing and instancing
Inputs variables are defined by groups both at the IEffect and at the IEffectPass level. That allows variable sharing with group granularity.
In case a group at the IEffectPass level is bound to variables that defines complete groups at the IEffectPass level, an interesting optimization is possible : IEffect to IEffectPass variable binding could detect that and create fixed constant buffers for IEffectPass variables.
Also, as the Render function of IEffectPass takes an enumerator of geometry, if instancing is enabled for a specific IEffectPass variable group and that geometries share other variable groups, the rendering function could fill an instancing constant buffer from content of the variable group.
As a result, with this architecture, we're given for free constant buffers, variable sharing across multiple geometries and instancing, in a transparent way for the user ! There is only one path for instancing and non-instancing rendering.
[edit] Geometry and GeometryPass
Geometry are associated an IEffect and are composed of GeometryPass which are themself associated with IEffectPass of the IEffect.
