Would one of you kind people do a sanity check for me
on this bit of pov code and tell me if it's a bug or
a feature. If I'm not mistaken when using the merge
function it should only remove interior surfaces
and not act like a intersection/difference function.
That is not what is happening with this useage as
defined below. IF it's a bug it will be the first
I have found and I will take it through the proper
channels once verified.

Thank you for your time,

Ken Tyler

camera{location<10,15,-25>look_at y*5}

light_source{<0, 50,-730>rgb 1}

//Incorrect behavior:
merge{
box{<-5, 5,-1>,<5, 7,1>}
box{<-1,-5,-1>,<1,10,1>}
 pigment{rgbf<1,0,0,1>}
  interior{ior 1.9}
   finish{ambient .95}
}

//Correct behavior:
merge{
sphere{<-10.0,10,0>,5
 pigment{rgbf<1,0,0,1>}
  interior{ior 1.9}
   finish{ambient .95}
}

sphere{<- 7.5,10,1.5>,5
 pigment{rgbf<0,0,1,1>}
  interior{ior 1.9}
   finish{ambient .95}
 }
}

plane{-z,-50 pigment{rgb 1}}

Post a reply to this message

Attachments:
Download 'us-ascii' (2 KB)

It seems to me that you are right...
It's in the merge... Strange that the boxes should eliminate eachother...
Well... Congratulations...

I wonder why it hasn't been found earlier....

//Spider


Ken wrote:
> 
> Would one of you kind people do a sanity check for me
> on this bit of pov code and tell me if it's a bug or
> a feature. If I'm not mistaken when using the merge
> function it should only remove interior surfaces
> and not act like a intersection/difference function.
> That is not what is happening with this useage as
> defined below. IF it's a bug it will be the first
> I have found and I will take it through the proper
> channels once verified.
> 
> Thank you for your time,
> 
> Ken Tyler
> 
> camera{location<10,15,-25>look_at y*5}
> 
> light_source{<0, 50,-730>rgb 1}
> 
> //Incorrect behavior:
> merge{
> box{<-5, 5,-1>,<5, 7,1>}
> box{<-1,-5,-1>,<1,10,1>}
>  pigment{rgbf<1,0,0,1>}
>   interior{ior 1.9}
>    finish{ambient .95}
> }
> 
> //Correct behavior:
> merge{
> sphere{<-10.0,10,0>,5
>  pigment{rgbf<1,0,0,1>}
>   interior{ior 1.9}
>    finish{ambient .95}
> }
> 
> sphere{<- 7.5,10,1.5>,5
>  pigment{rgbf<0,0,1,1>}
>   interior{ior 1.9}
>    finish{ambient .95}
>  }
> }
> 
> plane{-z,-50 pigment{rgb 1}}

Post a reply to this message

Spider wrote:

> It seems to me that you are right...
> It's in the merge... Strange that the boxes should eliminate eachother...
> Well... Congratulations...
>
> I wonder why it hasn't been found earlier....
>
> //Spider

I think I have figured out why it behaves this way. The two
faces in the -z/+z directions are overlapping even though
they are on the outside. Therefore they are coincident
surfaces and cancel each other out. I tried this code on
my install of v2.2 and it acted the same way so it's been
around for years. I guess the way to get around it would
be to under/over scale one of the boxes so the surfaces
don't coinside but I don't like the fact you can't create an
object with this simple cgs functioin without having a little
step on the surface. Come to think of it how would you
get a clean unstepped surface while eliminating the interior
surfaces any other way ? It's a Bug ! It's a BUG !

BUMMER !

Ken Tyler

Post a reply to this message

Ken wrote:
> 
> Spider wrote:
> 
> > It seems to me that you are right...
> > It's in the merge... Strange that the boxes should eliminate eachother...
> > Well... Congratulations...
> >
> > I wonder why it hasn't been found earlier....
> >
> > //Spider
> 
> I think I have figured out why it behaves this way. The two
> faces in the -z/+z directions are overlapping even though
> they are on the outside. Therefore they are coincident
> surfaces and cancel each other out. I tried this code on
> my install of v2.2 and it acted the same way so it's been
> around for years. I guess the way to get around it would
> be to under/over scale one of the boxes so the surfaces
> don't coinside but I don't like the fact you can't create an
> object with this simple cgs functioin without having a little
> step on the surface. Come to think of it how would you
> get a clean unstepped surface while eliminating the interior
> surfaces any other way ? It's a Bug ! It's a BUG !
> 
> BUMMER !
> 
> Ken Tyler

At first I thought 'Aha a simple coincident surface problem, one box is
always inside the other and is eliminated'.
However when A is inside B then B should be outside A and keep its
surface. Very odd.

Cheers, PoD.

Post a reply to this message

I don't know what's going on there but I tried putting a global_settings 
{max_trace_level 20}, out of habit, into the script and got a same-surface 
looking effect at the center of the cross. No other obvious changes. Then 
--another strange thing-- I tried 2 instead of 20 and no change *back* to the 
first look (difference?), even tried to comment it out; no return to previous 
state. So I shut POV off, restarted it, ran the scene again (global_settings 
still commented out) and it then returned to the first example: center 
removed.

Message <366AFABA.C1925F3F@pacbell.net>, Ken  typed...
>
>
>--------------E9E0C95792A610B50C726B33
>Content-Type: text/plain; charset=us-ascii
>Content-Transfer-Encoding: 7bit
>
>Would one of you kind people do a sanity check for me
>on this bit of pov code and tell me if it's a bug or
>a feature. If I'm not mistaken when using the merge
>function it should only remove interior surfaces
>and not act like a intersection/difference function.
>That is not what is happening with this useage as
>defined below. IF it's a bug it will be the first
>I have found and I will take it through the proper
>channels once verified.
>
>Thank you for your time,
>
>Ken Tyler
>
>camera{location<10,15,-25>look_at y*5}
>
>light_source{<0, 50,-730>rgb 1}
>
>//Incorrect behavior:
>merge{
>box{<-5, 5,-1>,<5, 7,1>}
>box{<-1,-5,-1>,<1,10,1>}
> pigment{rgbf<1,0,0,1>}
>  interior{ior 1.9}
>   finish{ambient .95}
>}
>
>//Correct behavior:
>merge{
>sphere{<-10.0,10,0>,5
> pigment{rgbf<1,0,0,1>}
>  interior{ior 1.9}
>   finish{ambient .95}
>}
>
>sphere{<- 7.5,10,1.5>,5
> pigment{rgbf<0,0,1,1>}
>  interior{ior 1.9}
>   finish{ambient .95}
> }
>}
>
>plane{-z,-50 pigment{rgb 1}}
>
>--------------E9E0C95792A610B50C726B33
>Content-Type: text/html; charset=us-ascii
>Content-Transfer-Encoding: 7bit
>
><HTML>
><TT></TT>
>
><P><TT>Would one of you kind people do a sanity check for me</TT>
><BR><TT>on this bit of pov code and tell me if it's a bug or</TT>
><BR><TT>a feature. If I'm not mistaken when using the merge</TT>
><BR><TT>function it should only remove interior surfaces</TT>
><BR><TT>and not act like a intersection/difference function.</TT>
><BR><TT>That is not what is happening with this useage as</TT>
><BR><TT>defined below. IF it's a bug it will be the first</TT>
><BR><TT>I have found and I will take it through the proper</TT>
><BR><TT>channels once verified.</TT><TT></TT>
>
><P><TT>Thank you for your time,</TT><TT></TT>
>
><P><TT>Ken Tyler</TT><TT></TT>
>
><P><TT>camera{location<10,15,-25>look_at y*5}</TT><TT></TT>
>
><P><TT>light_source{<0, 50,-730>rgb 1}</TT><TT></TT>
>
><P><TT>//Incorrect behavior:</TT>
><BR><TT>merge{</TT>
><BR><TT>box{<-5, 5,-1>,<5, 7,1>}</TT>
><BR><TT>box{<-1,-5,-1>,<1,10,1>}</TT>
><BR><TT> pigment{rgbf<1,0,0,1>}</TT>
><BR><TT>  interior{ior 1.9}</TT>
><BR><TT>   finish{ambient .95}</TT>
><BR><TT>}</TT><TT></TT>
>
><P><TT>//Correct behavior:</TT>
><BR><TT>merge{</TT>
><BR><TT>sphere{<-10.0,10,0>,5</TT>
><BR><TT> pigment{rgbf<1,0,0,1>}</TT>
><BR><TT>  interior{ior 1.9}</TT>
><BR><TT>   finish{ambient .95}</TT>
><BR><TT>}</TT><TT></TT>
>
><P><TT>sphere{<- 7.5,10,1.5>,5</TT>
><BR><TT> pigment{rgbf<0,0,1,1>}</TT>
><BR><TT>  interior{ior 1.9}</TT>
><BR><TT>   finish{ambient .95}</TT>
><BR><TT> }</TT>
><BR><TT>}</TT><TT></TT>
>
><P><TT>plane{-z,-50 pigment{rgb 1}}</TT></HTML>
>
>--------------E9E0C95792A610B50C726B33--
>

-- 
 omniVERSE: beyond the universe
  http://members.aol.com/inversez/POVring.html
=Bob

Post a reply to this message

In article <366b1ef6.0@news.povray.org> , ver### [at] aolcom (=Bob) wrote:

>I don't know what's going on there but I tried putting a global_settings 
>{max_trace_level 20}, out of habit, into the script and got a same-surface 
>looking effect at the center of the cross. No other obvious changes. Then 
>--another strange thing-- I tried 2 instead of 20 and no change *back* to the 
>first look (difference?), even tried to comment it out; no return to previous 
>state. So I shut POV off, restarted it, ran the scene again (global_settings 
>still commented out) and it then returned to the first example: center 
>removed.

Yes, this is a know problem of POV-Ray, max_trace_level is stored in a global
variable, and it is no (always?) updated/installized except at startup. This bug only
exists for the GUI versions of POV-Ray (Win and Mac) as they are not terminated  and
restarted for each render.


     Thorsten


For all who want to know, the value of max_trace_level is stored in the global
Max_Trace_Level in render.c.

Post a reply to this message

Thanks for that bit of important info. If one were to go by just the 
statistics after a render every max_trace_level shows a change if the number 
is different in the script.
Back to the merge thing...
I didn't look at it too well first time. Then I realized the textures were 
added differently for the pair of boxes and pair of spheres. The boxes have a 
shared texture in the merge statement. The spheres have independent textures.
The spheres also have a shadow showing the supposedly merged surface area 
which should be gone, and it is labeled as "correct". The boxes labeled 
"incorrect" have no shadow of the merged surfaces even when they are changed 
to have non-coincident surfaces by scaling the z of one slightly larger. Plus 
the anti-merge (or whatever) effect is gone this way too.

So, now what?

Message <366b26cd.0@news.povray.org>, Thorsten Froehlich  typed...
>
>In article <366b1ef6.0@news.povray.org> , ver### [at] aolcom (=Bob) wrote:
>
>>I don't know what's going on there but I tried putting a global_settings 
>>{max_trace_level 20}, out of habit, into the script and got a same-surface 
>>looking effect at the center of the cross. No other obvious changes. Then 
>>--another strange thing-- I tried 2 instead of 20 and no change *back* to 
the 
>>first look (difference?), even tried to comment it out; no return to 
previous 
>>state. So I shut POV off, restarted it, ran the scene again (global_settings 
>>still commented out) and it then returned to the first example: center 
>>removed.
>
>Yes, this is a know problem of POV-Ray, max_trace_level is stored in a global
>variable, and it is no (always?) updated/installized except at startup. This 
bug
> only
>exists for the GUI versions of POV-Ray (Win and Mac) as they are not 
terminated 
> and
>restarted for each render.
>
>
>     Thorsten
>
>
>For all who want to know, the value of max_trace_level is stored in the 
global
>Max_Trace_Level in render.c.

-- 
 omniVERSE: beyond the universe
  http://members.aol.com/inversez/POVring.html
=Bob

Post a reply to this message

=Bob wrote:

> Back to the merge thing...
> I didn't look at it too well first time. Then I realized the textures were
> added differently for the pair of boxes and pair of spheres. The boxes have a
> shared texture in the merge statement. The spheres have independent textures.
> The spheres also have a shadow showing the supposedly merged surface area
> which should be gone, and it is labeled as "correct".

The different pigments do nothing to the behavior. I checked.The demarkation line
you are seeing is due to the different
pigments and not due to internal surfaces. Otherwise they
would follow the shape of the sphere as opposed to being
a straight line.

> The boxes labeled
> "incorrect" have no shadow of the merged surfaces even when they are changed
> to have non-coincident surfaces by scaling the z of one slightly larger.

> Plus the anti-merge (or whatever) effect is gone this way too.

You lost me on this one. Care to rephrase the observation ?

> So, now what?

Which way to the circus ?

Ken Tyler

Post a reply to this message

Okay, I lined up the spheres perpendicular to the light and now see what you 
mean. I should have done that before.
  About the boxes, I removed the same-surface effect by scaling one of them 
slightly larger in the z direction.
  No merge problem so it appears. Except...

// blackout in box edges and in sphere overlap (check it out)

global_settings {max_trace_level 30 } //set high doesn't help

camera{location<5,15,-25>look_at y*5} //shifted camera over -10*x from before

light_source{<0, 50,-730> rgb 3} //same here, intense light

//Incorrect behavior: (corrected?)
merge{
box{<-5, 5,-1.01>,<5, 7,1.01> //z dimension increased
// pigment{rgbf<0,0,1,1>}
//  interior{ior 1.9}
//   finish{ambient .95}
}
box{<-1,-5,-1>,<1,10,1>}
 pigment{rgbf<1,0,0,1>}
  interior{ior 1.9}
   finish{ambient .95}
// }
}

//Correct behavior: (?what's with the blackout?)
merge{
sphere{<-10,10,0>,5
 pigment{rgbf<1,0,0,1>}
  interior{ior 1.9}
   finish{ambient .95}
}
sphere{<-7.5,10,0>,5
 pigment{rgbf<0,0,1,1>}
  interior{ior 1.09} //ior turned down to see blue at all
   finish{ambient .95}
 }
}

plane{-z,-50 pigment{rgb 1}}

background { color red 1 green 1 blue 1 } //no help either

//END

I tried increasing color intensities above 1 with no change too. I would have 
expected to see magenta. Any ideas?
  Oh yeah, Barnum&Baileys was recently in town, but I didn't see which way the 
train went ;)

Message <366BD04E.8B806AD0@pacbell.net>, Ken  typed...
>
>=Bob wrote:
>
>> Back to the merge thing...
>> I didn't look at it too well first time. Then I realized the textures were
>> added differently for the pair of boxes and pair of spheres. The boxes have 
a
>> shared texture in the merge statement. The spheres have independent 
textures.
>> The spheres also have a shadow showing the supposedly merged surface area
>> which should be gone, and it is labeled as "correct".
>
>The different pigments do nothing to the behavior. I checked.The demarkation 
lin
>e
>you are seeing is due to the different
>pigments and not due to internal surfaces. Otherwise they
>would follow the shape of the sphere as opposed to being
>a straight line.
>
>> The boxes labeled
>> "incorrect" have no shadow of the merged surfaces even when they are 
changed
>> to have non-coincident surfaces by scaling the z of one slightly larger.
>
>> Plus the anti-merge (or whatever) effect is gone this way too.
>
>You lost me on this one. Care to rephrase the observation ?
>
>> So, now what?
>
>Which way to the circus ?
>
>Ken Tyler
>

-- 
 omniVERSE: beyond the universe
  http://members.aol.com/inversez/POVring.html
=Bob

Post a reply to this message

=Bob wrote:
>   Okay, I lined up the spheres perpendicular to the light and now see what you
> mean. I should have done that before.
>   About the boxes, I removed the same-surface effect by scaling one of them
> slightly larger in the z direction.
>   No merge problem so it appears. Except...
[snipped code]
> I tried increasing color intensities above 1 with no change too. I would have
> expected to see magenta. Any ideas?

I agree about the merge problem (or lack thereof) - the cutout where the
surfaces overlap is more a "behaviour" than a "bug", and any POV-Ray
user with CSG experience knows little extra dimensions here and there
are par for the course.  At any rate, on POV-Ray for DOS a scale of <1,
1, 1+1e-14> to either box removes the problem, and if precision of that
order can't be considered smooth I'm not sure we can help you....!

Regarding the black-out; this is precisely what one would expect, given
that each surface filters light of two different primary colours, ie. as
the white light passes through the red surface, it is multiplied by the
pigment (3 * <1, 0, 0> = <3, 0, 0>).  When this filtered light passes
through the blue surface it is multiplied in the same way, and by my
calculations <3, 0, 0> * <0, 0, 1> results in <0, 0, 0>.

To achieve the magenta you are looking for, you need to allow both some
red and blue to filter through both surfaces, eg. using a <3, 3, 3>
light and rgbt <1, .5, .5, 1> and rgbt <.5, .5, 1, 1> pigments, you get
rgb <1.5, .75, 1.5> where the surfaces overlap.

Post a reply to this message