RT Shader System Component (RTSS)

[Mattan Furst]

Hi Nir,

I just submitted a patch in the SourceForge patch system. Patch num 2973405.
https://sourceforge.net/tracker/?func=d ... tid=302997

This patch extends and fixes issues in the RTSS serialization and the new layer blend sub-render state.

Issues fixed/extended in RTSS serialization:

• Sub render state factories can now be aware of previously created sub-render state for the same material/pass. This means that sub-render state can now be initialized by more than one single property.
• Sub render states using RTSS properties from texture units (layered blend) could now serialize their information when exporting their data.

Issues fixed/extended in layered blend serialization:

• Layered blend sub-render state serialize is working.
• Layered blend no longer requires a fake property in the "rtshader_system" node of the pass to initialize itself

Please review and commit it.

[Nir Hasson]

@masterfalcon
This is a specific case issue, that sample modified the polygon mode directly, I committed a fix for it anyway.

@mattan
I just committed a fix for the serialization issue caused by the interface change made by the LayerBlending class.
I'll review your patch in the next days and apply the needed fixes/extensions.

[Mattan Furst]

Hi Nir,

Just made a change to the patch I submitted.
In the previous patch I had added a check which failed if 2 sub render states of the same type were added to the same material\pass. I removed the check as it prevented the "Shader System" sample from working.

The reason the check kept failing is this:
The "RTShaderSystem.material" file contains a material called "RTSS/Athene/NormalMapping_MultiPass". This material inherits from the material "RTSS/NormalMapping_MultiPass". Both the material "RTSS/Athene/NormalMapping_MultiPass" and "RTSS/NormalMapping_MultiPass" define an rtshader_system property which starts with "lighting_stage normal_map ...". This means that the final material is created with 2 sub-render state instances of type NormalMapLighting.

I'm no longer sure whether doing the check is correct (logic-wise). However, I don't think that creating 2 NormalMapLighting sub-render states should occur either IMHO.

Opened question (for everyone):
Do you agree that this is a bug? If so who is it a bug of? a bug of the specific sub-render state for creating 2 instances of itself. Or a bug of the script deserialization\inheritance mechanism for not skipping over the property of the inherited material?

[kjuanlu]

In my case, if I use pssm with RTSS, the shadow map is repeated: http://bellotateam.com/images/pssm_rtss_bug.png
After reading the conversation, I think this problem (shadowmap) is the same as the lights. But I've tested with the official release

[Nir Hasson]

@Mattan -

I committed your patch and added some logic to solve the cases you raised -
- For inheritance, I simply remove the parent sub render state instance and add the new one instead of it.
- For multiple attempts of adding the same sub render state instance I simply check if it's not exist in the render state list already.
This scenario happens when more than one texture unit uses the LayeredBlending extension.

[Mattan Furst]

Hello Nir,

I just posted a patch which adds a new feature to the RTSS ExLayerBlend. id number 2977433

This patch adds to RTSS ExLayerBlend control capabilities over texture blending sources through custom parameters. By adding the correct command to a material file. Custom shader parameters will be added to the RTS shader. The custom parameters can then be used to modulate the intensity of the blending source colors (i.e. mainly texture) before the blending operation. The patch also includes a demonstration of this feature in the ShaderSystem sample.

I intend to use this feature to control the intensity of lightmap texture effect on surfaces during run-time. However I have attempted to make the feature as generic as possible so it can be used and extended for other purposes.

please review and commit if possible.


If you decide not to commit it you should know that there are 2 bugs in the ExLayerBlend which need to be addressed (already addressed in the patch).

1. The "OgreShaderExLayeredBlending.h" does not use the RTSHADER_SYSTEM_BUILD_EXT_SHADERS definition.
2. In the function LayeredBlending::setBlendMode. If the vector in the function is resized by more than one. The vector will have uninitialized parameters which will cause an undefined behavior.

[masterfalcon]

I wasn't quite sure if I should post this in the RTSS or GL ES 2 thread, but it seems a little more appropriate in this one. I think it's a problem with the use of the RTSS in GL ES 2 and I'm hoping someone might be able to shed some light on the issue before I delve too deep.

I've found that programs referenced in passes are compiled and linked properly when the material containing the pass is initially parsed. But when it comes time to use it, the programs aren't bound and activated.

For example, the grass demo uses several programs to animate the grass and cast shadows. None of them are bound by GL when the demo is launched.

So what I'm thinking is that the rendersystem's handleSchemeNotFound should bind and activate these programs by iterating over all passes for all techniques in a material. In these cases, createShaderBasedTechnique returns false because the techniques are programmable.

Does this sound like the right way to go?

[tdev]

just a little warning i stumbled upon when cmak'ing the latest hg version under linux:

Code: Select all

Warning: Source file "..../ogre/ogre/Components/RTShaderSystem/src/OgreShaderGLSLESProgramWriter.cpp" is listed multiple times for target "OgreRTShaderSystem".
Warning: Source file "..../ogre/ogre/Components/RTShaderSystem/src/OgreShaderGLSLESProgramProcessor.cpp" is listed multiple times for target "OgreRTShaderSystem".

idk where it comes from, i just thought i should let you know, just in case

[masterfalcon]

That's my fault. Just a dumb copy/paste error. Should be all fixed now

[xadhoom]

I have problems to define the shader cache path as relative path. I´ve posted about it here but did not yet receive an answer.
How is this done correctly? E.g. changing the shader cache path in the SampleBrowser (Sample.h line 430) to

Code: Select all

mShaderGenerator->setShaderCachePath("../"/*shaderCachePath*/);

excepts at runtime, too.

xad

[Nir Hasson]

Just came back from a short vacation…

@Mattan
Thanks for your patches (I saw the skinning patch as well - sounds great !).
I’ll review and merge in the next days,

@xad
Relative path weren’t handled correctly. I’ll fix it in the following days.
You can convert your relative path to absolute as a temporary solution…

[xadhoom]

@xad
Relative path weren’t handled correctly. I’ll fix it in the following days.
You can convert your relative path to absolute as a temporary solution…

Thank you very much. Hope you had a relaxing time

[masterfalcon]

Not sure if the fix is alright. It gets all crashy for me. Could be a runtime bug on OS X, but still should be fixed. Maybe a different variable name?

[Nir Hasson]

Are you talking about the relative path fix ?
Please provide some details from the log file. I tested on windows using ../ as a cache path and it worked fine.

[masterfalcon]

Yeah, the relative path fix. Nothing really to report in the log. But if I use a different variable name it won't crash.

Code: Select all

 const String  programName = programName + "." + language;

Is the line that crashes, deep in STL. My guess is that GCC is having problems with the same variable name in 2 scopes being used in the same statement.

[Nir Hasson]

I see now, my bad, please rename the varibale...

EDIT: I'll do it myself, thanks for tracing ..

[xadhoom]

Hi,

I´m a bit lost about how to correctly use the RT ShaderSystem in practice. The wiki page still lacks some important bits, the sample browser does not reuse the RT ShaderSystem at all and trilobytes description of his approach here did not help either.

My problem is that I have a world of objects which is restarted several times which includes creation and destruction of entities and their materials. While everything runs fine on the first run restarting leads to the first frame showing blank materials for all objects and on the following frames unshaded (default textured) materials.

The initialisation works fine as I can see on the first run. My problem is how to remove certain materials (of destroyed objects/materials). Currently I do the following on world destruciton:

Code: Select all

   
   (... go through all objects and remove them ...)

   // remove the viewport
   mFramework->getRenderWnd()->removeViewport(mViewport->getZOrder());
   
   // remove all shader based techniques here to avoid referencing issues of materials
   // which were already deleted
   mFramework->getShaderGenerator()->removeAllShaderBasedTechniques();
   mFramework->getShaderGenerator()->removeSceneManager(mSceneMgr);
   
   // destroy our ogre scene manager
   mFramework->getRoot()->destroySceneManager(mSceneMgr);

Although "removeAllShaderBasedTechniques()" is already a wooden hammer at least I hoped that would avoid the crashes I encountered so far when the RTShaderSystem tried to access already deleted materials. But now I run into the problem described above. When I recreate the world the materials are white and then unshaded.
I receive no useful log entries about these problem.

My initialisation of the world looks like this:

Code: Select all

   // create our scene manager, camera etc.
   mSceneMgr = mFramework->getRoot()->createSceneManager(ST_GENERIC, "SceneManager");
 
   // create our world camera and set its initial position/orientation/FOV
   mCamera = mSceneMgr->createCamera("Camera");
  
   // set our camera as "fullscreen" viewport with zOrder 0
   mViewport = mFramework->getRenderWnd()->addViewport(mCamera);

   // add our scene manager as shader material target and change scheme to RTShaderLib scheme
   mFramework->getShaderGenerator()->addSceneManager(mSceneMgr);
   mViewport->setMaterialScheme(Ogre::RTShader::ShaderGenerator::DEFAULT_SCHEME_NAME);

How can I dynamically create and delete materials with the RTShaderSystem robustly in a scenario like above?

xad

[Nir Hasson]

Xad –
Your code looks just fine to me.

Did you check the above scenario without the shader generator? (I guess it works fine..)
In case you use the material listener to register all the materials to the shader generator like the sample does, you should restore the viewport scheme to the default scheme in the finalization phase.

Anyway, I can a few ways to trace it –
You can try to create a simple scenario of material creation, destruction and re-creation to see if the problem occurs. Call removeAllShaderBasedTechniques for that material before destoying it.

Alternatively, in your own scenario, try to re-initialize the shader generator by calling ShaderGenerator::finalize() and ShaderGenerator::initialize().
There is also the an option to clean the generated shader programs by calling the ::flushShaderCache method.

[xadhoom]

Hi Nir,

Thank you for your comment.

Did you check the above scenario without the shader generator? (I guess it works fine..)

I´ve introduced the RT ShaderSystem in a fully working (small) project to benefit from this new cool features and basically to learn in a box how things are connected.

In case you use the material listener to register all the materials to the shader generator like the sample does, you should restore the viewport scheme to the default scheme in the finalization phase.

Although I know that nothing is rendered during world destruction/creation (the world also manages the camera/viewport etc.).

Your further suggestions sound good. I´ll give it a try and will report back ASAP.

Thanks!

[xadhoom]

Alternatively, in your own scenario, try to re-initialize the shader generator by calling ShaderGenerator::finalize() and ShaderGenerator::initialize().
There is also the an option to clean the generated shader programs by calling the ::flushShaderCache method.

Ok I´ve tried your recommendation above. My world creation/deletion (where all objects are created and deleted) is now guarded like this:

Code: Select all

void Application::init()
{
   (...)
   Framework::getSingletonPtr()->getShaderGenerator()->initialize();
   mWorld = new World(Framework::getSingletonPtr());
   (...)   
}

void Application::unInit()
{
   (...)
   // delete our world
   delete mWorld;
   Framework::getSingletonPtr()->getShaderGenerator()->flushShaderCache();
   Framework::getSingletonPtr()->getShaderGenerator()->finalize();
   (...)   
}

Suprisingly I get the exact behaviour which I really did not expect. I´m going to create minimal case which I might be able to share. The project here is small but already has some dependencies like PhysX which complicates things...

xad

[Nir Hasson]

This is really strange - I wait to see the results of your minimal case..
Anyways - good luck with that

[xadhoom]

Ok, I was able to create a simple app which shows the behaviour I described above except that it does not create blank materials at the first frame of the second run for a reason I did not yet figure out. Nevertheless the second and further runs are not applying the RT System shader correctly (e.g. the light is not affecting the material).

Here is the stuffed code of the app (interesting part is the run() method):

Code: Select all

#include <windows.h>       // Sleep
#include <Ogre.h>
#include <RTShaderSystem/OgreRTShaderSystem.h>
#include <OgreMaterialManager.h>

Ogre::Root*                      root;
Ogre::RenderWindow*              renderWin;
Ogre::RTShader::ShaderGenerator* shaderGen;

// forward declaration
void run();


// MaterialManager listener
class SGResolverListener : public Ogre::MaterialManager::Listener
{
public:

   SGResolverListener(Ogre::RTShader::ShaderGenerator* pShaderGenerator) : mShaderGenerator(pShaderGenerator)
   {
   }

   Ogre::Technique* handleSchemeNotFound(unsigned short schemeIndex, 
      const Ogre::String& schemeName, Ogre::Material* originalMaterial, unsigned short lodIndex, 
      const Ogre::Renderable* rend)
   {
      {	
         Ogre::Technique* generatedTech = NULL;

         // Case this is the default shader generator scheme.
         if (schemeName == Ogre::RTShader::ShaderGenerator::DEFAULT_SCHEME_NAME)
         {
            bool techniqueCreated;

            // Create shader generated technique for this material.
            techniqueCreated = mShaderGenerator->createShaderBasedTechnique(
               originalMaterial->getName(), 
               Ogre::MaterialManager::DEFAULT_SCHEME_NAME, 
               schemeName);	

            // Case technique registration succeeded.
            if (techniqueCreated)
            {
               // Force creating the shaders for the generated technique.
               mShaderGenerator->validateMaterial(schemeName, originalMaterial->getName());

               // Grab the generated technique.
               Ogre::Material::TechniqueIterator itTech = originalMaterial->getTechniqueIterator();

               while (itTech.hasMoreElements())
               {
                  Ogre::Technique* curTech = itTech.getNext();

                  if (curTech->getSchemeName() == schemeName)
                  {
                     generatedTech = curTech;
                     break;
                  }
               }				
            }
         }

         return generatedTech;
      }
   }

protected:	
   Ogre::RTShader::ShaderGenerator*	mShaderGenerator;
};


// starting point
int main(int argc, char* argv[])
{

   root = new Ogre::Root();

   if(!root->restoreConfig())
   {
      root->showConfigDialog();
   }

   renderWin = root->initialise(true, "RTTest");

   Ogre::RTShader::ShaderGenerator::initialize();
   shaderGen = Ogre::RTShader::ShaderGenerator::getSingletonPtr();
   shaderGen->setTargetLanguage("glsl");

   SGResolverListener* sgResolver = new SGResolverListener(shaderGen);				
   Ogre::MaterialManager::getSingleton().addListener(sgResolver);

   Ogre::ResourceGroupManager::getSingleton().addResourceLocation("..\\media", "FileSystem", "General");
   Ogre::TextureManager::getSingleton().setDefaultNumMipmaps(5);
   Ogre::ResourceGroupManager::getSingleton().initialiseAllResourceGroups();

   // run the test a few times
   run();
   run();
   run();

   return 0;
}

// creates a scene and renders something and eventually destroys everything
void run()
{
   Ogre::SceneManager* sceneMgr = root->createSceneManager(Ogre::ST_GENERIC, "SceneManager");

   // create our world camera and set its initial position/orientation/FOV
   Ogre::Camera* cam = sceneMgr->createCamera("Camera");
   cam->setPosition(Ogre::Vector3(10.0f, 10.0f, 10.0f));
   cam->lookAt(Ogre::Vector3(0.0f, 0.0f, 0.0f));
   cam->setNearClipDistance(0.1f);
   cam->setAutoAspectRatio(true);

   Ogre::Viewport* viewport = renderWin->addViewport(cam);

   // add our scene manager as shader material target and change scheme to RTShaderLib scheme
   shaderGen->addSceneManager(sceneMgr);
   viewport->setMaterialScheme(Ogre::RTShader::ShaderGenerator::DEFAULT_SCHEME_NAME);

   // create our main light
   Ogre::Light* mainLight = sceneMgr->createLight("MainLight");
   mainLight->setPosition(0.0f, 10.0f, 0.0f);

   // render something
   Ogre::SceneNode* node = sceneMgr->getRootSceneNode()->createChildSceneNode();
   Ogre::Entity* ent = sceneMgr->createEntity("ent", "My.mesh");
   node->attachObject(ent);

   // ent uses a cloned (unique) material
   // create a unique material for this mesh   Ogre::MaterialPtr clonedMat = ent->getSubEntity(0)->getMaterial()->clone("ClonedMat");
   ent->setMaterial(clonedMat);

   Ogre::LogManager::getSingleton().logMessage("Render Frame 1");
   root->renderOneFrame();
   Sleep(1000); // show frame one second

   Ogre::LogManager::getSingleton().logMessage("Render Frame 2");
   root->renderOneFrame();
   Sleep(1000); // show frame one second

   // remove cloned material
   Ogre::ResourcePtr clonedRes = ent->getSubEntity(0)->getMaterial();
   Ogre::MaterialManager::getSingletonPtr()->remove(clonedRes);

   // destroy everything
   sceneMgr->destroyEntity(ent);
   sceneMgr->destroySceneNode(node);

   shaderGen->removeAllShaderBasedTechniques();
   shaderGen->removeSceneManager(sceneMgr); // if I forget to remove the destroyed scene manager the materials are broken on the next run, too

   renderWin->removeViewport(viewport->getZOrder());
   root->destroySceneManager(sceneMgr);

}

I worked with the precompiled SDK with VS2005.

And here is the material file I used:

Code: Select all

material MeshMaterial
{
	technique
	{
		pass
		{
			specular 1.0 1.0 1.0 32
			ambient 0.172549 0.701961 0.172549 1
			diffuse 0.172549 0.701961 0.172549 1
   	
			// RT Shader system section.
			rtshader_system
			{	 	
				// Override lighting stage with per pixel lighting. 			
				lighting_stage per_pixel				
			}
		}
	}
}

Please just use any simple mesh with the given material script.

xad

[Nir Hasson]

Hi Xad

A few things I saw when testing your sample –
1. You are using script based material – so no material listener is required.

2. When you call removeAllShaderBasedTechniques method you cause your script based material to discard its RTSS defs, hence in the next runs you’ll see unexpected results.
To overcome this you can
a. Don’t call this method and don’t destroy these materials.
b. Or – make sure that material are reparsed before every run, so a shader based technique will be generated for them.
c. Or – create shader based technique by code at runtime..

3. The cloned material you create can’t be used for the reason that it is not known by the RTSS. I haven’t tackled this issue before cause I didn’t used it in this scenario.
Solution can be to clone material and the create the shader based technique at runtime…

Nir

[xadhoom]

Hi Nir,

Thank you for your help. I see that I´m misunderstanding some points here.
The reason why I eventually introduced the removeAllShaderBasedTechniques() call was because I manually destroy the cloned materials. Otherwise I create add a new cloned material on every world creation without destroying them.

The general problem I see is the lack of a more sophisticated listener approach on the material/materialgenerator side which connects the material/RTSS states more tightly when something changes on the material side (creation/cloning/destruction).

I fear you have good reasons for not doing that!?

xad

EDIT: The problem I have is that the current workflow is not orthogonal. E.g. its possible to just load and initialise the plugin to get advantage of the RTSS materials on all material scripts (and with some additions with runtime created ones, too) but as soon as the material world changes a bit you need to adjust things manually...

[Nir Hasson]

The general problem I see is the lack of a more sophisticated listener approach on the material/materialgenerator side which connects the material/RTSS states
more tightly when something changes on the material side (creation/cloning/destruction).

All the above operations - create, clone, destruction - are operations that should stay unbounded to the RTSS.
I didn't want to add RTSS related code inside the core material system since the RTSS is just an extra component.
At the moment, the coordination with the RTSS of each of these ops is in the responsibility of the user...