Mosaic_Preview has two options that it works with, Preview_Start_Size and
Preview_End_Size. The documentation is clear about what they do. But the
'wording' of Preview_End_Size is kind of misleading, as to its function: the
render *continues* anyway, until every pixel is rendered (i.e., the 'end size'
is 1 pixel, when thought of this way, even if Preview_End_Size is set to 32, for
example.)

I do realize that the docs' meaning of 'preview' is... 'PRIOR to the final
every-pixel render.'  But I would like to suggest a change to the operation of
Preview_End_Size: that the render actually end when that pixel-size is reached.
My reasoning is this: If the idea is to do a quick blocky 'preview' of a render,
to see the scene in a rather gross way for quickly determining any problems,
then continuing to render down to a single pixel is 'overkill', IMO, for two
reasons. It kind of defeats the purpose of the gross preview; and it takes more
time to render (... the final pass...) if just a blocky preview is wanted.

My two-cents, anyway.

Post a reply to this message

"Kenneth" <kdw### [at] gmailcom> wrote:
> Mosaic_Preview has two options that it works with, Preview_Start_Size and
> Preview_End_Size. The documentation is clear about what they do. But the
> 'wording' of Preview_End_Size is kind of misleading, as to its function: the
> render *continues* anyway, until every pixel is rendered (i.e., the 'end size'
> is 1 pixel, when thought of this way, even if Preview_End_Size is set to 32, for
> example.)
>
> I do realize that the docs' meaning of 'preview' is... 'PRIOR to the final
> every-pixel render.'  But I would like to suggest a change to the operation of
> Preview_End_Size: that the render actually end when that pixel-size is reached.
> My reasoning is this: If the idea is to do a quick blocky 'preview' of a render,
> to see the scene in a rather gross way for quickly determining any problems,
> then continuing to render down to a single pixel is 'overkill', IMO, for two
> reasons. It kind of defeats the purpose of the gross preview; and it takes more
> time to render (... the final pass...) if just a blocky preview is wanted.

Well, there is manually stopping.  ;)

I'm only able to think an actual output image as preview would be the real need
for such a thing, unless the idea would also be to free the computer itself of
needless tasking on a long render.

At least that's how I'm seeing this. Interesting that preview was never made to
prevent a finished render, and maybe that was how it was originally thought
of... and I can imagine why. Just like the annoying (did I say that?! ignore me
there) message if rendering a long time and trying to stop it.  :)

Bob

Post a reply to this message

"omniverse" <omn### [at] charternet> wrote:

>
> Well, there is manually stopping.  ;)

Ah yes, you have guessed correctly, o wise sage :-P  I end up stopping *every*
mosaic preview I make. Alas, that takes concentrated eye-hand coordination:
moving the mouse, pinpointing the STOP button, and clicking on it. Oh Lordy,
what a chore!!
>
>
> ...Interesting that preview was never made to
> prevent a finished render, and maybe that was how it was originally thought
> of...

I'm thinking the same-- because, by leaving OUT Preview_End_Size, the render
*still* continues to the final 1-pixel render. It seems to me that
Preview_End_Size was 'invented' to keep that from happening... but perhaps
doesn't work the way it was originally intended to.

Post a reply to this message

On 6/16/2017 3:09 PM, Kenneth wrote:
>> >Well, there is manually stopping.;)
> Ah yes, you have guessed correctly, o wise sage:-P   I end up stopping*every*
> mosaic preview I make. Alas, that takes concentrated eye-hand coordination:
> moving the mouse, pinpointing the STOP button, and clicking on it. Oh Lordy,
> what a chore!!

In windows Alt+g starts or stops depending if the render is running or not.
But then you need the coordination to find and press two keys at the 
same time. ;)

-- 

Regards
     Stephen

Post a reply to this message

"omniverse" <omn### [at] charternet> wrote:

>
> I'm only able to think an actual output image as preview would be the real need
> for such a thing [the way mosaic preview currently works]

Yes, there is that, I admit (although it's a *slow* way to make a final render.)
I can see that there might be two differing philosophies, about Preview_End_Size
continuing to the final 1-pixel render (as-is), or not.

Perhaps it's the phrase itself that bugs me. OR-- another thought-- mosaic
preview should logically have *3 options* instead of two:

1) Preview_Start_Size
2) Preview_Stop_Size (which is the current meaning of 'Preview_End_Size' but
without proceeding to a final 1-pixel render)
3) Preview_End_Size (for 'final' render; 1 or another chosen value.)

Leaving 3) out would make the render stop at 2).

Leaving 2) out would 'fall through' to 3)... and would cause 3) to default to
its present behavior (i.e., proceeding to a final 1-pixel render, for backward
compatibility, regardless of its 'new' feature of a chosen value.)

So far, I don't see a backwards-compatibility problem with this logic; but I
welcome comments from more astute observers ;-)

Post a reply to this message

If you really want a preview without a final render, how about just
using a lower resolution?

If the resulting image gets too small for your taste, you can always
maximize the render window.


There is actually a strong point in favour of `Preview_End_Size`s
current mode of operation:

Except in quite specific circumstances, the effort of creating the
mosaic preview _adds_ to the effort of creating the final render; if you
carry on with the preview all the way down to full resolution, in the
worst case (scenes where there is little anti-alias work to do) this
might increase render time by as much as 25%.

With modern image sizes, chances are you won't need the 2x2 mosaic
preview step to decide whether you want POV-Ray to go for the final
render, so cutting the mosaic preview short after the 4x4 step you can
cut down the mosaic preview overhead to little more than 6%; and if the
8x8 step is detailed enough for you, the overhead drops to less than 2%.

Post a reply to this message

clipka <ano### [at] anonymousorg> wrote:
>
> If you really want a preview without a final render, how about just
> using a lower resolution?
>
> If the resulting image gets too small for your taste, you can always
> maximize the render window.

Another mouse-click!!!!   :-0   But admittedly a good idea.

>
> With modern image sizes, chances are you won't need the 2x2 mosaic
> preview step to decide whether you want POV-Ray to go for the final
> render, so cutting the mosaic preview short after the 4x4 step you can
> cut down the mosaic preview overhead to little more than 6%; and if the
> 8x8 step is detailed enough for you, the overhead drops to less than 2%.

That's interesting, and useful. I had never done such a test myself, to
determine the overhead.

Post a reply to this message

Am 16.06.2017 um 23:58 schrieb Kenneth:

>> With modern image sizes, chances are you won't need the 2x2 mosaic
>> preview step to decide whether you want POV-Ray to go for the final
>> render, so cutting the mosaic preview short after the 4x4 step you can
>> cut down the mosaic preview overhead to little more than 6%; and if the
>> 8x8 step is detailed enough for you, the overhead drops to less than 2%.
> 
> That's interesting, and useful. I had never done such a test myself, to
> determine the overhead.

Neither have I - but the source code talks to me ;)

Post a reply to this message

On 6/17/2017 9:42 AM, clipka wrote:
> Neither have I - but the source code talks to me;)


Nurse!

-- 

Regards
     Stephen

Post a reply to this message

Stephen <mca### [at] aolcom> wrote:

>
> In windows Alt+g starts or stops depending if the render is running or not.
> But then you need the coordination to find and press two keys at the
> same time. ;)
>

Sounds exquisitely complicated!! Nevertheless, I shall practice the finger
gymnastics.

Hmm, now where is that ALT key...I know I saw it somewhere once...

Post a reply to this message