There are gaps in SDL's ability to query the state of the render, and
one of these is the default finish.  This is a problem for defining
certain library textures when radiosity is not used, as include files
have no access to the scene's lighting conditions.  This is the case
with several of the standard include files.

For a 100% diffuse texture, this is easily solved by omitting an ambient
from the finish, and setting a default ambient prior to including the
file that defines the texture; the textures in woods.inc are like this.
At the other extreme, a 100% specular texture, such as a pure metallic
texture, would have both ambient and diffuse set to zero.

But what about a texture that is, say, half metallic?  In that case, the
diffuse and ambient need to be halved.  But halved from what?  While it
is possible to override a finish ambient, I feel it is an unreasonable
burden on the user to have them figure out what ambient is appropriate
for each library texture.

The solution I used for RC3Metal was to have the user declare variables
with the scene's default ambient and diffuse.  But to implement this
solution over many include files would cumbersome for the user.  These
standard include files all set non-zero ambients on declared textures:
  glass_old.inc
  golds.inc
  metals.inc
  stones1.inc
  stones2.inc
  textures.inc

(Files finish.inc, skies.inc, and stars.inc also set non-zero ambients,
but these should really be converted to emission.)

One way to solve this would be to declare a single pair of variables
that would be used by all six include files.  Third party include files
would be encouraged to access these variables.  What do you think of
this proposal?  Does anyone have a better idea?

Post a reply to this message

Op 07/03/2022 om 19:33 schreef Cousin Ricky:
> [snip] >
> One way to solve this would be to declare a single pair of variables
> that would be used by all six include files.  Third party include files
> would be encouraged to access these variables.  What do you think of
> this proposal?  Does anyone have a better idea?

I am certainly no expert at all on this, but it seems a reasonable 
option to me while easiest to implement.

-- 
Thomas

Post a reply to this message

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

> One way to solve this would be to declare a single pair of variables
> that would be used by all six include files.  Third party include files
> would be encouraged to access these variables.  What do you think of
> this proposal?  Does anyone have a better idea?

Absent my current ability to formulate ways other than that one, I'd say that
starting all of those include files with an #include statement that references a
master include would be a good way to do it, in case any future tweaks happened.

Pre-coffee brain is thinking that the textures ought to be written as macros
that return a texture.
Why?
Then you could declare a secondary pair of values to hold "current" values while
retaining the default master values.   Then the user could use the stock
textures with the unaltered default master values, or override them by
redeclaring the "current" values.

Hope that makes sense.

Having some sort of "starter" include, or basic scene file template, or helper
libraries for new users has been intermittently discussed and worked on.
Perhaps as a means to implement, document, and standardize things going forward
from 3.8 to 4.0, you could take this value-pair idea and put that in a
default_values.inc or something that would always get included first thing.
Even after 30 years, we're still grappling with coincident textures, and so I
always define an E value, which is usually 0.000001 to make things bigger or
smaller by that much.  Having that value defined also serves as a reminder when
I'm doing differences, etc.

Post a reply to this message

hi,

Cousin Ricky <ric### [at] yahoocom> wrote:
> ...
> One way to solve this would be to declare a single pair of variables
> that would be used by all six include files.  Third party include files
> would be encouraged to access these variables.  What do you think of
> this proposal?  Does anyone have a better idea?

given that the typical use case is a scene file doing '#include's, a single
"guard" would be nice + easy from the user point of view.


regards, jr.

Post a reply to this message

On 2022-03-08 07:40 (-4), Bald Eagle wrote:
> Cousin Ricky <ric### [at] yahoocom> wrote:
> 
>> One way to solve this would be to declare a single pair of variables
>> that would be used by all six include files.  Third party include files
>> would be encouraged to access these variables.  What do you think of
>> this proposal?  Does anyone have a better idea?
> 
> Absent my current ability to formulate ways other than that one, I'd say that
> starting all of those include files with an #include statement that references a
> master include would be a good way to do it, in case any future tweaks happened.

What do you all think of the attached file?  Are there any other
variables we can add?

I added Defaults_Gamma in case an include file needs to correct for a
scene's assumed_gamma.  (I already have 2 Object Collection modules that
need to know a scene's assumed_gamma in order to return a proper color.)

Post a reply to this message

Attachments:
Download 'defaults.inc.zip' (1 KB)

hi,

Cousin Ricky <ric### [at] yahoocom> wrote:
> ...
> What do you all think of the attached file?  Are there any other
> variables we can add?

a good start ?  (a lot of uppercase letters.. </grin>)

unsure if it is "in the spirit", but a "dedicated" font (preferred TTF) default,
for "post installation" ?


> I added Defaults_Gamma in case an include file needs to correct for a
> scene's assumed_gamma.  (I already have 2 Object Collection modules that
> need to know a scene's assumed_gamma in order to return a proper color.)

given the name and the purpose[*] of the file, I tried using 'include_header' to
load it.  it seems that for the system-wide 'povray.ini' that keyword won't
work.  for my personal file (~/.povray/3.8.povray.ini) I needed to add a
'#version version;' line to 'defaults.inc', before the guard, to avoid the 'as
of version 3.7' error message.

[*] I am looking at it not as the first include in other include files but as an
"always load", ideally.

of interest, loading via 'include_header' works with alpha.99456327 (displaying
the 'Defaults_Epsilon' value), but not for the beta.2.  may be a case of how
things are set up here, can anyone please confirm ?


regards, jr.

Post a reply to this message

"jr" <cre### [at] gmailcom> wrote:
> ...
> of interest, loading via 'include_header' works with alpha.99456327 (displaying
> the 'Defaults_Epsilon' value), but not for the beta.2.  may be a case of how
> things are set up here, can anyone please confirm ?

both work fine, and using 'include_header' in the respective system-wide
'povray.ini' too works; I'd forgotten my using a 'POVINI' in the (BASH)
functions used to invoke povray :-(, sorry about that.

Post a reply to this message

On 2025-12-28 05:58 (-4), jr wrote:
> 
> given the name and the purpose[*] of the file, I tried using 'include_header' to
> load it.

I am not familiar with 'include_header', and cannot find any mention of
it in the documentation or include files.  What does this do?

Post a reply to this message

hi,

Cousin Ricky <ric### [at] yahoocom> wrote:
> ...
> I am not familiar with 'include_header', and cannot find any mention of
> it in the documentation or include files.  What does this do?

to use, add the this to your (global) 'povray.ini' file:

  include_header = /path/to/defaults.inc

guessing the path may be optional if the files are stored in same directory.

this causes the named file to be included, as first thing, before the
scene/frame parsing gets underway.

<wiki.povray.org/content/Reference:Scene_Parsing_Options#Include_File_Name>

in my installed 3.8 documentation it's under "3.2.5.2 Scene Parsing Options".

(fwiw, you may need to refresh your browser's cache before revisiting the wiki's
'Reference:Keywords' page)


regards, jr.

Post a reply to this message

On 2026-01-05 02:46 (-4), jr wrote:
> 
> Cousin Ricky <ric### [at] yahoocom> wrote:
>> ...
>> I am not familiar with 'include_header', and cannot find any mention of
>> it in the documentation or include files.  What does this do?
> 
> to use, add the this to your (global) 'povray.ini' file:
> 
>   include_header = /path/to/defaults.inc
> 
> guessing the path may be optional if the files are stored in same directory.
> 
> this causes the named file to be included, as first thing, before the
> scene/frame parsing gets underway.

This would defeat what I had in mind for the file.  The file would be
referenced by textures.inc, metals.inc, etc., but if the user wants
different defaults, they need to be #declared *before* these other files
are #included.

This is not a problem with the file as I posted it, but I was going to
post a new version of defaults.inc that set assumed_gamma and #default
finish automatically, to save the user a bit of redundancy.  If used via
'Include_Header', the global settings and #defaults would be set before
the scene file has a chance to tell it otherwise.

With my original version, this catch-22 is avoided by including
textures.inc, etc. *after* changing the default idenfifiers, but then
the scene file still has to set assumed_gamma and #default explicitly.

Where is Bald Eagle?  I'm sure he has some good input.

> <wiki.povray.org/content/Reference:Scene_Parsing_Options#Include_File_Name>
> 
> in my installed 3.8 documentation it's under "3.2.5.2 Scene Parsing Options".

Ah, this explains why I couldn't find it.  I looked for it under
keywords, and when it wasn't there. I did a global search on the
documentation, but the search was case sensitive.  In the docs, the word
is mixed case.

> (fwiw, you may need to refresh your browser's cache before revisiting the wiki's
> 'Reference:Keywords' page)

I searched on my local installation, not on the wiki.

Post a reply to this message

hi,

Cousin Ricky <ric### [at] yahoocom> wrote:
> On 2026-01-05 02:46 (-4), jr wrote:
> > ...
> > to use, add the this to your (global) 'povray.ini' file:
> >
> >   include_header = /path/to/defaults.inc
> > ...
> This would defeat what I had in mind for the file.  The file would be
> referenced by textures.inc, metals.inc, etc., but if the user wants
> different defaults, they need to be #declared *before* these other files
> are #included.

that is exactly what happens, the declarations in 'defaults.inc' are then
available in the scene, and all its includes.


> This is not a problem with the file as I posted it, but I was going to
> post a new version of defaults.inc that set assumed_gamma and #default
> finish automatically, to save the user a bit of redundancy.  If used via
> 'Include_Header', the global settings and #defaults would be set before
> the scene file has a chance to tell it otherwise.

ah, here we "part company" :-), I do not think _setting_ any values (in advance)
will actually be helpful.  likely I misunderstood yr intent, I thought the file
should allow having one or more "sensible" pre-declared values, one of which
I/user can then use.


> ...
> Where is Bald Eagle?  I'm sure he has some good input.

hope he's getting some rest </griin>.


regards, jr.

Post a reply to this message

"jr" <cre### [at] gmailcom> wrote:

> ah, here we "part company" :-), I do not think _setting_ any values (in advance)
> will actually be helpful.  likely I misunderstood yr intent, I thought the file
> should allow having one or more "sensible" pre-declared values, one of which
> I/user can then use.

I haven't had a chance to look through the wiki on this one - something new to
me.

The best thing I can think of to do presently is write out a little pseudo scene
file with pseudo code and comments that shows the code flow and what happens vs
what is desired.

I'm thinking that flags and conditionals might help.

> > Where is Bald Eagle?  I'm sure he has some good input.
>
> hope he's getting some rest </griin>.

Au contraire - I'm likely running full-bore every day this week.
Maybe I'll get a chance to look this over during the day and so have something
substantive, and perhaps even something helpful to say.

- BE

Post a reply to this message

I had a bit of time to re-read the whole thread after second coffee kicked in.
Below find Richard's discussion, and my labeled comments.
I don't regularly use ini files or command line flags, so this can likely be
supplemented by jr, who is much more well-versed in their implementation.

There are gaps in SDL's ability to query the state of the render, and
one of these is the default finish.  This is a problem for defining
certain library textures when radiosity is not used, as include files
have no access to the scene's lighting conditions.  This is the case
with several of the standard include files.

BE: Well, our inability to query any number of things is a crippling
disadvantage that requires workarounds, such as assigning values to
variable in SDL and then passing those into the definitions of scene
objects such as is done with the camera in screen.inc

But what about a texture that is, say, half metallic?  In that case, the
diffuse and ambient need to be halved.  But halved from what?  While it
is possible to override a finish ambient, I feel it is an unreasonable
burden on the user to have them figure out what ambient is appropriate
for each library texture.

BE: I would agree, and further comment about many unreasonable burdens that
are borne by the users.

The solution I used for RC3Metal was to have the user declare variables
with the scene's default ambient and diffuse.  But to implement this
solution over many include files would cumbersome for the user.  These
standard include files all set non-zero ambients on declared textures:
  glass_old.inc
  golds.inc
  metals.inc
  stones1.inc
  stones2.inc
  textures.inc

(Files finish.inc, skies.inc, and stars.inc also set non-zero ambients,
but these should really be converted to emission.)

One way to solve this would be to declare a single pair of variables
that would be used by all six include files.  Third party include files
would be encouraged to access these variables.  What do you think of
this proposal?  Does anyone have a better idea?

BE:  I think that it's time for a lot of these files to be rewritten,
both in form and substance.  I might suggest a standard
"Distribution_Standard_Defaults.inc" that:
1. gets checked for by any include file seeking to use the values therein.
Sanity checks and guards can be used in case the file is corrupt or missing.

2. It would be wise to allow the user to set values that can either be
overwritten
by the include file, or vise-versa.  Setting the actual value and then invoking
the
include file would overwrite the previous user-declared values, and setting a
Identifier_Override identifier to the value would keep the value in place.
writing a macro in "Distribution_Standard_Defaults.inc" to update values would
allow
the obvious updating of the value hierarchy.

3. As I have suggested before, "Distribution_Standard_Defaults.inc" ought to be
a sort of proxy
that includes the actual include file used, which is the latest
semantic-versioning include file.
That way a versioning history can be internally and automatically maintained,
and upgrading to the latest
include file version is as simple as adding the new include file to the
directory and pasting the filename into
"Distribution_Standard_Defaults.inc"
(The reasoning here is that all dependent files just use the proxy name, and so
don't need to be edited in any way. The proxy include file then acts as a
pointer to the latest version of the "real" include file)

The texture files can then be rewritten to use default values, dictionaries, etc
to construct the texture.
I would suggest that the textures be rewritten as macros, so that the user can
invoke them with different arguments if desired, and then the last section of
the include file just runs all of the macros to set the default textures.

These sorts of problems, workarounds, and solutions should be able to be used as
a template for 4.0 parser and source code to avoid and/or handle these problems
within the distribution.

In the absence of a primary developer, or dev group, I believe that the most
efficient way forward will be to construct a fully parallel "distribution"
package that we current active users develop, maintain, and USE, so that we can
iron all of this out and have it fully implemented once active development on
4.0 resumes.


- BE

Post a reply to this message

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

> What do you all think of the attached file?

I do believe that your opening #ifndef is missing a closing #end.
I also prefer really well-defined indentation and opening and closing
#directive #end, ( ), { } pairs, so that debugging is vastly easier.

(I actually have a very long list of preferences that clash with jr and TOK
(tabs), but I also recall that a sort of developer style guide with respect for
writing source code exists.)

> Are there any other variables we can add?

Perhaps.  However my mind is presently suggesting that many functions or macros
that should be inbuilt keywords ought to be included. (sgn, etc)

I can post my ideas and preferences if you like - either here or in a separate
thread so you can ponder their value.

Until then - off to sort my morning 300 pages.

- BE

Post a reply to this message

"Bald Eagle" <cre### [at] netscapenet> wrote:

> I can post my ideas and preferences if you like - either here or in a separate
> thread so you can ponder their value.

Let's just go with "sure, Bill, you do that."  ;)

Here's my saved preferences for having AI write SDL.
These are for clarity, ease of reading, to facilitate any future debugging, and
also as a pseudo-typing notation in case we go that route with 4.0
Some of it is obvious to us, but needed to be specified because AI seems to mix
& match SDL and c++ syntax and structures.



General Syntax & Formatting

Use tabs for indentation.
Directives (#if, #for, #declare) should be on their own lines.
Internal lines of macros, loops, and CSG should be indented with tabs.
Arguments and vector components separated with leading spaces.
Decimal values should have leading zeros (e.g., 0.5 instead of .5).
Spaces around operators (+, -, *, =, , >).
Extra space after directives before parentheses, no inner padding inside () or
<>.
Fixed decimal places across a block.
Leading space before positive numbers for sign alignment.
Compact formatting: space after keywords before {, no space after {.
End every code block with // ***end of code***.
Avoid lowercase identifiers (reserved keywords); prefix identifiers by type:

S_ for scalar
V_ for vector
A1D_ for 1D array
A2D_ for 2D array


Control Structures

Prefer #for loops over #while.
Loop bounds should reflect 0-based arrays: #for (i, 0, ArraySize-1).
Use #if (A = B) instead of #if (A == B).
Avoid ternary for text values; use #if/#else/#end instead.
When ternary is allowed, enclose in parentheses: (A ? B : C).


Math & Functions

Use mod(A, B) instead of % or frac.
Use bitwise_or(A, B) instead of A | B.
Use * for multiplication.
Functions must be strictly mathematical (no multiline logic, no
#declare/#local).
Function argument names must be unique and prefixed with FnPar_.
Avoid dot operators in functions; predeclare components if needed.
Use select() instead of ternary in VM functions.
Vector math: use vcross, vdot, vlength in macros only (not in functions).


Scene & Object Rules

Camera positioned on -z axis looking toward +z.
Use left-handed coordinate system: x → right, y → up, z →
forward.
Use rgb instead of deprecated color.
Prefer specular highlights over phong.
Transforms must output transform{...} wrapper.
Include transforms.inc before using vtransform().
Avoid wrapping multi-object macros in object{}; use union{} for single-object
wrapping.
Pigment syntax: pigment {object {ObjectName rgb rgb}} (omit comma).
Pigment functions: function {PigmentName} without arguments.


Data Structures

Empty array syntax: #declare Array = array; (not array[0]).
Use proper spline/function pattern:

#declare SPL = spline{...};
#declare F_SPL = function{SPL}.


Built-in spline keywords aren’t splines; can’t be used in functions or macro
arguments.


Macros

Identifiers assigned inside macros must use #local.
Do not #declare then #local the same identifier.
Macros should not take a named output parameter; return expression and assign
externally.
Separate arguments for macros, loops, and calls.


- BE

Post a reply to this message

"Bald Eagle" <cre### [at] netscapenet> wrote:

> > Are there any other variables we can add?

I believe there was some discussion about making tau available even if v3.8
wasn't being used.

Euler's number e

not_0 = 1/256; // for use in rgb values

Recently we explored val () in terms of accessing NAN and INF.
Perhaps have variables with these values predefined.

With regard to "epsilon", it might be useful at this juncture to differentiate
between all the various different small values.
There are several hard-coded limits in source, and those "epsilons" ought to be
be named. "Coincident_Epsilon", etc.
A mathematical Epsilon might be defined as the smallest possible value able to
be reliably represented by floating point across multiple systems.

And, following that, perhaps name some variable to represent the largest value.

Phi

phi

golden angle


Also, upon editing your file, I discovered (as I suspected but lazily dismissed
- throttle was engaged but steering was not) that your file is structured
properly and your final #end is the proper closing directive.


While only tangentially related, it might be worth discussing elsewhere what
constants, functions, transforms, etc we would like to see in case folks want a
nice library of such things to be readily available.

Hopefully when I get some free time and am in one of those manic phases, I can
edit my wiki page to list such things and have links to actual files.

Edited version attached.

- BE

Post a reply to this message

Attachments:
Download 'defaults.inc.txt' (2 KB)

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.

> given the name and the purpose[*] of the file, I tried using 'include_header' to
> load it.  it seems that for the system-wide 'povray.ini' that keyword won't
> work.  for my personal file (~/.povray/3.8.povray.ini) I needed to add a
> '#version version;' line to 'defaults.inc', before the guard, to avoid the 'as
> of version 3.7' error message.
> 
> [*] I am looking at it not as the first include in other include files but as an
> "always load", ideally.

I was thinking of this sort of construction in the scene description file:

---%<-----%<-----%<-----%<---[BEGIN CODE]---%<-----%<-----%<-----%<---
#declare Default_Ambient = rgb 0.05;
#declare Default_Diffuse = 0.8;
#declare Default_Gamma = 1.8; // I wouldn't, but some might ;)

#default
{ finish
  { ambient Defaults_Ambient
    diffuse Defaults_Diffuse
  }
}
global_settings { assumed_gamma Defaults_Gamma }

#include "textures.inc"
#include "metals.inc"
#include "golds.inc"
#include "androidrobot.inc"
--->%----->%----->%----->%----[END CODE]---->%----->%----->%----->%---

This would work with or without an "always load"; the other include
files could just test for the identifiers in default.inc, and if they're
not defined, the include file could just assume the POV-Ray defaults.

But I had the thought that those #default and assumed_gamma statements
look kinda redundant.  It would be cleaner if those statements were
incorporated into defaults.inc; but with that scheme, an "always load"
wouldn't work, because the scene file would not have the chance to
#declare the default identifiers in advance.

As for '#version version;', the fundamental problem I have with this
construct is that it leaves no indication which version of POV-Ray the
scene file or include file is intended for.

Post a reply to this message

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.

I were to interpret this,  I would say that after installing POV-Ray, we might
all agree to use Lucid_sans_unicode.ttf as our default font, and then the
default.inc file would run a check to see if that font existed, and if not, then
default to one of the inbuilt fonts.  Then default_font could be used as an
identifier in EVERY text {} object as the default, rather than specifying a
specific font filename.
Then if the default were changed, it could be done in that one place in the
default.inc file.


> I was thinking of this sort of construction in the scene description file:
>
> ---%<-----%<-----%<-----%<---[BEGIN CODE]---%<-----%<-----%<-----%<---
> #declare Default_Ambient = rgb 0.05;
> #declare Default_Diffuse = 0.8;
> #declare Default_Gamma = 1.8; // I wouldn't, but some might ;)
>
> #default
> { finish
>   { ambient Defaults_Ambient // Default_Ambient (no s)
>     diffuse Defaults_Diffuse // Default_Diffuse (no s)
>   }
> }
> global_settings { assumed_gamma Defaults_Gamma } // Default_Gamma (no s)
>
> #include "textures.inc"
> #include "metals.inc"
> #include "golds.inc"
> #include "androidrobot.inc"
> --->%----->%----->%----->%----[END CODE]---->%----->%----->%----->%---
>
> This would work with or without an "always load"; the other include
> files could just test for the identifiers in default.inc, and if they're
> not defined, the include file could just assume the POV-Ray defaults.
>
> But I had the thought that those #default and assumed_gamma statements
> look kinda redundant.  It would be cleaner if those statements were
> incorporated into defaults.inc; but with that scheme, an "always load"
> wouldn't work, because the scene file would not have the chance to
> #declare the default identifiers in advance.


The always-load would just declare those identifiers.
Any declarations in the scene would overwrite them.
What about Default_Ambient () as a macro, saving the typing of #declare, and it
could even call Default_Finish () to redeclare the default.
you could do the same with diffuse and gamma

> As for '#version version;', the fundamental problem I have with this
> construct is that it leaves no indication which version of POV-Ray the
> scene file or include file is intended for.

Well, there are comments,
but also, you could write a Version () macro that took two arguments, the
current version, and the intended version, and then you'd have a wide latitude
for what happens after that.

In fact, I'm thinking that a lot of the directives could be recast as
(capitalized) macros that do a lot of sanity checking and special handling.  As
a macro, we could internally document the use of the directive and guard against
any recurrent newbie (ab)uses.

It would be a great way to embed all of our accumulated knowledge into a
parallel system of commands that would be didactic/pedagogical,
self-documenting, and only a bit slower for most small, static scenes.

- BE

Post a reply to this message

hi,

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 am looking at it not as the first include in other include files but as an
> > "always load", ideally.
> I was thinking of this sort of construction in the scene description file:
>
> ---%<-----%<-----%<-----%<---[BEGIN CODE]---%<-----%<-----%<-----%<---
> #declare Default_Ambient = rgb 0.05;

won't fly.  '#version' has to be first.


> ...
> As for '#version version;', the fundamental problem I have with this
> construct is that it leaves no indication which version of POV-Ray the
> scene file or include file is intended for.

in the 'defaults.inc' example that line comes before the guard, needed to avoid
an error.  the version required by the code (for includes) is inside the guard.
for scene files (I guess) there'd be no difference.


regards, jr.

Post a reply to this message

hi,

"Bald Eagle" <cre### [at] netscapenet> wrote:
> ...
> In fact, I'm thinking that a lot of the directives could be recast as
> (capitalized) macros that do a lot of sanity checking and special handling.  As
> a macro, we could internally document the use of the directive and guard against
> any recurrent newbie (ab)uses.
>
> It would be a great way to embed all of our accumulated knowledge into a
> parallel system of commands that would be didactic/pedagogical,
> self-documenting, and only a bit slower for most small, static scenes.

v nice idea.  "self-documenting" - exactly, I like that.


regards, jr.

Post a reply to this message

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
Here’s how the version setting behaves across POV-Ray versions, both when
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]
POV-Ray 3.5–3.6: Defaults to 3.5 in the absence of an explicit directive
[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
(+MVn.n) is used, it falls back to “legacy defaults” — effectively defaulting to
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:
Plain Textpov isn’t fully supported. Syntax highlighting is based on Plain
Text.#local Temp_Vers = version; // Save current version#version 1.0;… //
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.1    3.1    Enables version-specific behavior, semicolon required
3.5–3.6    3.5    Enables newer features or retains older ones via dropping
3.7    3.62 (warning if omitted) Required to access 3.7+ behavior; else legacy
defaults used
≥ 3.8    3.62 (via legacy fallback) Enables full modern syntax and
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