Cannot bind cubemap probes to materials using per-pixel PCC about ogre-next HOT 4 CLOSED

I'll make a small clarification: This is a bug in the sample, not in Ogre.

It is invalid to set cubemap probes to materials while using per-pixel PCC.

The sample just doesn't correctly handle the case where mPerPixelReflections starts as true, as it only handles the case where mPerPixelReflections starts as false and later it is set to true via key toggle

from ogre-next.

I'll make a small clarification: This is a bug in the sample, not in Ogre.

It is invalid to set cubemap probes to materials while using per-pixel PCC.

After days spent trying to make reflections working in my engine, I guess to have a lot of confusion in my head. I've noticed just now that, when the sample switches to per-pixel PCC, it disables cubemap probes of materials. Apologize me, it's a bit embarassing... :/
To make the the story clear, so per-pixel PCC is the improved version of PCC in auto mode, correct? What of these statements (taken from HlmsPbsDatablock::setCubemapProbe documentation) are valild also for per-pixel PCC?

            Auto Advantages:
                * Smoothly blends between probes, making smooth transitions
                * Avoids seams.
                * No need to change anything on the material or the object,
                  you don't need to do anything.
                * Works best for dynamic objects (eg. characters)
                * Also works well on static objects if the camera is inside rooms/corridors, thus
                  blocking the view from distant rooms that aren't receiving reflections.
            Auto Disadvantages:
                * Objects that are further away won't have reflections as
                  only one probe can be active.
                * It depends on the camera's position.
                * Doesn't work well if the user can see many distant objects at once, as they
                  won't have reflections until you get close.

from ogre-next.

Apologize me, it's a bit embarassing... :/

Don't apologize! It's our fault.

We have 4 mutually-exclusive systems that perform the same thing (manually assigning a reflection texture, old PCC system, old PCC system with manually-assigned probes, new per pixel PCC system) and we decided to reuse the old PCC code for the new one to ease porting from old to new; but this causes documentation and code confusion because there's some code that is only meant for the old PCC and is not used by the new one. It's confusing, and that is our fault.

What of these statements (taken from HlmsPbsDatablock::setCubemapProbe documentation) are valild also for per-pixel PCC?

Per pixel PCC has the same advantages, but none of these disadvantages.

The only disadvantages of per pixel PCC are:

1. Potentially (and very likely) higher performance cost
2. Requires cubemap arrays (DX11 HW) unless the DPM fallback is used (supported on older DX10 HW; but probably the performance cost is too high for these GPUs anyway)

from ogre-next.

I close this issue since, at the end, it isn't a real bug, but just a misunderstood. There's no need nor advantage in make LocalCubemapsManualProbes sample being able to support per-pixel PCC at its start (at the end, it's just a sample, not multi-function tool).
Rethinking about what led me to the wrong path, I'd suggest to write in the documentation also advantages/disadvantages of per-pixel PCC. And maybe, removing per-pixel PCC from LocalCubemapsManualProbes sample, would make clearer that it's an alternative to automatic mode.

from ogre-next.