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

"Thomas de Groot" <t.d### [at] internlDOTnet> wrote:
> 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.

Here you go. It should be quite self-explanatory. If you don't want a smooth
finish then use triangle instead of smooth_triangle.

// begin code

#macro ballpoint(vangle, rangle, rad)
  #local yp = rad*cos(vangle);
  #local locrad = rad*sin(vangle);
  #local xp = locrad*sin(rangle);
  #local zp = locrad*cos(rangle);
  (<xp, yp, zp>)
#end

#macro meshball(obj, res)
  mesh {
  #local vang = 0;
  #local ang  = 0;
  #local dvang = pi/res;
  #local dang = 2*pi/res;
  #local n1 = <0,0,0>;
  #local n2 = <0,0,0>;
  #local n3 = <0,0,0>;
  #local n4 = <0,0,0>;
  #while (vang < pi)
    #while (ang < 2*pi)
      #local v1 = trace(obj, <0,0,0>, ballpoint(vang, ang, 1), n1);
      #local v2 = trace(obj, <0,0,0>, ballpoint(vang+dvang, ang, 1), n2);
      #local v3 = trace(obj, <0,0,0>, ballpoint(vang, ang+dang, 1), n3);
      #local v4 = trace(obj, <0,0,0>, ballpoint(vang+dvang, ang+dang, 1), n4);
      smooth_triangle { v1, n1, v2, n2, v3, n3 }
      smooth_triangle { v2, n2, v3, n3, v4, n4 }
      #local ang = ang + dang;
    #end
    #local ang = 0;
    #local vang = vang + dvang;
  #end }
#end

// end code


Just call meshball(obj, res) where obj is your pre-declared object (centred on
the origin) and res is the triangle resolution (it's pretty fast with 100-200
and looks ok).

Bill

Post a reply to this message

"Bill Pragnell" <bil### [at] hotmailcom> schreef in bericht 
news:web.47c7eeeee40b9a04731f01d10@news.povray.org...
>
> Here you go. It should be quite self-explanatory. If you don't want a 
> smooth
> finish then use triangle instead of smooth_triangle.
>

Excellent! Thanks a lot Bill!

Thomas

Post a reply to this message

Bill Pragnell wrote:
> 
> 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

That kind of nice-to-know -information is also provided by official 
Windows -version of POV-Ray, while it shows the PPM (pixels per minute?) 
-value at bottom right corner.

Just a FYI :).

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

Post a reply to this message

> Bill Pragnell wrote:
>>
>> 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
> 
> That kind of nice-to-know -information is also provided by official 
> Windows -version of POV-Ray, while it shows the PPM (pixels per minute?) 
> -value at bottom right corner.

Problem is the PPM is an average over the whole rendered image, so it's 
a bit hard to tell if a certain part takes longer.

Post a reply to this message

Mmm... have you noticed that in the left lower corner there is a profile 
   of a boulder-ish face? Your works is becoming alive...
;-)
Paolo

 >Bill Pragnell wrote:
> 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

Paolo Gibellini <p.g### [at] gmailcom> wrote:
> Mmm... have you noticed that in the left lower corner there is a profile
>    of a boulder-ish face? Your works is becoming alive...

So there is! I hadn't noticed, but it is quite conspicuous. A very elongated
chin, he probably has a dastardly handle-bar moustache...

Post a reply to this message