I have a mesh (list of vertices - .obj type of file) that i would like to shoot
a ray at from a particular point and see if it hits the mesh, and if it does,
get the coordinates of the intersection.  Is this possible to do with pov ray?
Can someone point me to an example that does something like this? Does pov ray
have its own scripting language or will I have to dig through the source code
to do this task?

Thanks,

Dave

Post a reply to this message

On Fri,  6 Jun 2008 16:47:27 EDT, "daviddoria" <nomail@nomail> wrote:

>I have a mesh (list of vertices - .obj type of file) that i would like to shoot
>a ray at from a particular point and see if it hits the mesh, and if it does,
>get the coordinates of the intersection.  Is this possible to do with pov ray?
>Can someone point me to an example that does something like this? Does pov ray
>have its own scripting language or will I have to dig through the source code
>to do this task?
>
Welcome Dave,
	What you want to do is possible. Look in the documentation for
trace, but be warned (gently) that this is an advanced feature. I am
sure someone better versed in Pov-Ray SDL can answer you better. 
As for a scripting language you are in luck, Pov-Ray's scripting
language is called SDL, see the document section 3.2  Scene
Description Language and have a look at the tutorial 2.3.10  SDL
tutorial: A raytracer.
Are you using a modeller to create your scene? And if so it is a very
good idea to stop for a moment to become familiar with SDL.
-- 

Regards
     Stephen

Post a reply to this message

"daviddoria" <nomail@nomail> wrote in message 
news:web.4849a25ff5d589ac145cec320@news.povray.org...
>I have a mesh (list of vertices - .obj type of file) that i would like to 
>shoot
> a ray at from a particular point and see if it hits the mesh, and if it 
> does,
> get the coordinates of the intersection.  Is this possible to do with pov 
> ray?
> Can someone point me to an example that does something like this? Does pov 
> ray
> have its own scripting language or will I have to dig through the source 
> code
> to do this task?
>
> Thanks,
>
> Dave
>

You'd need to convert it into a POV-Ray mesh which can be done using 
PoseRay.
You can then wrap the mesh definition in an object declaration using 
#declare to give it a name, then you can pass this into the 'trace' function 
along with the start point and a direction vector for the line you want to 
trace. This will return the coordinates of the point of intersection.

You should also pass the optional last parameter in which will be set to the 
normal at the point of intersection. You can then test the value and if it 
has a zero length, the ray didn't hit the object.

Your SDL would look something like this, assuming that the file 
'YourMeshFile.inc' contains the mesh definition generated using PoseRay and 
wrapped in a  #declare statement to give it the name 'MyMesh':

#include "YourMeshFile.inc"
#declare MyNormal = <0,0,0>;
#declare MyStart = <1, 1, 1>;
#declare MyDirection =  <0, 0, 0> - MyStart;
#declare MyIntersection =   trace ( MyMesh, MyStart, MyDirection, MyNormal);
#if (vlength(MyNormal)=0)
  ...  // What to do if the ray missed the object
#else
  ... // What to do if the ray hit the object
#end

Of course you then need to decide what you're going to do with the 
information. e.g. write the coordinates out to the debug stream or to a 
file, or display a scene with a sphere at the point of intersection.

Regards,
Chris B

Post a reply to this message

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

If not, is there some linux equivalent of pose ray?

Thanks,

Dave

Post a reply to this message

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

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