Ok I'm going to drop a bomb here. It may sound like a rant, [s]because it is[/s] but I'm just trying to go straight to the point and take it constructive:
A lot of people isn't using the RTSS. And the poll shows
an alarming number. Why? because
the documentation SUCKS.
Where are the material syntax extensions by the way? They're nowhere to be mentioned. Aaaand...
Seriously?
The system is too complex, large, intimidating. What's worse is that in the little time I've been digging into RTSS, extending with my own shaders looks like a nightmare.
There doesn't seem to be a clear example of how to extend it with your own. Not to mention that we should be able to extend it without writing much C++ code, which doesn't seem to be the case.
I opened up ShaderSystem.cpp from the Sample_ShaderSystem. Wait... what? It's 1800 lines! And there are three more files? And they're also large?!? What about the other projects... nevermind.
It seems like a lot of C++ effort needs to be done just to get RTSS up and running.
So much for a "plug'n play" package.
But then I see the changes that were done to add RTSS to Ogre Meshy, it hints it wasn't that hard after all. In fact it's just a couple of lines.
Of course, that only works if you don't want custom shaders (which can actually be a lot of users). GLES2 users are probably the biggest users.
I am guessing now that extending RTSS with my own shaders could still be a nightmare; but getting RTSS up and running on my own projects wasn't as intimidating as it initially looked. That's a documentation and sample fail.
Which brings me to the big problem: Having a robust material system. RTSS is one attempt to solve it.
A robust material system
Scrawl has a
good summary of reasons why the current material system is limited in usefulness. But frankly, I think Shiny is going too far to the other extreme.
To summarize Scrawl's complains, if my model is not animated; I need a vertex shader. If my model is animated, I need a different VS. If my model has more bone weights per vertex, I need a different VS. If I'm using Instancing, I need another VS. And if I want shadows, I also need ANOTHER VS. And better be sure the math in the caster's VS matches the receiver's VS. And if I want normal mapping, I need a permutation of all the previous variations with normal mapping on and off. It's a O(2^N) problem. Not cool.
Of course, I can use #ifdef macros (and that actually works, very well shall I add); but I have to write a vertex_program entry for each one of them. And a different material to bind these shaders. And better be sure I bound the right shadow caster program to that material.
This could be solved with a shader generator similar to RTSS, hey but then we got to deal with GLSL too (assuming you started first w/ HLSL or Cg)
We're not the only ones with problems on this area.
Unity too.
While writing the Ogre 2.0 manual (and having some ideas for future Ogre 2.x) I came to the conclusion the problem with the current material system is that
it is too flexible.
Think about it: the material system is just a low level interface where a VS and a PS are bounds. The only addition is that a shadow caster can also be bound.
But I don't want this kind of flexibility to go away. It's really useful for some tricky stuff. But most of the time I need a higher level system that deals with the usual permutation problem.
Wolfmanfx wrote:To make it usefull we have to get rid of all functions inside the shaders except the main function. Also i am not sure if the shader compiler can deal with the complicate un-optimized shader.
This is another issue. If we read
Low Level Thinking in High Level Shading Languages (in
ppt) we realize shader compiler suck at optimizing our code.
If we take a look at CryENGINE 3; their materials are actually quite rigid. They have a series of presets:
Cloth, Eye, Glass, Hair, HumanSkin, Ilum, etc which can have diffuse/normal/specular/environment maps, few parameters that can be tweaked
and that's it.
Artists only have to spend time tweaking the few parameters being given and the quality of their textures. And they've got the "Ilum" shader for most generic stuff.
Imagine if a material could just be:
Code: Select all
material MySweater
{
shader cloth
roughness 7
fresnel 0.25
receive_shadows off
diffuse_map mytexture.dds
normal_map mytextureNM.dds
specular_map mytextureSPEC.dds
}
Or we can look at UDK's flexibility which relies on
live node editing to get the job done. There's mixed feelings on this community regarding nodes, but I can tell you every artist I've known loves them (though they're prone to creating very slow materials because they don't have a programmer's mentality).
RTSS focusing on emulating FFP
Well, this is something I would love to review. RTSS should be focusing on providing materials that look good. We're trying to emulate the look games had in 2001 for God sake! Providing PBS (physically based shading) is a very good start.
The good thing about PBS is that we start caring more about just choosing one or two BDRF for the whole game, and then just tweak a few parameters for every surface. No need to write so many shaders.
Main issues when dealing with shaders
When I'm writing shaders, my first problem begins like this:
Code: Select all
#ifdef NORMA_MAP
float4 outTangent : TEXCOORD1;
float4 otherData : TEXCOORD2;
#else
float4 otherData : TEXCOORD1;
#endif
As the number of interpolators keep growing, I keep having to change their numbers. Same happens when I use VTF in a vertex shader (diffuse texture is now on texture unit 1, not 0; normal maps in TU 2, etc)
Unless we resort to generating the code entirely through C++ (like Sinbad's Terrain, something I like to avoid very much) this can easily solved with a shader preprocessor in Ogre: Include a set of keywords that will be recognized by Ogre.
For example:
Code: Select all
#ifdef NORMAL_MAP
float4 outTangent : @TEXCOORDN;
#endif
float4 otherData : @TEXCOORDN;
Each
@TEXCOORDN will be replaced by the next valid unused texcoord. Same can be done with texture samplers (to solve the VTF issue). This approach is very much like Shiny, but Shiny took it to an extreme where the whole shader looks like a mess of keywords so that it cross compiles into HLSL/GLSL to the point it looks like an entire different language. No thanks. That's a bit too much.
My second issue is already been mentioned, and it is not being able to easily match the VS versions of both receiver and caster (let Ogre strip all unnecessary defined macros, and add "-DDEPTH_CASTER" to the compile arguments)
And when a model is loaded, check whether it's using instancing and whether it's animated; and pick the right VS. That's not hard in code if you drive Ogre on how to do it with a couple text files.
A material system that generates material
Like I said, I don't want to remove the flexibility of the current material system. But we do can have a higher level material system that can generate the lower level material. Whether it is RTSS or another a new one, I don't know.
. This is something that should really be looked at. I have no idea about development on mobile platforms, but ill add it to the list. If you have any more info that would be helpful it would be good!
can be made optional ie user can have also other ways like lua script.. flexibility.
Currently shader libraries are in wild and even in the sample, it is not really great (and there are so many variants). And to those experts (I am not), they can always author their own shader.
, I think RTSS fits in nicely where it is, as component, at the moment