[Please vote] Knowledge, Usage and Future of Ogre's RTSS

[al2950]

When writing the triplanar texturing SRS, the hardest part was actually to debug syntax errors in the CG code. The RTSS just asserts with something very general ("could not create render state" or so). So I put breakpoints all over the RTSS to find the origin and then found out that it was actually a syntax error causing this. And syntax errors can not only occure in the actual shader file, but also with wrong usage of the (Uniform)ParameterPtr.

Thanks for the feedback, and also congratualtions on your recent work

could you post a link to the mentioned discussion you and Mattan started

The most recent discussion can be found here; http://ogre3d.org/forums/viewtopic.php?f=4&t=69507. Its a bit of a lengthy read and does have links to some older posts, but it should be an interesting read for anyone heavily involved in the RTSS.

Further to points pointed out in those posts, I have more recently had an urge to experiment with deferred shading techniques, and as a result i want to make the render states more flexible (NB not SRS). At the moment, when you create a RTSS render state it always emulates FFP. However I would like to create one that can create a G-Buffer & L-Buffer, but make it so it can be very configurable, and therefore easier to play with different Deferred ideas.

[duststorm]

When writing the triplanar texturing SRS, the hardest part was actually to debug syntax errors in the CG code. The RTSS just asserts with something very general

I guess it would be very helpful to let RTSS spit out error messages with the exact CG compiler error, like the regular CGProgamManager does.

Outputting the generated shader to file and running cgc manually on it is also feasible, of course.


Quote from Nir Hasson in the original RTSS announcement:

Implement visual shader editor that will enable to artist with zero knowledge in shading languages to create shader based materials.

This would also be a good step in the direction of a wider acceptance of the RTShader system.
This could be incorporated of a GUI-based material editor for Ogre, on one hand, another idea is a tool for easier shader development allowing visual debugging and runtime shader (re)compiling.
Maybe an idea for a future GSoC?


One extra thing I wanted to mention. There is a lot of documentation about how to set RTShader settings in material files here: http://www.ogre3d.org/forums/viewtopic.php?f=4&t=52417

[chaosavy]

I voted - aware but don't know how to use it.

However many times with Ogre how to use it is just a matter of looking through the demo. I'm guessing that down the line I'll look into it and use whatever I can Still focusing on gameplay elements in my project.

[Klaim]

I've read and been aware of this feature but couldn't work on 3D code for a long time. Now I'm back on it so I should use it very soon.

[Mattan Furst]

I have previously written a post on things that I thought needed to be done in the RTSS to improve it's ease of development here: http://www.ogre3d.org/forums/viewtopic.php?f=4&t=69507.
I have other 2 dozen custom sub-render states where I work. Given that some of the changes I mentioned required breaks in compatibility which meant I would have needed to re-write them, I was relactent to start the project and after a while forgot about it.

I would add to the list that I already wrote in the previous post (non-compatibility breaking):

1. As other people mentioned documentation on how to use and RTSS scripting .
2. Extend the current implemenetation of the texture SRS. It should:
   1. support all texture polling mechnism. including the new tri-planar texturing.
   2. it should support polling texture information for non-coloring purpuses. for instance getting the color of a normal map for preperation to another SRS. (more on this on number 3)
   3. The texturing SRS should be less sensitive to texture coordinate input parameters. For instance, if a texture parameter of size 3 or more is defined for a 2d texture. The SRS throws an exception.
3. The diffrent sub-render states need to be more integrated. For instance the current normal map SRS has 3 seperate jobs: It polls the information from the normal map texture. changes the normal according to the polled value. Then it calculates the lighting effect for the pixel. A proper implementation should be that a texturing SRS should be the one to poll the texture. The normal map SRS should only change the normal's direction according to the polled value. Than the a diffrent SRS such as the "per pixel lighting" SRS should the normal in its calculation.

I think I'll start working on these ideas again.

Update:
Didn't notice somebody already posting a link to my old post.

[PhilipLB]

Point 3 kept me off doing the normal mapping for the triplanar texturing. A SRS-step for only manipulating the (texturespace?) normal would make this very easy.

[Mattan Furst]

Point 3 kept me off doing the normal mapping for the triplanar texturing.

I actually almost implemented it once, however implementating it meant that the shaders would have been slightly less efficient and it would have also broken compatibility. After a short discussion I was instructed by the community to just keep the old method. I ended up doing it as a custom propitiatory SRS. Now thinking about it I probably should have insisted on it more.

[PhilipLB]

Maybe some lightweight API optimizations for 1.9 as proposed and bigger, backward compatibility breaking changes for 2.0?

[syedhs]

I once used RTShader and it generated better shadow ie sharper edges, less 'swimming' effect but there is a bug (of which I cannot fathom the reason, and cannot exactly locate the offending lines) that can suddenly dive down FPS a lot.. eg from 60FPS going down to 15 for a few seconds, and then resume normal which was very strange. I debugged the software for almost a week and then I found that the symptom happened after I put in RTShader. The bug was no longer there when I disabled RTShader and put in the shader manually. I asked in Developer Forum and no one can actually answer.

The thread is here: http://www.ogre3d.org/forums/viewtopic. ... 08#p428508.

I will definitely give it a spin once 1.9 is out Other than the issue above, RTShader definitely makes shader programming a piece of cake..

[bstone]

Other than the issue above, RTShader definitely makes shader programming a piece of cake..

Cakes make you fat really quick whereas coding shaders makes you exhausted and slim

[duststorm]

whereas coding shaders makes you exhausted and slim

And here I was, thinking that coding made you fat


On a more related note, I've been getting not-very-informative exceptions from RTSS when using rtshader_system material definitions, the likes of this

Code: Select all

An exception has occured: OGRE EXCEPTION(2:InvalidParametersException): Could not create gpu programs from render state in ProgramManager::acquireGpuPrograms at OgreShaderProgramManager.cpp (line 112)

Thinking that it could be related to cg profile restrictions (linux with an intel graphics card), I tried changing the target language to glsl. Unfortunately that didn't help.

I can reproduce it with this material:

Code: Select all

material RTSS/NormalMapping_SinglePass
{
        technique
        {
                pass
                {
                        specular 1.0 1.0 1.0 32
                        
                        texture_unit
                        {
                                texture Panels_Diffuse.png
                        }                               
                        
                        rtshader_system
                        {               
                                lighting_stage normal_map Panels_Normal_Tangent.png tangent_space 0 bilinear 1 -1.0
                        }                       
                }                               
        }
}

Comment out the specular and it works (both in glsl and cg), put it in and I get the exception.

Guess I'll have to dig a bit deeper to find my answer.
Is there someone that knows what might be wrong. This might also be one of these aforementioned cases where RTSS could benefit from more descriptive error messages.

[Arkiruthis]

The first time I came across the RTSS was in the Ogre iOS templates and had no idea what it was, so I ignored it. I just had a look at the Wiki article on it and can't wait to get stuck in tomorrow with some sample code. So if nothing else, this thread was a good idea on an educational front!

duststorm: Just looking at some code output from Blender Exporter here... what happens if you change your specular line to have an extra 1.0?

e.g., specular 1.0 1.0 1.0 1.0 32

I have no idea if specular requires an alpha value, but my material scripts all seem to have the 4th value included...

[duststorm]

what happens if you change your specular line to have an extra 1.0?

e.g., specular 1.0 1.0 1.0 1.0 32

I have no idea if specular requires an alpha value, but my material scripts all seem to have the 4th value included...

Alpha in specular is allowed, but should not be required. Anyway, I tried both with and without, and that didn't change things.

[TheSHEEEP]

Personally, I was aware of it, but also never used it due to the lack of examples, tutorials, etc.

Also, I'm trying to get into shaders more, meaning actually understanding what's going on, being able to write advanced shaders myself, etc.
And there, I think an additional layer of indirection would hinder the learning experience.

Someone who does know a lot about shaders already would probably profit quite a lot from using the RTSS; even more than someone who doesn't want to get into shaders too deep (very understandable ).

[oiram]

I'am working on ES2 that means RTSS is indispensable to me.
However I just copy code from sample and use RTSS to generate shader code for FF pipeline.
I think we need more sample and manual with RTSS for use correctly.

RTTS is great, thanks!

[rogerdv]

I used it in y projects, it was the only way to have normal map shaders.
By the way, Unigine has a similar (and easier) system based on inheritance. You just have to inherit your material from one in the base lib, lets say base_mesh, and then set the diffuse texture, normal map, specular map, etc.

[spacegaier]

I used it in y projects, it was the only way to have normal map shaders.
By the way, Unigine has a similar (and easier) system based on inheritance. You just have to inherit your material from one in the base lib, lets say base_mesh, and then set the diffuse texture, normal map, specular map, etc.

The interesting question now is whether they actually have such a flexible system as we do, meaning do they use a set of predefined ("hardcoded") shaders that then just get applied or can they - as our RTSS can - really generate them on the fly by concatenating various SubRenderStates?

If it is the first then Unigine is not the only one, e.g. Panda3D has that feature as well, but we are yet to come across a rendering engine that can do the latter .

[Assaf Raman]

I don't understand why Unigine is easier, you can set all the OGRE material properties directly in the material script file, sound about the same as Unigine, I will love for some more information why Unigine is easier.

[bstone]

All that Unigine material stuff sounds like the material inheritance already supported by Ogre's script compiler out of the box. So you don't even have to roll out the heavy artillery of RTSS to beat it I've used script inheritance and related features with great success. Very flexible stuff.

[Assaf Raman]

My point was that using RTSS features like normal map - can be done directly in the OGRE script files - in an easy way.

[rogerdv]

My point was that using RTSS features like normal map - can be done directly in the OGRE script files - in an easy way.

Never found a shader that worked for me, and even wasnt too sure if the RTSS was achieving a perceptible normal map effect.
I should have explained a bit more about why Unigine is easier. Indeed the inheritance system is similar, but inside Unigine editor you just have to click and browse your diffuse, heigthmaps, specular map, tessellation or whatever. Also, Unigine provides a larger base library including vegetation materials, tessellated meshes and many more. Nothing that cant be done with Ogre, but requiring a shader expert.

[PhilipLB]

Sounds like a similar system could be achieved with Ogre when it had a nice UI for the material inheritance stuff?

[bstone]

Sounds more like that's responsibility of a content creation system and not of a render engine. Otherwise from all the above it's obvious that Ogre is more flexible when it comes to materials and shaders than Unigine.

[duststorm]

But of course it would be wonderful to have a dedicated visual material editor for Ogre that uses RTSS. Together with a library of pre-defined materials, like foliage materials, maybe?

[bstone]

Well, sure thing. Like all the other cool external stuff already available for Ogre or soon becoming available.