RT Shader System Component (RTSS)

Discussion area about developing or extending OGRE, adding plugins for it or building applications on it. No newbie questions please, use the Help forum for that.
User avatar
Nir Hasson
OGRE Retired Team Member
OGRE Retired Team Member
Posts: 363
Joined: Wed Nov 05, 2008 4:40 pm
Location: TLV - Israel
x 2
Contact:

Re: RT Shader System Component (RTSS)

Post by Nir Hasson »

Well – that sounds good on the paper.
I would love to see it on practice.
The tricky part would be how to share the modified parameters between each subrenderstate. I.E – the normal map modifies the normal – how the PerPixel lighter knows about it ? common names ?
Anyway – it really sounds good idea to do – I would be happy to see that in action..
User avatar
Noman
OGRE Retired Team Member
OGRE Retired Team Member
Posts: 714
Joined: Mon Jan 31, 2005 7:21 pm
Location: Israel
x 2
Contact:

Re: RT Shader System Component (RTSS)

Post by Noman »

I thought about that question, and my current idea is "through the inputs" -
shader parameters (either inputs from the vertex programs or uniform constants) can be treated as local variables in shaders.
This means that we are allowed to write values to them and use the updated values later in the shader.

The way I see it, if each lighting stage writes its output to the input that it modifies (ie, normal shader writes its output to the input normal variable) we get transparent cooperation between the sub render states.

I'm currently using this method for specular mapping. I'll post my results when I'm done :)
User avatar
Nir Hasson
OGRE Retired Team Member
OGRE Retired Team Member
Posts: 363
Joined: Wed Nov 05, 2008 4:40 pm
Location: TLV - Israel
x 2
Contact:

Re: RT Shader System Component (RTSS)

Post by Nir Hasson »

Ok –
But sometimes this isn’t the case. The normal map calculates the normal in the pixel shader stage.
It is a local variable that is being computed during that phase. So the per pixel lighter will have to “know” the name of the normal variable…
Looking forward to see your work..
User avatar
Noman
OGRE Retired Team Member
OGRE Retired Team Member
Posts: 714
Joined: Mon Jan 31, 2005 7:21 pm
Location: Israel
x 2
Contact:

Re: RT Shader System Component (RTSS)

Post by Noman »

These shaders usually don't calculate - they modify. I think that this is key to this method.
Even if there was no normal mapper, there would still be a normal that the per-pixel-lighter uses for its calculations. It would be the interpolation of the normals from the vertex stage.
The normal mapper would modify that variable. The PPL's code would remain the same, using the same normal variable as input for its calculations. But in the case of normal mapping, the normal would get modified before the code reaches the PPL.

We would need to add treatment in case the mapper introduces a new variable (rather than modifying an existing one). But in this case, the next steps have to be aware of this new variable anyway, so this idea doesn't introduce new problems...
User avatar
Noman
OGRE Retired Team Member
OGRE Retired Team Member
Posts: 714
Joined: Mon Jan 31, 2005 7:21 pm
Location: Israel
x 2
Contact:

Re: RT Shader System Component (RTSS)

Post by Noman »

Started working on the nested texture units.
You can see the progress in a patch that can be found here
I didn't add it to the patch tracker because I don't intend to apply it to Ogre as-is.

Some comments
- I have a bit of a hack in place - I create a material (not part of resource management) just so the texture unit state can have access to placeholder parents (pass,technique etc) otherwise I get null pointer exceptions.
- I currently still support the previous mode, but I don't think its wise to remain with two when I commit into the HEAD branch. This will all go only into trunk, so API (or script format) changes are acceptable.
- The normal map extension doesn't still use all of the directives that can be found in texture units. (Things like texture matrices generated from rotations / scales etc for example). Perhaps we need to connect between the normal mapper and FFP_TEXTURING to create the correct texture sampling shader code.

Example of the main entity material export to .material:

Code: Select all


material Panels_RTSS_Export
{
	technique
	{
		pass
		{

			texture_unit
			{
				texture Panels_Diffuse.png
				rtshader_system
				{
				}
			}
			rtshader_system
			{
				lighting_stage normal_map object_space
				{

					texture_unit
					{
						texture Panels_Normal_Obj.png
						mipmap_bias -1
					}
				}
			}
		}

	}


}
User avatar
Noman
OGRE Retired Team Member
OGRE Retired Team Member
Posts: 714
Joined: Mon Jan 31, 2005 7:21 pm
Location: Israel
x 2
Contact:

Re: RT Shader System Component (RTSS)

Post by Noman »

Continuing the work on the nested texture units, currently thinking about how to generate the shader calls for them.
I think that the correct solution is to use the FFPTexturing render state and add the TextureUnitState to the list of states that they manage.
The only problem with that is that FFPTexturing takes care of the blending code, but we don't want these 'utility textures' to be part of the blending pipeline. I guess the easy solution for that would be to add an 'isUtility' flag to the TextureUnitParams (or similar) so that FFPTexturing will know not to use it as part of the blending. It will just expose a variable containing the calculated texcoord that the user (normal mapper in this case) will be able to access and use.

Another optimization question arises - if the texture matrix (and other params) are the same as an existing texture unit, the shader will calculate the same texcoords twice. This unnecessarily increases the bandwidth between the VS and PS, and adds some overhead to the vertex shader. Perhaps (in a later stage) we should also add option #2 (parent texcoord index) later.
User avatar
Nir Hasson
OGRE Retired Team Member
OGRE Retired Team Member
Posts: 363
Joined: Wed Nov 05, 2008 4:40 pm
Location: TLV - Israel
x 2
Contact:

Re: RT Shader System Component (RTSS)

Post by Nir Hasson »

That direction sounds good to me - I mean the texture unit usage via the texturing SubRenderState.
Adding static method to the texturing stage that gets the VS and PS programs + texture unit and handles all of the needed code in that place might be a “clean” solution.
Also keep in mind that the same functionality that you enable now from script should be available via code at application runtime stage.
User avatar
Noman
OGRE Retired Team Member
OGRE Retired Team Member
Posts: 714
Joined: Mon Jan 31, 2005 7:21 pm
Location: Israel
x 2
Contact:

Re: RT Shader System Component (RTSS)

Post by Noman »

More progress...
I didn't make the FFPTexturing methods static (because some of them rely on its internal state) but I did make some semi-internal functions public in order to be accessed from the outside.
Essentially, you can create TextureUnitParams instances on your own and use the FFPTexturing instance (that you obtain in preAddToRenderState) to make the function calls.

I had a closer look at normal mapping, and it is indeed a tough task because it not only modifies the normal calculations, it replaces some of them. So it will be hard to combine it with the regular per-pixel-lighter without breaking them into smaller pieces, which might not be worth it.

However, specular mapping is easier, so I will implement it like that.

Will clean up the code and upload a new patch soon...
al2950
OGRE Expert User
OGRE Expert User
Posts: 1227
Joined: Thu Dec 11, 2008 7:56 pm
Location: Bristol, UK
x 157

Re: RT Shader System Component (RTSS)

Post by al2950 »

Quick Question.....

Where should poeple put there custom made subRenderStates to share with the Ogre community? Could we have a wiki page, or maybe a single forum post for them all?

PS. There are a few things missing from the documentation (wiki page & api) that would make it easier for everyone to get up to speed with RTSS, I think i am nearly there although I am still confused about some things, especially at looking at the built in renderStates (ie PSSM). Are you going to add a bit more documentation!?

ok not such a quick question! What i got confused about was the line below found the the PSSM shader renderState, i dont understand how that line will always give the specular parameter;

Code: Select all

	mPSSpecualr = psMain->getParameterBySemantic(psMain->getInputParameters(), Parameter::SPS_COLOR, 1);
	if (mPSSpecualr.get() == NULL)	
	{
		mPSSpecualr = psMain->getParameterBySemantic(psMain->getLocalParameters(), Parameter::SPS_COLOR, 1);
		if (mPSSpecualr.get() == NULL)	
			return false;
	}
I have used this in my code, which makes more sense to me

Code: Select all

    mPSOutSpecular = psMain->getParameterByContent(psMain->getLocalParameters(), Parameter::SPC_COLOR_SPECULAR, GCT_FLOAT4);
	if (mPSOutSpecular.get() == NULL)
		return false;
User avatar
Nir Hasson
OGRE Retired Team Member
OGRE Retired Team Member
Posts: 363
Joined: Wed Nov 05, 2008 4:40 pm
Location: TLV - Israel
x 2
Contact:

Re: RT Shader System Component (RTSS)

Post by Nir Hasson »

Hi al,

You can create a patch of your custom sub-render state.
The best place will be the ShaderSystem demo in order to demonstrate it.
Regarding the docs - I know it's far from being perfect - but personally I can't see myself writing more docs in the near future..
For your question - the first attempt is to get the specular colour as it passed from the vertex shader.
In case it doesn't exist the second attempt will grab a local defined specular colour variable.
Your code will work well for all the cases where local specular parameter has been declared.
al2950
OGRE Expert User
OGRE Expert User
Posts: 1227
Joined: Thu Dec 11, 2008 7:56 pm
Location: Bristol, UK
x 157

Re: RT Shader System Component (RTSS)

Post by al2950 »

I appreciate i could just as easily contribute to the documentation, and I appreciate all the work you have done so far :D . So i have spent a little time trawling through the code to better understand the system. Could you please make sure my following statements are correct. Oh and I have a spec map shader, but i might wait untill Noman has finished with the nested texture units, before submitting a patch.

The PSSM shader gets the specular colour by looking at the the 2nd Colour semantic. However this is only true the render state has used FFP_COLOUR ?? You will always include FFP_COLOUR sub render state if you create a shader based technique using the method "createShaderBasedTechnique" AND have "RTSHADER_SYSTEM_BUILD_CORE_SHADERS!" is defined. ?

However, and this is where my understanding is lacking, a custom sub render state could override FFP_COLOUR and produce different parameters. (EG Diffuse Colour could be semantic index 1 and the specular could be index 0)??

This is one thing I could not follow in the code. I know the normal map lighting overrides the per pixel lighting sub render state, and i am pretty sure it is done via having the same execution order. Could you please point me to the area in the code where it works out the custom sub render state should override the core shader sub render state.

Cheers

PS. If i am happy with my understanding i might try and update documentation showing how to make a custom sub render state using the Spec Map as an example as its very simple :D
User avatar
Noman
OGRE Retired Team Member
OGRE Retired Team Member
Posts: 714
Joined: Mon Jan 31, 2005 7:21 pm
Location: Israel
x 2
Contact:

Re: RT Shader System Component (RTSS)

Post by Noman »

I have an implementation of specular mapping, I need to clean it up a bit before adding it to Ogre / RTSS sample. Hopefully I'll have time to clean it up by the end of the week.
User avatar
Nir Hasson
OGRE Retired Team Member
OGRE Retired Team Member
Posts: 363
Joined: Wed Nov 05, 2008 4:40 pm
Location: TLV - Israel
x 2
Contact:

Re: RT Shader System Component (RTSS)

Post by Nir Hasson »

@al
The PSSM shader gets the specular colour by looking at the the 2nd Colour semantic. However this is only true the render state has used FFP_COLOUR ?? You will always include FFP_COLOUR sub render state if you create a shader based technique using the method "createShaderBasedTechnique" AND have "RTSHADER_SYSTEM_BUILD_CORE_SHADERS!" is defined. ?
The FFP_Colour sub render state is always included in the renderstate when RTSHADER_SYSTEM_BUILD_CORE_SHADERS is defined. See ShaderGenerator.cpp

Code: Select all

FFPRenderStateBuilder::getSingleton().buildRenderState(this, mTargetRenderState);
.
However, and this is where my understanding is lacking, a custom sub render state could override FFP_COLOUR and produce different parameters. (EG Diffuse Colour could be semantic index 1 and the specular could be index 0)??
In case that one overrides the FFP_Colour sub render state, he should stay consistent with output standards of the FFP to avoid such a mess.
As you expect that one that overrides FFP_Transform will send it’s output position to the POSITION semantic, then you should expect the same with every other FFP stage override.

This is one thing I could not follow in the code. I know the normal map lighting overrides the per pixel lighting sub render state, and i am pretty sure it is done via having the same execution order. Could you please point me to the area in the code where it works out the custom sub render state should override the core shader sub render state.
The point you are looking starts at the

Code: Select all

FFPRenderStateBuilder::buildFFPSubRenderState
method, where the FFPBuilder builds the given subrender state.
It calls the source SGPass to check if custom subrender state overrides this stage.
Look at

Code: Select all

ShaderGenerator::SGPass::getCustomFFPSubState
to see how it is done. First it looks in the private custom render state of this pass, if non exists it looks in the global render state of the scheme. That way you can force per-pixel lighting for the whole scheme.
If no custom subrender state found – the FFPBuilder create the default FFP stage sub render state.

@Noman
It would be great to see it in the sample and as an extension of the lib if possible.
User avatar
trilobite
Silver Sponsor
Silver Sponsor
Posts: 135
Joined: Thu Jul 13, 2006 9:16 pm
Location: San Juan Capistrano, CA, USA
x 1

Re: RT Shader System Component (RTSS) - shadow artifacts

Post by trilobite »

I am using the pssm depth shadow map facility that is included in the RTShader System -- based on code in the RTShader sample.
I am trying to configure the system, but I am not having success.
In many configurations large dark shadow artifacts flicker at far right or far left of the scene. Some settings put these large artifacts permanently short distances away.
Here is an image to show what I mean...
Image

I have spent hours experimenting with different combinations of values. Each has tradeoffs of one kind or another.
Settings that give finer detail result in larger and closer distant artifacts. Settings that push the distant artifacts off the map produce less detail and more flickering.
I know that shadows are the ultimate alchemy of this enterprise, so I'm not surprised.
Still, I thought I would post a query here.
Thanks.

And to be thorough, I am including the code I am using...

Code: Select all

void pbShaderManager::CreateShadows(Ogre::SceneManager* pSceneMgr, Ogre::Camera *pCamera, int iShadowType)
{    
    if (mShaderGenerator)
    {
    // Grab the scheme render state.                                                
    Ogre::RTShader::RenderState* schemRenderState = mShaderGenerator->getRenderState(Ogre::RTShader::ShaderGenerator::DEFAULT_SCHEME_NAME);

    // No shadow
    if (iShadowType == 0)
    {
        pSceneMgr->setShadowTechnique(SHADOWTYPE_NONE);

#ifdef RTSHADER_SYSTEM_BUILD_EXT_SHADERS
        const Ogre::RTShader::SubRenderStateList& subRenderStateList = schemRenderState->getTemplateSubRenderStateList();
        Ogre::RTShader::SubRenderStateListConstIterator it = subRenderStateList.begin();
        Ogre::RTShader::SubRenderStateListConstIterator itEnd = subRenderStateList.end();

        for (; it != itEnd; ++it)
        {
            Ogre::RTShader::SubRenderState* curSubRenderState = *it;

            // This is the pssm3 sub render state -> remove it.
            if (curSubRenderState->getType() == Ogre::RTShader::IntegratedPSSM3::Type)
            {
                schemRenderState->removeTemplateSubRenderState(*it);
                break;
            }
        }
#endif

    }

#ifdef RTSHADER_SYSTEM_BUILD_EXT_SHADERS
    // Integrated shadow PSSM with 3 splits.
    else if (iShadowType == 1)
    {
        pSceneMgr->setShadowTechnique(SHADOWTYPE_TEXTURE_MODULATIVE_INTEGRATED);

        // 3 textures per directional light
        pSceneMgr->setShadowTextureCountPerLightType(Ogre::Light::LT_DIRECTIONAL, 3);
        pSceneMgr->setShadowTextureSettings(512, 3, PF_FLOAT32_R);
        pSceneMgr->setShadowTextureSelfShadow(true);    //    true

        // Set up caster material - this is just a standard depth/shadow map caster
        pSceneMgr->setShadowTextureCasterMaterial("PSSM/shadow_caster");
    
        // Disable fog on the caster pass.
        MaterialPtr passCaterMaterial = MaterialManager::getSingleton().getByName("PSSM/shadow_caster");
        Pass* pssmCasterPass = passCaterMaterial->getTechnique(0)->getPass(0);
        pssmCasterPass->setFog(true);

        // shadow camera setup
        PSSMShadowCameraSetup* pssmSetup = new PSSMShadowCameraSetup();

        pssmSetup->calculateSplitPoints(3, pCamera->getNearClipDistance(),  pSceneMgr->getShadowFarDistance());
//        equates to pssmSetup->calculateSplitPoints(3, 1, 11000);

        pssmSetup->setSplitPadding(pCamera->getNearClipDistance());
//        equates to pssmSetup->setSplitPadding(1);

        pssmSetup->setOptimalAdjustFactor(0, 2);
        pssmSetup->setOptimalAdjustFactor(1, 1);
        pssmSetup->setOptimalAdjustFactor(2, 0.5);

//        these are the original settings that don't look too bad... little flickering on vehicles. Lots of distant shadow artifacts.
//        pssmSetup->calculateSplitPoints(3, 5, 3000);
//        pssmSetup->setSplitPadding(10);
//        pssmSetup->setOptimalAdjustFactor(0, 2);
//        pssmSetup->setOptimalAdjustFactor(1, 1);
//        pssmSetup->setOptimalAdjustFactor(2, 0.5);

        pSceneMgr->setShadowCameraSetup(ShadowCameraSetupPtr(pssmSetup));
    
        Ogre::RTShader::SubRenderState* subRenderState = mShaderGenerator->createSubRenderState(Ogre::RTShader::IntegratedPSSM3::Type);    
        Ogre::RTShader::IntegratedPSSM3* pssm3SubRenderState = static_cast<Ogre::RTShader::IntegratedPSSM3*>(subRenderState);
        const PSSMShadowCameraSetup::SplitPointList& srcSplitPoints = pssmSetup->getSplitPoints();
        Ogre::RTShader::IntegratedPSSM3::SplitPointList dstSplitPoints;

        for (unsigned int i=0; i < srcSplitPoints.size(); ++i)
        {
            dstSplitPoints.push_back(srcSplitPoints[i]);
        }

        pssm3SubRenderState->setSplitPoints(dstSplitPoints);
        schemRenderState->addTemplateSubRenderState(subRenderState);        
    }
#endif

    // Invalidate the scheme in order to re-generate all shaders based technique related to this scheme.
    mShaderGenerator->invalidateScheme(Ogre::RTShader::ShaderGenerator::DEFAULT_SCHEME_NAME);
    }
}
User avatar
Nir Hasson
OGRE Retired Team Member
OGRE Retired Team Member
Posts: 363
Joined: Wed Nov 05, 2008 4:40 pm
Location: TLV - Israel
x 2
Contact:

Re: RT Shader System Component (RTSS)

Post by Nir Hasson »

Hi trilobite – shadows has been always a great pain in the .. you know.. :wink:
Regarding your issues – I can almost be sure that it has nothing to do with the generated shader code. From my experience – each scene has its own unique issues and adjustments you have to find in order to make the shadows work properly.
I would recommend you to run perfHUD (hopefully you’ve got nVidia card) and see the flickering reason in your own eyes. Other than that you can always use the good old methods of displaying the shadow map(s) over an overlay(s) and see the results for your self.
In your case I bet there is some situation where the terrain tile is not being rendered to the shadow map.. but you’ll be smarter when you’ll see the debug information in your own eyes.
Another thing you may consider is to write your own shadow camera setup.
Good luck with that – you’ll find the golden way eventually.. :D
factions
Gnoblar
Posts: 8
Joined: Mon Oct 04, 2010 10:36 am

Re: RT Shader System Component (RTSS)

Post by factions »

Is there a sample of using this besides one in the Ogre samples?
al2950
OGRE Expert User
OGRE Expert User
Posts: 1227
Joined: Thu Dec 11, 2008 7:56 pm
Location: Bristol, UK
x 157

Re: RT Shader System Component (RTSS)

Post by al2950 »

Have a look at the wiki, its not in a very obvious place!

http://www.ogre3d.org/tikiwiki/RT+Shade ... light=rtss
User avatar
jacmoe
OGRE Retired Moderator
OGRE Retired Moderator
Posts: 20570
Joined: Thu Jan 22, 2004 10:13 am
Location: Denmark
x 179
Contact:

Re: RT Shader System Component (RTSS)

Post by jacmoe »

It's obvious to me:
http://www.ogre3d.org/tikiwiki/Ogre+Cor ... evelopment
Articles on Ogre core features, written (primarily) by the Ogre team.
/* Less noise. More signal. */
Ogitor Scenebuilder - powered by Ogre, presented by Qt, fueled by Passion.
OgreAddons - the Ogre code suppository.
User avatar
jacmoe
OGRE Retired Moderator
OGRE Retired Moderator
Posts: 20570
Joined: Thu Jan 22, 2004 10:13 am
Location: Denmark
x 179
Contact:

Re: RT Shader System Component (RTSS)

Post by jacmoe »

But that's probably because I organised the wiki:
http://www.ogre3d.org/tikiwiki/tiki-ind ... n_Sections :wink:
/* Less noise. More signal. */
Ogitor Scenebuilder - powered by Ogre, presented by Qt, fueled by Passion.
OgreAddons - the Ogre code suppository.
factions
Gnoblar
Posts: 8
Joined: Mon Oct 04, 2010 10:36 am

Re: RT Shader System Component (RTSS)

Post by factions »

Thank you :oops: I did not see that tutorial when I looked. Is there a list of shaders that come with it? Tutorial says community can write more, but there is no mention of what shaders it has by default. Does it still need hlsl/cg/etc files or is it all code?
al2950
OGRE Expert User
OGRE Expert User
Posts: 1227
Joined: Thu Dec 11, 2008 7:56 pm
Location: Bristol, UK
x 157

Re: RT Shader System Component (RTSS)

Post by al2950 »

If you have a look at the source files its quite obvious, but it depends on which version of Ogre you have. The latest version (1,8) has
  • All Fixed Function Pipeline (It will automatically convert FFP materials to shader ones)
  • Per Pixel Lighting
  • PSSM Shadows
  • Normal maps
  • Reflection maps
  • Hardware Skinning
  • Photoshop blend modes
  • I Think Specular maps has been added, if not then it will be soon. (I have working version if anyone wants it)
Thats a quick lists off the top of my head, but i have not looked at it for a while.
CrimsonGT
Greenskin
Posts: 120
Joined: Thu Sep 20, 2007 10:13 am

Re: RT Shader System Component (RTSS)

Post by CrimsonGT »

This looks amazing, can't believe I didn't notice it until now. What are the limitations put on it? I am just wondering if it has all of the same capabilities as writing a normal shader file. I have been wanting to do a refraction shader for ages, as similar to this video as possible http://www.dailymotion.com/video/x7vbsz ... -ogre_tech

He outlined his method in the thread, I have included them below. I have never written a shader from scratch, but I would definitely like to try adding this to RTSS as an extension if it would be possible.
The render process is done in 3 times:
1- Render on Texture of all object which are behind the transparent objet (RT0) - this is the background
2- Render on Texture of the transparent objet but only its backface (RT1) using a specific shader to code XY offset distortion in color of each pixel. Falloff is too coded in third color componant.
3- Render on screen using special shader (for transparent object, only its frontface) which combine RT0 and RT1 to create Transparency and Distortion.

More details:
1- RT0
No difficulty, here i have just do a render of object which are behind the transparent objet
Image

2- RT1
Here i have render only the backface of the transparent objet.
I use a shader which code the XY offset of each pixel using Red and Green color.
The offset is given by the normal face transformed in WorldView.
I use too the Blue color to keep the falloff value.
Image

Only the offset coded in Red & Green:
Image

Only the falloff coded in Blue:
Image

3- Render on screen
Here the scene is normaly rendered but our transparent object is rendered using a shader which combine RT0 and RT1, and only its frontface are drawn.
This shader do that:
- Compute distortion offset (like shader for RT1 have done for backFace)
- Combine backface distortion offset which are coded in RT1 (red & Green color)
- Compute falloff using normal of the face to have a better render
- Combine previously computed falloff with backface falloff which is coded in RT1 (Blue color)
- Compute final pixel color using:
* background color taked on RT0 (using UV distroded by offset)
* Combined falloff value
* A soft specular highlight
* A soft environment mapping
Image


Finaly there is 2 distortion, in backface and in frontface.
The final pixel color is take on the background (RT0) but using an UV moved of some pixel by distortion.
After have take the good pixel on background (RT0) we apply somme effect (Falloff, Specular, EnvMap) to change (juste a little) color to have render like Ice, Plexiglass ...
al2950
OGRE Expert User
OGRE Expert User
Posts: 1227
Joined: Thu Dec 11, 2008 7:56 pm
Location: Bristol, UK
x 157

Re: RT Shader System Component (RTSS)

Post by al2950 »

@CrimsonGT

I would try to start off with something a little easier! That technique is fairly complicated in that it does a full screen render first, this is not something that you would do with the RTSS. You most certainly could do it manually and pass it in though.

@Nir & @trilobite
Guys....
I have found an issue with the PSSM shader in that it all goes wrong if you have more than one light even though you have configured only to have one light casting shadows. The first problem is that in a single pass the shadow is applied to the combined light colour instead of just the shadow cast light. The other problem is it can create some nasty flickering issues which I have not worked out yet. This may have been the problem trilobite was seeing as I think you are using caelum and you may not have set the option "forceSingleLightSource"
User avatar
Azgur
Goblin
Posts: 264
Joined: Thu Aug 21, 2008 4:48 pm

Re: RT Shader System Component (RTSS)

Post by Azgur »

CrimsonGT wrote:This looks amazing, can't believe I didn't notice it until now. What are the limitations put on it? I am just wondering if it has all of the same capabilities as writing a normal shader file. I have been wanting to do a refraction shader for ages, as similar to this video as possible http://www.dailymotion.com/video/x7vbsz ... -ogre_tech

He outlined his method in the thread, I have included them below. I have never written a shader from scratch, but I would definitely like to try adding this to RTSS as an extension if it would be possible.
This actually more sounds like a job for the new compositor framework. Considering it involves multiple render passes.
User avatar
Nir Hasson
OGRE Retired Team Member
OGRE Retired Team Member
Posts: 363
Joined: Wed Nov 05, 2008 4:40 pm
Location: TLV - Israel
x 2
Contact:

Re: RT Shader System Component (RTSS)

Post by Nir Hasson »

@al2950

This sounds interesting, I'll take a look in the next days to see if I can spot something.
It should be easy to modify the ShaderSystem sample in order to check it out.
Thanks for your observation.
Post Reply