"clipka" <ano### [at] anonymousorg> wrote in message 
news:4dd66204@news.povray.org...
> Am 20.05.2011 03:12, schrieb SGeier:
>> 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.

No, it is not an assumption. It is an *observation*.

I learned about isosurfaces by reading the isosurface tutorial. Isn't that 
what it's for? In the tutorial there are bits of example code. They have 
various items in various order, including order that is expressly in 
conflict with the above list. For example section 2.3.3.3.6 of the 
documentation that ships with the current RC3 has this piece of code:

  #declare Blob_threshold=0.01;

  isosurface {
    function {
      (1+Blob_threshold)
      -pow(Blob_threshold, fn_A(x,y,z))
      -pow(Blob_threshold, fn_B(x,y,z))
    }
    max_gradient 4
    contained_by { box { -2, 2 } }
  }


This has max_gradient *before* contained_by. And it works just fine. At this 
point I'm not exactly "assuming" anything when I start moving the other 
parts around -- and meeting with perfectly fine success. No problems placing 
any of the above in any order - *except* those "object_modifiers".

And no, nowhere in the tutorial is there any mention that there's any 
exceptions to this floating around.

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

I'm having trouble figuring out how things work by reading the verbose parts 
of the documentation and you think I'm going to go to the *quick-reference* 
to look them up? Seriously?

Especially after I've seen it start with a warning that it uses incompatible 
notation and thus that anything I learn here will not actually transfer to 
what I read elsewhere in the docs?

> [...] The only thing unclear was why you insisted it was an error.

I didn't "insist" on anything - Here's the first and last part of my 
original post:



>"SGeier" <som### [at] somewherecom> wrote in message 
>news:<4dd316e8$1@news.povray.org>...

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

[...]

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

>

> Why?

>



I posted something and asked "why is this like that". If someone had simply 
told me why it is that way, I would have learned something. Instead I was 
told "you didn't read the docs".  Huh. Very helpful. Turns out what I was 
*really* bumping into was about some subtle distinction about the items I 
can put into an isosurface{} statement, namely that some of them are 
"object_modifiers" and assume a special place, while others are 
object-specific and can go wherever.

Why? Who knows. I already have a max_trace_level in my global_settings, but 
isosurface ignores that and instead needs to be told its own specialized 
max_trace and when I do that it magically becomes  isosurface-specific and 
thus cannot be placed after clipped_by. Even though it is only ever needed 
*because* I am using clipped_by in the first place. IF I use clipped_by, 
THEN I need a max_trace and it must come BEFORE the clipped_by that 
necessitated it. And this is so amazingly *obvious* that it is sufficient to 
post "you didn't read the docs" because the docs are so completely clear on 
this.

Seriously.

Yes, I was making an assumption there somewhere: if the program and the docs 
disagree, the program wins. Thus something changed in the program since the 
docs were written. Not a big deal - let me post and ask around. Hah.

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

To be as clear as I can: I have certainly NOT read every single page in the 
docs. Because the documentation is amazingly self-indulgent in page upon 
page of tutorials on what the frickin' #if command does, but fails to 
mention the basic things someone trying to compose scripts in the SD 
language actually needs to know. Except for the few that are actually tucked 
away somewhere and sometimes I even sumble across them (usually while trying 
to figure out something else).

I have *easily* spent five times as much time reading POV-Ray documentation 
than reading Python docs; yet I am completely confident when I write Python 
code because what I have read explained the *why* of the various things in 
the simple, straightforward order in which an intelligent reader would 
expect to read them. While I keep flailing around in POV-Ray because such 
simple things as the order of ray-intersection test and clipping are either 
not documented at all or if they are then they're buried somewhere.

Post a reply to this message