On 24-6-2015 20:01, clipka wrote:
> Am 24.06.2015 um 16:08 schrieb Thomas de Groot:
>
>> 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?
>
> Using an emissive sphere instead of a light_source for the sun - while
> being proper PBR - is not a good idea performance-wise: The sun is quite
> small in the sky, and most rays will miss it. I suspect that's the
> underlying cause for your problem.

I suspected something like this. I shall experiment with alternative 
settings as you suggest. However, it probably will be more efficient to 
render the Sun with an area_light.

Thanks indeed!

-- 
Thomas

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:
>
> - 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.)



It is the method to approach PBR in one way truly. Some of it is my habit. One
is the rule "don't use phong or specular, rely on reflections instead".
Because all smooth surface can form an image of other object by it. Pov-ray
simulate this function by the 'reflection' keyword. It has done. And a highlight
is just the image of a bright object we say the light source, it is unnecessary
to give another keyword 'phong' to do the same and repeat phenomenon.
But at the same time, you should make a "well-matching "looks_like" object to
make it pretty. The thing which we should "well-matching" is the brightness of
this object and the intensity of the corresponding light source.

I want to say my story on this topic:
Several years ago, I saw the result making by some advanced rendering engine
like Indigo renderer. It is too wonderful, I start thinking how to make such a
realistic result.
I'm a physic bachelor, so I think I have the ability on the topic. The first
thing I tried in Pov-ray is to use the emission look like object to produce the
highlight on a reflect surface. I tend to use this method. Instead of the
specular or phong keyword. Then I tried to calculate the "well-matching
"looks_like" object should have what color brightness.

Post a reply to this message

Thomas de Groot <tho### [at] degrootorg> wrote:
>
> 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

Just like the opinion clipka have answered you the other day, an emission sphere
in the sky is too small to render. I always use the parallel light to
simulate the sun light and it is very convenient. If you would like to place a
white look-like object, the sun's color should like this: rgb<1,1,1>*10000.
Is a very large quantity.

Post a reply to this message

clipka <ano### [at] anonymousorg> wrote:
> - When using "brilliance", always use "brilliance FLOAT, FLOAT" with
> both parameters set to the same value, and specify "brilliance on" in
> the radiosity block. (You'll need a POV-Ray 3.7.1-alpha build for these,
> or UberPOV.)
>

Would you tell me what the "FLOAT, FLOAT" really mean? You said it ... what it
is bi-direction ..once to me, but I don't understand that yet.

Post a reply to this message

Am 25.06.2015 um 09:14 schrieb Thomas de Groot:
> On 24-6-2015 20:01, clipka wrote:
>> Am 24.06.2015 um 16:08 schrieb Thomas de Groot:
>>
>>> 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?
>>
>> Using an emissive sphere instead of a light_source for the sun - while
>> being proper PBR - is not a good idea performance-wise: The sun is quite
>> small in the sky, and most rays will miss it. I suspect that's the
>> underlying cause for your problem.
>
> I suspected something like this. I shall experiment with alternative
> settings as you suggest. However, it probably will be more efficient to
> render the Sun with an area_light.

Yup. Quite legit for a far-away light source, if I'm asked.

That was one of the things that seriously bothered me about MCPov: It 
didn't do classic light sources /at all/.

Post a reply to this message

Am 25.06.2015 um 20:13 schrieb And:
> clipka <ano### [at] anonymousorg> wrote:
>> - When using "brilliance", always use "brilliance FLOAT, FLOAT" with
>> both parameters set to the same value, and specify "brilliance on" in
>> the radiosity block. (You'll need a POV-Ray 3.7.1-alpha build for these,
>> or UberPOV.)
>>
>
> Would you tell me what the "FLOAT, FLOAT" really mean? You said it ... what it
> is bi-direction ..once to me, but I don't understand that yet.

At the default of "brilliance 1" the brightness of the diffuse component 
depends on the angle of the incoming light, following a cos(theta) law, 
where theta is the angle between the light ray and the surface normal 
(the vector perpendicular to the surface).

Similarly, if we're talking about brightness as the total amount of 
light reaching the observer from any given patch of surface, the 
brightness of the diffuse component also depends on the angle of the 
/outgoing/ light (i.e. the angle at which the surface is seen by an 
observer), following the very same cos(theta) law. However, this is 
already modeled exactly by the patch of surface appearing to get smaller 
as theta increases, while the brightness of any individual pixel remains 
constant.

Using "brilliance N" with any value other than 1 changes the dependency 
between the brightness of the diffuse component and the angle of 
incoming light: Rather than following a cos(theta) law, it now follows a 
cos(theta)^N law.

Now there is some fundamental law known to the contemporary world of 
professional and academic rendering, that any physically realistic 
shading formula must be "bi-directional", i.e. if you exchange the 
incoming and outgoing light rays, the formula must still yield the same 
result.

Thus, when you change the brightness' dependency on the incoming 
direction, you also need to change the dependency on the outgoing 
direction accordingly.

Traditionally however, POV-Ray will fail to do this, always leaving the 
brightness of an individual pixel constant no matter what the 
orientation of the surface towards the observer, which - as mentioned 
before - happens to be a perfect match for "brilliance 1", but breaks 
bi-directionality at any other setting.

Now fixing this behaviour of the "brilliance" keyword would be possible, 
but it would break each and every existing scene that makes use of 
brilliance. Therefore, I introduced an optional second parameter to 
"brilliance" which governs the dependency on the outgoing direction, 
allowing to restore bi-directionality by setting both parameters to the 
same value.

Post a reply to this message

Am 25.06.2015 um 19:37 schrieb And:

> I'm a physic bachelor, so I think I have the ability on the topic. The first
> thing I tried in Pov-ray is to use the emission look like object to produce the
> highlight on a reflect surface. I tend to use this method. Instead of the
> specular or phong keyword. Then I tried to calculate the "well-matching
> "looks_like" object should have what color brightness.

There's a caveat with the latter: When it comes to the brightness of 
light sources, POV-Ray's parameterization is off by some factor of pi or 
2*pi (can't remember which, and whether you need to multiply or divide) 
from the parameterization commonly used in papers on image synthesis.

Post a reply to this message

clipka <ano### [at] anonymousorg> wrote:
> At the default of "brilliance 1" the brightness of the diffuse component
> depends on the angle of the incoming light, following a cos(theta) law,
> where theta is the angle between the light ray and the surface normal
> (the vector perpendicular to the surface).
>
> Similarly, if we're talking about brightness as the total amount of
> light reaching the observer from any given patch of surface, the
> brightness of the diffuse component also depends on the angle of the
> /outgoing/ light (i.e. the angle at which the surface is seen by an
> observer), following the very same cos(theta) law. However, this is
> already modeled exactly by the patch of surface appearing to get smaller
> as theta increases, while the brightness of any individual pixel remains
> constant.
>
> Using "brilliance N" with any value other than 1 changes the dependency
> between the brightness of the diffuse component and the angle of
> incoming light: Rather than following a cos(theta) law, it now follows a
> cos(theta)^N law.
>
> Now there is some fundamental law known to the contemporary world of
> professional and academic rendering, that any physically realistic
> shading formula must be "bi-directional", i.e. if you exchange the
> incoming and outgoing light rays, the formula must still yield the same
> result.
>
> Thus, when you change the brightness' dependency on the incoming
> direction, you also need to change the dependency on the outgoing
> direction accordingly.
>
> Traditionally however, POV-Ray will fail to do this, always leaving the
> brightness of an individual pixel constant no matter what the
> orientation of the surface towards the observer, which - as mentioned
> before - happens to be a perfect match for "brilliance 1", but breaks
> bi-directionality at any other setting.
>
> Now fixing this behaviour of the "brilliance" keyword would be possible,
> but it would break each and every existing scene that makes use of
> brilliance. Therefore, I introduced an optional second parameter to
> "brilliance" which governs the dependency on the outgoing direction,
> allowing to restore bi-directionality by setting both parameters to the
> same value.

First of all, thank you very much for sharing this. This article is full of
information to me, and I'm interested in knowing such a thing. Now I get the
idea. You said that a bi-directionality is a law known to academic rendering, so
we believe it for now. And with many other new features I saw in your posts,
there is a marked gain with pov-ray. I'm impressed.

Post a reply to this message

clipka <ano### [at] anonymousorg> wrote:
> There's a caveat with the latter: When it comes to the brightness of
> light sources, POV-Ray's parameterization is off by some factor of pi or
> 2*pi (can't remember which, and whether you need to multiply or divide)
> from the parameterization commonly used in papers on image synthesis.

Thank you. I knew this. It must do. This is due to POV-Ray's light source
defines the color of a diffuse surface which is illuminate by the light source
at a distance of fade_distance.

Post a reply to this message

"And" <49341109@ntnu.edu.tw> wrote:
> Thank you. I knew this. It must do. This is due to POV-Ray's light source
> defines the color of a diffuse surface which is illuminate by the light source
> at a distance of fade_distance.

I'm very smart.!!

Post a reply to this message