Am 20.05.2011 03:12, schrieb SGeier:

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

Yes, it is.

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

It does explicitly specify it in the section you quoted:

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

Read section 3.1.1 "Notation and Basic Assumptions"; nowhere in there 
does it say that the items can be specified in arbitrary order, so it's 
your assumption that is wrong again here. The fact that /some/ of the 
stuff can be re-ordered is, as a matter of fact, a feature documented 
elsewhere.

See sections 3.8 "Quick Reference" for a description of the notation 
used for the syntax specification, and section 3.8.8.4 "Isosurface" for 
the description of the isosurface syntax. There you will find that 
ISOSURFACE_ITEMS (including all_intersections) may be specified in 
arbitrary order, but must go before OBJECT_MODIFIERS.

> 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

(As you seem to like precision, please note that we're not on usenet; 
we're on a private news server.)

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

Thorsten knew /exactly/ why the stuff was happening that you saw, and I 
myself didn't post a reply until I had figured it out as well. (Believe 
me, while as a matter of fact I often /do/ start writing responses to 
reports of possible errors before checking it out, I virtually never 
press "send" before I checked that I'm not talking nonsense.) The only 
thing unclear was why you insisted it was an error.

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

Maybe because with your originally posted code we didn't need to examine 
things, because your description matched the behaviour /we/ did expect?

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

That was when your problem apparently shifted, from getting an 
unexpected (for you) result from your originally posted code to some 
rather vague complaint in connection with all_intersections (which you 
hadn't mentioned earlier, so we all naturally assumed - and still assume 
- you hadn't tried it).

So why are you surprised you're getting a more thorough inspection only 
later? It's like you're phoning up the garage complaining to the 
mechanic that the engine on your car stutters, and by the way there's a 
red light in the display, looking somewhat like a fuel pump (*); not 
surprisingly the mechanic will simply recommend to try and fill her up 
(knowing that stuttering engines are to be expected when there's a lack 
of fuel), but now you start complaining that the fuel pump doesn't fit 
in the tank. It's probably only /then/ that the mechanic will consider a 
more thorough inspection. (And as it turns out the problem is that you 
tried to pump your diesel at a pump for heavy trucks, so you blame the 
car manufacturer for failing to make a note of this incompatibility in 
the car's user manual.)

(* I am well aware that the example limps here because usually those 
lights are well documented. However, the fact that a car needs fuel to 
drive is typically taken for granted.)

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

... or he knows some things mentioned in sections of the docs you didn't 
read.

Post a reply to this message