[2.2]Porting my engine to 2.2
-
- OGRE Expert User
- Posts: 1148
- Joined: Sat Jul 06, 2013 10:59 pm
- Location: Chile
- x 168
Re: [2.2]Porting my engine to 2.2
Ok, another clue, everything that has nothing behind gets the problem, that's why when I have some thickness it looks good, I am going to make a gif describing the problem
-
- OGRE Expert User
- Posts: 1148
- Joined: Sat Jul 06, 2013 10:59 pm
- Location: Chile
- x 168
- dark_sylinc
- OGRE Team Member
- Posts: 5296
- Joined: Sat Jul 21, 2007 4:55 pm
- Location: Buenos Aires, Argentina
- x 1278
- Contact:
Re: [2.2]Porting my engine to 2.2
Is this with reverse_depth off or on?
I am not 100% sure what I am looking at. Is it possible to make an easy repro? It looks like it...
I am not 100% sure what I am looking at. Is it possible to make an easy repro? It looks like it...
-
- OGRE Expert User
- Posts: 1148
- Joined: Sat Jul 06, 2013 10:59 pm
- Location: Chile
- x 168
Re: [2.2]Porting my engine to 2.2
reverse_depth off ( params["reverse_depth"] = "No"; ) I guess No also works? :S
its like if the black background is in front the plane (from the light's perspective) so it cast a shadow in front of the right plane, the left plane is there just to show how the shadow appears on the right plane just when the left plane's shadow reach the border of the green floor (aka the black background overlaps the right plane)
I can do a repro later tonight o maybe tomorrow
its like if the black background is in front the plane (from the light's perspective) so it cast a shadow in front of the right plane, the left plane is there just to show how the shadow appears on the right plane just when the left plane's shadow reach the border of the green floor (aka the black background overlaps the right plane)
I can do a repro later tonight o maybe tomorrow
-
- OGRE Expert User
- Posts: 1148
- Joined: Sat Jul 06, 2013 10:59 pm
- Location: Chile
- x 168
Re: [2.2]Porting my engine to 2.2
hello, I ow you the repro about the shadow problem.. for now I move to another stuff, so this is my next problem:
I am porting my ocean, and I have a 3D texture, which I am pretty certain that I created with mipmaps but it looks ver aliased far away, so I checked (getNumMipmaps()) andit says that it has 1 mipmap, so I checked with Ogre2.1 (were it looks fine) and it says 8
how can I load a 3D texture with mipmaps?
I am porting my ocean, and I have a 3D texture, which I am pretty certain that I created with mipmaps but it looks ver aliased far away, so I checked (getNumMipmaps()) andit says that it has 1 mipmap, so I checked with Ogre2.1 (were it looks fine) and it says 8
how can I load a 3D texture with mipmaps?
- dark_sylinc
- OGRE Team Member
- Posts: 5296
- Joined: Sat Jul 21, 2007 4:55 pm
- Location: Buenos Aires, Argentina
- x 1278
- Contact:
Re: [2.2]Porting my engine to 2.2
Is this 3D texture loaded from a dds file?
There could be a bug.
Is it created manually?
Then you must call setNumMipmaps( 8 ); (or 9?) before transitioning to resident.
There could be a bug.
Is it created manually?
Then you must call setNumMipmaps( 8 ); (or 9?) before transitioning to resident.
- dark_sylinc
- OGRE Team Member
- Posts: 5296
- Joined: Sat Jul 21, 2007 4:55 pm
- Location: Buenos Aires, Argentina
- x 1278
- Contact:
Re: [2.2]Porting my engine to 2.2
Yes please. At first I thought it could be a problem inherent with reverse depth, but from what you're saying (reverse_depth is off) it must be a silly code bug.
Btw remember you can export scenes using SceneExporter.
-
- OGRE Expert User
- Posts: 1148
- Joined: Sat Jul 06, 2013 10:59 pm
- Location: Chile
- x 168
Re: [2.2]Porting my engine to 2.2
yes is a file
I solved the problem with Ogre::TextureFilter::TypeGenerateHwMipmaps, maybe I was wrong and my texture didnt have mipmaps and Ogre2.1 generate them by default?
can I do that even if I don't load a single thing from .mesh/.material files?dark_sylinc wrote: ↑Tue Jan 22, 2019 4:24 am Btw remember you can export scenes using SceneExporter.
- dark_sylinc
- OGRE Team Member
- Posts: 5296
- Joined: Sat Jul 21, 2007 4:55 pm
- Location: Buenos Aires, Argentina
- x 1278
- Contact:
Re: [2.2]Porting my engine to 2.2
Yes, 2.1 generated them by default.
It doesn't mean 2.2 is bug-free a though. IF the dds file has mipmaps, then it is a bug either in the dds loader, or in the TextureGpuManager/Image2.
Yes, even if the meshes, textures and materials were all generated by code, they will be exported. The compo script is not exported though, so I would need to see how it is set up (though it's probably easy to repro)xrgo wrote: ↑Tue Jan 22, 2019 4:35 amcan I do that even if I don't load a single thing from .mesh/.material files?dark_sylinc wrote: ↑Tue Jan 22, 2019 4:24 am Btw remember you can export scenes using SceneExporter.
-
- OGRE Expert User
- Posts: 1148
- Joined: Sat Jul 06, 2013 10:59 pm
- Location: Chile
- x 168
Re: [2.2]Porting my engine to 2.2
tbh I have no idea how to confirm that
niiiiiiice!
- dark_sylinc
- OGRE Team Member
- Posts: 5296
- Joined: Sat Jul 21, 2007 4:55 pm
- Location: Buenos Aires, Argentina
- x 1278
- Contact:
Re: [2.2]Porting my engine to 2.2
Visual Studio can open DDS files.
Also DirectX Texture tool.
If the DDS has mipmaps, you'll be able to check them. Else those options will be greyed out and the options to generate them will be present.
-
- OGRE Expert User
- Posts: 1148
- Joined: Sat Jul 06, 2013 10:59 pm
- Location: Chile
- x 168
Re: [2.2]Porting my engine to 2.2
Thanks! didn't knew that visual studio had that capability, so I opened the dds file and it did not have mipmaps =), I can generate them right there but when saving it says that it will only save the first slice, so i'll keep the ogre's filter to generate them at runtime
thank you!!
thank you!!
-
- OGRE Expert User
- Posts: 1148
- Joined: Sat Jul 06, 2013 10:59 pm
- Location: Chile
- x 168
Re: [2.2]Porting my engine to 2.2
Hello! I was away a few weeks but now I am back! to continue the porting! I have just a few pending stuffs!
the next problem is:
I ported my Ocean, which uses planar reflections (just to generate the reflection texture, I apply it in a different way) but now when enabling mReuseCullData for my right eye it uses the culling data from the planar reflection pass, so I see everything in the left eye and just the reflected objects in the right eye =(
its the same code I had before porting.
I think what's going on is that when doing the left eye scene pass, first does the culling process, then renders the reflection workspace (and inside it does its culling process), then it actually finish rendering the left eye.. then when rendering the right eye it uses the last culling data which is the relfection's one.
sadly I can't check that because today I updated Ogre and now I get a crash when using remotery :S
so that's another problem I have to check
is it posible to guarantee do the reflection before processing the culling data for the left eye?
the next problem is:
I ported my Ocean, which uses planar reflections (just to generate the reflection texture, I apply it in a different way) but now when enabling mReuseCullData for my right eye it uses the culling data from the planar reflection pass, so I see everything in the left eye and just the reflected objects in the right eye =(
its the same code I had before porting.
I think what's going on is that when doing the left eye scene pass, first does the culling process, then renders the reflection workspace (and inside it does its culling process), then it actually finish rendering the left eye.. then when rendering the right eye it uses the last culling data which is the relfection's one.
sadly I can't check that because today I updated Ogre and now I get a crash when using remotery :S
pretty sure it was working with the Ogre 2.2 from 3 weeks ago1 Remotery 0x7ff928122109
2 rmt_BeginOpenGLSample Remotery 0x7ff92812600f
3 Ogre::Win32Window::swapBuffers BaseProjectDev 0x7ff75da85397
4 Ogre::CompositorWorkspace::_swapFinalTarget BaseProjectDev 0x7ff75db26e59
5 Ogre::CompositorManager2::_swapAllFinalTargets BaseProjectDev 0x7ff75db1f0b9
6 Ogre::Root::_updateAllRenderTargets BaseProjectDev 0x7ff75da98206
7 Ogre::Root::renderOneFrame BaseProjectDev 0x7ff75da9a7df
so that's another problem I have to check
is it posible to guarantee do the reflection before processing the culling data for the left eye?
-
- OGRE Expert User
- Posts: 1148
- Joined: Sat Jul 06, 2013 10:59 pm
- Location: Chile
- x 168
- dark_sylinc
- OGRE Team Member
- Posts: 5296
- Joined: Sat Jul 21, 2007 4:55 pm
- Location: Buenos Aires, Argentina
- x 1278
- Contact:
Re: [2.2]Porting my engine to 2.2
Check that GL3PlusRenderSystem::initGPUProfiling is getting called before getting there (via Profiler::getSingleton().setEnabled).
And that GL3PlusRenderSystem::deinitGPUProfiling isn't getting called.
See GraphicsSystem::initialize, I remember it got a mild update, but I do not recall if it was for Ogre 2.2
As for the Reflection stuff, I don't think you're correct in your assessment. We do not alter the render order you give us. It's possible that the new CamerasInProgress code either has a small bug, or is asking something new/different from you and the wrong camera (the reflection camera) is being sent.
And that GL3PlusRenderSystem::deinitGPUProfiling isn't getting called.
See GraphicsSystem::initialize, I remember it got a mild update, but I do not recall if it was for Ogre 2.2
As for the Reflection stuff, I don't think you're correct in your assessment. We do not alter the render order you give us. It's possible that the new CamerasInProgress code either has a small bug, or is asking something new/different from you and the wrong camera (the reflection camera) is being sent.
-
- OGRE Expert User
- Posts: 1148
- Joined: Sat Jul 06, 2013 10:59 pm
- Location: Chile
- x 168
Re: [2.2]Porting my engine to 2.2
since I've just updated Ogre i had pending updating MyGui so I just return; in my GuiManager::init, I fixed that, and somehow the profiler works now xD. now I can continue digging the reflection problem
-
- OGRE Expert User
- Posts: 1148
- Joined: Sat Jul 06, 2013 10:59 pm
- Location: Chile
- x 168
Re: [2.2]Porting my engine to 2.2
ok, solved! I had a "mPassSceneDefRight->mIdentifier = 25001;" in the right eye, removing it solves the culling problem, I had to adjust some shaders after but its working great now. It makes me think why it was working with 2.1 :S, but no time to solve that mistery, must continue with the next thing
thanks!!!!
thanks!!!!
-
- OGRE Expert User
- Posts: 1148
- Joined: Sat Jul 06, 2013 10:59 pm
- Location: Chile
- x 168
Re: [2.2]Porting my engine to 2.2
neeeext problem! alpha test shadows aren't working
I see that in calculateHashForPreCaster it does enter the if( hasAlphaTest ) and I can see the texture in datablock->mTexturesDescSet... the shader is (aparently) being generated correctly... but I did a renderDoc capture and the textureMaps0 says No resource.
I'll keep digging
edit: more info
Its also reaching here:
with the right texture on mTexturesDescSet in fillBuffersFor
I see that in calculateHashForPreCaster it does enter the if( hasAlphaTest ) and I can see the texture in datablock->mTexturesDescSet... the shader is (aparently) being generated correctly... but I did a renderDoc capture and the textureMaps0 says No resource.
I'll keep digging
edit: more info
Its also reaching here:
Code: Select all
//---------------------------------------------------------------------------
// ---- PIXEL SHADER ----
//---------------------------------------------------------------------------
if( !casterPass || datablock->getAlphaTest() != CMPF_ALWAYS_PASS )
{
#ifdef OGRE_BUILD_COMPONENT_PLANAR_REFLECTIONS
if( mHasPlanarReflections &&
(queuedRenderable.renderable->mCustomParameter & 0x80) &&
mLastBoundPlanarReflection != queuedRenderable.renderable->mCustomParameter )
{
const uint8 activeActorIdx = queuedRenderable.renderable->mCustomParameter & 0x7F;
TextureGpu *planarReflTex = mPlanarReflections->getTexture( activeActorIdx );
*commandBuffer->addCommand<CbTexture>() =
CbTexture( mTexUnitSlotStart - 1u, planarReflTex,
mPlanarReflectionsSamplerblock );
mLastBoundPlanarReflection = queuedRenderable.renderable->mCustomParameter;
}
#endif
if( datablock->mTexturesDescSet != mLastDescTexture )
{
if( datablock->mTexturesDescSet )
{
//Rebind textures
size_t texUnit = mTexUnitSlotStart;
//IT DOES REACH HERE
*commandBuffer->addCommand<CbTextures>() =
CbTextures( texUnit, datablock->mCubemapIdxInDescSet,
datablock->mTexturesDescSet );
if( !mHasSeparateSamplers )
{
*commandBuffer->addCommand<CbSamplers>() =
CbSamplers( texUnit, datablock->mSamplersDescSet );
}
//texUnit += datablock->mTexturesDescSet->mTextures.size();
}
mLastDescTexture = datablock->mTexturesDescSet;
}
if( datablock->mSamplersDescSet != mLastDescSampler && mHasSeparateSamplers )
{
if( datablock->mSamplersDescSet )
{
//Bind samplers
size_t texUnit = mTexUnitSlotStart;
*commandBuffer->addCommand<CbSamplers>() =
CbSamplers( texUnit, datablock->mSamplersDescSet );
mLastDescSampler = datablock->mSamplersDescSet;
}
}
}
- dark_sylinc
- OGRE Team Member
- Posts: 5296
- Joined: Sat Jul 21, 2007 4:55 pm
- Location: Buenos Aires, Argentina
- x 1278
- Contact:
Re: [2.2]Porting my engine to 2.2
The most likely explanations:
1. This is wrong:
Hence, the textures are being bound at the wrong slot.
Alternatively...
2. This is wrong:
Hence the shader is expecting the texture to be bound at the wrong slot. This is the most likely cause, since I see HlmsPbs::notifyPropertiesMergedPreGenerationStep checking if this is a shadow caster pass on once (by retrieving HlmsBaseProp::ShadowCaster)
If you look at the RenderDoc capture, you can toggle "Show Disabled Items" and "Show Empty Items" to see if a texture is being bound but unused.
1. This is wrong:
Code: Select all
size_t texUnit = mTexUnitSlotStart;
Alternatively...
2. This is wrong:
Code: Select all
const int32 samplerStateStart = texUnit; //<--- The value calculated up to here
{
char tmpData[32];
LwString texName = LwString::FromEmptyPointer( tmpData, sizeof(tmpData) );
texName = "textureMaps";
const size_t baseTexSize = texName.size();
int32 numTextures = getProperty( PbsProperty::NumTextures );
for( int32 i=0; i<numTextures; ++i )
{
texName.resize( baseTexSize );
texName.a( i ); //textureMaps0
setTextureReg( PixelShader, texName.c_str(), texUnit++ );
}
}
If you look at the RenderDoc capture, you can toggle "Show Disabled Items" and "Show Empty Items" to see if a texture is being bound but unused.
-
- OGRE Expert User
- Posts: 1148
- Joined: Sat Jul 06, 2013 10:59 pm
- Location: Chile
- x 168
Re: [2.2]Porting my engine to 2.2
thank you! more info:
In renderdoc I can see the texture is bound at an unused slot 5, but the textureMaps0 is in slot 1, I also checked in code that mTexUnitSlotStart is 5 at that point.
I also checked 2. and I saw a 5 but I also saw a couple of other numbers (I'll have to clean the scene and leave just one object and try again since I don't know which number was for each shader)
Then I disabled the (only one) reflection probe (automatic/perpixel) that my scene had and it works! but Obviously I need them
edit: also, when its working (no probes) the textureMaps0 is in slot 1, I'll keep looking
In renderdoc I can see the texture is bound at an unused slot 5, but the textureMaps0 is in slot 1, I also checked in code that mTexUnitSlotStart is 5 at that point.
I also checked 2. and I saw a 5 but I also saw a couple of other numbers (I'll have to clean the scene and leave just one object and try again since I don't know which number was for each shader)
Then I disabled the (only one) reflection probe (automatic/perpixel) that my scene had and it works! but Obviously I need them
edit: also, when its working (no probes) the textureMaps0 is in slot 1, I'll keep looking
-
- OGRE Expert User
- Posts: 1148
- Joined: Sat Jul 06, 2013 10:59 pm
- Location: Chile
- x 168
Re: [2.2]Porting my engine to 2.2
apparently just adding a !casterPass fixes the problem!!!
would that be the right fix?
Code: Select all
if( !casterPass && mParallaxCorrectedCubemap && !mParallaxCorrectedCubemap->isRendering() )
mTexUnitSlotStart += 1;
- dark_sylinc
- OGRE Team Member
- Posts: 5296
- Joined: Sat Jul 21, 2007 4:55 pm
- Location: Buenos Aires, Argentina
- x 1278
- Contact:
Re: [2.2]Porting my engine to 2.2
Yes, that's the correct fix.
However you pointed out we have several similar cases. Almost all (all?) of the textures that cause mTexUnitSlotStart += 1; shouldn't be getting done for caster passes.
Nice find.
However you pointed out we have several similar cases. Almost all (all?) of the textures that cause mTexUnitSlotStart += 1; shouldn't be getting done for caster passes.
Nice find.
-
- OGRE Expert User
- Posts: 1148
- Joined: Sat Jul 06, 2013 10:59 pm
- Location: Chile
- x 168
-
- OGRE Expert User
- Posts: 1148
- Joined: Sat Jul 06, 2013 10:59 pm
- Location: Chile
- x 168
Re: [2.2]Porting my engine to 2.2
made a PR:
https://bitbucket.org/sinbad/ogre/pull- ... hadow/diff
edit: lol https://bitbucket.org/sinbad/ogre/commi ... d5d2b781e5
well, my PR has 3 things, can you merge the other 2?
https://bitbucket.org/sinbad/ogre/pull- ... hadow/diff
edit: lol https://bitbucket.org/sinbad/ogre/commi ... d5d2b781e5
well, my PR has 3 things, can you merge the other 2?
- dark_sylinc
- OGRE Team Member
- Posts: 5296
- Joined: Sat Jul 21, 2007 4:55 pm
- Location: Buenos Aires, Argentina
- x 1278
- Contact:
Re: [2.2]Porting my engine to 2.2
I put that into my own hands. I had to go through each one of them and compare them against HlmsPbs::fillBuffersFor code.
I also had to go through notifyPropertiesMergedPreGenerationStep, and it seems that was good because those properties are not set during caster passes, except for PbsProperty::IrradianceVolumes which was already handled.
Interesting. You're right.