[2.2]Porting my engine to 2.2

Discussion area about developing with Ogre2 branches (2.1, 2.2 and beyond)
xrgo
OGRE Expert User
OGRE Expert User
Posts: 1064
Joined: Sat Jul 06, 2013 10:59 pm
Location: Chile
x 83

Re: [2.2]Porting my engine to 2.2

Post by xrgo » Fri Jan 18, 2019 7:39 pm

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
0 x

xrgo
OGRE Expert User
OGRE Expert User
Posts: 1064
Joined: Sat Jul 06, 2013 10:59 pm
Location: Chile
x 83

Re: [2.2]Porting my engine to 2.2

Post by xrgo » Fri Jan 18, 2019 7:50 pm

Image
there are two planes here, with opossite normals, and a pointlight moving up and down
as you can see in the left plane is like if the background is casting a shadow
0 x

User avatar
dark_sylinc
OGRE Team Member
OGRE Team Member
Posts: 4138
Joined: Sat Jul 21, 2007 4:55 pm
Location: Buenos Aires, Argentina
x 268
Contact:

Re: [2.2]Porting my engine to 2.2

Post by dark_sylinc » Sat Jan 19, 2019 5:54 pm

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...
0 x

xrgo
OGRE Expert User
OGRE Expert User
Posts: 1064
Joined: Sat Jul 06, 2013 10:59 pm
Location: Chile
x 83

Re: [2.2]Porting my engine to 2.2

Post by xrgo » Sat Jan 19, 2019 10:41 pm

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
0 x

xrgo
OGRE Expert User
OGRE Expert User
Posts: 1064
Joined: Sat Jul 06, 2013 10:59 pm
Location: Chile
x 83

Re: [2.2]Porting my engine to 2.2

Post by xrgo » Tue Jan 22, 2019 4:21 am

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?
0 x

User avatar
dark_sylinc
OGRE Team Member
OGRE Team Member
Posts: 4138
Joined: Sat Jul 21, 2007 4:55 pm
Location: Buenos Aires, Argentina
x 268
Contact:

Re: [2.2]Porting my engine to 2.2

Post by dark_sylinc » Tue Jan 22, 2019 4:23 am

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.
0 x

User avatar
dark_sylinc
OGRE Team Member
OGRE Team Member
Posts: 4138
Joined: Sat Jul 21, 2007 4:55 pm
Location: Buenos Aires, Argentina
x 268
Contact:

Re: [2.2]Porting my engine to 2.2

Post by dark_sylinc » Tue Jan 22, 2019 4:24 am

xrgo wrote:
Tue Jan 22, 2019 4:21 am
hello, I ow you the repro about the shadow problem..
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.
0 x

xrgo
OGRE Expert User
OGRE Expert User
Posts: 1064
Joined: Sat Jul 06, 2013 10:59 pm
Location: Chile
x 83

Re: [2.2]Porting my engine to 2.2

Post by xrgo » Tue Jan 22, 2019 4:35 am

dark_sylinc wrote:
Tue Jan 22, 2019 4:23 am
Is this 3D texture loaded from a dds file?
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?
dark_sylinc wrote:
Tue Jan 22, 2019 4:24 am
Btw remember you can export scenes using SceneExporter.
can I do that even if I don't load a single thing from .mesh/.material files?
0 x

User avatar
dark_sylinc
OGRE Team Member
OGRE Team Member
Posts: 4138
Joined: Sat Jul 21, 2007 4:55 pm
Location: Buenos Aires, Argentina
x 268
Contact:

Re: [2.2]Porting my engine to 2.2

Post by dark_sylinc » Tue Jan 22, 2019 4:46 am

xrgo wrote:
Tue Jan 22, 2019 4:35 am
dark_sylinc wrote:
Tue Jan 22, 2019 4:23 am
Is this 3D texture loaded from a dds file?
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?
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.
xrgo wrote:
Tue Jan 22, 2019 4:35 am
dark_sylinc wrote:
Tue Jan 22, 2019 4:24 am
Btw remember you can export scenes using SceneExporter.
can I do that even if I don't load a single thing from .mesh/.material files?
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)
0 x

xrgo
OGRE Expert User
OGRE Expert User
Posts: 1064
Joined: Sat Jul 06, 2013 10:59 pm
Location: Chile
x 83

Re: [2.2]Porting my engine to 2.2

Post by xrgo » Tue Jan 22, 2019 5:19 am

dark_sylinc wrote:
Tue Jan 22, 2019 4:46 am
IF the dds file has mipmaps
tbh I have no idea how to confirm that
dark_sylinc wrote:
Tue Jan 22, 2019 4:46 am
Yes, even if the meshes
niiiiiiice!
0 x

User avatar
dark_sylinc
OGRE Team Member
OGRE Team Member
Posts: 4138
Joined: Sat Jul 21, 2007 4:55 pm
Location: Buenos Aires, Argentina
x 268
Contact:

Re: [2.2]Porting my engine to 2.2

Post by dark_sylinc » Tue Jan 22, 2019 5:47 am

xrgo wrote:
Tue Jan 22, 2019 5:19 am
dark_sylinc wrote:
Tue Jan 22, 2019 4:46 am
IF the dds file has mipmaps
tbh I have no idea how to confirm that
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.
0 x

xrgo
OGRE Expert User
OGRE Expert User
Posts: 1064
Joined: Sat Jul 06, 2013 10:59 pm
Location: Chile
x 83

Re: [2.2]Porting my engine to 2.2

Post by xrgo » Tue Jan 22, 2019 6:07 am

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!!
2 x

xrgo
OGRE Expert User
OGRE Expert User
Posts: 1064
Joined: Sat Jul 06, 2013 10:59 pm
Location: Chile
x 83

Re: [2.2]Porting my engine to 2.2

Post by xrgo » Thu Feb 14, 2019 9:37 pm

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
1 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
pretty sure it was working with the Ogre 2.2 from 3 weeks ago
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?
0 x

xrgo
OGRE Expert User
OGRE Expert User
Posts: 1064
Joined: Sat Jul 06, 2013 10:59 pm
Location: Chile
x 83

Re: [2.2]Porting my engine to 2.2

Post by xrgo » Thu Feb 14, 2019 10:01 pm

about the remotery crash:

Image

the "stamp" in OpenGLTimestamp_Begin is null, so the assert jumps
0 x

User avatar
dark_sylinc
OGRE Team Member
OGRE Team Member
Posts: 4138
Joined: Sat Jul 21, 2007 4:55 pm
Location: Buenos Aires, Argentina
x 268
Contact:

Re: [2.2]Porting my engine to 2.2

Post by dark_sylinc » Fri Feb 15, 2019 1:41 am

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.
0 x

xrgo
OGRE Expert User
OGRE Expert User
Posts: 1064
Joined: Sat Jul 06, 2013 10:59 pm
Location: Chile
x 83

Re: [2.2]Porting my engine to 2.2

Post by xrgo » Fri Feb 15, 2019 4:27 pm

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
0 x

xrgo
OGRE Expert User
OGRE Expert User
Posts: 1064
Joined: Sat Jul 06, 2013 10:59 pm
Location: Chile
x 83

Re: [2.2]Porting my engine to 2.2

Post by xrgo » Fri Feb 15, 2019 6:12 pm

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!!!!
0 x

xrgo
OGRE Expert User
OGRE Expert User
Posts: 1064
Joined: Sat Jul 06, 2013 10:59 pm
Location: Chile
x 83

Re: [2.2]Porting my engine to 2.2

Post by xrgo » Fri Feb 15, 2019 11:50 pm

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:

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;
                }
            }
        }
with the right texture on mTexturesDescSet in fillBuffersFor
0 x

User avatar
dark_sylinc
OGRE Team Member
OGRE Team Member
Posts: 4138
Joined: Sat Jul 21, 2007 4:55 pm
Location: Buenos Aires, Argentina
x 268
Contact:

Re: [2.2]Porting my engine to 2.2

Post by dark_sylinc » Sun Feb 17, 2019 12:16 am

The most likely explanations:

1. This is wrong:

Code: Select all

size_t texUnit = mTexUnitSlotStart;
Hence, the textures are being bound at the wrong slot.
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++ );
	}
}
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.
0 x

xrgo
OGRE Expert User
OGRE Expert User
Posts: 1064
Joined: Sat Jul 06, 2013 10:59 pm
Location: Chile
x 83

Re: [2.2]Porting my engine to 2.2

Post by xrgo » Sun Feb 17, 2019 7:24 pm

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
0 x

xrgo
OGRE Expert User
OGRE Expert User
Posts: 1064
Joined: Sat Jul 06, 2013 10:59 pm
Location: Chile
x 83

Re: [2.2]Porting my engine to 2.2

Post by xrgo » Sun Feb 17, 2019 8:27 pm

apparently just adding a !casterPass fixes the problem!!!

Code: Select all

        if( !casterPass && mParallaxCorrectedCubemap && !mParallaxCorrectedCubemap->isRendering() )
            mTexUnitSlotStart += 1;
would that be the right fix?
0 x

User avatar
dark_sylinc
OGRE Team Member
OGRE Team Member
Posts: 4138
Joined: Sat Jul 21, 2007 4:55 pm
Location: Buenos Aires, Argentina
x 268
Contact:

Re: [2.2]Porting my engine to 2.2

Post by dark_sylinc » Sun Feb 17, 2019 10:05 pm

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.
0 x

xrgo
OGRE Expert User
OGRE Expert User
Posts: 1064
Joined: Sat Jul 06, 2013 10:59 pm
Location: Chile
x 83

Re: [2.2]Porting my engine to 2.2

Post by xrgo » Sun Feb 17, 2019 10:20 pm

thanks! I am going to make a PR very soon with this and a couple more things


btw, I just tested the new sample UpdatingDecalsAndAreaLightTex and noticed that the "reflection" (I guess its the specular component?) of the area lights should be reflected/flipped

Image
0 x

xrgo
OGRE Expert User
OGRE Expert User
Posts: 1064
Joined: Sat Jul 06, 2013 10:59 pm
Location: Chile
x 83

Re: [2.2]Porting my engine to 2.2

Post by xrgo » Sun Feb 17, 2019 11:17 pm

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?
0 x

User avatar
dark_sylinc
OGRE Team Member
OGRE Team Member
Posts: 4138
Joined: Sat Jul 21, 2007 4:55 pm
Location: Buenos Aires, Argentina
x 268
Contact:

Re: [2.2]Porting my engine to 2.2

Post by dark_sylinc » Sun Feb 17, 2019 11:36 pm

xrgo wrote:
Sun Feb 17, 2019 10:20 pm
thanks! I am going to make a PR very soon with this and a couple more things
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.
xrgo wrote:
Sun Feb 17, 2019 10:20 pm
btw, I just tested the new sample UpdatingDecalsAndAreaLightTex and noticed that the "reflection" (I guess its the specular component?) of the area lights should be reflected/flipped

Image
Interesting. You're right.
1 x

Post Reply