So I finished the Alaska building and am now working on the tallest building in
Hawaii. I made a glass texture for windows.

#declare My_glass_bluish = color rgbf <0.5, 0.5, 1.0, 0.8>;

My question isn't about the texture. It's fine.

 I placed two boxes next to each other. One was an opaque grey color that went
from z= -.886 to z= .866. The second block, which had the glass texture, went
from Z= .866 to Z= .867. After unionizing them, I turned them around, 180
degrees, on the Y axis. Behind them both, I had a box with a floor plan
superimposed on it.

When I viewed the image, I was able to see completely through the two boxes to
see the one with the floorplan. I then moved the second box from .866-.867 to
..867-.868. Basically moving it away on the Z axis by .001, so they no longer
touched.

When viewed, I could no longer see through the two boxes.

My question is, is this normal? Does the box, with the transparency, replace the
texture/pigment of the opaque box, at the location they touch?

In the past, whenever I want to make a window in an object, I used to difference
out the window hole first, before placing a transparent object there. Could it
be that I didn't have to do that, all along?

And yes, I work with tiny objects. The scale I use is 1 unit = 200 feet. That
way, all my buildings are to scale, and will fit next to each other on my final
city project.

Post a reply to this message

Le 2024-03-15 à 17:00, David Kraics a écrit :
> So I finished the Alaska building and am now working on the tallest building in
> Hawaii. I made a glass texture for windows.
> 
> #declare My_glass_bluish = color rgbf <0.5, 0.5, 1.0, 0.8>;
> 
> My question isn't about the texture. It's fine.
> 
>   I placed two boxes next to each other. One was an opaque grey color that went
> from z= -.886 to z= .866. The second block, which had the glass texture, went
> from Z= .866 to Z= .867. After unionizing them, I turned them around, 180
> degrees, on the Y axis. Behind them both, I had a box with a floor plan
> superimposed on it.
> 
> When I viewed the image, I was able to see completely through the two boxes to
> see the one with the floorplan. I then moved the second box from .866-.867 to
> ..867-.868. Basically moving it away on the Z axis by .001, so they no longer
> touched.
> 
> When viewed, I could no longer see through the two boxes.
> 
> My question is, is this normal? Does the box, with the transparency, replace the
> texture/pigment of the opaque box, at the location they touch?
> 
> In the past, whenever I want to make a window in an object, I used to difference
> out the window hole first, before placing a transparent object there. Could it
> be that I didn't have to do that, all along?
> 
> And yes, I work with tiny objects. The scale I use is 1 unit = 200 feet. That
> way, all my buildings are to scale, and will fit next to each other on my final
> city project.
> 
When two or more objects have a surface in the same location, you have 
coincident surfaces. When rendering, it's impossible to know witch one 
will be encountered first, and the other being ignored. That usually 
result in lot of noise as the «first» can change from pixel to pixel. 
Here, you got lucky and POV-Ray only hit the transparent object first. 
It could have been totally opaque, or a noisy mixture.

That's not an issue if all the objects are opaque and share the same 
texture as whatever the «first» one don't mater.
It's also often not an issue with transparent objects that have the same 
texture AND interior, but, in those case, you should use merge instead 
of union.

By moving one of the objects like you did, the surfaces are no longer 
coincident. So, if the opaque surface is in the front, you see only that 
object. If the transparent one is in front, then, you see the opaque one 
thru the transparent one.

So, punching the holes to contain the windows is the correct way.
It's better, performance wise, to use an union of smaller boxes rather 
than a large box with the holes made using a difference. Especially when 
you have many windows in that wall.

Post a reply to this message

Alain Martel <kua### [at] videotronca> wrote:
> When two or more objects have a surface in the same location, you have
> coincident surfaces. When rendering, it's impossible to know witch one
> will be encountered first, and the other being ignored. That usually

> Here, you got lucky and POV-Ray only hit the transparent object first.
> It could have been totally opaque, or a noisy mixture.
>
> That's not an issue if all the objects are opaque and share the same

> It's also often not an issue with transparent objects that have the same
> texture AND interior, but, in those case, you should use merge instead
> of union.
>
> By moving one of the objects like you did, the surfaces are no longer
> coincident. So, if the opaque surface is in the front, you see only that
> object. If the transparent one is in front, then, you see the opaque one
> thru the transparent one.
>
> So, punching the holes to contain the windows is the correct way.
> It's better, performance wise, to use an union of smaller boxes rather
> than a large box with the holes made using a difference. Especially when
> you have many windows in that wall.

Thanks for clearing that up. It makes sense. I'll just leave that tiny gap so I
can get the best effect. In this case I used union just to turn them around to
see what it looked like from the other side. I didn't intend them to be combined
together, so merge wasn't needed.

Post a reply to this message

On 16.03.2024 0:00, David Kraics wrote:

> ..867-.868. Basically moving it away on the Z axis by .001, so they no longer
> touched.
> 
> When viewed, I could no longer see through the two boxes.

Just a guess - what happen if you increase max_trace_level ?

Ilyich the Toad

Post a reply to this message

Ilya Razmanov <ily### [at] gmailcom> wrote:
> On 16.03.2024 0:00, David Kraics wrote:
>
> > ..867-.868. Basically moving it away on the Z axis by .001, so they no longer
> > touched.
> >
> > When viewed, I could no longer see through the two boxes.
>
> Just a guess - what happen if you increase max_trace_level ?
>
> Ilyich the Toad

I don't know what that does or is. Honestly, even after 30 or so years of using
this program, I only know how to use some of its features.

Post a reply to this message

hi,

"David Kraics" <bar### [at] aolcom> wrote:
> Ilya Razmanov <ily### [at] gmailcom> wrote:
> > On 16.03.2024 0:00, David Kraics wrote:
> > > ..867-.868. Basically moving it away on the Z axis by .001, so they no longer
> > > touched.
> > > When viewed, I could no longer see through the two boxes.
> >
> > Just a guess - what happen if you increase max_trace_level ?
> > Ilyich the Toad
>
> I don't know what that does or is. Honestly, even after 30 or so years of using
> this program, I only know how to use some of its features.

<https://wiki.povray.org/content/Reference:Global_Settings#Max_Trace_Level>


regards, jr.

Post a reply to this message

Le 2024-03-16 à 12:06, David Kraics a écrit :
> Ilya Razmanov <ily### [at] gmailcom> wrote:
>> On 16.03.2024 0:00, David Kraics wrote:
>>
>>> ..867-.868. Basically moving it away on the Z axis by .001, so they no longer
>>> touched.
>>>
>>> When viewed, I could no longer see through the two boxes.
>>
>> Just a guess - what happen if you increase max_trace_level ?
>>
>> Ilyich the Toad
> 
> I don't know what that does or is. Honestly, even after 30 or so years of using
> this program, I only know how to use some of its features.
> 
max_trace_level determine how many surfaces a ray can interact with 
before the tracing process stop.
Currently, it ignore simple transparent surfaces where there is no 
reflection and no refraction.
The default value is 5. That mean that the fifth surface encountered is 
treated as black, opaque and non-reflective.
That's a global_settings parameter.

global_settings{
	max_trace_level 25
  }

Post a reply to this message

On 16.03.2024 19:06, David Kraics wrote:

> I don't know what that does or is. Honestly, even after 30 or so years of using
> this program, I only know how to use some of its features.

As it was explained already, it controls the number of light/surface 
interactions for a ray. Most of my scene files, especially 
auto-generated, start with:

global_settings
{
   max_trace_level 3
   adc_bailout 0.01
   assumed_gamma 1.0
}

because objects are opaque and rather "plastic" and not expected to 
produce complex reflections and stuff, so even default max_trace_level 5 
is excessive and only makes rendering slower, I can improve rendering 
speed without quality problems by reducing max_trace_level from 5 to 3.

However, when you start using glasses, things become more complex 
because glass have not only outer surface, but inner surface. It have 
not only front, but back as well. So, if you have several glass objects 
layered or nested, surfaces multiply <s>and only one man can stop 
them</s>. The first symptom of too small max_trace_level is part of the 
scene turning black.

My morning doses of phosphodiesterase inhibitor and N-cholinomimetics 
are not completely uptaken yet, so I refuse to *think* about your scene, 
and just suggest to edit scene header to something like

global_settings
{
   max_trace_level 30
   // plus something else you may have here already
}

and see if something (beside rendering time) change. If it does, than 
trace level is the source of the problem, and you may start counting 
surfaces to define minimal sufficient value.

Ilyich the Toad
https://dnyarri.github.io/

Post a reply to this message

Le 2024-03-17 à 01:41, Ilya Razmanov a écrit :
> On 16.03.2024 19:06, David Kraics wrote:
> 
>> I don't know what that does or is. Honestly, even after 30 or so years 
>> of using
>> this program, I only know how to use some of its features.
> 
> As it was explained already, it controls the number of light/surface 
> interactions for a ray. Most of my scene files, especially 
> auto-generated, start with:
> 
> global_settings
> {
>    max_trace_level 3
>    adc_bailout 0.01
>    assumed_gamma 1.0
> }
> 
Instead of reducing max_trace_level, it's often better to increase 
adc_bailout.

When max_trace_level is reached, black is returned.
When the tracing stop due to adc_bailour, you get the current 
evaluation, not black.
In your case, you probably won't see a speed degradation using a larger 
max_trace_level. No change expected going from a value of 4 to to 50 or 
more, as sdc_bailout would kick in pretty early.

The default adc_bailout is 1/256. Your 0.01, or 1/100, is better for 
your situation. You may even use something like
adc_bailout 0.03
Without issue. It may make your rendering go a little bit faster.
I very often increase adc_bailout for test renders.

Post a reply to this message

On 17.03.2024 19:38, Alain Martel wrote:

> Instead of reducing max_trace_level, it's often better to increase 
> adc_bailout.

Funny thing, I almost forgot about it. Meaning I did it once and 
immediately forgot what I did it for. "Dementia is an excellent disease 
- no pain, and you discover something new every day" (c) country saying

Indeed, it can make some of my scenes faster. Thanks for reminding!

Ilyich the Toad
https://dnyarri.github.io/

Post a reply to this message