POV-Ray : Newsgroups : povray.programming : Speeding render times Server Time
15 Oct 2024 06:01:13 EDT (-0400)
  Speeding render times (Message 1 to 6 of 6)  
From: Bald Eagle
Subject: Speeding render times
Date: 28 Aug 2013 10:15:00
Message: <web.521e05a715e88f6edd2ebc560@news.povray.org>
OK, I had an idea (it happens frequently, and they're all worth what you pay for
them) [and I do realize that those in the know may look at this and say, 'well
that _sounds_ great, posterior-haberdash, but coding that would be a nightmare,
besides the fact that it just doesn't WORK that way...].

It seems like there are a lot of trivial, easy to do things that significantly
slow render times, and there are a few 'standard' way to avoid these pitfalls.

If a light source is inside a light-tight object, it seems that there might be
some way to recognize this fact with something along the lines of a bounding
box.  Turned around, perhaps the same could be done with the camera, for
instance, if the camera were looking at the inside of a hollow sphere, and there
were multiple light sources outside said sphere...
Sometimes there are multiple light sources in a scene, yet the user knows that
any light coming from those would not significantly impact the rest of the
scene, due to distance from the camera, or due to  the visible scene being
outside of the fade distance of the light source, and there seems no good reason
to take these light sources into account when rendering the visible scene.
Perhaps the same ideology can be applied to such lights, or one could have
"light-camera" blobs where the light source only gets recognized when the
defined radii of both the camera and the light source intersect.  Or just a
simple "proximity light" where the light source is only taken into account when
the vector length between the camera and light is less than a certain distance.
Or the option to user-define a bounding box for a light source.

I often see folks with issues where only a few components of a scene actually
change, while other parts are what are "actively" being rendered.  Would it be
possible to define "layers" - some of which would render and others wouldn't?

Which would be dependent upon, and leads me to the next fantasy feature, an
inter-frame storage buffer of sorts.  I've seen people discuss this whole
"saving radiosity data" business (which I'll admit, I have no idea how to do,
since I haven't progressed to using that feature) - and having an in-built
function, or an include file that saves certain data between frames seems like
it would greatly benefit the heavy users of such a tool.
Perhaps a scheme where POV-Ray could pre-render a scene, and then objects could
be tagged with no_render (like no_object, no_reflection, no_shadow) and thus be
excluded from future renders.

Coupling that with the rendering-in-layers idea, perhaps it would be possible to
render the initial "background" layers, store the information, and then simply
reload it before rendering the "active" layer...

In a WIP, I was alerted to the effect of multiple CSG operations on render time.
 Would it be possible to display a warning - something like "Object has
'excessive' number of CSG tests"?  Or a way to break down the contribution of
each object to the render time by separately displaying how many tests each one
contributes to the overall render?  #(;)display_object_tests ?
Perhaps a "reflective object, line XXX"
Anything that would help the user identify and analyze time-eating elements of
their scene.

Clearly some of these features would be user-invoked rather than default
behaviour of the rendering engine.

Just throwing out grist for the mind-mill, hoping they may benefit somebody,
somewhere...


Post a reply to this message

From: Warp
Subject: Re: Speeding render times
Date: 28 Aug 2013 12:00:45
Message: <521e1ead@news.povray.org>
Bald Eagle <cre### [at] netscapenet> wrote:
> If a light source is inside a light-tight object, it seems that there might be
> some way to recognize this fact with something along the lines of a bounding
> box.

light_group is designed for that purpose.

> I often see folks with issues where only a few components of a scene actually
> change, while other parts are what are "actively" being rendered.  Would it be
> possible to define "layers" - some of which would render and others wouldn't?

Even a small change can have an effect on other parts of the scene due to
shadows, reflections, refractions and radiosity.

-- 
                                                          - Warp


Post a reply to this message

From: scott
Subject: Re: Speeding render times
Date: 28 Aug 2013 12:19:30
Message: <521e2312$1@news.povray.org>
>> I often see folks with issues where only a few components of a scene actually
>> change, while other parts are what are "actively" being rendered.  Would it be
>> possible to define "layers" - some of which would render and others wouldn't?
>
> Even a small change can have an effect on other parts of the scene due to
> shadows, reflections, refractions and radiosity.

And usually if you're sure it won't have any impact (or are not bothered 
about the errors) you can write some SDL to render the parts separately 
anyway (using #if, texture baking, transparency etc). This is sometimes 
done for the background/environment, rendered once with a spherical 
camera, and then just included as an HDR textured sphere in future renders.

The only thing that could be improved is not having to reparse the whole 
scene each animation frame, but that's not likely to change until the 
whole SDL/parser is rewritten. An idea I had was that you could load and 
save a "binary" version of an object much like you can do with radiosity 
data. That way if you have a huge mesh in an animation (that is not 
changing) it wouldn't take forever to parse exactly the same data each 
frame.


Post a reply to this message

From: Bald Eagle
Subject: Re: Speeding render times
Date: 28 Aug 2013 13:40:01
Message: <web.521e356f9871a9cfdd2ebc560@news.povray.org>
> light_group is designed for that purpose.

I was unaware of this directive.  Thanks for bringing it to my attention.
I'm not quite sure that would address the problem of an unnecessarily long
render time for 1000 light sources embedded in the center of light-tight black
spheres though.  I'll try it out, but I'm expecting wait a LONG time to get a
jet black render.


> Even a small change can have an effect on other parts of the scene due to
> shadows, reflections, refractions and radiosity.

Indeed this is true, but I think for "casual" rendering, animations where the
camera moves around a lot, or the light source isn't "in" (define this how you
wish) the scene, then it would save a lot of rendering time while developing
scenes and rendering animations that don't need to be IRTC-level quality.

Like I said, these would be options the user could choose to select, not default
behaviour of the render engine.


Post a reply to this message

From: clipka
Subject: Re: Speeding render times
Date: 28 Aug 2013 14:52:08
Message: <521e46d8$1@news.povray.org>
Am 28.08.2013 18:19, schrieb scott:

> And usually if you're sure it won't have any impact (or are not bothered
> about the errors) you can write some SDL to render the parts separately
> anyway (using #if, texture baking, transparency etc). This is sometimes
> done for the background/environment, rendered once with a spherical
> camera, and then just included as an HDR textured sphere in future renders.

Exactly that.

> The only thing that could be improved is not having to reparse the whole
> scene each animation frame, but that's not likely to change until the
> whole SDL/parser is rewritten.

Strike "not likely", replace with "definitely not". Unless you are happy 
with just moving the camera around, in which case the clockless 
animation feature will do exactly that.

> An idea I had was that you could load and
> save a "binary" version of an object much like you can do with radiosity
> data. That way if you have a huge mesh in an animation (that is not
> changing) it wouldn't take forever to parse exactly the same data each
> frame.

Either that, or it'll give you the possibility to pre-compile include 
files. Or - most probably - both.


Post a reply to this message

From: Christian Froeschlin
Subject: Re: Speeding render times
Date: 28 Aug 2013 18:02:24
Message: <521e7370$1@news.povray.org>
Bald Eagle wrote:

> Sometimes there are multiple light sources in a scene, yet the user knows that
> any light coming from those would not significantly impact the rest of the
> scene, due to distance from the camera, or due to  the visible scene being
> outside of the fade distance of the light source

That is already a known suggestion in the pipeline

http://bugs.povray.org/task/118

> Which would be dependent upon, and leads me to the next fantasy feature, an
> inter-frame storage buffer of sorts.

I had also suggested this earlier, it can be quite useful. I hacked
this in a locally built version by adding "#static" variables. These
were identical to those using "#declare" except that they were not
cleared after parsing, so they were available in another frame or
even for different renders as long as POV-Ray was not closed.

This worked fine in principle although the only way to free the memory
hogged by a static variable was to render a script that "#undef"-ed it.

Unfortunately the fix is based on an old beta. I was thinking
to submitting this as a patch after 3.7 final is out.


Post a reply to this message

Copyright 2003-2023 Persistence of Vision Raytracer Pty. Ltd.