"Alain" <aze### [at] qwertyorg> wrote in message 
news:4ddb1917$1@news.povray.org...

[...]>>>>     [OBJECT_MODIFIERS...]
>>>>     }
>
> Note that all items are lower case, then, you have OBJECT_MODIFIERS in all 
> UPPERCASE. This tells you that OBJECT_MODIFIERS is not in the same 
> category. In fact, it tells that OBJECT_MODIFIERS in not an item.

Pray tell. Could you imagine that this might be the case why I called it "a 
whole class of [object_modifiers]" in the paragraph directly following this 
(that you so politely quoted right here:)

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

Not that it has any bearing on this:

>>>> 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.
>
> The documentations clearly state that all object modifiers must follow all 
> objects items.

It is good to hear that there is at least one thing that the documentation 
"clearly states". Because most parts of the documentations are rather 
unclear.

Surely it wouldn't be too much of a bother if you could kindly direct me to 
the section in the documentation that "clearly states" such a thing? It 
seems that I keep missing all the important parts of the docs and I'd like 
to make sure I have read at least those parts that clearly state things.

[...]
> You seems to confuse "items" and "modifiers".
> Items can be in any order.
> Modifiers also can be specified in about any order. They also MUST follow 
> the last item.

The word "item" has a fairly well-established meaning in the English 
language, a meaning that would make every "thing" inside the {}, including 
any modifier, an "item". If the POV-Ray docs would like the reader to 
understand the term it in a manner incompatible with the common meaning then 
I'm sure they "clearly state" such a thing. Could you please simply tell me 
where I should go to find that?

[...]
>>> "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.
> You asked if there was a bug, and there is none.
> It leaves the "something phenomenally stupid" part...

As it turns out there was a third possibility: the documentation is wrong.

This is clearly a problem with my expectations: when I use the RC of some 
software, I expect to find a bug here'n'there. And maybe possibly that I'm 
just using the software wrong. I don't really expect to find documentation 
that

- doesn't document the behaviour of the software correctly AND
- doesn't express the intent of the programmers

[...]
 >>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.
>
> Again, "object_modifiers" are not items. It thus don't follows the general 
> rule of order as the items.
>

Oh, so there is such a thing as a "general rule of order"? Surely you can 
point me to the part of the documentation that expresses that rule, right?

And if object_modifiers *must* be in a certain position because they *don't* 
follow that "general rule", then I am concluding that the "general rule" is 
that I can put items into any order? Because that seems to be in direct 
contradiction with Christian Froeschlin's claim "in absence of special 
syntax, everything is to be taken literally and in the order specified."

[...]
> This is that way at least since version 1.
>
> primitive_name{mendatory_items [optional_items_in_any_order] 
> [OBJECT_MODIFIERS_IN_ANY_ORDER]}

That line there - can you show me where I can find that in the docs? 
Obviously it must be in there somewhere if it has been that way since 
version 1. Thanks.

> If you look around, you'll find that:
> Most of the time, max_gradient immediately FOLLOWS the function. It's 
> question of style and general concensus.
> Also, most of the time, contained_by is the last isosurface parameter. 
> Also a question of style and concensus.

And where, exactly, would I do that "looking around" thing you're talking 
about? The newsgroups have very little POV code on them, and where they do 
it's usually someone posting something that *doesn't* work.

I guess the obvious place would be the "code samples" section of the 
documentation. Oh, sorry, there is no such section. Hummm ...

> max_trace_level apply exclusively to transparency and reflections, never 
> ever to any surface that can never be visible.

I think you might benefit from reading the actual message I posted here that 
started the thread. It would allow you to make comments that have a bearing 
on the matter at hand. The suface I was writing about  was perfectly visible 
*if* it was encased in a transparent object. It vanished when the enclosing 
transparent object was removed. The issue is thus *very much* one of 
"transparency and reflection" and nobody here anywhere wrote about a surface 
"that can never be visible".

It would be possible to *make* the surface in question "never be visible" by 
setting
 global_settings {max_trace_level 1}

> max_trace/all_intersections is very different and there is no "magic" 
> transforming one into the other.
> max_trace_level is a global setting that affect the evaluation of tracing 
> rays.
> max_trace is an object attribute specific to the isosurface in exactly the 
> same way that max_gradient is. It affect how the isosurface is evaluated 
> if there are surfaces that can't be seen. Please note that ther is NO 
> "_level" here. They do LOOK similar, but are totaly different things.

Both are instructions that tell POV-Ray how many ray-surface intersections 
to follow before giving up.

I am at a loss how a sentient being can claim that they are "totally 
different things".

Post a reply to this message