RT Shader System Component (RTSS)

[Wolfmanfx]

OSX build broken

Code: Select all

Index: Samples/ShaderSystem/include/ShaderSystem.h
===================================================================
--- Samples/ShaderSystem/include/ShaderSystem.h	(revision 9285)
+++ Samples/ShaderSystem/include/ShaderSystem.h	(working copy)
@@ -31,7 +31,7 @@
 	void itemSelected(SelectMenu* menu);
 
 	/** @see Sample::buttonHit. */
-	virtual void buttonHit(Button* b);
+	virtual void buttonHit(OgreBites::Button* b);
 
 	/** @see Sample::getRequiredPlugins. */
 	StringVector getRequiredPlugins();
Index: Samples/ShaderSystem/src/ShaderSystem.cpp
===================================================================
--- Samples/ShaderSystem/src/ShaderSystem.cpp	(revision 9285)
+++ Samples/ShaderSystem/src/ShaderSystem.cpp	(working copy)
@@ -126,7 +126,7 @@
 }
 
 //-----------------------------------------------------------------------
-void Sample_ShaderSystem::buttonHit( Button* b )
+void Sample_ShaderSystem::buttonHit( OgreBites::Button* b )
 {
 	// Case the current material of the main entity should be exported.
 	if (b->getName() == EXPORT_BUTTON_NAME)

[Nir Hasson]

What went wrong ?
Can you provide more info ?

[Assaf Raman]

Seems that you need to use the "OgreBites" namespace with "Button" - else it doesn't compile on OSX, at least that is what I can see from the patch...

[Wolfmanfx]

Yep last night gcc could not resolve Button because its defined anywhere else.

[masterfalcon]

I could swear that I saw a patch from Sinbad for this. Weird. Oh well, resubmitting a fix.

[Assaf Raman]

@masterfalcon: Can you explain more about why this happens so the windows developers can adapt a "best practice" for using name spaces?

[Wolfmanfx]

So now GLSL shader writer is working some cleanup and documentation is needed

GLSLWriter.jpg

[al2950]

@Wolfmanfx
Nice work

@Nir Hasson
Just wondering as you have already added most of the basic shaders, are you planning on adding specular maps aswell....? Or should i begin looking at creating custom Shaders, which i am going to have to do anyway!

[Nir Hasson]

@Wolfmanfx
That's great news !! good job

@al2950
The top priority now is to write some documentation that describes the system internals and explain how to extend it.
Regarding the specular map - it sounds like very common and useful effect - so in general I think the system should provide it.

But you raised here very important topic - what approach should we take regarding extensions for the RTSS ?
These are some approaches I thought about -

1. Provide the minimum set and put all the effort on the user - that way the system remains light and clean but the user have to do some work in order to create shader based effects.
2. Collect effect patches from users and add to the system - this approach has the benefit of continuously growing library of effects but it will also make the RTSS code go bigger.
3. A mix between the two previous - keep the RTSS core clean and create some new platform the share effects - RTSS Extensions library or something like that.
This approach has the benefits of both previous approach.
I personally think that it will be great to have that shared platform of effects but still give more advanced users the option to write their own custom effects and.

[al2950]

I would certainly say option 3...

[Nir Hasson]

Regarding the extensions - I opened a new thread on it
http://www.ogre3d.org/forums/viewtopic.php?f=4&t=53716.

I just submitted a patch based on Wolfmanfx work - added the GLSL support.
He did great job with it and also demonstrate it in the Shader System sample - you can change the target language on the fly.
There are some small known issues he is going to deal with in the next few days - but he deserves much appreciation.

Good job Woflmanfx

[Assaf Raman]

Wonderful Woflmanfx, amazing work!

U 2 Nir.

[Wolfmanfx]

thx

I send nir the latest patch which fixes some odd gl linker errors (now the log is error free..at least for the rtsys (: ) and the per_pixel (spot light not applied to the sphere in per pixel mode) bug.

[Jabberwocky]

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.

One feature which would be really nice is to somehow specify different textures for different material schemes. This would be used to support a high-resolution texture set, and a normal resolution texture set. For example, if the user selected "texture quality: high", then we would want to activate all the high-res textures in our materials, and if the user selected "texture quality: low", then we would activate the normal-res textures in our materials.

I'm not quite sure the best way of doing this. Maybe some kind of custom "rtshader_system" keyword, like you used in this example:

Code: Select all

     rtshader_system
     {
        light_model sgx_normal_map BeachStones.dds
     }

[Nir Hasson]

@Jabberwocky
You should be able doing it by now regardless the RTSS by specifying different scheme to different techniques – see the manual for more details.
However if you meant that you want to keep the same source technique and define multiple shader based techniques based on it the answer is yes.
In material terms it means that you have to declare multiple rtshader_system sections each with different material schme.

The following code defines just two schemes – the SG_Low will generate per pixel lighting shaders and the SG_High will generate normal map lighting shadrs.

Code: Select all

// RT Shader system section.
 rtshader_system SG_Low
{	 	
 	// Override lighting stage with per pixel lighting. 			
 			lighting_stage per_pixel				
}	
 			
 			
// RT Shader system section.
 rtshader_system SG_High
{	 	
 	// Override lighting stage with normal map lighting.
 	lighting_stage normal_map Panels_Normal_Tangent.png tangent_space 0
}

[Assaf Raman]

@Jabberwocky: You my also reconsider using the code from this thread.

[Wolfmanfx]

So just to keep you informed (not that we do the same tasks twice) i start this week with parallax mapping i will integrate it as an (optional (: )option to the normalmapping subrenderstate and then i thought i could make the hlsl writer (should be pretty same as cg this time)

[Assaf Raman]

sounds good, I was always able to create shaders that work both as cg and as hlsl in the past - but for some cases I had to play with them for a long time to get it just right.

[Wolfmanfx]

Just a little progress update not finished because diffuse tex sampling is not using the parallax texcoord (is a limit from the rtss which is solveable)

[Wolfmanfx]

Hi i think the main problem is that there is no way to override params in 'FunctionInvocations' in a simpliyed way its working like this

funcinvoc.png

But i think a subrenderstate should also be possible to give something out thats why i got stuck because atm i can only rely on ordering and hope that the compiler removes duplicate code (and i do not know if glsl would optimize the example which gave me last night with two texture sampler...cg will (: )
Because the shaders already rely on the parameter content and semantic so it should be no problem to give subrenderstates the possibility to say he take my local ver as a texcoord 1 and all funcinvoc which are after mine should take this local var as texcoord. (also think this is solveable an the cpu program level)

[Nir Hasson]

Good work with the Parallax !!

Regarding the parameters override problem - have to think about some sort of general solution...

[Wolfmanfx]

Think loud maybe you could write a new topic about this problem/design issue?

[xadhoom]

I think I mentioned that problem in the compacting algorithms thread. You might need a data flow model with a determined order to cover enough cases to keep the extension system flexible. You need a parameter type/name specification to give the user an idea which names input/output parameter should have in case they are shared with previous/following states (e.g. "normal", "diffuse texcoord" etc.). There is a tradeoff where the user wants to benefit from predefined components (e.g. calculating the parallax shift, applying a specular map etc.) and where he has to create custom components (with certain inputs/outputs) to achieve the wanted effects...

xad

[Wolfmanfx]

Yep i just thought a little bit more about it and we have to deffer the parameter binding and move the the parameter binding to the Function Atoms. Why because the functions atoms have to be sorted and then we have a list (in the right order) and can request the parameters for each function atom based on their content/semantic so it would be possible to override parameters in function atoms (something like in css so that functions atoms define scopes where the vars are visible).
But this change is huge throughout the system but otherwise we will stuck on easy effects like this one, also to solve this problem via listener would be wrong (now it seems that the FunctionAtoms sbould more behave like small building blocks with in/out slots).

[Nir Hasson]

There is the option to add a pre/post CPU program creation methods to the SubRenderState.
That way SubRenderState could declare which parameters they need from the VS/FS programs during the preCpuProgramCreate call and replace/override some of the parameters in the postCpuProgamCreate method.
The compacting algorithm runs at the post program creation context and he is doing some similar task to the one you need – it actually replace references to input/output parameters in the whole VS/PS programs in case it has to pack/unpack some parameters.
So basically your parallax sub render state will have to override the empty postCpuProgramCreate method in which he will replace any references to the texture coordinate with the tex coord generated by the parallax sub-shader.