On 21/05/2011 23:15, Stephen wrote:
> Have the clocks gone back 10 years?
> Have we returned to the days where the simplest question was met by RTFM?
> 
> I thought that we had developed into a nice community not one that 

> 


I'd like to suggest that the response of some people in this group could
have been a bit nicer. Please however understand that geeks are sometimes a
little short on social graces :(

Post a reply to this message

On 21/05/2011 2:40 PM, Chris Cason wrote:
> I'd like to suggest that the response of some people in this group could
> have been a bit nicer.

And more helpful IMO.

> Please however understand that geeks are sometimes a
> little short on social graces:(

And that is an acceptable excuse?
It is like saying that we Glaswegians are renowned for mindless violence 
so don't take the stitches and broken leg personally.

An apology goes a long way. (Not directed at you cobber.)

-- 
Regards
     Stephen

Post a reply to this message

Stephen <mcavoys_at@aoldotcom> wrote:
> Have the clocks gone back 10 years?
> Have we returned to the days where the simplest question was met by RTFM?

> I thought that we had developed into a nice community not one that 
> answered a legitimate question with ???I know and I???m not going to tell you???.

> I???m very disappointed with the behaviour of some people here.

  I don't think it's fair to judge the entire community because of the
behavior of one person. People are different and have different
personalities, and sometimes personalities might clash a bit. However,
judging everybody for this is not nice.

-- 
                                                          - Warp

Post a reply to this message

On 21/05/2011 7:56 PM, Warp wrote:
>    I don't think it's fair to judge the entire community because of the
> behavior of one person. People are different and have different
> personalities, and sometimes personalities might clash a bit. However,
> judging everybody for this is not nice.

You are entirely right.
With all that implies.

-- 
Regards
     Stephen

Post a reply to this message

"Thorsten Froehlich" <nomail@nomail> wrote in message 
news:web.4dd613da955938cce619b42c0@news.povray.org...
> Actually, you misread the grammar: As there is no "|" between the
> isosurface-specific modifiers and the "[OBJECT_MODIFIERS...]", the grammar
> clearly states that putting "all_intersections" after 
> "[OBJECT_MODIFIERS...]" is
> not possible.
>
> BTW, that you find at http://www.povray.org/documentation/view/3.6.1/214/ 
> ;-)
>
>    Thorsten
>


Is this some kind of character set issue? Did you really mean to use a pipe 
symbol (vertical bar) in your quotation marks up there?

I'm staring at the page to which you posted a link there and I fail to see 
ANY mention of any relationship between a pipe symbol and the order in which 
things need to be provided. As a matter of fact the only mention of a pipe 
symbol that I see there is this pair of sentences:

> Choices are represented by a vertical bar between
> syntax items. For example a choice between three
> items would be written as ITEM1 | ITEM2 | ITEM3.

Could you please quote to me the sentence/s on that page that you linked up 
there that indicates that vertical bars have anything whatsoever to do with 
the order of things.

(Yes, I'm aware that the quick-reference has such a statement, but it also 
has a warning that the syntax convention there is different from the user 
documentation).

Post a reply to this message

"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

> "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]
ALL items between the function and here can be placed in ANY order. They 
are objects items and are often specific to the primitive used.
>>>     [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.

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

The documentations clearly state that all object modifiers must follow 
all objects items.

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

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.

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

Still because OBJECT_MODIFIERS are NOT object items.

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

Uniquely because the tutorials don't scale, rotate or translate the 
sample isosurfaces...
The isosurface tutorial concentrate only on creating the isosurface, not 
modifying them, clipping them or using them in CSG with other primitives.

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

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

Again, "object_modifiers" are not items. It thus don't follows the 
general rule of order as the items.

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

Your assumption and interpretation <> documentations that are fidel to 
the programm.
This is that way at least since version 1.

primitive_name{mendatory_items [optional_items_in_any_order] 
[OBJECT_MODIFIERS_IN_ANY_ORDER]}

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

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.

max_trace_level apply exclusively to transparency and reflections, never 
ever to any surface that can never be visible. 
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.

Then, you have clipped_by, whitch is an OBJECT MODIFIER.

ALL object modifiers always MUST follow ANY object items. This also 
apply to any pigment, texture, material, translate, scale and rotate. 
You can't translate an isosurface before you use contained_by. Also, you 
can't apply a pigment before, say, accuracy or open.



Alain

Post a reply to this message

> I'm staring at the page to which you posted a link there and I fail to see 
> ANY mention of any relationship between a pipe symbol and the order in which 
> things need to be provided.

What that documentation page fails to mention explicitely is that,
in absence of special syntax, everything is to be taken literally
and in the order specified.

For example, "sphere {<Center>, Radius}" means first write sphere,
then write curcly brace open, then write vector expression, then write
scalar expression, then write closing brace.

The reference to the pipe is that typically elements A and B
that may be present in arbitrary order could be given as:

[SOME_ITEM...]

SOME_ITEM: A | B

However, such syntax allows you to give the same item multiple
times, even if that was not the intent. It also seems that some
SDL descriptions are given in a way that imply a specific parameter
order although that is not the intent and not the implementation.
This may lead to confusion where order is important.

For non-technical users this page might benefit from an example.

Post a reply to this message

"Christian Froeschlin" <chr### [at] chrfrde> wrote in message 
news:4ddb8acc@news.povray.org...
>> I'm staring at the page to which you posted a link there and I fail to 
>> see ANY mention of any relationship between a pipe symbol and the order 
>> in which things need to be provided.
>
> What that documentation page fails to mention explicitely is that,
> in absence of special syntax, everything is to be taken literally
> and in the order specified.

"Is to be taken" - by whos opinion? Who says that this is so? The 
programmers certainly don't say so. If you disagree with this statement, 
show me where they do. Oh, you just said that the documentation "fails to 
mention" that. Bummer.

The documentation also fails to mention that chocolate is evil and should be 
outlawed. Does that mean you, I or anybody can just claim that it is somehow 
"meant" even though it "isn't mentioned explicitely"?

The various items in isosurface *can* be used in arbitrary order, as 
*demonstrated* in the tutorial; even though there is no "special syntax" 
anywhere. *Except* for those "object_modifiers" that are no more nor less 
marked with pipe-symbols or anything but somehow can only go at the very 
end. The only vertical pipe is between [max_trace ...] and 
[all_intersections] indicating an either/or choice as vertical pipes do in 
all EBNF I've ever seen.

So not only does the page "fail to mention expressly" that order is 
important, if it did mention such a thing it would be *false* because the 
behaviour of the program itself is such that order does not matter *except* 
in the case of object modifiers that have to be at the end. And where I'm 
coming from, where the documentation and the behaviour of the program 
differ, the program is right and the documentation is wrong. Fortunately it 
is NOT wrong here, because it does not actually say such a thing.

Meanwhile, this was Thorsten Froehlich's claim:
>Actually, you misread the grammar: As there is no "|" between the
>isosurface-specific modifiers and the "[OBJECT_MODIFIERS...]", the grammar
>clearly states that putting "all_intersections" after 
>"[OBJECT_MODIFIERS...]" is
>not possible.

Cool, if "the gramma clearly states" such a thing then it should be easy to 
show me *where* the grammar clearly states such. Because I somehow missed it 
and so I'm assuming it is in some area of the documentation that I didn't 
read and I assume there's more things in that section that I need to know.

His further claim was

> BTW, that you find at http://www.povray.org/documentation/view/3.6.1/214/

which unfortunately does NOT show any such information at all, so I'm going 
to assume that he *accidently* pointed me to the wrong section in the 
documentation.

Post a reply to this message

Am 24.05.2011 03:21, schrieb SGeier:

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

It's an observation that /some/ items can be specified in arbitrary 
order (and as a matter of fact happens to be true for all 
non-OBJECT_MODIFIER items). However, it was only your /assumption/ that 
it was also true for /all/ items including OBJECT_MODIFIER elements.


That said, rather than continuing this interesting nitpicking contest, 
please take a step back, rethink, and tell us what you /want/ from the 
dev team.

No, we won't improve the docs much before the 3.70 repease proper 
(unless some volunteer(s) happen to step up to actively help us with 
them - and by actively I mean more than demonstrating that you didn't 
understand them), for the simple reason that there's lack of manpower in 
that respect. Yes, the docs badly do need some improvement, but (1) 
that's not a new issue caused by the 3.6 -> 3.7 transition, and (2) it's 
not realistically achievable with just adding a bit of more patchwork 
here and there; what's really necessary is a systematic overhaul, which 
will possibly include a major rewrite and/or restructuring of many sections.

Post a reply to this message