RT Shader System Component (RTSS)
- Nir Hasson
- 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)
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..
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..
- Noman
- 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)
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
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
- Nir Hasson
- 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)
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..
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..
- Noman
- 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)
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...
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...
- Noman
- 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)
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:
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
}
}
}
}
}
}
- Noman
- 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)
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.
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.
- Nir Hasson
- 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)
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.
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.
- Noman
- 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)
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...
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...
-
- OGRE Expert User
- Posts: 1227
- Joined: Thu Dec 11, 2008 7:56 pm
- Location: Bristol, UK
- x 157
Re: RT Shader System Component (RTSS)
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;
I have used this in my code, which makes more sense to me
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;
}
Code: Select all
mPSOutSpecular = psMain->getParameterByContent(psMain->getLocalParameters(), Parameter::SPC_COLOR_SPECULAR, GCT_FLOAT4);
if (mPSOutSpecular.get() == NULL)
return false;
- Nir Hasson
- 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)
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.
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.
-
- OGRE Expert User
- Posts: 1227
- Joined: Thu Dec 11, 2008 7:56 pm
- Location: Bristol, UK
- x 157
Re: RT Shader System Component (RTSS)
I appreciate i could just as easily contribute to the documentation, and I appreciate all the work you have done so far . 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
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
- Noman
- 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)
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.
- Nir Hasson
- 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)
@al
.
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.
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 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.
The FFP_Colour sub render state is always included in the renderstate when RTSHADER_SYSTEM_BUILD_CORE_SHADERS is defined. See ShaderGenerator.cppThe 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. ?
Code: Select all
FFPRenderStateBuilder::getSingleton().buildRenderState(this, mTargetRenderState);
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.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)??
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.
The point you are looking starts at theThis 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.
Code: Select all
FFPRenderStateBuilder::buildFFPSubRenderState
It calls the source SGPass to check if custom subrender state overrides this stage.
Look at
Code: Select all
ShaderGenerator::SGPass::getCustomFFPSubState
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.
- trilobite
- 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
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...
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...
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...
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);
}
}
- Nir Hasson
- 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)
Hi trilobite – shadows has been always a great pain in the .. you know..
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..
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..
-
- Gnoblar
- Posts: 8
- Joined: Mon Oct 04, 2010 10:36 am
Re: RT Shader System Component (RTSS)
Is there a sample of using this besides one in the Ogre samples?
-
- OGRE Expert User
- Posts: 1227
- Joined: Thu Dec 11, 2008 7:56 pm
- Location: Bristol, UK
- x 157
Re: RT Shader System Component (RTSS)
Have a look at the wiki, its not in a very obvious place!
http://www.ogre3d.org/tikiwiki/RT+Shade ... light=rtss
http://www.ogre3d.org/tikiwiki/RT+Shade ... light=rtss
- jacmoe
- OGRE Retired Moderator
- Posts: 20570
- Joined: Thu Jan 22, 2004 10:13 am
- Location: Denmark
- x 179
- Contact:
Re: RT Shader System Component (RTSS)
It's obvious to me:
http://www.ogre3d.org/tikiwiki/Ogre+Cor ... evelopment
Articles on Ogre core features, written (primarily) by the Ogre team.
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.
Ogitor Scenebuilder - powered by Ogre, presented by Qt, fueled by Passion.
OgreAddons - the Ogre code suppository.
- jacmoe
- OGRE Retired Moderator
- Posts: 20570
- Joined: Thu Jan 22, 2004 10:13 am
- Location: Denmark
- x 179
- Contact:
Re: RT Shader System Component (RTSS)
But that's probably because I organised the wiki:
http://www.ogre3d.org/tikiwiki/tiki-ind ... n_Sections
http://www.ogre3d.org/tikiwiki/tiki-ind ... n_Sections
/* Less noise. More signal. */
Ogitor Scenebuilder - powered by Ogre, presented by Qt, fueled by Passion.
OgreAddons - the Ogre code suppository.
Ogitor Scenebuilder - powered by Ogre, presented by Qt, fueled by Passion.
OgreAddons - the Ogre code suppository.
-
- Gnoblar
- Posts: 8
- Joined: Mon Oct 04, 2010 10:36 am
Re: RT Shader System Component (RTSS)
Thank you 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?
-
- OGRE Expert User
- Posts: 1227
- Joined: Thu Dec 11, 2008 7:56 pm
- Location: Bristol, UK
- x 157
Re: RT Shader System Component (RTSS)
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)
-
- Greenskin
- Posts: 120
- Joined: Thu Sep 20, 2007 10:13 am
Re: RT Shader System Component (RTSS)
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.
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 ...
-
- OGRE Expert User
- Posts: 1227
- Joined: Thu Dec 11, 2008 7:56 pm
- Location: Bristol, UK
- x 157
Re: RT Shader System Component (RTSS)
@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"
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"
- Azgur
- Goblin
- Posts: 264
- Joined: Thu Aug 21, 2008 4:48 pm
Re: RT Shader System Component (RTSS)
This actually more sounds like a job for the new compositor framework. Considering it involves multiple render passes.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.
- Nir Hasson
- 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)
@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.
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.