Understand cubemap probes parameters

[TaaTT4]

I have some difficulties in understanding how the parameters of CubemapProbe::set method work. A premise before start: I'm using per-pixel PCC.

This is the scenario:

I have two different probes in scene which are positioned where the bigger reflective spheres are. Their probeShape parameter correspond to the inner wireframe boxes, while the area parameter correspond to the outer wireframe boxes (and area is 1.5 times bigger than probeShape). The gray plane uses a material with metallic workflow and metalness and roughness equals to 0.5.

What I'd like to obtain is:

• No interpolation between probes inside the inner region
• Smooth interpolation between probes in the region included between inner and outer

To doing so, I've set the areaInnerRegion parameter as Vector3(1.0f / 1.5f). Of course, as you can see from the image, the result is not what I was expecting.

Looking at the shader code, I've seen that the area parameter isn't taken in account to decide whether a pixel must be lit by a probe:

Code: Select all

		float probeFade = getProbeFade( posInProbSpace, probe );

		if( probeFade > 0 )

The probe object (of type CubemapProbe) infact doesn't contain any information about the area parameter. That's the reason why I don't see any reflection in the pixels contained between the inner and outer region.

On the contrary, the area parameter is taken in account when ndf is calculated:

Code: Select all

			float ndf = getProbeNDF( posInProbSpace.xyz, probeToAreaCenterOffsetLS.xyz,
									 probeInnerRange.xyz, probeOuterRange.xyz );

So, what's the purpose of the area parameter? In addition, what's the sense of having an area greater than probeShape (like is done in every sample)? How can I achieve my goal?

[dark_sylinc]

I suggest playing with:

Code: Select all

pccGridPlacement.setOverlap( Ogre::Vector3( 1.25f ) );

In PccPerPixelGridPlacementGameState.cpp and with the 0.5 in

Code: Select all

probe->set( camCenter, area, Vector3( 0.5f ), Matrix3::IDENTITY, probeShape );

from OgrePccPerPixelGridPlacement.cpp

Now as to your question: Blending happens only during overlap (i.e. no overlap = it doesn't fade away to 0)
The area cannot extend beyond the probe's shape. It gets clamped. There must be a warning in Ogre.log about that.

So that's more likely the reason you don't see anything.

[TaaTT4]

I suggest playing with:

Code: Select all

pccGridPlacement.setOverlap( Ogre::Vector3( 1.25f ) );

In PccPerPixelGridPlacementGameState.cpp and with the 0.5 in

Code: Select all

probe->set( camCenter, area, Vector3( 0.5f ), Matrix3::IDENTITY, probeShape );

from OgrePccPerPixelGridPlacement.cpp

I did! I understood how the setOverlap works and what's the idea behind. It increases/reduces the regions shared by the probes smoothing the lighting transition between them. Instead, I honestly didn't notice any appreciable visual difference in changing Vector3( 0.5f ) (even using values near its extremes).

EDIT: I have to correct myself: I wasn't able to see the difference in the sample probably due to low metalness/high rougness values. In my test scenario, the difference is clearly noticeable (0.05 on the left, 1.0 on the right).

There must be a warning in Ogre.log about that.

Hmm, I guess there isn't...

OT: The Sample_PccPerPixelGridPlacement doens't work in debug mode (both in D3D11 and GL). This is the stack trace, if interested:

Code: Select all

 	ucrtbased.dll!00007ffc3ba41a65()	Unknown
 	ucrtbased.dll!00007ffc3ba41883()	Unknown
 	ucrtbased.dll!00007ffc3ba441cf()	Unknown
>	OgreMain_d.dll!Ogre::AsyncTextureTicket::downloadFromGpu(Ogre::TextureGpu * textureSrc, unsigned char mipLevel, bool accurateTracking, Ogre::TextureBox * srcBox) Line 86	C++
 	RenderSystem_Direct3D11_d.dll!Ogre::D3D11AsyncTextureTicket::downloadFromGpu(Ogre::TextureGpu * textureSrc, unsigned char mipLevel, bool accurateTracking, Ogre::TextureBox * srcBox) Line 139	C++
 	OgreMain_d.dll!Ogre::AsyncTextureTicket::download(Ogre::TextureGpu * textureSrc, unsigned char mipLevel, bool accurateTracking, Ogre::TextureBox * srcBox, bool bImmediate) Line 159	C++
 	OgreHlmsPbs_d.dll!Ogre::PccPerPixelGridPlacement::buildStart(unsigned int resolution, Ogre::Camera * camera, Ogre::PixelFormatGpu pixelFormat, float camNear, float camFar) Line 319	C++
 	Sample_PccPerPixelGridPlacement.exe!Demo::PccPerPixelGridPlacementGameState::setupParallaxCorrectCubemaps() Line 77	C++
 	Sample_PccPerPixelGridPlacement.exe!Demo::PccPerPixelGridPlacementGameState::createScene01() Line 167	C++
 	Sample_PccPerPixelGridPlacement.exe!Demo::BaseSystem::createScene01() Line 29	C++
 	Sample_PccPerPixelGridPlacement.exe!Demo::MainEntryPoints::mainAppSingleThreaded(HINSTANCE__ * hInst, HINSTANCE__ * hPrevInstance, char * strCmdLine, int nCmdShow) Line 82	C++
 	Sample_PccPerPixelGridPlacement.exe!WinMainApp(HINSTANCE__ * hInst, HINSTANCE__ * hPrevInstance, char * strCmdLine, int nCmdShow) Line 23	C++
 	Sample_PccPerPixelGridPlacement.exe!WinMain(HINSTANCE__ * hInst, HINSTANCE__ * hInst2, char * strCmdLine, int intParam) Line 35	C++
 	[External Code]	

[dark_sylinc]

EDIT: I have to correct myself: I wasn't able to see the difference in the sample probably due to low metalness/high rougness values. In my test scenario, the difference is clearly noticeable (0.05 on the left, 1.0 on the right).

Awesome!

OT: The Sample_PccPerPixelGridPlacement doens't work in debug mode (both in D3D11 and GL). This is the stack trace, if interested:

Thanks, I can repro it. It seems it broke with the ibl_specular stuff.

[TaaTT4]

What instead in case of nested probes? Think at a global probe that encloses all the scene including a local probe that instead encloses just a portion of the scene (the russian probes...).
I've seen a CubemapProbe::setPriority method, is it the right way to proceed? Priority value range is contained in a 16 bit unsigned int. Can I think at it as a discretization of [0.0, 1.0] interval? And then that it's passed as an input to some kind of lerp function?

[dark_sylinc]

Nested probes is the main reason for using areas and priorities.
You have a large room, and instead of having only one probe for that room you use e.g. 4 probes; one at each 25%; with some overlap. The probe shape is the same (not necessarily) but their camera positions are different (hence more accurate)

However the setup can be messed up if probes overlap their region where they are supposed to be at 100% (i.e. the inner region).

The priority value is just a boost in weight. The main reason for creating it was when probes overlap and there is a "fallback" probe, you want that fallback to have the least influence if there are other probes that can be used.

[TaaTT4]

The priority value is just a boost in weight. The main reason for creating it was when probes overlap and there is a "fallback" probe, you want that fallback to have the least influence if there are other probes that can be used.

That's exactly my situation. Eg. When the car is inside the box, I don't want that the cubemap captured inside the box would be combined with the cubemap captured outside.

[dark_sylinc]

That's exactly my situation. Eg. When the car is inside the box, I don't want that the cubemap captured inside the box would be combined with the cubemap captured outside.

There are two ways:

1. Increase the box inner region (so it is at 100%, doesn't get combined with anything else)
2. Assign the inside box a much large priority (e.g. 1000) than the priority to the box outside of it (e.g. 1). Then the blending is 1+1000 = 10001; w0 = 1 / 1001 and w1 = 1000 / 1001

Note that priorities are a double edge sword: Depending how overlaps happen, the weights may change too suddenly; e.g. w0 = 1 and there is no w1.