Orchid XP v3 wrote:
>>     Did you try:
>> H*sin (K * pow (pow(abs(x/LX), 2/E) + pow(abs(z/LZ), 2/E), E/2) - y
>>
>>     Where:
>>  - H is the height of the waves;
>>  - K is a constant that defines the wave length;
>>  - LX and LZ are the dimensions of your stone block;
>>  - E is the same as the "Value_E" coefficient of the superellipsoid
>> object.
>>
>>         Jerome
>>
>> PS: I haven't tried it, but I think it should work...
> 
> Nice try, but... not, that doesn't work.
> 
	Actually, it does if you close the parenthesis I forgot (just
before the "-y"). See attached image...

		Jerome
-- 
+------------------------- Jerome M. BERGER ---------------------+
|    mailto:jeb### [at] freefr      | ICQ:    238062172            |
|    http://jeberger.free.fr/     | Jabber: jeb### [at] jabberfr   |
+---------------------------------+------------------------------+

Post a reply to this message

Attachments:
Download 'waves.jpg' (65 KB)

Preview of image 'waves.jpg'

news:452ff41e@news.povray.org...

> Actually, it does if you close the parenthesis I forgot (just
> before the "-y"). See attached image...


   That is a brilliant optical illusion.

    ~Steve~



>
> Jerome
> -- 
> +------------------------- Jerome M. BERGER ---------------------+
> |    mailto:jeb### [at] freefr      | ICQ:    238062172            |
> |    http://jeberger.free.fr/     | Jabber: jeb### [at] jabberfr   |
> +---------------------------------+------------------------------+
>

Post a reply to this message

Tim Nikias wrote:
>>   The height_field primitive uses optimized code which renders faster
>> than an equivalent mesh (at least in theory; I have never tested this
>> in practice).
> 
> It should? I'll have to research on that, might prove invaluable for one
> or the other render. :-)

  Note, however, that there's evidence that heightfields don't always
render correctly (perhaps precisely because of bugs in this optimized
code). "Smooth" heightfields are not always so "smooth", even though
equivalent smooth meshes are.

  Btw, another advantage of heightfields is that they, too, are
reference-counted when copied, in the same way as meshes.

Post a reply to this message

Warp wrote:
>   Note, however, that there's evidence that heightfields don't always
> render correctly (perhaps precisely because of bugs in this optimized
> code). "Smooth" heightfields are not always so "smooth", even though
> equivalent smooth meshes are.

  Actually this isn't necessarily true. Height_field uses a rather
different algorithm for calculating normal vectors than a mesh. In
some cases this produces *better* smoothing than an equivalent mesh
gives. However, in some cases it doesn't seem to work perfectly.
I just tested this.

  In the attached image the upper heightfields are made with the
height_field primitive, and the lower heighfields are meshes created
with the HF_Square macro.
  The non-smooth versions are obviously identical. The smooth versions
have a considerable difference, the height_field being better.

Post a reply to this message

Attachments:
Download 'hftest.jpg' (64 KB)

Preview of image 'hftest.jpg'

Warp wrote:
> Warp wrote:
>>   Note, however, that there's evidence that heightfields don't always
>> render correctly (perhaps precisely because of bugs in this optimized
>> code). "Smooth" heightfields are not always so "smooth", even though
>> equivalent smooth meshes are.
> 
>   Actually this isn't necessarily true. Height_field uses a rather
> different algorithm for calculating normal vectors than a mesh. In
> some cases this produces *better* smoothing than an equivalent mesh
> gives. However, in some cases it doesn't seem to work perfectly.
> I just tested this.
> 
>   In the attached image the upper heightfields are made with the
> height_field primitive, and the lower heighfields are meshes created
> with the HF_Square macro.
>   The non-smooth versions are obviously identical. The smooth versions
> have a considerable difference, the height_field being better.

Hm, interesting. How does the height_field generate the normals, do you 
know from the POV-Ray source-code? Perhaps by calculating the gradient 
from the image instead of averaging the normals?

Nontheless, as you said, sometimes the "smooth"-feature on the 
heightfield doesn't look like it's working too well. It'd be interesting 
if it might be better to pre-generate a mesh and use that instead of 
heightfields. Of course, the first time generating it would take longer, 
but if the loading of the final mesh doesn't take much longer than the 
heightfield, it might be a good trade.

Regards,
Tim

-- 
aka "Tim Nikias"
Homepage: <http://www.nolights.de>

Post a reply to this message

Orchid XP v3 <voi### [at] devnull> wrote:
> Yes, *this* is the image that took 9 hours and 45 minutes to render.

Kids these days!  <yawn>  9 hours and 45 minutes? <yawn>  Wanna hear some
war stories? <G>

(just teasing you, of course!)

Post a reply to this message