Orchid XP v3 wrote:
>>> Well, it's 160 splash functions added together. (!)
>>
>> Well, as there is no overlapping, no internal bubbles... Why can't you 
>> use a heightfield with a high enough resolution and some "smooth" 
>> thrown in for good measure. I'd think it would look much the same for 
>> this scene. You can use functions for heightfields just as well:
>>
>> #declare HF_Detail = 100; //Simulates image-resolution of 100x100
>>   height_field{
>>     function HF_Detail,HF_Detail{ HF(x,y,z).gray }
>>     smooth
>>   }
> 
> And that does what, exactly? Makes a 100x100 polygon mesh and applies 
> some normal trickery to give the illusion of a smooth surface?

Yep, 100x100 triangle mesh and then just smooth_triangles, sorta.

> Well, you learn something every day. Just out of curiosity, how does a 
> heightfield work when used as a "solid" object? Clearly the function 
> defines the upper surface, but what about the lower one?

Everything "underneath" the heightfield is solid, everything above 
isn't. So in the cube from <0,0,0> to <1,1,1>, you divide the box into a 
lower and a top part with the heightfield.

Regards,
Tim

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

Post a reply to this message

>> PS: I haven't tried it, but I think it should work...
>
> Nice try, but... not, that doesn't work.
>
> (It makes ripples that are diagonal rather than parallel to the axies.
> And the ripples decrease in frequency rather than amplitude as they
> spread out. And there is no rounding at the corners.)
>
> I am looking into making the function simpler though - but hopefully
> without loosing its "organic" quality.

How about this:

y-10*sin(10*pow(pow(x,4)+pow(z,4),1/4)-1)/(pow(abs(x)+1,4)+pow(abs(z)+1,4))

(designed for a box{-8,8})

The middle gets a bit screwed up but you can chop that bit out for your box 
to go in.

Post a reply to this message

Attachments:
Download 'iso.jpg' (20 KB)

Preview of image 'iso.jpg'

Tim Nikias wrote:
> Yep, 100x100 triangle mesh and then just smooth_triangles, sorta.

  Actually 100x100x2 triangles.

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

Post a reply to this message

Warp wrote:
> Tim Nikias wrote:
>> Yep, 100x100 triangle mesh and then just smooth_triangles, sorta.
> 
>   Actually 100x100x2 triangles.

Eh, yeah, my bad. I was thinking about 100x100 vertices, not 100x100(x2) 
triangles.

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

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

Post a reply to this message

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