 |
|
|
|
|
|
| |
| |
|
|
|
|
| |
| |
|
|
daviddoria <nomail@nomail> wrote:
> It sounds like using POV ray for this may be overkill?
Why would it be overkill? It sounds to me like the easiest way by far.
--
- Warp
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
On Fri, 6 Jun 2008 22:00:59 EDT, "daviddoria" <nomail@nomail> wrote:
>Thanks for the quick responses! It sounds like using POV ray for this may be
>overkill? Is there an easier approach that someone can recommend? It seems like
>it should be possible to shoot rays at a model without converting it to a POV
>ray scene (of course not with POV ray though haha!).
This newsgroup tends to be inhabited by PovRay fanatics so you might
not get a suitable reply. For us using PovRay is goal in its own
right. :)
>If not, is there some linux equivalent of pose ray?
>
I believe that you can run PoseRay under Wine.
--
Regards
Stephen
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
"daviddoria" <nomail@nomail> wrote in message
news:web.4849ebdb784caf0d145cec320@news.povray.org...
> Thanks for the quick responses! It sounds like using POV ray for this may
> be
> overkill? Is there an easier approach that someone can recommend? It seems
> like
> it should be possible to shoot rays at a model without converting it to a
> POV
> ray scene (of course not with POV ray though haha!).
>
Whether there's an easier approach depends largely on where you're starting
from and where you're going with this.
If you're developing an application that reads the obj file you may find it
easiest to use the application code examples outlined at the following URL:
http://www.codeproject.com/KB/graphics/Simple_Ray_Tracing_in_C_2.aspx?display=Print
If you're using a particular modeller to generate or process the obj file,
then that modeller may provide something that can perform that sort of
calculation for you. Various modellers now support their own form of
scripting.
If you're a dab hand at Perl scripting then you might find it easiest to
read the vertices of the triangles directly from the obj file (it's just a
plain ASCII file) and calculate the intersection point triangle by triangle.
If the line intercepts multiple triangles you just keep track of the one
closest to your start point.
> If not, is there some linux equivalent of pose ray?
According to the announcement at
http://news.povray.org/povray.news-submissions/thread/%3C451a0953@news.povray.org%3E/?ttop=274065&toff=50
you can run PoseRay on Linux using Wine 0.9.21.
Regards,
Chris B.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
"Chris B" <nom### [at] nomail com> 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.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
"Kenneth" <kdw### [at] earthlinknet> wrote in message
news:web.484abf7e784caf0d78dcad930@news.povray.org...
> "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.
>
Yes probably. I just adapted the example from the help. I assumed from his
question that Dave would know the particular point that he wanted to shoot
the ray from and the direction he wanted to shoot it in.
Regards,
Chris B.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
"Chris B" <nom### [at] nomailcom> wrote:
>
> Yes probably. I just adapted the example from the help. I assumed from his
> question that Dave would know the particular point that he wanted to shoot
> the ray from and the direction he wanted to shoot it in.
>
Ah yes, I see what you mean. It does make sense, when tracing a sphere.
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.
For example, although the docs state--in a roundabout way--that the
optional 4th parameter (the found 'normal' at the object's surface) has to have
it's vector pre-#declared before it can be used in the trace operation, and
gives <0,0,0> as an example, in fact it can be any arbitrary vector
value...like <26,-38,1.0046>. It's only a 'place-holder' which will be filled
with REAL values as soon as trace shoots a ray at the object surface. SO...
trace can actually return TWO values, the intersection point and the normal at
that point...both vectors, and both requiring a #declare. 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!
Speaking of vnormalize: The 'normal' vector found at the surface during a trace
is automatically 'normalized' to be one unit in length. This is how the trace
example uses it to make a cylinder sticking out from the surface of the sphere.
Ken W.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
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
|
|
| |
| |
|
|
|
|
| |
|
|
