"clipka" <ano### [at] anonymousorg> wrote in message 
news:4dd5a5ed$1@news.povray.org...
> Am 19.05.2011 20:47, schrieb SGeier:
>
>> 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).
>
> You didn't actually /try/ the code you posted, did you?

Yes, I did. Noting that this doesn't work.

> Otherwise you'd have noticed that above code does not support your point 
> at all, but instead just gives a parse error.

Indeed, it does. Which I noticed. Which is why I was trying to coax Thorsten 
Froehlich into trying his own suggestion. Which was this:

> add all_intersections and just be happy.

Which does not work. Thank you for trying it. Thank you for noticing that 
*the advice given by people who know the program so well DOES NOT WORK*.

> all_intersections needs to go before the clipped_by statement.

Thank you for pointing that out. Always pleased to learn something.

> That, by the way, is in the docs, too.

No, it is not.

This is exactly where our views on the documentation differ drastically. 
Yes, now that you mention it, I can see how one *could* read the 
documentation such as to suggest that. However it *definitely* does not 
contain the sentence

"all_intersections needs to go before the clipped_by statement."

or any sentence anywhere close to it.

Here's what section 3.4.4 of the documentation shipping with the windows 
verion *actually* says:
isosurface {
  function { FUNCTION_ITEMS }
  [contained_by { SPHERE | BOX }]
  [threshold FLOAT_VALUE]
  [accuracy FLOAT_VALUE]
  [max_gradient FLOAT_VALUE]
  [evaluate P0, P1, P2]
  [open]
  [max_trace INTEGER] | [all_intersections]
  [OBJECT_MODIFIERS...]
  }
This tells me that a number of items can occur inside the isosurface{} 
entity. For example [threshold ...] or [contained_by ...] and a whole class 
of [object modifiers]. Nowhere in the docs is any mention that their order 
matters in any way and as a matter of fact some of the examples in the 
tutorial have them in an order different from the above.

If the [object modifiers] have a special status here, in that they *have* to 
be at any one particular place (at the end), then that needs to be spelled 
out. If it isn't spelled out, then you cannot claim that it is in the docs.

Here is a place where the documentation might not be in direct contradiction 
with the behavior of the program, but the program certainly doesn't behave 
as documented. [all_intersections] can apparently go anywhere it wants in 
that list up there *except* after [object modifiers] -- and users are 
supposed to magically know that even though it is definitely NOT written 
anywhere.

And when someone like myself complains about the documentation we're being 
told that we should improve it. But of course we *cannot* improve it since 
there is no way to find out what the real behaviour actually *is*, since the 
documentation doesn't mention it and asking on usenet gets me helpful advice 
like

> add all_intersections and just be happy.

which I had seen, tried, and noticed it didn't work. So I figured that 
something changed since the docs were written, so I post here.

So it turns out the whole thing was *really* not about clipping at all, all 
the blah-blah about reading the documentation on clipping and max_trace and 
all_intersections was completely besides the point. Apparently neither you 
nor Thorsten had the slightest idea what was wrong, you just immediately 
assumed that *obviously* I hadn't read the documentation and *obviously* you 
know exactly what's going on, no need to actually investigate anything or 
think about anything.

Cool, so there's nothing wrong with the binary, it's the documentation that 
is unclear. Good to know.

Now why is it like pulling teeth to get someone to actually come out and 
examine things and state these things here on the ng? Until I posted the few 
lines there in toto, nobody around here had even *tried* to diagnose what my 
problem might be -- you all just assumed you knew exactly what the problem 
was (and it turned out to be somewhere else).

> You're complaining that Thorsten did not try out the code you posted - but 
> why should he, if he knows POV-Ray good enough (and yes, obviously better 
> than you) that he's not in the least surprised, and can even tell you 
> /why/ it is happening? (Besides, what makes you so sure that he didn't try 
> it?)

Because his answer "add this line to your SDL and it'll all work" did NOT 
work. Either he doesn't know POV-Ray as well as you both think, or he knows 
it *too* well, where he's not stating what assumptions *he* is making (which 
is exactly what I find myself accused of).

Post a reply to this message