Shader Abstractions
Author
Is it me or is it Tom Forsyth's shader abstraction in ShaderX2 (and GDC 2007) and pluggable shaders from Material/Shader implmentation thread very similar?
How do you guys abstract shaders these days? can we resurrect the discussion of shader integration & shader/material system design.
I think the majority of people on these boards probably go for some variation on either the D3D Effects system or Yann Lombard's system.
In Yann's system I personally didnt like all the meta-processing that seems to happen to connect things together, when i say i didnt like it i mean it is of course very clever but i didnt fancy coding it up [smile]. Im therefore hopefully heading for a happy medium between yanns material/shader system and a variation on the D3D effects system whereby the effects & techniques will need to be referencing shaders loaded from a DLL unlike actual D3D Effects where a pass is coded directly in there.
Actually with Yanns system im not convinced it ought be the shaders responsibility to upload data into the VRAM cache, ive been considering changing this im just not sure how yet.
Im thinking that shaders could register their data requirements with some VRAM cache uploader which in theory could perform some optimisations if it knows the requirements off all shaders (like sharing the same cache slot between different shaders if it knows it is safe to do so, i.e. the data requirements are the same, the vertices themselves will be the same between the two different shaders and neither shader will modified/dirty the vertices in the cache).
In Yann's system I personally didnt like all the meta-processing that seems to happen to connect things together, when i say i didnt like it i mean it is of course very clever but i didnt fancy coding it up [smile]. Im therefore hopefully heading for a happy medium between yanns material/shader system and a variation on the D3D effects system whereby the effects & techniques will need to be referencing shaders loaded from a DLL unlike actual D3D Effects where a pass is coded directly in there.
Actually with Yanns system im not convinced it ought be the shaders responsibility to upload data into the VRAM cache, ive been considering changing this im just not sure how yet.
Im thinking that shaders could register their data requirements with some VRAM cache uploader which in theory could perform some optimisations if it knows the requirements off all shaders (like sharing the same cache slot between different shaders if it knows it is safe to do so, i.e. the data requirements are the same, the vertices themselves will be the same between the two different shaders and neither shader will modified/dirty the vertices in the cache).
Quote:Original post by dmatter
Actually with Yanns system im not convinced it ought be the shaders responsibility to upload data into the VRAM cache, ive been considering changing this im just not sure how yet.
Im thinking that shaders could register their data requirements with some VRAM cache uploader which in theory could perform some optimisations if it knows the requirements off all shaders (like sharing the same cache slot between different shaders if it knows it is safe to do so, i.e. the data requirements are the same, the vertices themselves will be the same between the two different shaders and neither shader will modified/dirty the vertices in the cache).
I'm working on implementing a system pretty much like this to get reuse of vertex components, and to better support interleaved data. It is not done yet, but it is pretty much like you describe - each shader can be queried for its component requirements and the VRAM write/uploader handles the details of setting up the format and writing to VRAM slots.
The only downside I can think of with this is a more complex implementation, and you loose a bit of the nice and simple modularity of the original shaders.
..but as I said, its not done yet so I'm not sure if there could be unforseen problems.
I am currently implementing a shader system similar to Yann L's,
except for a few things
here is how the shader definitions will look like
the blend_four_layers_parallax is provided by a parallax shader dll which actually implements may tiny sub shader parts, so you can combine the shader sources at loadtime and do as much as possible in one single pass
note the vertex_format, resources are stored with the maximum information and at load time I decide with components to load, you don t need the tbn if you don t do normal mapping and such things for example
the shader class receives a lightmodel instance during setup to extract the light model shader code
...
some glsl
...
<lightmodelcode>
...
following a convention you can simply combine it, as long as all the data is available before the pass, e.g.: shader map generation ...
[Edited by - Basiror on May 13, 2007 12:51:46 PM]
except for a few things
here is how the shader definitions will look like
1 textures/stalingrad/stalingrad_ground1 2 { 3 vertex_shader "default" 4 pixel_shader "blend_four_layers_parallax" 5 vertex_format "v_n_t_b_uv4_para" 6 map0 textures/common/bark 7 param0 texture_mag_filter linear 8 param0 texture_min_linear linear_mipmap_linear 9 param0 texture_wrap_s repeat 10 param0 texture_wrap_t repeat 11 map1 textures/common/mud 12 map2 textures/common/rough 13 map3 textures/common/caulk 14 15 //material properties 16 ambient 0.8 0.7 0.6 17 diffuse 0.8 0.7 0.6 18 emission 0.8 0.7 0.6 19 shininess 0.8 20 21 //physic parameters such as bounciness ... 22 physic_material "materialname" 23 24 //callback setup 25 on_bullethit "<bullethandler>" 26 } 27 28 textures/common/bark 29 { 30 vertex_shader "default" 31 pixel_shader "blend_four_layers_parallax" 32 vertex_format "v_n_t_b_uv4_para" 33 map0 textures/common/bark 34 35 //physic parameters 36 physic_material "materialname" 37 38 //callback setup 39 on_bullethit "<bullethandler>" 40 }the blend_four_layers_parallax is provided by a parallax shader dll which actually implements may tiny sub shader parts, so you can combine the shader sources at loadtime and do as much as possible in one single pass
note the vertex_format, resources are stored with the maximum information and at load time I decide with components to load, you don t need the tbn if you don t do normal mapping and such things for example
the shader class receives a lightmodel instance during setup to extract the light model shader code
...
some glsl
...
<lightmodelcode>
...
following a convention you can simply combine it, as long as all the data is available before the pass, e.g.: shader map generation ...
[Edited by - Basiror on May 13, 2007 12:51:46 PM]
as for the light model, its seperated into several steps
e.g.:
lightmodel:
shadow pass
reflection pass
runtime pass
post processing pass
anti alias pass
....
so the whole rendering is controlled by a light model instance, which offers several passes,
the runtime pass is the core pass where everything is combined to produce the final image
the "post" and "anti alias" passes are used for deffered shading implementations
as you see here the light model also takes care about passing information other than vertex data & shader texture maps to the runtime pass,
it is responsible to bind the correct shadow map, the right reflection map ...
the other advantage of the light model abstraction is that you can make it modifiable easily, e.g.: to implement the graphics option menu ...
plus it seperates the highly flexible shader part from the more or less steady passes such as
- environment map generation
- liminance extraction from environment maps
- shadow map algorithms
- reflection algorithms
the later ones change very seldom, while other technices change with every gpu generation
the order of combination of shader code is defined by the light model since it is responsible to deliver the required data
e.g.:
lightmodel:
shadow pass
reflection pass
runtime pass
post processing pass
anti alias pass
....
so the whole rendering is controlled by a light model instance, which offers several passes,
the runtime pass is the core pass where everything is combined to produce the final image
the "post" and "anti alias" passes are used for deffered shading implementations
as you see here the light model also takes care about passing information other than vertex data & shader texture maps to the runtime pass,
it is responsible to bind the correct shadow map, the right reflection map ...
the other advantage of the light model abstraction is that you can make it modifiable easily, e.g.: to implement the graphics option menu ...
plus it seperates the highly flexible shader part from the more or less steady passes such as
- environment map generation
- liminance extraction from environment maps
- shadow map algorithms
- reflection algorithms
the later ones change very seldom, while other technices change with every gpu generation
the order of combination of shader code is defined by the light model since it is responsible to deliver the required data
This topic is closed to new replies.
Advertisement
Popular Topics
Advertisement
