POV-Ray : Newsgroups : povray.pov4.discussion.general : On the #version scene language directive. : On the #version scene language directive. Server Time
3 Mar 2024 17:09:37 EST (-0500)
  On the #version scene language directive.  
From: William F Pokorny
Date: 29 Jan 2024 07:00:26
Message: <65b7935a$1@news.povray.org>
While running down this bug:


I ended up reviewing a lot of the version setting code.

For a long time code development was on a path to require #version as 
the very first line of a scene. If you coded:

#declare One = 1.0;
#version 3.7;

you'd get warnings or errors saying something like:

"Parse Error: As of POV-Ray v3.7, the '#version' directive must be the 
first non-comment statement in the scene file. ..."

After the v3.8 release parser code was backed up to an earlier form of 
the parser, this checking coded ended up excluded in, v3.8 beta 2, via 
some hard coding in the source (#if 0 .... #endif). Comments were added 
about the check was a problem because of the +hi include header feature 
for as one issue. Yuqk still issues an error, within the context of the 
newer parser.

In the overall code, it looks like to me, the original intent was the 
default-version / optional-version override when running of 'povray' was 
to be accomplished with 'version=' ini / +mv flag options - which makes 
a lot of sense.

The #version directive in the scene description language being needed 
only when, locally specific, scene language handling was needed. A 
little of this original intent can be seen by running the code above 
with a (v3.8 beta 2) executable and looking at the 'input:' line just 
below the 'Parser Options' header in the output.

povray above.pov version=3.7
<Input file: hmm2.pov (compatible to version 3.70)>

povray above.pov +mv3.8
<Input file: hmm2.pov (compatible to version 3.80)>

povray above.pov
<Input file: hmm2.pov>

Always handling the initial rendering version via ini / flag settings 
solves the 'must be first' problem and the '+hi include file first on 
the fly' problem.

Unfortunately, it looks like the ini / flag defaulting isn't completely 
there today code wise (the default isn't set correctly(a)). However, I 
think the ini / flag solution should be the path going forward for v4.0. 
I intend to adopt the approach for future releases of the yuqk fork.

Putting the #version first still good form. Further, for those already 
doing it, the ini / flag approach will result in no changes at all in 

Bill P.

(a) - I think things ended up this way for backward compatibility. No 
#version and defaulting going all the way back to 3.6.2.

(b) - Excepting where users making use of +hi.

Post a reply to this message

Copyright 2003-2023 Persistence of Vision Raytracer Pty. Ltd.