  | 
  | 
 | 
  | 
 | 
  | 
 |   | 
 |   | 
 | 
  | 
 | 
  | 
 |   | 
 |   | 
 | 
  | 
Can anyone help me translate MegaPov's height_of to the new Pov? Thank you.
 
 Post a reply to this message 
 | 
  | 
 |   | 
 |   | 
 | 
  | 
From: Christoph Hormann 
Subject: Re: MegaPov height_of to Pov 3.5 
Date:  5 Aug 2002 03:51:15 
Message: <3D4E2E73.7BEF94D@gmx.de> 
 | 
 
 
 | 
  | 
 |   | 
 |   | 
 | 
  | 
Glenn Greenway wrote:
> 
> Can anyone help me translate MegaPov's height_of to the new Pov? Thank you.
You mean 'hf_height_at()'?
Just use 'trace()' instead.
Christoph
-- 
POV-Ray tutorials, IsoWood include,                 
TransSkin and more: http://www.tu-bs.de/~y0013390/  
Last updated 03 Aug. 2002 _____./\/^>_*_<^\/\.______
 
 Post a reply to this message 
 | 
  | 
 |   | 
 |   | 
 | 
  | 
 | 
  | 
 |   | 
 |   | 
 | 
  | 
In article <B973A1CB.4BDC%gle### [at] isrv com>,
 Glenn Greenway <gle### [at] isrv com> wrote:
> Can anyone help me translate MegaPov's height_of to the new Pov? Thank you.
If you are talking about the hf_height_at() function, adding it to POV 
3.5 would be a waste of time, since trace() is already there and is a 
much better solution. Just trace from a point above the height field 
directly down. It is much more flexible, and works for any shape.
-- 
Christopher James Huff <chr### [at] mac com>
POV-Ray TAG e-mail: chr### [at] tag povray org
TAG web site: http://tag.povray.org/
 
 Post a reply to this message 
 | 
  | 
 |   | 
 |   | 
 | 
  | 
 | 
  | 
 |   | 
 |   | 
 | 
  | 
in article chr### [at] netplex aussie org, Christopher
James Huff at chr### [at] mac com wrote on 8/5/02 12:08 PM:
> In article <B973A1CB.4BDC%gle### [at] isrv com>,
> Glenn Greenway <gle### [at] isrv com> wrote:
> 
>> Can anyone help me translate MegaPov's height_of to the new Pov? Thank you.
> 
> If you are talking about the hf_height_at() function, adding it to POV
> 3.5 would be a waste of time, since trace() is already there and is a
> much better solution. Just trace from a point above the height field
> directly down. It is much more flexible, and works for any shape.
Thank you for your comments.  However, I would like to evaluate a height
field at parse time, not render time.  I've been trying to use bitmap data
to add a deformation map feature to a mesh creation macro i've been working
on. I thought that the 3.5 function feature might be the way to go.  But i
can't figger it.  With MegaPov hf_height_at() i could loop through and
evaluate values at each point before rendering.  Thanks again.
 
 Post a reply to this message 
 | 
  | 
 |   | 
 |   | 
 | 
  | 
 | 
  | 
 |   | 
 |   | 
 | 
  | 
"Glenn Greenway" wrote:
> With MegaPov hf_height_at() i could loop through and
> evaluate values at each point before rendering.
You can still do that with trace().
 
 Post a reply to this message 
 | 
  | 
 |   | 
 |   | 
 | 
  | 
 | 
  | 
 |   | 
 |   | 
 | 
  | 
In article <B9744727.4BFF%gle### [at] isrv com>,
 Glenn Greenway <gle### [at] isrv com> wrote:
> Thank you for your comments.  However, I would like to evaluate a height
> field at parse time, not render time. 
The trace() function is a scene description language feature that 
operates at parse time, not render time.
> I've been trying to use bitmap data to add a deformation map feature 
> to a mesh creation macro i've been working on. I thought that the 3.5 
> function feature might be the way to go.  But i can't figger it.  
> With MegaPov hf_height_at() i could loop through and evaluate values 
> at each point before rendering.  Thanks again. 
You could do the exact same thing with the trace() function, see the 
manual. However, it sounds like functions are a better solution. You 
might want to look at the height field macros in shapes.inc for examples.
-- 
Christopher James Huff <chr### [at] mac com>
POV-Ray TAG e-mail: chr### [at] tag povray org
TAG web site: http://tag.povray.org/
 
 Post a reply to this message 
 | 
  | 
 |   | 
 |   | 
 | 
  | 
 | 
  | 
 |   |