Getting nowhere veeery slooowly.

Now rendering line 26 0f 240 (311373 radiosity samples). 271PPH:  4.5167
pixels per minute on an Athlon 3200+ and dropping as it hits more objects in
the centre of the image.  This is only a preliminary 320x240 render to get
some radiosity samples to reuse for a high definition image later.  I was
going to do the final at 1600x1200 AA 0.3.  Aagh, it'll NEVER finish!

Well, that taught me that function-pigment isosurfaces and radiosity don't
mix  :-)   It's not even near to tracing the isosurface yet, this slowness
is all due to radiosity rays bouncing off other objects (a simplish
mesh-and-cone tree of around 930 finites, not all of it in the scene either)
and hitting the isosurface.

#declare FpPlane = function {pigment {pPlane}}

  isosurface
  { function { y + FpPlane(x,y,z).gray}
    threshold 0.5
    max_gradient 150
    contained_by {box {<-500,-1,-500>, <500,1,500>}}
    texture {tPlane}
  }

Perhaps I could set the max_gradient much lower than 150 and put up with
holes versus the extra speed.  But Povray has already reported a max
gradient of 897 in the isosurface!

Perhaps I could make the isosurface much smaller in the contained_by bounds,
so there's less area for radiosity rays to hit, and use a simple plane of
the same texture pattern ( pigment {pPlane}) for the outer distances.  But
it was intended to be visible over a long-distance shot, and I think that
the boundary is going to be highly visible as a simple plane returns light
very differently (and I'd have to interrupt this render to test it).

Perhaps I should set an accuracy value larger than the default (0.001).  Any
suggestions?  It doesn't have to be a mathematically correct surface, it's
only supposed to represent a rocky ground plane for the artistic statement.

Do you know of a way to "soften" a pigment function as used in an
isosurface, that may reduce that gradient?  This one has a turbulent
function like an agate in it.

I'm also using settings somewhat based on Tim's two-pass radiosity
experiments at NoLights.

    #if (Rad_Pretrace)  // For a low-res high quality first pass
      pretrace_start 1
      pretrace_end   1
      count          300
      nearest_count   10
      error_bound    0.1
      recursion_limit  2
      low_error_factor 1
      gray_threshold 0.2
      minimum_reuse  0.005
      // normal on
      // media on
      save_file "RTCliche4HoH1.rmap"
      load_file "RTCliche4HoH1.rmap"
      // always_sample  off
    #else
<rad settings for the hi-res trace here>
    #end

I haven't actually gone as stringent as some of Tim's settings, but this
scene is still slooow at 320x240.  It looks like I'll have to pull back on
most of those settings.  Which will give the greatest return -- 
recursion_limit and minimum_reuse perhaps?

Without radiosity, the shadows are horribly flat on the very busy surfaces
in the scene.

Should I let this small render run for the rest of the fortnight, so I keep
the radiosity file, then loosen everything up for the final?  How DO you
speed up isos so they complete before your computer dies of old age?

Cheers,
    Brian

Post a reply to this message

In article <40e0308d$1@news.povray.org> , "Brian Elliott" 
<bel### [at] gilcomau> wrote:

> Getting nowhere veeery slooowly.
>
> Now rendering line 26 0f 240 (311373 radiosity samples). 271PPH:  4.5167
<snip - did not read it all>

If the scene renders much faster without radiosity (around two orders of
magnitude), then you are most likely using radiosity incorrectly.  Otherwise
(i.e. just one order of magnitude faster without radiosity), this is about
normal.

    Thorsten

____________________________________________________
Thorsten Froehlich, Duisburg, Germany
e-mail: tho### [at] trfde

Visit POV-Ray on the web: http://mac.povray.org

Post a reply to this message

Brian Elliott wrote:
> Getting nowhere veeery slooowly.
> 
> Now rendering line 26 0f 240 (311373 radiosity samples). 

Just do a simple bit of arithmetic and you will see this does not make 
much sense.  311373 samples in a 320x240 render - that's about 4 samples 
per pixel and you still have nearly the whole final trace left with 
always_sample on, in the end it is probably about 5-6 samples per pixel. 
  Of course it is possible to use such radiosity settings but there is 
not much reason to do such a render.

Christoph

-- 
POV-Ray tutorials, include files, Sim-POV,
HCR-Edit and more: http://www.tu-bs.de/~y0013390/
Last updated 01 May. 2004 _____./\/^>_*_<^\/\.______

Post a reply to this message

"Thorsten Froehlich" <tho### [at] trfde> wrote in message
news:40e03787$1@news.povray.org...
> If the scene renders much faster without radiosity (around two orders of
> magnitude), then you are most likely using radiosity incorrectly.
Otherwise
> (i.e. just one order of magnitude faster without radiosity), this is about
> normal.

Good.  Thanks for explaining what should be expected of radiosity.  This
case is definitely beyond a couple of orders of magnitude, probably three,
as it has run 120 times longer than a render without radiosity, and has now
progressed to 11%.

I'll let it go until tomorrow night - it is already 1:50am and I've already
stolen too much sleep time from work tomorrow - and then I'll pull the
render and redo those settings.

Brian

Post a reply to this message

"Christoph Hormann" <chr### [at] gmxde> wrote in message
news:cbpdhb$7h7$1@chho.imagico.de...
> Just do a simple bit of arithmetic and you will see this does not make
> much sense.  311373 samples in a 320x240 render - that's about 4 samples
> per pixel and you still have nearly the whole final trace left with
> always_sample on, in the end it is probably about 5-6 samples per pixel.
>   Of course it is possible to use such radiosity settings but there is
> not much reason to do such a render.

Thanks Christoph, and noted.  I'll kill it next chance.

Brian.

Post a reply to this message

"Brian Elliott" <bel### [at] gilcomau> wrote:
> Do you know of a way to "soften" a pigment function as used in an
> isosurface, that may reduce that gradient?  This one has a turbulent
> function like an agate in it.

I have also experimented with isosurfaces for terrain, and the conclusion I
came up with is that, where possible, you should first render a height
field of the object as that will run many times faster.  The downside is,
you won't have bumps sticking out horizontally (only vertically).  Still,
if you could find some way to first tesselate the object, you would save
yourself several days' worth of rendering time.

....Chambers

Post a reply to this message

Best thing to do with slow renders that take weeks: forget about them and
let them run on low priority for years! Just make sure that the result is
worth it and you'll be fine ;P

Post a reply to this message

"Chambers" <bdc### [at] yahoocom> wrote in message
news:web.40e05c8d35bc6efdca11893c0@news.povray.org...
> "Brian Elliott" <bel### [at] gilcomau> wrote:
> > Do you know of a way to "soften" a pigment function as used in an
> > isosurface, that may reduce that gradient?  This one has a turbulent
> > function like an agate in it.
>
> I have also experimented with isosurfaces for terrain, and the conclusion
I
> came up with is that, where possible, you should first render a height
> field of the object as that will run many times faster.  The downside is,
> you won't have bumps sticking out horizontally (only vertically).  Still,
> if you could find some way to first tesselate the object, you would save
> yourself several days' worth of rendering time.

Thanks.

I had briefly looked into Ingo's mesh making macros - I thought maybe
param.inc might be of use.  But I was confused by the need to pass three
functions to it, whereas all I have is a single pigment function in the
isosurface.

If I could use heightfield or mesh to render the more distant parts - it
would be a close-enough simulation.  Closer to the camera, it would need a
fairly tight mesh resolution, I expect.  Locations right near to camere
perspective , I'd probably have to retain as isosurface for realism.

Brian

Post a reply to this message

"Apache" <apa### [at] hotmailcom> wrote in message
news:40e0a970$1@news.povray.org...
> Best thing to do with slow renders that take weeks: forget about them and
> let them run on low priority for years! Just make sure that the result is
> worth it and you'll be fine ;P

Actually I've decided I'm not going to do any more work on it tonight, and
let it go for now.  17% complete at 2d 04h 08m.  :-)

I'll probably kill it at some point, but in no hurry now, and if I do, I'll
save the partial image and radiosity map.  Might be useful for something,
particularly the radiosity samples already taken.

Brian

Post a reply to this message

Update:

In the end, I *had to* stop the render -- shortly after my last message,
while typing a message on another news.povray.org thread, all keyboard
control stopped.  Type away; every key went "blip, blip, blip", nothing on
screen, nothing from the three-fingered salute.  At least Windows was still
controllable by the mouse, but it still meant I had to stop the render and
SHUTDOWN.

Which was a blessing.  Necessity re-taught me something I had forgotten
about PoV-Ray in the years since I had stopped:  I rediscovered in the docs
the Resume option and Mosaic Preview!  Actually I think I hadn't used Mosaic
since the days of 25MHz 386'es and software-floating-point in C libraries!

SO...  With the render stopped, I set recursion_limit back to 1 [from 2],
and minimum_reuse to 0.01 [from 0.005], and resumed.  It is now blistering

of magnitude faster than before, and I can live with that.  :-)

Brian

Post a reply to this message