OK, I'm either doing something phenomenally stupid, or there's a blatant bug 
in isosurface{} in 3.7rc3.

Step 1) Consider the following simple scene:


  #version 3.7;
  global_settings { assumed_gamma 2.2 }

  camera{ location 5 look_at 0 right x*4/3 }
  light_source{<2,4,8>, <1, .8, .6> }

  sky_sphere {pigment {gradient -y}}

  #declare clipper = difference {box {-2 2} box {<0,-3,0> 3}}
  object {clipper pigment {rgbft <0,1,1,.2,.2>} }


I'm declaring an object and displaying it. It is a box with one quarter 
taken out. I'm calling it "clipper" because I want to use it to clip another 
object.

Step 2) Now add the following object:

  sphere {0 2 pigment {rgb 1}}

Since 'clipper' is parially transparent, you can see the back 3/4 though it 
with the front quarter exposed.

Step 3) use 'clipper' to clip the sphere, i.e. modify the 'sphere' object 
like this:

  sphere {0 2 clipped_by {clipper} pigment {rgb 1}}

The front part of the sphere is now clipped away by the 'clipper' box, but 
the rest can still be seen in the box. Note the shadow cast by the front 
right edge of the sphere onto/into the inside of the sphere.

Step 4) Remove the line that shows the clipper box:

  // object {clipper ....

You can now see the (hollow) back 3/4 of a sphere with the opening pointing 
at you. You can still see the aforementioned shadow.

So far this is all as I would expect it.

HOWEVER: now do the same thing again, but in step (2), instead of the 
sphere{} put this simple isosurface instead:

  isosurface{function{ sqrt(x*x+y*y+z*z) }
        threshold 2 max_gradient 100 contained_by{ box {-5 5} }
     //     clipped_by { clipper }
          pigment {rgb 1}
        }

In steps (2) and (3) I see the exact same thing that I see with the sphere 
object. In particular I can see the shadow on step (3) that tells me that I 
can see the inside/backside of the isosurface.

But in step 4, the back/inside of the isosurface is gone.

Why?

Post a reply to this message

Le 18/05/2011 02:46, SGeier a écrit :
> OK, I'm either doing something phenomenally stupid, or there's a blatant bug 
> in isosurface{} in 3.7rc3.

Have you tried it with 3.6 ?

> Why?

I would not use clipped_by to perform CSG intersection.


-- 
Software is like dirt - it costs time and money to change it and move it
around.

Just because you can't see it, it doesn't weigh anything,
and you can't drill a hole in it and stick a rivet into it doesn't mean
it's free.

Post a reply to this message

"SGeier" <som### [at] somewherecom> wrote:
>   isosurface{function{ sqrt(x*x+y*y+z*z) }
>         threshold 2 max_gradient 100 contained_by{ box {-5 5} }
>      //     clipped_by { clipper }
>           pigment {rgb 1}
>         }
>
> In steps (2) and (3) I see the exact same thing that I see with the sphere
> object. In particular I can see the shadow on step (3) that tells me that I
> can see the inside/backside of the isosurface.
>
> But in step 4, the back/inside of the isosurface is gone.
>
> Why?

Because you did not read the manual.

See http://www.povray.org/documentation/view/3.6.1/300/

Thorsten

Post a reply to this message

On 05/18/2011 06:55 AM, Thorsten Froehlich wrote:
> "SGeier"<som### [at] somewherecom>  wrote:
>>    isosurface{function{ sqrt(x*x+y*y+z*z) }
>>          threshold 2 max_gradient 100 contained_by{ box {-5 5} }
>>       //     clipped_by { clipper }
>>            pigment {rgb 1}
>>          }
>>
>> In steps (2) and (3) I see the exact same thing that I see with the sphere
>> object. In particular I can see the shadow on step (3) that tells me that I
>> can see the inside/backside of the isosurface.
>>
>> But in step 4, the back/inside of the isosurface is gone.
>>
>> Why?
>
> Because you did not read the manual.
>
> See http://www.povray.org/documentation/view/3.6.1/300/
>
> Thorsten
>
>
>
hmmm ... I didn't spot the clue. I'm tempted to say the use of or size 
clipper ... care to offer another hint ;-)

Post a reply to this message

Jim Holsenback <jho### [at] povrayorg> wrote:
> On 05/18/2011 06:55 AM, Thorsten Froehlich wrote:
> > "SGeier"<som### [at] somewherecom>  wrote:
> >>    isosurface{function{ sqrt(x*x+y*y+z*z) }
> >>          threshold 2 max_gradient 100 contained_by{ box {-5 5} }
> >>       //     clipped_by { clipper }
> >>            pigment {rgb 1}
> >>          }
> >>
> >> In steps (2) and (3) I see the exact same thing that I see with the sphere
> >> object. In particular I can see the shadow on step (3) that tells me that I
> >> can see the inside/backside of the isosurface.
> >>
> >> But in step 4, the back/inside of the isosurface is gone.
> >>
> >> Why?
> >
> > Because you did not read the manual.
> >
> > See http://www.povray.org/documentation/view/3.6.1/300/
> >
> > Thorsten
> >
> >
> >
> hmmm ... I didn't spot the clue. I'm tempted to say the use of or size
> clipper ... care to offer another hint ;-)

The hint about CSG and isosurfaces is at the very end of that page ;-)

Thorsten

Post a reply to this message

"Thorsten Froehlich" <nomail@nomail> wrote in message 
news:web.4dd3aa7c955938cce619b42c0@news.povray.org...
> Jim Holsenback <jho### [at] povrayorg> wrote:
>> On 05/18/2011 06:55 AM, Thorsten Froehlich wrote:
>> > "SGeier"<som### [at] somewherecom>  wrote:
[...]
>> >> In steps (2) and (3) I see the exact same thing that I see with the 
>> >> sphere
>> >> object. In particular I can see the shadow on step (3) that tells me 
>> >> that I
>> >> can see the inside/backside of the isosurface.
>> >>
>> >> But in step 4, the back/inside of the isosurface is gone.
>> >>
>> >> Why?
>> >
>> > Because you did not read the manual.
>> >
>> > See http://www.povray.org/documentation/view/3.6.1/300/
>> >
>> > Thorsten
>> >
>> >
>> >
>> hmmm ... I didn't spot the clue. I'm tempted to say the use of or size
>> clipper ... care to offer another hint ;-)
>
> The hint about CSG and isosurfaces is at the very end of that page ;-)
>
> Thorsten

*IF* you are making reference to this sentence:

  "By default POV-Ray searches only for the first surface which the ray 
intersects. But when using an isosurface in CSG operations, the other 
surfaces must also be found. Therefore, the keyword max_trace must be added 
to the isosurface statement. It must be followed by an integer value.

*THEN* I'd like to point out that this sentence is false:
- The back-side of the isosurface IS the first surface the ray intersects 
after the sphere is clipped.
- It is in fact found when the 'clipper' object is visible.

It only vanishes after I turn off the clipper object. Even though it is 
still the first surface of the sphere that the viewing-ray intersects 
(because all surfaces "in front of it" are clipped). Nothing has changed 
about the sphere or which of its surfaces should or should not be 
intersected by the viewing ray; all that has changed is that I made the 
clipper-volume invisible.

Of course there is no reason why 3.7 should conform to the 3.6 
documentation. Which makes it a bit disingenous to point people to the 3.6 
docs when they ask questions about 3.7 regarding behaviour *that is 
definitely in conflict with the 3.6 documentation*.

Post a reply to this message

On 18.05.11 21:00, SGeier wrote:
> *IF* you are making reference to this sentence:
>
>    "By default POV-Ray searches only for the first surface which the ray
> intersects. But when using an isosurface in CSG operations, the other
> surfaces must also be found. Therefore, the keyword max_trace must be added
> to the isosurface statement. It must be followed by an integer value.
>
> *THEN* I'd like to point out that this sentence is false:

The sentence is true and correct for 3.6 as well as 3.7. What is wrong is 
your interpretation of what you are seeing without knowing the inner 
workings of POV-Ray by making assumptions about the inner workings that are 
false.

> Of course there is no reason why 3.7 should conform to the 3.6
> documentation.

You can be certain POV-Ray conforms to this part of the documentation, be it 
3.6 or 3.7.

> Which makes it a bit disingenous to point people to the 3.6
> docs when they ask questions about 3.7 regarding behaviour *that is
> definitely in conflict with the 3.6 documentation*.

No.

It certainly helps to read the documentation when being pointed to it, 
rather than complain about being helped ... add all_intersections and just 
be happy.

	Thorsten

Post a reply to this message

Am 18.05.2011 21:00, schrieb SGeier:

> *IF* you are making reference to this sentence:
>
>    "By default POV-Ray searches only for the first surface which the ray
> intersects. But when using an isosurface in CSG operations, the other
> surfaces must also be found. Therefore, the keyword max_trace must be added
> to the isosurface statement. It must be followed by an integer value.
>
> *THEN* I'd like to point out that this sentence is false:

Well, actually it's not.

> - The back-side of the isosurface IS the first surface the ray intersects
> after the sphere is clipped.

The catch is that the back side may be the first surface of the 
isosurface /within the clipped_by object/ - but /not/ the first surface 
of the isosurface /per se/ - which the ray intersects.

clipped_by is implemented as follows:

(1) The base object's intersection(s) with the ray are determined;

(2) for each intersection it is checked whether it is inside the 
clipped_by object.

Any intersections not reported by step (1) are ignored.

> - It is in fact found when the 'clipper' object is visible.
>
> It only vanishes after I turn off the clipper object. Even though it is
> still the first surface of the sphere that the viewing-ray intersects
> (because all surfaces "in front of it" are clipped). Nothing has changed
> about the sphere or which of its surfaces should or should not be
> intersected by the viewing ray; all that has changed is that I made the
> clipper-volume invisible.

Note that strictly speaking the object you're making (in)visible is 
/not/ the clipped_by object; rather, the two are independent objects 
that just happen to be derived from the same "prototype" object (your 
"clipper" object).

Once the ray hits the surface of a partially transparent object, a new 
ray is shot from that intersection point in the same direction as the 
original ray; with this intersection point being /inside/ the 
(non-clipped) isosurface, the back side now is /truly/ the first surface 
of the isosurface the ray intersects.

Again, note that the clipped_by object is /not/ a full-fledged scene 
object; POV-Ray never performs any intersection tests on it when 
shooting rays - it is /exclusively/ used to check whether an 
already-found intersection is inside of it.

> Of course there is no reason why 3.7 should conform to the 3.6
> documentation. Which makes it a bit disingenous to point people to the 3.6
> docs when they ask questions about 3.7 regarding behaviour *that is
> definitely in conflict with the 3.6 documentation*.

That's quite a *bold* statement (in any sense, including typographic); 
please be aware that /sometimes/ the developers do know POV-Ray better 
than the average user ;-)

I'd agree that Thorsten may not be the best diplomat - but technically 
he's right: The behaviour you're observing may be surprising, but works 
as intended. Maybe the wording in the docs isn't ideal, but aside from 
that there's nothing wrong.

Post a reply to this message

"clipka" <ano### [at] anonymousorg> wrote in message 
news:4dd45e2b@news.povray.org...
> Am 18.05.2011 21:00, schrieb SGeier:
>
>> *IF* you are making reference to this sentence:
>>
>>    "By default POV-Ray searches only for the first surface which the ray
>> intersects. But when using an isosurface in CSG operations, the other
>> surfaces must also be found. Therefore, the keyword max_trace must be 
>> added
>> to the isosurface statement. It must be followed by an integer value.
>>
>> *THEN* I'd like to point out that this sentence is false:
>
> Well, actually it's not.
>
>> - The back-side of the isosurface IS the first surface the ray intersects
>> after the sphere is clipped.
>
> The catch is that the back side may be the first surface of the isosurface 
> /within the clipped_by object/ - but /not/ the first surface of the 
> isosurface /per se/ - which the ray intersects.
>
> clipped_by is implemented as follows:
>
> (1) The base object's intersection(s) with the ray are determined;
>
> (2) for each intersection it is checked whether it is inside the 
> clipped_by object.
>
> Any intersections not reported by step (1) are ignored.

Good to know that this is how it is implemented. However this is NOT how it 
is documented. Put the above paragraph into the documentation and 
implementation and documentation are in agreement.

[...]
>> Of course there is no reason why 3.7 should conform to the 3.6
>> documentation. Which makes it a bit disingenous to point people to the 
>> 3.6
>> docs when they ask questions about 3.7 regarding behaviour *that is
>> definitely in conflict with the 3.6 documentation*.
>
> That's quite a *bold* statement (in any sense, including typographic); 
> please be aware that /sometimes/ the developers do know POV-Ray better 
> than the average user ;-)

I would hope so - that's why I post things here that do not work as 
documented.

There's a perennial communications problem between programmers and users: To 
the programmer, the code is the end-all and be-all. Whatever the code does 
is "true" and if the documentation deviates from it, then the documetation 
is wrong. However from the user perspective, the documentation is all there 
is - it tell me what is *supposed* to happen and if the observed results are 
different then the code is buggy.

I'm happy to go either way - but there IS still a mismatch between 
implementation and documentation here.

> I'd agree that Thorsten may not be the best diplomat - but technically 
> he's right: The behaviour you're observing may be surprising, but works as 
> intended.

To a user of POV-Ray it does not (can not) matter what the programmers 
*intended*. Unless you want every single one of us folks out here to come 
here and post so that you can explain every single one of us what you 
intended. The only thing that *can* matter to us is what is *documented*.

> Maybe the wording in the docs isn't ideal, but aside from that there's 
> nothing wrong.

If the wording in the docs leads the reader to expect behaviour different 
from what is implemented, then the wording is far enough from ideal that we 
might as well call it false. No part of the documentation indicates that the 
back/inside of the isosurface object will be found when the outer clipping 
object is made visible (or the clipped object embedded into a transparent 
object or any such thing). In the case of the sphere object, it is visible 
in both cases, in the case of the isosurface object it is visible in the 
one, but not the other case.

If that is "as intended", then this intention needs to be communicated (in 
the docs, not here).
Which it isn't.

Post a reply to this message

On 05/19/2011 12:06 AM, SGeier wrote:
> If that is "as intended", then this intention needs to be communicated (in
> the docs, not here).
> Which it isn't.

if you think it's /that/ out of whack then ... get yourself a login on 
the wiki and edit the section to your liking ... i'll even meet you 
halfway. i've copied the aforementioned section into a talk page so have 
at it

http://wiki.povray.org/content/Documentation_Talk:Reference_Section_4.2

Post a reply to this message