"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

Am 19.05.2011 05:06, schrieb SGeier:

>> 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.

If you think the documentation is bad, then you're happily invited to 
help make it better.

It's not like the developers & other people helping with POV-Ray would 
be paid anything for it; our only payment is the joy of doing it (and 
every programmer knows that implementation work is more fun than writing 
documentation), the joy of seeing people get good results of it, and the 
joy of receiving some motivating feedback from the community now and then.

So if you /want/ anything from us, or want to /insist/ on some point of 
view that the dev team does not share, you're in the wrong place.

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

It's one thing to get feedback on things that people /think/ is wrong. 
Getting feedback from someone who /knows better/ (or at least sounds 
like that) is something entirely different.

> 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.

No. To the programmer, the /intention/ is the end-all and be-all. If the 
code fails to match that, it is buggy. If the documentation fails to 
match that, it is either wrong (making an explicit statement that is not 
true), incomplete (failing to make an explicit statement that is true 
bot not necessarily obvious to the user), or imprecise (making a 
statement that can be interpreted in a way that is true, but also in 
another way that is not).

In this particular case, the documentation is /incomplete/, but not 
wrong: It does /not/ make an explicit statement about the situation you 
encountered. It does however make a statement about similar situations 
with CSG, which /might/ give resourceful users a hint what's going wrong 
with regard to clipped_by.


BTW, to the end user, the /expectation/ is the end-all and be-all; the 
documentation can only serve to modify those expectations. So if some 
docs do not explicitly mention the program's behaviour in a very rare 
situation, who is outright /wrong/: The documentation, or the user's 
expectations? I dare say the latter, because the docs simply cannot 
foresee all that a user may expect.

Also note that in real life there is no such thing as a /complete/ 
documentation.

> 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.

I disagree in some points:

(1) The docs do not /lead/ the reader to expect behaviour different from 
what is implemented in this case. It is /your/ expectation, and all you 
can blame the documentation for is that it did not /lead you away/ from 
that expectation. Provided that you even gave it a chance to do so, by 
thoroughly reading the isosurfaces doc section.

(2) I guess that careful reading of the doc section on isosurfaces 
/will/ lead the majority of readers away from that expectation, at least 
to the degree that they're not too surprised when their original 
expectation proves wrong.

(3) My definition of a "false" documentation is more strict than yours 
seems to be. In my terminology, "incomplete" or "imprecise" is not 
necessarily "false".


> If that is "as intended", then this intention needs to be communicated (in
> the docs, not here).

(4) There is no /need/ to communicate the programmers' intentions to the 
users. It's probably /helpful/, but there is no such /obligation/ to the 
dev team - neither legally (see the license) nor morally (what you get 
from the dev team is a free gift, and you can either take it or leave 
it, and there's nothing you can /demand/ on top).

Post a reply to this message

"Thorsten Froehlich" <tho### [at] trfde> wrote in message 
news:4dd41abd@news.povray.org...
> On 18.05.11 21:00, SGeier wrote:
>
> It certainly helps to read the documentation when being pointed to it, 
> rather than complain about being helped

It /also/ certainly helps to try a non-functioning case of code when being 
pointed to it, rather than complain about being helped. Because that's what 
*I'm* doing when I point out things that don't work: help you. By either 
alerting you to buggy code (code that does not work as intended) or buggy 
documentation (documentation that does not communicate how things are 
intended to work).

>... add all_intersections and just be happy.

Why don't you try it yourself?

Seriously: Why not?

I gave you the best bug-report I can think of writing; with a few discrete 
steps where I describe at each step why I am taking it, what I expect to see 
and what I actually see.

What do I have to do to motivate you to simply follow along with my example, 
see for yourself where things stop working - and then enter that line and 
see it /start/ working. Wouldn't that give you satisfaction? Why are you so 
afraid of simply trying it? What do you have to lose here?

Let me save you typing effort and reproduce the whole file so you can just 
cut/paste it:

// --------------------start here
  #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}}

  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}
          all_intersections
        }
//--------------------end here

See: I have the best documentation there is: the program itself. Whatever 
the program does is whatever it does. You may /imagine/ that you know it 
better than me, but I've actually looked at it. I get to see the actual 
binary, produced by compiler 'x', using library 'y' interacting with OS 'z'. 
(OS'es are Windows Server.03 32bit and and Server.08 64bit just in case 
anybody really cares).

Post a reply to this message