Hi folks,

examining some mosaic pretrace related code, I've come across some stuff
that looks fishy to me, and leads me to suspect that abort-continue may
not work properly under /some/ conditions when mosaic pretrace (`+spN`
and `+epN`; not to be confused with radiosity pretrace) is used.

I have a hunch that abort-continue might result in bogus results for
/some/ combinations of mosaic pretrace and anti-aliasing settings.

I /think/ the problematic case would be when `+spN +ep1 -a` with N>1 is
used, i.e. mosaic pretrace starting from any resolution and ending at
full resolution, with no anti-aliasing; but I'm not sure whether it'll
actually go wrong, and/or whether other cases might also be affected.

Anyone have time to give this some thorough testing?

Post a reply to this message

The problem I'm encountering so far (in 3.7.1 beta 8) doesn't seem to be related
to mosaic preview or AA, but rather to 'Continue_Trace' itself.

1) Start a render of a typical scene-- no AA--with mosaic preview's
Preview_Start_Size=128 and Preview_End_Size=32, for example (I'm using my
resolution .ini file rather than the command line). OR, no mosaic preview at
all.

2) STOP the render at some point while it is still pre-tracing. (At this point,
NO 'state file' has been generated.)

3) In the .ini file, turn on Continue_Trace.

4) Run the scene to completion. (I can't tell if the 'state file' was ever
generated, as it isn't there now either. But that's normal operation AFAIK-- any
state file *should* disappear once the render is completed.)

5) By MISTAKE, leave 'Continue_Trace=on' in the .ini file

6) Run the scene again, the same way --which seems to take no time at all. But
the render window doesn't show up, and the 'Show/Hide' button is now dimmed out.
(The message window says, "File already rendered and continue requested;
skipping", which makes sense, by itself.)

7) FIX the mistake of leaving 'Continue_Trace=on' by turning it off.

But *any* subsequent render of the scene-- or *any* scene-- does not show up in
the render window, and the 'Show/Hide' button continues to stay dimmed out. (The
scenes ARE rendering, but 'invisibly.') The only way to restore normal operation
is to quite POV-Ray and restart.

It seems that mistakenly leaving 'Continue_Trace=on' is the culprit here, at
least for this particular problem.

Post a reply to this message

clipka <ano### [at] anonymousorg> wrote:
> Hi folks,
>
> examining some mosaic pretrace related code, I've come across some stuff
--->8---
> I /think/ the problematic case would be when `+spN +ep1 -a` with N>1 is
> used, i.e. mosaic pretrace starting from any resolution and ending at
> full resolution, with no anti-aliasing; but I'm not sure whether it'll
> actually go wrong, and/or whether other cases might also be affected.

Using sp>1 (and tried ep>1<sp too) getting a screen pattern in final image.
Every other line has black for every other pixel, while every other line and
column is rendered correctly.

Another thing, it can cause the render window to show same screen pattern, yet
with transparent checkerboard background. I think it must be when final pass is
interrupted and continue trace used afterward.
So maybe if not final pass during stop it won't affect render window.

And confirm same as Kenneth found with continue and no render window, if doing
same here, except using command line instead.

64 bit beta 8.

Post a reply to this message

Am 16.06.2017 um 12:46 schrieb omniverse:
> clipka <ano### [at] anonymousorg> wrote:
>> Hi folks,
>>
>> examining some mosaic pretrace related code, I've come across some stuff
> --->8---
>> I /think/ the problematic case would be when `+spN +ep1 -a` with N>1 is
>> used, i.e. mosaic pretrace starting from any resolution and ending at
>> full resolution, with no anti-aliasing; but I'm not sure whether it'll
>> actually go wrong, and/or whether other cases might also be affected.
> 
> Using sp>1 (and tried ep>1<sp too) getting a screen pattern in final image.
> Every other line has black for every other pixel, while every other line and
> column is rendered correctly.
> 
> Another thing, it can cause the render window to show same screen pattern, yet
> with transparent checkerboard background. I think it must be when final pass is
> interrupted and continue trace used afterward.
> So maybe if not final pass during stop it won't affect render window.

Yes, that pretty much fits my expectations. So looks like I'm onto
something.


> And confirm same as Kenneth found with continue and no render window, if doing
> same here, except using command line instead.

I'm pretty sure that's entirely unrelated.

Post a reply to this message

Am 16.06.2017 um 12:46 schrieb omniverse:

> Using sp>1 (and tried ep>1<sp too) getting a screen pattern in final image.
> Every other line has black for every other pixel, while every other line and
> column is rendered correctly.

If you can find the time, please give beta.9 a thorough shakedown in
this respect.

You may also want to try with and without radiosity pretrace, as well as
radiosity pretrace without mosaic preview.


(Kenneth's scenario is still unfinished business, as I haven't found the
time to investigate it yet.)

Post a reply to this message

Am 15.06.2017 um 21:09 schrieb Kenneth:

> 5) By MISTAKE, leave 'Continue_Trace=on' in the .ini file
> 
> 6) Run the scene again, the same way --which seems to take no time at all. But
> the render window doesn't show up, and the 'Show/Hide' button is now dimmed out.
> (The message window says, "File already rendered and continue requested;
> skipping", which makes sense, by itself.)
> 
> 7) FIX the mistake of leaving 'Continue_Trace=on' by turning it off.
> 
> But *any* subsequent render of the scene-- or *any* scene-- does not show up in
> the render window, and the 'Show/Hide' button continues to stay dimmed out. (The
> scenes ARE rendering, but 'invisibly.') The only way to restore normal operation
> is to quite POV-Ray and restart.

There is an alternative to restarting POV-Ray in such cases: Run a
render at a different resolution. This will always cause the render
window to be closed (if it is open) and then re-opened, making it a
viable workaround for the issue you're seeing.

Post a reply to this message

Am 18.06.2017 um 21:06 schrieb clipka:
> Am 15.06.2017 um 21:09 schrieb Kenneth:
> 
>> 5) By MISTAKE, leave 'Continue_Trace=on' in the .ini file
>>
>> 6) Run the scene again, the same way --which seems to take no time at all. But
>> the render window doesn't show up, and the 'Show/Hide' button is now dimmed out.
>> (The message window says, "File already rendered and continue requested;
>> skipping", which makes sense, by itself.)
>>
>> 7) FIX the mistake of leaving 'Continue_Trace=on' by turning it off.
>>
>> But *any* subsequent render of the scene-- or *any* scene-- does not show up in
>> the render window, and the 'Show/Hide' button continues to stay dimmed out. (The
>> scenes ARE rendering, but 'invisibly.') The only way to restore normal operation
>> is to quite POV-Ray and restart.
> 
> There is an alternative to restarting POV-Ray in such cases: Run a
> render at a different resolution. This will always cause the render
> window to be closed (if it is open) and then re-opened, making it a
> viable workaround for the issue you're seeing.

Also, for the records, the problem is already known, and tracked on
GitHub as issue #189 ("Port of FS47 - Render Preveiw window can become
disabled"):

https://github.com/POV-Ray/povray/issues/189

Post a reply to this message

clipka <ano### [at] anonymousorg> wrote:
> Am 15.06.2017 um 21:09 schrieb Kenneth:
>
> > 5) By MISTAKE, leave 'Continue_Trace=on' in the .ini file
> >

>
> There is an alternative to restarting POV-Ray in such cases: Run a
> render at a different resolution. This will always cause the render
> window to be closed (if it is open) and then re-opened, making it a
> viable workaround for the issue you're seeing.

Sounds good as a temporary workaround; thanks. The most obvious way to prevent
the problem is not to make the mistake in the first place!  ;-)

Post a reply to this message