On 22/11/2021 5:11 am, Kenneth wrote:
> Alain Martel <kua### [at] videotronca> wrote:
>>
>> I've experienced with negative ior. That makes the surface behave as if
>> it had
>> finish{ reflection 1 }
>>
> 
> That's an interesting observation. With my own tests here, I was not sure a
> 'negative' ior was having any effect when lower than 0.5-- until I re-positioned
> the crystal and camera 'just so'. Then I could see at least my sphere inclusion
> subtly changing its appearance as the ior decreased. But as a practical matter,
> the more negative it goes, the less of a visual change there is.
> 


In this animation I cycle the ior of a glass sphere from 1.6 to zero and 
back:

<https://youtu.be/gUzp0Bc6u1I>

Probably not relevant :-)

Post a reply to this message

On 11/21/21 4:11 PM, Kenneth wrote:
> Alain Martel <kua### [at] videotronca> wrote:
>>
>> I've experienced with negative ior. That makes the surface behave as if
>> it had
>> finish{ reflection 1 }
>>
> 
> That's an interesting observation. With my own tests here, I was not sure a
> 'negative' ior was having any effect when lower than 0.5-- until I re-positioned
> the crystal and camera 'just so'. Then I could see at least my sphere inclusion
> subtly changing its appearance as the ior decreased. But as a practical matter,
> the more negative it goes, the less of a visual change there is.
> 

FWIW. The ior value ripples into many finish features and how it is used 
in any given feature depend upon additional finish settings and the 
version of POV-Ray - v3.7, v3.8 releases and the (v4.0 master branch) 
all differ somewhat. For example, fresnel being on in a many v3.8 finish 
features will cause the negative negative ior values to be treated as 
positive ones. In other words, only the ior magnitude then matters.

Also FWIW. In the most recent povr branch tarball there is a file called 
albedoFresnelStory.txt in the doc directory with a great deal of finish 
related detail - should anyone be interested. It was started as an 
attempt at albedo documentation I could understand and intended to be a 
wiki subject for the v3.8 release. As I dug, it grew and grew - and got 
more and more complicated. I changed the aim to be a newsgroup post at 
some point - but I've never posted it.

The file does represent my current understanding of the state of many 
finish features in v3.7/v3.8/v4.0. To a significant degree it explains 
why I'm playing with certain changes in my povr branch.

Anyhow...

Bill P.

Post a reply to this message

"m@b" <sai### [at] googlemailcom> wrote:
>
> In this animation I cycle the ior of a glass sphere from 1.6 to zero and
> back:
>
> <https://youtu.be/gUzp0Bc6u1I>
>

Nicely done!

Are you sure that your sphere's ior goes to exactly 0.0? I am not seeing the
'glitch' that I mentioned earlier, where ior 0.0 = ior 1.0. I suspect that your
animation code gets the ior *very close* to zero, but then cycles back.

Post a reply to this message

On 23/11/2021 3:45 am, Kenneth wrote:
> "m@b" <sai### [at] googlemailcom> wrote:
>>
>> In this animation I cycle the ior of a glass sphere from 1.6 to zero and
>> back:
>>
>> <https://youtu.be/gUzp0Bc6u1I>
>>
> 
> Nicely done!
> 
> Are you sure that your sphere's ior goes to exactly 0.0? I am not seeing the
> 'glitch' that I mentioned earlier, where ior 0.0 = ior 1.0. I suspect that your
> animation code gets the ior *very close* to zero, but then cycles back.
> 
> 
> 
> 
Yes - well spotted it goes down to 0.001 :-)

Post a reply to this message

Le 2021-11-22 à 19:52, m@b a écrit :
> On 23/11/2021 3:45 am, Kenneth wrote:
>> "m@b" <sai### [at] googlemailcom> wrote:
>>>
>>> In this animation I cycle the ior of a glass sphere from 1.6 to zero and
>>> back:
>>>
>>> <https://youtu.be/gUzp0Bc6u1I>
>>>
>>
>> Nicely done!
>>
>> Are you sure that your sphere's ior goes to exactly 0.0? I am not 
>> seeing the
>> 'glitch' that I mentioned earlier, where ior 0.0 = ior 1.0. I suspect 
>> that your
>> animation code gets the ior *very close* to zero, but then cycles back.
>>
>>
>>
>>
> Yes - well spotted it goes down to 0.001 :-)
> 
That mean a substance where light travels at 1000 times the speed of light.

An ior of zero would mean light travelling at an infinite speed... In 
both directions at the same time.

Post a reply to this message

William F Pokorny <ano### [at] anonymousorg> wrote:
>
> fresnel being on in a many v3.8 finish
> features will cause the negative negative ior values to be treated as
> positive ones. In other words, only the ior magnitude then matters.

Wow, that's...strange. I didn't know. Good detective work.
>
> Also FWIW. In the most recent povr branch tarball there is a file called
> albedoFresnelStory.txt in the doc directory with a great deal of finish
> related detail - should anyone be interested...

I would definitely like to read that. Could you post a link to it, here or
elsewhere? I thought I had various links to your povr stuff, but can't find
them. (They might be on my previous Win 7 machine, which is down at the moment.)
I actually couldn't find any povr/Github reference on the web at all, even with
a detailed Google search(!)

Post a reply to this message

On 11/23/21 4:33 PM, Kenneth wrote:
>> Also FWIW. In the most recent povr branch tarball there is a file called
>> albedoFresnelStory.txt in the doc directory with a great deal of finish
>> related detail - should anyone be interested...

> I would definitely like to read that. Could you post a link to it, here or
> elsewhere? I thought I had various links to your povr stuff, but can't find
> them. (They might be on my previous Win 7 machine, which is down at the moment.)
> I actually couldn't find any povr/Github reference on the web at all, even with
> a detailed Google search(!)

See:
http://news.povray.org/povray.binaries.programming/thread/%3C61781abc%40news.povray.org%3E/

or

Web Message: <61781abc@news.povray.org>


---
Thus far, the povr branch is published on the POV-Ray newsgroups as a 
linux/unix tarball a few times a year.

Bill P.

Post a reply to this message

Alain Martel <kua### [at] videotronca> wrote:

> > Alain Martel <kua### [at] videotronca> wrote:

> >>> Hello Forum,
> >>>
> >>> I am relatively new to POV-RAY, but have a functional script .
> >>>
> >>> I am simulating air bubbles in a glass tube full of gel.  I am running into a
> >>> funny problem where, if I add too many bubbles to the script, they go from being
> >>> transparent and rendered correctly, to a completely opaque, black object through
> >>> which no light shines.
> >>>
> >>> Things that don't seem to work:
> >>>
> >>> 1) Increasing the  max_trace_level
> >>>
> >>> 2) I have tried to be sure that the inner surface of the gel is not in contact
> >>> with the air bubble by reducing the bubble radius by epsilon (.0001).  Oddly
> >>> enough, the script with up to 4 bubbles works only when the two surfaces are
> >>> coincident, and subtracting an epsilon value (.0001,.001,.01) causes the bubbles
> >>> to turn black, no matter the number.
> >>>
> >>> I would love your input on this issue as I am stumped.  I cannot figure out why
> >>> this renders without issue when I only have a certain number of objects defined.
> >>>
> >>>
> >>> The order of my file:
> >>>
> >>> In my scene, centered at the origin, I have bubbles, inside of gel, inside of a
> >>> glass tube, inside of water, inside of a plexiglass cylinder.
> >>>
> >>> My code
> >>>
> >>> 1) I define variables, set trace level, and place the camera
> >>>
> >>> 2) I create a distributed area light source on a rectangular box
> >>>
> >>> 3) I define the bubbles I want in the gel
> >>>
> >>> 4) I create the glass tube into which the gel will sit
> >>>
> >>> 5) I create the gel region with voids into which the bubbles sit.
> >>>
> >>> 6) I then add water around the glass tube, and then a plexiglass perimeter.
> >>>
> >>>
> >>>
> >>>
> >>
> >> The first thing that I would to would be to increase max_trace_level
> >> further still. It can go up to 255.
> >>
> >> Note : Your area_light is oblique. If you want it to be flat, then, it's
> >> size should be something like this :
> >> area_light 160*x 200*z 65 65
> >> adaptive 0 // start with zero, then, increase if needed
> >> Size of area_light adjusted to match the light_box dimensions.
> >>
> >> During testing, you should disable the area_light. It makes testing and
> >> debugging faster.
> >>
> >> The 100 by 100 get silently increased to 129 by 129 when adaptive is
> >> used. That increase DO NOT affect the rendering time.
> >>
> >> Using dispersion 1 is the same as not using dispersion. It must be
> >> slightly different than 1. Realistic values are usually in the 1.01 to
> >> 1.08. Values less than 1 result in inverted dispersion.
> >>
> >> You are using fade_power 1000 !? You should use 1 or 1001.
> >> Using 1000 may cause some issues.
> >
> > Hello Alain,
> >
> > Thank you so much for your reply and suggestions.  As you may have noticed, I am
> > still in the process of understanding the different features.
> >
> > In the case of max_trace_level, I have put this all the way up to the max as you
> > suggested, but this did not resolve the issue from my original script.  I'll
> > have to keep digging for a solution in that regard.
> >
> > For the area_light, I was certainly not clear on the pov-ray documentation and
> > examples.  From what I understand, I am creating a box (light box) that is
> > parallel with the xy-plan, onto which I'm stretching an array of 100x100 light
> > sources.  And as you stated, by adding the adaptive, feature, this gets
> > increased when running (Great thing to know!  I wasn't completely clear on what
> > happened in the background).
> >
> > I am, however, still confused on why the area_light would be tilted.  As you
> > mentioned, I want a light parallel to the xy plane, and thought that this was
> > the case.
> >
> > Given this example below, my understanding is that my light_box is a box that is
> > 160x200x2 units (x,y,z) and collared white.  I then locate my light_source at
> > <light_loc_x, light_loc_y,light_loc_z>.  I then use the area_light feature to
> > define two points <-10, -10, 10>, <10, 10, 10> from the origin to indicate the
> > vectors over which to stretch the light.
> >
> > #declare light_box = box{ <-80,-100,0>, <80,100,2>
> >          pigment{color White}
> >         } //end light box
> > light_source {
> >      <light_loc_x, light_loc_y,light_loc_z>
> >      color White
> >      area_light <-10, -10, 10>, <10, 10, 10>, 100, 100
> >      adaptive 1
> >      jitter
> >      looks_like { light_box }
> >    }
> >
> >
> The size vectors of an area_light define the 2D dimentions of the
> area_light. A line going from the origin to one of them will be parallel
> to the side of the area_light.
>
> Simple length are used for a light array with sides parallel to the axis.
> Two non-zero component are used for an array parallel to one of the
> major planes but rotated/sheared.
> Three non-zero components will define an array that is not parallel to
> any of the planes.
>
> Normally, we use simple lengts parameters, each in line with one of the
> axis.
>
> In the present example, the vectors are diagonal. They pass through the
> origin <0,0,0> and the defined points, or <-10, -10, 10> and <10, 10, 10>.
>
> It goes from <-10, -10, 10> to <0, 0, 0> to <10, 10, 10>.

>
> If you want an area_light parallel to the X-Z plane, then, the vectors
> need their Y components to be zero.
>
> light_source {
>      <light_loc_x, light_loc_y,light_loc_z>
>      color White
>      area_light <-10, 0, 10>, <10, 0, 10>, 100, 100
>      adaptive 1
>      jitter
>      looks_like { light_box }
>    }

>
> light_source {
>      <light_loc_x, light_loc_y,light_loc_z>
>      color White
>      area_light <-10, -10, 0>, <10, 10, 0>, 100, 100
>      adaptive 1
>      jitter
>      looks_like { light_box }
>    }
> Defines a LINEAR light array as the two vectors are colinear. It won't,
> but should, generate at least a warning.

Hello Alain,

Thank you again for all of your input and help.  I was unexpectedly out of my
project for a bit, but have implemented a number of changes of the code that
have resolved the issues of my bubbles being opaque.  I have also declared
objects and materials to simplify the code.

The last issue that I'm having is this topic of the area_light.  Your
explanation is much clearer than the documentation online, and I think I now
have it set in my scene correctly.  I just wanted to bounce this off of you as a
sanity check:

What I want is an area_light acting as a diffuse backlight shining through my
tube setup into my camera.  I want this area_light parallel to the XY plane
with dimensions 160x200, centered along the Z-axis, and translated +100 units in
the Z direction.

If I were only defining an area light without attaching it to an object it would
be defined as:

light_source {
    <0, 0,100>
    color White
    area_light <160, 0, 0>, <, 200, 0>, 100, 100
    adaptive 1
    jitter
  }

When I do this, however, the background is all black, as I believe this only
produces rays from the defined area_light, but doesn't really simulate the
appearance of looking into a bright backlight.  To mimic realistic backlighting,
I can then use the command looks_like{ light_box } where I predefine a white
rectangle called "light_box."  My code then looks like this:

#declare light_box = box{ <-80,-100,0>, <80,100,2>
        pigment{color White}
       } //end light box

light_source {
    <0, 0,100>
    color White
    area_light <-10, -10, 0>, <10, 10, 0>, 100, 100
    adaptive 1
    jitter
    looks_like { light_box }
  }

Doing this, I have defined an area_light parallel to the XY, stretched it over
my box dimensions, and translated that box/area_light +100 units in the
Z-direction.

Is this correct?

Sincerely,

bubble_person

Post a reply to this message

Attachments:
Download 'example-transparent-object-10-obj-and-mat-declaration.pov.txt' (10 KB)

Le 2021-12-01 à 08:58, bubble_person a écrit :

> light_source {
>      <0, 0,100>
>      color White
>      area_light <160, 0, 0>, <, 200, 0>, 100, 100
>      adaptive 1
>      jitter
>    }
> 
> When I do this, however, the background is all black, as I believe this only
> produces rays from the defined area_light, but doesn't really simulate the
> appearance of looking into a bright backlight.  To mimic realistic backlighting,
> I can then use the command looks_like{ light_box } where I predefine a white
> rectangle called "light_box."  My code then looks like this:
> 
> #declare light_box = box{ <-80,-100,0>, <80,100,2>
>          pigment{color White}
>         } //end light box
> 
> light_source {
>      <0, 0,100>
>      color White
>      area_light <-10, -10, 0>, <10, 10, 0>, 100, 100// Not correct !
>      adaptive 1
>      jitter
>      looks_like { light_box }
>    }
> 
> Doing this, I have defined an area_light parallel to the XY, stretched it over
> my box dimensions, and translated that box/area_light +100 units in the
> Z-direction.
> 
> Is this correct?
Not quite...
> 
> Sincerely,
> 
> bubble_person
> 

First point : It is important to remember that light sources are never 
directly visible by the camera. They are ONLY places from where light 
emanate to illuminate the scene, they are not actual objects.

In your example, one side of the area_light is parallel to a line going 
from the origin to a point at <-10, -10, 0>, and the other side is 
parallel to a line going from the origin to <10, 10, 0>.
Those two lines are co-linear. This will cause soft shadows in only one 
direction. That direction is a diagonal.

There is an obvious, for me, confusion about what is defined where.

When defining a box, you use the two opposite corners. You effectively say :
Here is a box with faces parallel to the orthogonal planes, and it's 
opposite corners are at those locations.

When defining an area_light, you define the DIRECTION and length of each 
sides, NOT the location of the corners of the parallelogram covering the 
area_light. Here, you are effectively saying :
Here is a parallelogram centred at the light's location with one side 
oriented this way and this long, and the other side oriented that way 
and that long.

Normally, you want those to be orthogonal. In your case, they need to 
align to the X and Y axis. That mean that only one coordinate have to be 
non-zero and the other two have to be zero. The sign is not important, 
only the absolute value of the length.

area_light 160*x, 200*y, 100, 100
area_light -160*x, 200*y, 100, 100
area_light 160*x, -200*y, 100, 100
and
area_light -160*x, -200*y, 100, 100
all define exactly the same area_light.

As you want the light to be parallel to the X-Y plane, it should be 
defined as :
#declare light_box = box{ <-80,-100,0>, <80,100,2>
         pigment{color White}
   finish{emission 1}
        } //end light box

light_source {
     <0, 0,100>
     color White
     area_light 160*x, 200*y, 65, 65
     adaptive 0 // May be enough
     jitter
     looks_like { light_box }
   }

The smaller size is more than adequate. Because it use the adaptive 
mechanism, the performance is nearly identical.
Just using adaptive 0 will enable the adaptive sampling. The value is 
not an on/off switch, but determine the minimum number of elements to 
start with.

adaptive 0 start with just the four corners, a 2x2 array. (2^0 +1)
adaptive 1 start with a 3x3 array. (2^1 +1)
adaptive 2 start with a 5x5 array. (2^2 +1)
adaptive 3 start with a 9x9 array. (2^3 +1)
.
.
.

That progression is also why your 100 by 100 array get increased to 129 
by 129, or 2^7 + 1.

Post a reply to this message

Alain Martel <kua### [at] videotronca> wrote:

>
> > light_source {
> >      <0, 0,100>
> >      color White
> >      area_light <160, 0, 0>, <, 200, 0>, 100, 100
> >      adaptive 1
> >      jitter
> >    }
> >
> > When I do this, however, the background is all black, as I believe this only
> > produces rays from the defined area_light, but doesn't really simulate the
> > appearance of looking into a bright backlight.  To mimic realistic backlighting,
> > I can then use the command looks_like{ light_box } where I predefine a white
> > rectangle called "light_box."  My code then looks like this:
> >
> > #declare light_box = box{ <-80,-100,0>, <80,100,2>
> >          pigment{color White}
> >         } //end light box
> >
> > light_source {
> >      <0, 0,100>
> >      color White
> >      area_light <-10, -10, 0>, <10, 10, 0>, 100, 100// Not correct !
> >      adaptive 1
> >      jitter
> >      looks_like { light_box }
> >    }
> >
> > Doing this, I have defined an area_light parallel to the XY, stretched it over
> > my box dimensions, and translated that box/area_light +100 units in the
> > Z-direction.
> >
> > Is this correct?
> Not quite...
> >
> > Sincerely,
> >
> > bubble_person
> >
>
> First point : It is important to remember that light sources are never
> directly visible by the camera. They are ONLY places from where light
> emanate to illuminate the scene, they are not actual objects.
>
> In your example, one side of the area_light is parallel to a line going
> from the origin to a point at <-10, -10, 0>, and the other side is
> parallel to a line going from the origin to <10, 10, 0>.
> Those two lines are co-linear. This will cause soft shadows in only one
> direction. That direction is a diagonal.
>
> There is an obvious, for me, confusion about what is defined where.
>
> When defining a box, you use the two opposite corners. You effectively say :
> Here is a box with faces parallel to the orthogonal planes, and it's
> opposite corners are at those locations.
>
> When defining an area_light, you define the DIRECTION and length of each
> sides, NOT the location of the corners of the parallelogram covering the
> area_light. Here, you are effectively saying :
> Here is a parallelogram centred at the light's location with one side
> oriented this way and this long, and the other side oriented that way
> and that long.
>
> Normally, you want those to be orthogonal. In your case, they need to
> align to the X and Y axis. That mean that only one coordinate have to be
> non-zero and the other two have to be zero. The sign is not important,
> only the absolute value of the length.
>
> area_light 160*x, 200*y, 100, 100
> area_light -160*x, 200*y, 100, 100
> area_light 160*x, -200*y, 100, 100
> and
> area_light -160*x, -200*y, 100, 100
> all define exactly the same area_light.
>
> As you want the light to be parallel to the X-Y plane, it should be
> defined as :
> #declare light_box = box{ <-80,-100,0>, <80,100,2>
>          pigment{color White}
>    finish{emission 1}
>         } //end light box
>
> light_source {
>      <0, 0,100>
>      color White
>      area_light 160*x, 200*y, 65, 65
>      adaptive 0 // May be enough
>      jitter
>      looks_like { light_box }
>    }
>
> The smaller size is more than adequate. Because it use the adaptive
> mechanism, the performance is nearly identical.
> Just using adaptive 0 will enable the adaptive sampling. The value is
> not an on/off switch, but determine the minimum number of elements to
> start with.
>
> adaptive 0 start with just the four corners, a 2x2 array. (2^0 +1)
> adaptive 1 start with a 3x3 array. (2^1 +1)
> adaptive 2 start with a 5x5 array. (2^2 +1)
> adaptive 3 start with a 9x9 array. (2^3 +1)
> .
> .
> .
>
> That progression is also why your 100 by 100 array get increased to 129
> by 129, or 2^7 + 1.

Hello Alain,

Thank you so much for the in-depth description and example to illustrate the
concepts.  I see exactly what you mean, and I definitely got myself turned
around on it.  This makes total sense about the light source not being visible
by itself, and the coordinate system.  I think I got turned around on the online
diagrams of the area_light, and trying to figure out where the two defining
vectors were connected (as you said, an origin which is why I was doing wacky
things like making two co-linear vectors!).

As for the adaptive, this makes sense now and thank you for making this clear.
I just posted another question on my rendering that includes essentially this
same question.  I did not see your reply, and will go change the post if I can
because this has cleared up my questions.  Thank you again for all of your
support and insight!

Sincerely,

Bubble_person

Post a reply to this message