Kenneth nous illumina en ce 2008-06-07 13:07 -->
> "Chris B" <nom### [at] nomailcom> wrote:
>> "daviddoria" <nomail@nomail> wrote in message
>> news:web.4849a25ff5d589ac145cec320@news.povray.org...
> 
>> #declare MyStart = <1, 1, 1>;
>> #declare MyDirection =  <0, 0, 0> - MyStart;
> 
> The resulting MyDirection vector in this case would be <-1,-1,-1>...kind of an
> odd direction in which to shoot a trace ray, *assuming* that the mesh occupies
> some area on an x/z plane...i.e., horizontal. Far better would be to shoot the
> trace ray straight 'down.'
> 
> Let's assume that the mesh extends from <0,0,0> to <1,0,1>--like a POV-Ray
> height_field. Would it not be better to say
> #declare MyStart =
> <*some value between 0 and 1*,100,*some value between 0 and 1*>; // y is just an
> // arbitrary large number, to place it well above the mesh
> 
> #declare MyDirection = <0,-1,0>; // pointing straight down
> 
> OR
> #declare MyDirection = <0,0,0> - <0, MyStart.y,0>; // using dot notation to pick
> // one value out of a vector
> 
> OR
> #declare MyDirection = <0, -MyStart.y,0>;
> 
> These three MyDirection's all all equivalent...but <0,-1,0> is far easier to
> write!
> 
> Ken W.
> 
> 
> 
> 
The proposed solution allows you to shoot the ray from some arbitrary location 
toward an object centered around the origin. There is nothing in the original 
post that even remotely suggest that the mesh may be planar.
In fact, Dave question explicitly ask fro a trace from some arbitrary location 
directed at the mesh, without any information about it's location.

If the mesh is NOT around the origin, you can use max_extend(Object) and 
min_extent(object) to get the location of it's bounding box. You can then shoot 
your tracing ray at that bounding box.

-- 
Alain
-------------------------------------------------
Either write something worth reading or do something worth writing.
Benjamin Franklin

Post a reply to this message

Alain <ele### [at] netscapenet> wrote:

>
> The proposed solution allows you to shoot the ray from some arbitrary location
> toward an object centered around the origin.

That's true--but the example given in the docs does not make that clear or
explain what's going on; a new user would, IMO, have to "read between the
lines" to understand that the example *is* shooting toward the origin.

> There is nothing in the original
> post that even remotely suggest that the mesh may be planar.

Well, he doesn't say where it is, how big it is OR what shape it is (*all* of
which have a bearing on how to trace it--and how successful the trace will be,
especially if there are undercuts in the mesh object.)  But I admit that when I
think of a 'mesh', I think of an open 'planar'-like object, like a height_field.
That was a bad assumption on my part. Meshes can be any shape, open or closed.

> If the mesh is NOT around the origin, you can use max_extend(Object) and
> min_extent(object) to get the location of it's bounding box. You can then shoot
> your tracing ray at that bounding box.

That's a good idea, I agree. And should probably be mentioned as part of the
trace definition in the docs, if only briefly. (I don't believe a new user
would think of that, yet it's a useful and easy trick.)

KW

Post a reply to this message

"Kenneth" <kdw### [at] earthlinknet> wrote in message 
news:web.484b4a43784caf0d78dcad930@news.povray.org...
> "Chris B" <nom### [at] nomailcom> wrote:
>
> I do feel sorry for new users trying to make sense of the trace operation, 
> given
> the short and somewhat perfunctory explanation of it. It's such a powerful
> feature of POV-Ray! But some of the documentation just isn't as clear as 
> it
> should be.

I do remember the trace function being quite difficult to get my head around 
when I first used it, but now, when I look at the help entry it seems fairly 
straight forward. I don't know whether the help entry has been updated over 
the years or whether it's just that the answer makes sense when you already 
know it.

Maybe this is a prime example of where the wiki at http://wiki.povray.org/ 
could be used to collaboratively develop a clear and succinct 'how-to' 
explanation suitable for newer users.

> ... Another item of
> confusion: Somewhere above the trace explanation, it says, "The following 
> are
> the functions which return vector values."  The important word being 
> RETURN.
> But there are other functions following trace that actually DON'T return 
> any
> value (vnormalize being one.) Pity the poor new user trying to understand 
> all
> of this!

The vnormalize function does return a value, which is a unit length vector 
of the vector you pass it as a parameter. The returned value can be assigned 
to a variable using the #declare or #local statement or can be used inline 
in your SDL. The trace function is one of a small number of functions that 
requires a vector identifier as a parameter so that the function can update 
it, thereby effectively returning two values.

Regards,
Chris B.

Post a reply to this message

"Chris B" <nom### [at] nomailcom> wrote:

>
> I do remember the trace function being quite difficult to get my head around
> when I first used it, but now, when I look at the help entry it seems fairly
> straight forward. I don't know whether the help entry has been updated over
> the years or whether it's just that the answer makes sense when you already
> know it.
>

heh, heh, I think it's the latter. It's funny how *experience* with POV-Ray
makes seemingly obtuse descriptions completely understandable...with the vital
help of the great contributors to these newsgroups!

>
> The vnormalize function does return a value, which is a unit length vector
> of the vector you pass it as a parameter. The returned value can be assigned
> to a variable using the #declare or #local statement or can be used inline
> in your SDL. The trace function is one of a small number of functions that
> requires a vector identifier as a parameter so that the function can update
> it, thereby effectively returning two values.
>

That's a clear description of the difference; better than mine by far. I should
have said that vnormalize (and *most* other functions) don't *need* to be pre-
#declared in order to be used, wheras trace and a few others do. Alas, the
current documentation makes a mish-mash of that.

Ken W.

Post a reply to this message