Here we go again. Not much variation in these rocks, sorry, I promise to post
something more interesting soon!

In the end I gave up using the isosurface approximation macro, it was producing
far too many sharp angles and the smoothing was suffering. So I wrote a quick
and dirty mesh approximator that just shoots rays in a spherical polar grid
from the center of the object. Obviously, if the object occludes its own centre
anywhere then this won't work properly, but I'm just after a basic rocky shape
so what the hell. This saves loads of parsing time and still looks pretty good
up close; a little less craggy than previous versions maybe.

So, this image rendered in 7 hours, a bit steep but the bushes and trees in
cahoots with the antialiasing were the main culprits (that's the nice thing
about MegaPOV, you can see exactly which pixels are slowing you down). The
boulder itself renders really quick, even with radiosity. I'm really happy with
the (relatively simple) bozo pigment on the rock, it hints at surface texture
that isn't there, even really close up (thanks to partial tests without
radiosity at 3000x3000).

The triangular gaps in the plant life are deliberate; that's where the buildings
will be.

njoy
Bill

Post a reply to this message

Attachments:
Download 'rocktetra4.jpg' (150 KB)

Preview of image 'rocktetra4.jpg'

> (that's the nice thing about MegaPOV, you can see exactly which
> pixels are slowing you down).

Uhh, MegaPOV? In the official POV-Ray you can see exactly which pixels 
are slowing you down too. Search 'histogram' on the official docs.

Post a reply to this message

Looking very good, Bill.

I won't pretend that I fully understand the method used to obtain the 
surface but it seems to do a good job for a (relatively) simple surface. Do 
you mean that overhangs could occlude the center from 'higher' surfaces? I 
would understand that. Seems an interesting method. If you have time to port 
that out to the community, I (at least) would be very grateful. I can 
imagine a lot of applications.

Thomas

Post a reply to this message

Nicolas Alvarez <nic### [at] gmailisthebestcom> wrote:

> > (that's the nice thing about MegaPOV, you can see exactly which
> > pixels are slowing you down).
>
> Uhh, MegaPOV? In the official POV-Ray you can see exactly which pixels
> are slowing you down too. Search 'histogram' on the official docs.

I meant as it traces - the preview is updated almost pixel-by-pixel (I'm sure
there's a slight performance hit, but whatever)

Post a reply to this message

> Nicolas Alvarez <nic### [at] gmailisthebestcom> wrote:

>>> (that's the nice thing about MegaPOV, you can see exactly which
>>> pixels are slowing you down).
>> Uhh, MegaPOV? In the official POV-Ray you can see exactly which pixels
>> are slowing you down too. Search 'histogram' on the official docs.
> 
> I meant as it traces - the preview is updated almost pixel-by-pixel (I'm sure
> there's a slight performance hit, but whatever)

Really? :o

Well anyway... A much more accurate benchmark would be using the 
histogram and disabling preview completely :)

Post a reply to this message

"Thomas de Groot" <t.d### [at] internlDOTnet> wrote:
> I won't pretend that I fully understand the method used to obtain the
> surface but it seems to do a good job for a (relatively) simple surface. Do
> you mean that overhangs could occlude the center from 'higher' surfaces?

Overhangs would be occluded from the centre by the lower surface. That's
probably what you meant anyway! It's little more than a spherical height-field
to be honest, there may well be macros already out there to do this sort of
thing.

I should point out that the tetrahedron is not a continuous surface; it is built
from hundreds of copies of such a simple rock shape, rotated and scaled
according to position.

> If you have time to port
> that out to the community, I (at least) would be very grateful. I can
> imagine a lot of applications.

It's quite a simple bit of code. I don't have it on this computer but I'll try
post it tomorrow!

Bill

Post a reply to this message

Nicolas Alvarez <nic### [at] gmailisthebestcom> wrote:

> > I meant as it traces - the preview is updated almost pixel-by-pixel (I'm sure
> > there's a slight performance hit, but whatever)
>
> Really? :o
>
> Well anyway... A much more accurate benchmark would be using the
> histogram and disabling preview completely :)

Yeah, well, I don't care that much, it's just nice to know roughly what's
slowing things down. :) Anyway, preview is useful, I don't have to wait for a
complete render to see if something worked or not. Displaying the vista
buffer's useful too, sometimes you can see something's wrong even before the
rendering gets to the bit you're interested in...

Post a reply to this message

> It's little more than a spherical height-field to be honest, there 
> may well be macros already out there to do this sort of thing.

http://povray.org/documentation/view/3.6.1/468/#HF_Sphere

Post a reply to this message

Nicolas Alvarez <nic### [at] gmailisthebestcom> wrote:

> > It's little more than a spherical height-field to be honest, there
> > may well be macros already out there to do this sort of thing.
>
> http://povray.org/documentation/view/3.6.1/468/#HF_Sphere

Yah, there you go. My macro takes a #declared object as a parameter to be
trace()ed, so it is subtly different from the above. There are probably
scenarios where it's preferable, so I'll post it anyway. :D

Post a reply to this message

> Nicolas Alvarez <nic### [at] gmailisthebestcom> wrote:

>>> It's little more than a spherical height-field to be honest, there
>>> may well be macros already out there to do this sort of thing.
>> http://povray.org/documentation/view/3.6.1/468/#HF_Sphere
> 
> Yah, there you go. My macro takes a #declared object as a parameter to be
> trace()ed, so it is subtly different from the above. There are probably
> scenarios where it's preferable, so I'll post it anyway. :D

Well, can trace() be used inside a function, and then passed as first 
argument to HF_Sphere? :)

Post a reply to this message