Ogre Forums

Ah ok, so if I generated the materials with code I could then generate the shaders automatically? I want to avoid having a million variations to maintain, so in code I'd simply generate the materials with a few if statements. Wouldn't it be cool to have an if statement in material files??

Here's my two cents for the day.

One of the arguments I keep hearing against real time shader generation systems is that the code they will produce is very generic and therefore long and unoptimized. And you can always write better optimized shaders by hand.

One of the ways the RT Shader System can circumvent this problem is to allow the user to define which parameters are constant. For instance when defining a light source the attenuation parameters and light color usually do not change during runtime (at least not per specific light). You can then generate a shader with the constant parameters written directly into the shader. Furthermore calculations involving multiplication by one or zero and additions of zero values can be removed completely.

This way you can generate shaders that are so specific that only the most feverish of optimization buffs can compete with.

Ah ok, so if I generated the materials with code I could then generate the shaders automatically?

Sure you can, that was one of the main goals of this system and I use it in this scenario - I have bunch of materials that generated thru code and now I can generate shaders for them at runtime, nothing is precompiled and of course nothing to maintain... (Just the code of the system itself)

Wouldn't it be cool to have an if statement in material files??

Regarding the material files - I work now on extending the property set in order to make the RT Shader System deal with scripts as well beside the option to explicitly generate shaders using its API. So you could also use the current material script system and in a few lines of script you can cause to existing FFP material to be processed by the system and have shader based techniques..

Maybe material scripts should support C# style attributes?

Maybe material scripts should support C# style attributes?

Don't know what this means - I didn't work on C# too much (thank god )
I thoght about something like this
This will generate a new tehcnique with the scheme name DefaultShaderGenerator that will do per pixel lighting..
If you have other suggestion maybe put it in this thread http://www.ogre3d.org/forums/viewtopic.php?f=4&t=52417 - cause we are getting out of this thread scope...

I'm seeing a bunch of errors similar to this on OS X:
Is this just me?

I'm seeing a bunch of errors similar to this on OS X:

I don't have the OS X env here - so I can not check it.
However I guess it is related to some compiler casts that are done implicitly on Microsoft and Linux env.
I think the compiler dont perform implict cast of the enum there to int.
Try replacing With Keep me update in order to add it to next patch

Nir Hasson wrote:

I'm seeing a bunch of errors similar to this on OS X:

I don't have the OS X env here - so I can not check it.
However I guess it is related to some compiler casts that are done implicitly on Microsoft and Linux env.
I think the compiler dont perform implict cast of the enum there to int.
Try replacing

Code: Select all

sh_hash_combine(hashCode, mFogMode);
sh_hash_combine(hashCode, mCalcMode);

With

Code: Select all

sh_hash_combine(hashCode, (int)mFogMode);
sh_hash_combine(hashCode, (int)mCalcMode);

Keep me update in order to add it to next patch

casting hashCode to (size_t &) solved the errors for me. I haven't tried running yet as I'm at work right now.

O.K - that is strange since all other implementations in other source defines hashCode as uint32 and nothing went wrong there...
Anyways I'll just modify the combine function protoype from
To this code This is internal function used by the RT Shader System and it is declared in OgreShaderPrerequisites.h.
Can you verify that this solution works for you ? I prefer it over solving it just in the FFPFog class...

Nir Hasson wrote:O.K - that is strange since all other implementations in other source defines hashCode as uint32 and nothing went wrong there...
Anyways I'll just modify the combine function protoype from

Code: Select all

inline void sh_hash_combine(std::size_t& seed, T const& v)

To this code

Code: Select all

inline void sh_hash_combine(uint32& seed, T const& v)

This is internal function used by the RT Shader System and it is declared in OgreShaderPrerequisites.h.
Can you verify that this solution works for you ? I prefer it over solving it just in the FFPFog class...

Yeah, that appears to work great!

Yeah, that appears to work great!

Thanks man WIll be in next patch...

Is possible to add an example on how to set up Ogre with the RT Shader system?

Thanks

Is possible to add an example on how to set up Ogre with the RT Shader system?

Sorry for my late response - had a long weekend.
The trunk code already has the RT Shader System embedded example in all samples code that based on the ExampleApplication frame work.
Make sure you build the RT Shader System component – using the OGRE_BUILD_COMPONENT_RTSHADERSYSTEM variable in the CMake script.
Then take a look at the ExampleFrameListener.h and take a look at the code sections between the USE_RTSHADER_SYSTEM defines.
Basically pressing F3 will switch the main viewport scheme to the default scheme of the ShaderGenerator and therefore all materials will run using shader generated techniques.
Pressing F2 will switch back to default material scheme.

Hope it helps you…

Hi –
Just finished some work on the normal map side.
Here is the original material script – And this is the script that generates normal map shader This is the result when rendering with the default material scheme - This is the result when rendering with the shader generator material scheme -

Wow,looks very nice!

Nice advertisement

Is this functionality already in the trunk?

xad

xadhoom wrote:Nice advertisement

Is this functionality already in the trunk?

xad

Yep, press F3 and F2 to swap between fixed function and shader in the ogre demos

Nice advertisement

Is this functionality already in the trunk?

xad

I have to finish the point light implementation, spot light and linear depth first - then I'll merge it in.
I guess around the end of this week - just building the tension till there
In the mean while the version in the trunk contains only the FFP emulation - so you won't find there any special effects
Nir

Hi –

I just commited the new version for the RT Shader System.

This version includes the following changes –
1. Built in per pixel and normal map custom sub render states implementation. Enables generating shaders that perform per pixel lighting calculations instead.
Current implementation supports all kind of light type but can be used only in a single pass since it always adds the ambient term. I'll might implement option to separate it in order to user in per light iteration passes.

2. Script support for the system. In each pass in the material script users can add now a section called rtshader_system and within it define custom properties.
Currently the only one property is built in supported:
light_model sgx_per_pixel // Per pixel lighting model.
Light_model sgx_normal_map normal_map_texture_name // Normal map lighting model.

3. Ability to implement custom sub render state outside the RT Shader System project scope. I implemented a custom PSSM receiver sub render state and used it in my own application. I did it also in the PlayPen frame work but didn’t include it in this patch.

4. Sample application changes -
F2 – set the main viewport material scheme to default material manager scheme.
F3 – set the main viewport material scheme to default shader generator scheme (This can be referred as turning the shader generator on).
F4 – Toggle the light model of the default scheme render state of the shader generator between per vertex to per pixel.

5. Demo_Dot3Bump – added another material that demonstrates using bump map lighting model of the RT Shader system. The material is added to the Examples-Advanced.material and called Examples/RTShaderSystem/BumpMapping.
In order to see it in action toggle to it pressing m and then press F3 to enable the shader generating.

6. Material changes – particle system material uses track vertex colour property on in order to give same results when rendering via shaders.

7. Core changes are only in the Pass::setUserAny method which I added previously. Now it takes a key parameter in order to allow associating multiple user data objects to a single pass.

Hi
Are there any plans to document how the system (i mean in an abstract way) suppose to work? I know the source code is well documented and right now i am reading it but you know

Hi -

I guess you got a point there. Documentation isn’t my favorite part - but I guess it is somewhat helpful
I’ll add it to my task list and submit it where it belongs. I’ll try to attach some high level design documents I made as well.
Where do you suggest me to place the documents? In the wiki or general system documents?.
Beside, I'm working on a dedicated sample as well as cross samples integration that will demonstrate its capabilities.

The place is not so importanted for me
Describe the SubRenderState because its a little bit mixed up for me in one place you use it to supply the system with basic functions like transform in another class you build up the whole NormalMap extension in it which make use of other subrenderstates.

Ok – I'll figure out where to put it…

In the meanwhile – just a short answer for you:
The SubRenderState represents an independent piece of rendering pipeline starting from the vertex shader until the pixel shader. It is done in this way in order to allow users to extend the system capabilities in a seamless way. The FFP emulation is built upon sub classing this interface so there you see the Transform part, Lighting per vertex etc.
In addition I added some common extension such as per pixel and normal mapping both again are sub classes of SubRenderState…

Hi –

I just commit a new dedicated RT Shader System sample to main brunch.
It will demonstrate the main system capabilities – FFP Emulation, built in lighting models etc.
I also merged the system to the new samples frame work (I like it ) and now you can see exactly how many shaders have been generated during each sample runtime.
F2 – Toggles the system.
F3 - Toggles global lighting model (Vertex / Pixel).
F4 – Toggle the info panel.

I’d like to get feedback for Linux and Mac users since I can’t test it in these environments.

Art credits goes to Michael Grosberg.
Object space normal map generated using xNormal- check it out here…
http://www.xnormal.net/

Here is a screen shot from the new sample -