|
 |
> "clipka"<ano### [at] anonymous org> 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
|
|
