RT Shader System Component (RTSS)

Discussion area about developing or extending OGRE, adding plugins for it or building applications on it. No newbie questions please, use the Help forum for that.

RT Shader System Component (RTSS)

Postby Nir Hasson » Thu Aug 27, 2009 12:29 pm

Hi –

In the last few weeks I've been working on a runtime shader system component. (RTShader System).
The need for such a system comes from the demand to reduce the amount of work needed by writing many shader programs for each material in my system.

Another issue I had to tackle is that some components in my application generate materials during the runtime, so the actual shader code of these materials is not predictable and therefore I can't write an appropriate shader programs in advance.

The main goals for this system are –
1.Be able to take an existing Technique and create an equivalent technique that goes thru shader rendering pipeline.
I.E – In case you're application base content composed of many materials that rendered only with the FFP and you want them all to be rendered with shader programs, the RTShader System will allow you doing so without writing single line of shading code.
2.Be able to extend the system beyond the core implementation of the fixed function pipeline.
I.E adds per pixel lighting support for all the material in the system, or basically any shader based effect.

Possible future uses of this component are:
1.Seamlessly support shader based render system such as D3D10 and OpenGL ES 2.0.
2.Implement visual shader editor that will enable to artist with zero knowledge in shading languages to create shader based materials.

The RT Shader System component composed of the following interface:
1.ShaderGenerator – this is a singleton class that enables the creation of shader based technique for a given material.
2.RenderState – this class use to define a complete set of rendering states from which one can create a set of shader programs.
3.SubRenderState – this class is abstract interface for detailed sub part of render state. Each sub state of render state should derive from it and implement the pure methods it declares. The RTShader System contains sub class implementation for all Fixed Function Pipeline sub components: FFPTransform, FFPLighting, FFPTexturing, FFPColour and FFPFog.
4.ProgramWriter – singleton class that perform the actual conversion from a CPU shader program classes to
GPU programs.

In order to create shader based technique for specific material one should call the ShaderGenerator::createShaderBasedTechnique and pass to it the name of the material, name of the source technique scheme and name of the destination technique scheme name.
In case of success, a new technique will be created in this material and it will be using shader programs that will emulate the exact behavior of the source technique as if rendered using the fixed pipeline.
In order to use the new technique, one can simply change to material scheme name of the viewport(s) he uses and then the internal mechanism of Ogre will automatically choose the appropriate technique to use during the rendering process.

In order to use shader based effect one should be familiar with the concept of RenderState and SubRenderState classes, then implement the desired effect by creating new sub class of SubRenderState and finally apply this custom render state either to the whole scheme or just for specific material.

The basic concept that stands beyond the shader code generation is to use a set of predefined shader functions and link them together by need at runtime by the render state definition.
The RT Shader System comes with set of shader libraries that contains implementation of the Fixed Function Pipeline:
FFPLib_Common.cg , FFPLib_Transform.cg, FFPLib_Lighting.cg , FFPLib_TextureStage.cg, FFPLib_Fog.cg.

Currently the system supports only CG as target shader language.
In order to support other languages we'll have to port these libraries to the desired shading language. This can be useful for situations where CG shader code is not enough.

In order to compile and use the RT Shader System one should define the OGRE_BUILD_COMPONENT_RTSHADERSYSTEM option as TRUE in the CMakeLists.txt file under the root folder of the source code.
I personally use the CMake GUI application to do that.
Then the OgreRTShaderSystem project is added to the Ogre solution and basic demonstration code is added to the basic demo's framework.
On each sample that uses this framework pressing the F3 Key will cause to every material in the scene to be rendered using a shader based technique and pressing the F2 key will switch back to default material behavior.

Future work Steps –
1.Add common shading effects implementation to the system - per pixel lighting, bump map, etc.
2.Integrate to D3D10 render system.
The RTShader System is not aware of the vertex declaration while it generates the shader code and therefore it may result in creating functions prototype that doesn’t fit the incoming vertex streams.
In order to integrate with D3D10 render system a bridge layer should be implemented to overcome the strict demand of 1 to 1 matching between vertex declaration and shader entry point prototype. This layer will simply add adapter entry function that matches the vertex declaration and it will call the original function with the appropriate parameters adjustments.
BTW – During the integration with the samples I found a crash in the OgreMain module caused by using NULL pointer, it is in the OgreMovableObject.cpp in MORecvShadVisitor::visit method that reference a Renderable object technique without checking its value.

The RTSahder System patch can be found here
https://sourceforge.net/tracker/?func=detail&aid=2845510&group_id=2997&atid=302997
The MovableObject crash fix patch can be found here
https://sourceforge.net/tracker/?func=detail&aid=2845402&group_id=2997&atid=302997

I'll keep updating my progress later on…
Last edited by Nir Hasson on Sun Aug 30, 2009 9:20 am, edited 2 times in total.

For this message the author Nir Hasson has received 2 kudos
User avatar
Nir Hasson
OGRE Retired Team Member
OGRE Retired Team Member
 
Posts: 363
Kudos: 2
Joined: 05 Nov 2008
Location: TLV - Israel

Re: RT Shader System Component

Postby CABAListic » Thu Aug 27, 2009 6:23 pm

There were a few minor things which needed to be changed so that the patch compiles on Linux, I have attached an updated version of the patch. However, the generator doesn't quite seem to work. When I press F3 in either of the samples, I get the following error:
Code: Select all
An exception has occured: OGRE EXCEPTION(2:InvalidParametersException): Could not create gpu programs from render state  in ProgramManager::acquireGpuPrograms at /home/cabal/programming/ogre/sources/trunk/Components/RTShaderSystem/src/OgreShaderProgramManager.cpp (line 108)


Also, I think it might be better to create a dedicated sample for the component instead of hooking it into all the samples.
Attachments
RTShaderGenerator.zip
(57.7 KiB) Downloaded 359 times
CABAListic
OGRE Retired Team Member
OGRE Retired Team Member
 
Posts: 2902
Kudos: 59
Joined: 18 Jan 2007

Re: RT Shader System Component

Postby Assaf Raman » Thu Aug 27, 2009 6:32 pm

Does it work for you on windows?
Watch out for my OGRE related tweets here.
User avatar
Assaf Raman
OGRE Team Member
OGRE Team Member
 
Posts: 3092
Kudos: 78
Joined: 11 Apr 2006
Location: TLV, Israel

Re: RT Shader System Component

Postby CABAListic » Thu Aug 27, 2009 6:34 pm

Don't know. I can try next time I'm booting Windows.
CABAListic
OGRE Retired Team Member
OGRE Retired Team Member
 
Posts: 2902
Kudos: 59
Joined: 18 Jan 2007

Re: RT Shader System Component

Postby Nir Hasson » Thu Aug 27, 2009 7:38 pm

Thanks for the fixes CABAListic -
I don't have Linux environment so I couldn’t test it..
It will be kind of you if you can provide more details regarding the exception you mentioned earlier. My guess is that the given cache path of the shader system is not valid under the Linux deployment and so the actual writing the shader programs to a file failed and you get this exception. I can refer you to the Program Manager interface, you’ll see there the attempt to write to a file. If you can check this place for me and send the result it would be great so I could fix it for Linux users.
User avatar
Nir Hasson
OGRE Retired Team Member
OGRE Retired Team Member
 
Posts: 363
Kudos: 2
Joined: 05 Nov 2008
Location: TLV - Israel

Re: RT Shader System Component

Postby Noman » Fri Aug 28, 2009 4:00 pm

I get the same exception as well, it seems to be because the cachePath is not set up correctly.

Since CMake sets up the following directory structure as default (when the source path and build path are the same) :

Code: Select all
<OgreRoot>
   bin
      debug
      release
   Samples
      Media
      ...


The root dir is only two levels above the default, while the code in ExampleFrameListener.h assumes three levels. (I assume your cmake setup put the build path in a subdirectory called 'build' or something similar?)
Changing the code from this :

Code: Select all
         // Set shader cache path.
         mShaderGenerator->setShaderCachePath("../../../Samples/Media/RTShaderLib/");   
            
         // Create and register the material manager listener.
         mMaterialMgrListener = new ShaderGeneratorTechniqueResolverListener(mShaderGenerator);            
         MaterialManager::getSingleton().addListener(mMaterialMgrListener);

         // Add resource location for the core shader lib.
         ResourceGroupManager::getSingleton().addResourceLocation("../../../Samples/Media/RTShaderLib", "FileSystem");               


To this
Code: Select all
         // Set shader cache path.
         mShaderGenerator->setShaderCachePath("../../Samples/Media/RTShaderLib/");   
            
         // Create and register the material manager listener.
         mMaterialMgrListener = new ShaderGeneratorTechniqueResolverListener(mShaderGenerator);            
         MaterialManager::getSingleton().addListener(mMaterialMgrListener);

         // Add resource location for the core shader lib.
         ResourceGroupManager::getSingleton().addResourceLocation("../../Samples/Media/RTShaderLib", "FileSystem");               


Fixed the problem.
After this change, the demos work cleanly here (on windows).

However, this points to the real problem - the code assumes something about the build environment, instead of taking this path from a configuration file (from resources.cfg or whatever) which should be set up by the CMake build system...

However, the good news is that besides this issue the code works flawlessly. Tried a few samples and they were pixel perfect. Great stuff!
User avatar
Noman
OGRE Retired Team Member
OGRE Retired Team Member
 
Posts: 714
Kudos: 2
Joined: 31 Jan 2005
Location: Israel

Re: RT Shader System Component

Postby Nir Hasson » Fri Aug 28, 2009 5:17 pm

Thanks for that observation –
The actual usage of the cachePath is to provide a folder that the application can write into, so in future runs it will use shaders that already written to that folder instead of writing the actual file.
However the resource location of the core FFP libraries is different issue - the system will fail to generate valid shading code if it is not set properly – I guess I’ll add it to the resources.cfg, probably as zip file and it will do the work.
I agree that it should not be depend on the folder structure, so I’ll try to find some sort of generic solution and submit it in the next patch update…. :)
User avatar
Nir Hasson
OGRE Retired Team Member
OGRE Retired Team Member
 
Posts: 363
Kudos: 2
Joined: 05 Nov 2008
Location: TLV - Israel

Re: RT Shader System Component

Postby Nir Hasson » Sun Aug 30, 2009 9:22 am

I just updated the patch in the tracker -
It includes now the Linux fixes made by CABListic and the demos framework fixes suggested by Noman.
Thanks for your help guys..
User avatar
Nir Hasson
OGRE Retired Team Member
OGRE Retired Team Member
 
Posts: 363
Kudos: 2
Joined: 05 Nov 2008
Location: TLV - Israel

Re: RT Shader System Component

Postby Nir Hasson » Tue Sep 01, 2009 7:57 am

Yesterday I added the first core custom shader extension to the RT Shader System – A Custom per pixel lighting sub render state. It was the first test case which proofed that the system is really extendable. Beside minor changes in the interface of the SubRenderState class all it took was to sub class the SubRenderState interface with per pixel implementation.
I also extended the sample frame work application to allow third material scheme in which all custom shader extension will be tested.
The bottom line is that now I can switch the lighting model of ALL ogre samples with a single key press!!! .
No matter how many lights in the scene, what kind of lights, what texture blends or effects are or whatever other material properties exists the RT Shader System builds for you a matching shader. Just imagine how much time it would take you to port all Ogre samples FFP based materials to be rendered with per pixel light model....
I attached here screen shots from the RenderToTexture demo which I modified a bit - I added another point light to the scene and changed the material specular related properties.

This is the scene rendered with the default RT Shader System scheme which emulates the FFP completly.
RTSS_FFP_1.jpg
RT Shader System - FFP Light model emulation
RTSS_FFP_1.jpg (108.74 KiB) Viewed 17050 times


This is the scene rendered with a custom RT Shader System scheme which includes Per Pixel Lighting model.
RTSS_PerPixel_2.jpg
RT Shader System - PerPixel Light model emulation
RTSS_PerPixel_2.jpg (111.5 KiB) Viewed 17050 times


Will keep update...
User avatar
Nir Hasson
OGRE Retired Team Member
OGRE Retired Team Member
 
Posts: 363
Kudos: 2
Joined: 05 Nov 2008
Location: TLV - Israel

Re: RT Shader System Component

Postby xadhoom » Tue Sep 01, 2009 8:41 am

Hi Nir!

Does this RT Shader System Component create shader code "on the fly" depending on the configuration?
Typical question would then be: How about the performance of these shaders? And how adaptive is this system to meet requirements like e.g. using Fresnel/Cell shader or deferred shading?

xad
User avatar
xadhoom
Minaton
 
Posts: 973
Kudos: 2
Joined: 28 Dec 2007
Location: Germany

Re: RT Shader System Component

Postby Nir Hasson » Tue Sep 01, 2009 9:03 am

Hi xadhoom !

Does this RT Shader System Component create shader code "on the fly" depending on the configuration?

The answer is yes.. It does it by assembling set of predefined shader functions into a matching vertex and pixel shaders.
How about the performance of these shaders?

As my previous answer suggests - it is completely depends on the predefined functions you write in advance and of course on the shader compiler itself.
Although I didn't get deep into this field yet, I did some tests when writing the FFP lighting model and compared the generated shaders to hand written tailored made shaders and the compiler did excellent job - they both ended with the same instruction set.
I guess there is a lot of testing to do in this field of optimizing the core FFP shader library - I'll get into it in the future.

And how adaptive is this system to meet requirements like e.g. using Fresnel/Cell shader or deferred shading?

One of the main goals was to allow this system to be extendable and not just act as FFP emulator.
At this point I'm implementing set of extensions for it and see how it really works. As I wrote before - the per pixel lighting implementation passed almost smoothly. For the next days I plan to implement a PSSM shadow receiver custom sub render state as external library class - I want it to specific project and also to see how third party application can use and extend the system.
So the bottom line is that the system is adaptive (at least suppose to be :D ).
I guess the best way to advance is that I'll implement some more custom sub render state and when it will be in a stage that it works fine I'll submit a new patch that includes all of this stuff....
User avatar
Nir Hasson
OGRE Retired Team Member
OGRE Retired Team Member
 
Posts: 363
Kudos: 2
Joined: 05 Nov 2008
Location: TLV - Israel

Re: RT Shader System Component

Postby iloseall » Thu Sep 03, 2009 2:09 am

One of the main goals was to allow this system to be extendable and not just act as FFP emulator.


Great. I like the RT Shader System although My project don't use FFP.
In my project, I use a lua script to create Ogre Material from a Material template( option set , like g_EnableNormal=true export from max).
I Make a macro define list for the program to custom the shader when create material.
I use a lot of Macro define in Shader Files! that is very ugly.
User avatar
iloseall
Gremlin
 
Posts: 160
Kudos: 0
Joined: 14 Sep 2003
Location: Beijing China

Re: RT Shader System Component

Postby Nir Hasson » Thu Sep 03, 2009 4:01 pm

Great. I like the RT Shader System although My project don't use FFP.


Thanks for that - I guess you mean that you don't use the whole FFP as it is only parts of it - most likely the texture coordinates processing and even texture sampling and blending.
The RT Shader System gives you the option to override any part of the FFP as well as adding new custom stages.
My current work in progress is integrating it into larger project I’m working on, testing it in different scenarios (multi threading, large scale usage etc..) and implementing some other custom shader extensions like PSSM receiver, normal map etc.
I hope to upload a second patch that will include all of this stuff as well as bug fixes in the next week.

I Make a macro define list for the program to custom the shader when create material.
I use a lot of Macro define in Shader Files! that is very ugly.


From my experience with defined based systems - they finally become huge, non-extendible and generally a nightmare for maintaining.
I hope that many users will find this system useful and help improving it in the future…
User avatar
Nir Hasson
OGRE Retired Team Member
OGRE Retired Team Member
 
Posts: 363
Kudos: 2
Joined: 05 Nov 2008
Location: TLV - Israel

Re: RT Shader System Component

Postby Vectrex » Thu Sep 10, 2009 12:19 pm

Just to clarify, would this be used in a case like ours where our uber-shader has loads of #ifdefs and it's getting harder to 'insert' new abilities without problems? Eg organising texcoords etc. Basically like how crysis has small chunks of fairly normal looking shader code which it then compiles seperate shaders for each material using combinations of the small chunks?
Vectrex
Troll
 
Posts: 1354
Kudos: 1
Joined: 12 Aug 2003
Location: Melbourne, Australia

Re: RT Shader System Component

Postby Nir Hasson » Thu Sep 10, 2009 1:00 pm

I'll try to clarify it –
It is NOT going to be another Uber shader mainly because the reason you mentioned.
The heart of the system is the ability to create and bind all sorts of shader program parameters like uniform, input, output and local parameters and use them as needed.
It is based on small pieces of shader code, which their functions prototype is known to the components that going to use it. During the program runtime the RT Shader System use this knowledge and tail a specific shader using these libraries. The actual implementation is to add the relevant #include directives of each library to the shader and of course create and send the relevant parameters as needed. Another important issue is the execution order of each function group. I defined special enums for that purpose –
// Fixed Function vertex shader stages.

Code: Select all
enum FFPVertexShaderStage
{
   FFP_VS_PRE_PROCESS               = 0,   
   FFP_VS_TRANSFORM               = 100,
   FFP_VS_COLOUR                  = 200,
   FFP_VS_LIGHTING                  = 300,
   FFP_VS_TEXTURING               = 400,      
   FFP_VS_FOG                     = 500,   
   FFP_VS_POST_PROCESS               = 2000,
};


That way one can add custom shader code in the relevant stage he needs.
Here is simple vertex shader that generated by this system for the overlay material-

Code: Select all
//-----------------------------------------------------------------------------
// Program Name: 573154384_VS
// Program Desc: Vertex Shader Program
// Program Type: Vertex shader
// Language: cg
// Created by Ogre CRT Shader Generator. All rights reserved.
//-----------------------------------------------------------------------------

//-----------------------------------------------------------------------------
//                         PROGRAM DEPENDENCIES
//-----------------------------------------------------------------------------
#include "FFPLib_Transform.cg"
#include "FFPLib_Common.cg"
#include "FFPLib_Texturing.cg"

//-----------------------------------------------------------------------------
//                         GLOBAL PARAMETES
//-----------------------------------------------------------------------------

float4x4   worldviewproj_matrix;

//-----------------------------------------------------------------------------
// Function Name: main
// Function Desc: Program Entry point
//-----------------------------------------------------------------------------
void main
   (
    in float4   iPos_0 : POSITION0,
    in float2   iTexcoord2_0 : TEXCOORD0,
    out float4   oPos_0 : POSITION0,
    out float2   oTexcoord2_0 : TEXCOORD0
   )
{
   float4   lDiffuse;
   float4   lSpecular;

   FFP_Transform(worldviewproj_matrix, iPos_0, oPos_0);

   FFP_Construct(1.0, 1.0, 1.0, 1.0, lDiffuse);

   FFP_Construct(0.0, 0.0, 0.0, 0.0, lSpecular);

   FFP_Assign(iTexcoord2_0, oTexcoord2_0);
}


And the pixel shader is –
Code: Select all

//-----------------------------------------------------------------------------
// Program Name: 573154384_PS
// Program Desc: Fragment Shader Program
// Program Type: Fragment shader
// Language: cg
// Created by Ogre CRT Shader Generator. All rights reserved.
//-----------------------------------------------------------------------------

//-----------------------------------------------------------------------------
//                         PROGRAM DEPENDENCIES
//-----------------------------------------------------------------------------
#include "FFPLib_Common.cg"
#include "FFPLib_Texturing.cg"

//-----------------------------------------------------------------------------
//                         GLOBAL PARAMETES
//-----------------------------------------------------------------------------

sampler2D   gTextureSampler0 : register(s0);

//-----------------------------------------------------------------------------
// Function Name: main
// Function Desc: Program Entry point
//-----------------------------------------------------------------------------
void main
   (
    in float2   iTexcoord2_0 : TEXCOORD0,
    out float4   oColor_0 : COLOR0
   )
{
   float4   lDiffuse;
   float4   lSpecular;
   float4   texel;
   float4   source1;
   float4   source2;

   FFP_Construct(1.0, 1.0, 1.0, 1.0, lDiffuse);

   FFP_Construct(0.0, 0.0, 0.0, 0.0, lSpecular);

   FFP_Assign(lDiffuse, oColor_0);

   FFP_SampleTexture(gTextureSampler0, iTexcoord2_0, texel);

   FFP_Assign(texel, source1);

   FFP_Assign(lDiffuse, source2);

   FFP_Modulate(source1, source2, oColor_0);

   FFP_Add(oColor_0.xyz, lSpecular.xyz, oColor_0.xyz);
}


As I mentioned earlier I've already implemented per pixel lighting sub render state as part of the RT Shader System core. Right now I'm in final stages of implementing sub render state of integrated shadow maps based on PSSM technique as external class.
It seems like this system can really be extended and useful for other users.
In the next patch I'll try to add the custom sub render state of my PSSM as a tutorial that demonstrates how to use and extend the core components of the RT Shader System
User avatar
Nir Hasson
OGRE Retired Team Member
OGRE Retired Team Member
 
Posts: 363
Kudos: 2
Joined: 05 Nov 2008
Location: TLV - Israel

Re: RT Shader System Component

Postby Thieum » Thu Sep 10, 2009 3:05 pm

Hi !

I remember that Assaf Raman talked about a shader emulation of the fixed pipeline for Dx10 (because there weren't any fixed pipeline at all in dx10)
does shader system is somehow related to this emulator ? could it replace it ?
but maybe this my information about this is outdated :)

anyway, this is looking good!
When you parse the material passes, can you take the name of the texture units into account in order to know which features you have to enable ?
for example, if you have a texture unit like "texture_unit NormalMap { ... }", you know you will have to enable the normal mapping
User avatar
Thieum
Gnome
 
Posts: 342
Kudos: 2
Joined: 26 Apr 2006
Location: Bordeaux, France

Re: RT Shader System Component

Postby Nir Hasson » Thu Sep 10, 2009 3:13 pm

Hola !!

I remember that Assaf Raman talked about a shader emulation of the fixed pipeline for Dx10 (because there weren't any fixed pipeline at all in dx10)
does shader system is somehow related to this emulator ? could it replace it ?


I work closely with Assaf - and basically the answer is yes - using it as emulator was one of the secondary goals for this system.
Basically all that we'll have to do in order to use it under D3D10 or D3D11 :D is to implement the core shader libraries of the FFP in HLSL4.
Currently I did it only in Cg - and I assume it wouldn't take much time to complete it in HLSL4.

When you parse the material passes, can you take the name of the texture units into account in order to know which features you have to enable ?
for example, if you have a texture unit like "texture_unit NormalMap { ... }", you know you will have to enable the normal mapping


These are the question I have to deal with now - I've opened a separate topic in purpose -
take a look here
http://www.ogre3d.org/forums/viewtopic.php?f=4&t=52417
User avatar
Nir Hasson
OGRE Retired Team Member
OGRE Retired Team Member
 
Posts: 363
Kudos: 2
Joined: 05 Nov 2008
Location: TLV - Israel

Re: RT Shader System Component

Postby Nir Hasson » Tue Sep 15, 2009 9:35 am

I've just complete writing the first shader based extension to the RT Shader System.
This extension is a PSSM shadow receiver piece. I thought that this kind of extension would be useful when using shadow texture based technique… It will defiantly save lots of time of customizing all materials to include this kind of feature.
I did this test in the PlayPen sample using some of the basic materials on the knot entity and then apply the custom shader state on it.
This is the original technique -
FixedPipeline_PSSM.JPG
Original material
FixedPipeline_PSSM.JPG (95.05 KiB) Viewed 16691 times

And this is the generated pssm technique -
ShaderGenerator_PSSM.JPG
Shader Generator material.
ShaderGenerator_PSSM.JPG (90.26 KiB) Viewed 16691 times


My next steps will be extending the material scripts so that the RT Shader System will be able to build shader based techniques based on material script instead of doing it by code.
One could simple add a line like rtshadersystem_psss to a material pass script and that material will recive pssm shadows...

Will keep update :D
User avatar
Nir Hasson
OGRE Retired Team Member
OGRE Retired Team Member
 
Posts: 363
Kudos: 2
Joined: 05 Nov 2008
Location: TLV - Israel

Re: RT Shader System Component

Postby Vectrex » Tue Sep 15, 2009 9:50 am

excited! :D With this and noman's compositor enhancements it should make material issues way simpler and nicer to work with. Thank you!
Vectrex
Troll
 
Posts: 1354
Kudos: 1
Joined: 12 Aug 2003
Location: Melbourne, Australia

Re: RT Shader System Component

Postby xadhoom » Tue Sep 15, 2009 5:58 pm

Wow, sounds/looks fantastic! An automated aproach would be a relief for many designers...

xad
User avatar
xadhoom
Minaton
 
Posts: 973
Kudos: 2
Joined: 28 Dec 2007
Location: Germany

Re: RT Shader System Component

Postby Vectrex » Tue Sep 15, 2009 6:16 pm

xadhoom wrote:Wow, sounds/looks fantastic! An automated aproach would be a relief for many designers...

xad


Also I'm hoping it massively simplifies shader detail level options implementations.
Vectrex
Troll
 
Posts: 1354
Kudos: 1
Joined: 12 Aug 2003
Location: Melbourne, Australia

Re: RT Shader System Component

Postby Nir Hasson » Tue Sep 15, 2009 7:44 pm

Thank you guys for appreciating this work :D

Wow, sounds/looks fantastic! An automated aproach would be a relief for many designers...

It sure will do – future work can integrate this system into some visual material editor and allow the artists to create shader based materials by simply connecting a few shader elements together. I can imagine something like unreal engine material editor
http://udn.epicgames.com/Three/MaterialEditorUserGuide.html.

Also I'm hoping it massively simplifies shader detail level options implementations

Using the system as is will need no shader code writing at all. However if one would like to change the default behavior, optimize it or adding new custom shader blocks he may need to write some shader code snippets.
User avatar
Nir Hasson
OGRE Retired Team Member
OGRE Retired Team Member
 
Posts: 363
Kudos: 2
Joined: 05 Nov 2008
Location: TLV - Israel

Re: RT Shader System Component

Postby Vectrex » Tue Sep 15, 2009 7:51 pm

Nir Hasson wrote:
Also I'm hoping it massively simplifies shader detail level options implementations

Using the system as is will need no shader code writing at all. However if one would like to change the default behavior, optimize it or adding new custom shader blocks he may need to write some shader code snippets.


Yeah, I'm thinking of things like simple, detailed and no shadowmapping options for users with lower computers etc. I guess it could recompile the shaders when the users changes graphics options, or probably better would be the crysis idea of generating every combination and storing them in a cache (I think)
Vectrex
Troll
 
Posts: 1354
Kudos: 1
Joined: 12 Aug 2003
Location: Melbourne, Australia

Re: RT Shader System Component

Postby Nir Hasson » Tue Sep 15, 2009 8:03 pm

Yeah, I'm thinking of things like simple, detailed and no shadowmapping options for users with lower computers etc. I guess it could recompile the shaders when the users changes graphics options, or probably better would be the crysis idea of generating every combination and storing them in a cache (I think)


I got your point now - it will be possible simply by defining alternative schemes.
This system works by creating a shader based technique from a given source technique.
In order to use the shader based technique that just created you simply change your viewport material scheme name.
Using this concept you can create multiple shader based technique each one with different scheme name - something like SG_Low, SG_Medium and SG_High and then apply the scheme that is most appropriate for your need.
Regarding the generation itself - I already cache the generated shaders - each set of VS/PS has its own hash code so it is used by each pass that do the same thing.... New combinations of PS/VS programs are generated on the fly only if it is not exist already...
User avatar
Nir Hasson
OGRE Retired Team Member
OGRE Retired Team Member
 
Posts: 363
Kudos: 2
Joined: 05 Nov 2008
Location: TLV - Israel

Re: RT Shader System Component

Postby Assaf Raman » Tue Sep 15, 2009 8:17 pm

Also - it is easy to switch back to using only the fixed function.
Watch out for my OGRE related tweets here.
User avatar
Assaf Raman
OGRE Team Member
OGRE Team Member
 
Posts: 3092
Kudos: 78
Joined: 11 Apr 2006
Location: TLV, Israel

Next

Return to Developer talk

Who is online

Users browsing this forum: No registered users and 2 guests