POV-Ray : Newsgroups : povray.binaries.scene-files : Dakota Red Granite macro - beta #1 : Re: Dakota Red Granite macro - beta #1.1 Server Time
21 Jun 2024 09:31:04 EDT (-0400)
  Re: Dakota Red Granite macro - beta #1.1  
From: Bald Eagle
Date: 18 May 2021 14:00:00
Message: <web.60a4003e581f2f681f9dae3025979125@news.povray.org>
"Dave Blandston" <IsN### [at] protonmailch> wrote:

> If I may offer a humble opinion/observation, using a value of 1/256 for the
> purpose of multiplying the brightness of an object does not make sense (to me,
> anyway) for this reason: Assuming the base scene is lit such that a fully-lit
> part of an object will have the same approximate output RGB value as the
> corresponding RGB value of the input pigment, a value of 1/256 will result in a
> pixel value of 0. In my opinion, that should be considered the true base value.
> What is the alternative? 1/256 is arbitrary. Why not 1/317? It's not possible to
> foresee what value is actually going to be desired.
>
> Also, even the best monitors don't display pure black anyway. Maybe future
> technological developments will change that...

http://news.povray.org/web.607425886a35d6561f9dae3025979125%40news.povray.org

So, the idea here is that we have some "pigment" color value that defines the
visible color.

If it were considered in a vacuum, where everything would be static, and you'd
be directly mapping that value onto the monitor, then all would be fine.

The complication comes in when other things begin to happen in the scene, and
you wonder why your scene looks weird / not good / off.

And that's where the not_0 thing comes into play.  We want to define a non-zero
color component for each of the channels.  If I focus the rays of the sun onto a
black object with a big parabolic mirror or magnifying glass, then there needs
to be - from a computational standpoint, some way of calculating what the
resulting object would look like under those conditions.  And that is usually a
result of multiplying the object pigment by the light source.  If I define
reflection, metallic, or shine a red light on something, then a zero r channel
value would give a 0 * whatever result.  Zero.   And that's not going to give
you "the expected" visual result.  The same thing happens with radiosity.  I
might have a "blue" wall, but when white light reflected off of red and green
objects hit the wall, they affect the perceived color of the wall - and so you
need a non-zero value for the r and g color channels.  There needs to be
_something_ there to get multiplied, and I just figured that a value _just_
below the perceptible / representable threshold value would be a good place to
start.

You are correct, that it IS arbitrary, however it is a value that has a basis /
reason as the current starting point.  I just wanted to make sure it was
actually below the threshold and not above it.



Inigo Quilex worked for Pixar, so I'm making the grounded presumption that he
learned a lot of good professional tricks / best practices.

https://www.youtube.com/channel/UCdmAhiG8HQDlz8uyekw4ENw

And Martijn Steinrucken also seems to really know his way around the inner
workings of colors, lighting, and reflections.

https://www.youtube.com/c/TheArtofCodeIsCool/videos


So if you have a few hours, they both mention this point in their videos
multiple times, and might possibly do a quick few lines of throwaway code that
they execute to demonstrate the concept.  Somewhere.


Post a reply to this message

Copyright 2003-2023 Persistence of Vision Raytracer Pty. Ltd.