History: OGRE SMASH - JaJDoo Shader Guide - Basics

Source of version: 11 (current)

!:::OGRE.EAT(shader);:::
!:::Or:::
!:::Exporting to OGRE:::
!:::and:::
!:::Alternatives:::

{maketoc}

!!Down to business 
So it comes down to this: we want that shader in our OGRE application. How do we do that? Luckily, its not a very difficult procedure.

First thing we have to do is put our shader in its own file. But before we do that, we have to make some changes.

# You cannot use global variables - everything has to be sent from OGRE.
# We cannot use the technique we created inside the file.

First, we’ll make the necessary changed to the file:

{CODE(wrap="1", colors="c++")}
float4 mainVS(		float4 		pos : POSITION,
		uniform float4x4 	worldViewProj_m
		) : POSITION
{
	return mul(pos,worldViewProj_m);
}

float4 mainPS() : COLOR 
{
	return float4(1, 0, 0, 1);
}{CODE}


This is how our new vertex and pixel programs look. You will notice that while the pixel program had not changed, the vertex program had.
In order to use the world-view-projection matrix, we will have to add it to the programs argument list. 

You’re probably thinking “why not declare the WVP matrix with the same semantic we used when it was a global?”

Well, both vertex programs and pixel programs have a list of acceptable input and output semantics. Anything not part of this list must be declared as either a __uniform__ or a __varying__ argument.

We declare an input as __uniform__ when we know its value will not change during the executions of the shader. For instance: the WVP matrix will not change while running the program, it will only change after the frame has been rendered, by then the shader is being executed again, with different values.
In practice, the global variables we defined are actually uniform.

Varying input is all input that’s not uniform. In practice, all input flagged with semantics are of varying type. For instance: the position of the vertex can be manipulated while the shader is executed – if it wasn’t, shaders wouldn’t really be useful.

Once you have written this code to file (you can use notepad, I save them with an .hlsl extension, but it doesn’t really matter to OGRE) Remember to put it somewhere your application can find it.

{REMARKSBOX(type="The interfering tip box",title="the interfering")}Not satisfied? 
Feeling smart? 
Read what I just explained with more detail here:
http://msdn.microsoft.com/en-us/library/bb944006%28VS.85%29.aspx#Uniform_Shader_Inputs
{REMARKSBOX}

!!The material
One of the best parts about OGRE is the material scripts system. It allow you to quickly change things without recompiling your application.

So how is the material script arranged?
Actually, it’s very much like we’ve done in FXC, with a bit of difference.
 
First of, we declare the vertex and pixel programs:

{CODE(wrap="1", colors="c++")}
vertex_program [name] hlsl
{
	source [your-file-name-here+extension]
	entry_point [function name]
	target vs_1_1
	default_params
	{
		param_named_auto worldViewProj_m worldviewproj_matrix
	}
}

fragment_program [name] hlsl
{
	source [your-file-name-here+extension]
	entry_point [function name]
target ps_2_0
}
{CODE}

!!!Closer look : Creating a program profile within the material
#	__Declaration__: Vertex/fragment_program |name| hlsl (The hlsl in the end defines in which language the code is written. can be glsl, cg, asm….)
#	__~~#F00:Source~~ |file name|__ : the file in which you put the code.
#	__~~#F00:entry_point~~ |program name|__ : the name of the function this reference will run.
#	__~~#F00:target~~ |name|__ : same as what comes after compile back in FXC.
#	__~~#F00:default_params~~__ : This one is important. Using this part, you can send data from your OGRE application to your shaders. There are four types of default params, two manual, and two automatic.
##__~~#F00:param_named~~ 		|param name|	|type|	|value| |extra params|__
##__~~#F00:param_indexed~~ 	|param index|	|type|	|value| |extra params|__
##__~~#F00:param_named_auto~~ 	|param name|	|automatic value| |extra params|__
##__~~#F00:param_indexed_auto~~ 	|param index|	|automatic value| |extra params|__

The parameters using name require the name of the input argument as it is written in the function definition.
The parameters using index require the index of the input argument in the function argument list (for instance, wvp in mainVS is the first and only argument).

Special parameters (such as the primary matrices) have an automatic value you can send (very much like using their semantic in FXC). Their name may be somewhat different, make sure you check.

You can look for the corresponding string in the ogre manual ( http://www.ogre3d.org/docs/manual/manual_23.html#SEC125 ) or use an OGRE script editor such as YAOSE that can offer possible candidates.

!!!The technique
Much like the technique we wrote in FXC, we need to create a rendering technique. The syntax is similar to how it written in pure hlsl file (such as in FXC)
{CODE(wrap="1", colors="c++")}material [name]
{
	technique
	{
		pass
		{
			vertex_program_ref [vertex program name]
			{
			}
			fragment_program_ref [pixel program name]
			{
			}
		}
	}
}{CODE}

The material definition has a few part, some you can easily recognize:
#	__~~#00F:material~~ |name|__ – you use this name when loading the material within OGRE.
#	__~~#00F:technique~~__
#	__~~#00F:pass~~__
##	Inside the pass we create references to the vertex and pixel programs we defined earlier.  Syntax:
###	__~~#00F:Vertex/fragment_program_ref~~ |name|__
##	For now, we have no need to add anything inside the reference. The reference has an option to send parameters to the program, much like the default param part in the definition. If you use the same program in different passes / techniques / materials and want to send a different value depending on the specific case, you can define that in this part.

!!The final result
When we combine the two parts, your resulting file will look like this:
{CODE(wrap="1", colors="c++")} 
vertex_program [give me a name] hlsl
{
	source [your file name here+extension]
	entry_point [function name]
	target vs_1_1
	default_params
	{
		param_named_auto worldViewProj_m worldviewproj_matrix
	}
}
fragment_program [give me a name] hlsl
{
	source [your-file-name-here+extension]
	entry_point [function name]
	target ps_2_0
}

material [give me a name]
{
	technique 
	{
		pass
		{
			vertex_program_ref [vertex program name]
			{
			}
			fragment_program_ref [pixel program name]
			{
			}
		}
	}
}
{CODE}

Now you can load the material to inside your OGRE application using the name you provided. Remember to fill all the missing parts (names) that I have left blank inside [].

Load the material, and run your application.
You will now witness darkness (probably). 
If you move around, you will eventually see something like this: 
{IMG(src="display1811")}{IMG} 

!!Why?! What is that!?
Remember what your second grade teacher said about mortifications? Ill remind you:
''__2 * 3 is the same as 3 * 2__''

Well, when matrices are in play this law no longer applies. We need to know how our system organizes matrices to know in what order to multiply.

I’ll give you a shortcut; remember this:
{REMARKSBOX(type="tip",title="REMEMBER",highlight="y",close="n")}In FXC you multiply the VECTOR by the MATRIX

In OGRE you multiply the MATRIX by the VECTOR
{REMARKSBOX}

In order to fix our shader to work with OGRE, we need to change

{CODE(wrap="1", colors="c++")}output.Position = mul( input.Position , worldViewProj_m );
{CODE}
To this

{CODE(wrap="1", colors="c++")}output.Position = mul( worldViewProj_m, input.Position );{CODE}

Now the result will be that useless red material we made in FXC.
{REMARKSBOX(type="tip",title="Another interfering tip box")}Feeling smart? 
Want to know why matrices make your life hard?
http://www.math.umn.edu/~nykamp/m2374/readings/matvecmult/
This page will show you how matrices multiplication works, and why order of the multiplication is important.
Also: read this entry in the OGRE manual:
http://www.ogre3d.org/docs/manual/manual_20.html#SEC116
{REMARKSBOX}

!!Using NVIDIA CG as alternative
If you try to run your OGRE application using OpenGL your material will not be loaded, since it’s written in HLSL which is D3D specific.

CG is another shading language developed by NVIDIA capable of compiling against OpenGL and D3D.

The main advantage of using CG for us is that its syntax is identical to HLSL, allowing us to write as we are used to, and have a shader that runs on both systems.

There are a two changes required:
#	__~~#00F:vertex/fragment_program~~ |name| cg__ – we need to specify that the program is cg format. (switch hlsl appendix to cg)
#	__~~#F00:profiles~~  |first profile| |second profile|…__ : instead of the keyword target we use the keyword profiles. You can add a list of profiles to use, both D3D and OpenGL.
##	Note that I use arbvp1 / arbfp1 for OpenGL because I’m an ATI user. If you have an NVIDIA card, you can use one of the NVIDIA specific profiles. They are called vp** or fp** ( ** being the version, such as vp20 or fp30, check which ones you support )

Well that’s it, now you will be able to run the same shader with both OpenGL and D3D. But remember, __cg is not HLSL__ (even if they share the same syntax) and neither is it GLSL. Each one (including CG) has its specifics, though at some cases, CG provides a valid and recommended alternative .

This is how the file looks on my side of the fence.
{CODE(wrap="1", colors="c++")}vertex_program v cg
{
	source bbb.hlsl
	entry_point VertexShaderFunction
	profiles  vs_2_0 arbvp1
	default_params
	{
		param_named_auto   	worldViewProj_m 	worldviewproj_matrix
	}
}
fragment_program p cg
{
	source bbb.hlsl
	entry_point PixelShaderFunction
	profiles ps_2_0 arbfp1
}

material bs
{
	technique
	{
		pass
		{
			vertex_program_ref v
			{	
			}
			fragment_program_ref p
			{
			}
		}
	}
}{CODE}

!!A purer alternative
While some people argue that CG = pow(OpenGL + D3D, easy), some will claim that CG = NONE. If you don’t want to use CG as an alternative to HLSL and GLSL, you can use OGRE’s ‘unified’ type program in your script (provided you have another version of your shader in a different language)

Unified allow you to use two or more different programs in one reference, instead of creating an alternative technique just to allow both to run in the same material.

Here’s how it works strait out of OGRE manual:
{CODE(wrap="1", colors="c++")}vertex_program myVertexProgramHLSL hlsl
{
	source prog.hlsl
	entry_point main_vp
	target vs_2_0
}

vertex_program myVertexProgramGLSL glsl
{
	source prog.vert
}

// unified definition
vertex_program myVertexProgram unified
{
	delegate myVertexProgramGLSL
	delegate myVertexProgramHLSL
}

……
// reference works the same, but points to the unified program. OGRE rocks doesn't it?
		pass
		{
			vertex_program_ref myVertexProgram
			{}
……
{CODE}


You can learn more about it in the OGRE manual if you’d like. (Though this is pretty much all there is to it)
History: OGRE SMASH - JaJDoo Shader Guide - Basics

Source of version: 11 (current)

Search by Tags

Latest Changes

Search

Online Users
