[2.2] Decals issues Topic is solved

Discussion area about developing with Ogre2 branches (2.1, 2.2 and beyond)
Post Reply
rujialiu
Goblin
Posts: 224
Joined: Mon May 09, 2016 8:21 am
x 20

[2.2] Decals issues

Post by rujialiu » Tue Feb 12, 2019 2:09 am

Hi!

1. Very similar issue when SSD is just developed in Ogre 2.1: When only emissive texture is present, the sampler's index will be wrong. Here is Ogre 2.2 generated code:

Code: Select all

SamplerState decalsSampler : register(s0);
Texture2DArray decalsEmissiveTex : register(t4);
Here is Ogre 2.1's (correct):

Code: Select all

SamplerState decalsSampler : register(s4);    
Texture2DArray decalsEmissiveTex : register(t4);
Looking at piece "DeclDecalsSamplers" I think there should be some kind of "first decal texture idx"? This can be reproduced with Decals sample by commenting out "decal->setDiffuseTexture( textureDiff );" and "sceneManager->setDecalsDiffuse( textureDiff );"

2. However, I workaround this by changing decalsSampler to use decalsEmissiveTex and the sample's index is correct now. However, I still cannot get Decals in my own app shown in Ogre 2.2 (both D3D11 and Metal iOS), but Ogre 2.1 is correct. With RenderDoc, I confirmed that the emissive texture array is uploaded correctly. but with RenderDoc 1.2's HLSL source-level debugging, I suspect decal's absLocalPos.z is wrong (abnormal big value), which might be caused by incorrect InvWorldMatrix. Then I changed

Code: Select all

@property( hlms_decals_emissive )
            finalDecalEmissive    += (absLocalPos.x > 0.5f || absLocalPos.y > 0.5f ||
                                    absLocalPos.z > 0.5f) ? 0.0f : (decalEmissive.xyz * decalMask);
        @end
to

Code: Select all

@property( hlms_decals_emissive )
            finalDecalEmissive    += (absLocalPos.x > 0.5f || absLocalPos.y > 0.5f ||
                                    absLocalPos.z > 0.5f) ? 1.0f : 0.0f;
        @end
Which should mean "change the pixel to white when the grid CELL is intersecting the decal but the PIXEL is outside the decal". The code gives me intended rendering with Ogre's Decals Sample, but for my own app, almost all the screen is white, including the pixels that are definitely inside the decal. Ogre 2.1 is correct.

So I looked at the code to upload invWorldMatrix and the alignment is wrong. Here is what I tried:

Code: Select all

OgreMain/src/OgreForwardPlusBase.cpp | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/OgreMain/src/OgreForwardPlusBase.cpp b/OgreMain/src/OgreForwardPlusBase.cpp
index 509a3342..a5646e14 100644
--- a/OgreMain/src/OgreForwardPlusBase.cpp
+++ b/OgreMain/src/OgreForwardPlusBase.cpp
@@ -197,6 +197,7 @@ namespace Ogre
             if( numDecals > 0u )
                 accumOffset = alignToNextMultiple( accumOffset, c_ForwardPlusNumFloat4PerDecal );
             mDecalFloat4Offset = static_cast<uint16>( accumOffset );
+            accumOffset += numDecals * c_ForwardPlusNumFloat4PerDecal;
             if( numCubemapProbes > 0u )
                 accumOffset = alignToNextMultiple( accumOffset, c_ForwardPlusNumFloat4PerCubemapProbe );
             mCubemapProbeFloat4Offset = static_cast<uint16>( accumOffset );
@@ -313,7 +314,7 @@ namespace Ogre
         //Align to the start of cubemap probes
         //Alignment happens in increments of float4, hence the "<< 2u"

-        lightData += (mCubemapProbeFloat4Offset - mDecalFloat4Offset) << 2u;
+        lightData += (mCubemapProbeFloat4Offset - mDecalFloat4Offset - numDecals * c_ForwardPlusNumFloat4PerDecal) << 2u;

         viewMatrix = camera->getViewMatrix();

         Matrix3 invViewMatrix3 = viewMatrix3.Inverse();
But it changed nothing. Then I realized even if this piece of code is wrong, it only affect cubemap probes' data, not decals' data, but still, my changes look reasonable? Any ideas why my decals are not shown in Ogre 2.2?
0 x

rujialiu
Goblin
Posts: 224
Joined: Mon May 09, 2016 8:21 am
x 20

Re: [2.2] Decals issues

Post by rujialiu » Tue Feb 12, 2019 12:38 pm

rujialiu wrote:
Tue Feb 12, 2019 2:09 am
But it changed nothing. Then I realized even if this piece of code is wrong, it only affect cubemap probes' data, not decals' data, but still, my changes look reasonable?
It turns out these changes (alignment things) solved most of the problems. For some reason I was using the wrong version of the Ogre after making these changes... Now the decals are seen. After removing these changes, the decals disappear again. So I assume these changes did something good!

However, there are still subtle issues, still investigating...
0 x

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

Re: [2.2] Decals issues

Post by dark_sylinc » Tue Feb 12, 2019 11:53 pm

I was convinced we had a sample testing decals and per pixel cubemaps at the same time, but I was wrong, we only have decals + regular cubemaps.

I took at look at your code and it appears to be the correct fix. I have yet to look at the scene you sent me via email.

Cheers
0 x

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

Re: [2.2] Decals issues

Post by dark_sylinc » Thu Feb 14, 2019 12:49 am

Fixed!!!
I got 15 minutes to give your repro a try, and with it, it was a piece of cake.

You just missed another place were offsets were wrong.

By setting width, height and slice to 1, I got a lot of noise out which made things easier to debug:

Code: Select all

sceneManager->setForwardClustered( true, 1, 1, 1, 256, 64, 4, 10, 20000 )
Since the bug could be repro when cubemapProbesPerCell was non-zero, I compared both Good and Bad with RenderDoc, and used the function to export the f3dList buffer to CSV, and there was only one ushort that was different (a 0 that should've been an 8). And with that, finding the cause was easy.

Thanks for the repro and the fixes!

Btw the scene you sent me flickers on two of the four walls, it's caused by floating point precision when evaluating the normals:

Code: Select all

isOutsideDecal = dot( decalDir.xyz, inPs.normal.xyz ) <= 0.0 ? true : isOutsideDecal;
I guess we should change that boolean comparison to a lerp to dampen the flicker.
1 x

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

Re: [2.2] Decals issues

Post by dark_sylinc » Thu Feb 14, 2019 1:25 am

1 x

rujialiu
Goblin
Posts: 224
Joined: Mon May 09, 2016 8:21 am
x 20

Re: [2.2] Decals issues

Post by rujialiu » Thu Feb 14, 2019 4:32 am

dark_sylinc wrote:
Thu Feb 14, 2019 12:49 am
Since the bug could be repro when cubemapProbesPerCell was non-zero, I compared both Good and Bad with RenderDoc, and used the function to export the f3dList buffer to CSV, and there was only one ushort that was different (a 0 that should've been an 8). And with that, finding the cause was easy.
I was also thinking about using the "set everything dimensition to 1" trick but was too lazy to debug 8-)
But I wasn't aware of the "export buffer from RenderDoc CSV and compare" trick, thanks!

I've tried both D3D11 and Metal iOS and both of them are working perfectly no matter how I rotate the camera! Also, the flickering is indeed gone with your latest "smooth fade" commit. Thanks!!!
0 x

Post Reply