Using the +C +F options (resuming and file output) when the file doesn't
exist yet causes the parsing to abort with an error message saying "Continue
Trace Error: Error opening BMP image". +C alone (without file output)
doesn't cause the problem.
This is new behaviour: in previous versions, POV-Ray gave the message
"Warning: Cannot open continue trace output file. Opening new output file"
and went on rendering, which is more practical IMHO.

3.6b1, Windows XP HE SP1, 1 Gb RAM

-- 
**********************
http://www.oyonale.com
**********************
- Graphic experiments
- POV-Ray and Poser computer images
- Posters

Post a reply to this message

Gilles Tran wrote:
> Using the +C +F options (resuming and file output) when the file doesn't
> exist yet causes the parsing to abort with an error message saying "Continue
> Trace Error: Error opening BMP image". +C alone (without file output)
> doesn't cause the problem.

Does this only happen with sys (bmp) file format or also with others?

Christoph

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

Post a reply to this message

news:4o4### [at] tritonimagicode...
> Gilles Tran wrote:
> > Using the +C +F options (resuming and file output) when the file doesn't
> > exist yet causes the parsing to abort with an error message saying
"Continue
> > Trace Error: Error opening BMP image". +C alone (without file output)
> > doesn't cause the problem.
>
> Does this only happen with sys (bmp) file format or also with others?

Only with the sys format (+F or +FS on Windows).

G.


-- 
**********************
http://www.oyonale.com
**********************
- Graphic experiments
- POV-Ray and Poser computer images
- Posters

Post a reply to this message

"Gilles Tran" <gitran_nospam_@wanadoo.fr> wrote in message
news:401cfdda$1@news.povray.org...

> news:4o4### [at] tritonimagicode...
> > Gilles Tran wrote:
> > > Using the +C +F options (resuming and file output) when the file doesn't
> > > exist yet causes the parsing to abort with an error message saying
> "Continue
> > > Trace Error: Error opening BMP image". +C alone (without file output)
> > > doesn't cause the problem.
> >
> > Does this only happen with sys (bmp) file format or also with others?
>
> Only with the sys format (+F or +FS on Windows).

I'm just fixing this now.

What would you prefer it do in the case where the file exists, but is (a) corrupt, (b)
of the wrong format (e.g. bit-depth), or (c)
of the wrong resolution.

-- Chris

Post a reply to this message

Program ended abnormally on 11/03/2004 09:59, Due to a catastrophic Chris Cason 
error:
> "Gilles Tran" <gitran_nospam_@wanadoo.fr> wrote in message
news:401cfdda$1@news.povray.org...
> 

>>news:4o4### [at] tritonimagicode...
>>
>>>Gilles Tran wrote:
>>>
>>>>Using the +C +F options (resuming and file output) when the file doesn't
>>>>exist yet causes the parsing to abort with an error message saying
>>
>>"Continue
>>
>>>>Trace Error: Error opening BMP image". +C alone (without file output)
>>>>doesn't cause the problem.
>>>
>>>Does this only happen with sys (bmp) file format or also with others?
>>
>>Only with the sys format (+F or +FS on Windows).
> 
> 
> I'm just fixing this now.
> 
> What would you prefer it do in the case where the file exists, but is (a) corrupt,
(b) of the wrong format (e.g. bit-depth), or (c)
> of the wrong resolution.
> 

You could warn the user and offer and interactive choice to:
(a) start from scratch, overwriting the file.
(b) start from scratch, renaming the previous file.
(c) continue using the original file's resolution and color depth.
(d) abort the render.

Or maybe, if and interactive choice is not a good idea, have these behaviours be 
part of an .ini setting.


-- 
/*Francois Labreque*/#local a=x+y;#local b=x+a;#local c=a+b;#macro P(F//
/*    flabreque    */L)polygon{5,F,F+z,L+z,L,F pigment{rgb 9}}#end union
/*        @        */{P(0,a)P(a,b)P(b,c)P(2*a,2*b)P(2*b,b+c)P(b+c,<2,3>)
/*   videotron.ca  */}camera{orthographic location<6,1.25,-6>look_at a }

Post a reply to this message

"Francois Labreque" <fla### [at] videotronca> wrote in message
news:40512aef$1@news.povray.org...
> >
> > What would you prefer it do in the case where the file exists, but is
(a) corrupt, (b) of the wrong format (e.g. bit-depth), or (c)
> > of the wrong resolution.
>
> You could warn the user and offer and interactive choice to:
> (a) start from scratch, overwriting the file.
> (b) start from scratch, renaming the previous file.
> (c) continue using the original file's resolution and color depth.
> (d) abort the render.
>
> Or maybe, if and interactive choice is not a good idea, have these
behaviours be
> part of an .ini setting.

Ahem. Please excuse me if I am making this seem trivial. Maybe there should
only be a warning telling of the incompatible file so the user can check
into that themselves.

This error was about a default system output file not being continuable, so
with that fixed (whether about the file itself or only the switch +F) I'd
think it simpler to just warn with a text message that there is a fault with
the file intended for usage. Most any typical circumstance would be that a
partial (and correct) image file is awaiting continuance and be written to.
Specifying a different output type would obviously be a mistake.

Now, I'll take back what I say here if Francois' suggestion were to be
invoked for every file type, because that means a person might be trying to
juggle image files around and would need the extra presentation of options
before allowing the +C switch to have control automatically. Guess that was
the idea about additional INI settings, to intervene in various ways. If you
can see it my way a moment, what I'm trying to convey here is that a popup
dialog asking to make a few choices either needs plenty of info passed to
the user (more than just "there's a problem"), or can cause the user to need
to go check on the file anyhow while that dialog sits awaiting a response.

Hopefully I'm making some sense. For me, a continued trace is always just
that, continued and not changed. On the other hand, I'd hate to see a
potentially usable file overwritten from the start by mistake too. But this
depends on how much failsafe you think ought to be built in to guard against
that happening, regardless of how one might get named and placed the same as
what would be done during the next render.

Bob H.

Post a reply to this message

news:40507ed6@news.povray.org...

> What would you prefer it do in the case where the file exists, but is (a)
corrupt, (b) of the wrong format (e.g. bit-depth), or (c)
> of the wrong resolution.

It should stop and show an error message explaining the problem as precisely
as possible. I don't see much the point of continuing a render in these 3
cases.

G.


-- 
**********************
http://www.oyonale.com
**********************
- Graphic experiments
- POV-Ray and Poser computer images
- Posters

Post a reply to this message