"Kenneth" <kdw### [at] gmailcom> wrote:
> > I guess a new build was overdue.
>
> [on Windows 7 Ultimate 64-bit]
> I'm getting a strange fatal error on all scene files that I try to run...

BTW, my scenes do run (they parse), but the error occurs at the end of the
parsing stage. So it doesn't seem to be a library-path problem(?)

Post a reply to this message

On 08/31/2018 01:48 PM, Kenneth wrote:
> 
>> I guess a new build was overdue.
> 
> [on Windows 7 Ultimate 64-bit]
> I'm getting a strange fatal error on all scene files that I try to run (which I
> haven't seen before, with other similar development builds that get installed
> into the v3.7 directory):
> 
> "cannot create render state output file"
> 
> Since no one else has mentioned this, I must be doing something wrong at my
> end(?)
> 
> I assume that a scene needs  #version 3.8  (although I've also tried it with
> #version 3.80 and 3.7, with no luck.) Does anything in PVENGINE or POVRAY.INI
> need changing, perhaps?
> 
> 
> 
> 

This says POV-Ray does not have permission to write to the directory.

Changing the version in the SDL won't affect POV-Ray's ability to write
to that directory. :)

The render state file is an intermediate file in case you want to
abort/resume a render. You can turn it off with -CC on the command line,
but then I'd bet that it won't have permission to write the output image
to that directory either.

Does it work with other directories? i.e. ones you own?

-- 
dik
Rendered 1024 of 921600 pixels (0%)

Post a reply to this message

dick balaska <dic### [at] buckosoftcom> wrote:

> > [on Windows 7 Ultimate 64-bit]
> > I'm getting a strange fatal error on all scene files that I try to run...
> > "cannot create render state output file"
> >
>
> This says POV-Ray does not have permission to write to the directory.

My first thought was to check my (Windows)POV-Ray menu item, "Options/Script I/O
restrictions" (in case it had changed somehow), but it's set to:
No restrictions
Permit Read/Write in Current Directory
Disable Starting Other programs

BTW, no problem occurs when I run one of the older (3.7-folder) alpha or beta
versions-- just this 3.8.0 variant.

>
> The render state file is an intermediate file in case you want to
> abort/resume a render. You can turn it off with -CC on the command line,
> but then I'd bet that it won't have permission to write the output image
> to that directory either.
>

Good news: Adding -cc to the command line DOES work-- the scene now renders!
Thanks for that hint.

So apparently(?), the problem is with the state-file-writing mechanism, in some
way... (at least on my end)...

Post a reply to this message

"Kenneth" <kdw### [at] gmailcom> wrote:

>
> Good news: Adding -cc to the command line DOES work-- the scene now renders!
> Thanks for that hint.
>

Well, things are still not quite right: I neglected to notice that, even though
the scene does now render to the preview window, there's no image saved:

"cannot write PNG data" (fatal error after the preview)

I re-checked my POVRAY.INI file to make sure it has the correct library path for
image output; it's still correctly set to...

Output_File_Name="C:/Users/Computer/Documents/Kens POV-Ray rendered IMAGES/"

But no image file is written.
Alas, still very strange...

Post a reply to this message

"Kenneth" <kdw### [at] gmailcom> wrote:
> "Kenneth" <kdw### [at] gmailcom> wrote:
>
> Well, things are still not quite right...
>
..... and they're getting stranger :-/

Now the same problem is happeniong with my (older) 3.7 alphas and betas-- even
my original 3.7.0--  EXCEPT with my 'stand-alone' 3.7.1 beta 9  install. That
one continues to work correctly. (It's own 'guts' are in its own folder in
"Programs/POV-Ray" called "3.7 beta", which might be a clue; all the other 3.7
alphas and betas-- and 3.7.0-- share another different folder there but still in
"Programs/POV-Ray".)

So I re-booted my computer as a last resort. But the problem remains.

Seems that *something* must have gotten corrupted in the 'problem' POV-ray
folder (my only guess right now.) Woe is me :-(

Post a reply to this message

On 08/31/2018 04:05 PM, Kenneth wrote:
> "Kenneth" <kdw### [at] gmailcom> wrote:
> 
>>
>> Good news: Adding -cc to the command line DOES work-- the scene now renders!
>> Thanks for that hint.
>>
> 
> Well, things are still not quite right: I neglected to notice that, even though
> the scene does now render to the preview window, there's no image saved:
> 
> "cannot write PNG data" (fatal error after the preview)
> 
> I re-checked my POVRAY.INI file to make sure it has the correct library path for
> image output; it's still correctly set to...
> 
> Output_File_Name="C:/Users/Computer/Documents/Kens POV-Ray rendered IMAGES/"

Is that the directory that the SDL source is in? Just wondering. The
default is to write to the same directory, so maybe ...

It would be helpful if the error message included the path that POV-Ray
is trying to write to.

Try copying your source file to that directory.  Then render it. If that
works, then we know it's a config problem elsewhere.
-- 
dik
Rendered 1024 of 921600 pixels (0%)

Post a reply to this message

"Kenneth" <kdw### [at] gmailcom> wrote:
>
> I re-checked my POVRAY.INI file to make sure it has the correct library
> path for image output; it's still correctly set to...
>
> Output_File_Name="C:/Users/Computer/Documents/Kens POV-Ray rendered IMAGES/"
>

Well, I found the problem: Human Error (as usual!)

With my WORKING v3.7.1 beta 9 version, I had *changed* the name of my
image-output folder to...

Kens_POV_Ray_rendered_IMAGES

.... which is the currently correct one.

..... and likewise for the image-output library path in its own POVRAY.INI
file...
Output_File_Name=C:\Users\Computer\Documents\Kens_POV_Ray_rendered_IMAGES\

Note the added underscores (and the no-longer-needed double-quotes, since there
are no longer any spaces in that library path.) So everything works fine in beta
9!

HOWEVER, the new 3.8.0 alpha 'engine' was loaded into my older 3.7 folder (which
is the correct placement)-- but the POVRAY.INI file for *v3.7* was using my OLD
library path (the one that I *thought* was correct, the one with no underscores
etc.) I had forgotten to change that INI file to the newer library path for my
output images.

SO... it turned out to be a library-path problem after all. Duh. I updated that
'bad' path, and all is well. Sorry for the trouble and confusion.

A question, though: In testing out alphas, betas, etc., OR while running the
original 3.7.0, should I make ONE master POVRAY.INI file and always use that, no
matter what program version I'm running? Up until now, I've always thought that
each version should keep its own INI file intact. (Uh, which obviously led to my
problem!)

Post a reply to this message

Am 31.08.2018 um 19:08 schrieb jr:
> hi,
> 
> clipka <ano### [at] anonymousorg> wrote:
>> Am 30.08.2018 um 21:38 schrieb jr:
>>
>>> is it ok to just make and copy the new executable into place, or have any of the
>>> supporting files (docs etc) changed too?
>> There's a caveat regarding the help file: ... `povray37.chm`.
> 
> this is a for a Linux box.  :-)

Oops, I didn't see the "make and" there.

(*scratches head*)

I'd have to dig deep and embark on an extensive investigation to make a
reliable statement about this.

If you're talking about dropping the new executable into a v3.7
installation, then I would recommend against it. IIRC the Unix/Linux
incarnation wasn't designed to live piggyback on a v3.7 installation;
that's only done on Windows, because full-fledged installation is
difficult there.

If you're talking about replacing an existing v3.8-alpha binary with the
new one, that shouldn't be a problem.


>> I haven't gotten around to updating the v3.8 help file to the latest
>> Wiki contents yet, so it may be a bit behind.
> 
> when you do, can you please add information regarding the new, relaxed upper
> limit for strings?  I found a few mentions of it [limit] not applying any more,
> but no number for the new limit.  also for the colour_map entry, iirc.

Sky's the limit now. Whatever fits into your memory.

Post a reply to this message

Am 01.09.2018 um 04:15 schrieb Kenneth:

> A question, though: In testing out alphas, betas, etc., OR while running the
> original 3.7.0, should I make ONE master POVRAY.INI file and always use that, no
> matter what program version I'm running? Up until now, I've always thought that
> each version should keep its own INI file intact. (Uh, which obviously led to my
> problem!)

The plan is as follows (for Windows at any rate):


(A) Final Releases
==================

Final releases of different "generations" (e.g. v3.7 vs. v3.8) are
intended to live separately from each other without interfering. The
only intentional point of contact would be the new generation copying
settings from the older generation (if detected) when first started.
(This means that, among other things, they each have their own POVRAY.INI.)

Final releases of the same generation (e.g. v3.7.0 vs. v3.7.1, though
this is hypothetical) are intended to replace each other. The only
reasonably sane way for different binaries of the same generation to
live alongside each other would be to rename one of the binaries, and
have both binaries share everything (most notably the POVRAY.INI, but
also registry settings and other stuff.)


(B) Release Candidates
======================

Release candidates are intended to behave exactly like the respective
final release (except for showng a different version number); this
extends to where they choose to live and how to (not) cooperate or
interfere with other versions.


(C) Beta Releases
=================

In order to allow for installing a beta release while also keeping an
earlier final release of the same generation (e.g. v3.7.0 proper and
v3.7.1-beta.1), beta releases are intended to live in their own happy
place, without interfering with any non-beta versions (but replacing or
interfering with other betas of the same generation).


(D) Development (Alpha) Releases
================================

While all of the above come with an installer, alpha releases don't;
therefore, to make installation reasonably easy, they need to piggyback
on an existing installation, and interfere with it extensively. It is
presumed that alpha users are experienced enough not to mess up their
nice final release, and are willing to accept the (small) risk of the
alpha accidently screwing something up.

New alpha releases of an existing generation (e.g. v3.7.1-alpha) will
piggyback on an earlier final release of the same generation (any v3.7
in the example case.

Alpha releases of a brand new generation (e.g. 3.8.0-alpha) have to
piggyback on a final release of the previous generation (again any v3.7
in the example case).


(E) Experimental Releases
=========================

Same deal as with alpha releases.

Post a reply to this message

hi,

clipka <ano### [at] anonymousorg> wrote:
> If you're talking about replacing an existing v3.8-alpha binary with the
> new one, that shouldn't be a problem.

perfect.

> > ... the new, relaxed upper limit for strings?
> Sky's the limit now. Whatever fits into your memory.

ok.

thank you.


regards, jr.

Post a reply to this message