On 2026-01-06 13:53 (-4), jr wrote:
> Cousin Ricky <ric### [at] yahoocom> wrote:
>> On 2025-12-25 05:58 (-4), jr wrote:
>>> unsure if it is "in the spirit", but a "dedicated" font (preferred TTF) default,
>>> for "post installation" ?
>> I don't know what you mean by "dedicated."  In current text{} syntax, a
>> font is always specified, so there is no default font.
> 
> in context I mean(t):
> #declare Defaults_Font = "timrom.ttf";
> 
> to allow use in those 'text{}'s.

I dunno.  That seems superfluous to me.

>> ---%<-----%<-----%<-----%<---[BEGIN CODE]---%<-----%<-----%<-----%<---
>> #declare Default_Ambient = rgb 0.05;
> 
> won't fly.  '#version' has to be first.

Granted.  I should have started that scene file excerpt with '#version
3.8;'.

Post a reply to this message

I wrote out a generic implementation for an always-included set of files.

A few things not yet implemented due to not having the code readily available.

Just a proof-of-concept, I'm sure that some things might be best loaded from
other dedicated include files, (best would be inbuilt as source), though I'm
still trying to work out a good way to have a "monolithic include file" where
only the desired parts will actually be loaded/implemented.

I think that a calculation for minimum visible size/radius would be a good
addition, as would an always-face-the-camera macro.

Post a reply to this message

Attachments:
Download 'defaults_be.inc.txt' (6 KB)

hi,

Cousin Ricky <ric### [at] yahoocom> wrote:
> ...
> > #declare Defaults_Font = "timrom.ttf";
> ...
> I dunno.  That seems superfluous to me.

:-)


> >> ---%<-----%<-----%<-----%<---[BEGIN CODE]---%<-----%<-----%<-----%<---
> >> #declare Default_Ambient = rgb 0.05;
> >
> > won't fly.  '#version' has to be first.
>
> Granted.  I should have started that scene file excerpt with '#version
> 3.8;'.

right, I used '#version version' as per "recommendation", see last sentence(s)
on the page:
<https://wiki.povray.org/content/Reference:Numeric_Expressions#Built-in_Variables>


regards, jr.

Post a reply to this message

On 2026-01-08 02:57 (-4), jr wrote:
> 
> right, I used '#version version' as per "recommendation", see last sentence(s)
> on the page:
> <https://wiki.povray.org/content/Reference:Numeric_Expressions#Built-in_Variables>

I read that paragraph a long time ago, and it didn't make sense to me.
Now I'm reading it over and over, and I still can't figure out what it
means, or why I should use that construct.

Post a reply to this message

Cousin Ricky <ric### [at] yahoocom> wrote:
> On 2026-01-08 02:57 (-4), jr wrote:
> >
> > right, I used '#version version' as per "recommendation", see last sentence(s)
> > on the page:
> > <https://wiki.povray.org/content/Reference:Numeric_Expressions#Built-in_Variables>
>
> I read that paragraph a long time ago, and it didn't make sense to me.
> Now I'm reading it over and over, and I still can't figure out what it
> means, or why I should use that construct.

I will agree that that paragraph is poorly phrased.
It may even have typos.

In any event, I think that the general idea is to just be able to declare the
version to be whatever software version is used. (automatically)
You can get rid of the warning/error using boilerplate and without having to
know what version is being used.

Then you can do whatever manual versioning stuff afterwards.

At least that seems to be the intent. (?)

- BE

Post a reply to this message

hi,

"Bald Eagle" <cre### [at] netscapenet> wrote:
> Cousin Ricky <ric### [at] yahoocom> wrote:
> > On 2026-01-08 02:57 (-4), jr wrote:
> > > right, I used '#version version' as per "recommendation", ...
> > I read that paragraph a long time ago, and it didn't make sense to me.
> > Now I'm reading it over and over, and I still can't figure out what it
> > means, or why I should use that construct.
>
> I will agree that that paragraph is poorly phrased.
> It may even have typos.

in which case, would (either of) you mind sending (or posting) a suggestion for
a re-worded, improved paragraph ?


> In any event, I think that the general idea is to just be able to declare the
> version to be whatever software version is used. (automatically)
> You can get rid of the warning/error using boilerplate and without having to
> know what version is being used.
> Then you can do whatever manual versioning stuff afterwards.
> At least that seems to be the intent. (?)


regards, jr.

Post a reply to this message

Cousin Ricky <ric### [at] yahoocom> wrote:

> I read that paragraph a long time ago, and it didn't make sense to me.
> Now I'm reading it over and over, and I still can't figure out what it
> means, or why I should use that construct.

Best I can do on short notice.

I am aware that it's not entirely correct, however it's a step forward to
unraveling what actually occurs, so that we can properly, clearly, and
unambiguously summarize the behaviour of the version keyword(s).


See comments by clipka at:
https://github.com/POV-Ray/povray/issues/414

https://wiki.povray.org/content/Reference:Numeric_Expressions#Built-in_Variables
The built-in float variable version contains the current setting of the version
compatibility option.

.....

Note: As of POV-Ray v3.7, the version compatibility option defaults to 3.62
(corresponding to v3.6.2) rather than the actual software version.

However, in POV-Ray v3.7.0, version defaults to the actual software version.

This is a Change in POV-Ray v3.8 so that version generally reflects the version
compatibility option even in the default case, except when used inside the very
first #version statement where it still defaults to the actual software version.

Therefore, to identify POV-Ray version 3.8 or higher, you will need to start
your scene file with the following construct:

#version version;

-------------------------------------------------------------------------------------------

Copilot

omitted and when explicitly set via #version version;:

Default Behavior When #version Is Omitted

Up to POV-Ray 3.1: Defaults to 3.1 [www-f9.ijs.si]

[povray.org]
POV-Ray 3.7: Defaults to 3.62 (a legacy-compatible default), and a warning is
issued if no #version appears before other declarations [wiki.povray.org]
POV-Ray 3.8 and beyond: If neither #version, INI (Version=n.n), nor CLI switch

3.62 for compatibility [wiki.povray.org], [github.com]


Behavior When #version X.Y; Is Specified

Sets the language feature set to that version, enabling or disabling features
accordingly ─ e.g. #version 1.0 disables float expressions and newer
syntax [povray.org], [wiki.povray.org]
The trailing semicolon is mandatory (since v3.1); omitting it causes warnings
and can break macros [povray.org], [www-f9.ijs.si]
Setting #version multiple times during parsing switches compatibility modes and
can be used alongside #local and the version built-in:


1.0‑mode code#version Temp_Vers;         // Restore previous version```
[2](https://www.povray.org/documentation/view/3.6.0/240/)[3](https://wiki.povray.org/content/Reference:Version_Directiv
e)
 Show more lines

From POV-Ray 3.7 onward, explicitly specifying #version 3.7; (or higher) is
required to get full access to the latest syntax and defaults; otherwise,
old-style legacy defaults persist. [wiki.povray.org]


Summary Table

POV-Ray Version Range  Default if Omitted  #version X.Y; Effect


3.7    3.62 (warning if omitted) Required to access 3.7+ behavior; else legacy
defaults used

defaults for specified version


Key Takeaways

Omitting #version defaults to legacy-compatibility version (3.5 pre‑3.7,
3.62 from 3.7 onward).
Explicit #version X.Y; sets feature availability to that version (and is
required in modern POV-Ray to opt into newer syntax).
The version built-in and re-assignment via #version version; allow preserving
and restoring compatibility states during inclusion or scene control.




- BE

Post a reply to this message