Am 23.06.2015 um 19:04 schrieb Nekar Xenos:

> I am assuming PBR in games doesn't do ray-tracing, so why do they call it
> Physically Based Rendering in games. Even Space Engineers has PBR now.

After having googled a bit, it seems that in DirectX 11 parlance, the 
buzzword "PBR" is used in a more basic sense:

(1) Perform colour computations on linear values rather than 
gamma-compressed ones (in POV-Ray terms, use "assumed_gamma 1.0"). It 
seems that the gaming world is only just now realizing that they've been 
applying their math to the wrong type of values, and that they need to 
do more about gamma than just giving us that infamous "gamma" slider to 
adjust the output image to our display gamma (and that using proper 
gamma handling really adds to realism - or, in other words, that the 
failure to do so has been a serious limit to realism).

(2) Use high dynamic range material for environment maps.

(3) Discard the dated Blinn-Phong model for specular highlights in 
favour of the Cook-Torrance model:

(3a) Make sure that the brightness of specular highlights is within 
physically reasonable bounds. (In POV-Ray, this can easily be achieved 
by using the "albedo" keyword.)

(3b) Make the brightness of specular highlights (and maybe also 
environment maps for reflection?) dependent on the angle of incidence 
according to the Fresnel function. (For non-metallic materials, this one 
has only recently been added to POV-Ray as well, by allowing to use 
"fresnel on" in the entire finish block. However, POV-Ray goes even one 
step further there, and also modulates the diffuse component 
accordingly, which the gaming industry apparently doesn't. On the other 
hand the gaming industry seems to be going for a GGX-based version of 
Cook-Torrance, while POV-Ray is still stuck with a Phong- or 
Blinn-Phong-based version.)

(3c) For metallic materials, make sure that the specular highlights have 
the same colour as the diffuse component. (In POV-Ray this has been part 
of the package for ages, by using "metallic on".)

Post a reply to this message

Am 22.06.2015 um 18:07 schrieb clipka:

> - You can freely combine elements from different sources. In a non-PBR
> environment, only the combination of materials and lighting can be
> assessed for whether they are convincing or not, and any attempt to set
> up some "neutral" setting to assess just one or the other is moot: To
> assess whether a lighting setup is "neutral" it would have to be tested
> with known "neutral" materials, but to assess whether a material is
> "neutral" in the first place it would have to be tested with a known
> "neutral" lighting setup - a classic hen and egg problem. In practice,
> different authors will inevitably have different ideas what a chicken
> actually is. In a PBR environment, however, a material can be assessed
> simply by checking whether the parameters plugged in match the optical
> characteristics observed in reality, without rendering even a single
> image, and the same goes for lighting setups. So even if you don't have
> the facilities to measure the exact optical chracteristics of all your
> materials and lighting setups, you can jump-start your chicken farm from
> a small set of precisely known materials and lighting setups.

Seems like this is a much bigger issue in the gaming industry than I 
previously thought. Apparently, up to now it has been customary in 
high-end games to have different variants of one and the same material 
for different lighting conditions.

Post a reply to this message

Going off off-topic, I think an example of this should be in the Pov-Ray  
insert-menu with a RSOCP scene.

On Mon, 22 Jun 2015 18:07:16 +0200, clipka <ano### [at] anonymousorg> wrote:

> Am 21.06.2015 um 09:44 schrieb Nekar Xenos:
>> Can some explain to me what exactly PBR is. In Pov-Ray terms would be
>> nice :)
>
> PBR avoids old-school shading models and rendering algorithms that were  
> designed to achieve a particular effect, and instead uses mechanisms  
> that were designed to model the underlying physical processes.
>
> POV-Ray has been heavily geared towards PBR in recent times, and UberPOV  
> should by now be a viable PBR tool, provided you stick to the following  
> rules:
>
> - Don't use "ambient". Use radiosity instead, and "emission" where  
> applicable.
>
> - Don't use "phong" or "specular". Rely on reflections instead (which,  
> for good results, mandates that you use blurred reflections).
>
> - If you decide that you do need to use "phong" or "specular", prefer  
> "specular", and /always/ use it in tandem with reflection, making sure  
> that the parameters match: Use "specular albedo N" where N is the  
> maximum reflection intensity, and use "fresnel on" or "metallic on" for  
> the entire finish block just as you do in the reflection block. Also,  
> make sure to specify the same "roughness" in the reflection block.  
> (You'll need an up-to-date version of UberPOV for "fresnel on" in the  
> entire finish block and "roughness" in the reflection block.)
>
> - Always use "fresnel on" for reflections (don't forget to specify  
> "ior"), or "metallic on" where applicable, and always use 0.0 for the  
> minimum reflection (or leave it out, specifying the maximum reflection  
> only).
>
> - Don't use colours as reflection parameters. Use the "metallic"  
> mechanism for this instead.
>
> - Don't use "light_source". Use objects with "emission" (or a sky  
> sphere) and radiosity instead.
>
> - If you decide that you do need to use "light_source", always use a  
> well-matching "looks_like" object with "no_radiosity on", always use  
> "area_light", always use "fade_power 2" with "fade_distance" set to  
> (roughly) half the area light vectors' dimensions, and always use  
> "area_illumination" unless the light source is sufficiently far away.  
> Also, do make use of photon mapping.
>
> - Use "normals on" and "media on" in the radiosity settings. Use  
> high-quality settings, and/or turn sample caching off (requires UberPOV).
>
> - Don't use "filter" (unless you know what you're doing). Use a fading  
> interior instead, with "fade_power 1001", or use absorbing media.
>
> - Don't use "rainbow" (does anyone?).
>
> - Do use a little bit of reflection on all your materials (typically  
> with heavy blur).
>
> - If something doesn't look right, don't ask "what effect can I add or  
> tweak to make it look better?" but "what phyiscal properties of my scene  
> have I not modelled correctly?"
>
>
> As for HDR light probes, contrary to what Jerome wrote, the question of  
> whether they're legit as a /sky sphere/ to avoid complex modelling is  
> outside the scope of PBR; what's a no-go in PBR is using them for  
> /environment mapping/ to fake reflections, but POV-Ray doesn't support  
> that technique out of the box anyway. (You /could/ achieve a similar  
> effect and possibly some of the speedup by using a HDR sky sphere and  
> setting all objects to "no_reflection on", but environment mapping is  
> also frequently used with different maps for different objects.)
>
>
> The advantages of PBR are threefold:
>
> - It takes far less time to achieve a convincing result, provided you  
> have a basic understanding of the the underlying physical effects,  
> because you don't need endless iterations of tweaking your material and  
> light source parameters, repeatedly trying to figure out (A) what's  
> still wrong about the resulting image, and (B) how to counter this with  
> the knobs available (without introducing other undesired effects). With  
> PBR, first of all your images will /always/ be physically consistent in  
> themselves (and thus convincing in a very basic sense), and second, all  
> you need to achieve a truly convincing look is to carefully examine the  
> materials and light sources you intend to model and plug in the  
> corresponding values. If you did it right, all you have left to do is  
> worry about whether the image is pleasing, not whether it is convincing.
>
> - You can freely combine elements from different sources. In a non-PBR  
> environment, only the combination of materials and lighting can be  
> assessed for whether they are convincing or not, and any attempt to set  
> up some "neutral" setting to assess just one or the other is moot: To  
> assess whether a lighting setup is "neutral" it would have to be tested  
> with known "neutral" materials, but to assess whether a material is  
> "neutral" in the first place it would have to be tested with a known  
> "neutral" lighting setup - a classic hen and egg problem. In practice,  
> different authors will inevitably have different ideas what a chicken  
> actually is. In a PBR environment, however, a material can be assessed  
> simply by checking whether the parameters plugged in match the optical  
> characteristics observed in reality, without rendering even a single  
> image, and the same goes for lighting setups. So even if you don't have  
> the facilities to measure the exact optical chracteristics of all your  
> materials and lighting setups, you can jump-start your chicken farm from  
> a small set of precisely known materials and lighting setups.
>
> - You can rely on the results being physically accurate, allowing you to  
> model scenes for which you have no real-life reference image to go by.  
> (Maybe one of the most spectacular examples is the black hole and  
> accretion disk in the "Interstellar" movie, which was modeled solely  
> from physical principles - at least as far as the distortion of  
> spacetime is concerned - rather than preconceived notions of how such a  
> phenomenon would look like.)
>


-- 
-Nekar Xenos-

Post a reply to this message

On 23-6-2015 19:22, clipka wrote:
> Am 23.06.2015 um 09:28 schrieb Thomas de Groot:

>> No more sad examples of reflective spheres on chequered planes :-)
>
> It's impressive what a difference it can make to really press for PBR,
> even for something so seemingly trivial as RSoCP; I think especially
> using a fully fresnel-aware model (using "fresnel on" in the entire
> finish block) and blurred reflections (with specular highlights properly
> tuned to match) really adds a level of credibility that you might not
> even have expected to be there.
>

Oh yes! While I jokingly mentioned the RSoCP I fully realised the 
implications your rules would have on them.

-- 
Thomas

Post a reply to this message

On 23-6-2015 19:35, clipka wrote:
> Oh, and another one:
>
> - Always, I mean /really/ always and without exception, use
> "assumed_gamma 1.0".
>
> I guess this one is so trivial for me that I entirely forgot to mention it.
>

Oh, we are so used to your typical head bashing that we just grumble 
"here we go again" ;-)

But that aside, it can never be mentioned too often.

-- 
Thomas

Post a reply to this message

On 24/06/2015 08:22, Thomas de Groot wrote:
> Oh yes! While I jokingly mentioned the RSoCP I fully realised the
> implications your rules would have on them.

Pictures!
Not real if there is no proof. :-)


-- 

Regards
     Stephen

Post a reply to this message

On 24-6-2015 10:02, Stephen wrote:
> On 24/06/2015 08:22, Thomas de Groot wrote:
>> Oh yes! While I jokingly mentioned the RSoCP I fully realised the
>> implications your rules would have on them.
>
> Pictures!
> Not real if there is no proof. :-)
>
>
We are not allowed RSoCP pictures in this n.g., sir ;-)

-- 
Thomas

Post a reply to this message

On 24/06/2015 12:06, Thomas de Groot wrote:
> On 24-6-2015 10:02, Stephen wrote:
>> On 24/06/2015 08:22, Thomas de Groot wrote:
>>> Oh yes! While I jokingly mentioned the RSoCP I fully realised the
>>> implications your rules would have on them.
>>
>> Pictures!
>> Not real if there is no proof. :-)
>>
>>
> We are not allowed RSoCP pictures in this n.g., sir ;-)
>

I know the rules. But I thought for you they could be bent.
Since uncle Ken moved on. We are sliding into decadence. :-)

-- 

Regards
     Stephen

Post a reply to this message

clipka <ano### [at] anonymousorg> wrote:
> Am 21.06.2015 um 09:44 schrieb Nekar Xenos:
> > Can some explain to me what exactly PBR is. In Pov-Ray terms would be
> > nice :)
>
> PBR avoids old-school shading models and rendering algorithms that were
> designed to achieve a particular effect, and instead uses mechanisms
> that were designed to model the underlying physical processes.
>
> POV-Ray has been heavily geared towards PBR in recent times, and UberPOV
> should by now be a viable PBR tool, provided you stick to the following
> rules:
> [...]


Precious information that definitely needs to land in POV-Ray documentation. But
I do like the shortcuts, because they are my only hope for an acceptable render
time, though I have not reached it yet.



Off topic request: please don't suppress POV rainbows! If you can't leave them
alone, please just improve them, as you did with iridescence.

Post a reply to this message

On 24-6-2015 13:47, Stephen wrote:
> On 24/06/2015 12:06, Thomas de Groot wrote:
>> On 24-6-2015 10:02, Stephen wrote:
>>> On 24/06/2015 08:22, Thomas de Groot wrote:
>>>> Oh yes! While I jokingly mentioned the RSoCP I fully realised the
>>>> implications your rules would have on them.
>>>
>>> Pictures!
>>> Not real if there is no proof. :-)
>>>
>>>
>> We are not allowed RSoCP pictures in this n.g., sir ;-)
>>
>
> I know the rules. But I thought for you they could be bent.
> Since uncle Ken moved on. We are sliding into decadence. :-)
>

We are living in troubled times. No respect for the simplest rules of 
render behaviour. I shall see yet in my old age the heresy of chequered 
spheres on reflecting planes I am afraid.

That said, and in keeping with off off-topic, I have trouble with an 
emission sphere replacing a Sun light_source in a scene. Whatever the 
emission value, the scene remains fairly dark and no shadows seem to be 
cast. Using UberPOV. What about this, Christoph?

-- 
Thomas

Post a reply to this message