Hi,

In order to have a better impression of speed and a faster overlook of the final
image, the last pass should render the pixel in a certain order.

During the first passes, Pov calculate a render weight of each pixels. The
render weights is determined by the cpu/memory/time needed to render. And on the
last pass, Pov render the pixels by weight order.

It's also a way to find rendering holes, where most of the time is consumed.

Did you think is a good idea ?

Cheers

Nico7550

Post a reply to this message

On 2014-05-04 08:34, nico7550 wrote:
> During the first passes, Pov calculate a render weight of each pixels. The
> render weights is determined by the cpu/memory/time needed to render. And on the
> last pass, Pov render the pixels by weight order.

While it's in there figuring out how long a pixel needs to render, why 
not just take home the pixel's final value and be done with it?  I don't 
know if there's a clever way to determine ahead of time what a given ray 
will encounter and need to do without actually chewing through things.

--
Tim Cook
http://empyrean.sjcook.com

Post a reply to this message

> Hi,
>
> In order to have a better impression of speed and a faster overlook of the final
> image, the last pass should render the pixel in a certain order.
>
> During the first passes, Pov calculate a render weight of each pixels. The
> render weights is determined by the cpu/memory/time needed to render. And on the
> last pass, Pov render the pixels by weight order.
>
> It's also a way to find rendering holes, where most of the time is consumed.
>
> Did you think is a good idea ?
>
> Cheers
>
> Nico7550
>
>
>
>

Interesting idea... But not doable without a huge render time cost.

"First pass" can only occurs during a render using radiosity. It's known 
as pretrace steps and is used to collect radiosity data before the 
rendering itself. It crutial to prevent artefacts.

Next, a "quick" pass before the render itself can't raly help in finding 
the pixels that will need the more computation as that quick pass just 
can't touch every pixels and follow all trace paths when there is any 
reflection or refraction, and, if there is any media, compute that 
media, and you need to know that in order to sort the pixels render time 
weight.



Alain

Post a reply to this message

Surely a quick-mosaic render covers this for you. You get an early idea of how
the whole page hangs together.

Post a reply to this message

> Surely a quick-mosaic render covers this for you. You get an early idea of how
> the whole page hangs together.
>
>

A quick mosaic render or preview can give you an idea of how it will 
look and things like general illumination level and balance, it just 
can't find those pixels that take for ever to render unless it appens to 
sit in the middle of a given mosaic tile. It's like doing a render at a 
fraction of the intended resolution and blowing it up in a graphic 
application by a large factor without any resampling nor interpolation.

Post a reply to this message

Le 08/05/2014 22:09, Alain nous fit lire :
> Le 14-05-07 02:21, FNH a écrit :
>> Surely a quick-mosaic render covers this for you. You get an early
>> idea of how
>> the whole page hangs together.
>>

In 3.7, you can play with +RP, +BS, +WT and +RS


> http://wiki.povray.org/content/Reference:Tracing_Options

With enough threads in parallel, and small enough block, by jumping over
blocks, you can get some global overview of your whole picture, even
without mozaic preview.

Enough threads, so that at least one would not get stuck in your slow
blocks.

Using a pattern (+RP) which start at other extremities (for instance
+RP4 starts both left and right side and go toward center), you can get
more than one area in progress at once.

Jumping blocks (with +RS7), it will take 7 "passes" over the whole
picture, so you have an overview as soon as 1/7 of the picture is done.

And the size of block (+BS) can of course be adjusted.

Post a reply to this message