Yes, *this* is the image that took 9 hours and 45 minutes to render. Not 
the other one I posted (which took a long old while, but less than 1 hour).

Why did it take so long? The answer is the water; it's an isosurface. It 
has a max_gradient of 1.07, but the function that describes it is 
extremely complicated and thus takes one hell of a long time to 
evaluate. What *is* this function, exactly?

Well, it's 160 splash functions added together. (!)

Each "splash function" is actually just some concentric rings of sine 
waves, decaying exponentially as you move away from the center. Each of 
the 160 splash functions has a different center point; the center points 
trace the outline of the stone block. In this way, the waves appear to 
follow the outline of the stone block, the way *real* water would move.

Of course, this only works if you have enough splashes; otherwise you 
just get more or less random-looking interference patterns. (It appears 
the number of splashes on each edge must be approximately the same as 
the frequency of the waves - which would make sense I guess! Thus, the 
smaller the ripples are, the more functions you must have.)

Go on, admit it... it *does* look kinda cool. ;-)

Post a reply to this message

Attachments:
Download 'glassware05-wave40.jpg' (123 KB)

Preview of image 'glassware05-wave40.jpg'

Orchid XP v3 wrote:
> Yes, *this* is the image that took 9 hours and 45 minutes to render. Not 
> the other one I posted (which took a long old while, but less than 1 hour).
> 
> Why did it take so long? The answer is the water; it's an isosurface. It 
> has a max_gradient of 1.07, but the function that describes it is 
> extremely complicated and thus takes one hell of a long time to 
> evaluate. What *is* this function, exactly?
> 
> 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
   }


Regards,
Tim

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

Post a reply to this message

>> 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?

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?

Post a reply to this message

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Orchid XP v3 wrote:
> Of course, this only works if you have enough splashes; otherwise you
> just get more or less random-looking interference patterns. (It appears
> the number of splashes on each edge must be approximately the same as
> the frequency of the waves - which would make sense I guess! Thus, the
> smaller the ripples are, the more functions you must have.)
> 
	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...

- --
+------------------------- Jerome M. BERGER ---------------------+
|    mailto:jeb### [at] freefr      | ICQ:    238062172            |
|    http://jeberger.free.fr/     | Jabber: jeb### [at] jabberfr   |
+---------------------------------+------------------------------+
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.2.2 (GNU/Linux)

iD8DBQFFLqWCd0kWM4JG3k8RAivVAJwLkUGqMNYoFeaJZc97jm3FmYRKBgCggCUk
KQiAFZRIXX5QIUFS/fNCXhU=
=+vnb
-----END PGP SIGNATURE-----

Post a reply to this message

Orchid XP v3 wrote:
> 
> Go on, admit it... it *does* look kinda cool. ;-)
> 

Yep. Even Arthur's towel is there ;).

-- 
Eero "Aero" Ahonen
   http://www.zbxt.net
      aer### [at] removethiszbxtnetinvalid

Post a reply to this message

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

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

Post a reply to this message

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