Hi, as the title states, can you use the trace command on a heightfield?

I've been trying and trying and I cant get it to work.  I've successfully 
used the trace() command on isosurfaces and simple boxes, spheres but I cant 
for the life of me get this to work.

Just wondering if this actually does work or I'm barking up the wrong tree!

Cheers Dre

Post a reply to this message

"Dre" <and### [at] gmailcom> wrote in message 
news:4bbd2f59$1@news.povray.org...
> Hi, as the title states, can you use the trace command on a heightfield?
>
> I've been trying and trying and I cant get it to work.  I've successfully 
> used the trace() command on isosurfaces and simple boxes, spheres but I 
> cant for the life of me get this to work.
>
> Just wondering if this actually does work or I'm barking up the wrong 
> tree!
>
> Cheers Dre
>

Post a reply to this message

"Dre" <and### [at] gmailcom> wrote in message 
news:4bbd2f59$1@news.povray.org...
> Hi, as the title states, can you use the trace command on a heightfield?
>
> I've been trying and trying and I cant get it to work.  I've successfully 
> used the trace() command on isosurfaces and simple boxes, spheres but I 
> cant for the life of me get this to work.
>
> Just wondering if this actually does work or I'm barking up the wrong 
> tree!
>
> Cheers Dre
>
Nevermind, I worked it out, that trace command has some weirdness about it.

This doesn't work:

#declare norm = <0, 0, 0>;
trace(object, <xPos, 10, zPos>, <xPos, -10, zPos>, norm>)

Yet this does:

#declare norm = <0, 0, 0>;
#declare startPoint =<xPos, 10, zPos>;
#declare endPoint = <xPos, -10, zPos>;
trace(object, startPoint, endPoint, norm)

Unless I'm doing something wrong, that seems broken to me...

Version 3.6 btw.

Cheers Dre

Post a reply to this message

"Dre" <and### [at] gmailcom> schreef in bericht 
news:4bbd517d$1@news.povray.org...
> "Dre" <and### [at] gmailcom> wrote in message 
> news:4bbd2f59$1@news.povray.org...
>> Hi, as the title states, can you use the trace command on a heightfield?
>>
>> I've been trying and trying and I cant get it to work.  I've successfully 
>> used the trace() command on isosurfaces and simple boxes, spheres but I 
>> cant for the life of me get this to work.
>>
>> Just wondering if this actually does work or I'm barking up the wrong 
>> tree!
>>
>> Cheers Dre
>>
> Nevermind, I worked it out, that trace command has some weirdness about 
> it.
>
> This doesn't work:
>
> #declare norm = <0, 0, 0>;
> trace(object, <xPos, 10, zPos>, <xPos, -10, zPos>, norm>)
>
> Yet this does:
>
> #declare norm = <0, 0, 0>;
> #declare startPoint =<xPos, 10, zPos>;
> #declare endPoint = <xPos, -10, zPos>;
> trace(object, startPoint, endPoint, norm)
>
> Unless I'm doing something wrong, that seems broken to me...
>


No, trace() is not broken. The following always works for me, with whatever 
object as target:
    #declare Norm =  <0, 0, 0>;
    #declare Start = <my.x, 10, my.z>;
    #declare Pos = trace (Obj, Start, -y, Norm);

Start must be above the object, so adapt the y value; -y indicates the 
direction of tracing.

Thomas

Post a reply to this message

Am 08.04.2010 05:46, schrieb Dre:

>> I've been trying and trying and I cant get it to work.  I've successfully
>> used the trace() command on isosurfaces and simple boxes, spheres but I
>> cant for the life of me get this to work.

How does the failure-to-work manifest itself? Are we talking e.g. about 
a parser error?

> This doesn't work:
>
> #declare norm =<0, 0, 0>;
> trace(object,<xPos, 10, zPos>,<xPos, -10, zPos>, norm>)
>
> Yet this does:
>
> #declare norm =<0, 0, 0>;
> #declare startPoint =<xPos, 10, zPos>;
> #declare endPoint =<xPos, -10, zPos>;
> trace(object, startPoint, endPoint, norm)
>
> Unless I'm doing something wrong, that seems broken to me...

Well, unless you introduced a typo when writing this posting, I'm not at 
all surprised: In the non-working example, you have an extra ">" after 
"norm". I'm not sure what the parser makes of this, but most likely not 
what you expected.

Post a reply to this message

Dre <and### [at] gmailcom> wrote:
> Yet this does:

> #declare norm = <0, 0, 0>;
> #declare startPoint =<xPos, 10, zPos>;
> #declare endPoint = <xPos, -10, zPos>;
> trace(object, startPoint, endPoint, norm)

  I don't think it does (well, not in the way you want). The third parameter
of trace() specifies a direction, not an endpoint.

  Probably you want the third parameter to be <0, -1, 0> because that's
the direction you are shooting the rays towards.

-- 
                                                          - Warp

Post a reply to this message

"clipka" <ano### [at] anonymousorg> wrote in message 
news:4bbd9ff6$1@news.povray.org...
> Am 08.04.2010 05:46, schrieb Dre:
>
>>> I've been trying and trying and I cant get it to work.  I've 
>>> successfully
>>> used the trace() command on isosurfaces and simple boxes, spheres but I
>>> cant for the life of me get this to work.
>
> How does the failure-to-work manifest itself? Are we talking e.g. about a 
> parser error?

No it parses correctly, however none of the intersections are correct, they 
are all either at <0, 0, 0> or some weird location.

>
>> This doesn't work:
>>
>> #declare norm =<0, 0, 0>;
>> trace(object,<xPos, 10, zPos>,<xPos, -10, zPos>, norm>)
>>
>> Yet this does:
>>
>> #declare norm =<0, 0, 0>;
>> #declare startPoint =<xPos, 10, zPos>;
>> #declare endPoint =<xPos, -10, zPos>;
>> trace(object, startPoint, endPoint, norm)
>>
>> Unless I'm doing something wrong, that seems broken to me...
>
> Well, unless you introduced a typo when writing this posting, I'm not at 
> all surprised: In the non-working example, you have an extra ">" after 
> "norm". I'm not sure what the parser makes of this, but most likely not 
> what you expected.

Ooops!  Yes that extra bracket is a typo, sorry.

I just find it weird that it accepts the same vectors as variables, but not 
as the actual vector itself...

Cheers Dre

Post a reply to this message

"Thomas de Groot" <tDOTdegroot@interDOTnlANOTHERDOTnet> wrote in message 
news:4bbd832a$1@news.povray.org...
>
> "Dre" <and### [at] gmailcom> schreef in bericht 
> news:4bbd517d$1@news.povray.org...
>> "Dre" <and### [at] gmailcom> wrote in message 
>> news:4bbd2f59$1@news.povray.org...
>>> Hi, as the title states, can you use the trace command on a heightfield?
>>>
>>> I've been trying and trying and I cant get it to work.  I've 
>>> successfully used the trace() command on isosurfaces and simple boxes, 
>>> spheres but I cant for the life of me get this to work.
>>>
>>> Just wondering if this actually does work or I'm barking up the wrong 
>>> tree!
>>>
>>> Cheers Dre
>>>
>> Nevermind, I worked it out, that trace command has some weirdness about 
>> it.
>>
>> This doesn't work:
>>
>> #declare norm = <0, 0, 0>;
>> trace(object, <xPos, 10, zPos>, <xPos, -10, zPos>, norm>)
>>
>> Yet this does:
>>
>> #declare norm = <0, 0, 0>;
>> #declare startPoint =<xPos, 10, zPos>;
>> #declare endPoint = <xPos, -10, zPos>;
>> trace(object, startPoint, endPoint, norm)
>>
>> Unless I'm doing something wrong, that seems broken to me...
>>
>
>
> No, trace() is not broken. The following always works for me, with 
> whatever object as target:
>    #declare Norm =  <0, 0, 0>;
>    #declare Start = <my.x, 10, my.z>;
>    #declare Pos = trace (Obj, Start, -y, Norm);
>
> Start must be above the object, so adapt the y value; -y indicates the 
> direction of tracing.
>
> Thomas
>

Yes that format works for me too, now try your example without the 
variables, put the actual vectors in your Pos declaration and see if you get 
the same results.  I dont.

Cheers Dre

Post a reply to this message

"Warp" <war### [at] tagpovrayorg> wrote in message 
news:4bbda1be@news.povray.org...
> Dre <and### [at] gmailcom> wrote:
>> Yet this does:
>
>> #declare norm = <0, 0, 0>;
>> #declare startPoint =<xPos, 10, zPos>;
>> #declare endPoint = <xPos, -10, zPos>;
>> trace(object, startPoint, endPoint, norm)
>
>  I don't think it does (well, not in the way you want). The third 
> parameter
> of trace() specifies a direction, not an endpoint.
>
>  Probably you want the third parameter to be <0, -1, 0> because that's
> the direction you are shooting the rays towards.
>
> -- 
>                                                          - Warp

Well it does to what I want now that I changed the way I coded it to the 
example above.  I then modified the norm as you stated but it didn't make 
any difference at all.  Both my norm and yours are below my start point so 
they are essentially shooting the rays in the same direction.

Cheers Dre

Post a reply to this message

Dre <and### [at] gmailcom> wrote:
> "Warp" <war### [at] tagpovrayorg> wrote in message 
> news:4bbda1be@news.povray.org...
> > Dre <and### [at] gmailcom> wrote:
> >> Yet this does:
> >
> >> #declare norm = <0, 0, 0>;
> >> #declare startPoint =<xPos, 10, zPos>;
> >> #declare endPoint = <xPos, -10, zPos>;
> >> trace(object, startPoint, endPoint, norm)
> >
> >  I don't think it does (well, not in the way you want). The third 
> > parameter
> > of trace() specifies a direction, not an endpoint.
> >
> >  Probably you want the third parameter to be <0, -1, 0> because that's
> > the direction you are shooting the rays towards.
> >
> > -- 
> >                                                          - Warp

> Well it does to what I want now that I changed the way I coded it to the 
> example above.  I then modified the norm as you stated but it didn't make 
> any difference at all.  Both my norm and yours are below my start point so 
> they are essentially shooting the rays in the same direction.

  The normal is the *fourth* parameter. I was talking about the *third*
parameter, which is the direction. That should be <0, -1, 0>.

-- 
                                                          - Warp

Post a reply to this message

Dre <and### [at] gmailcom> wrote:
> No it parses correctly, however none of the intersections are correct, they 
> are all either at <0, 0, 0> or some weird location.

  Because you are not shooting the rays towards <0, -1, 0>.

-- 
                                                          - Warp

Post a reply to this message

Warp <war### [at] tagpovrayorg> wrote:
> Dre <and### [at] gmailcom> wrote:
> > Yet this does:
>
> > #declare norm = <0, 0, 0>;
> > #declare startPoint =<xPos, 10, zPos>;
> > #declare endPoint = <xPos, -10, zPos>;
> > trace(object, startPoint, endPoint, norm)
>
>   I don't think it does (well, not in the way you want). The third parameter
> of trace() specifies a direction, not an endpoint.
>
>   Probably you want the third parameter to be <0, -1, 0> because that's
> the direction you are shooting the rays towards.
>

Warp's correct. (Also, I would assume that <0,-10,0> has the same directional
effect as <0,-1,0> )

There's a big difference between <xpos,-10,zPos> and <0,-10,0> as a *direction*
vector. Let's say xPos=7 and zPos=5.  That produces a *direction* of
<7,-10,5>--which certainly isn't straight down. The trace rays are probably not
even hitting the HF (and your placed object(s) are ending up at a <0,0,0>
location by default, unless you're using Norm to 'stop' that in some way, which
I assume you are.)

As has been mentioned:
* The trace ray 'start' location needs to be somewhere *above* the
HF...obviously  ;-)  Personally, I would use <xPos,1000,zPos> to be safe.
* the 'start' vector is an actual location point; the trace ray direction is a
*directional* vector, NOT the location of a point, and shouldn't normally
change--at least when tracing a HF.

Ken

Post a reply to this message

"Kenneth" <kdw### [at] earthlinknet> schreef in bericht 
news:web.4bbf648570f2d07d65f302820@news.povray.org...
> As has been mentioned:
> * The trace ray 'start' location needs to be somewhere *above* the
> HF...obviously  ;-)  Personally, I would use <xPos,1000,zPos> to be safe.
> * the 'start' vector is an actual location point; the trace ray direction 
> is a
> *directional* vector, NOT the location of a point, and shouldn't normally
> change--at least when tracing a HF.
>

Yes, and when you want to trace, say, a spherical object, like a planet, the 
following macro by Tim Attwood comes in handy:

//start code
//--- Tim Attwood's random distribution macro ---
#macro RandOnSurface(Obj, rsd, thresh)
   #local mn = min_extent(Obj)-thresh;
   #local mx = max_extent(Obj)+thresh;
   #local dist = 1000000;
   #while (dist>thresh)
      #local flag = 0;
      #while (flag = 0)
         #local rfrom = VRand_In_Box(mn, mx, rsd);
         #local rdir = vrotate(<1,1,1>,
            <360*rand(rsd),360*rand(rsd),360*rand(rsd)>);
         #declare Norm = <0, 0, 0>;
         #local hit = trace(Obj, rfrom, rdir, Norm);
         #if (vlength(Norm) != 0)
            #local flag = 1;
         #end
      #end
      #local dist = vlength( hit - rfrom);
   #end
   #local result = hit;
   (result)
#end
//end code

Thomas

Post a reply to this message

"Warp" <war### [at] tagpovrayorg> wrote in message 
news:4bbebfde@news.povray.org...
> Dre <and### [at] gmailcom> wrote:
>> No it parses correctly, however none of the intersections are correct, 
>> they
>> are all either at <0, 0, 0> or some weird location.
>
>  Because you are not shooting the rays towards <0, -1, 0>.
>
> -- 
>                                                          - Warp

I believe I am shooting them in that direction, they are starting at <x, 10, 
z> and finishing at <x, -10, y>, thats towards <0, -1, 0> in my mind or am I 
wrong here?

Cheers Dre

Post a reply to this message

"Warp" <war### [at] tagpovrayorg> wrote in message 
news:4bbebfaf@news.povray.org...
> Dre <and### [at] gmailcom> wrote:
>> "Warp" <war### [at] tagpovrayorg> wrote in message
>> news:4bbda1be@news.povray.org...
>> > Dre <and### [at] gmailcom> wrote:
>> >> Yet this does:
>> >
>> >> #declare norm = <0, 0, 0>;
>> >> #declare startPoint =<xPos, 10, zPos>;
>> >> #declare endPoint = <xPos, -10, zPos>;
>> >> trace(object, startPoint, endPoint, norm)
>> >
>> >  I don't think it does (well, not in the way you want). The third
>> > parameter
>> > of trace() specifies a direction, not an endpoint.
>> >
>> >  Probably you want the third parameter to be <0, -1, 0> because that's
>> > the direction you are shooting the rays towards.
>> >
>> > -- 
>> >                                                          - Warp
>
>> Well it does to what I want now that I changed the way I coded it to the
>> example above.  I then modified the norm as you stated but it didn't make
>> any difference at all.  Both my norm and yours are below my start point 
>> so
>> they are essentially shooting the rays in the same direction.
>
>  The normal is the *fourth* parameter. I was talking about the *third*
> parameter, which is the direction. That should be <0, -1, 0>.
>
> -- 
>                                                          - Warp

What difference does it make if its -1 or -10, they are both in the same 
plane.

Or are you saying the 3rd parameters is a direction vector not a final end 
point vector?

Cheers Dre

Post a reply to this message

"Kenneth" <kdw### [at] earthlinknet> wrote in message 
news:web.4bbf648570f2d07d65f302820@news.povray.org...
> Warp <war### [at] tagpovrayorg> wrote:
>> Dre <and### [at] gmailcom> wrote:
>> > Yet this does:
>>
>> > #declare norm = <0, 0, 0>;
>> > #declare startPoint =<xPos, 10, zPos>;
>> > #declare endPoint = <xPos, -10, zPos>;
>> > trace(object, startPoint, endPoint, norm)
>>
>>   I don't think it does (well, not in the way you want). The third 
>> parameter
>> of trace() specifies a direction, not an endpoint.
>>
>>   Probably you want the third parameter to be <0, -1, 0> because that's
>> the direction you are shooting the rays towards.
>>
>
> Warp's correct. (Also, I would assume that <0,-10,0> has the same 
> directional
> effect as <0,-1,0> )
>
> There's a big difference between <xpos,-10,zPos> and <0,-10,0> as a 
> *direction*
> vector. Let's say xPos=7 and zPos=5.  That produces a *direction* of
> <7,-10,5>--which certainly isn't straight down. The trace rays are 
> probably not
> even hitting the HF (and your placed object(s) are ending up at a <0,0,0>
> location by default, unless you're using Norm to 'stop' that in some way, 
> which
> I assume you are.)
>
> As has been mentioned:
> * The trace ray 'start' location needs to be somewhere *above* the
> HF...obviously  ;-)  Personally, I would use <xPos,1000,zPos> to be safe.
> * the 'start' vector is an actual location point; the trace ray direction 
> is a
> *directional* vector, NOT the location of a point, and shouldn't normally
> change--at least when tracing a HF.
>
> Ken
>
Thanks very much for the clarification.  That clears things up completely :)

I was getting the third parameter wrong, I thought it was an end point 
rather than a direction vector, I mentioned this in my reply to warp.

So much POV to learn, so little time!

Cheers Dre

Post a reply to this message

"Dre" <and### [at] gmailcom> wrote:

> So much POV to learn, so little time!

Not a day goes by that I don't learn something new as well, some new trick that
POV-Ray is capable of, or some new 'understanding.' The best way to learn
is...practice, practice, practice.  ;-) And to read these newsgroups, of
course--they are a real fountain of knowledge.

I remember the trace command being difficult to fully understand as well, when I
first tried to use it. (In fact, a newsgroup query may have helped *me* at the
time.) And that Norm thing had me guessing too--until I finally
realized that the value (the vector) that's placed there--with #declare norm =
<0,0,0> --is just to set it up, as a kind of 'place-holder.' (In fact, the
vector can contain *any* three values.) Then, when trace() is used or called, it
RETURNS an *actual* vector (a directional vector again!) found at the traced
point, and loads it into 'norm', replacing the temporary values--which can then
be used elsewhere in the scene. The documentation describes some of this, but in
a roundabout way, not completely clear. (Which is unfortunate, because trace is
an *extremely* valuable and fun tool!) So don't feel bad about your temporary
lack of understanding.

Ken

Post a reply to this message

Dre <and### [at] gmailcom> wrote:
> "Warp" <war### [at] tagpovrayorg> wrote in message 
> news:4bbebfde@news.povray.org...
> > Dre <and### [at] gmailcom> wrote:
> >> No it parses correctly, however none of the intersections are correct, 
> >> they
> >> are all either at <0, 0, 0> or some weird location.
> >
> >  Because you are not shooting the rays towards <0, -1, 0>.
> >
> > -- 
> >                                                          - Warp

> I believe I am shooting them in that direction, they are starting at <x, 10, 
> z> and finishing at <x, -10, y>, thats towards <0, -1, 0> in my mind or am I 
> wrong here?

  You are shooting them towards <x, -10, y>, not towards <0, -1, 0> because
that's what you are telling trace() to do.

  You have to do it like this:

trace(TheObject, <X, 10, Z>, <0, -1, 0>, TheNormal)

-- 
                                                          - Warp

Post a reply to this message

Dre <and### [at] gmailcom> wrote:
> >  The normal is the *fourth* parameter. I was talking about the *third*
> > parameter, which is the direction. That should be <0, -1, 0>.
> >
> > -- 
> >                                                          - Warp

> What difference does it make if its -1 or -10, they are both in the same 
> plane.

  <X, -10, Z> is not the same thing as <0, -10, 0>.

> Or are you saying the 3rd parameters is a direction vector not a final end 
> point vector?

  It's a direction vector.

-- 
                                                          - Warp

Post a reply to this message

Le 2010-04-11 20:19, Dre a écrit :
> "Warp"<war### [at] tagpovrayorg>  wrote in message
> news:4bbebfde@news.povray.org...
>> Dre<and### [at] gmailcom>  wrote:
>>> No it parses correctly, however none of the intersections are correct,
>>> they
>>> are all either at<0, 0, 0>  or some weird location.
>>
>>   Because you are not shooting the rays towards<0, -1, 0>.
>>
>> --
>>                                                           - Warp
>
> I believe I am shooting them in that direction, they are starting at<x, 10,
> z>  and finishing at<x, -10, y>, thats towards<0, -1, 0>  in my mind or am I
> wrong here?
>
> Cheers Dre
>
>

You are wrong :(

If you start at <x,10,z> and have a direction of <x,-10,z>, then, you 
shoot toward <x*2,0, z*2>.
Remember, the first value is the starting location.

The second value is a *direction* vector, it is ADDED to the start 
location. If you use a /location/ your tracing rays will fan out.

The result is that most rays, about 75% if the hight_field is around the 
X-Z plane, will totaly miss the hight_field. Any ray that don't hit the 
target will return a location of <0,0,0> and a normal of <0,0,0>.
If the hight_field is a around -10*y, then only 1/16 trace will hit it, 
at the wrong locations.



Alain

Post a reply to this message

"Kenneth" <kdw### [at] earthlinknet> wrote in message 
news:web.4bc2e33970f2d07d65f302820@news.povray.org...
> "Dre" <and### [at] gmailcom> wrote:
>
>> So much POV to learn, so little time!
>
> Not a day goes by that I don't learn something new as well, some new trick 
> that
> POV-Ray is capable of, or some new 'understanding.' The best way to learn
> is...practice, practice, practice.  ;-) And to read these newsgroups, of
> course--they are a real fountain of knowledge.
>
> I remember the trace command being difficult to fully understand as well, 
> when I
> first tried to use it. (In fact, a newsgroup query may have helped *me* at 
> the
> time.) And that Norm thing had me guessing too--until I finally
> realized that the value (the vector) that's placed there--with #declare 
> norm =
> <0,0,0> --is just to set it up, as a kind of 'place-holder.' (In fact, the
> vector can contain *any* three values.) Then, when trace() is used or 
> called, it
> RETURNS an *actual* vector (a directional vector again!) found at the 
> traced
> point, and loads it into 'norm', replacing the temporary values--which can 
> then
> be used elsewhere in the scene. The documentation describes some of this, 
> but in
> a roundabout way, not completely clear. (Which is unfortunate, because 
> trace is
> an *extremely* valuable and fun tool!) So don't feel bad about your 
> temporary
> lack of understanding.
>
> Ken
>
I totally agree.  There is something very satisfying when you see your scene 
finally trace correctly after working out some new process/technique.

Without these groups I would be stuck a long time ago, not to mention the 
absolutely amazing pictures you see in p.bi.

Cheers Dre

Post a reply to this message

"Warp" <war### [at] tagpovrayorg> wrote in message 
news:4bc308a1@news.povray.org...
> Dre <and### [at] gmailcom> wrote:
>> >  The normal is the *fourth* parameter. I was talking about the *third*
>> > parameter, which is the direction. That should be <0, -1, 0>.
>> >
>> > -- 
>> >                                                          - Warp
>
>> What difference does it make if its -1 or -10, they are both in the same
>> plane.
>
>  <X, -10, Z> is not the same thing as <0, -10, 0>.
>
>> Or are you saying the 3rd parameters is a direction vector not a final 
>> end
>> point vector?
>
>  It's a direction vector.
>
> -- 
>                                                          - Warp

Yep, that was where I was going wrong.

Thanks for your help!

Cheers Dre

Post a reply to this message

"Alain" <aze### [at] qwertyorg> wrote in message 
news:4bc31c84$1@news.povray.org...
> Le 2010-04-11 20:19, Dre a écrit :
>> "Warp"<war### [at] tagpovrayorg>  wrote in message
>> news:4bbebfde@news.povray.org...
>>> Dre<and### [at] gmailcom>  wrote:
>>>> No it parses correctly, however none of the intersections are correct,
>>>> they
>>>> are all either at<0, 0, 0>  or some weird location.
>>>
>>>   Because you are not shooting the rays towards<0, -1, 0>.
>>>
>>> --
>>>                                                           - Warp
>>
>> I believe I am shooting them in that direction, they are starting at<x, 
>> 10,
>> z>  and finishing at<x, -10, y>, thats towards<0, -1, 0>  in my mind or 
>> am I
>> wrong here?
>>
>> Cheers Dre
>>
>>
>
> You are wrong :(
>
> If you start at <x,10,z> and have a direction of <x,-10,z>, then, you 
> shoot toward <x*2,0, z*2>.
> Remember, the first value is the starting location.
>
> The second value is a *direction* vector, it is ADDED to the start 
> location. If you use a /location/ your tracing rays will fan out.
>
> The result is that most rays, about 75% if the hight_field is around the 
> X-Z plane, will totaly miss the hight_field. Any ray that don't hit the 
> target will return a location of <0,0,0> and a normal of <0,0,0>.
> If the hight_field is a around -10*y, then only 1/16 trace will hit it, at 
> the wrong locations.
>
>
>
> Alain

Yep, the thing that was messing me up was the fact that I thought the second 
value was the final end point not a direction vector.

All sorted now though, thanks for your help!

Cheers Dre

Post a reply to this message