While running down this bug:

https://news.povray.org/povray.beta-test/thread/%3C65b6ba93%241%40news.povray.org%3E/

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 
behavior(b).

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

On 1/29/24 07:00, William F Pokorny wrote:
> 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.

See related discussion about assumed_gamma and version settings at:

https://news.povray.org/povray.beta-test/thread/%3C65bebb56%241%40news.povray.org%3E/

Status update. In the yuqk fork the default version is now v3.8 and it 
gets set ahead of the parsing with ini version=, flag +mv or v3.8 gets 
defaulted as the version at that pre-parsing stage.

I opted not to drastically modify how the scene description language 
(SDL) #version / version works. While parsing a scene, #version is 
mostly about switching the version defaults(a) and parsing behavior.

(a) - Unless the default{} block has been used in which the version 
default switching part stops working. (The yuqk fork still plans to 
remove the default{} block)

The exception is the very last #version seen will still sometimes affect 
output gamma handling too where assumed_gamma is not set anywhere in the 
file. However, unlike recent, official releases, yuqk requires the ini / 
flag stage, version align even where no ini / flag setting used. In 
other words, now in yuqk, a scene where the last #version was v3.5 will 
not turn off output gamma handling unless the executable is run with 
+mv3.5. The ini / flag version becomes the arbiter of what output gamma 
handling gets done.

For v4.0 the approach is not the cleanest possible. With v4.0 maybe two 
version settings - or just drop the backward compatibility and fix 
assumed_gamma and output gamma handling so 'version' isn't tangled in 
that bit.

Bill P.

Post a reply to this message