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}.



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