povray.beta-test message digest

[Bald Eagle] Re: v3.8b2. height_field input values at 0.0 not... [14 days 15 hours and 58 minutes ago]

Wed, 25 Mar 2026 15:55:00 GMT

And actually, there seems to be some potentially conflicting information in the
documentation.

https://wiki.povray.org/content/Documentation:Tutorial_Section_2.2
"For every position in POV-space, a pattern returns a float value in the range
from zero to one. Values outside the zero to one range are ignored."

Presumably if a pigment pattern was wrapped in a function, one could then have
access to the actual values emitted, and either graph them or just run tests to
detect the presence of values <0 or >1.

- BE

[Bald Eagle] Re: v3.8b2. height_field input values at 0.0 not... [14 days 16 hours and 8 minutes ago]

Wed, 25 Mar 2026 15:45:00 GMT

William F Pokorny <ano### [at] anonymousorg> wrote:

> Perhaps worth saying a little more than the above. Whether creating a
> height_field or internal image_map from a function in POV-Ray, any
> 'function return' values outside the [0-1] get 'wrapped' to a ramp wave
> as is the default with the majority of inbuilt patterns.
>
> So, function return values of:
> -0.1 --> 0.9
> -0.5 --> 0.5
> -0.9 --> 0.1.
> 1.1 --> 0.1
> 1.5 --> 0.5
> 1.9 --> 0.9

I will just point out that this is not currently documented anywhere.
https://wiki.povray.org/content/Reference:Maps
is blank.

If anyone wanted a quick 10-15 min project, writing a scene with a simple 0 --->
x color map and a loop, function, gradient pigment, or similar and showing that
the color_map value.x is modulo-wrapped would be great.
Numeric output via #debufg or file, or a graph showing Color.x would be nice.

- BE

[Bald Eagle] Re: Ambient and diffuse for include files? [85 days 18 hours and 43 minutes ago]

Tue, 13 Jan 2026 13:10:00 GMT

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

[Mr] Demo POV +RTR at a "real time" SIGGRAPH thematic... [86 days 16 hours and 33 minutes ago]

Mon, 12 Jan 2026 15:20:00 GMT

Hi !
I noticed the Chair persons of this event
https://s2026.siggraph.org/program/real-time-live/
....made an online call for applicants who want to give talks to their 2026
edition. 

It would be so great if someone could show the world that POV is not dead and no
matter how "alpha", the '+RTR' command line option could be an incentive to
apply... Is anyone who has ever managed to get this feature to work close enough
to give a try?

If so, any application should occur before Tue, 7 April 2026
22:00 +00:00 GMT:
https://ssl.linklings.net/conferences/siggraph/

[jr] Re: Ambient and diffuse for include files? [89 days and 18 minutes ago]

Sat, 10 Jan 2026 07:35:00 GMT

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.

[Bald Eagle] Re: Ambient and diffuse for include files? [89 days 5 hours and 38 minutes ago]

Sat, 10 Jan 2026 02:15:00 GMT

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

[Cousin Ricky] Re: Ambient and diffuse for include files? [89 days 6 hours and 13 minutes ago]

Sat, 10 Jan 2026 01:40:09 GMT

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.

[jr] Re: Ambient and diffuse for include files? [91 days and 53 minutes ago]

Thu, 8 Jan 2026 07:00:00 GMT

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.

[Bald Eagle] Re: Ambient and diffuse for include files? [91 days 14 hours and 3 minutes ago]

Wed, 7 Jan 2026 17:50:00 GMT

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.

[Cousin Ricky] Re: Ambient and diffuse for include files? [92 days 4 hours and 15 minutes ago]

Wed, 7 Jan 2026 03:38:09 GMT

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;'.

[jr] Re: Ambient and diffuse for include files? [92 days 13 hours and 43 minutes ago]

Tue, 6 Jan 2026 18:10:00 GMT

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.

[jr] Re: Ambient and diffuse for include files? [92 days 13 hours and 58 minutes ago]

Tue, 6 Jan 2026 17:55:00 GMT

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.

[Bald Eagle] Re: Ambient and diffuse for include files? [92 days 14 hours and 23 minutes ago]

Tue, 6 Jan 2026 17:30:00 GMT

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

[Cousin Ricky] Re: Ambient and diffuse for include files? [92 days 16 hours and 39 minutes ago]

Tue, 6 Jan 2026 15:13:52 GMT

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.

[Bald Eagle] Re: Ambient and diffuse for include files? [92 days 16 hours and 43 minutes ago]

Tue, 6 Jan 2026 15:10:00 GMT

"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

[Bald Eagle] Re: Ambient and diffuse for include files? [92 days 17 hours and 28 minutes ago]

Tue, 6 Jan 2026 14:25:00 GMT

"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

[Bald Eagle] Re: Ambient and diffuse for include files? [92 days 17 hours and 58 minutes ago]

Tue, 6 Jan 2026 13:55:00 GMT

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

[Bald Eagle] Re: Ambient and diffuse for include files? [92 days 18 hours and 8 minutes ago]

Tue, 6 Jan 2026 13:45:00 GMT

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

[Bald Eagle] Re: Ambient and diffuse for include files? [92 days 20 hours and 23 minutes ago]

Tue, 6 Jan 2026 11:30:00 GMT

"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

[jr] Re: Ambient and diffuse for include files? [93 days and 3 minutes ago]

Tue, 6 Jan 2026 07:50:00 GMT

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.

[Cousin Ricky] Re: Ambient and diffuse for include files? [93 days 3 hours and 17 minutes ago]

Tue, 6 Jan 2026 04:36:32 GMT

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.

[jr] Re: Ambient and diffuse for include files? [94 days 1 hour and 3 minutes ago]

Mon, 5 Jan 2026 06:50:00 GMT

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.

[Cousin Ricky] Re: Ambient and diffuse for include files? [94 days 7 hours and 36 minutes ago]

Mon, 5 Jan 2026 00:17:20 GMT

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?

[jr] Re: Ambient and diffuse for include files? [101 days 19 hours and 38 minutes ago]

Sun, 28 Dec 2025 12:15:00 GMT

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

[jr] Re: Ambient and diffuse for include files? [101 days 21 hours and 53 minutes ago]

Sun, 28 Dec 2025 10:00:00 GMT

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.

[Cousin Ricky] Re: Ambient and diffuse for include files? [110 days 6 hours and 39 minutes ago]

Sat, 20 Dec 2025 01:14:24 GMT

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

[jr] Re: Version 3.8, status? [174 days 17 hours and 18 minutes ago]

Thu, 16 Oct 2025 14:35:00 GMT

hi,

"Paul Bourke" <pau### [at] gmailcom> wrote:
> I'm using POV-Ray 3.8.0-beta.2.unofficial, compiled by myself on MacOS from the
> corresponding povunix-*-src.tar.gz

ok.  no idea re "MacOS".  where did you get the source,
<github.com/POV-Ray/povray/tags> ?  and, './configure' etc details, please.

regards, jr.

[Paul Bourke] Re: Version 3.8, status? [175 days and 28 minutes ago]

Thu, 16 Oct 2025 07:25:00 GMT

> using a (self-compiled) beta.2, both those options work, from ini and from the
> command line

I'm using POV-Ray 3.8.0-beta.2.unofficial, compiled by myself on MacOS from the
corresponding povunix-*-src.tar.gz

[Chris Cason] Re: Version 3.8, status? [176 days 18 hours and 9 minutes ago]

Tue, 14 Oct 2025 13:43:53 GMT

On 15/10/2025 00:26, Bald Eagle wrote:
> "Paul Bourke" <pau### [at] gmailcom> wrote:
>> Hope I didn't miss this somehow, but can I ask where I find the status of
>> version 3.8?
> 
> You, fine Sir, are looking at it.
> 
>> I've started using the current beta but since it's for a long term
>> project I would like to know what the future might hold.
> 
> And in that respect, you join us all.
> I have posted very many times about the need to attract new users and advertise
> wherever we might for people to help further develop this open-source project.
> 
> At present, it seems that just myself, and mostly William F Pokorny are
> investigating various parts of the source code to better understand, comment,
> and hopefully improve upon the extant code base.
> 
> I think that working out various functions, diagramming out the geometry,
> documenting the math with publicly-accessible references, and clearly commenting
> the code would be an excellent project for undergraduate (and graduate) students
> in math and computer science, and help provide a solid entry point for further
> development efforts.  Though the contributions may seem small, they do indeed
> add up over time.
> 
> 
>> For example, there seem to be some command line switches missing, like +sf and
>> +ef. Have they been dropped, is there a different way to implement animation
>> subsets, any documentation?
> 
> I see that jr has addressed these concerns.

I have some ideas that will hopefully get us out of the beta rut, though they are more
long-term than finishing what Clipka left right now.

Keep an eye on this thread as it seems a good place to post updates on this topic.

regards,

-- Chris

[Bald Eagle] Re: Version 3.8, status? [176 days 18 hours and 23 minutes ago]

Tue, 14 Oct 2025 13:30:00 GMT

"Paul Bourke" <pau### [at] gmailcom> wrote:
> Hope I didn't miss this somehow, but can I ask where I find the status of
> version 3.8?

You, fine Sir, are looking at it.

> I've started using the current beta but since it's for a long term
> project I would like to know what the future might hold.

And in that respect, you join us all.
I have posted very many times about the need to attract new users and advertise
wherever we might for people to help further develop this open-source project.

At present, it seems that just myself, and mostly William F Pokorny are
investigating various parts of the source code to better understand, comment,
and hopefully improve upon the extant code base.

I think that working out various functions, diagramming out the geometry,
documenting the math with publicly-accessible references, and clearly commenting
the code would be an excellent project for undergraduate (and graduate) students
in math and computer science, and help provide a solid entry point for further
development efforts.  Though the contributions may seem small, they do indeed
add up over time.

> For example, there seem to be some command line switches missing, like +sf and
> +ef. Have they been dropped, is there a different way to implement animation
> subsets, any documentation?

I see that jr has addressed these concerns.

- BW

[jr] Re: Version 3.8, status? [176 days 20 hours and 13 minutes ago]

Tue, 14 Oct 2025 11:40:00 GMT

"jr" <cre### [at] gmailcom> wrote:
> "Paul Bourke" <pau### [at] gmailcom> wrote:
> > ...
> > For example, there seem to be some command line switches missing, like +sf and
> > +ef. Have they been dropped, is there a different way to implement animation
> > subsets, any documentation?
>
> was not aware those CLI options don't work, will try and find time to test here.

using a (self-compiled) beta.2, both those options work, from ini and from the
command line, eg using an animation copied and "rigged" for the test, I have
'initial_frame' and 'final_frame' as before, added the
'subset_(end|start)_frame' options, and ran that, and commented out out again:

  $ povray proj.ini
  $ povray proj.ini +sf0 +ef99

also, I "discovered" :-) the "partial output" options, and re-ran the above with
those options added, ie

  $ povray proj.ini +sf0 +ef99 +sr0.25 +sc0.25 +er0.75 +ec0.75

and got the results I expected reading the docs.

wondering what, if any, of the configuration options used might come "into
play".  if you have no luck with command line and or ini, can you please post
your build details ?

> Hope I didn't miss this somehow, but can I ask where I find the status of
> version 3.8? I've started using the current beta but since it's for a long term
> project I would like to know what the future might hold.

some months ago, now, Chris Cason posted about intentions of bringing 3.8 out of
the beta stage.  there are .. intermittent discussions here in the NGs
concerning development, the lack of, rather.  wrt long-term, I'd expect the
features in the beta.2 to all continue to be available.

regards, jr.

[jr] Re: Version 3.8, status? [177 days and 53 minutes ago]

Tue, 14 Oct 2025 07:00:00 GMT

hi,

"Paul Bourke" <pau### [at] gmailcom> wrote:
> ...
> For example, there seem to be some command line switches missing, like +sf and
> +ef. Have they been dropped, is there a different way to implement animation
> subsets, any documentation?

was not aware those CLI options don't work, will try and find time to test here.
 different way - use .ini files, and there you can use keywords instead of
abbreviated options.  documentation - I usually start from
<wiki.povray.org/content/Reference:Keywords>.

regards, jr.

[Paul Bourke] Version 3.8, status? [177 days 1 hour and 3 minutes ago]

Tue, 14 Oct 2025 06:50:00 GMT

Hope I didn't miss this somehow, but can I ask where I find the status of
version 3.8? I've started using the current beta but since it's for a long term
project I would like to know what the future might hold.
For example, there seem to be some command line switches missing, like +sf and
+ef. Have they been dropped, is there a different way to implement animation
subsets, any documentation?

[William F Pokorny] Re: CSG Issues with disc shape. v38 beta 2. [180 days 11 hours and 56 minutes ago]

Fri, 10 Oct 2025 19:57:31 GMT

On 9/30/25 19:36, William F Pokorny wrote:
>> POV-Ray screwed me.
>>
>> "Unnecessary bounding object removed."
>>
>> Might be time to fix that or update the bounded_by documentation page.
>>
> 
> You can manually bound, if you use '-ur' / 'remove_bounds=off'.

Ugh! In looking more at bounded_by{} and clipped_by{} myself of late, I 
re-discovered / remembered - after thrashing a couple days - that 
official versions of POV-Ray have this weird 3D volume test which limits 
user specified bounding to that which is 'smaller' than the initial 
automatic bounding volume. The code just does this "I know better than 
the user bit," silently.

The yuqk fork removed the volume increase limiting code back in 2017. It 
was always a bad idea for reasons - not the least of which is that it 
often prevents users from working around automatic bounding which isn't 
working correctly.

So... I was too flippant with my initial response with respect to 
official releases of POV-Ray supporting manual bounding and +-ur / 
remove_bounds=. Manual bounding is at least somewhat broken / limited in 
recent official POV-Ray releases.

I'm working in yuqk mostly, and thousands of changes down the road, my 
old head doesn't remember everything different relative to official 
POV-Ray releases. I've been trying to get yuqk's documentation up to 
date - largely for my own sanity in helping me remember changes like 
these - but I'd not gotten to writing updated documentation for 
bounded_by{} and clipped_by{}. :-( FWIW.

There are other yuqk manual bounding differences too. Another of note, 
is that the official POV-Ray code will update bounding based upon the 
clipped_by{} shape(s) alone (or by overriding bounded_by{}). The yuqk 
fork only updates manual bounding based upon any bounded_by{} block(s)!

IIRC, using clipped_by{} to also manually bound was a v3.6 -> v3.7 
change. In any case manual, bounding sometimes needs to be slightly 
larger than any clipped_by{} specifications - we shouldn't be using 
clipped_by{} to set or update bounding.

Bill P.

[William F Pokorny] Re: CSG Issues with disc shape. v38 beta 2. [189 days 10 hours and 51 minutes ago]

Wed, 1 Oct 2025 21:02:26 GMT

On 9/30/25 20:41, Bald Eagle wrote:
>> We could then too use bounded_by{} to do much of what clipped_by{} can
>> do, but more efficiently.
> Why more efficiently?

Your question got me thinking - thanks. It's probably less often more 
efficient than I first thought.

The clipped_by{} process is something which runs after ray-surface 
intersections for the object being clipped are determined. Basically, it 
runs one or more shape inside tests for each surface intersection. Those 
found inside are kept, those not are ignored. The inside tests are not 
free to calculate - and they bypass the higher level generic bounding so 
the inside test often get run more than strictly necessary.

What had in mind was something like the sphere solid-not-solid example 
using a difference as a stand in for clipped_by{} where the disc was out 
of scope bounding wise. We'd use only the 'inverse' inside test - within 
the bounding box. Unlike that solid-not-solid example, the inside test 
cost close to nothing - higher compiler optimization levels should 
eliminate even the method / function call.

On letting your question bang around in my skull for a while I had the 
thought - well Bill P, you could just use the inverted disc as the 
clippped_by{} shape. In that case the inside test itself would be faster 
because it is always false. We'd still be losing out on the high level 
bounding by using clipped_by{}.

---

Related. What I'm starting to think a lot about, is trying out some 
no-surfaces-ever / inside-test-only 'non-shapes' as another class of 
objects we could use in CSG operations.

In POV-Ray proper we have the object{} pattern. (In yuqk the object{} 
pattern has been renamed bool_object{} and about a half dozen additional 
forms like dens_object, list_object{} patterns have been added.)

I 'think' there is nothing stopping us from using what are effectively 
scalar value fields (value patterns) as inside tests that can be bounded 
and used more or less 'directly' in CSG to select / ignore portions of 
surfaces. Those CSG surface results could then have spatial object 
modifiers applied, for example, in addition to specific texturing.

---

I saw your suggestion about creating some how to object documentation... 
I think clipka did something like this in a post for what is more or 
less obvious as necessary functions / methods by looking at something 
like disc.cpp. In support of any object is dedicated parsing code for 
the supporting SDL.

It's complicated beyond that rough outline. What you've been doing with 
trying to pull back the layers with the sor{} implementation is just 
what one has to do - pretty much shape by shape because they are all 
implemented somewhat differently.

Maybe, if I do get to trying on or more 'non-shapes' / 'insider'(s), I 
can keep a rough log of what I did to implement one. No promises.

Bill P.

[Bald Eagle] Re: CSG Issues with disc shape. v38 beta 2. [190 days 7 hours and 8 minutes ago]

Wed, 1 Oct 2025 00:45:00 GMT

William F Pokorny <ano### [at] anonymousorg> wrote:

> So... We have in the code two slightly different ways to set up patch
> like objects. Why? Why? Why! you ask.

Why, Bill?  :D

> "Parse Warning:
> Patch object used in difference{} or intersection{} block. If a mesh{}
> or mesh2{} shape consider defining an 'inside_vector' to enable inside
> testing."

That's like one of the best POV-Ray warning messages I've ever read.  :)

> We could then too use bounded_by{} to do much of what clipped_by{} can
> do, but more efficiently.

Why more efficiently?

> The obvious downside, I think, is the behavior is less intuitive /
> obvious to users (me included). Thoughts?

Well, that depends on the documentation and examples provided, right?
I'm sure that given everything that gets learned, all of that should be
documented/preserved in a directory specific to that object type.
Scene files, comments, and supplementary documentation files are cheap - but the
preservation of the insights and lessons are invaluable.
Detailed diagrams and even animations are cheaply stored in the distro as .pov
and .ini files.

> In any case, all has me leaning even more toward changing the default in
> V4.0 to preserving user specified bounding as the default. These days,
> mostly, there is only auto-bounding in scenes. Where a user specifies
> bounded_by{} he probably wants to use that bounding.

We would assume so, yes.

Now that you're that deep into the code for disc, which is a simple object,
could you at some point help a few of us POV-bros out and give a general layout
of how POV-Ray .h and .cpp files go about "making" the object?

Perhaps in a dedicated thread?

The faster I'm able to learn to navigate my way through one object, the easier
the rest of them will be.  Even I can't start writing various bug fixes and
features from scratch, I can at least start writing up good, accurate, and truly
helpful documentation and diagrams.

-----

Hugely tangentially related, have you thought about using that as a test object
(simple normal code) for developing things like surface normal pigment
functions, directional gradient pigment functions, and surface curvature pigment
functions?
Applying that to a sphere would allow anisotropic scaling to then start to
really test those out.  I'm sure even mistakes would yield interesting results.

- BW

[William F Pokorny] Re: CSG Issues with disc shape. v38 beta 2. [190 days 8 hours and 16 minutes ago]

Tue, 30 Sep 2025 23:36:57 GMT

On 9/25/25 18:52, Bald Eagle wrote:
> "Bald Eagle" <cre### [at] netscapenet> wrote:
> 
>> Have you tried manually bounding the cones with a cylinder using the max
>> (abs(r1), abs(r2)) in SDL?
> 
> POV-Ray screwed me.
> 
> "Unnecessary bounding object removed."
> 
> Might be time to fix that or update the bounded_by documentation page.
> 

You can manually bound, if you use '-ur' / 'remove_bounds=off'.

The '-b' option turns off all general object bounding(*) in the yuqk 
fork. It turns off most, but not all, of that same general bounding in 
v3.7 and v3.8 versions of POV-Ray.

Bill P.

(*) - Bounding methods 1 (slab) and 2 (bsp).

Beyond that bounding, some shapes like blob{} and mesh{} / mesh2{} have 
internal bounding which can sometimes (always?) be turned off with the 
SDL 'hierarchy off' object modifier; Some shapes - like the sor{} - have 
internal bounding that is always there; Some shapes always use a 
contained_by{} shape which both determines bounds and can become part of 
the overall result - a little like a, tucked in the shape, 
intersection{}.

[William F Pokorny] Re: CSG Issues with disc shape. v38 beta 2. [190 days 8 hours and 26 minutes ago]

Tue, 30 Sep 2025 23:27:14 GMT

On 9/24/25 15:07, William F Pokorny wrote:
> In yuqk I'm leaning heavily toward changing the disc{} to a patch object 
> with an inside test that always returns false. To fix it, I suspect I'd 
> have add internal dual cylinder bounding, but cost wise this will be not 
> much different than a CSG difference with two cylinders...

Alright. In yuqk I've turned the disc{} shape into a shape like 
polygon{} having an inside test which always returns false.

---

What I learned is that the polygon{} shape - and now the disc{} shape 
too - are not PATCH_OBJECT type shapes internally, but rather 
BASIC_OBJECT types also using that NonsolidObject class.

I'd earlier missed that the NonsolidObject class overrides the Invert() 
method in the base object class in a way that turns the object modifier 
'inverse' method into a No-OP (disables 'inverse').

So... We have in the code two slightly different ways to set up patch 
like objects. Why? Why? Why! you ask.

The only effective difference I see at the moment is that when the 
patch-like shape is set up as a PATCH_OBJECT type we get warnings we 
don't get when the patch-like shape is set up as a BASIC_OBJECT type. 
Specifically:

   "Parse Warning: Patch objects not allowed in intersection."

and

   "Cannot invert a patch object."

In yuqk, I've changed that first warning so that it is only active for 
yuqk's debug compile because I don't see much value in it - we can do 
those sorts of intersections. Further, I changed the debug compile 
warning message so that it now reads:

"Parse Warning:
Patch object used in difference{} or intersection{} block. If a mesh{} 
or mesh2{} shape consider defining an 'inside_vector' to enable inside 
testing."

The second parse warning has - for release R20 - been moved to 
NonsolidObject::Invert() to generate warnings for all patch-like shapes 
no matter their being set up as BASIC_OBJECT or PATCH_OBJECT.

As for how all this patch-like stuff should ultimately be set up, I need 
think about it for a while (see aside below).

Bill P.

Aside
-----

Why not allow 'inverse' with more (all?) these patch-like 
(NonsolidObject) shapes? In some limited code play things look to work.

It flips the normals, which is useful where both texture{} and 
interior_texture are set up.

The inside region would be limited by the shape's bounding box where 
'inverse' is used.

We could then too use bounded_by{} to do much of what clipped_by{} can 
do, but more efficiently.

The obvious downside, I think, is the behavior is less intuitive / 
obvious to users (me included). Thoughts?

In any case, all has me leaning even more toward changing the default in 
V4.0 to preserving user specified bounding as the default. These days, 
mostly, there is only auto-bounding in scenes. Where a user specifies 
bounded_by{} he probably wants to use that bounding.

[Bald Eagle] Re: CSG Issues with disc shape. v38 beta 2. [195 days 8 hours and 58 minutes ago]

Thu, 25 Sep 2025 22:55:00 GMT

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

> Have you tried manually bounding the cones with a cylinder using the max
> (abs(r1), abs(r2)) in SDL?

POV-Ray screwed me.

"Unnecessary bounding object removed."

Might be time to fix that or update the bounded_by documentation page.

[Bald Eagle] Re: CSG Issues with disc shape. v38 beta 2. [195 days 13 hours and 3 minutes ago]

Thu, 25 Sep 2025 18:50:00 GMT

William F Pokorny <ano### [at] anonymousorg> wrote:

> I took a few swings at fixes late last night, but no luck. I'm going to
> code up some parser checks to limit the radii to positive values only
> until I can come back to this issue with more focus.

I'm looking at the following

if (fabs(apex_radius - base_radius) < EPSILON)           // line 757

if (apex_radius < base_radius)                           // line 768

tmpf = base_radius * len / (apex_radius - base_radius);  // line 782

if (((apex_radius - base_radius)*len/tlen) < EPSILON)    // line 788

and wondering if those should should use fabs of each radius for the
calcs/comparisons

Just because I'm getting the impression that once one of the values crosses
zero, the differences sort of double-back on themselves, which might trigger
that whole

 /* What we are dealing with here is really a cylinder */

        Set_Flag(this, CYLINDER_FLAG);

        Compute_Cylinder_Data();

        return;

part, which might wind up clipping one side of the cone.
So it might be partially an algorithmic bug?

What bounding are you disabling in yuqk?
Is it stuff in
https://github.com/POV-Ray/povray/tree/master/source/core/bounding ?

Have you tried manually bounding the cones with a cylinder using the max
(abs(r1), abs(r2)) in SDL?  Curious if that would
a. work
and
b. be faster

- BW

[Bald Eagle] Re: CSG Issues with disc shape. v38 beta 2. [195 days 16 hours and 13 minutes ago]

Thu, 25 Sep 2025 15:40:00 GMT

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

> > Aside 2: clipka fixed something with the cone behavior (my memory
> > otherwise fails) in v3.8. I expect v3.7 cone behavior is different in
> > some aspect.

https://www.povray.org/beta/

--------------------------------------------
Changes between 3.7.beta.35 and 3.7.beta.35a
--------------------------------------------

Fixed an axis problem with cones.



And that's all I've found so far.
Haven't downloaded the 3.8 source to dig through that yet.   All I have is 3.7
stable.

- BW

[William F Pokorny] Re: CSG Issues with disc shape. v38 beta 2. [195 days 20 hours and 19 minutes ago]

Thu, 25 Sep 2025 11:34:39 GMT

On 9/24/25 19:26, Bald Eagle wrote:
> Looks like there's some kind of clipping going on with the bounding.

Yep, tried my '-b' yuqk flag and it fixes all the +- -+ cases in your 
test scene where bounding goes wrong(*). Thank you for posting it! :-)

I took a few swings at fixes late last night, but no luck. I'm going to 
code up some parser checks to limit the radii to positive values only 
until I can come back to this issue with more focus.

I have quite a bit yet to do to finish the sor{} changes in yuqk{} and 
that's only the most recent ball I've let hit the ground. :-)

Bill P.

(*) The render was slow without bounding!

[Bald Eagle] Cylinder / cone bounding [195 days 20 hours and 43 minutes ago]

Thu, 25 Sep 2025 11:10:00 GMT

Referencing
https://news.povray.org/povray.beta-test/message/%3Cweb.68d47e2be434b08f1f9dae3025979125%40news.povray.org%3E/#%3Cweb.6
8d47e2be434b08f1f9dae3025979125%40news.povray.org%3E

What we ought to have for every shape and it bounding scheme is something along
the lines of:

https://www.geometrictools.com/Documentation/IntersectionLineCone.pdf

So that we have our own POV-Ray "owned" copy of the theoretical and practical
development of the source code.

That way people can pick it up, get on track very quickly, and understand what,
why, and how.

The provision of clear, well labeled diagrams probably can't be overstated.

- BW

[Bald Eagle] Re: CSG Issues with disc shape. v38 beta 2. [196 days 8 hours and 23 minutes ago]

Wed, 24 Sep 2025 23:30:00 GMT

William F Pokorny <ano### [at] anonymousorg> wrote:

> Blast, it doesn't work for all +- values.  Let me see if I can figure
> out why not.

Whoa.  I did not expect that.
Looks like there's some kind of clipping going on with the bounding.

- bw


#version 3.8;
global_settings {
 assumed_gamma 1.0
}

#declare E = 0.000001;

#declare Zoom = 14; //60;
camera {
 orthographic
 location <0, 0, -10>
 right    x*image_width/Zoom
 up       y*image_height/Zoom
 look_at  <0, 0, 0>
}

light_source {<0, 0, -200> rgb 1}

sky_sphere {pigment {rgb 0}}

#declare XM = 25;
#declare YM = 25;

#for (Y, -1, 1, 0.1)
 #for (X, -1, 1, 0.1)

  cone {-x, Y, x, X
  texture {pigment {rgb <abs(X), abs(Y), abs(X+Y)>} finish {emission 0.2}}
  translate <X*XM, Y*YM, 0>
  }

 #end
#end

text { ttf "arial.ttf", "+r1, -r2", 0.02, 0.0 translate <-1.2*XM,  1*YM, 0>}
text { ttf "arial.ttf", "-r1, -r2", 0.02, 0.0 translate <-1.2*XM, -1*YM, 0>}
text { ttf "arial.ttf", "r1=0, -r2", 0.02, 0.0 translate <-1.2*XM, 0, 0>}
text { ttf "arial.ttf", "+r1, +r2", 0.02, 0.0 translate < 1.1*XM,  1*YM, 0>}
text { ttf "arial.ttf", "-r1, +r2", 0.02, 0.0 translate < 1.1*XM, -1*YM, 0>}
text { ttf "arial.ttf", "-r1, r2=0", 0.02, 0.0 translate <-3, -1.05*YM, 0>}

[William F Pokorny] Re: CSG Issues with disc shape. v38 beta 2. [196 days 9 hours and 1 minute ago]

Wed, 24 Sep 2025 22:52:07 GMT

On 9/24/25 18:12, William F Pokorny wrote:
>> What I meant, if you misunderstood, was to have one side be radius r, 
>> and the
>> other side be radius -r, so that it would make a "double-cone".
> 
> Ah, yes, the double cone looks to work fine.

Blast, it doesn't work for all +- values.  Let me see if I can figure 
out why not.

Started to look at allowing both values to be negative and in testing 
that potential change I found not all +- -+ radii values work for 
getting a double cone.

Saw your other post on normal changes. I've not seen that in v3.8+, but 
who knows. Maybe it worked at some point as you suggested.

Bill P.

[Bald Eagle] Re: CSG Issues with disc shape. v38 beta 2. [196 days 9 hours and 18 minutes ago]

Wed, 24 Sep 2025 22:35:00 GMT

William F Pokorny <ano### [at] anonymousorg> wrote:
> On 9/24/25 15:46, Bald Eagle wrote:
> > What I meant, if you misunderstood, was to have one side be radius r, and the
> > other side be radius -r, so that it would make a "double-cone".
>
> Ah, yes, the double cone looks to work fine.

Well...  sorta.

I was actually wondering if the normal flipped, which apparently it used to:

https://news.povray.org/povray.general/thread/%3Cweb.58228e15512a2627116828db0%40news.povray.org%3E/?mtop=412640

"Note : a cone can take a negative radius. In this case, you'll get a
double cone. You can try this :
cone{2*x, 2, -2*x, -2 pigment{rgb 1} inside_texture{pigment{rgb<0,0,1>}}}
Yes, the left part IS blue."

And that's why I think that allowing the negative radius should be kept, and
perhaps even enhanced. *

I tried searching for documentation instances for "negative radius" but didn't
find much - but I seem to remember notes to the effect that the normal would be
flipped.  torus?  sphere?

* What I'm currently thinking about is whether there should be some mechanism
for "inside-out" shapes to be functionally equivalent to _inverse_.
So maybe in regular mode, the negative radius just flips the normal, but perhaps
with an additional keyword, any inside-out part would actually be inverted.

Which also had me wondering what other shapes we can cleverly play with using
negative values.

- bw

[William F Pokorny] Re: CSG Issues with disc shape. v38 beta 2. [196 days 9 hours and 40 minutes ago]

Wed, 24 Sep 2025 22:12:50 GMT

On 9/24/25 15:46, Bald Eagle wrote:
> What I meant, if you misunderstood, was to have one side be radius r, and the
> other side be radius -r, so that it would make a "double-cone".

Ah, yes, the double cone looks to work fine.

On the cone fix all I could find was a fix Chris implemented for v3.7 
which wasn't in v3.6. For v3.8 there is some uv mapping stuff added and 
then removed by clipka where others were involved. So... It might just 
be my failing head getting things mixed up. :-)

Bill P.

[Bald Eagle] Re: CSG Issues with disc shape. v38 beta 2. [196 days 11 hours and 43 minutes ago]

Wed, 24 Sep 2025 20:10:00 GMT

William F Pokorny <ano### [at] anonymousorg> wrote:

> In yuqk I'm leaning heavily toward changing the disc{} to a patch object
> with an inside test that always returns false. To fix it, I suspect I'd
> have add internal dual cylinder bounding, but cost wise this will be not
> much different than a CSG difference with two cylinders...

I would say that that makes sense.
As I have discussed with jr, and perhaps brought up in other posts, I would like
to have default values for things like the disc radii and surface normal if they
are not provided.   That might be a parser thing in addition to a .cpp thing.

Useful would be a swept annulus - a tube {}
Simply because it seems to be a common shape and it can be cumbersome if one has
a lot of them to make - especially for a newbie.

One of the things that I have read about in CS courses, and elsewhere, is that
they have that "regularized Boolean" variant, which I think we could immensely
benefit from - given that it would get rid of the residual coincident surface
problem when doing differences.

Alternately, would be some hierarchical CSG logic, whereby the last object
specified in any given CSG operation takes precedence.  I guess it would be sort
of like a z-buffer for CSG.  It's also how I code differences in my editor - the
differencing objects get indented after the parent object.  So, in a coincident
surface contest, the parent object should always lose.

Getting better at reading and interpreting the source, though I don't see the
big picture in terms of information flow.

-bw

[Bald Eagle] Re: CSG Issues with disc shape. v38 beta 2. [196 days 12 hours and 3 minutes ago]

Wed, 24 Sep 2025 19:50:00 GMT

William F Pokorny <ano### [at] anonymousorg> wrote:

Nice renders.  These are a great starting point for a debugging toolkit, as well
as what could be some interesting extra documentation.

> Ah, I see the cone is doing something weird where the two radii are
> negative. We should probably just not allow negative radii arguments in
> the parser - for any shape.

What I meant, if you misunderstood, was to have one side be radius r, and the
other side be radius -r, so that it would make a "double-cone".

> Bill P.
>
> Aside 1: Long on my todo list is breaking apart the cylinder and cone
> code. Today it's all munged together making both slower and more complex
> than they need be.

clipka at one time said that the cylinder is just a cone with 2 equal end radii

> Aside 2: clipka fixed something with the cone behavior (my memory
> otherwise fails) in v3.8. I expect v3.7 cone behavior is different in
> some aspect.

It would be great if someone could hunt down the readme for 3.8 to see if that's
mentioned.  Are there any comments in source?

- bw

[William F Pokorny] Re: CSG Issues with disc shape. v38 beta 2. [196 days 12 hours and 45 minutes ago]

Wed, 24 Sep 2025 19:07:56 GMT

On 9/24/25 09:40, Bald Eagle wrote:
> So, I need to question the whole top row.
> I refer to the disc {} in its form with a hole using the mathematically accurate
> term "annulus".

I think the answer to most (all?) of your questions about the disc is 
the inside test is supposed to be equivalent to a plane{}'s inside test 
using the disc{}'s normal.

In yuqk I'm leaning heavily toward changing the disc{} to a patch object 
with an inside test that always returns false. To fix it, I suspect I'd 
have add internal dual cylinder bounding, but cost wise this will be not 
much different than a CSG difference with two cylinders...

FYI. You are correct the issue in v3.8 beta2 is bounding related. 
Attached an image rendered with yuqk using the '-b' flag to turn 
bounding off. The yuqk fork turns bounding 'completely' off with '-b' 
where v3.7 and v3.8 made code changes which pushed the last level of 
bounding for shapes outside the +-b flag's control(*). The yuqk fork has 
restored the v3.6 and prior behavior - and the restoration is certainly 
helpful here for debugging.

(*) - The change offered a performance optimization in some situations.

---

Ah, I see the cone is doing something weird where the two radii are 
negative. We should probably just not allow negative radii arguments in 
the parser - for any shape.

Bill P.

Aside 1: Long on my todo list is breaking apart the cylinder and cone 
code. Today it's all munged together making both slower and more complex 
than they need be.

Aside 2: clipka fixed something with the cone behavior (my memory 
otherwise fails) in v3.8. I expect v3.7 cone behavior is different in 
some aspect.

[Bald Eagle] Re: CSG Issues with disc shape. v38 beta 2. [196 days 18 hours and 8 minutes ago]

Wed, 24 Sep 2025 13:45:00 GMT

William F Pokorny <ano### [at] anonymousorg> wrote:

> The top row a disc{} is being intersected with a sphere{}. In the second
> row a roughly equivalent polygon{} is intersected in the same fashion.
>
> I believe the disc{} results are correct only in the second and last
> columns. The polygon row of intersections I believe is OK(*).

So, I need to question the whole top row.
I refer to the disc {} in its form with a hole using the mathematically accurate
term "annulus".

It's interesting that the annulus gets rendered with what appears to be a
bounding box with the sphere texture included.  I'm assuming that's part of the
erroneous behaviour - only the annulus ought to be rendered.

1. If column 2 and 5 both show the sphere, then why doesn't column 1 show the
lower part of the sphere?

(bounding boxes and perhaps some method of showing the inside () results of the
disc might help. VRandInObject or whatever it's called, or media)

2. Confused about why inverse shows so much of the sphere.
Does the disc act like a half-infinite cylinder?
Does inverse now cause it to be  NOT(half-infinite cylinder)?
Because even that doesn't seem like the correct result to me.

3. I guess it's wrong, but consistent with render 1.

4. perhaps this might be correct, if we're considering the disc/annulus to
technically have an inside () ?  Though I would expect for there to not be
anything, since the annulus surface is outside/tangent to the sphere

5.  No idea why you think that's correct, since there's now no overlap, unless
we're somehow considering the annulus to be some form of plane / half-space
object.  But then that leaves me confused about the rest of the renders in that
row.

I am in full agreement about the bottom row.

Suggest:
0. show bounding boxes and insidedness tests for the annulus.
1. apply an inside_texture to the sphere
2. use a sphere with a negative radius
3. use sphere {inverse}
4. use both inverse
5. make the major and minor radii of the annulus equal.

6. refer to my Boolean operations render, and see if that inspires any
additional experiments - my subconscious tells me that using that as a guide to
construct formalisms for what we're doing with objects and CSG (and using very
accurate, formal terminology apart from what we use in SDL) might help us
unravel what our less rigorous discussions may be hiding from us.

https://news.povray.org/povray.documentation.inbuilt/thread/%3Cweb.68573b7934ec28cb1f9dae3025979125%40news.povray.org%3
E/

"Since POV-Ray does not implement regularized Boolean operations (i.e., union,
intersection and difference are done as conventional set operations)"
(bottom of page)
https://pages.mtu.edu/~shene/COURSES/cs3621/LAB/povray/csg.html

P.S. As I was letting Second Coffee percolate into my blood stream this morning,
I was mixing thoughts about scene experiments, and I recently tried to render a
cone (a real, mathematical "double-cone") as an isosurface and had an issue,
until I reformulated how I was doing it to avoid division-by-zero.

Could you (someone) also render a cone {} with one radius positive, and the
other radius the unary inverse?  Use inside_texture and repeat CSG experiments.

Thanks,

- BW

[William F Pokorny] CSG Issues with disc shape. v38 beta 2. [196 days 22 hours and 51 minutes ago]

Wed, 24 Sep 2025 09:02:31 GMT

Due to recent discussions in the pov4 forum, I decided to document what 
I believe are issues with disc{} shape's CSG results. Ref:

https://news.povray.org/povray.pov4.discussion.general/thread/%3C68c8a619%241%40news.povray.org%3E/

See the attached image and scene files.

The top row a disc{} is being intersected with a sphere{}. In the second 
row a roughly equivalent polygon{} is intersected in the same fashion.

I believe the disc{} results are correct only in the second and last 
columns. The polygon row of intersections I believe is OK(*).

Bill P.

(*) Image results use v3.8 beta 2. The normal in yuqk for the polygon{} 
is flipped so +z is the outside texture.

[William F Pokorny] Re: Seam bugs / issues with bump_map. [419 days 4 hours and 35 minutes ago]

Fri, 14 Feb 2025 03:17:46 GMT

On 2/13/25 22:06, William F Pokorny wrote:
> Attached is a v3.8 beta 2 compatible scene which shows the issues and 
> two images.

Oops...

Scene file attached. Plus added image of what I see for a resulting 
image in v3.8 beta 2 using that scene file.

Bill P.

[William F Pokorny] Re: Seam bugs / issues with bump_map. [419 days 4 hours and 40 minutes ago]

Fri, 14 Feb 2025 03:12:46 GMT

On 2/13/25 22:06, William F Pokorny wrote:
> With respect to bump_map{}, the first root issue is due the multiple 
> samples sometimes spanning the seam in a given mapping type. The second 
> root issue - sitting smack on top of the first - is that games are being 
> played internal to all interpolations which introduce / mangle the 
> values in the pixels at the images edges.

So, what I decided to fix and not... (R19 v0.6.13.0 of yuqk fork)

The current collection of fixes has been implemented against the 
bump_map{} feature alone. The issues are most apparent / vibrant with 
this feature.

Within the bump_map{} code the planar (0) and angular (7) map types have 
been left as is code wise. (spherical, cylindrical, toroidal were updated)

The planar map because the user can use scaling / placements to avoid 
problem seams if they show up & the artefacts tend to be much less 
noticeable with planar mapping.

With the angular mapping usage any issues are both unlikely to show up 
and unlikely to matter if they do.

Ultimately there are no perfect solutions here. At the image edges we 
end up with a pile of trade-offs and no, general, ideal solutions.

Attached are two images.

--

The first is the zoomed in on the sphere surface form shown in the prior 
post. It basically shows things are better.

Results are solid for no interpolation so long as the image pixel 
resolution is >> effective pixel use in the rendered image.

Results are good for the bi-linear interpolation, but due the fix we've 
traded a small flat region at the image's pixel value over generated, 
additional edge values.

Results for the bi-cubic interpolation are accurate, but this means we 
now often see the ringing below 0.0 and above 1.0 which happens with 
this interpolation type.

Results for the normalized-distance are much better, but more visible 
than bi-linear.

---

The second image showing comparisons. Top row no interpolation needing 
only the fix for the first issue. The rows two through four show the 
interpolations 2,3 and 4 with the first issue fix in place. The center 
column shows the interpolation type specific fixes for each. The right 
column showing differences.

Bill P.

[William F Pokorny] Seam bugs / issues with bump_map. [419 days 4 hours and 46 minutes ago]

Fri, 14 Feb 2025 03:06:42 GMT

I recently made a post in the pbi forum which mentioned that the
bump_map{} code has a seam bug. See:

http://news.povray.org/povray.binaries.images/thread/%3C67a154c1%241%40news.povray.org%3E/

Bald Eagle posted a link to: https://iquilezles.org/articles/tunnel/
which is a cousin to one of two issues found with the current POV-Ray
code. (Thanks Bill)

Details...

There are many factors which contribute to the vibrancy of the issues
found in any given render result. Very generally it's worse with the
bump_map due how it takes multiple samples from the image to implement
the normal perturbation. Yes, the issues exist with image_map{},
image_pattern{} and image_indexed_textures{} (formally material_map{})
too - but mostly in muted / harder to see ways.

With respect to bump_map{}, the first root issue is due the multiple
samples sometimes spanning the seam in a given mapping type. The second
root issue - sitting smack on top of the first - is that games are being
played internal to all interpolations which introduce / mangle the
values in the pixels at the images edges.

Attached is a v3.8 beta 2 compatible scene which shows the issues and
two images. A triangle_wave gradient of x*pi is used to create the input
image for the bump_map{} where the mapping is spherical. The camera is
zoomed in on a smaller part of the sphere's surface containing the seam.

Both images show No-interpolation and Bi-Linear interpolation in the top
row and Bi-Cubic and Normalized-distance in the bottom row.

The image bump_map_state.png shows the current state with both issues
present and overlapping.

The image bump_map_intrpIssues.png shows the interpolation issues in
isolation - with code where the first issue is fixed.

Bill P.

[Kenneth] Re: material_map bug in v3.8 beta 2 [442 days 18 hours and 48 minutes ago]

Tue, 21 Jan 2025 13:05:00 GMT

"Kenneth" <kdw### [at] gmailcom> wrote:
> William F Pokorny <ano### [at] anonymousorg> wrote:
> > On 1/19/25 05:28, Kenneth wrote:
> > >
> > > for all of my usual .png renders in 3.8 beta 1,
> > > Ive's IC app reports them as having the correct sRGB embedded gamma.
> >
> > When I use the command:
> >
> >    p380b2 material_map_tester_kw.pov file_gamma=srgb
> >
> > [The srgb block is] not there by
> > default and should be (and for a LONG while it was. It should be there
> > in v3.7 renders, for example). Our default gamma handling in v3.8 is srgb.
> >
>
> Ah, I see what you mean now. Yes, if I leave out an explicit File_Gamma=srgb
> when running a render in 3.8 beta 1, Ive's IC reports the image as having a
> 'vanilla' 2.2 gamma instead, when it should be srgb 'by default'.
>

My apologies, Willaim: I mis-quoted your reply, which probably made my own reply
a bit confusing. It should have been the following:

[Kenneth:]
for all of my usual .png renders in 3.8 beta 1,
Ive's IC app reports them as having the correct sRGB embedded gamma.
   {because I use an explicit File_Gamma=srgb]

[William:]
When I use the command:

        p380b2 material_map_tester_kw.pov file_gamma=srgb

I get an output file size of 6638 - because the srgb block has been
added with the latter command (13 bytes larger). It's not there by
default and should be (and for a LONG while it was. It should be there
in v3.7 renders, for example). Our default gamma handling in v3.8 is srgb.

[Kenneth:]
Ah, I see what you mean now. Yes, if I leave out an explicit File_Gamma=srgb
when running a render in 3.8 beta 1, Ive's IC reports the image as having a
'vanilla' 2.2 gamma instead, when it should be sRGB 'by default'.

-----
When running 'official' v3.7.0 instead, the 'default' File_Gamma is indeed sRGB,
as you mentioned.

[Kenneth] Re: material_map bug in v3.8 beta 2 [444 days 16 hours and 53 minutes ago]

Sun, 19 Jan 2025 15:00:00 GMT

William F Pokorny <ano### [at] anonymousorg> wrote:
> On 1/19/25 05:28, Kenneth wrote:
> >
> > for all of my usual .png renders in 3.8 beta 1,
> > Ive's IC app reports them as having the correct sRGB embedded gamma.
>
> When I use the command:
>
>    p380b2 material_map_tester_kw.pov file_gamma=srgb
>
> [The srgb block is] not there by
> default and should be (and for a LONG while it was. It should be there
> in v3.7 renders, for example). Our default gamma handling in v3.8 is srgb.
>

Ah, I see what you mean now. Yes, if I leave out an explicit File_Gamma=srgb
when running a render in 3.8 beta 1, Ive's IC reports the image as having a
'vanilla' 2.2 gamma instead, when it should be srgb 'by default'.


> You can 'see' whether the srgb block exists in any png file by looking
> at the first 100 bytes or so in an editor or by using a command to write
> those initial bytes to the screen of a terminal window.
>
Sorry to say that I don't have an appropriate editor to check that in Windows
(unless there is some trick that I don't know of!)
>
> On the interpolation noise bug, I ran your scene with 'interpolation 3'
> and I do see it with my v3.8 beta 2 compile (top). See attached image -
> the current yuqk result on the bottom.

Yes, I see a bit of speckling even with interpolate 2, and far worse noise (like
your example) with interpolate 3 and 4.
>
>
> With the traditional material_map implementation, if you have in the
> index control image (MMT.png), indexes larger than the length of the
> texture list it gets wrapped back onto the list with a sort of
> 'mod(index,txtr_list_length)'.
>
> I thought this approach confusing. Now in yuqk, the map overruns are set
> to the index zero texture.
>
> I think it makes sense to map out of bounds
> indexes to the zero index in the same way.
>
Yes, that sounds like a more logical way of doing it, and more understandable as
to the visual result. (The documentation about "taking modulo N" is not very
easy to mentally visualize, ha.)

[Bald Eagle] Re: material_map bug in v3.8 beta 2 [444 days 18 hours and 3 minutes ago]

Sun, 19 Jan 2025 13:50:01 GMT

"Bald Eagle" <cre### [at] netscapenet> wrote:
> So, I may be way off base here, but I just wanted to speculate, to promote
> clarification of what's going on.
>
> It occurred to me that what Kenneth might be seeing is an artifact of one gamma
> "stretching" the color values sufficiently so that they skip over some of them.
> I now also wonder if he's missing a "compression" in another part of the
> mapping, where one value gets represented twice, and so it _looks_ like a single
> instance.
>
> Probably something to do numerically rather than graphically to really see
> what's going on.
>
> Just some thoughts.

One thing you might try is, rather than use png, use gif.

https://en.wikipedia.org/wiki/GIF

It seems that gif exclusively used an indexed color palette (color look up
table).

Then you can simply open the gif in IrfanView, and use Image > Information, and
it will tell you how many unique color indices you have.

If you're going to do graphic / visual experiments, it might be worth assembling
a color_map such that your color entries are non-adjacent in the color wheel.
So, all of the even entries would be "monotonically" increasing from 0, and all
the odd entries would get shifted - say, by adding 127, and taking mod(N, 255)
to get the result that's "wrapped around to 0".
That way, you get maximum contrast between color indexes, and might be better
able to see doubled entries.
You'd need hard stops in your color map to prevent interpolation between
entries, and then you could simply render a smooth gradient across a wide image
format (1920 x 1080).

- BW

[jr] Re: material_map bug in v3.8 beta 2 [444 days 18 hours and 3 minutes ago]

Sun, 19 Jan 2025 13:50:01 GMT

hi,

William F Pokorny <ano### [at] anonymousorg> wrote:
> On 1/19/25 05:28, Kenneth wrote:
> > I didn't know that. Although, for all of my usual .png renders in 3.8 beta 1,
> > Ive's IC app reports them as having the correct sRGB embedded gamma.
> ...
> When you run v3.8 beta 1 without using 'file_gamma=1.0' on the command
> line (or as an ini setting), do you see the sRGB[**] text in the png file?

no, you're correct.  have attached output of a quick 'hexdump'[*], comparing
images rendered by beta.2 and the recent yuqk.

[*] easier to read :-).
[**] another "easy" one for the 1st commit ;-)

regards, jr.

[William F Pokorny] Re: material_map bug in v3.8 beta 2 [444 days 18 hours and 37 minutes ago]

Sun, 19 Jan 2025 13:16:08 GMT

On 1/19/25 05:28, Kenneth wrote:
> I didn't know that. Although, for all of my usual .png renders in 3.8 beta 1,
> Ive's IC app reports them as having the correct sRGB embedded gamma.

Thanks for the scene code! :-)

I don't have a v3.8 beta 1 compile currently and I cannot find the 
newsgroup post where I wrote about the png, sRGB block bug...

Using your scene; Once I have created an MMT.png file (using 
file_gamma=1.0 on the command line), if I run:

   p380b2 material_map_tester_kw.pov

I get an output file size of 6625 bytes. When I use the command:

   p380b2 material_map_tester_kw.pov file_gamma=srgb

I get an output file size of 6638 - because the srgb block has been 
added with the latter command (13 bytes larger). It's not there by 
default and should be (and for a LONG while it was. It should be there 
in v3.7 renders, for example). Our default gamma handling in v3.8 is srgb.

You can 'see' whether the srgb block exists in any png file by looking 
at the first 100 bytes or so in an editor or by using a command to write 
those initial bytes to the screen of a terminal window. On linux:

'head -c100 my.png'

	ï¿½PNG
ï¿½
IHDR 'gAMAï¿½ï¿½

ï¿½asRGBï¿½ï¿½ï¿½sï¿½ï¿½Oï¿½tIMEï¿½
--
               above

When you run v3.8 beta 1 without using 'file_gamma=1.0' on the command 
line (or as an ini setting), do you see the sRGB text in the png file?

The sRGB block being missing leads to an inconsistency where we cannot 
make a read-->immediate_write, srgb round trip of an png image through 
POV-Ray without image changes.
---

On the interpolation noise bug, I ran your scene with 'interpolation 3' 
and I do see it with my v3.8 beta 2 compile (top). See attached image - 
the current yuqk result on the bottom.

---

With the traditional material_map implementation, if you have in the 
index control image (MMT.png), indexes larger than the length of the 
texture list it gets wrapped back onto the list with a sort of 
'mod(index,txtr_list_length)'.

I thought this approach confusing. Now in yuqk, the map overruns are set 
to the index zero texture.

Regions outsides the effective mapping and/or 'once' area (or to actual 
indexed image indexes which are transparent I believe) already get 
mapped to the zero index. I think it makes sense to map out of bounds 
indexes to the zero index in the same way.

---

Bill P.

[Kenneth] Re: material_map bug in v3.8 beta 2 [444 days 21 hours and 18 minutes ago]

Sun, 19 Jan 2025 10:35:00 GMT

William F Pokorny <ano### [at] anonymousorg> wrote:
> On 1/18/25 09:09, Kenneth wrote:
> > [using v3.7.0 and v3.8 beta 1 in Windows 10]
>
> Did you intend to attach an image to your post?
>

I was going to originally, but the image may not have been very informative
without comparing it the test code I used. So I have attached the code here
instead.

It uses a switch, to first *create* the 24-bit .png image-- which needs to be
renamed as "MMT" --then to use that image to run the material_map/textures
result. (This code is my own slight re-working of the documentation's example
and uses only five texture entries in the material_map.)

> IIRC the default srgb set up with png files for recent official
> v3.8 releases has an issue where the srgb block is not being written.
> This was fixed in the yuqk fork.

I didn't know that. Although, for all of my usual .png renders in 3.8 beta 1,
Ive's IC app reports them as having the correct sRGB embedded gamma.

from BE:
> It occurred to me that what Kenneth might be seeing is an artifact of one
> gamma "stretching" the color values sufficiently so that they skip over
> some of them. I now also wonder if he's missing a "compression" in another
> part of the mapping, where one value gets represented twice, and so
> it _looks_ like a single instance.

I have been contemplating that idea as well, if I understand your meaning. For
example, an sRGB 'File_Gamma' has a slightly different 'curve' from straight 2.2
gamma, at the low and high ends of its brightness(?) representations (if I
understand this stuff sufficiently.) And both of those gammas vary greatly from
a straight 'linear' gamma 1.0, of course. So numerically, these odd combinations
between assumed_gamma and File_Gamma don't match-- which will throw off the
material_map's indices of textures vs. red-channel brightness values.

To truly see where all of these differences occur in a material_map, an
interesting experiment would be make the 'preliminary' .png image with 256
distinct levels of brightness in the red channel-- and then to create 256
different texture entries in the material_map, to correspond! (I think my posted
code here could probably be re-jiggered to automatically do all of
this...although the visual result might be a bit difficult to interpret in a
meaningful way!)

[Bald Eagle] Re: material_map bug in v3.8 beta 2 [445 days 6 hours and 28 minutes ago]

Sun, 19 Jan 2025 01:25:00 GMT

So, I may be way off base here, but I just wanted to speculate, to promote
clarification of what's going on.

It occurred to me that what Kenneth might be seeing is an artifact of one gamma
"stretching" the color values sufficiently so that they skip over some of them.
I now also wonder if he's missing a "compression" in another part of the
mapping, where one value gets represented twice, and so it _looks_ like a single
instance.

Probably something to do numerically rather than graphically to really see
what's going on.

Just some thoughts.

[William F Pokorny] Re: material_map bug in v3.8 beta 2 [445 days 14 hours and 58 minutes ago]

Sat, 18 Jan 2025 16:54:55 GMT

On 1/18/25 09:09, Kenneth wrote:
> [using v3.7.0 and v3.8 beta 1 in Windows 10]
> 
> The material_map feature is new to me; I don't think that I have ever used it in
> a scene-- probably because I never use 'indexed' images. But your post spurred
> me to take a look at the documentation, and to try it out.
> 
> Instead of using a true indexed image, I decided to make a typical .png 24-bit
> image for use in the map, by following the docs' example code at  "2.3.5.11 When
> All Else Fails: Material Maps". (The material_map pattern still makes use of
> so-called 'indices' in the image, but they are the red-channel gradations of
> 0/255, 1/255, 2/255 etc, rather than 1,2,3 etc.) I rendered this initial image
> with *no* antialiasing, which makes a big difference...and *no* interpolation
> later, when I used it in the map.
> 
> So far, I have not been able to reproduce the 'noise' that you mentioned-- but I
> discovered something else: Once I carefully made the preliminary image for the
> material_map, and added the required number of textures to correspond to the
> 'indices' of its red-channel steps, the final rendered texture results did not
> quite correspond correctly to the indices: A few textures were missing.
> 
> After a lot of double-checking of my code and some experimentation, I made a
> 'lucky informed guess' as to the cause: It turned out to be a gamma issue. To
> make the initial image for use in the material_map, I had used assumed_gamma 1.0
> as usual, and with my File_Gamma as 'srgb' (as usual). But this 'mis-match' of
> gammas caused the problem! So I re-made the image, keeping assumed_gamma at 1.0
> but *changing* the File_Gamma to 1.0 to match it-- and the missing textures
> appeared correctly in the final material_map render. (Using assumed_gamma 2.2
> and a matching 2.2 File_Gamma also solves it.) Apparently, those two gamma
> values need to be the same for that initial render, so that the material_map
> code will then work correctly with it under-the-hood.
> 
> I don't yet know if this problem affects true 'indexed' images.
> 
> This solution leads me to believe that, when the material_map code was first
> implemented in POV-ray long ago, the various gammas of rendering might have been
> different than they currently are... possibly with a gamma of 2.2 being used
> across-the-board, or by default. That's my guess.
> 

Thanks for the feedback. I think I need to tweak my documentation on 
gamma. Up front I recommended it not be used because I assumed these 
'indexed aimed' images would be written at a file gamma of 1.0 where the 
red channel was used, but you're right, ultimately gamma while reading 
an image file needs to match the gamma encoding for the image (*) when 
it was written. Excepting indexed images, for which the gamma settings 
should not matter.

(*) - IIRC the default srgb set up with png files for recent official 
v3.8 releases has an issue where the srgb block is not being written. 
This was fixed in the yuqk fork.

Did you intend to attach an image to your post?

The noise issue can only show up if one of the interpolation modes is 
used. It's more likely to be there for interpolations 3 and 4. It didn't 
show up for me always with linear interpolation. In being numerical 
noise, it might be somewhat sensitive to compiler settings too.

Bill P.

[Kenneth] Re: material_map bug in v3.8 beta 2 [445 days 17 hours and 43 minutes ago]

Sat, 18 Jan 2025 14:10:00 GMT

[using v3.7.0 and v3.8 beta 1 in Windows 10]

The material_map feature is new to me; I don't think that I have ever used it in
a scene-- probably because I never use 'indexed' images. But your post spurred
me to take a look at the documentation, and to try it out.

Instead of using a true indexed image, I decided to make a typical .png 24-bit
image for use in the map, by following the docs' example code at  "2.3.5.11 When
All Else Fails: Material Maps". (The material_map pattern still makes use of
so-called 'indices' in the image, but they are the red-channel gradations of
0/255, 1/255, 2/255 etc, rather than 1,2,3 etc.) I rendered this initial image
with *no* antialiasing, which makes a big difference...and *no* interpolation
later, when I used it in the map.

So far, I have not been able to reproduce the 'noise' that you mentioned-- but I
discovered something else: Once I carefully made the preliminary image for the
material_map, and added the required number of textures to correspond to the
'indices' of its red-channel steps, the final rendered texture results did not
quite correspond correctly to the indices: A few textures were missing.

After a lot of double-checking of my code and some experimentation, I made a
'lucky informed guess' as to the cause: It turned out to be a gamma issue. To
make the initial image for use in the material_map, I had used assumed_gamma 1.0
as usual, and with my File_Gamma as 'srgb' (as usual). But this 'mis-match' of
gammas caused the problem! So I re-made the image, keeping assumed_gamma at 1.0
but *changing* the File_Gamma to 1.0 to match it-- and the missing textures
appeared correctly in the final material_map render. (Using assumed_gamma 2.2
and a matching 2.2 File_Gamma also solves it.) Apparently, those two gamma
values need to be the same for that initial render, so that the material_map
code will then work correctly with it under-the-hood.

I don't yet know if this problem affects true 'indexed' images.

This solution leads me to believe that, when the material_map code was first
implemented in POV-ray long ago, the various gammas of rendering might have been
different than they currently are... possibly with a gamma of 2.2 being used
across-the-board, or by default. That's my guess.

[William F Pokorny] material_map bug in v3.8 beta 2 [447 days 21 hours and 31 minutes ago]

Thu, 16 Jan 2025 10:22:17 GMT

(The bug can be avoided by never using image interpolation)

---

While working on a renamed and refurbished material_map{} feature for 
the yuqk fork, ran across a bug where non-indexed / non-palette image 
was - by numerical noise - sometimes slipping into an indexed state of 0 
when interpolation was used. This happening no matter whether the base 
image was indexed or not.

The bug traced to two functions in imageutil.cpp called 
InterpolateBicubic() and Interp(). These are general routines so the 
exposure touches any code which looks at the calculated 'index' value to 
decide later actions.

The fix I used was to apply rounding rather than a cast to int when 
returning the index value - which is always calculated alongside the red 
/ grey color channel. (Yes, the index values themselves are interpolated 
too for actual indexed images)

---
In InterpolateBicubic() change:

   *index = (int)tempIndex;
to:
   *index = (int)std::lround(tempIndex);

---
In Interp() change:

   *index = (int)temp_index;
to:
   *index = (int)std::lround(temp_index);


Find attached a sample scene for v3.8 beta 2 and an image where the top 
portion shows noise from the bug and the bottom being the yuqk fork's 
current output for the same set up with the fixes above applied.

Bill P.

[William F Pokorny] Collection of polygon object bugs / issues [484 days 2 hours and 30 minutes ago]

Wed, 11 Dec 2024 05:23:36 GMT

References:

https://github.com/POV-Ray/povray/issues/467
"[BUG] doesn't give an error if a polygon is not 2D #467"

https://news.povray.org/povray.general/thread/%3Cweb.674a4c31296bdfa2e3cbe740b3ec8729%40news.povray.org%3E/
"polygon not visible"

While looking into a fix for the above issues in addition to extensions
to the existing polygon object functionality, I found additional bugs
and issues.

1) The automatic polygon closing feature creates confusing results as
often as it helps. It only works somewhat well for single loops of
points not yet closed.

2) In POV-Ray v3.0, the polygon object was re-written, substantially
upgrading its capabilities. Some guessing here, but it looks like the
effort started with an approach using a general projection of 3D polygon
points onto the x-y plane. Though there has long been the restriction
that the z values all be the same, the general code is still in there -
and it doesn't always create a valid initial transform /
inverse-transform 'transform structure'. In my testing it seems to
always work where the loops are all triangles - which is a fair
hint/guess as to what went wrong.

There are many rendering ameliorations which will lead to the bad
transforms going unnoticed. In adding certain features to yuqk's polygon
object I circumvented ALL of them. Users will mostly see things working.
Especially when working on the polygon as a single object in
isolation. That said, I expect the bad transform the cause of some flaky
results over the years.

Today, the only 3D flexibility is where all z coordinates being the same
can indicate an offset along the z axis for the x-y plane - and this is
the transform structure which should be created. For the inverse
transform this a matrix:

<1, 0, 0, 0>
<0, 1, 0, 0>
<0, 0, 1, 0>
<0, 0, -z, 1>

and the transform matrix is:

<1, 0, 0, 0>
<0, 1, 0, 0>
<0, 0, 1, 0>
<0, 0, +z, 1>

The upcoming R17 (v0.6.11.0) of the yuqk fork hard codes these!

3) The 'transform structure' created by the v3.0 code has also been used
to flip direction of the normal based upon point order. However, bugs
aside, the transform creating code typically looks only at the first
four points of the first loop. This is not enough to reliably determine
the polygon's point loops rotation direction.

The standard method for this is a polygon area measuring algorithm often
called the shoelace formula. Release R17 of yuqk moves to this method
for setting the normal z direction.

4) There are a handful of checks in the code for the validity of polygon
point description. Most all since v3.7 were quietly marking the polygon
as an invalid shape which caused it to disappear. In the yuqk fork these
checks now all generate parse time errors on such failures.

However, there is a fairly large set of possible degenerate polygon
point descriptions for which there has never been any checking - and for
which adding checking is a chunks of work. This remains a TODO item in
the yuqk fork.

Bill P.

[William F Pokorny] Re: Difference in wrapped vs raw wood in normal{} [494 days 20 hours and 31 minutes ago]

Sat, 30 Nov 2024 11:22:38 GMT

On 11/30/24 05:52, Mr wrote:
> This is the first result and does seem relevant:
> https://learnopengl.com/Advanced-Lighting/Normal-Mapping

Thank you for the reference!

Bill P.

[Mr] Re: Difference in wrapped vs raw wood in normal{} [494 days 20 hours and 58 minutes ago]

Sat, 30 Nov 2024 10:55:00 GMT

William F Pokorny <ano### [at] anonymousorg> wrote:
> On 11/29/24 06:20, Mr wrote:
> > So... Is there still no chance to create tangent space normal maps macros since
> > most recent fixes?
>
> Probably not... :-)
>
> I don't know is my actual answer. I have doubts I've changed mapping
> capability enough in yuqk to do much new over what POV-Ray can do.
>
> When I have a little more time I'll have to search the web and the
> newsgroups for exactly what you mean by "tangent space normal maps macro".
>
> Bill P.

This is the first result and does seem relevant:
https://learnopengl.com/Advanced-Lighting/Normal-Mapping

Crossfingers! Anyway, thanks a lot for ALL the work you are doing, very much
appreciated, please keep having fun !

[William F Pokorny] Re: Difference in wrapped vs raw wood in normal{} [495 days 5 hours and 39 minutes ago]

Sat, 30 Nov 2024 02:13:57 GMT

On 11/29/24 06:20, Mr wrote:
> So... Is there still no chance to create tangent space normal maps macros since
> most recent fixes?

Probably not... :-)

I don't know is my actual answer. I have doubts I've changed mapping 
capability enough in yuqk to do much new over what POV-Ray can do.

When I have a little more time I'll have to search the web and the 
newsgroups for exactly what you mean by "tangent space normal maps macro".

Bill P.

[Mr] Re: Difference in wrapped vs raw wood in normal{} [495 days 20 hours and 28 minutes ago]

Fri, 29 Nov 2024 11:25:00 GMT

William F Pokorny <ano### [at] anonymousorg> wrote:
> On 11/27/24 08:00, William F Pokorny wrote:
> > Real life keeping me busy over the next few days, but I plan to dig into
> > this when I get some time. My guess at the moment is it is some
> > numerical difference near values of 0 and/or 1, but we'll see.
>
> What is going on popped into my head 10 minutes ago. The following does
> produce the same result as normal{ wood rotatex*90 } :
>
>      #declare Fn = function {
>          pattern {  // This {} enables value modifiers
>              wood
>            //rotate x*90
>          }
>      }
>      normal {
>          Fn(x,y,z)
>          rotate x*90  // Moved the rotation here
>      }
>
> Where I had coded this:
>
>      #declare Fn = function {
>          pattern {  // This {} enables value modifiers
>              wood
>              rotate x*90
>          }
>      }
>      normal {
>          Fn(x,y,z)
>      }
>
> In the top the rotate happens in normal{} context. With the bottom
> encoding it happens in the pre-compiled function{ pattern{} } context.
>
> The normal{} value sampling - in being only a pyramid  of 4 samples - is
> asymmetric. It sees the wood pattern's value not-rotated in one case and
> rotated in the other and we get different perturbed normal results.
>
> Bill P.

So... Is there still no chance to create tangent space normal maps macros since
most recent fixes?

[William F Pokorny] Re: Difference in wrapped vs raw wood in normal{} [497 days 12 hours and 25 minutes ago]

Wed, 27 Nov 2024 19:28:41 GMT

On 11/27/24 08:00, William F Pokorny wrote:
> Real life keeping me busy over the next few days, but I plan to dig into 
> this when I get some time. My guess at the moment is it is some 
> numerical difference near values of 0 and/or 1, but we'll see.

What is going on popped into my head 10 minutes ago. The following does 
produce the same result as normal{ wood rotatex*90 } :

     #declare Fn = function {
         pattern {  // This {} enables value modifiers
             wood
           //rotate x*90
         }
     }
     normal {
         Fn(x,y,z)
         rotate x*90  // Moved the rotation here
     }

Where I had coded this:

     #declare Fn = function {
         pattern {  // This {} enables value modifiers
             wood
             rotate x*90
         }
     }
     normal {
         Fn(x,y,z)
     }

In the top the rotate happens in normal{} context. With the bottom 
encoding it happens in the pre-compiled function{ pattern{} } context.

The normal{} value sampling - in being only a pyramid  of 4 samples - is 
asymmetric. It sees the wood pattern's value not-rotated in one case and 
rotated in the other and we get different perturbed normal results.

Bill P.

[William F Pokorny] Difference in wrapped vs raw wood in normal{} [497 days 18 hours and 52 minutes ago]

Wed, 27 Nov 2024 13:00:55 GMT

In writing this post to the v4.0 forum:

http://news.povray.org/povray.pov4.discussion.general/thread/%3C67471126%241%40news.povray.org%3E/

I discovered weird differences in results between using the wood pattern 
directly within a normal and wrapping it in pigment_pattern{} or 
function{pattern{}}.

In other words, the following:

normal {
   wood
   rotate*90
}

Results in behavior different than either:

#declare Fn = function {
   pattern {
     wood
     rotate x*90
   }
}
...
normal { Fn(x,y,z) }

     or

normal {
   pigment_pattern {
     wood
     color_map {
       [0 rgb 0]
       [1 rgb 1]
     }
     rotate x*90
}

In the attached image the left column is using one of the wood {} 
wrapped forms. The middle column uses 'wood' directly in the normal{}.
The right column showing a 4x multiple of differences which should not 
exist. No AA used. The image results are from v3.8 beta 2, but this 
issue exists in the yuqk fork too.

The top row is just the wood base normal. The bottom row showing the 
wood based normal used in a slope map{}.

Real life keeping me busy over the next few days, but I plan to dig into 
this when I get some time. My guess at the moment is it is some 
numerical difference near values of 0 and/or 1, but we'll see.

Bill P.

[William F Pokorny] Re: Concerns with the tiling pattern's numerical... [502 days 20 hours and 29 minutes ago]

Fri, 22 Nov 2024 11:24:16 GMT

On 11/21/24 22:23, William F Pokorny wrote:
> Picked up numerical noise with tiling patterns: 3, 12, 13 and 14.

Add 6, 11, 15 to the list too. I rendered the whole set to some 
different square image sizes.

I also tried the following fix to great success for pattern use:

   // If seeing numerical noise, try a TINY rotation like:
   rotate z*1e-5

Whether the rotation fix will work where the tiling pattern is used as 
part of an isosurface function will depend upon 'stuff'.

Bill P.

[William F Pokorny] Re: Concerns with the tiling pattern's numerical... [503 days 4 hours and 30 minutes ago]

Fri, 22 Nov 2024 03:23:13 GMT

On 2/28/22 06:03, William F Pokorny wrote:
> In coming back to the tiling patterns for some povr testing, I 
> suddenly(1) picked up 'new' isosurface issues with tiling's 13 and 14. 
> On more digging, it looks like there are generic issues in these two, 
> similar, patterns. Issues I fear exist in other tiling patterns too, but 
> I've not gone looking for more grief as yet.

For the record and FWIW.

In working on documentation for yuqk created a test scene rendering all 
27 tiling patterns to grey gradients with jitter off, but otherwise 
heavy Anti-Aliasing (AA). Using an orthographic camera.

Picked up numerical noise with tiling patterns: 3, 12, 13 and 14. 
Patterns 13 & 14 known about when I made the original post.

NOTE! Many things affect whether such numerical noise will show up or 
matter. In typical scenes don't worry about this numerical noise - until 
you see it and need to deal with it.

Attaching the image for 3 - rendered with v3.8 beta 2.

Bill P.

[William F Pokorny] Re: v3.8+ crackle instability (facets?) with >1 ... [506 days 20 hours and 1 minute ago]

Mon, 18 Nov 2024 11:51:54 GMT

On 11/17/24 21:52, Bald Eagle wrote:
> William F Pokorny <ano### [at] anonymousorg> wrote:
>> On 11/17/24 06:51, William F Pokorny wrote:
>>> No attempt wrap the cylinder - just punching out a thin part of the
>>> crackle cell outlines.
> 
> Huh.  And what happens if you do the same sort of thing with something like the
> Stanford bunny?
> 

If the aim is seeing the outlines rather than creating an isosurface 
shape from them, the quick thing would be to create a pigment from the 
crackle pattern set up to show outlines - the parts of the pattern not 
outlines would be set transparent. Ignoring that we can define an inside 
vector for a well formed / closed mesh, a mesh surface is already 
infinitely thin for the purposes of sampling.

If you want to play with isosurfaces based upon a mesh, one of the 
techniques to turn them into value fields would be the up front 
approach. There are a couple SDL only ones. A method I posted in the mid 
to late 2000s and one Sam B posted in the early 2010s. The yuqk fork has 
hard_object{} and soft_object{} inbuilt features for turning shapes into 
value fields / patterns.

The recent filling a shape with random noise approach might work for a 
noisier result. There is too a way to pre-sample a shapes interior 
saving the result as a df3 file which can then be used as a value 
pattern suitable for an isosurface.

A straight intersection with a mesh having a clean inside region or any 
object with an defined inside is an option too. The gradients will be 
bad and the result, visually, less interesting as the outer layer of 
cell outlines will hide everything to the interior.

Bill P.

Aside: I've wondered some what an intersection of two crackle value 
pattern intersected might look like - where one crackle changes ip_seed, 
is rotated or scaled differently such that the cells walls intersect 
sparsely.

With the ip_strength option set up asymmetrically we might also be able 
to define certain patterns or shapes. One crackle ip_repeat, repeating 
differently than the other where both have identical ip_seed, seeds...

[Bald Eagle] Re: v3.8+ crackle instability (facets?) with >1 ... [507 days 4 hours and 58 minutes ago]

Mon, 18 Nov 2024 02:55:00 GMT

William F Pokorny <ano### [at] anonymousorg> wrote:
> On 11/17/24 06:51, William F Pokorny wrote:
> > No attempt wrap the cylinder - just punching out a thin part of the
> > crackle cell outlines.

Huh.  And what happens if you do the same sort of thing with something like the
Stanford bunny?

- BW

[William F Pokorny] Re: v3.8+ crackle instability (facets?) with >1 ... [507 days 8 hours and 40 minutes ago]

Sun, 17 Nov 2024 23:13:28 GMT

On 11/17/24 07:53, William F Pokorny wrote:
> Got some coffee in me and gave the cylindrical warp a go.

While playing, created attached images. The right one by accident...

Last part of the function { pattern {crackle ...} } used was:

         warp {
             it_amount <1/3,1/3,1/3>
             it_omega 0.87 it_lambda 4.7 it_scale 1/5
         }
         scale <1/6,1,1>
         warp { cylindrical }
         warp { spherical }    // Oops

Aiming again for shapes that are not really shapes in a usual way. 
Suppose yesbird's recent gravity toy post in the same vein.

The isosurface gradient set low (1.3), accuracy really rough at 0.05, 
but with isosurface jitter (jittering within accuracy range) on - and 
aggressive AA (antialias_min_depth=2 +r4) sampling. yuqk only features 
are involved.

Bill P.

[William F Pokorny] Re: v3.8+ crackle instability (facets?) with >1 ... [507 days 19 hours ago]

Sun, 17 Nov 2024 12:53:18 GMT

On 11/17/24 06:51, William F Pokorny wrote:
> No attempt wrap the cylinder - just punching out a thin part of the 
> crackle cell outlines.

Got some coffee in me and gave the cylindrical warp a go. The crackle 
function becomes:

#declare FnCrk = function {
     pattern {
         crackle
         ip_form <-0.1,0.080,0>
         ip_strength <0.25,0.25,0.25>
         ip_repeat <5,0,0>
         ip_raw_return
         raw_wave
         scale 1/5
         scale <1/5,1,1>
         warp { cylindrical }
     }
}

(And I fattened up the cell walls for a better gradient)

Aside: I think there is a slight stretch in the wrap because the warp{} 
mapping warps often seems to want radian measures - 'scale <1/tau,1,1>' 
for best geometric mapping.

Anyhow. Image attached.

Bill P.

[William F Pokorny] Re: v3.8+ crackle instability (facets?) with >1 ... [507 days 20 hours and 2 minutes ago]

Sun, 17 Nov 2024 11:51:35 GMT

On 11/12/24 03:17, William F Pokorny wrote:
> Thanks for the references. IIRC shadertoy has a distance method to draw 
> the outline of cells, but I don't recalled the particulars at the 
> moment. I have ideas for how to do it in C++, but I also wonder if in 
> yuqk it cannot already 'mostly' be done. Stuff like this why I added the 
> ip_raw_return as a yuqk crackle option. Maybe I'll take a 'crack' at it 
> in a bit.

I didn't spend much time on it, but the top of the attached image shows 
outlines as a pigment just slightly red (negative) by allowing raw value 
returns after changing ip_form to: 'ip_form <-0.1,0.08,0> - the default 
is <-1,1,0>.

The bottom of the image is an isosurface where a cylindrical shell is 
intersected with a similar crackle pattern in space. No attempt wrap the 
cylinder - just punching out a thin part of the crackle cell outlines.

The isosurface functions are:

// yuqk required
#declare Fn00 = function (x,y,z) {
     f_planar(f_cylinder(x,y,z,0.9),0.01,1)
}
#declare FnCrk = function {
     pattern {
         crackle
         ip_form <-0.1,0.097,0>
         ip_strength <0.25,0.25,0.25>
         ip_raw_return
         raw_wave
         translate <0,0,0.25>
         scale 1/5
     }
}
#declare Fn01 = function (x,y,z) { max(Fn00(x,y,z),FnCrk(x,y,z)) }

Yes, The outline / cell-walls vary some due differences in gradients - 
but more due how the slices catch the cell wall. For practical purposes, 
expect an approach like this often OK for cell outlines.

Bill P.

[Bald Eagle] Re: v3.8+ crackle instability (facets?) with >1 ... [512 days 17 hours and 33 minutes ago]

Tue, 12 Nov 2024 14:20:00 GMT

William F Pokorny <ano### [at] anonymousorg> wrote:

> IIRC shadertoy has a distance method to draw
> the outline of cells, but I don't recalled the particulars at the
> moment. I have ideas for how to do it in C++, but I also wonder if in
> yuqk it cannot already 'mostly' be done. Stuff like this why I added the
> ip_raw_return as a yuqk crackle option. Maybe I'll take a 'crack' at it
> in a bit.

Perhaps you are thinking of this article:
https://iquilezles.org/articles/voronoilines/

> I see a path to something like a the Delaunay dual for which performance
> might be acceptable, but due the current limits to the three closest
> measures it would be limited / degenerate in a strict sense.

I'm not sure where we are with libraries, but I'm pretty sure CGAL has all of
this stuff, plus a bewildering pile more.

> With a lot of this voronoi like stuff, 2d is a lot easier than three.
> General, solid 3D solutions likely requires stand alone dedicated code.
> We are working under the constraint that we want a reasonably performant
> pattern in the end - as you know :-).

Maybe?
I don't really know that that's true, if we exclude the fancy stuff.
A dirt-simple min (distance-of-pixel-from-all-seeds) ought to work just as well
in 3D as it does in 2.
I'll bet that visualizing that with a black-to-clear gradient or media would be
a quick and easy test.

- BW

[William F Pokorny] Re: v3.8+ crackle instability (facets?) with >1 ... [512 days 23 hours and 36 minutes ago]

Tue, 12 Nov 2024 08:17:16 GMT

On 11/11/24 15:30, Bald Eagle wrote:
> Relevant search results and further reading:
> 
> Stephane Laurent (stla)
> https://github.com/stla/Apollonius
> 
> Inigo Quilez
> https://www.shadertoy.com/view/4sd3D7
> 
> Voronoi Diagram Research Center
> http://voronoi.hanyang.ac.kr/c3_voronoiDiagrams.htm
> 
> Need to further look into:
> Johnson-Mehl tessellation
> 

Thanks for the references. IIRC shadertoy has a distance method to draw 
the outline of cells, but I don't recalled the particulars at the 
moment. I have ideas for how to do it in C++, but I also wonder if in 
yuqk it cannot already 'mostly' be done. Stuff like this why I added the 
ip_raw_return as a yuqk crackle option. Maybe I'll take a 'crack' at it 
in a bit.

I see a path to something like a the Delaunay dual for which performance 
might be acceptable, but due the current limits to the three closest 
measures it would be limited / degenerate in a strict sense.

As for other extensions, some might be worth a try.

With a lot of this voronoi like stuff, 2d is a lot easier than three. 
General, solid 3D solutions likely requires stand alone dedicated code. 
We are working under the constraint that we want a reasonably performant 
pattern in the end - as you know :-).

Bill P.

[Bald Eagle] Re: v3.8+ crackle instability (facets?) with >1 ... [513 days 11 hours and 18 minutes ago]

Mon, 11 Nov 2024 20:35:00 GMT

Relevant search results and further reading:

Stephane Laurent (stla)
https://github.com/stla/Apollonius

Inigo Quilez
https://www.shadertoy.com/view/4sd3D7

Voronoi Diagram Research Center
http://voronoi.hanyang.ac.kr/c3_voronoiDiagrams.htm

Need to further look into:
Johnson-Mehl tessellation

[Bald Eagle] Re: v3.8+ crackle instability (facets?) with >1 ... [513 days 16 hours and 3 minutes ago]

Mon, 11 Nov 2024 15:50:00 GMT

William F Pokorny <ano### [at] anonymousorg> wrote:

> With this I think the code is the best answer. In my re-write, I
> flattened the code so there is little (no?) jumping around in the
> overall code base required to see what is going on. Last time I counted,
> yuqk's crackle was roughly 400 lines of code or so. See:
>
> CracklePattern::EvaluateRaw() in source/core/material/pattern.cpp

It's probably going to take me a bit of time to translate from c++ to something
I can more easily follow.

However, let me offer the following for your consideration:
(inspired by recent scenes, and some long-standing & recurring challenges, plus
you comment: "// TODO. Idea here is maybe return largest fitting spheres, etc...
")

The Appolonian Gasket code returns the largest fitting circles, and in 3D - the
largest fitting spheres.
Perhaps if "crackle" were to be approached from the standpoint of Voronoi and
Appolonian sharing common ground, then the triangles or tetrahedra containing
the inscribed circles or spheres would be more easily generated, and we could
get both for (a little more than) the price of one?

This would be the/a solution to the long-desired ability to pack a region with
non-overlapping circles/spheres.

A similar and directly related pattern would be the Malfatti circles.

Do we presently have the capability to simply "draw the outline" of the Voronoi
cells?

Do we have any idea what would be required to be able to generate the Dual
pattern - the Delaunay triangulation?

- BW

[Bald Eagle] Re: v3.8+ crackle instability (facets?) with >1 ... [517 days 17 hours and 38 minutes ago]

Thu, 7 Nov 2024 14:15:00 GMT

William F Pokorny <ano### [at] anonymousorg> wrote:

> With this I think the code is the best answer. In my re-write, I
> flattened the code so there is little (no?) jumping around in the
> overall code base required to see what is going on. Last time I counted,
> yuqk's crackle was roughly 400 lines of code or so. See:
>
> CracklePattern::EvaluateRaw() in source/core/material/pattern.cpp

Excellent.
Thanks - I hope I get the opportunity to download that and spend some
uninterrupted time reading and understanding it.

So much to do!

[William F Pokorny] Re: v3.8+ crackle instability (facets?) with >1 ... [518 days 5 hours and 54 minutes ago]

Thu, 7 Nov 2024 01:58:46 GMT

On 11/6/24 13:26, Bald Eagle wrote:
> How many Voronoi "seeds" are there in the unit cube before you reach the "edge"
> and there is a repeat?  Is that / can that be a variable?

The is one seed point per unit cubelet. To do the repeat the overall 
5x5x5 cube gets re-created as the evaluation point moves to another 
centered global cubelet location (tracked with unsigned integers in yuqk).

A trick of the repeat is to wrap in both in the forward direction as 
each x,y,z change - but also behind so the local 'center' see an 
environment valid for the range of supported distances(*).

(*) In yuqk the ip_strength vector lets you use >1.0 vector components 
and exceed the technically supported distances. Same can happen if the 
ip_exponent of the '0' / power ip_metric is <1.0. You still get a result 
usable for effect, but it doesn't look like a standard crackle / Voronoi 
result.

The repeat values are user variables.

The size of the supported cache for cubes of cubelets environments is 
done with build options / environment variables.

To date the max size of the cuble for experimentation is manually hacked 
into the code - I'm not sure what all I might be doing there in the end.

> 
> What are you doing at the edges/corners to make a space-filling tesselation by
> that "unit cube" of Voronoi pattern?  Essentially just a mod (<x, y, z>, N)?

Yes, fmod() (SDL's mod()) gets used to set up both the cubelet locations 
and the repeated cubelets.

With this I think the code is the best answer. In my re-write, I 
flattened the code so there is little (no?) jumping around in the 
overall code base required to see what is going on. Last time I counted, 
yuqk's crackle was roughly 400 lines of code or so. See:

CracklePattern::EvaluateRaw() in source/core/material/pattern.cpp

Bill P.

[Bald Eagle] Re: v3.8+ crackle instability (facets?) with >1 ... [518 days 13 hours and 23 minutes ago]

Wed, 6 Nov 2024 18:30:00 GMT

William F Pokorny <ano### [at] anonymousorg> wrote:

> The evaluation point is in the center cubelet of a larger 5x5x5 cube(*)
> of cubelets. The center point of all cubelets is offset by a random-ish
> still within each cubelet as the 'Voronoi' points.
>
> (*) Official POV-Ray does an optimization to calculate only 81 cubelet
> offset vectors & yuqk might later adopt something similar (**). The
> current yuqk crackle is set up for up to 7x7x7 as I wanted to experiment
> with other crackle options at some point.

Right - I forgot about the larger cube dimensions to "catch" the corners.

So, some better thought-out questions are:

How many Voronoi "seeds" are there in the unit cube before you reach the "edge"
and there is a repeat?  Is that / can that be a variable?

What are you doing at the edges/corners to make a space-filling tesselation by
that "unit cube" of Voronoi pattern?  Essentially just a mod (<x, y, z>, N)?

> > Also, have you thought about allowing user-defined distance metrics (Euclidean,
> > Manhattan, Minkowski, etc.) for generating the underlying pattern?
>
> Sure, the first two are already implemented as metrics 2 and 1 (***).
> I'm not completely sure what you mean by minkowski. I'm familiar with
> minkowski sum and difference with respect to shapes. Some options today
> give a similar look, but the devil is in the details.

I guess Minkowski is a generalized form of the first two.
see:
https://www.kdnuggets.com/2023/03/distance-metrics-euclidean-manhattan-minkowski-oh.html

Apparently there's also
Chebyshev
power diagrams - https://en.wikipedia.org/wiki/Power_diagram
weighted Voronoi diagrams -
https://en.wikipedia.org/wiki/Weighted_Voronoi_diagram
https://cs.stackexchange.com/questions/43817/voronoi-diagrams-with-l%E2%88%9E-metric
https://www.researchgate.net/publication/228910426_Visualization_of_Generalized_Voronoi_Diagrams
https://www.researchgate.net/publication/331203691_Computation_of_Compact_Distributions_of_Discrete_Elements

etc

[William F Pokorny] Re: v3.8+ crackle instability (facets?) with >1 ... [518 days 14 hours and 33 minutes ago]

Wed, 6 Nov 2024 17:20:18 GMT

On 11/6/24 10:51, Bald Eagle wrote:

Hi.

> So - you've got a central cubelet surrounded by 26 other neighbor cubelets.
> Is the central cubelet (off)set at <2, 2, 2>?
> 

The evaluation point is in the center cubelet of a larger 5x5x5 cube(*) 
of cubelets. The center point of all cubelets is offset by a random-ish 
still within each cubelet as the 'Voronoi' points.

(*) Official POV-Ray does an optimization to calculate only 81 cubelet 
offset vectors & yuqk might later adopt something similar (**). The 
current yuqk crackle is set up for up to 7x7x7 as I wanted to experiment 
with other crackle options at some point.

(**) - I think OK to a high probability & for our crackle pattern, but 
not quite completely "right".

> 
> Recalling some of your other posts - the pattern looks very "cubic" - rather
> than a typical Voronoi pattern.
> 

Allowing for some tuning differences, both the official POV-Ray and yuqk 
methods are cubelets forming a cube based (not pure Voronoi, points 
anywhere implementations), so yes this underlying structure is noticeable.

I suspect you are more noticing yuqk's new ip_strength vector multiplier 
for the offsets, which can be <1.0 for any of the components. At a 
strength of 0.0 the cube of cublets structure is completely on display.

> Also, have you thought about allowing user-defined distance metrics (Euclidean,
> Manhattan, Minkowski, etc.) for generating the underlying pattern?

Sure, the first two are already implemented as metrics 2 and 1 (***). 
I'm not completely sure what you mean by minkowski. I'm familiar with 
minkowski sum and difference with respect to shapes. Some options today 
give a similar look, but the devil is in the details.

(***) The official POV-Ray code both implements a power metric and 
defined the exponent for it by using metrics values other than 1 or 2. I 
thought this ugly, especially given I wanted to add more metrics.

So in yuqk there is an ip_metric 0, which means use a power metric with 
which a new ip_exponent keyword for the exponent to use. This allows 
ip_metric to be extended. I've only added one in (3) for four total in 
0,1,2,3 - but there are plans to try others.

User defined. The ip_form vector offers some control. Each component is 
a +- distance multiplier for the three distance measures taken (The 
three closest points to the evaluation point).

Bill P.

[Bald Eagle] Re: v3.8+ crackle instability (facets?) with >1 ... [518 days 15 hours and 58 minutes ago]

Wed, 6 Nov 2024 15:55:00 GMT

William F Pokorny <ano### [at] anonymousorg> wrote:

> Unsure how much my particular methods might help! How one might approach
> repeatability depends on the environment, underlying metrics, forms, etc.

I guess I was mostly interested in if/how you were doing the modular arithmetic
to get seamless tiling, and assign pattern results to drive color_map values.

> In my re-write of the crackle code I took advantage of newer hardware
> and features of C++. For example, I push all the working coordinates
> into a +x, +y +z space. Already the working grid internally (for the
> cubes) was integer based as the origin for each offset point relative to
> the evaluation point.

So - you've got a central cubelet surrounded by 26 other neighbor cubelets.
Is the central cubelet (off)set at <2, 2, 2>?

I suppose I will have to read through your code to better understand, and ask
better questions (or any at all).

Recalling some of your other posts - the pattern looks very "cubic" - rather
than a typical Voronoi pattern.

Also, have you thought about allowing user-defined distance metrics (Euclidean,
Manhattan, Minkowski, etc.) for generating the underlying pattern?

- BW

[William F Pokorny] Re: v3.8+ crackle instability (facets?) with >1 ... [523 days 11 hours and 40 minutes ago]

Fri, 1 Nov 2024 20:13:34 GMT

On 11/1/24 09:36, Bald Eagle wrote:
> I would greatly appreciate some advice on how to properly accomplish this, as my
> experiments in the past were fraught with unwanted artefacts:
> https://news.povray.org/ 
> web.6394be0a7dc652cc1f9dae3025979125%40news.povray.org
> 
> I'm sure that one of your long "ramblings on" would be an insightful read, and
> probably spur on other tangential projects - as they always do.
> 
> Hopefully we'll both have a few round-tuits at some point to compare notes.
> 
> Good work, and much appreciated!

Hi Bill.

Thanks.

Unsure how much my particular methods might help! How one might approach 
repeatability depends on the environment, underlying metrics, forms, etc.

In my re-write of the crackle code I took advantage of newer hardware 
and features of C++. For example, I push all the working coordinates 
into a +x, +y +z space. Already the working grid internally (for the 
cubes) was integer based as the origin for each offset point relative to 
the evaluation point.

Much of the trouble I had with repeat (I suspect it's related to what's 
wrong with the v3.8 repeat feature and caching too) was realizing I had 
to do the cube calculations for offsets apart from the cached cube 
coordinates. This something which might not even be doable with the 
cache structure of the V3.8 beta 2 code - not thought about it too much 
though. The yuqk caching is set up differently.

When I finally got my head on straight about that, the repeat code 
became something which creates x,y,z unsigned integer coordinates 
differently for the negative cube coordinates and positive cube 
coordinates about the center evaluation cube - depending upon where in 
the repeat range the evaluation point is on each axis.

In the POV-Ray implementation, a virtual environment of cubes containing 
offset points is created around each cube in space where we find 
ourselves evaluating 3D locations. For the repeat aspect, suppose I 
created what amounts to another virtual working space on top of that one 
in which to repeat.

Backing up, the POV-Ray set up of a virtual box of cubelets containing 
the center cube with the evaluation point is driven by the 'form' 
feature. It requires up to three closest point measures for downstream 
metric calculations.

If for your crackle implementation, you only care about the closest 
points - as is true for solid(*) results - the implementation can be 
simpler.

(*) - In the yuqk re-write I treat the solid feature as something almost 
completely apart from the crackle proper features.

Anyhow. The updated source code will be in the next yuqk release (R16). 
Having it to review might help make sense of what I've written.

Bill P.

Aside: I'm reminded that years ago I experimented some with different 
shape functions set at point locations as a way to to create crackle 
pattern shapes - all in SDL - which was limiting. The traditional 
crackle solid look you can create with cones. Can't find the post... Too 
many ideas and not enough time. :-)

[Bald Eagle] Re: v3.8+ crackle instability (facets?) with >1 ... [523 days 18 hours and 13 minutes ago]

Fri, 1 Nov 2024 13:40:00 GMT

William F Pokorny <ano### [at] anonymousorg> wrote:

> Took me a while, but I think I've gotten to what clipka was aiming for
> in his v3.8 crackle repeat feature. A <3,3,0> repeat is shown in the
> center of the attached image.

I would greatly appreciate some advice on how to properly accomplish this, as my
experiments in the past were fraught with unwanted artefacts:
https://news.povray.org/web.6394be0a7dc652cc1f9dae3025979125%40news.povray.org

I'm sure that one of your long "ramblings on" would be an insightful read, and
probably spur on other tangential projects - as they always do.

Hopefully we'll both have a few round-tuits at some point to compare notes.

Good work, and much appreciated!

- BW

[William F Pokorny] Re: v3.8+ crackle instability (facets?) with >1 ... [524 days 8 hours and 42 minutes ago]

Thu, 31 Oct 2024 23:11:14 GMT

On 10/30/24 02:19, William F Pokorny wrote:
> In the lower left showing my development yuqk re-write, crackle repeat 
> feature result. Yes, its different than v3.8. I didn't like the 
> complexity and cost of the v3.8 implementation and went with something 
> simpler (I avoided the self cache repeat bug by chance...). With yuqk 
> (R16) the pattern flipping would be done with warp { repeat }(s).

In the end, after I played a bit, I didn't much like my alternate repeat 
implementation in yuqk...

Took me a while, but I think I've gotten to what clipka was aiming for 
in his v3.8 crackle repeat feature. A <3,3,0> repeat is shown in the 
center of the attached image.

Bill P.

[William F Pokorny] Re: v3.8+ crackle instability (facets?) with >1 ... [526 days 1 hour and 34 minutes ago]

Wed, 30 Oct 2024 06:19:17 GMT

On 6/8/24 15:12, William F Pokorny wrote:
> I've been playing with 'facets' and 'crackle' of late. I've turned up a 
> bug (or two) (*).
> 
> Documenting now - partly so I can think through what I'm seeing as I write.
> 
> The crackle pattern and facets perturbation maintain thread local 
> storage so information can be cached in a thread safe way.
> 
> The issue, I think, is that that storage is set up to work with one 
> crackle and/or facets use per thread and no more.
> 
> Once we run >1 of either in the same thread they share the thread local 
> storage. This >1 usage per thread happens, for example, when we layer 
> textures both based upon crackle

An update for those who might follow at some later time...

I think I've finished the re-write of the crackle pattern with a simpler 
fixed size, per thread cache (for other than ip_solid on) which tracks 
the pattern along with the center cube location. To be released in 
yuqk(R16).

In testing the new code I discovered the 'repeat' feature of v3.8 beta 2 
has a self cache collision issue at the origin in addition to the cache 
collision issues of multiple crackle patterns within a thread.

For the attached images the scene set up is a large disc with a hole. 
Within the hold there is a second smaller disc which doesn't quite fill 
the hole. The rose color is the background seen through a gap. The outer 
disc crackle pattern is scaled very small, but is otherwise the default 
crackle.

The repeat, self, cache collision bug of v3.8 beta 2 is shown in the 
upper left. I didn't chase a fix.

The image in the upper right is the version of yuqk I released in July 
(R15) where, by hack, I disabled the crackle caching. The crackle 
implementation is still what is in V3.8 beta 2. The repeat works as I 
thin clipka intended!

In the lower left showing my development yuqk re-write, crackle repeat 
feature result. Yes, its different than v3.8. I didn't like the 
complexity and cost of the v3.8 implementation and went with something 
simpler (I avoided the self cache repeat bug by chance...). With yuqk 
(R16) the pattern flipping would be done with warp { repeat }(s).

The lower right is there just to fill out the 4x4! It shows the use of 
a, new to yuqk, crackle ip_seed feature to change the inner disc's 
ip_solid result. I added ip_seed to make it easier to get different 
crackle looks on different shapes otherwise using the same crackle 
pattern specification.

Bill P.

Aside 1: What is the repeated pattern on the outer disc seen in the v3.8 
top row? It's a side effect of the more limited accuracy of the hashing 
mechanism used to create the per cube point offsets in the v3.8 code. I 
believe I changed things so this type of artifact is much less likely 
with yuqk.

Aside 2 (*): Why is yuqk's lower left image a little brighter than 
v3.8s? One of the aspects of the traditional POV-Ray crackle cube point 
offsets is that they work from a starting corner. This produces a result 
which, to my eye, creates too many pinched regions in the pattern's 
result. With the yuqk re-write the offsets are done from the cube center 
in a +-(0.0 to 0.49) way. Less pinching, more white area, brighter image...

(*) - This yuqk change unexpectedly created a sampling issue where, when 
scaling the crackle pattern very small, the crackle's inner cube nature 
becomes more quickly apparent when anti-aliasing is off. It's a kind of 
harmonic of rays with the underlying, less pinched crackle pattern. It's 
not an issue when AA is used.

[William F Pokorny] Re: Photons are broken with true inverse squared... [657 days 18 hours and 14 minutes ago]

Thu, 20 Jun 2024 13:39:33 GMT

On 6/19/24 18:16, William F Pokorny wrote:
> I'll look at this tomorrow.

In source/core/lighting/photons.cpp there are two methods:

     void PhotonTrace::addSurfacePhoton()

     void PhotonMediaFunction::addMediaPhoton()

which have code like:

     if ((photonLight->Fade_Power > 0.0) &&
         (fabs(photonLight->Fade_Distance) > gkMinIsectDepthReturned))
     {
         Attenuation = 2.0 /
         (1.0 + pow(threadData->photonDepth /
             photonLight->Fade_Distance, photonLight->Fade_Power)
         );
     }
     else
         Attenuation = 1;

In both methods, the code needs to be something like:

     if (photonLight->Fade_Power > 0.0)
     {
         if (fabs(photonLight->Fade_Distance) >= gkMinIsectDepthReturned)
         {
             Attenuation = 2.0 /
                 (1.0 + powf(threadData->photonDepth /
                             photonLight->Fade_Distance,
                             photonLight->Fade_Power
                        )
                 );
         }
         else if (threadData->photonDepth >= gkMinIsectDepthReturned)
         {
             Attenuation =
                 powf(threadData->photonDepth,-photonLight->Fade_Power);
         }
         else
         {
             Attenuation = 0.0;
         }
     }
     else if (photonLight->Fade_Power == 0)
     {
         Attenuation = 1;
     }
     else
     {
         Attenuation = 0.0;
     }

Bill P.

Aside: I moved pow to powf as the latter often much faster and float 
accuracy is fine for attenuation. It might be official releases are 
already running 'pow()' with floats without code that forces it.

[William F Pokorny] Re: Photons are broken with true inverse squared... [658 days 9 hours and 37 minutes ago]

Wed, 19 Jun 2024 22:16:24 GMT

On 6/19/24 15:14, Cousin Ricky wrote:
> Well, I found out why my 30th anniversary tribute to POV-Ray went crazy
> when I upgraded the lamp fixtures: photons are broken with POV-Ray 3.8's
> inverse squared lighting.

At the time the photons feature was added, a significant part of the 
tracing code was duplicated in the photons tracing code. When a trace 
related feature is updated, we have to remember to duplicate the feature 
update in that photons code.

I'd guess this didn't happen - at least not correctly.

I'll look at this tomorrow.

Bill P.

[Cousin Ricky] Photons are broken with true inverse squared lig... [658 days 12 hours and 39 minutes ago]

Wed, 19 Jun 2024 19:14:18 GMT

https://news.povray.org/povray.binaries.images/thread/%3C65c7ec42%40news.povray.org%3E/

Well, I found out why my 30th anniversary tribute to POV-Ray went crazy
when I upgraded the lamp fixtures: photons are broken with POV-Ray 3.8's
inverse squared lighting.  I rendered my initial scene before I had
finished the DeskLamp module, and at that time, the scene used only
POV-Ray's legacy light fading; but the DeskLamp module automatically
uses true inverse squared if it detects #version 3.8 or later.

The 2 control images below were rendered without photons, just to verify
that the legacy light source and true inverse squared light source are
comparable.

---%<----%<----%<----%<--[BEGIN CODE]--%<----%<----%<----%<----%<---
// +KFF4 +W512 +H384
#version 3.8;

#declare Has_photons = (frame_number >= 3);
#declare True_invsq = 1 - mod (frame_number, 2);

#include "screen.inc"

global_settings
{ assumed_gamma 1
  max_trace_level 100
  #if (Has_photons)
    photons { spacing 0.005 autostop 0 }
  #end
}
#default { finish { ambient 0.1 diffuse 0.6 emission 0 } }
box
{ -<6, 0.001, 6>, <6, 8, 6>
  hollow
  pigment { rgb 1 }
}
Set_Camera (<2, 3, -5>, <0.25, 1, 0>, 60)

#declare v_Source = <-5, 7, -5>;
#declare v_Focus = <0, 1, 0>;
#declare Dist = vlength (v_Source - v_Focus);
#if (True_invsq)
  light_source
  { v_Source, rgb pow (Dist, 2)
    fade_distance 0
    fade_power 2
  }
#else
  #declare FD = 0.1;
  light_source
  { v_Source, rgb (1 + pow (Dist / FD, 2)) / 2
    fade_distance FD
    fade_power 2
  }
#end

intersection
{ box { -1, 1 }
  box { -1.1, 1.1 rotate 45 * x }
  box { -1.1, 1.1 rotate 45 * y }
  box { -1.1, 1.1 rotate 45 * z }
  translate y
  pigment { rgbf 1 }
  finish
  { fresnel 1
    reflection { 1 fresnel } conserve_energy
    specular 1 roughness 0.0003
  }
  interior { ior 1.8 dispersion 1.04 }
  photons { target collect off reflection on refraction on }
}

Screen_Object
( text
  { ttf "cyrvetic"
    concat
    ( #if (True_invsq) "True inverse squared",
      #else "Old fade formula",
      #end
      #if (Has_photons) " with photons"
      #else " control"
      #end
    )
    0.001, 0
    pigment { rgb 0 }
    scale 16 / image_height
  },
  <0, 0>, <0.02, 0.01>, yes, 1
)
--->%---->%---->%---->%---[END CODE]--->%---->%---->%---->%----%<---

[William F Pokorny] Re: v3.8+ crackle instability (facets?) with >1 ... [662 days 19 hours and 10 minutes ago]

Sat, 15 Jun 2024 12:43:08 GMT

On 6/14/24 09:49, Bald Eagle wrote:
> Minimally hijacking this thread to just post an FYI which may be helpful in some
> of your source-code optimizing work.
> 
> https://iquilezles.org/articles/noacos/

Thanks. Been some years, but I read that article at some point in the 
past! Good to be reminded of it.

Bill P.

[Bald Eagle] Re: v3.8+ crackle instability (facets?) with >1 ... [663 days 18 hours and 3 minutes ago]

Fri, 14 Jun 2024 13:50:00 GMT

Minimally hijacking this thread to just post an FYI which may be helpful in some
of your source-code optimizing work.

https://iquilezles.org/articles/noacos/

I haven't looked under the hood in a while to see how we're handling stuff like
this, but it seems like it could provide some performance increases, and for the
basis for some macros / include files.

- BW

[William F Pokorny] Re: v3.8+ crackle instability (facets?) with >1 ... [663 days 19 hours and 26 minutes ago]

Fri, 14 Jun 2024 12:27:14 GMT

On 6/8/24 15:12, William F Pokorny wrote:
> The crackle pattern and facets perturbation maintain thread local 
> storage so information can be cached in a thread safe way.

Note too:

https://stackoverflow.com/questions/35985960/c-why-is-boosthash-combine-the-best-way-to-combine-hash-values

---
In working to clean up and commit my last updates, I ran across a TODO 
comment I'd added to friend std::size_t hash_value() in cracklecache.h 
about the initial seed value of 0 - which bothers me. I did a quick 
search this morning to look for rumblings about boost:combine().

Other issues aside. It might be our crackle caching mechanism is less 
effective than it could be.

Bill P.

[William F Pokorny] Re: v3.8+ crackle instability (facets?) with >1 ... [664 days 8 hours and 27 minutes ago]

Thu, 13 Jun 2024 23:26:02 GMT

On 6/11/24 14:17, Thorsten wrote:
> It is impossible to predict the complexity with modern CPU, I think.

I agree. Today's hardware optimizations make performance tuning a tough 
trick - and make questionable a number of "rules of thumb" about which 
algorithms perform best.

> 
> The benefit would be that the "texturing" would become a completely 
> separate task, and could actually be done (sans reflection and 
> refraction) after tracing, which, if nothing else, would lead to a cool 
> looking render preview. The other effect would be that at least bounding 
> optimisations and mesh intersection testing could be done on a GPU.
> 
> Yet another benefit you get from separating the tracing and the 
> texturing is that you end up with a sort of frame buffer that contains 
> object data. An idea I never pursued to the end 20 or so years ago was 
> that this gives rise to the ability to edit a ray-traced scene on the 
> fly because you have access to the objects making up an individual pixel 
> and can separate objects in and out of the scene as long as the camera 
> doesn't move.

Cool ideas. :-) I can see how some parts might work, but far from all of 
it.

Our ray tracing and texturing is today tangled in places (adc bailout, 
filtering/transparency, media, object modifiers). There is too how to 
handle anti-aliasing (AA) / camera focal blur.

Though our 'AA' approach today is expensive(a), it's a strength with 
respect to 'true result' that each sample ray considers the scene - 
including texturing - alongside all the ray tracing / branching in total.

Bill P.

(a) - With respect to performance, on my 'try it someday' list are 
cheaper AA / focal blur modes where the rays beyond some 'sampling 
depth/count' would terminate at a much shallower max_trace_level/sample 
count(*). Or maybe we gradually reduce the trace depth in opposition to 
the AA/blur sampling 'depth'. Results would be less true, but I 
'suspect' they'd often look good as a rule. (There is a tradeoff buried 
in the idea as the less accurate results due shallower ray trace depth 
would sometimes itself trigger additional sampling - and sometimes not 
where we would otherwise have shot more rays.)

(*) - Yes! I made trying the idea harder by implementing the forced min 
sampling AA in yuqk.

[Thorsten] Re: v3.8+ crackle instability (facets?) with >1 ... [666 days 13 hours and 36 minutes ago]

Tue, 11 Jun 2024 18:17:07 GMT

On 11.06.2024 17:39, William F Pokorny wrote:
> When I think about really implementing that approach, I also start to 
> think about how a different approach to parallelism than our block based 
> approach could be good. One where we spin up the combined 
> shape/solver(s) as processes to which we'd send batches of rays at a 
> time and get back batches of intersections... Yeah, I'm practically 
> dreaming, but pretty sure that sort of set up would be best for the 
> merged uni-variate, polynomial solver/shape approach. How it well that 
> structure would work overall - I'm not at all sure. ðŸ˜„

Well, yes, an intersection based approach would probably offer the most 
potential performance on a shared memory system. You would also end up 
with a stack-based approach automatically that way. However, you hit 
sort of a wall once you get to the really big multi-die systems like 
Epyc and newer Xeons because they only share the last level cache with 
all cores. So in the end the best performance probably hides somewhere 
in a hybrid of the two with blocks still offering some benefit for large 
multi-core systems. That is, of course, assuming the ray order doesn't 
disrupt first and second level caches too much. It is impossible to 
predict the complexity with modern CPU, I think.

The benefit would be that the "texturing" would become a completely 
separate task, and could actually be done (sans reflection and 
refraction) after tracing, which, if nothing else, would lead to a cool 
looking render preview. The other effect would be that at least bounding 
optimisations and mesh intersection testing could be done on a GPU.

Yet another benefit you get from separating the tracing and the 
texturing is that you end up with a sort of frame buffer that contains 
object data. An idea I never pursued to the end 20 or so years ago was 
that this gives rise to the ability to edit a ray-traced scene on the 
fly because you have access to the objects making up an individual pixel 
and can separate objects in and out of the scene as long as the camera 
doesn't move.

Thorsten

[William F Pokorny] Re: v3.8+ crackle instability (facets?) with >1 ... [666 days 16 hours and 14 minutes ago]

Tue, 11 Jun 2024 15:39:12 GMT

On 6/11/24 03:43, Thorsten wrote:
> Hi Bill,
> 
> the other issue to consider is that while there is no user interface for 
> it, in theory multiple renders of the same scene can run in parallel. 
> The actual solution to the whole problem is to keep the data needed not 
> only thread-local but look carefully at what is actually cached and then 
> ideally have it block local (also meaning, as with thread-local storage, 
> that the pattern changes with render block size) or even better pixel 
> local (no change with block size). To avoid the access to thread-local 
> storage, the whole rendering actually could be overhauled (which would 
> be good anyway) to move from a recursive to a stack based approach. That 
> way the needed local data could be (more easily) passed as argument down 
> to patterns ... but expect half a year full time to implement something 
> like this.
> 
> Thorsten

Hi Thorsten,

Thank you for your thoughts about the situation.

One thing I've not done is think about all patterns / perturbations / 
shape, thread caching with respect to overlapping in-thread storage use. 
In other words, what other problems like this might be sitting in the 
code today...

On the blocking, you got me thinking one nearer term option with crackle 
and facets might be to track the pattern / perturbation pointers 
themselves alongside the usual cube centers. In cases where we get a 
hit, but the pointers themselves don't match, we'd act like we missed 
and create a new cache entry. Rather than stick that 'overlapping hit' 
entry in the cache, we'd do the distance measures locally and discard 
the entry. Not optimal, more storage for the cache, but it would be 
better than just turning the cache off.

On storage block or pixel local/thread storage. Better I'd say, but so 
long as the patterns might share the storage, I think it still leaves us 
exposed given how the crackle / facets patterns work today.

Overhauling the rendering approach. Yeah, likely due and good, but not 
at all trivial as you say. I'm not myself sure how such a restructuring 
should look in total.

With the solver work I did now 5-6 years ago, I came to the conclusion a 
fused shape/solver approach would be far better given we are 
ray-tracing. See:

https://news.povray.org/povray.programming/thread/%3C5d0f64ff%241%40news.povray.org%3E/

When I think about really implementing that approach, I also start to 
think about how a different approach to parallelism than our block based 
approach could be good. One where we spin up the combined 
shape/solver(s) as processes to which we'd send batches of rays at a 
time and get back batches of intersections... Yeah, I'm practically 
dreaming, but pretty sure that sort of set up would be best for the 
merged uni-variate, polynomial solver/shape approach. How it well that 
structure would work overall - I'm not at all sure. :-)

As a practical near term solution, one thing I want to try is similar to 
what I did with the four ripple/wave value-pattern/normal-perturbation 
re-writes. I dumped already calculated locations for ones always 
calculated on the fly. At the default source location count of 10, the 
hit for not storing the locations was 20% give or take - IIRC.

If I can figure out a way to re-write the crackle and facets at that 
sort of performance hit, I'll probably just dump all the caching / 
thread local storage in total for local stack based storage.

Whether I can accomplish such a re-write - at a performance hit not too 
bad -is an open question at the moment. Not the least for the reason 
it's a chunk of work which well might not work out as a solution in the 
end - so I'm procrastinating.

Bill P.

[Thorsten] Re: v3.8+ crackle instability (facets?) with >1 ... [667 days and 9 minutes ago]

Tue, 11 Jun 2024 07:43:56 GMT

On 10.06.2024 13:51, William F Pokorny wrote:
> On 6/9/24 00:21, William F Pokorny wrote:
>> Ah, and what about facets.
> 
> FWIW. The caching mechanism is simpler (older) for facets. As with 
> crackle I experimented some with forcing 100% misses. The slow down in 
> the heavy AA case is +195% as opposed to the +335% seen with crackle. 
> The difference likely comes down to the overhead for the simpler facets 
> cache being smaller. The facets cache comes close to what I wanted to 
> try with the crackle cache.
> 
> Going to let ideas to rattle around in my head for a while as to what to 
> do. ( 1. Limit use to one crackle and one facets use in any given scene. 
> 2. A cache per crackle/facets use / per thread. 3. ...)

Hi Bill,

the other issue to consider is that while there is no user interface for 
it, in theory multiple renders of the same scene can run in parallel. 
The actual solution to the whole problem is to keep the data needed not 
only thread-local but look carefully at what is actually cached and then 
ideally have it block local (also meaning, as with thread-local storage, 
that the pattern changes with render block size) or even better pixel 
local (no change with block size). To avoid the access to thread-local 
storage, the whole rendering actually could be overhauled (which would 
be good anyway) to move from a recursive to a stack based approach. That 
way the needed local data could be (more easily) passed as argument down 
to patterns ... but expect half a year full time to implement something 
like this.

Thorsten

[William F Pokorny] Re: v3.8+ crackle instability (facets?) with >1 ... [667 days 20 hours and 2 minutes ago]

Mon, 10 Jun 2024 11:51:26 GMT

On 6/9/24 00:21, William F Pokorny wrote:
> Ah, and what about facets.

FWIW. The caching mechanism is simpler (older) for facets. As with 
crackle I experimented some with forcing 100% misses. The slow down in 
the heavy AA case is +195% as opposed to the +335% seen with crackle. 
The difference likely comes down to the overhead for the simpler facets 
cache being smaller. The facets cache comes close to what I wanted to 
try with the crackle cache.

Going to let ideas to rattle around in my head for a while as to what to 
do. ( 1. Limit use to one crackle and one facets use in any given scene. 
2. A cache per crackle/facets use / per thread. 3. ...)

Bill P.

[William F Pokorny] Re: v3.8+ crackle instability (facets?) with >1 ... [669 days 3 hours and 32 minutes ago]

Sun, 9 Jun 2024 04:21:13 GMT

On 6/8/24 15:12, William F Pokorny wrote:
> The issue, I think, is that that storage is set up to work with one 
> crackle and/or facets use per thread and no more.

OK. I ran an experiment where I forced 100% cache misses in yuqk. I then 
re-ran a collections of scenes running multiple crackle patterns per 
thread. Everything looks OK.

This method of disabling the cache is not optimal as the cache set up 
mechanism is forced to run all the time, but the cached data is never 
used. Still, I ran some timing using the crackle2_v38.pov scene with no 
AA and forced (+a0.0) heavy AA.

p380b2 -> yuqk (R15). Cache active. No AA. Shows yuqk 62% faster(a).
p380b2 -> yuqk (R15). Cache active. With AA. Shows yuqk 34% faster(a).

yuqk (with cache) -> yuqk (all misses). No AA. yuqk is 240% slower.
yuqk (with cache) -> yuqk (all misses). With AA. yuqk is 335% slower.

So... Forcing cache misses and getting no cache benefit is very costly. 
Of course, the results are correct, which matters more.

Suppose, I need to attempt thread local storage which completely 
replaces the current cache mechanism to see where that performance comes 
in. :-(

Unsure if I'll do that work for R15 though. I might just force the cache 
misses for now. It would leave me a release where crackle is working and 
I've not further twiddled with how the the code works.

Ah, and what about facets.

Bill P.

(a) - Is the current yuqk speed up over p380b2 is mostly:

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

I'm unsure what else it might be if not.

[William F Pokorny] v3.8+ crackle instability (facets?) with >1 uses... [669 days 12 hours and 40 minutes ago]

Sat, 8 Jun 2024 19:12:53 GMT

I've been playing with 'facets' and 'crackle' of late. I've turned up a 
bug (or two) (*).

Documenting now - partly so I can think through what I'm seeing as I write.

The crackle pattern and facets perturbation maintain thread local 
storage so information can be cached in a thread safe way.

The issue, I think, is that that storage is set up to work with one 
crackle and/or facets use per thread and no more.

Once we run >1 of either in the same thread they share the thread local 
storage. This >1 usage per thread happens, for example, when we layer 
textures both based upon crackle.

See the two attached scene files which result in images like those 
attached when things go wrong. (Using v3.7 beta 2 and the not yet 
released yuqk R15 for the renders)

1) Things don't always go wrong. The problem is flaky. Scene renders 
with artifacts often later run cleanly and visa versa. The two scene 
files attached are good at having problems.

2) The v38 scene uses 'repeat <>' and the yuqk one 'ip_strength <>' - 
which twiddles with the strength of the noise used to push the point per 
cube around inside the cube for the pseudo random-ish point set. My 
guess at the moment is these features turn over the thread crackle cache 
more often.

3) I've only seen the buggy results when the text output reports less 
than 100% cache hits. For example:

   Crackle Cache Queries:          960000
   Crackle Cache Hits:             888124 ( 93 percent)

4) The problem seems slightly worse - with more of a render block 
signature - when multiple threads are used. This doesn't really line up
with my best guess as to the issue! At the moment I think this probably 
a secondary bug where maybe the cache is supposed to be cleared at 
render block end, but it isn't, or similar. Might be a secondary thread 
safety issue too.

5) I've not looked at the v3.7 code as yet for these issue(s).

---
I know. The yuqk fork's tearing result looks kinda cool - wish it 
reflected intent... :-)

Bill P.

(*) - There are a couple other minor bugs too in crackle with offset and 
<=0 metric settings patched / fixed in the yuqk fork.

[William F Pokorny] Dynamic, CPU optimization, build bug and a patch. [698 days 2 hours and 35 minutes ago]

Sat, 11 May 2024 05:18:21 GMT

Issue discussed first in the newsgroup thread:

https://news.povray.org/povray.general/thread/%3C663cdc51%241%40news.povray.org%3E/

At some point a few years ago, the default gnu unix/linux builds for 
v3.8+ versions of POV-Ray stopped correctly detecting x86 CPU features 
necessary to use the hand coded optimizations which work on my old i3 
CPU. The build problem is likely more general, but to an extent unknown.

The g++ compiler is in-lining an __asm__ coded function despite source 
code attributes indicating it should not. The in-lining comes with 
side-effects.

If compiling on an x86 AMD or Intel CPU (or equivalent VM) and you are 
getting a generic optimization over a hand coded one, you can try a 
build using +O0 while configuring which prevents all in-lining of code. 
The resulting build will be slow, but if you then get a dynamic 
optimization, you too are seeing the issue.

Because the issue results in hand optimizations not being used, it's 
harmless with respect to end result. Some scenes will render a little 
more slowly than they might otherwise.

See the upcoming yuqk release (R15) for one possible patch. Specifically 
changes to the file <code install dir>/platform/x86/cpuid.cpp.

--

Note! Clang++ (emulating gnu gcc/g++) builds were OK, with or without 
the suggested patch on my i3. See yuqk's INSTALL.txt for a suggested 
configuration for a clang++ based build.

--

Related: There is a github pull request with a hand coded avx512 
implementation for the v3.8 POV-Ray branch:

    https://github.com/POV-Ray/povray/pull/452

I've not myself tried the pull request with my yuqk fork. I don't have 
the AMD and Intel hardware on which to test it.

Bill P.

[William F Pokorny] Re: Re-discovering issues with finding ini files... [706 days 22 hours and 56 minutes ago]

Thu, 2 May 2024 08:57:05 GMT

On 4/15/24 22:49, William F Pokorny wrote:
> The above said, the aim of this post is to document that I've found 
> issues with ini parsing error reporting when ini files are directly 
> included!

I believe these issues now fixed in the upcoming release R14 of yuqk.

> ...
> Because it's part of the 'ini' tofix pile and related, I'll toss out 
> again that the ini directory ordering, as affected by library paths, is 
> glitch-y. We should not be using the library search paths for ini files 
> at all, but rather only for include files.
> 
> It believe it should always have been another path set up mechanism for 
> ini files (perhaps an INIPATH env var similar to PATH?). Or, no path 
> searching at all and just include_ini= or +ini usage. This latter 
> approach is how I plan to go with yuqk - though I've not yet worked out 
> the code changes to disable to sometimes searching of the library path 
> for ini files, so we'll see.

And with the library paths in v3.8+ onward(*); the problem with the ini 
search mechanism only picking up the first search directory in the set 
has been fixed for release R14 of yuqk.

While there are other fixes / changes in yuqk besides, I 'think' much 
can be had in official v3.8+ POV-Ray releases by simply adding the line:

   libpath.clear();

just ahead of:

   if (POVMSAttr_GetUTF8String(&item,kPOVMSType_UCS2String,libpath) != 0)

in:

   ITextStream *ProcessRenderOptions::OpenINIFileStream(...)

in the file:  source/frontend/processrenderoptions.cpp

Things go wrong in POVMSAttr_GetUTF8String() and the collection of 
functionality it calls in that the individual paths returned after the 
first are mangled / blended with prior results.

I've kept the now working library path searching in yuqk rather than 
create an alternate approach / method for it - though I think any 
eventual v4.0 offering should set up a separate 'ini path'.

(*) - The v3.8+ code is different than the v3.7 code. Unsure how v3.7 
works with respect to ini files and searching the specified library path.

Bill P.

[William F Pokorny] Re: Re-discovering issues with finding ini files... [723 days 5 hours and 4 minutes ago]

Tue, 16 Apr 2024 02:49:13 GMT

On 3/20/24 01:49, William F Pokorny wrote:
> With that change I'm able to run the following (reminder yuqk is 
> linux/unix only):
> 
>  Â Â Â  yuqk playpen.pov
include_ini="quickres.ini[1024x768, AA 0.3]"
> 
> or
> 
>  Â Â Â  yuqkZ playpen.pov +ini"quickres.ini[1024x768,
AA 0.3]"
> 
> Of course, with that set up you can then only reach local directory ini 
> files afterward because those are all that will be found.

First, as an addition to the previous post, I should have added as a 
footnote that using include_ini= (*) or +ini with a full path or 
complete relative path specification for ini files works.

Today. These options are in fact the only way other than copying all the 
ini files you need into the local rendering directory to be sure(**) you 
find ini files (other than install or user-local povray.ini) correctly.

(*) - The include_ini= option exists today in official releases, but 
isn't documented.

(**) - This isn't the same as saying the current ini mechanism doesn't 
often work. Of course, this is an ugly position to be in as it means the 
ini behavior, where other than having all same directory ini file(s), is 
unreliable.

---

The above said, the aim of this post is to document that I've found 
issues with ini parsing error reporting when ini files are directly 
included! :-(

(Yes, now guessing that, not documenting 'include_ini=' might have been 
some sort of a 'delay for fixes' which never happened.)

Basically, ini files included via this mechanism can have serious 
parsing issues which end up completely ignored in official releases of 
POV-Ray (Linux / Unix versions at least). They are 'somewhat ignored' 
with current releases of the yuqk fork.

The yuqk fork reports the parsing problems with additional text messages 
where official releases usually don't. However, today in released yuqk 
versions up to R13, the parsing still doesn't stop on finding serious 
issues. The bad error return code gets eaten / overwritten due how the 
include_ini= option was originally implemented.

---

Because it's part of the 'ini' tofix pile and related, I'll toss out 
again that the ini directory ordering, as affected by library paths, is 
glitch-y. We should not be using the library search paths for ini files 
at all, but rather only for include files.

It believe it should always have been another path set up mechanism for 
ini files (perhaps an INIPATH env var similar to PATH?). Or, no path 
searching at all and just include_ini= or +ini usage. This latter 
approach is how I plan to go with yuqk - though I've not yet worked out 
the code changes to disable to sometimes searching of the library path 
for ini files, so we'll see.

Bill P.

[William F Pokorny] A v3.8 / v4.0 divide by zero exposure AA samplin... [742 days 19 hours and 11 minutes ago]

Wed, 27 Mar 2024 12:42:18 GMT

It happens when we end up with a single pixel within a within a thread 
rendering block; When neighborSamples in tracetask.cpp ends up as 1. My 
patch bumps that value to at least '2'. This makes the test to the 
threshold less forgiving, but at worst a few more samples are taken.

The single pixel in a render block isn't something which will happen 
often in practice(a).

As for what happens today on hitting this bug; It will depend on how 
your particular executable is compiled. If nothing else, it's
a component contributing to somewhat flaky render reporting. My fast 
compile ran without a squeak, but it also bailed too early on the AA for 
the single pixel.

Bill P.

(a) - The code involved here has some addition implications related to 
how many initial samples there are available in the block for a given 
pixel. The count changes downstream behavior. At the start of the 
sampling, I don't think it will matter much to the end result. This 
'concern' is mostly mitigated, if using yuqk's anti-aliasing min depth 
option with a depth >0.

[William F Pokorny] Re-discovering issues with finding ini files in ... [750 days 2 hours and 4 minutes ago]

Wed, 20 Mar 2024 05:49:06 GMT

Aside: New thread as original not recovered after the crash with respect 
to the news server itself, which leaves Thunderbird unable to continue it.

Ref:

https://news.povray.org/povray.beta-test/message/%3C5bdf75ab%241%40news.povray.org%3E

[insert long back story here] ... My thinking was the ini include 
searching of the library path was working fairly well despite what some 
had said.

I recently re-enabled the parsing of a users local povray.ini and 
povray.conf files stored in $HOME/.povray/3.8

Turns out. If the ini file you want isn't in your local directory - and 
the library path where it exists isn't the first listed in the reported 
library paths parsing cannot find it and dies.  :-(

The only immediately useful thing for those with $HOME/.povray 
povray.ini files, you can use the shipped ini files if you change:

     Library_Path="__POVLIBDIR__"
     Library_Path="__POVLIBDIR__/ini"
     Library_Path="__POVLIBDIR__/include"

to

     Library_Path="__POVLIBDIR__/ini"
     Library_Path="__POVLIBDIR__"
     Library_Path="__POVLIBDIR__/include"

With that change I'm able to run the following (reminder yuqk is 
linux/unix only):

     yuqk playpen.pov include_ini="quickres.ini[1024x768, AA 0.3]"

or

     yuqkZ playpen.pov +ini"quickres.ini[1024x768, AA 0.3]"

Of course, with that set up you can then only reach local directory ini 
files afterward because those are all that will be found.

I was getting fooled as to the state of things. I mostly run without 
$HOME./povray local povray.ini and povray.conf file. So, when I added 
the ini included directory to the library path files, things worked - 
because that path happened to be the first in the list of library 
directories.

Bill P.

Aside(2): The yuqk fork itself does not ship the ini directory of files 
at present. They existing ones are very much out of date.

[William F Pokorny] The github issue #458 affects v3.8 beta 2 / v4.0... [753 days 4 hours and 6 minutes ago]

Sun, 17 Mar 2024 03:47:30 GMT

See:

https://github.com/POV-Ray/povray/issues/458

Bill P.

[Thorsten] Re: Stream _file=false ini options not wor... [767 days 15 hours and 18 minutes ago]

Sat, 2 Mar 2024 16:34:49 GMT

On 02.03.2024 15:39, William F Pokorny wrote:
 > The secondary problem is ProcessOptions::IsTrue (and
 > uProcessOptions::IsFalse) use ProcessOptions::Matches which needs the
 > following code at the very top
 >
 >     if ( ((v2[0] == 0) || (v1[0] == 0)) &&
 >         !((v2[0] == 0) && (v1[0] == 0)))
 >     {
 >         return false;
 >     }
 >
 > to not, falsely, test 'true' on empty string options.
Interesting. Then I am not sure this ever worked as documented before in 
the first place: The matches-code is a straight port from 3.1 and 
according to the header there dates back to April 1994. So you probably 
found a 30 year old bug here ...

Thorsten

[William F Pokorny] Re: Stream _file=false ini options not wor... [767 days 17 hours and 13 minutes ago]

Sat, 2 Mar 2024 14:39:50 GMT

On 3/1/24 13:32, Thorsten wrote:
> I think this is more a documentation error remaining than a missing 
> feature. All this would do is turn OFF output to a file, which already 
> will only be written if it is specified in the first place ... what does 
> work is setting this to an empty string.
> 
> However, if you wanted to implement "false" it, it should be in 
> frontend/renderfrontend.cpp method RenderFrontendBase::CreateScene
> 
> Find the line
>
if(ProcessOptions::IsTrue(UCS2toSysString(shd.streamnames[gStreamNumber[i]]).c_str())
== true)
> 
> and add a case for IsFalse that sets the 
> shd.streamnames[gStreamNumber[i]] to an empty string.

Thank you, Thorsten, for digging.

Unfortunately, your suggestion to try the empty string highlights a 
secondary bug. All of the variations below direct the stream to a 
defaulted filename of debug.out in my testing (ini forms too).

yuqk debug.pov debug_file=on
yuqk debug.pov debug_file=true
yuqk debug.pov debug_file=yes
yuqk debug.pov debug_file=1
yuqk debug.pov debug_file=
yuqk debug.pov debug_file=""
yuqk debug.pov debug_file=''

The secondary problem is ProcessOptions::IsTrue (and 
uProcessOptions::IsFalse) use ProcessOptions::Matches which needs the 
following code at the very top

    if ( ((v2[0] == 0) || (v1[0] == 0)) &&
        !((v2[0] == 0) && (v1[0] == 0)))
    {
        return false;
    }

to not, falsely, test 'true' on empty string options. With that 
secondary fix in place, the following code is testing out OK for me. 
(Ugly code formatting to avoid uglier formatting on posting of code...)

Replace:

     shd.streamnames[gStreamNumber[i]] =
         obj.GetUCS2String(gStreamTypeUtilData[i]);
     if (ProcessOptions::IsTrue(
         UCS2toSysString(shd.streamnames[gStreamNumber[i]]).c_str()
         ) == true)
         shd.streamnames[gStreamNumber[i]] =
         SysToUCS2String(gStreamDefaultFile[i]);

With:

     if (ProcessOptions::IsTrue(
         UCS2toSysString(
             obj.GetUCS2String(gStreamTypeUtilData[i])
         ).c_str()) == true)
     {
         shd.streamnames[gStreamNumber[i]] =
             SysToUCS2String(gStreamDefaultFile[i]);
     }
     else if (ProcessOptions::IsFalse(
         UCS2toSysString(
             obj.GetUCS2String(gStreamTypeUtilData[i])
         ).c_str()) == true)
     {
         // Do nothing if the string indicates false (or empty).
     }
     else
     {
         shd.streamnames[gStreamNumber[i]] =
             obj.GetUCS2String(gStreamTypeUtilData[i]);
     }

Bill P.

[Thorsten] Re: Stream _file=false ini options not wor... [768 days 13 hours and 21 minutes ago]

Fri, 1 Mar 2024 18:32:24 GMT

On 01.03.2024 15:58, William F Pokorny wrote:
> It looks like these options have not functioned correctly since at least 
> v3.7.
> 
> I have not yet fixed them the yuqk fork - the fix priority is low.
> 
> The options in particular are:
> 
> all_file=false
> debug_file=false
> fatal_file=false
> render_file=false
> statistic_file=false

I think this is more a documentation error remaining than a missing 
feature. All this would do is turn OFF output to a file, which already 
will only be written if it is specified in the first place ... what does 
work is setting this to an empty string.

However, if you wanted to implement "false" it, it should be in 
frontend/renderfrontend.cpp method RenderFrontendBase::CreateScene

Find the line
if(ProcessOptions::IsTrue(UCS2toSysString(shd.streamnames[gStreamNumber[i]]).c_str()) 
== true)

and add a case for IsFalse that sets the 
shd.streamnames[gStreamNumber[i]] to an empty string.

Thorsten

[William F Pokorny] Stream _file=false ini options not working. [768 days 16 hours and 55 minutes ago]

Fri, 1 Mar 2024 14:58:07 GMT

It looks like these options have not functioned correctly since at least 
v3.7.

I have not yet fixed them the yuqk fork - the fix priority is low.

The options in particular are:

all_file=false
debug_file=false
fatal_file=false
render_file=false
statistic_file=false

Bill P.

[William F Pokorny] Command line parsing bugs with '-v+w700' [771 days 16 hours and 11 minutes ago]

Tue, 27 Feb 2024 15:42:35 GMT

Where a single character flag like +v, +d, etc. accidentally run into 
the flag after, the current official command line parsing quietly does 
nothing at all with the multi flag blob.

Adding checking to the yuqk fork to catch flag such mistakes on the 
command line as errors.

Bill P.

[William F Pokorny] Bugs related to the shell out string substitutions [771 days 16 hours and 18 minutes ago]

Tue, 27 Feb 2024 15:34:51 GMT

In the yuqk fork, fixed bugs related to the shell out string 
substitutions '%%', '%s', '%h' and '%w'. The first two are broken 
outright. The second two in defaulted situations.

These bugs look to exist back to v3.7 - though I tested only v3.8 beta 2.

While in the code I added two additional shell out string substitutions 
in %d and %e. Where %d substitutes the directory in which the scene file 
exists and %e substitutes the output image file extension.

Bill P.

[William F Pokorny] v3.8 beta 2 unix / linux ini / flag parsing mess... [791 days 17 hours and 45 minutes ago]

Wed, 7 Feb 2024 14:07:46 GMT

In official releases of POV-Ray since v3.7, where we get ini or flag 
parsing errors, the output looks something like:

Problem with option setting
<install dir>/bin/povray try
Failed to parse command-line option


For some years yuqk has done better in that it spits out more detail - 
though I have no idea what fix or change over time made that so!

That said, while the yuqk output had more useful information about the 
actual problem, it contained duplicate messages and some of those 
messages were mangled in a way indicating a string handling (or thread 
safety?) issue.

I've traced the duplication and string mangling to:

class vfeProcessRenderOptions : public ProcessRenderOptions // (*)

if vfe/vfe.h. More specifically to these message related methods:

virtual void ParseError(const char *, ...) override;
virtual void ParseErrorAt(ITextStream *, const char *, ...) override;
virtual void WriteError(const char *, ...) override;

All three methods contain the following three lines:

     m_Session->AppendStatusMessage(str);
     m_Session->AppendErrorMessage(str, file->name(), file->line(), 0);
     m_Session->SetFailed();

Comment the first one to fix the duplicate messages to the unix / linux 
terminal. Basically, the status and error messages are both ending up as 
outputs to the terminal with strange ordering - where, probably, in 
windows they do not. Eliminating the duplicates appears to have fixed 
the message mangling too where parts and pieces getting blended.

// Causes mangled duplicate messages to unix terminal
//  m_Session->AppendStatusMessage(str);
     m_Session->AppendErrorMessage(str, file->name(), file->line(), 0);
     m_Session->SetFailed();

(*) - Yep, there is some oddness in vfeProcessRenderOptions over-ridding 
complete, unix compatible, methods in the ProcessRenderOptions class for 
methods less workable. Not dug inot why the situation is as it is. There 
is likely a some cleaner solution, but for now I'm taking what I can get 
quickly.

Aside: Attempts at cleaner output using '\n' in the strings passed to 
the vfeProcessRenderOptions continue to cause problems - so the output 
below not as 'pretty' as it could be.

For same error as what tripped the short message above, yuqk now kicks out:

Possible unquoted string with spaces in INI file. Use " or ' to quote.
Cannot open INI file 'txt'.
Cannot continue to process INI file: 'boom.ini' due to a parse error in 
line 3.
Cannot continue to process INI file: 'try' due to a parse error in line 7.


Problem with option setting
<install dir>/bin/povray try
Failed to parse command-line option

Bill P.

[William F Pokorny] Re: v3.8 beta 2. Some inconsistent gamma default... [791 days 18 hours and 15 minutes ago]

Wed, 7 Feb 2024 13:38:26 GMT

On 2/5/24 02:26, William F Pokorny wrote:
> It's the direction in which I'm trying to push yuqk.

For a status update related to the yuqk fork see:

http://news.povray.org/povray.pov4.discussion.general/thread/%3C65b7935a%241%40news.povray.org%3E/

Bill P.

[William F Pokorny] Re: v3.8 beta 2. Some inconsistent gamma default... [794 days and 27 minutes ago]

Mon, 5 Feb 2024 07:26:14 GMT

On 2/4/24 16:17, Kenneth wrote:
> Although you mentioned running 3.8 beta 2, I decided to test your examples plus
> your command-line  +mv3.7 additions in 3.8 beta 1 (Windows)-- just to see if the
> behavior and returned parse warnings are the same. They all are-- except for the
> 'extra' warnings you mentioned "after bounding completes, the following
> happens..." Those do not appear. I guess that's a slight change between beta 1
> and beta 2.

Hmm. The yuqk fork 'branched off' in early 2019. The v3.8 beta 2 code 
and yuqk both have this code in the common to all executable(s) in the 
source/frontend/renderfrontend.h file. So, I'd bet against a code change 
being the reason you don't see the additional warning, but?

When running in a unix / linux terminal all the output comes back to the 
terminal where it's perhaps separated in the windows interface? <-- My 
only guess is the output is going somewhere unexpected or going 'poof' 
on windows.

> 
> [BTW: I noticed that your command-line switch for #version has an extra period
> or decimal point--  +mv.3.7  -- whereas the documentation says  +mv3.7. But
> either one seems to work OK, which surprised me.]

That's me making a typo. I checked my command history and the extra '.' 
isn't there in what I ran.

Aside: Using +mv.3.7 doesn't come back with an error (neither does 
version=.3.7). It, rather, sets the version to 1.0. Probably because a 
simple atof() is being used and the value comes in at 0.3 or similar.
Looks like the upper range isn't protected either.

I tried version=999 and surprisingly things run quickly:

"AI active. Quantum computing virtual machine version 77.3.5.1.
...
All scenes you've ever written or imagined have been rendered with every 
possible advanced option on. Output images and animations have been 
saved to your google cloud drive. Please login into your google account 
for a chat with AI_LittleIcePick12. Storage charges have exceeded 
existing credit limits and an immediate payment is due."

More seriously, I'll look at at least clamping the version range to 
something more reasonable in yuqk. Maybe extend the trial c+11 regexp 
flag checker to do more - but I've not played with that code now in years...

> 
> Actually, the ini/command-line switches for a scene's #version (and/or
> assumed_gamma) is something that I have never used; instead, I always explicitly
> state those in my scenes. But from what you mentioned here and in another recent
> thread, I get the feeling that the switches are the 'proper' way to do it-- to
> override(?) what might already be in a scene, and to avoid any possible (or
> difficult-to-track-down) problems that might crop up. Are my assumptions
> correct?
> 

If things were only black and white...

It's the direction in which I'm trying to push yuqk. For v3.8 beta 2, 
probably, it's safer to specify as a command line flag or ini option 
with the same version specified as the first line #version of your scene 
file than not. I've yet to see any evidence doing it hurts and it 
sometimes helps.

Another place the +mv sort of version spec is necessary is with the 
unspecified default camera. Meaning with the following sort of set up:

//---
#version 3.7;
global_settings { assumed_gamma 1.0 }
plane { -z, -1 pigment {rgb <1,1,0>} }
//...
#version 3.5;
sphere { <0,0,1.0> , 0.1
     pigment { rgb <0,0,1> }
     finish { emission 1 } // Yes, this generates a warning.
}
// camera {} // Specified default camera grabs current version defaults
//---        // and its use is what is seen in the right three columns

Without writing a small chapter, the second and third columns of the 
attached test image show that the ini / flag version setting is used 
when there is a leading #version statement in the scene code - over the 
version specified in that #version statement (or defaulted version).

> If so, I am curious about your c.pov example:
> 
> // c.pov file
> #version 3.7;
> global_settings { assumed_gamma 1.0 }
> //...
> #version 3.5;
> sphere { 0, 1 }
> 
> Does adding a command-line switch like +mv3.8 override BOTH of the explicit
> #version settings there? 

Certainly not for most things, but for some smaller set things / 
situations, yes.

> I have to admit that I am rather naive about all of
> this #version business and the various possible interactions.
> 

Me too! :-)

Bill P.

[Kenneth] Re: v3.8 beta 2. Some inconsistent gamma default... [794 days 10 hours and 33 minutes ago]

Sun, 4 Feb 2024 21:20:00 GMT

Although you mentioned running 3.8 beta 2, I decided to test your examples plus
your command-line  +mv3.7 additions in 3.8 beta 1 (Windows)-- just to see if the
behavior and returned parse warnings are the same. They all are-- except for the
'extra' warnings you mentioned "after bounding completes, the following
happens..." Those do not appear. I guess that's a slight change between beta 1
and beta 2.

[BTW: I noticed that your command-line switch for #version has an extra period
or decimal point--  +mv.3.7  -- whereas the documentation says  +mv3.7. But
either one seems to work OK, which surprised me.]

Actually, the ini/command-line switches for a scene's #version (and/or
assumed_gamma) is something that I have never used; instead, I always explicitly
state those in my scenes. But from what you mentioned here and in another recent
thread, I get the feeling that the switches are the 'proper' way to do it-- to
override(?) what might already be in a scene, and to avoid any possible (or
difficult-to-track-down) problems that might crop up. Are my assumptions
correct?

If so, I am curious about your c.pov example:

// c.pov file
#version 3.7;
global_settings { assumed_gamma 1.0 }
//...
#version 3.5;
sphere { 0, 1 }

Does adding a command-line switch like +mv3.8 override BOTH of the explicit
#version settings there? I have to admit that I am rather naive about all of
this #version business and the various possible interactions.

[William F Pokorny] Re: v3.8 beta 2. Some inconsistent gamma default... [794 days 17 hours and 21 minutes ago]

Sun, 4 Feb 2024 14:31:52 GMT

On 2/3/24 17:41, Cousin Ricky wrote:
> I suppose the lesson for non-developers is to*always*  set
> assumed_gamma, so that the parser, whichever version it is or is trying
> to be, doesn't have to guess.

Yes, I think that a good rule.

---
For yuqk / v4.0 still thinking about what to do with

#version <float> / version / version=<float> / +mv<float>

global_settings { assumed_gamma <...> } / internally defaulted gammas

and

defaults{} / (internal default switching)

Honestly, the more I look at the code the more muddled it all is. I 
think some of the 'fog' comes from really needing two forms of 'version' 
both internal to the source code and in POV-Ray as seen by users.

The first a 'version_gamma' and a second 'version_parsing'. Both would 
be set to a most current version default as part of the ini / flag 
mechanisms - otherwise there are things which break. The 
'version_gammaIssues' would not be chang-able after the ini / flag 
stage. The 'version_parsing' could be used with the scene's SDL to 
switch parsing behavior and the 'internal default' differences between 
major release versions.

It would also be good to get away from having both a #version directive 
and a version keyword in the Scene Description Language. It's ugly by 
set up and in code.

--- on 'assumed_gamma'  (change name to working_gamma ?)
This setting too really needs to always be set initially in the ini / 
flag stage for all other features to work properly. Probably defaulted 
by the ini / flag version options unless otherwise set explicitly there. 
Done this way suppose the global_settings { assumed_gamma ... } could 
become a check on the ini / flag gamma results in what is required by 
the scene.

Yep, I'm thinking aloud... I still don't completely understand how all 
the setting and defaulting is happening.

Bill P.

[Cousin Ricky] Re: v3.8 beta 2. Some inconsistent gamma default... [795 days 9 hours and 12 minutes ago]

Sat, 3 Feb 2024 22:41:41 GMT

On 2024-02-03 18:16 (-4), William F Pokorny wrote:
> As I work to understand the existing version handling with the idea of
> the ini / flag mechanism defaulting up front in the yuqk fork to v3.8,
> I've run across inconsistencies in how the version / gamma defaulting is
> being done in v3.8 beta 2.
> 
> The short of it is if you specify an initial version and assumed_gamma
> value things are OK I think - this the c.pov file.

I suppose the lesson for non-developers is to *always* set
assumed_gamma, so that the parser, whichever version it is or is trying
to be, doesn't have to guess.

[William F Pokorny] v3.8 beta 2. Some inconsistent gamma defaulting. [795 days 9 hours and 36 minutes ago]

Sat, 3 Feb 2024 22:16:54 GMT

As I work to understand the existing version handling with the idea of 
the ini / flag mechanism defaulting up front in the yuqk fork to v3.8, 
I've run across inconsistencies in how the version / gamma defaulting is 
being done in v3.8 beta 2.

The short of it is if you specify an initial version and assumed_gamma 
value things are OK I think - this the c.pov file.

With yuqk, I'm less concerned with pre-v3.8 compatibility - so I 
probably won't chase all of inconsistencies highlighted below.

Roughly, the code is is taking the ini / flag setting as most important 
setting of version with respect to non-specified gamma - until it 
doesn't. Further, the initial #version in the scene file doesn't seem to 
mean that much with respect to non-specified gamma handling - until it does.

Bill P.

================================================


Create the following four files:

// a.pov file
#version 3.7;
// global_settings { assumed_gamma 1.0 }
//...
#version 3.5;
sphere { 0, 1 }

// b.pov file
// #version 3.7;
// global_settings { assumed_gamma 1.0 }
//...
#version 3.5;
sphere { 0, 1 }

// c.pov file
#version 3.7;
global_settings { assumed_gamma 1.0 }
//...
#version 3.5;
sphere { 0, 1 }

// d.pov file
#version 3.5;
// global_settings { assumed_gamma 1.0 }
//...
#version 3.7;
sphere { 0, 1 }
---


Running v3.8 beta 2 with the commands:

povray a.pov   (??? The leading version setting is 3.7)
------------
Parse Warning: assumed_gamma not specified, so gamma_correction
is turned off for compatibility with this pre POV-Ray v3.7 scene.
See the documentation for more details.

povray b.pov
------------
Parse Warning: assumed_gamma not specified, so gamma_correction
is turned off for compatibility with this pre POV-Ray v3.7 scene.
See the documentation for more details.

povray c.pov
------------
<No warnings>

povray d.pov   (??? We only ended at version 3.7...)
------------
Possible Parse Error: assumed_gamma not specified in this POV-Ray
v3.7 or later scene. Future versions of POV-Ray may consider this
a fatal error. To avoid this warning, explicitly specify
'assumed_gamma 1.0' in the global_settings section. See the
documentation for more details.


povray a.pov +mv.3.7
--------------------
Parse Warning: assumed_gamma not specified, so gamma_correction
is turned off for compatibility with this pre POV-Ray v3.7 scene.
See the documentation for more details.
(And then after bounding completes, the following happens...)
-----------------------------------------------------------------
Warning: A version of 3.7 or greater was specified in an INI file
or on the command-line, but the scene finished parsing with a
#version of 3.6x or earlier and without assumed_gamma set. Output
gamma correction is being turned on as per the v3.7 default using
an assumed_gamma default of 1.0, rather than left off (which was
the v3.6.x and earlier default), because the INI file or
command-line specified version directive takes precedence.
-----------------------------------------------------------------


povray b.pov +mv.3.7
--------------------
Parse Warning: assumed_gamma not specified, so gamma_correction
is turned off for compatibility with this pre POV-Ray v3.7 scene.
See the documentation for more details.
(And then after bounding completes, the following happens...)
-----------------------------------------------------------------
Warning: A version of 3.7 or greater was specified in an INI file
or on the command-line, but the scene finished parsing with a
#version of 3.6x or earlier and without assumed_gamma set. Output
gamma correction is being turned on as per the v3.7 default using
an assumed_gamma default of 1.0, rather than left off (which was
the v3.6.x and earlier default), because the INI file or
command-line specified version directive takes precedence.
-----------------------------------------------------------------


povray c.pov +mv.3.7
--------------------
<No warnings>


povray d.pov +mv3.7  (Should do the override too, but it doesn't)
-------------------
Possible Parse Error: assumed_gamma not specified in this POV-Ray
v3.7 or later scene. Future versions of POV-Ray may consider this
a fatal error. To avoid this warning, explicitly specify
'assumed_gamma 1.0' in the global_settings section. See the
documentation for more details.

[William F Pokorny] A v3.8 onward bug in version initialization. [801 days 11 hours and 18 minutes ago]

Sun, 28 Jan 2024 20:35:31 GMT

Found a v3.8 onward bug(*) while running a scene Kenneth posted in this 
thread:

https://news.povray.org/povray.binaries.programming/thread/%3C65b14502%40news.povray.org%3E/

The internal version defaulting sometimes does not run leaving the 
values which should be set by the defaulting mechanism to whatever 
defaulting is otherwise done on the creation of initial scene data.

In parser.cpp and the function Parser::Run() there is a call to 
InitDefaults(). Whether InitDefaults() does anything depends on whether 
the initial version selects the DefaultsVersion::kLegacy set or the 
DefaultsVersion::k380 set; Further, after the selection, whether the set 
of version defaults is different than that set just above the call to 
InitDefaults() pointed to with the variable defaultsVersion.

If the defaultVersion aligns with DefaultsVersion, InitDefaults() does 
nothing. There are only two states, so half the time it doesn't do the 
initialization it should(*). We need three DefaultsVersion states to 
force InitDefaults() to always run at least once at the start of parsing.

The fix
-------

In parser.h change:

         enum class DefaultsVersion : char
         {
             kLegacy,  ///< Pre-v3.8 defaults.
             k380,     ///< v3.8.0 defaults.
         };

to:

         enum class DefaultsVersion : char
         {
             kInvalid, ///< Use in Parser::Run() as initial default.
             kLegacy,  ///< Pre-v3.8 defaults.
             k380,     ///< v3.8.0 defaults.
         };

In parser.cpp and Parser::Run(), before the InitDefaults() call, change:

             defaultsVersion = DefaultsVersion::kLegacy;
or
             defaultsVersion = DefaultsVersion::k380;

to:

             defaultsVersion = DefaultsVersion::kInvalid;


(*) - There are many ways the bug can be hidden by option and scene 
settings. It might be too, even if tripping the bug, the internal 
defaulting of values outside of InitDefaults() aligns with the 
particular scene being run - and so no ill effects are seen.

Bill P.

[William F Pokorny] Re: A v3.8 / v4.0 / yuqk vector tuple assignment... [879 days 9 hours and 23 minutes ago]

Sat, 11 Nov 2023 22:30:10 GMT

On 11/6/23 11:29, William F Pokorny wrote:
> I've take a run or two at forcing the semicolon in this one tuple / 
> batch assignment type, but so far I'm failing there too. That said, I 
> think this the more likely outcome at the moment.

I believe this fixed in the yuqk fork - in that lack of a semicolon is 
now flagged as an error. Only took a week... :-(

Bill P.

Details for those interested.
-----------------------------

Added an optional parameter in hereViaRValue defaulted false to:

Parse_Unknown_Vector()

called from Parser::Parse_RValue() and set true. Plus to

Parse_Express(expr, &terms, true)

called from Parser::Parse_Declare() and set true.

Plus to a set of expression related functions and calls in 
parser_expressions.cpp so the proper indication of the 'right value 
parsing' state exists in the function called Parser::Parse_Num_Factor() 
where the vector dot access parsing happens near the bottom.

It appears when the dot access methods were coded, the right side 
parsing state was never extended down into Parse_Num_Factor(). Further, 
necessary checking for semicolons was never created. Such checking needs 
to know whether the parser was in a right hand value parsing state.

This despite code being used where the dot access bit sometimes, 
necessarily, is triggering the execution of directives coded right in 
the middle of other work parsing work(a).

(a) - The triggering by way of a side effect of somewhere down the call 
chains grabbing directive tokens while the parser is in a state which 
allows the mid stream directives.

What all this means.

In the yuqk fork, the vector form of tuple / batch / list ID assignments 
should work. Further, due the additional checking down in the dot access 
methods for semicolons, it should be much less likely other non-tuple 
form vector type assignments can cause unwanted side effects due the 
lack of a semicolon. It would have been complicated SDL code which fell 
into the trap previously. If users previously tripped it, and got 
confusing results, my bet is they probably simplified their code - and 
things began to work.

I offer no equivalent v3.8 parser fixes beyond what can be found in my 
code or the description herein. Partly, this because I leaned on some 
newer yuqk / v4.0 parser functionality for the fix but, the update is 
complicated and I'm not going to try and replicate it in another version 
of parser code.

Disclaimer. There are simply too many paths into Parse_Num_Factor() for 
me to be 100% sure all situations which could be a problem are fixed. My 
test cases are clean... It's better than it was.

[William F Pokorny] Re: A v3.8 / v4.0 / yuqk vector tuple assignment... [884 days 15 hours and 24 minutes ago]

Mon, 6 Nov 2023 16:29:25 GMT

On 11/6/23 10:04, William F Pokorny wrote:
> All seems to work except the mandatory semicolon bit is not enforced by 
> the parser!
> 
> This means the following code runs without complaint, but incorrectly.
> 
>  Â Â Â  #declare <A0,A1,A2> = <3,2,1>; // This works.
>  Â Â Â  #declare <A0,A1,A2> = <1,2,3>Â  //
This only appears to work
> 
Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â 
// Meaning no parse error
>  Â Â Â  #debug concat("A0 = ",str(A0,3,1),"\n")
>  Â Â Â  #debug concat("A1 = ",str(A1,3,1),"\n")
>  Â Â Â  #debug concat("A2 = ",str(A2,3,1),"\n")
> 
>  Â Â Â  #error "Stopping at parse test end\n"
> 
> The exposure made worse because in other applications, the tuple ID 
> assignments treat the trailing semicolon as optional.

An update. It was apparent once I dug through the code that clipka 
intended for the vector form to work like other tuple assignments in not 
needing a trailing semicolon, but allowing one.

The vector tuple form is broken in all parsers since mid 2015 in not 
working as intended or failing for lack of semicolons.

Try as I might over the past few days, I've not been able to make it 
work as intended without breaking the general ability to declare things 
nearly anywhere.

A capability which looks to be the primary reason we sometimes need 
semicolons. We need to somehow mark the end of all the '#' language 
directives where we allow them in the middle of a other parsing.

It's also very much related to how grabbing a single token can sometimes 
cause the parser to eat up a bunch of scene code and do nothing with it. 
This last is exactly what is happening in the sample code up top. It is 
what was happening with this recent bug find too:

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

I've take a run or two at forcing the semicolon in this one tuple / 
batch assignment type, but so far I'm failing there too. That said, I 
think this the more likely outcome at the moment.

Bill P.

[William F Pokorny] Re: A v3.8 / v4.0 / yuqk vector tuple assignment... [884 days 16 hours and 48 minutes ago]

Mon, 6 Nov 2023 15:04:59 GMT

On 11/4/23 03:07, William F Pokorny wrote:
> Attempting to attach original post as text file.

Attempting again to post about issue again with Chris's spam filter fix 
in place.

  I've been working through more tuple (batch) ID assignment test cases. 
In the documentation I've been able to turn up for the original tuple 
capability, there was this bit related to assigning components of 
vectors to individual identifiers:

---
In addition, a similar syntax extension has been added for easier 
assignment of vector components to individual variables:

     #declare < ID1, ID2, ... > = VECTOR_EXPR;

This statement is fully equivalent to:

     #local TEMP = VECTOR_EXPR;
     #declare ID1 = TEMP.x;
     #declare IDY = TEMP.y;
    ...

except that the new syntax does not actually define a local variable 
named TEMP.  The terminating semicolon is mandatory.
---

All seems to work except the mandatory semicolon bit is not enforced by 
the parser!

This means the following code runs without complaint, but incorrectly.

     #declare <A0,A1,A2> = <3,2,1>; // This works.
     #declare <A0,A1,A2> = <1,2,3>  // This only appears to work
                                    // Meaning no parse error
     #debug concat("A0 = ",str(A0,3,1),"\n")
     #debug concat("A1 = ",str(A1,3,1),"\n")
     #debug concat("A2 = ",str(A2,3,1),"\n")

     #error "Stopping at parse test end\n"

The exposure made worse because in other applications, the tuple ID 
assignments treat the trailing semicolon as optional.

Bill P.

[William F Pokorny] Re: A v3.8 / v4.0 / yuqk vector tuple assignment... [887 days and 45 minutes ago]

Sat, 4 Nov 2023 07:07:59 GMT

On 11/4/23 03:04, William F Pokorny wrote:
> There is a bug specific tuple (batch) ID assignments from vectors.
> 
> The detail for which is again being eaten by the spam filter.
> 
> Bill P.

Attempting to attach original post as text file.

[William F Pokorny] A v3.8 / v4.0 / yuqk vector tuple assignment iss... [887 days and 49 minutes ago]

Sat, 4 Nov 2023 07:04:25 GMT

There is a bug specific tuple (batch) ID assignments from vectors.

The detail for which is again being eaten by the spam filter.

Bill P.

[William F Pokorny] Re: v3.8 b2. Deprecated feature doesn't work wit... [891 days 13 hours and 20 minutes ago]

Mon, 30 Oct 2023 18:33:12 GMT

On 10/29/23 01:04, Chris Cason wrote:
> ok. sorry didn't get to fix it, I've been clobbered with a particularly 
> nasty variant of the flu going around Australia right now. normally only 
> takes me a few days to get over a flu, approaching 10 days now.

I hope you're feeling better.

It was not my older fork name and I had not much luck in isolating the 
cause for the spam rejection.

It seems to be some longer span 'rejection rule match'.

See the rejected posts to povray.test with the Fourteenth (and 
Fifteenth) runs at the spam filter for the smallest posts I managed 
still getting rejected. Both about half the size of the original.

Get well. No rush.

Bill P.

[Chris Cason] Re: v3.8 b2. Deprecated feature doesn't work wit... [893 days 2 hours and 49 minutes ago]

Sun, 29 Oct 2023 05:04:33 GMT

On 28/10/2023 22:04, William F Pokorny wrote:
> On 10/25/23 09:30, Chris Cason wrote:
>> Donâ€™t worry about renaming it yet, I need to run it through the
spam filter
>> manually and find what specifically is tripping it up. Will do that today.
>>
> 
> Chris,
> 
> FYI. I've started the work to rename the fork. I want to get away from from the
adult site name in any case.
> 
> Once done, I'll try a post to povray.test of the original text, except with my new
fork name. If it still gets rejected, I can find the issue myself with repeated posts
to p.test. You can take this work item off your plate - except for any eventual spam
filter update, should one still be needed.

ok. sorry didn't get to fix it, I've been clobbered with a particularly nasty variant
of the flu going around Australia right now. normally only takes me a few days to get
over a flu, approaching 10 days now.

[William F Pokorny] Re: v3.8 b2. Deprecated feature doesn't work wit... [893 days 20 hours and 49 minutes ago]

Sat, 28 Oct 2023 11:04:18 GMT

On 10/25/23 09:30, Chris Cason wrote:
> Donâ€™t worry about renaming it yet, I need to run it through the
spam filter
> manually and find what specifically is tripping it up. Will do that today.
> 

Chris,

FYI. I've started the work to rename the fork. I want to get away from 
from the adult site name in any case.

Once done, I'll try a post to povray.test of the original text, except 
with my new fork name. If it still gets rejected, I can find the issue 
myself with repeated posts to p.test. You can take this work item off 
your plate - except for any eventual spam filter update, should one 
still be needed.

Bill P.

[Bald Eagle] Re: v3.8. Other than macro use of optional featu... [896 days 12 hours and 23 minutes ago]

Wed, 25 Oct 2023 19:30:00 GMT

William F Pokorny <ano### [at] anonymousorg> wrote:

> I was only aware of (or only remember) the macro usage, but it's
> supported more broadly - and since June 2015! I found a
> 'news-submissions post from clipka announcing new features which
> included 'optional'.

Yes, I remember that exact post - but I don't remember the application to
arrays!
Thanks for bumping that.


http://news.povray.org/povray.news-submissions/thread/%3C558b4c09%241%40news.povray.org%3E/

That could certainly be useful - you're certainly giving the parser a workout
with some interesting test cases   :O

- BW

[William F Pokorny] v3.8. Other than macro use of optional feature? [896 days 18 hours and 15 minutes ago]

Wed, 25 Oct 2023 13:38:13 GMT

Is anyone using the v3.8 'optional' feature for more than macro arguments?

---
On looking at deprecated, global and local keywords of late, my eye 
caught code related to 'optional' where I didn't expect it.

I was only aware of (or only remember) the macro usage, but it's 
supported more broadly - and since June 2015! I found a 
'news-submissions post from clipka announcing new features which 
included 'optional'.

Not sure what all of it works today. Some things mentioned there that 
I've tried no longer function, while some do. I have gotten to trying 
everything mentioned. Not have I tried to work out from the code the 
more complicated ways 'optional' might be used.

This kind of thing does work:

//---
// #declare Z = "gack\n";

#declare optional A = Z;

#local optional deprecated B = Z;
//---


Any extended use of optional will complicate the question as to whether 
some word is a defined identifier - it might not be until something 
else, or some chain of something 'elses' is defined.

A and B are not (by the immediately following lines of code at least) 
considered defined with the declare of Z commented.

My initial thought is the extended use is not all that useful and it 
opens up ways for very confusing things to happen on editing scenes.

However, there is a dictionary form, and one with tuple assignments in 
the news post. Those might be useful - but I've not tested what of those 
forms are working in v3.8.

Bill P.

[Chris Cason] Re: v3.8 b2. Deprecated feature doesn't work wit... [896 days 18 hours and 23 minutes ago]

Wed, 25 Oct 2023 13:30:28 GMT

Donâ€™t worry about renaming it yet, I need to run it through the spam
filter
manually and find what specifically is tripping it up. Will do that today.

[William F Pokorny] Re: v3.8 b2. Deprecated feature doesn't work wit... [896 days 19 hours ago]

Wed, 25 Oct 2023 12:53:20 GMT

On 10/24/23 00:25, Chris Cason wrote:
> On 24/10/2023 00:59, William F Pokorny wrote:
>> That showed up and I tried again to send my long response. It again is 
>> in my sent folder, but otherwise again went poof... :-(
> 
> The spam filter ate it (and the previous). I'll try to work out what's 
> triggering it and either remove that factor or find a way to exempt your 
> posts.
> 
> -- Chris
> 

I had the thought maybe my glitching head had dropped a 'bad word' into 
my rejected post. I carefully read what I'd sent again, but it all 
looked innocuous.

Made some coffee, took a few sips, and I thought to search on my 
playpen's fork name. Dang, a gazillion adult sites pop up. When I picked 
that name I saw only a few unimportant collisions on searching the web.

Well _____(a). I guess, moving to another fork name is now at the top of 
my to do list no matter the reason the spam filter tripped. What a pain.

Something obscure, z_4_  ?

Except, jr, wouldn't like having to use the shift key...

Bill P.

(a) - That was a bad word.

[William F Pokorny] Re: v3.8 b2. Deprecated feature doesn't work wit... [897 days 20 hours and 50 minutes ago]

Tue, 24 Oct 2023 11:03:28 GMT

On 10/24/23 00:25, Chris Cason wrote:
> On 24/10/2023 00:59, William F Pokorny wrote:
>> That showed up and I tried again to send my long response. It again is 
>> in my sent folder, but otherwise again went poof... :-(
> 
> The spam filter ate it (and the previous). I'll try to work out what's 
> triggering it and either remove that factor or find a way to exempt your 
> posts.
> 
> -- Chris
> 
Thank you Chris.

Bill P.

[Chris Cason] Re: v3.8 b2. Deprecated feature doesn't work wit... [898 days 3 hours and 27 minutes ago]

Tue, 24 Oct 2023 04:25:44 GMT

On 24/10/2023 00:59, William F Pokorny wrote:
> That showed up and I tried again to send my long response. It again is in my sent
folder, but otherwise again went poof... :-(

The spam filter ate it (and the previous). I'll try to work out what's triggering it
and either remove that factor or find a way to exempt your posts.

-- Chris

[William F Pokorny] Re: v3.8 b2. Deprecated feature doesn't work wit... [898 days 17 hours and 54 minutes ago]

Mon, 23 Oct 2023 13:59:00 GMT

On 10/23/23 09:43, William F Pokorny wrote:
> On 10/22/23 15:39, jr wrote:
>> would dropping the 'global' make an actual difference ?
> 
> Sure. Whether the difference matters depends on - stuff.
> 
> (Above a MUCH shorter response than I tried to send a while ago from 
> thunderbird. A response sitting in my sent folder, but thus far it has 
> not shown up elsewhere? I this doesn't work, I'll ping you via email 
> directly)
> 
> Bill P.

That showed up and I tried again to send my long response. It again is 
in my sent folder, but otherwise again went poof... :-(

Suppose beyond my thinking while writing it, my ramblings don't rate 
much for general value in any case.

I'm going to work on other stuff for a while. :-)

Bill P.

[William F Pokorny] Re: v3.8 b2. Deprecated feature doesn't work wit... [898 days 18 hours and 9 minutes ago]

Mon, 23 Oct 2023 13:43:48 GMT

On 10/22/23 15:39, jr wrote:
> would dropping the 'global' make an actual difference ?

Sure. Whether the difference matters depends on - stuff.

(Above a MUCH shorter response than I tried to send a while ago from 
thunderbird. A response sitting in my sent folder, but thus far it has 
not shown up elsewhere? I this doesn't work, I'll ping you via email 
directly)

Bill P.

[jr] Re: v3.8 b2. Deprecated feature doesn't work wit... [899 days 12 hours and 13 minutes ago]

Sun, 22 Oct 2023 19:40:00 GMT

hi,

William F Pokorny <ano### [at] anonymousorg> wrote:
> The #declare / #local, deprecated sub-feature does not function when the
> reference to the identifiers is done via the 'global' and 'local' pseudo
> dictionaries(*).
> ...
> (*) As mentioned in an earlier post to beta-test, I don't presently
> recommend any pseudo dictionary use in v3.8 beyond the #macro local.
> testing for optional parameter defaults.

for instance, if I have 'A.pov' and 'A.inc', and the latter '#include's another
file ('filed.inc', in this particular situation), I have taken to writing in
'A.inc' eg:

#ifdef (global.fild_workingDir)
  ...
#end

would dropping the 'global' make an actual difference ?


regards, jr.

[William F Pokorny] Re: Bug and detail for, new at v3.8, global and ... [899 days 14 hours and 45 minutes ago]

Sun, 22 Oct 2023 17:08:20 GMT

On 10/22/23 10:36, Bald Eagle wrote:
> I've experimented with tracking the nesting level of the SDL code in the 
> past, and maybe there's a way to make that visible to the SDL from 
> within source without slowing things down / adding too much overhead.

Unsure in total, what sort of tracking you mean, but...

I did take a run in povr at a debug option for the include files and it 
is still available via the environment variable: 
POV_PARSER_File_Text_INC_DEBUG, but with scenes making use of the 
parse_string / Parse_String macro for dynamic SDL code it's unusable as 
one drowns in debug output so it isn't today a run time povr option.

It's on my list to create a parse_string feature which doesn't use the 
include file mechanism, but some sort of 'memory file' instead.

> Also, I'm wondering if in your povr branch, you could try addressing the 
> highly ambiguous "#end" directive and switching over to #endif #endfor 
> etc. 

Yeah, I find myself typing #endif all the time when coding SDL! It's not 
all that easy to implement differing 'end tokens' unfortunately; So, 
it's not a near term povr work item.

> Since you're coding source (in C? c++?), it would be interesting to 
> hear your "ramblings" on the types of data structures and code-flow 
> directives we're currently missing in SDL that you think would be of 
> use. 

:-) Expect the list here goes on for a while and general 'list' (c++ 
vector) support one feature I'd like(*). I'll leave further rambling on 
this topic for another day.

(*) Some work has been done in this direction by jr and others with 
include files.

> Great work tracking down these parse errors. They can seriously 
> challenge one's sanity when trying to debug scenes in SDL.

Thanks & agree (my sanity is questionable as is).

Took a quick look at your reference to the kumiko triangles project and 
I realize I didn't test 'deprecated' or the 'global', 'local' pseudo 
dictionaries with tuple assignments. The combinations go on and on...

-----
With the pseudo dictionaries my current recommendation would be to use 
only in #macro 'local.' ones.

On writing that, I had the thought we can, I think, implement a 
trustworthy 'global.' test, at least, inside macros with something like:

#if ((!defined(local.V123)) & (defined(V123)))
...
#end

Pending fixes / changes, I'd say stay away 'global' altogether and use 
'local' only within macros for conditional tests or references. Further, 
don't do any assignment / redefinition / undef of identifiers via the 
'global' and 'local' dictionaries.

In povr, wondering if I can make 'global' pseudo dictionary use a parse 
error for now... I worry about where I have myself used it. I know it's 
there in povr's shipped munctions.inc and setidtypes.inc includes. 
Probably none of my 'global' use is absolutely necessary in those though.

What if, we change the expected and documented behavior from:

"Included are the two pseudo-dictionaries local and global they 
represent the most local and the least local or global identifiers 
respectively."

to be:

"Included are the two pseudo-dictionaries local and global, they 
represent the most local and the scene's top file's identifiers 
respectively."

???

The latter is closer to what we have today by implementation. Then we'd 
probably need a new way(s) to create / modify / undef identifiers which 
strictly works with the top file's identifiers. A #top V123 = 123; which 
would bypass any identifier name masking.

The 'least local' which are not today (always?) in the global dictionary 
could be isolated with the code posted above or

#if ((!defined(global.V123)) & (!defined(local.V123)) & (defined(V123)))
...
#end

depending on needs.

Hmm. Is that enough to handle aimed modifications. Maybe, yes, except 
where the #local masking is more than one instance deep(a), but we 
probably don't much need to whack the intermediate locals. They go away 
when we exit the macro or file context, so undef useless there really - 
and redefinition too seems unlikely excepting maybe as a way to 'return 
values' from a included file's context(a).

(a) - There is sort of a "most global, not top level" class of 
identifiers possible too I guess.

I don't know. Thinking aloud...

Might be simpler to fix the bug / match what is documented for behavior, 
but it leaves the pseudo dictionaries as less of a solution to 
identifier name masking than perhaps they could be.

Bill P.

[William F Pokorny] v3.8 b2. Bug(s) with deprecated feature [899 days 16 hours and 52 minutes ago]

Sun, 22 Oct 2023 15:01:15 GMT

I had the thought the deprecated feature could be a way to track or 
inquire about the home scope of particular identifier names. It should 
be the deprecated message follows the identifier around as long it 
exists. This being, perhaps, a use making the the feature more worthwhile.

Again I set up a scene hierarchy of:

     A.pov -> B.inc -> C.inc

Where I used #declare or #local I made use of the deprecated feature. In 
A.pov, for example, I set up identifiers A and B:

#declare deprecated "Referenced A 'declared' in file A.pov" A = "A\n"
#local deprecated "Referenced B 'localed' in file A.pov" B = "B\n"

and so on into C.inc where I added this #local declaration of A which is 
entirely local to C.inc:

#local deprecated "Referenced A 'localed' in file C.inc" A = "A_l\n"

What happens might or might not be the same bug. I'm not going to 
further debug and try and work up a fix. The 'deprecated' feature is 
going away in the povr fork.

For v3.8 b2:

Bug 1.
The #local 'A' creation in C.inc has nothing to do with the global 'A', 
however, POV-Ray issues the deprecated message as if the global 'A' in 
A.pov is being referenced. It does this whether or not the #local in 
C.inc of A uses the deprecated feature itself.

Bug 2. The follow on reference to the local A in C.inc returns the 
correct local to C.inc 'A' value, but no deprecated message at all - 
though I specified one. Other #local use where there is no name 
collision with a more global identifiers to work fine with the 
deprecated feature.

Aside: I previously mentioned the deprecated feature is not working with 
the 'global' and 'local' pseudo dictionaries in this thread:

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

Lastly, I've attached a tarball with the code I was using that exposed 
the bug(s).

Bill P.

[Bald Eagle] Re: Bug and detail for, new at v3.8, global and ... [899 days 17 hours and 13 minutes ago]

Sun, 22 Oct 2023 14:40:00 GMT

William F Pokorny <ano### [at] anonymousorg> wrote:

> The implication here, if leaning on the local / global dictionaries to
> decide things in your scene, is that the conditional test results will
> change as you move code about in the hierarchy of files. Some of this we
> might expect, while other behavior very likely not.

Hi Bill,

It looks like you may be finally touching on the elusive bug that has plagued me
in a number of "recent" projects - where I was having problems with certain
macro results not being defined, especially (it seemed) when I was running those
macros from within include files.

I'm not sure if I posted full code for those examples or not, and it's a bit
worrisome, since it suggests that more such things may be lurking in the parser
- and even more worrisome - that there may be some fundamentally flawed
logic/implementation in the way the entire parser is structured (aside from the
obvious things that we've discussed over the past decade(s) ;) )

I can't recall all of the various instances where I've run into these problems,
but certainly it was a recurring theme in the kumiko triangles project:

https://news.povray.org/povray.advanced-users/thread/%3Cweb.64209db9e0deeaab1f9dae3025979125%40news.povray.org%3E/

I've experimented with tracking the nesting level of the SDL code in the past,
and maybe there's a way to make that visible to the SDL from within source
without slowing things down / adding too much overhead.

Also, I'm wondering if in your povr branch, you could try addressing the highly
ambiguous "#end" directive and switching over to #endif #endfor etc.

Since you're coding source (in C?  c++?), it would be interesting to hear your
"ramblings" on the types of data structures and code-flow directives we're
currently missing in SDL that you think would be of use.

Great work tracking down these parse errors.   They can seriously challenge
one's sanity when trying to debug scenes in SDL.

- BW

[William F Pokorny] v3.8 b2. Deprecated feature doesn't work with ps... [900 days 6 hours and 35 minutes ago]

Sun, 22 Oct 2023 01:18:38 GMT

The #declare / #local, deprecated sub-feature does not function when the 
reference to the identifiers is done via the 'global' and 'local' pseudo 
dictionaries(*).

Aside:
With the povr fork, I'm considering dropping the 'deprecated' feature 
given the extremely light usage in official POV-Ray releases. There is 
no use in povr itself today.

It is an expensive parse time feature given the benefit. Every reference 
to identifiers during parsing - even with 'once' use - must be checked 
to support it.

We can issue deprecated messages without it for existing scene 
description language implemented features, only once, when they are 
included or defined, but not on actual usage of the SDL feature.

And... There look to be bug(s?) with the deprecated feature itself which 
I'll post about at a later time.

(*) As mentioned in an earlier post to beta-test, I don't presently 
recommend any pseudo dictionary use in v3.8 beyond the #macro local. 
testing for optional parameter defaults.

Bill P.

[William F Pokorny] v3.8 parse issue related to bare 'global' and 'l... [900 days 18 hours and 43 minutes ago]

Sat, 21 Oct 2023 13:10:05 GMT

While fixing parsing issues in the povr/v4.0 fork's newer parser related 
to the 'global' and 'local' keywords, I found some are also exposures in 
the v3.8 beta 2 release too. Namely, some bare word situations are not 
being flagged that the source code intends to be errors - and which 
should be parse errors.

Code like:

//----

local
global

#...

// Which are more likely to come up where a user might try:

#local   localDict = local
#declare globalDict = global

#...

// Neither assignment above works properly, but the v3.8 parser does
// not complain. The povr fork's parser will in the next release.

//----

I only briefly looked at the relate v3.8 source, but the cause in both 
the old and new parsers looks to be the same.

In the file parser_tokenizer.cpp and the function Parser::Read_Symbol() 
there is code related to handling the two pseudo dictionaries. Look for 
the text 'pseudoDictionary'. In that code there is a line which reads:

Get_Token(); // ensures the error is reported at the right token

Delete the line or comment it. What happens is that call to Get_Token() 
- one intended to better point to the error column position - jumps the 
parsing state ahead if the next token is '#'. In other words, it jumps 
the parser past the following Warning() and Expectation_Error() calls!

Weird, but, it is what it is.

Bill P.

[William F Pokorny] Bug and detail for, new at v3.8, global and loca... [901 days 13 hours and 3 minutes ago]

Fri, 20 Oct 2023 18:49:53 GMT

If using the local and global, parsing automatic, dictionaries, it's 
safe to use local dictionary test inside macros. This capability is 
essential to the macro, optional parameter defaulting also new to v3.8.

#macro Foo(P1, optional P2)
#ifndef(local.P2) #local P2 = 0; #end // provide default for P2
...
#end

Otherwise, be very careful as there is at least one bug and also some 
complicated behavior - which might or might not be the best thing to 
do... Basically, other documented behavior may or may not work!

Details
-------------------------

Recently, I again wondered, how the, new at v3.8 and later, 'global' and 
'local' dictionaries of identifiers worked at the very top level. The 
#local identifiers are effectively globals when used at the very top of 
the scene hierarchy.

Well, in the top file, #local identifiers are added to both the parser's 
automatic local and global dictionaries of identifiers. Also true for 
all #declare identifiers, declares from the command line, #for loops 
iteration variables (treated internally as non-scoped #local(s)) and 
such in the top file.

The implication here, if leaning on the local / global dictionaries to 
decide things in your scene, is that the conditional test results will 
change as you move code about in the hierarchy of files. Some of this we 
might expect, while other behavior very likely not.

The bug
----------------------
I went on to do a bunch of test cases on and off over a the past couple 
days and that testing turned up relatively basic bug.

If we have three files in A.pov, B.inc, and C.inc where the include 
chain is:

A.pov -> B.inc -> C.inc

where we have #local identifiers defined in B.inc, these are not getting 
added to the global (or local for that matter) dictionary while reading 
/ including C.inc. This a bug.

Those B.inc scoped variables are effectively global for the code in 
C.inc. A #declare in C.inc for #local identifier names in B.inc will 
update those identifiers in the B.inc scope - ones 'effectively global' 
while in C.inc. The #ifdef(), #ifndef() and defined() all return the 
appropriate results for the #local identifiers in B.inc. Namely, those 
older features see the the #local names in B.inc as defined while in 
C.inc. I've attached a failing test case tarball set up with A.pov -> 
B.inc -> C.inc.

Aside: I suspect this bug might have gotten passed us due the top level 
seeing all the methods of setting up identifiers as creating global ones 
(and local). If we imagine the testing was done with something more 
like: A.pov -> B.inc alone. Well, things work then because of that 
global/local duality in the very top file.

Not sure when I'll get around to looking at the bug. My current leaning 
for the global/local duality at the top is everything should be in the 
global dictionary and not the local one too, but, I should let that 
thought bang around in my head for a while.

Bill P.

[William F Pokorny] Broken sqr() function implementation. [975 days 19 hours and 20 minutes ago]

Mon, 7 Aug 2023 12:32:45 GMT

There is a long broken (back to v3.7 at least) sqr() function 
implementation sitting in our code.

The fix in my povr (near v3.8) code base was done all in the 
source/parser directory.

In the files reservedwords.h and reservedwords.cpp move SQR_TOKEN to be 
just above SQRT_TOKEN. The order matters in this case.

Plus, in parser_functions.cpp, add the lines:

      case SQR_TOKEN:
          result = pow(node->child->number,2.0);
          break;

adjacent to those for the SQRT_TOKEN code.

Once fixed, sqr() will work both in the parser and within functions at 
parse time or run time.

Aside: In regular releases I believe there was a f_sqr() function 
defined. In the povr fork this now a munction resulting in an F_sqr 
function being defined/compiled.

Bill P.

[William F Pokorny] Re: Assigning an interior crashes 3.8 beta 2 [985 days 18 hours and 40 minutes ago]

Fri, 28 Jul 2023 13:13:06 GMT

On 5/11/23 07:49, William F Pokorny wrote:
> At the bottom the issue here seems to be that the first created interior 
> gets deleted before the copy in the symbol table code. There was an 
> attempt to move to smart pointers on removing the reference counting in 
> v3.7, and something went wrong there. I just cannot yet see it - or how 
> I might patch it.

I've spent a little more time on this and I don't currently see a clean 
way to fix this issue. Well, other than returning to a plain pointer and 
reference counting as in v3.7 (and v3.8 to some point during development).

Given how the parser is set up, v3.8 is running smart, shared, interior 
pointers through casts to a void pointer and back to a shared pointers.

Pending an actual fix, I strongly recommend v3.8 add a throw in 
symboltable.cpp just after the switch "case INTERIOR_ID_TOKEN:". 
Something like:

throw POV_EXCEPTION_STRING("Interior ID = ID copies broken in v3.8");

While likely the garbage in memory pointed to after the attempted 
interior ID copy will stink enough to crash code somewhere within 
POV-Ray(a), a scene with such a copy could 'execute' without a crash - 
if one is unlucky.

Bill P.

(a) - It's not the actual copy which crashes, but some later operation 
on garbage data.

[Bald Eagle] Re: Assigning an interior crashes 3.8 beta 2 [1063 days 14 hours and 28 minutes ago]

Thu, 11 May 2023 17:25:00 GMT

William F Pokorny <ano### [at] anonymousorg> wrote:

> The form and feel of this bug rings a bell. There was some other bug
> recently due a similar move from reference counting to smart pointers
> that I patched by creating a local copy of something to itself be what
> was really copied because the original smart pointer controlled to be
> copied version was going poof too quickly.

Yeah - I vaguely recall that too.  Was it with the heightfield stuff?

[William F Pokorny] Re: Assigning an interior crashes 3.8 beta 2 [1063 days 20 hours and 3 minutes ago]

Thu, 11 May 2023 11:49:58 GMT

On 5/9/23 09:14, Cousin Ricky wrote:
> The following scene crashes with the error:
> 
>    line 4: Parse Error: std::bad_alloc
> 
> ----------[BEGIN CODE]----------
> #version max (3.5, min (3.8, version));
> global_settings { assumed_gamma 1 }
> #declare Int = interior { ior 1.5 }
> #declare myInt = Int
> -----------[END CODE]-----------
> 
> The discontinued 3.7.1-rc.1 also crashes, but previous versions of
> POV-Ray do not.
> 
> POV-Ray version: POV-Ray 3.8.0-beta.2 (self-compiled)
> Operating system: openSUSE Leap 15.3 GNU/Linux
> Hardware: Lenovo Ideapad Slim 7
> CPU: Intel Core i7

Thanks Cousin Ricky and Kenneth and jr for confirmations and tests with 
other shapes. I've been looking at this, but will be away for a while 
starting later today.

So, an update.

At the bottom the issue here seems to be that the first created interior 
gets deleted before the copy in the symbol table code. There was an 
attempt to move to smart pointers on removing the reference counting in 
v3.7, and something went wrong there. I just cannot yet see it - or how 
I might patch it.

The form and feel of this bug rings a bell. There was some other bug 
recently due a similar move from reference counting to smart pointers 
that I patched by creating a local copy of something to itself be what 
was really copied because the original smart pointer controlled to be 
copied version was going poof too quickly.

Bill P.

---
More for those interested.

a) What I suspect here and with that other bug (I can't completely 
remember at the moment...) is that thinking a smart pointer can always 
simply replace reference counting method is dangerous.

I believe what's happening is the reference counting previous had 
different in timing with respect to when some allocated thing was 
'counted' as no longer referenced then deleted than the scope based auto 
magic happening with smart pointers to do the reference tracking and 
deletion. I think the latter tends to clean up faster.

b) There is on top of the issue above another in that the template 
function introduced in the symbol table code depends on there being a 
valid form of an = type object copy. There was none.

Someone had added an explicit bit of C++ preventing an '=' overload for 
the copy. I don't know why. I cannot see a reason for it.

So, I fixed things so there was a proper = overload as there is with 
some other things (media, camera..) using the same template id copying 
function in the symbol table code. But, the core issue was still there - 
which didn't surprise me too much.

And why was that? Well in a happy world where C++ helps you, the 
compiler would have just died on not finding the matching '=' copy. The 
lack of the '=' copy was just something I noticed. My, unconfirmed, 
suspicion is all the casting to void pointers happening within that 
template function, bypassed the C++ feature preventing the original '=' 
sort of object copy of interiors.

Anyhow. No idea when I'll get back to this. The free time I'll have in 
the coming weeks amounts to small run fragments.

[jr] Re: Assigning an interior crashes 3.8 beta 2 [1065 days 11 hours and 23 minutes ago]

Tue, 9 May 2023 20:30:00 GMT

hi,

Cousin Ricky <ric### [at] yahoocom> wrote:
> The following scene crashes with the error:
> ...
> POV-Ray version: POV-Ray 3.8.0-beta.2 (self-compiled)

same for self-compiled 3.8.0-alpha.9945627.


regards, jr.

[Kenneth] Re: Assigning an interior crashes 3.8 beta 2 [1065 days 18 hours and 3 minutes ago]

Tue, 9 May 2023 13:50:00 GMT

I just tried a similar construct using a pigment instead of an interior--
thinking that the same error might occur...

#version max (3.5, min (3.8, version));
global_settings { assumed_gamma 1 }
#declare PIG = pigment{bozo}
#declare myPIG = PIG

... but that runs OK! So it seems that the problem might be exclusive to the
'interior' block... or ior... ?

[Kenneth] Re: Assigning an interior crashes 3.8 beta 2 [1065 days 18 hours and 8 minutes ago]

Tue, 9 May 2023 13:45:00 GMT

[in Windows 10, running official v3.8.0 beta 1, Lenovo desktop machine, Core i7]

These first 3 lines run OK...

#version max (3.5, min (3.8, version));
global_settings { assumed_gamma 1 }
#declare Int = interior { ior 1.5 }

Adding the 4th line...
      #declare myInt = Int
...causes a fatal error-- but the error message changes(!)

If I freshly start POV-ray, the error says
       "Parse error: vector <T> to long"  (whatever that means).

Immediately running the code again, it's
      "Parse error: bad allocation"

By changing the 4th line to
      #declare myInt = interior{Int}
it all runs fine, no error.

[Cousin Ricky] Assigning an interior crashes 3.8 beta 2 [1065 days 18 hours and 39 minutes ago]

Tue, 9 May 2023 13:14:14 GMT

The following scene crashes with the error:

  line 4: Parse Error: std::bad_alloc

----------[BEGIN CODE]----------
#version max (3.5, min (3.8, version));
global_settings { assumed_gamma 1 }
#declare Int = interior { ior 1.5 }
#declare myInt = Int
-----------[END CODE]-----------

The discontinued 3.7.1-rc.1 also crashes, but previous versions of
POV-Ray do not.

POV-Ray version: POV-Ray 3.8.0-beta.2 (self-compiled)
Operating system: openSUSE Leap 15.3 GNU/Linux
Hardware: Lenovo Ideapad Slim 7
CPU: Intel Core i7

[jr] Re: Possible v3,8 b2ta 2 fix for "Borked diacrit... [1097 days 16 hours and 38 minutes ago]

Fri, 7 Apr 2023 15:15:00 GMT

hi,

William F Pokorny <ano### [at] anonymousorg> wrote:
> ...
> In any case, I had a current local copy of the v3.8 beta 2 unix/linux
> tar ball. Attached is a unified diff patch file. It should be Chris, or
> whomever, can use it to apply the fix to the current v3.8 beta 2
> truetype.cpp file and compile. I ran one of my test sets (vowels with 9
> Ubuntu shipped fonts) and results looked OK.

wow.  quick.  patched a beta.2 and tried with a couple of fonts, and (think) I
see an improvement with 'times.ttf'.  hope to do some more .. organised :-)
testing this weekend.  thank you.

regards, jr.

[William F Pokorny] Re: Possible v3,8 b2ta 2 fix for "Borked diacrit... [1097 days 18 hours and 7 minutes ago]

Fri, 7 Apr 2023 13:45:59 GMT

On 4/7/23 07:27, jr wrote:
> think this is really important, and useful, and so hope you will find the time
> to "back-port".  (thank you, in advance)

The particular change there was one of Christoph's which got backed out 
for the v3.8 release. The READSHORT() and READUSHORT() arguments need to 
be changed to what they are in the v3.8 beta 2 code. I didn't notice the 
argument change as it has nothing to do with the fix.

In any case, I had a current local copy of the v3.8 beta 2 unix/linux 
tar ball. Attached is a unified diff patch file. It should be Chris, or 
whomever, can use it to apply the fix to the current v3.8 beta 2 
truetype.cpp file and compile. I ran one of my test sets (vowels with 9 
Ubuntu shipped fonts) and results looked OK.

patch truetype.cpp <borked_ttf.patch

Bill P.

[jr] Re: Possible v3,8 b2ta 2 fix for "Borked diacrit... [1097 days 20 hours and 23 minutes ago]

Fri, 7 Apr 2023 11:30:00 GMT

hi,

William F Pokorny <ano### [at] anonymousorg> wrote:
> With respect to the "Borked diacritical marks" thread in
> povray.binaries.images.
> ...
> I believe, but I've not verified, the fix used for the povr fork will
> work with the current v3.8 beta 2 code.

no, alas.  see below.


> ...
> to this:
>
> //---
> #ifdef TTF_DEBUG
>              Debug_Info("sub_glyph %d:\n", sub_glyph_index);
> #endif
>
>              if (flags & ARG_1_AND_2_ARE_WORDS)
>              {
> #ifdef TTF_DEBUG
>                  Debug_Info("ARG_1_AND_2_ARE_WORDS\n");
> #endif
>                  if (flags & ARGS_ARE_XY_VALUES)
>                  {  // Values are int16_t
>                      arg1 = READSHORT(*ffile->file);
>                      arg2 = READSHORT(*ffile->file);
>                  }
>                  else
>                  {  // Values are uint16_t
>                      arg1 = READUSHORT(*ffile->file);
>                      arg1 = READUSHORT(*ffile->file);
>                  }
>              }
>              else

lost opening brace ?


in your 'povr' you made changes to the TrueTypeFont struct(ure), among them the
introduction of the 'file' member.
source/core/shape/truetype.h:125, in version _6e4ed6c2.

think this is really important, and useful, and so hope you will find the time
to "back-port".  (thank you, in advance)


regards, jr.

[William F Pokorny] Possible v3,8 b2ta 2 fix for "Borked diacritical... [1098 days 10 hours and 49 minutes ago]

Thu, 6 Apr 2023 21:04:40 GMT

With respect to the "Borked diacritical marks" thread in 
povray.binaries.images.

Ref:

http://news.povray.org/povray.binaries.images/thread/%3C642f0cc9%241%40news.povray.org%3E/

or

Message: <63cd6b12$1@news.povray.org>


I believe, but I've not verified, the fix used for the povr fork will
work with the current v3.8 beta 2 code. See below - with a little 
reformatting to prevent awkward lines splits.

Bill P.



In truetype.cpp change the following v3.8 beta 2 code:

//---
#ifdef TTF_DEBUG
             Debug_Info("sub_glyph %d: ", sub_glyph_index);
#endif

             if (flags & ARG_1_AND_2_ARE_WORDS)
             {
#ifdef TTF_DEBUG
                 Debug_Info("ARG_1_AND_2_ARE_WORDS ");
#endif
                 arg1 = READSHORT(ffile->fp);
                 arg2 = READSHORT(ffile->fp);
             }
             else
             {
                 arg1 = READUSHORT(ffile->fp);
                 arg2 = arg1 & 0xFF;
                 arg1 = (arg1 >> 8) & 0xFF;
             }
//---

to this:

//---
#ifdef TTF_DEBUG
             Debug_Info("sub_glyph %d:\n", sub_glyph_index);
#endif

             if (flags & ARG_1_AND_2_ARE_WORDS)
             {
#ifdef TTF_DEBUG
                 Debug_Info("ARG_1_AND_2_ARE_WORDS\n");
#endif
                 if (flags & ARGS_ARE_XY_VALUES)
                 {  // Values are int16_t
                     arg1 = READSHORT(*ffile->file);
                     arg2 = READSHORT(*ffile->file);
                 }
                 else
                 {  // Values are uint16_t
                     arg1 = READUSHORT(*ffile->file);
                     arg1 = READUSHORT(*ffile->file);
                 }
             }
             else
#ifdef TTF_DEBUG
                 Debug_Info("ARG_1_AND_2_ARE_BYTES\n");
#endif
                 if (flags & ARGS_ARE_XY_VALUES)
                 {  // Values are int8_t * 2

                     union uC {
                         int8_t buffer[2];
                         uint16_t value;
                     } u;
                     u.value = READUSHORT(*ffile->file);

             // Determine this machine's endianness. Method used herein
             // derived from netpbm's pamtopfm converter by: Bryan
             // Henderson, San Jose, CA April 2004. Code was contributed
             // to the public domain.
                     short const testNumber = 0x0001;
                     unsigned char* const storedNumber =
			(unsigned char *)&testNumber;
                     int BigEndian = (storedNumber[0] == 0x01) ? 0 : 1;

                     if (BigEndian)
                     {
                         arg1 = (SHORT)u.buffer[0];
                         arg2 = (SHORT)u.buffer[1];
                     }
                     else
                     {
                         arg1 = (SHORT)u.buffer[1];
                         arg2 = (SHORT)u.buffer[0];
                     }
                 }
                 else
                 {  // Values are uint8_t
                     arg1 = READUSHORT(*ffile->file);
                     arg2 = arg1 & 0xFF;
                     arg1 = (arg1 >> 8) & 0xFF;
                 }
             }
//---

[William F Pokorny] v3.8 b2. Exposure with number_of_waves parse vs ... [1118 days 16 hours and 12 minutes ago]

Fri, 17 Mar 2023 15:41:02 GMT

I recently resumed a look at the ripples and waves patterns - which 
exist for both normal and pattern value map blocks.

If you never use other than the default of 10 waves, you can stop reading.

---

Be aware, the internal initialization of vectors and frequency / 
amplitude values happens when each worker thread is initialized. So, the 
parse thread gets initialized, before, it has a chance to parse any 
'global_settings { number_of_waves <n> }' settings or change-settings 
during parsing.

In other words we always get 10 waves in the parsing thread and we'll 
only get the last number_of_waves setting in the post-parse threads for 
photons / radiosity / render.

So what, you shout!

You might be right. This state of thing might come to nothing - except 
when you do something in the parse phase like place objects on a surface 
perturbed by the ripples and/or waves pattern. Later, when the render of 
that surface happens, it isn't the same surface as what existed during 
parsing.

Bill P.


Aside: The other unfortunate bit I'm taking a swing at fixing is that we 
always get the same vectors and values. It's as if we are working with a 
long fixed list and only get to pick the first <n> sets(a). Changing the 
number could change all <n> values, but it doesn't today. What we really 
want are truly independent patterns where we can specify more of what we 
want for each of the uses. We'll see.

(a) - The reason for a fixed list might be how 'waves' is implemented. 
There isn't a hard clamp on the upper range of values, but rather a 
heuristic function. Admittedly, one which might well be as good as an 
optimal one for any reasonable number of waves(b) given the known fixed 
stream of values!

(b) - There is no check on the upper value today while parsing, which 
itself, might result in crashes, bangs and booms - or cursing while a 
render takes forever and 12 years. :-) (Effective limit is MAX_INT)

[William F Pokorny] Image_map out of bounds color channel issue. v3.... [1120 days 8 hours and 38 minutes ago]

Wed, 15 Mar 2023 23:15:10 GMT

Where color images read into an image_map and the x,y position is found 
to be outside the image(a) the code makes those pixels transparent. It's 
a cool feature about which I did not know. Basically you can implement 
old style sprite animations with color images on a plane. Set the 
background to rgbt <0,0,0,1> and render with +ua and the alpha channel 
transparency carries through to the output file.

The problem is the transparency was being set to rgbft <1,1,1,0,1>. I'll 
let the comments I added to the code say the rest.

bool ColourImagePattern::Evaluate(...)
...

if (map_pos(EPoint, pImage, &xcoor, &ycoor))
{

// Below, for many years, was <1.0, 1.0, 1.0, 0.0, 1.0>. However, this
// led to incorrect channel values when the image_map was accessed by
// channel or by a limited subset of channels as with functions using
// ().gray, for example(b). Making the RGB channels 0.0 aligns behavior
// with that of other pigment{} related methods like pigment_pattern
// which hard codes a return of 0.0 on seeing false, image_pattern does
// a map_pos() check and if off the map hard codes a return of 0.0.

result = ToTransColour(RGBFTColour(0.0, 0.0, 0.0, 0.0, 1.0));
return false;
}
else
...

Bill P.

(a) - This happens while using 'once'.

(b) - In existing releases you can sometimes change/align the behavior 
by knowing about the hidden internal code - and where not otherwise 
using an alpha channel, filter or transmit. Something like this is ugly, 
but get you to black for the outside pixels.

pigment {
     function {
         FnPgOnly(x,y,z).gray*(1.0-FnPgOnly(x,y,z).transmit)
     }
}

[William F Pokorny] Re: v3.8 beta 2. Bug with image_pattern use_inde... [1120 days 16 hours and 57 minutes ago]

Wed, 15 Mar 2023 14:55:44 GMT

On 3/15/23 09:00, Kenneth wrote:
> It seems to me that it should use the image's gray values instead (like a .gray
> equivalent). That would make more sense... and would be consistent with, for
> example, a bump_map (which uses the gray values for its normals by default).
> 
> The other inconsistency is the height_field-- which again uses only the red
> channel from a color image_map. That should use gray as well, IMHO.

The unfortunate answer here is it sometimes does use gray - when the 
channel depth is >8. There are other factors in play too which make the 
height_field from an image game complicated.

Using already true grey format images are simpler / safer - especially 
those written and read at 'gamma 1.0'.

> I wonder why these features are restricted to the red channel? Perhaps, when
> they were first introduced, the idea was that only gray-scale image_maps would
> be used in them(?)

Maybe.

I do not know how the focus on the red channel started with respect to 
reading color images. I have guesses too, like early versions of POV-Ray 
perhaps not having much for inbuilt color to grey conversions, but, I 
don't know. I agree that gray makes more sense, but probably better 
would be to throw an exception when the alpha channel the user wants is 
not present.

It often makes sense in todya's POV-Ray to use .red access for already 
gray images as you then avoid some calculation. You could use .green or 
.blue, but .red is fewer characters... Aside: Internally any time you 
run through the pigment code wrap you have color vectors / channels.

Bill P.

[Kenneth] Re: v3.8 beta 2. Bug with image_pattern use_inde... [1120 days 18 hours and 48 minutes ago]

Wed, 15 Mar 2023 13:05:00 GMT

William F Pokorny <ano### [at] anonymousorg> wrote:

>
> Aside 2: In a surprise to me, the use_alpha option uses the red channel
> when it cannot find an actual alpha channel for the return values.
>

Confirmed in Windows v3.8.0 beta 1-- using a typical .png COLOR image_map for
the image_pattern (non-indexed and with no alpha-channel). BTW, I already had an
image_pattern test scene available from 2018, courtesy of a Thomas De Groot
post... but I never noticed this red-channel-only behavior.

It seems to me that it should use the image's gray values instead (like a .gray
equivalent). That would make more sense... and would be consistent with, for
example, a bump_map (which uses the gray values for its normals by default).

The other inconsistency is the height_field-- which again uses only the red
channel from a color image_map. That should use gray as well, IMHO.

I wonder why these features are restricted to the red channel? Perhaps, when
they were first introduced, the idea was that only gray-scale image_maps would
be used in them(?)

[William F Pokorny] v3.8 beta 2. Bug with image_pattern use_index ke... [1121 days 7 hours and 57 minutes ago]

Tue, 14 Mar 2023 23:56:33 GMT

In the function ParseImagePattern() there has long been an error with 
the use_index parsing.

CASE (USE_INDEX_TOKEN)
	image->Use = USE_INDEX; // Should be USE_NONE
END_CASE

Yes, the set up is strange, but USE_NONE means don't use the color 
and/or alpha channels - but rather use the palette indexes. The other 
image parsing options look to be correct setting USE_NONE on seeing 
use_index. The parsing is set up with respect to what color channels to 
use - so even defining USE_INDEX is odd. It's probably a remnant from 
old code.

Aside 1 : The index handling is hard coded to 8 bits (0-255) which is 
gif compatible and will work many png or tiff palette images, but png 
supports options with fewer bits and the de-facto standard tiff can use 
a 16 bit palette format.

Stick with 8 bit palettes would be the rule for use_index.

FWIW. I didn't test other than gif palette images.

In addition to some additional parse time checking for use_color, 
use_alpha and use_index - I added an exception if someone attempts to 
use use_index where none exists in the input image.

Aside 2: In a surprise to me, the use_alpha option uses the red channel 
when it cannot find an actual alpha channel for the return values.

Bill P.

[William F Pokorny] Intended image_pattern, etc, warning not generat... [1122 days 11 hours and 23 minutes ago]

Mon, 13 Mar 2023 20:30:27 GMT

Issue seen while playing with image_pattern{} vs image_map{}.

---
In the function parse_image() located in the file:

<source install>/source/parser/parser_materials.cpp

there is code to generate a warning when no image gamma is specified and 
the image is being used in a height_field, bump_map or image_pattern. 
The code back to v3.7 at least, has never worked. Where today the code has:

if (options.gammacorrect && !options.gammaOverride)

it should read:

if (!options.gammacorrect && !options.gammaOverride)

In povr I also added a second warning about using exr and hdr images 
files with the height_field, bump_map or image_pattern.

if (!GammaCorrect)
{
     if (!options.gammacorrect && !options.gammaOverride)
     {
         Warning("...");
     }
     if ((filetype==EXR_FILE) || (filetype==HDR_FILE))
     {
         Warning("...");
     }
}

---
Using:

image_pattern { "test.exr" ... }

and not specifying a gamma correction, I now get:

File 'hmm3.pov' line 67:
Parse Warning:

Input image gamma not specified for height_field, bump_map or 
image_pattern; no gamma adjustment (equals gamma 1.0) performed on input 
image; Specify the appropriate gamma correction or, to be rid of this 
warning, "gamma 1.0".

File 'hmm3.pov' line 67:
Parse Warning:

High Dynamic Range Image being used with a height_field, bump_map or 
image_pattern; This will likely lead to artefacts as such images have 
internal values outside the zero to one range.

[Kenneth] Re: v3.8b2. height_field input values at 0.0 not... [1144 days 15 hours and 18 minutes ago]

Sun, 19 Feb 2023 16:35:00 GMT

"Bald Eagle" <cre### [at] netscapenet> wrote:
> William F Pokorny <ano### [at] anonymousorg> wrote:
>
> > In looking at your results I'm not at all sure why the max extent values
> > for x and z are all zero? The HF max extent should be 1 or larger for x
> > and z (always I think if not scaled) ?
>
> This got me curious as well.
>
> So I just threw some quick lines of code together.
>
> The hf looks fine to me.   Typo in Ken's code?
>

Oooh, yet another one! You're absolutely right, I screwed up my #debug
statements, a cut-and-paste error from running  so many tests. I never actually
used my max_extent values. :-[  So sorry. That was a real whopper of a mistake.
My apologies to William P for 'chasing this down a rabbit hole'.

Using my now-corrected code, these are today's results:
function 500,500 {0}

MIN_EXT = <0.0000000000, -0.0000000153, 0.0000000000>

MAX_EXT = <1.0000000000, 0.0000000153, 1.0000000000>

--- BTW: For a somewhat quicker test, the HF could use   function 2,2 {0}
instead; the resulting planar HF still looks fine as an object, and also
produces the speckles vs. no-speckles comparison.

> 1/pow (2, 16) = 0.00001526

That's fascinating; I didn't realize that my 'jump' point had a computational
basis. Thanks!

[Bald Eagle] Re: v3.8b2. height_field input values at 0.0 not... [1145 days 6 hours and 13 minutes ago]

Sun, 19 Feb 2023 01:40:00 GMT

William F Pokorny <ano### [at] anonymousorg> wrote:

> In looking at your results I'm not at all sure why the max extent values
> for x and z are all zero? The HF max extent should be 1 or larger for x
> and z (always I think if not scaled) ?

This got me curious as well.

So I just threw some quick lines of code together.

The hf looks fine to me.   Typo in Ken's code?

#declare delta_hf = 1/pow (2, 16);
#debug concat ("1/pow (2, 16) = ", str (delta_hf, 0, 8), "\n")

#declare HF = height_field {
     function 800, 800 { 1 }
     }

#declare Min = min_extent (HF);
#declare Max = max_extent (HF);


-0.0 shows up as : -0.000000
+0.0 shows up as : 0.000000

Var negZero shows up as : -0.000000
Var posZero shows up as : 0.000000
Var hmmZero shows up as : -0.000000

select () interprets -0 as zero
sgn () interprets -0 as zero
Ternary interprets -0 as zero
#if interprets -0 as zero
1/pow (2, 16) = 0.00001526
Heightfield min_extent = = 0.00000000, 0.99998474, 0.00000000
Heightfield max_extent = = 1.00000000, 0.99998480, 1.00000000


Changing the function result to 0 yields:

Heightfield min_extent = = 0.00000000, -0.00000002, 0.00000000
Heightfield max_extent = = 1.00000000, 0.00000002, 1.00000000

[Tor Olav Kristensen] Re: v3.8b2. height_field input values at 0.0 not... [1145 days 7 hours and 8 minutes ago]

Sun, 19 Feb 2023 00:45:00 GMT

William F Pokorny <ano### [at] anonymousorg> wrote:
> On 2/17/23 20:49, Tor Olav Kristensen wrote:
> >> Aside: You can use the 3 term select depending upon a boolean result in
> >> the first term test by doing something like:
> >>
> >> select(1-(2*((x<0.0) | (x>1.0))), 0, 1)
> >> ...
> > How about just this:
> >
> > select(
> >      -((x < 0.0) | (1.0 < x)),
> >      0,
> >      1
> > )
> >
> > - or this:
> >
> > select(
> >      -((0.0 <= x) & (x <= 1.0)),
> >      1,
> >      0
> > )
>
> :-)
>
> Very likely OK in practice, and cleaner in form than my three term select.
>
> What spooks me some is that -0 and +0 are real things in the IEEE
> floating point standard and as supported by C++. If a C++ coder has
> thought to test for -0 < 0, they can.

When you mention it, I think that I've actually have run into a problem with
negative zero in a version of POV-Ray.

IIRC I got different result when I used select() from what I got when I used <
or > in an #if statement.

So yes, it is scary.

--
Tor Olav
http://subcube.com
https://github.com/t-o-k

[Tor Olav Kristensen] Re: v3.8b2. height_field input values at 0.0 not... [1145 days 7 hours and 13 minutes ago]

Sun, 19 Feb 2023 00:40:00 GMT

"Tor Olav Kristensen" <tor### [at] TOBEREMOVEDgmailcom> wrote:
> William F Pokorny <ano### [at] anonymousorg> wrote:
> >...
> > I used the 4 term because I think it reads a little cleaner when setting
> > up a boolean test in the first term which can only return a zero or one
> > - the negative action is never used as Bill W said.
>
> I agree..
>
>
> > Aside: You can use the 3 term select depending upon a boolean result in
> > the first term test by doing something like:
> >
> > select(1-(2*((x<0.0) | (x>1.0))), 0, 1)
> >...
>
> How about just this:
>
> select(
>     -((x < 0.0) | (1.0 < x)),
>     0,
>     1
> )
>
> - or this:
>
> select(
>     -((0.0 <= x) & (x <= 1.0)),
>     1,
>     0
> )

But for that check select() isn't needed.
This should be sufficient:

((0.0 <= x) & (x <= 1.0))


--
Tor Olav
http://subcube.com
https://github.com/t-o-k

[Kenneth] Re: v3.8b2. height_field input values at 0.0 not... [1145 days 9 hours and 53 minutes ago]

Sat, 18 Feb 2023 22:00:00 GMT

William F Pokorny <ano### [at] anonymousorg> wrote:

>
> In looking at your results I'm not at all sure why the max extent values
> for x and z are all zero? The HF max extent should be 1 or larger for x
> and z (always I think if not scaled) ?

Yes, that surprised me as well. My HF scale was at <1,1,1>. Odd results indeed.

[William F Pokorny] Re: v3.8b2. height_field input values at 0.0 not... [1145 days 10 hours and 7 minutes ago]

Sat, 18 Feb 2023 21:46:21 GMT

On 2/18/23 14:50, Kenneth wrote:
> So from these stats and results, my*guess*  is that there could be a very slight
> 'bias'(?) in the HF creation code-- or function-to-HF process? -- whereby the HF
> is not actually from 0-1, but (0 minus a small value) to (1 minus the small
> value.) OR, the same with the color_map mechanism. Although, the abrupt 'jumps'
> between .0000152 and .0000153 are puzzling

Interesting results and I think on the right track for some of what is 
unique about height_field bounding. What you see with the sudden large 
jump on that last subtraction is the out of bounds ramp wave value re-map.

For the smaller jumps. Internally, and probably due the original 
image_map only usage, the max 3d size we can have is 2^16 a side - 
HF_VAL is an unsigned short int. Vertically this means we are working in 
a best resolution of 1/2^16 steps = 0.00001525...  This lines up with 
the values where you see abrupt change in extents and that's kinda cool.

The bounds tracking is done at least in part in terms of doubles during 
calculation and where a value of HFIELD_OFFSET (currently 0.001) is 
subtracted from the lowest value per side and added to the greatest 
value on the top side. After the at double calculation, the result is 
converted back to HF_VAL.

Because that 0.001 isn't a multiple of the 16bits of resolution I 
believe there must be some value snapping going on during the double to 
HF_VAL conversion.

That's as far as I got before bailing out.

In looking at your results I'm not at all sure why the max extent values 
for x and z are all zero? The HF max extent should be 1 or larger for x 
and z (always I think if not scaled) ?

Bill P.

[Kenneth] Re: v3.8b2. height_field input values at 0.0 not... [1145 days 11 hours and 48 minutes ago]

Sat, 18 Feb 2023 20:05:00 GMT

"Kenneth" <kdw### [at] gmailcom> wrote:

A typo, so sorry.

> function 500,500 { 0 - .0000152} -- The planar HF jumps up to y=1 (almost!) as I
> kind of expected... but no speckles at all again, which was surprising.
> MIN_EXT = <0.0000000000, 0.9999847412, 0.0000000000> -- y is not quite 1.0
> MAX_EXT = <0.0000000000, 0.9999847412, 0.0000000000>

function 500,500 { 0 - .0000153}

[Kenneth] Re: v3.8b2. height_field input values at 0.0 not... [1145 days 11 hours and 58 minutes ago]

Sat, 18 Feb 2023 19:55:00 GMT

William F Pokorny <ano### [at] anonymousorg> wrote:
>
> Just something I happened to see while looking into other height_field
> questions of late.
>
> The HF zero (y as image/fnct evaluated) and z HF result should cleanly
> show up no matter scaling! At best it is today noisy.
>
> Looks to be an issue back through v3.7 stable at least. I think given
> the noise it's likely some numerical and/or bounding issue rather than
> the actual HF mesh. We'll see.
>

[Running v3.8.0 beta 1 in Windows 10]

I ran a bunch of animation tests of
height_field{
      function 500,500 {0}
.....

....while changing various values. Here are some results:

If the HF is given a solid color pigment, I don't see any speckles or odd
coincident-surface problems at all.

But if I give it
       pigment{ gradient y color_map{[0 rgb 0][1 red 10]}}
I do see the speckles.

Apparently, the color_map is repeating from the top of its red color, but from
'below' the HF.

I also ran some tests while slightly varying the function value itself, and also
used min_extent/max_extent to see what values they would return. The results are
a bit odd, to say the least:

(using the gradient y color_map):

function 500,500 {0} has the speckles
MIN_EXT = <0.0000000000, -0.0000000023, 0.0000000000> note minus sign for y
MAX_EXT = <0.0000000000, -0.0000000023, 0.0000000000>

function 500,500 { 0 + .0000152} has the speckles.
The resulting height_field size:
MIN_EXT = <0.0000000000, -0.0000000023, 0.0000000000> -- same as above
MAX_EXT = <0.0000000000, -0.0000000023, 0.0000000000>

function 500,500 { 0 + .0000153} shows no speckles at all -- but with an abrupt
change in the y value:
MIN_EXT = <0.0000000000, 0.0000022865, 0.0000000000>
MAX_EXT = <0.0000000000, 0.0000022865, 0.0000000000>
---------
Now, if I change the function additions to subtractions:
function 500,500 { 0 - .0000152} has the speckles.
MIN_EXT = <0.0000000000, -0.0000000023, 0.0000000000> -- same as addition
MAX_EXT = <0.0000000000, -0.0000000023, 0.0000000000> -- ditto

function 500,500 { 0 - .0000152} -- The planar HF jumps up to y=1 (almost!) as I
kind of expected... but no speckles at all again, which was surprising.
MIN_EXT = <0.0000000000, 0.9999847412, 0.0000000000> -- y is not quite 1.0
MAX_EXT = <0.0000000000, 0.9999847412, 0.0000000000>

So from these stats and results, my *guess* is that there could be a very slight
'bias'(?) in the HF creation code-- or function-to-HF process? -- whereby the HF
is not actually from 0-1, but (0 minus a small value) to (1 minus the small
value.) OR, the same with the color_map mechanism. Although, the abrupt 'jumps'
between .0000152 and .0000153 are puzzling.

The tests were interesting at least!

[William F Pokorny] Re: v3.8b2. height_field input values at 0.0 not... [1145 days 14 hours and 3 minutes ago]

Sat, 18 Feb 2023 17:49:43 GMT

On 2/18/23 08:33, Bald Eagle wrote:
> William F Pokorny <ano### [at] anonymousorg> wrote:
> 
>> What spooks me some is that -0 and +0 are real things in the IEEE
>> floating point standard and as supported by C++. If a C++ coder has
>> thought to test for -0 < 0, they can.
> 
> Which raises the question about how the IEEE 754 gets implemented in POV-Ray's
> source code, and if a user can test for -0 through SDL.

So tempted to answer I don't know(a)... ;-)

For the floating point standard we mostly get what the C++ compilers 
give us depending upon options used while compiling. Excepting where in 
the POV-Ray source there might be hard coded behavior which is not 
strictly compliant or in days gone by was intended to handle things is 
some more compliant manner(b).

As for testing for -0 via SDL, I cannot think of any direct method...

On my development compiles using g++ 11.3 and the -ffast_math flag, I 
can code:

#declare negZero = -0.0;
#declare posZero = +0.0;
#declare hmmZero = 0.0/-1.0;

#debug concat("-0.0 shows up as : ",str(-0.0,0,-1)," \n")
#debug concat("+0.0 shows up as : ",str(+0.0,0,-1)," \n")

#debug concat("Var negZero shows up as : ",str(negZero,0,-1)," \n")
#debug concat("Var posZero shows up as : ",str(posZero,0,-1)," \n")
#debug concat("Var hmmZero shows up as : ",str(hmmZero,0,-1)," \n")

#error "\nStopping at end of parsing\n"

and see as a result:

-0.0 shows up as : -0.000000
+0.0 shows up as : 0.000000
Var negZero shows up as : -0.000000
Var posZero shows up as : 0.000000
Var hmmZero shows up as : -0.000000

So maybe build up strings and do a string compare?

Aside: The C++ value comparison operators mirrored in SDL will - by 
default - ignore the sign of zero.

> 
> I actually just watched:
> 
> Fast Inverse Square Root â€” A Quake III Algorithm
> https://www.youtube.com/watch?v=p8u_k2LIZyo
> 
> yesterday (it was in the sidebar when watching yesbird's animation), and they
> went over some interesting points, and was also wondering if we could implement
> something like this in POV-Ray SDL, and source, and if you'd find it useful or
> are already using it in povr.
> 
Cool old stuff!

As for fast, clever algorithms... I've tried some tricks in povr and 
looked over quite a few, though not the particular one in the video. 
Most come with somewhat noisy behavior compared to standards compliant 
code. The noise is difficult to swallow given the end benefit(c) - 
floor() and ceil() fast equivalents, for example.

Bill P.

(a) I don't know it all - about anything. Where I do know a little, 
there's almost never a simple, complete answer.

(b) The radiosity code to this day has some complicated configurations 
related to the floating point math, for example. Unsure what all of this 
used or needed these days.

(c) The povr fork, while coding up new functions, did implement single 
and floating point flavors / options for many functions. Anywhere the 
single floating point code was significantly faster on my i3 hardware - 
at the expense of accuracy. Often single float accuracy in functions is 
OK depending on - stuff.

Measuring and tuning for performance is REALLY difficult these days 
given the hardware realities. For core functionality, the tuning job is 
best left to the compiler folks as a near hard rule.

[Bald Eagle] Re: v3.8b2. height_field input values at 0.0 not... [1145 days 18 hours and 18 minutes ago]

Sat, 18 Feb 2023 13:35:00 GMT

William F Pokorny <ano### [at] anonymousorg> wrote:

> What spooks me some is that -0 and +0 are real things in the IEEE
> floating point standard and as supported by C++. If a C++ coder has
> thought to test for -0 < 0, they can.

Which raises the question about how the IEEE 754 gets implemented in POV-Ray's
source code, and if a user can test for -0 through SDL.

I actually just watched:

Fast Inverse Square Root — A Quake III Algorithm
https://www.youtube.com/watch?v=p8u_k2LIZyo

yesterday (it was in the sidebar when watching yesbird's animation), and they
went over some interesting points, and was also wondering if we could implement
something like this in POV-Ray SDL, and source, and if you'd find it useful or
are already using it in povr.

- BW

[William F Pokorny] Re: v3.8b2. height_field input values at 0.0 not... [1145 days 21 hours and 13 minutes ago]

Sat, 18 Feb 2023 10:40:25 GMT

On 2/17/23 20:49, Tor Olav Kristensen wrote:
>> Aside: You can use the 3 term select depending upon a boolean result in
>> the first term test by doing something like:
>>
>> select(1-(2*((x<0.0) | (x>1.0))), 0, 1)
>> ...
> How about just this:
> 
> select(
>      -((x < 0.0) | (1.0 < x)),
>      0,
>      1
> )
> 
> - or this:
> 
> select(
>      -((0.0 <= x) & (x <= 1.0)),
>      1,
>      0
> )

:-)

Very likely OK in practice, and cleaner in form than my three term select.

What spooks me some is that -0 and +0 are real things in the IEEE 
floating point standard and as supported by C++. If a C++ coder has 
thought to test for -0 < 0, they can.

Bill P.

[Tor Olav Kristensen] Re: v3.8b2. height_field input values at 0.0 not... [1146 days 6 hours and 3 minutes ago]

Sat, 18 Feb 2023 01:50:00 GMT

William F Pokorny <ano### [at] anonymousorg> wrote:
>...
> I used the 4 term because I think it reads a little cleaner when setting
> up a boolean test in the first term which can only return a zero or one
> - the negative action is never used as Bill W said.

I agree..


> Aside: You can use the 3 term select depending upon a boolean result in
> the first term test by doing something like:
>
> select(1-(2*((x<0.0) | (x>1.0))), 0, 1)
>...

How about just this:

select(
    -((x < 0.0) | (1.0 < x)),
    0,
    1
)

- or this:

select(
    -((0.0 <= x) & (x <= 1.0)),
    1,
    0
)


--
Tor Olav
http://subcube.com
https://github.com/t-o-k

[Kenneth] Re: v3.8b2. height_field input values at 0.0 not... [1146 days 12 hours and 8 minutes ago]

Fri, 17 Feb 2023 19:45:00 GMT

"Kenneth" <kdw### [at] gmailcom> wrote:
>
> The boolean results in parentheses are only ever 0 or 1 (true or false).

The boolean results in parentheses are only ever 0 or 1 (false or true).

Oops.  ;-)

[Kenneth] Re: v3.8b2. height_field input values at 0.0 not... [1146 days 12 hours and 43 minutes ago]

Fri, 17 Feb 2023 19:10:00 GMT

William F Pokorny <ano### [at] anonymousorg> wrote:
>
> I'm going to re-state things because what showed up where I
> have ???? characters above looks different on the web than what I see in
> Thunderbird(a).

No problem at my end; I see the correct syntax in the web portal.

Sorry for my longer-than-usual-delay in responding; I had to think hard about
this 'negative option being ignored' thing, and the difference between a 3-part
vs. 4-part select(). I was still thinking about it when I feel asleep last
night! William P's function construct makes better sense to me now; I finally
had the 'flashing insight'.

docs for the 4-part select:
When used with four parameters, if A < 0 it will return B. If A = 0 it will
return C. Else it will return D (A > 0).

I had to work out my own rather pedantic 'truth table' of sorts, as I see it --
hopefully corrected this time--

-------
Given  ((x<0.0) | (x>1.0))  as the first argument 'A':
The boolean results in parentheses are only ever 0 or 1 (true or false).

if x is indeed less than 0.0 OR greater than 1.0, that produces boolean TRUE (or
1) in the parentheses. Compared against select's 'zero by definition' for A,  1
is 'greater than zero'.  So according to the rules, the outcome of select() will
be argument D-- the f_boom macro. Effectively, it doesn't matter if x exceeds
either limit; the result will be TRUE in either case.

If x is exactly 0.0  *or inside the given range*, the boolean operation in
parentheses produces FALSE (or 0). But, for select's argument A
comparison, 'zero equals zero' -- and argument C is chosen, which is 0.0 in
William P's code and 0.3 in mine.
-------

So far, argument B is never chosen; C and D take care of every possible outcome
of    ((x<0.0) | (x>1.0))

HOWEVER, I see now that a simpler 3-part select() would not work when using
argument A as written-- because of the 3-part rules: Argument B is only chosen
when argument A is *less than* 0, which never occurs with  ((x<0.0) | (x>1.0))

[William F Pokorny] Re: v3.8b2. height_field input values at 0.0 not... [1146 days 21 hours and 42 minutes ago]

Fri, 17 Feb 2023 10:11:09 GMT

On 2/16/23 18:45, Kenneth wrote:
> Yes. Functions as used in height_fields never see called x,y values
> outside the [0-1] range.

Perhaps worth saying a little more than the above. Whether creating a 
height_field or internal image_map from a function in POV-Ray, any 
'function return' values outside the [0-1] get 'wrapped' to a ramp wave 
as is the default with the majority of inbuilt patterns.

So, function return values of:
-0.1 --> 0.9
-0.5 --> 0.5
-0.9 --> 0.1.
1.1 --> 0.1
1.5 --> 0.5
1.9 --> 0.9

In other words, there is a jump or discontinuity when returning values 
go negative or larger than 1. Further, there is no ability to to invoke 
wave(a) modifiers as is true with the pattern mechanism.

Function based image_maps and height_fields all end up in a [0-1] 
vertical/value range - even if your function itself returns values 
outside that range.

Bill P.

(a) - The povr fork offers some wave modification capability via new 
inbuilt functions like f_sine_wave().

[William F Pokorny] Re: v3.8b2. height_field input values at 0.0 not... [1146 days 22 hours and 2 minutes ago]

Fri, 17 Feb 2023 09:51:17 GMT

On 2/16/23 19:56, Bald Eagle wrote:
> since a 3-term select statement is divided into 2 results:  negative or
 > ????.

Bill W (BE) explained well.

However, I'm going to re-state things because what showed up where I 
have ???? characters above looks different on the web than what I see in 
Thunderbird(a).

There are two forms of select(). The is a four term/argument version and 
a three term version. The four term allows 'actions' for negative, zero 
and positive input values. The three term one allows actions for 
negative and (zero or positive) values.

I used the 4 term because I think it reads a little cleaner when setting 
up a boolean test in the first term which can only return a zero or one 
- the negative action is never used as Bill W said.

Aside: You can use the 3 term select depending upon a boolean result in 
the first term test by doing something like:

select(1-(2*((x<0.0) | (x>1.0))), 0, 1)

I think this form less clear and, FWIW, it's slower than the four term 
version.

Bill P.

(a) The leading '>' character got picked up as being an indication of 
text from a previous post and is displaying as a vertical bar '|' in 
Thunderbird.

[Bald Eagle] Re: v3.8b2. height_field input values at 0.0 not... [1147 days 6 hours and 53 minutes ago]

Fri, 17 Feb 2023 01:00:00 GMT

"Kenneth" <kdw### [at] gmailcom> wrote:

> > #include "functions.inc"
> > #declare FnChkVals = function (x) {
> >      select(((x<0.0) | (x>1.0)),
> >          0,
> >          0,
> >          f_boom(x,2,3,4,5,6)
> >      )
> > }


Kenneth, I use select all the time.

This is how it works:

select (N, -1, 0, 1)

When your comparison function gets evaluated, it returns a Boolean state (in
POV-Ray it's a 0 or a 1).

So what he's doing, is checking if x is less than 0 or greater than 1.
If it is, then the Boolean result is true, which in POV-Ray is 1.
If it's not, then the result is false, or zero.
The negative option in the select statement never gets used - it's just there to
force the select function to have a zero option that's separate from the 1
option, since a 3-term select statement is divided into 2 results:  negative or
>= 0.

I hope that helps.

[Kenneth] Re: v3.8b2. height_field input values at 0.0 not... [1147 days 7 hours and 53 minutes ago]

Fri, 17 Feb 2023 00:00:00 GMT

"Kenneth" <kdw### [at] gmailcom> wrote:

>
> *If* that is the case, then the select() result can have only two states or
> outcomes-- true or false (or 1 and zero). Which would then pick either argument
> B or C, but never D(??) So, I am wondering if your f-boom macro will ever
> actually be chosen by this select() set-up.
>

Hmm. I think I muddied my question and my logic, sorry. I kind of mixed up what
happens in a 4-argument 'select' use.

But it would seem that only two of the three B-C-D select() results could be
chosen by your function, but not all three.

[Kenneth] Re: v3.8b2. height_field input values at 0.0 not... [1147 days 8 hours and 3 minutes ago]

Thu, 16 Feb 2023 23:50:00 GMT

On 2/15/23 05:34, William F Pokorny wrote:

[from a recent post in " Using a function in a height_field declaration" thread]

> Yes. Functions as used in height_fields never see called x,y values
> outside the [0-1] range.

> Forgot to plug a new povr function called f_boom() I believe should be
> in any v4.0 release.

> #include "functions.inc"
> #declare FnChkVals = function (x) {
>      select(((x<0.0) | (x>1.0)),
>          0,
>          0,
>          f_boom(x,2,3,4,5,6)
>      )
> }
>
> height_field {
>   function 500, 500 { FnChkVals(y) }

> A little ugly in that it throws after printing six values, but it offers
> a quick way for 'users' to test values in functions. Above we're testing
> that y as seen in the HF called function is never outside the [0,1]
> range.

I've been taking a look at this and playing around with it in a modified way--
leaving out  f_boom(...) and changing some values so that the construct itself
will work for me...

I didn't #include "functions.inc", just...

#declare FnChkVals = function (y) {
     select(((x<0.0) | (x>1.0)),
         0,
         0.3,
         0.6 // instead of f_boom
     )
}

height_field {
   function 500, 500 { FnChkVals(y) }
   }

As a result, I get a nice 'planar' height_field at y=0.3... so at least that's
my own 'sanity check', and that I can make it work in a basic way ;-)

But there is something about your construct that puzzles me, as I do not use
'select' very much. The documentation says, "Select compares the first argument
with zero, depending on the outcome it will return B, C or D."

The way I see
           select(((x<0.0) | (x>1.0))
is that it's basically a 'true/false' comparison(?) here. In other words, no
matter what the values of x might be, the result of the argument in parentheses
can only be a 'comparison against 0', by definition.

*If* that is the case, then the select() result can have only two states or
outcomes-- true or false (or 1 and zero). Which would then pick either argument
B or C, but never D(??) So, I am wondering if your f-boom macro will ever
actually be chosen by this select() set-up.

I assume that it *does* work for you, so I must have a misconception about
select() itself and how it operates here.

[William F Pokorny] Re: v3.8b2. height_field input values at 0.0 not... [1147 days 19 hours and 23 minutes ago]

Thu, 16 Feb 2023 12:30:22 GMT

On 2/15/23 08:15, William F Pokorny wrote:
> The HF zero (y as image/fnct evaluated) and z HF result should cleanly 
> show up no matter scaling! At best it is today noisy.

:-) My first thoughts are so often mostly wrong...

The problem in this scene starts with a coincident surface! If the 
height_field mesh is entirely at 0.0 in y, it is coincident with the 
plane in the scene. Fix this issue and results are solid no matter the 
scaling in y.

Note. Inbuilt Patterns especially often clamp to the [0-1] range due 
numerical noise.

Bill P.

More detail
-----------
The coincident surface signature is different than I'm used to. Here it 
is tangled with auto bounding in an odd way based on scaling in y. If I 
turn bounding off with -mb, the cases which had previously disappeared 
completely on larger or no scaling in y, are cleanly there - which is 
also an odd coincident surface signature.

No bounding and the smaller scaling is more there and with a more 
typical (to my eye's experience anyhow) coincident surface appearance.

I don't understand why scaling is affecting results as it is, but, I'm 
not going to further chase this.

[William F Pokorny] v3.8b2. height_field input values at 0.0 not cle... [1148 days 18 hours and 38 minutes ago]

Wed, 15 Feb 2023 13:15:25 GMT

The following code can be used to explore the issue. I've not yet dug 
beyond what I tried in this posted scene.

Just something I happened to see while looking into other height_field 
questions of late.

The HF zero (y as image/fnct evaluated) and z HF result should cleanly 
show up no matter scaling! At best it is today noisy.

Looks to be an issue back through v3.7 stable at least. I think given 
the noise it's likely some numerical and/or bounding issue rather than 
the actual HF mesh. We'll see.

Bill P.

// Test scene
#version 3.7;
global_settings { assumed_gamma 1 }

camera
{ // location <1,1,1> * 2
   location <1.5,3,-2>
   look_at <.5,.3,0>
   angle 50
}

light_source { <10,10,10>, rgb <1,1,1> }

height_field {
   function 500, 500 { 0 } // Noisy result at y scale 0.3? Poof 0.5?
//function 500, 500 { 1 } // This is always OK no matter the scaling.
   smooth
//scale <1, 0.3, 1> // Zero Fn val Noisy
//scale <1, 0.5, 1> // Zero Fn val. HF now invisible ?
// and with no scaling also invisible.
   pigment { green 0.8 }
}

//----------

plane{y,0 pigment{rgb .2}}

[William F Pokorny] Re: Spline causing 3.8 beta 2 to crash [1149 days 21 hours and 46 minutes ago]

Tue, 14 Feb 2023 10:06:51 GMT

On 2/14/23 03:31, jr wrote:
> need to get back to you in a few days, but quick look-see last night resulted in
> "error: 'CurrentTokenDataPtr' was not declared in this scope".  (looks like the
> code bases have diverged.. ;-))

Well, bummer. Perhaps the general approach I took would still fly with 
code changes not too major to work with v3.8 b2?

> 
> re Ubuntu.  Debian now packs all/bin/  in/usr/bin/, and makes the former a
> symlink; more Windows mid nineties than Linux ðŸ™.

:-)

Bill P.

[jr] Re: Spline causing 3.8 beta 2 to crash [1149 days 23 hours and 18 minutes ago]

Tue, 14 Feb 2023 08:35:00 GMT

hi,

William F Pokorny <ano### [at] anonymousorg> wrote:
> ...
> Thanks! I'm interested in whether the fix works for v3.8b2

need to get back to you in a few days, but quick look-see last night resulted in
"error: 'CurrentTokenDataPtr' was not declared in this scope".  (looks like the
code bases have diverged.. ;-))

re Ubuntu.  Debian now packs all /bin/ in /usr/bin/, and makes the former a
symlink; more Windows mid nineties than Linux :-(.

regards, jr.

[William F Pokorny] Re: Spline causing 3.8 beta 2 to crash [1150 days 13 hours and 31 minutes ago]

Mon, 13 Feb 2023 18:22:12 GMT

On 2/13/23 12:23, ingo wrote:
> Try FreeBSD? Much more stable in this regards (and in others probably too)

I've toyed with the idea of playing with other linux distributions, but 
not too seriously.

My povr branch is a unix/linux/osx only branch. The only way for windows 
users to play with it is the windows' linux subsystem - which is derived 
from Ubuntu. Ubuntu is also available and supported for the Raspberry Pi 
hardware.

Never say never, but yeah.

Bill P.

[ingo] Re: Spline causing 3.8 beta 2 to crash [1150 days 14 hours and 28 minutes ago]

Mon, 13 Feb 2023 17:25:00 GMT

William F Pokorny <ano### [at] anonymousorg> wrote:

> Anyhow. Change. I believe too a younger generation is coming to the fore
> support wise. They see things differently. Most of us old time unix /
> linux users are getting on in years. :-)
>

Try FreeBSD? Much more stable in this regards (and in others probably too)

ingo

[William F Pokorny] Re: Spline causing 3.8 beta 2 to crash [1150 days 14 hours and 46 minutes ago]

Mon, 13 Feb 2023 17:07:40 GMT

On 2/12/23 18:43, William F Pokorny wrote:
> My current fight is with autotools as upgraded. I cannot re-generate a 
> configure script cleanly - even with unchanged source! There are 
> multiple problems and the first ones looked at aren't making much sense 
> to me after spending a big chunk of time on it today. I'll probably next 
> try completely uninstalling / reinstalling - fingers and toes crossed.

OK. Spent another day or so banging away and I can now create updated 
configure scripts which work.

For the record...

- A chunk of the issues had to do with local M4 files in need of update 
due autotool changes.

- One update looks to be a change in the internals of the Ubuntu 22.04 
autoconf code tightening up on something previously allowed with an 
internal M4 macro - which probably should not have been. This tripped up 
one of the M4 macros I re-wrote for the dual (v1.2/v2.0) Simple Direct 
media Layer version support.

- The last autotools issue is another change internal to autoconf, which 
at the moment, I believe a mistake. On generation of configure there is 
some checking done on whether an automake and libtool script called 
'missing' runs. The previous generated code looked like:

---

# Expand $ac_aux_dir to an absolute path.
am_aux_dir=`cd "$ac_aux_dir" && pwd`

if test x"${MISSING+set}" != xset; then
   case $am_aux_dir in
   *\ * | *\	*)
     MISSING="\${SHELL} \"\"$am_aux_dir\"/missing\"" ;;
   *)
     MISSING="\${SHELL} \"$am_aux_dir\"/missing" ;;
   esac
fi
# Use eval to expand $SHELL
if eval "$MISSING --is-lightweight"; then
   am_missing_run="$MISSING "
else
   am_missing_run=
   { $as_echo "$as_me:${as_lineno-$LINENO}: WARNING: 'missing' script is 
too old or missing" >&5
$as_echo "$as_me: WARNING: 'missing' script is too old or missing" >&2;}
fi

---

The new failing code looks like:

    # Expand $ac_aux_dir to an absolute path.
am_aux_dir=`cd "$ac_aux_dir" && pwd`

   if test x"${MISSING+set}" != xset; then
   MISSING="\${SHELL} '\"$am_aux_dir\"/missing'"
fi
# Use eval to expand $SHELL
if eval "$MISSING --is-lightweight"; then
   am_missing_run="$MISSING "
else
   am_missing_run=
   { printf "%s\n" "$as_me:${as_lineno-$LINENO}: WARNING: 'missing' 
script is too old or missing" >&5
printf "%s\n" "$as_me: WARNING: 'missing' script is too old or missing" 
 >&2;}
fi

However, the eval "$MISSING --is-lightweight"; now always fails and 
am_missing_run gets set to null / nothing. We get a warning over an 
error as it is not a problem unless some autotools program later needed 
is truly missing. This won't usually happen - excepting maybe in 
corrupted autotools packages or disk failures and such.

Aside: I think someone noticed that case always selected only one of the 
MISSING forms, but when things got hard coded they set up a MISSING var 
which doesn't run! If I hard code the one previously always picked or 
change the code to look as it previously did, MISSING runs and the 
am_missing_run variable gets set up correctly. In the near term guess 
I'm stuck patching the generated configuration file(a) or letting the 
issue go. For the latter, users will, with a few exceptions, see an ugly 
warning message, but things will work.

There were also some necessary autoconf am updates and source code 
updates to hush a new BOOST warning on generic bind variables in the 
global name space(a). This warning doesn't prevent compilation, but it 
makes povr's clean output look ugly.

Bill P.

(a) - The bind methods available in newer c++ versions can perhaps 
replace the BOOST bind code, but I've not gotten around to attempting it.

[William F Pokorny] Re: Spline causing 3.8 beta 2 to crash [1150 days 15 hours and 23 minutes ago]

Mon, 13 Feb 2023 16:30:18 GMT

On 2/13/23 08:36, Cousin Ricky wrote:
> On 2023-02-12 19:43 (-4), William F Pokorny wrote:
>>
>> The 22.04 Ubuntu upgrade itself failed for me - a first. I had to patch
>> and polish to get things going at all. My guess is they'd not taken code
>> developers very much into account while testing. Developer related stuff
>> seemed to be the source of many issues.
> 
> My last few upgrades of openSUSE have seen more and more developer tools
> removed from the basic OS.  The excuse I heard was "security," but I'm
> starting to wonder if the overlords are seeing themselves as gate keepers.
> 
>> As you know, Christoph backed up the parser from the one I branched povr
>> off for the v3.8 release. In other words, I know the parser itself is
>> different than what is in povr and v4.0/master, but hopefully not in a
>> way which too much changed the spline parsing...
> 
> For what it's worth, these were my results with openSUSE Leap 15.3:
> 
>    povray-3.8.0-alpha.9945627   std::bad_alloc
>    povray-3.8.0-beta.1          std::bad_alloc
>    povray-3.8.0-beta.2          segmentation fault
>    povray-3.8.0-alpha.10013324  std::bad_alloc
>    povray-3.8.0-alpha.10064268  std::bad_alloc
> 
> I believe alpha.9945627 was the rollback point.
> 

Thanks and this must mean the fix for Ingo's issue was done by Christoph 
between v3.8 beta1 and beta2.

On recent linux distributions I get that those supporting them want to 
simplify their jobs and the less you ship officially the simpler it is.

With Ubuntu I 'suspect' some of what's happening are changes due its 
broadening adoption - as the windows linux subsystem, for example. I'd 
make a small bet the change in core file handling was done in part to 
better support such uses. The old core handling has issues too.

One of my other pet peeves with Ubuntu 22.04 is they've adopted snaps 
(code on VMs) as the up front supported code for shipped packages like 
firefox. OK, except, I have long run firefox against files located all 
over my computer's file system - especially off ram disks - and by 
default most such file systems are not accessible from within the snap 
instances.

Anyhow. Change. I believe too a younger generation is coming to the fore 
support wise. They see things differently. Most of us old time unix / 
linux users are getting on in years. :-)

Bill P.

[Cousin Ricky] Re: Spline causing 3.8 beta 2 to crash [1150 days 18 hours and 17 minutes ago]

Mon, 13 Feb 2023 13:36:26 GMT

On 2023-02-12 19:43 (-4), William F Pokorny wrote:
> 
> The 22.04 Ubuntu upgrade itself failed for me - a first. I had to patch
> and polish to get things going at all. My guess is they'd not taken code
> developers very much into account while testing. Developer related stuff
> seemed to be the source of many issues.

My last few upgrades of openSUSE have seen more and more developer tools
removed from the basic OS.  The excuse I heard was "security," but I'm
starting to wonder if the overlords are seeing themselves as gate keepers.

> As you know, Christoph backed up the parser from the one I branched povr
> off for the v3.8 release. In other words, I know the parser itself is
> different than what is in povr and v4.0/master, but hopefully not in a
> way which too much changed the spline parsing...

For what it's worth, these were my results with openSUSE Leap 15.3:

  povray-3.8.0-alpha.9945627   std::bad_alloc
  povray-3.8.0-beta.1          std::bad_alloc
  povray-3.8.0-beta.2          segmentation fault
  povray-3.8.0-alpha.10013324  std::bad_alloc
  povray-3.8.0-alpha.10064268  std::bad_alloc

I believe alpha.9945627 was the rollback point.

[William F Pokorny] Re: Spline causing 3.8 beta 2 to crash [1151 days 8 hours and 10 minutes ago]

Sun, 12 Feb 2023 23:43:04 GMT

On 2/12/23 09:59, jr wrote:
> will there be an updated 'povr' in the near future ?  (it's been a while)
> 

Honest answer is I don't know. Almost exactly a year ago I was pushing 
for one and then - stuff. Lately been starting to play with things again.

However, after my Ubuntu 22.04 upgrade I've still got development issues 
to sort. :-( Some of it is me just not staying current due the long 
break from heavy coding.

The Ubuntu segfault core files are now all in one directory uniquely 
named, for example. It took me an embarrassing amount of time to realize 
that not getting core files wasn't do any of the usual issues, but 
simply that they were not located or named as they always had been. I 
could write (rant) more on the topic, but...

The 22.04 Ubuntu upgrade itself failed for me - a first. I had to patch 
and polish to get things going at all. My guess is they'd not taken code 
developers very much into account while testing. Developer related stuff 
seemed to be the source of many issues.

My current fight is with autotools as upgraded. I cannot re-generate a 
configure script cleanly - even with unchanged source! There are 
multiple problems and the first ones looked at aren't making much sense 
to me after spending a big chunk of time on it today. I'll probably next 
try completely uninstalling / reinstalling - fingers and toes crossed. 

To do the debugging I did for this thread I had to dig up an old 
configure file for the same source. The old one from July of last year 
still worked.

It's frustrating to be dealing mostly with the development environment 
and I find myself not wanting to fight through it. But, I'll have to 
grind it out, if I want to put together and ship a povr update. We'll see.

Aside: There's also a list of little things different and annoying in 
22.04 too that I'm just living with at the moment.

> will try and patch beta.2 with the update, in the coming days, for testing.

Thanks! I'm interested in whether the fix works for v3.8b2

As you know, Christoph backed up the parser from the one I branched povr 
off for the v3.8 release. In other words, I know the parser itself is 
different than what is in povr and v4.0/master, but hopefully not in a 
way which too much changed the spline parsing...

Bill P.

[jr] Re: Spline causing 3.8 beta 2 to crash [1151 days 16 hours and 53 minutes ago]

Sun, 12 Feb 2023 15:00:00 GMT

hi,

William F Pokorny <ano### [at] anonymousorg> wrote:
> ...
> The updated code works for all my povr branch spline testing. It will
> likely fix any v3.8/v4.0 code too, but I've not tested that claim.

will there be an updated 'povr' in the near future ?  (it's been a while)

will try and patch beta.2 with the update, in the coming days, for testing.

regards, jr.

[William F Pokorny] Re: Spline causing 3.8 beta 2 to crash [1153 days 15 hours and 19 minutes ago]

Fri, 10 Feb 2023 16:34:32 GMT

On 2/9/23 07:39, William F Pokorny wrote:
> What I suspect off the top of my head is more recent parser code is 
> dumping the macro defined #local spline where it should not. The first 
> question is why and have a thought or two(a).
> 
> (a) For example, wondering about the new macro caching mechanism and 
> whether it makes the macro 'look' like it's in another ram file with 
> respect to #local ID / spline content persistence.

True to form, my first guesses as to the problem were mostly wrong. :-)

The v3.7 code was aware the #local spine ID might go out of macro or 
file scope. The code did extra work using the old style C++ object 
reference counting and, if need be, local copies of the spline. This why 
v3.7 works for the originally posted code.

At some point after v3.7 the the Parse_Spline() code was substantially 
re-written for reasons about which I'm unsure(a), but in part it 
eliminated the reference counting bits which protected against premature 
deletions of objects by the parser on scope changes.

The code appeared to me to have other issues too. I've attached an 
updated Parse_Spline() which in v3.8/v4.0 is found in:

source/parser/parser_expressions.cpp

The updated code works for all my povr branch spline testing. It will 
likely fix any v3.8/v4.0 code too, but I've not tested that claim.

Bill P.

(a) The newer code allows some interesting things like:

#declare A1=spline {
    cubic_spline
    -0.5, < 1,-1, 0>
     0.0, < 1, 0, 0>
     0.5, < 2, 1, 0>
     1.0, < 1, 2, 0>
     1.5, < 1, 3, 0>
}
#declare A2=spline {A1 linear_spline}
#declare A3=spline {A1 natural_spline
         2.0, < 1, 4, 0>
         2.5, < 2, 4, 0>
         3.0, < 2, 2, 0>
}

[Kenneth] Re: Spline causing 3.8 beta 2 to crash [1153 days 18 hours and 58 minutes ago]

Fri, 10 Feb 2023 12:55:00 GMT

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

>
> A #local has to be declared in a temporary location, then released when
> the macro returns.  This is opportunity for an allocation/de-allocation
> mix-up that doesn't occur with #declare.

Ah, I see. I don't know much about the subtle(?) inner code-workings of #local
vs. #declare, but I grasp the idea. I arrived at my 'fix' in my usual way--
trial-and-error guesswork, ha.

[Kenneth] Re: Spline causing 3.8 beta 2 to crash [1153 days 19 hours and 8 minutes ago]

Fri, 10 Feb 2023 12:45:00 GMT

William F Pokorny <ano### [at] anonymousorg> wrote:
>
> The debugging you all have done has been helpful to me. Thanks!
>
> Short on time but, I think we are seeing two different failure
> mechanisms, the second being tangled in the fix for Ingo's spline issue
> from July 2021...

That was some good and fast detective work! I was hoping that you would take a
look. ;-)

[Cousin Ricky] Re: Spline causing 3.8 beta 2 to crash [1154 days 12 hours and 44 minutes ago]

Thu, 9 Feb 2023 19:09:23 GMT

On 2/9/23 06:02, Kenneth wrote:
> Just discovered that your full original code example (WITH #debug) works OK, if
> the #local inside the macro is changed to #declare. Why that should matter, I
> don't know.

A #local has to be declared in a temporary location, then released when
the macro returns.  This is opportunity for an allocation/de-allocation
mix-up that doesn't occur with #declare.

[William F Pokorny] Re: Spline causing 3.8 beta 2 to crash [1154 days 19 hours and 14 minutes ago]

Thu, 9 Feb 2023 12:39:38 GMT

On 2/9/23 05:02, Kenneth wrote:
> Just discovered that your full original code example (WITH #debug) works OK, if
> the #local inside the macro is changed to #declare. Why that should matter, I
> don't know.
> 
> #macro make_spline()
>      #declare _s   = spline {
>          quadratic_spline
>          0, <0, 0, 0>,
>          1, <0, 0, 1>,
>          2, <1, 0, 2>,
>          3, <2, 1, 3>
>      }
>      _s
> #end
> 
> #local myspline = spline { make_spline() }
> 
> #debug concat("_pt=<", vstr(3, myspline(0), ",", 0, 3), ">\n")
> 

The debugging you all have done has been helpful to me. Thanks!

Short on time but, I think we are seeing two different failure 
mechanisms, the second being tangled in the fix for Ingo's spline issue 
from July 2021. Ref:

http://news.povray.org/povray.beta-test/thread/%3CXnsAD687938A665Aseed7%40news.povray.org%3E/

Message: <XnsAD687938A665Aseed7@news.povray.org>

Running my povr branch with the final form of the fix using a clone 
method suggested by Christoph over my original code, I get the 
segmentation fault seen by many of you in newer official POV-Ray code. I 
have traced the segfault to this bit in parser_expressions.cpp:

     if (!New)
     {
         if (Old)
         {
             // Note. v3.7/v3.8 was always: New = new LinearSpline(*Old);
             New = Old->Clone(); // <-- Segfault with Clone method.

If I revert to the previous & incorrect code of:

           New = new LinearSpline(*Old);

I then see:

Parse Error:
std::bad_array_new_length

which is perhaps a different signature for the same bug, but I've not 
had time to dig into it.

Also not looked yet at the v3.7 stable code. The parser changed somewhat 
significantly after v3.7 as many know.

What I suspect off the top of my head is more recent parser code is 
dumping the macro defined #local spline where it should not. The first 
question is why and have a thought or two(a).

(a) For example, wondering about the new macro caching mechanism and 
whether it makes the macro 'look' like it's in another ram file with 
respect to #local ID / spline content persistence.

Bill P.

[Kenneth] Re: Spline causing 3.8 beta 2 to crash [1154 days 21 hours and 48 minutes ago]

Thu, 9 Feb 2023 10:05:00 GMT

Just discovered that your full original code example (WITH #debug) works OK, if
the #local inside the macro is changed to #declare. Why that should matter, I
don't know.

#macro make_spline()
    #declare _s   = spline {
        quadratic_spline
        0, <0, 0, 0>,
        1, <0, 0, 1>,
        2, <1, 0, 2>,
        3, <2, 1, 3>
    }
    _s
#end

#local myspline = spline { make_spline() }

#debug concat("_pt=<", vstr(3, myspline(0), ",", 0, 3), ">\n")

[Cousin Ricky] Re: Spline causing 3.8 beta 2 to crash [1155 days 5 hours and 52 minutes ago]

Thu, 9 Feb 2023 02:01:11 GMT

On 2023-02-08 10:54 (-4), Chris R wrote:
> "Chris R" <car### [at] comcastnet> wrote:
>> I have been experiencing crashes running the latest beta of POV-Ray v3.8 (Win64)
>> when trying to call a spline.  The narrowed it down to a few lines of code that
>> causes the crash:
>>
>> [snip]

Confirmed on GNU/Linux.  V3.8 beta 2 yields a seg fault.  All other
versions I have beyond 3.1.0.10, including the master branch, UberPOV,
and the discontinued v3.7.1-RC1, yield "std::bad_alloc".  My oldest
UberPOV is 1.37.1.0-b10.

> One last observation, the following code also seems to work fine.  This leads me
> to believe the problem lies with returning the spline identifier from the macro
> and then trying to use it.  It's a kludgy work-around, but I can use it to
> continue on my current project.
> 
> #macro make_spline_macro()
> #declare myspline = spline {
>    natural_spline
>    0, <0, 0, 0>,
>    1, <0, 0, 1>,
>    2, <1, 0, 2>,
>    3, <2, 1, 3>
> }
> #end
> 
> make_spline_macro()
> 
> #debug concat("_pt=<", vstr(3, myspline(0), ",", 0, 3), ">\n")

This non-kludgy workaround also works:

#macro make_spline()
    spline {
        quadratic_spline
        0, <0, 0, 0>,
        1, <0, 0, 1>,
        2, <1, 0, 2>,
        3, <2, 1, 3>
    }
#end

#local myspline = make_spline()

#debug concat("_pt=<", vstr(3, myspline(0), ",", 0, 3), ">\n")

[Kenneth] Re: Spline causing 3.8 beta 2 to crash [1155 days 12 hours and 53 minutes ago]

Wed, 8 Feb 2023 19:00:00 GMT

"Kenneth" <kdw### [at] gmailcom> wrote:
>
> I find that the above by itself runs OK in Windows 10, no fatal error.

Sorry, I meant to include your #local myspline too. The following still runs OK.

#macro make_spline()
    #local _s   = spline {
        quadratic_spline
        0, <0, 0, 0>,
        1, <0, 0, 1>,
        2, <1, 0, 2>,
        3, <2, 1, 3>
    }
    _s
#end

#local myspline = spline { make_spline() }
>
> However, adding your #debug line causes the memory access violation.

[Kenneth] Re: Spline causing 3.8 beta 2 to crash [1155 days 13 hours and 38 minutes ago]

Wed, 8 Feb 2023 18:15:00 GMT

"Chris R" <car### [at] comcastnet> wrote:
> ..narrowed it down to a few lines of code that
> causes the crash:
>
> #macro make_spline()
>     #local _s   = spline {
>         quadratic_spline
>         0, <0, 0, 0>,
>         1, <0, 0, 1>,
>         2, <1, 0, 2>,
>         3, <2, 1, 3>
>     }
>     _s
> #end
>

I find that the above by itself runs OK in Windows 10, no fatal error. (I'm
running v3.8.0 beta 1, but I don't expect beta 2 to be much different.)

However, adding your #debug line causes the memory access violation.

[jr] Re: Spline causing 3.8 beta 2 to crash [1155 days 16 hours and 28 minutes ago]

Wed, 8 Feb 2023 15:25:00 GMT

"jr" <cre### [at] gmailcom> wrote:
> ...
> changing the macro to
>
> #macro make_spline()
>     spline {
>         quadratic_spline
>         0, <0, 0, 0>,
>         1, <0, 0, 1>,
>         2, <1, 0, 2>,
>         3, <2, 1, 3>
>     }
> #end
>

and then writing

#declare myspline = make_spline();

appears to work, though.


regards, jr.

[jr] Re: Spline causing 3.8 beta 2 to crash [1155 days 16 hours and 38 minutes ago]

Wed, 8 Feb 2023 15:15:00 GMT

hi,

"Chris R" <car### [at] comcastnet> wrote:
> I have been experiencing crashes running the latest beta of POV-Ray v3.8 (Win64)
> when trying to call a spline.  The narrowed it down to a few lines of code that
> causes the crash:
>
> #macro make_spline()
>     #local _s   = spline {
>         quadratic_spline
>         0, <0, 0, 0>,
>         1, <0, 0, 1>,
>         2, <1, 0, 2>,
>         3, <2, 1, 3>
>     }
>     _s
> #end
>
> #local myspline = spline { make_spline() }
>
> #debug concat("_pt=<", vstr(3, myspline(0), ",", 0, 3), ">\n")
>
> The contents of the spline don't seem to matter nor does the type of spline.
> The result is a memory access violation.

my self compiled beta.2 (Linux) too crashes, same error I think.  the
alpha.9945627 outputs the 'pt_' ok.

changing the macro to

#macro make_spline()
    spline {
        quadratic_spline
        0, <0, 0, 0>,
        1, <0, 0, 1>,
        2, <1, 0, 2>,
        3, <2, 1, 3>
    }
#end

gives me 'Parse Error: Spline must have at least one entry.', and no crash.


regards, jr.

[Chris R] Re: Spline causing 3.8 beta 2 to crash [1155 days 16 hours and 58 minutes ago]

Wed, 8 Feb 2023 14:55:00 GMT

"Chris R" <car### [at] comcastnet> wrote:
> I have been experiencing crashes running the latest beta of POV-Ray v3.8 (Win64)
> when trying to call a spline.  The narrowed it down to a few lines of code that
> causes the crash:
>
> #macro make_spline()
>     #local _s   = spline {
>         quadratic_spline
>         0, <0, 0, 0>,
>         1, <0, 0, 1>,
>         2, <1, 0, 2>,
>         3, <2, 1, 3>
>     }
>     _s
> #end
>
> #local myspline = spline { make_spline() }
>
> #debug concat("_pt=<", vstr(3, myspline(0), ",", 0, 3), ">\n")
>
> The contents of the spline don't seem to matter nor does the type of spline.
> The result is a memory access violation.
>
> When I run the same code on v3.7 it works fine.
>
> Declaring the spline outside of a macro does not cause the crash:
>
> #local myspline   = spline {
>     natural_spline
>     0, <0, 0, 0>,
>     1, <0, 0, 1>,
>     2, <1, 0, 2>,
>     3, <2, 1, 3>
> }
>
> #debug concat("_pt=<", vstr(3, myspline(0), ",", 0, 3), ">\n")
>
> -- Chris R.

One last observation, the following code also seems to work fine.  This leads me
to believe the problem lies with returning the spline identifier from the macro
and then trying to use it.  It's a kludgy work-around, but I can use it to
continue on my current project.

#macro make_spline_macro()
#declare myspline = spline {
   natural_spline
   0, <0, 0, 0>,
   1, <0, 0, 1>,
   2, <1, 0, 2>,
   3, <2, 1, 3>
}
#end

make_spline_macro()

#debug concat("_pt=<", vstr(3, myspline(0), ",", 0, 3), ">\n")


-- Chris R.

[Chris R] Spline causing 3.8 beta 2 to crash [1155 days 17 hours and 3 minutes ago]

Wed, 8 Feb 2023 14:50:00 GMT

I have been experiencing crashes running the latest beta of POV-Ray v3.8 (Win64)
when trying to call a spline.  The narrowed it down to a few lines of code that
causes the crash:

#macro make_spline()
    #local _s   = spline {
        quadratic_spline
        0, <0, 0, 0>,
        1, <0, 0, 1>,
        2, <1, 0, 2>,
        3, <2, 1, 3>
    }
    _s
#end

#local myspline = spline { make_spline() }

#debug concat("_pt=<", vstr(3, myspline(0), ",", 0, 3), ">\n")

The contents of the spline don't seem to matter nor does the type of spline.
The result is a memory access violation.

When I run the same code on v3.7 it works fine.

Declaring the spline outside of a macro does not cause the crash:

#local myspline   = spline {
    natural_spline
    0, <0, 0, 0>,
    1, <0, 0, 1>,
    2, <1, 0, 2>,
    3, <2, 1, 3>
}

#debug concat("_pt=<", vstr(3, myspline(0), ",", 0, 3), ">\n")

-- Chris R.

[Mr] Re: Is this version still moving forward? [1251 days 21 hours and 28 minutes ago]

Fri, 4 Nov 2022 10:25:00 GMT

"The Traveler" <jho### [at] northrimnet> wrote:
> "The Traveler" <jho### [at] northrimnet> wrote:
> > Howdy all.
> > Just wondering if this beta is still moving towards a release candidate. Povray
> > has always had somewhat long intervals between releases, so, just askin'.
> >
> > Cheers.
>
> Well, here it is November and it appears that the 3.8.0-Beta2 version hasn't
> seen any further changes in over a year.
>
> Is the codebase in need of a new maintainer or ???
>
> Cheers.

Hi Jeff ! Please any core developer correct me if I'm wrong, but from what I
read, qualified maintainers are indeed welcome, especially for:

a) Versioning and cross-platform building process :
* motivation to invest in git + github is absolutely required, But also
importantly, means to test a Unix (Linux+mac) + Windows build process. Work on
all of this has been started by Clipka and he may even show up again once people
are ready to move the whole development process in that direction. AND once
point b and c are complete.

b) Updating current Macros (they also contain many typos) and integrate these
updates to the github repo.
[personal opinion:]
Thomas de Groot and Cousin Ricky have made great contributions, some of which
definitely would need to be added to main master since they are much more worth
it than current official ones. Also a lot of reaching out needs to be done to
relicence and also integrate or rewrite as fit to do so the "legendary" macros
such as lightsys etc. [:end personal opinion]

c) Documentation which is currently one of the biggest show slower/stopper
before release:
* Media Wiki is still currently one of the entry point tools where you can start
but draft paragraphs can even be proposed here. People have indeed complained
that docs where not updated everywhere but this needs to be formalized for every
point brought up. Made into high quality text and illustrations.[personal
opinion:] some illustrations have inddeed been lacking even for existing docs.
but more importantly the quality definitely needs to be improved to reflect pov
real artistic capacity. POV can no longer afford to look old.[:end personal
opinion] Once it is considered up to date, there is a process to convert the
wiki to offline help files that needs to be dust off, run and probably fixed.

In all of this the only part I can personnally help one with currently, are the
wiki and reaching out to specific people. Take care, thanks for your interest in
all this as people like you make POV what it is !

[The Traveler] Re: Is this version still moving forward? [1254 days 11 hours and 48 minutes ago]

Tue, 1 Nov 2022 20:05:00 GMT

"The Traveler" <jho### [at] northrimnet> wrote:
> Howdy all.
> Just wondering if this beta is still moving towards a release candidate. Povray
> has always had somewhat long intervals between releases, so, just askin'.
>
> Cheers.

Well, here it is November and it appears that the 3.8.0-Beta2 version hasn't
seen any further changes in over a year.

Is the codebase in need of a new maintainer or ???

Cheers.

[Saul Luizaga] Re: typ error [1364 days 6 hours and 22 minutes ago]

Fri, 15 Jul 2022 01:30:56 GMT

On 14/07/2022 08:00, Thomas de Groot wrote:
> Op 14-7-2022 om 12:10 schreef Saul Luizaga:
> 
>> Yes thank you and Bold Eagle, it's a Windows build, I uninstalled a 29 
>> Dec 2021 v3.8.0b2 and it doesn't ha that line, looks like is something 
>> developers want to introduce in the final 3.8, so it comes only on the 
>> latest beta builds; but thanks for the help
>>
>>
> I got it also for 3.7 and I seem to remember that I downloaded the 
> package, years ago, from: 
> http://www.f-lohmueller.de/pov_tut/down/insert_a.htm
> 
> Possibly, it followed me over all those years and through different pov 
> updates by simply copy/past the insert menu each time...
> Hmmm, interesting, only a copy-paste huh? I'll try that, thank you


-- 
El software de antivirus Avast ha analizado este correo electrÃ³nico en
 busca de virus.
https://www.avast.com/antivirus

[Thomas de Groot] Re: typ error [1364 days 19 hours and 53 minutes ago]

Thu, 14 Jul 2022 12:00:23 GMT

Op 14-7-2022 om 12:10 schreef Saul Luizaga:

> Yes thank you and Bold Eagle, it's a Windows build, I uninstalled a 29 
> Dec 2021 v3.8.0b2 and it doesn't ha that line, looks like is something 
> developers want to introduce in the final 3.8, so it comes only on the 
> latest beta builds; but thanks for the help
> 
> 
I got it also for 3.7 and I seem to remember that I downloaded the 
package, years ago, from: 
http://www.f-lohmueller.de/pov_tut/down/insert_a.htm

Possibly, it followed me over all those years and through different pov 
updates by simply copy/past the insert menu each time...

-- 
Thomas

[Saul Luizaga] Re: typ error [1364 days 21 hours and 27 minutes ago]

Thu, 14 Jul 2022 10:26:14 GMT

On 14/07/2022 06:10, Saul Luizaga wrote:
> On 11/07/2022 08:08, Thomas de Groot wrote:
>> Op 11-7-2022 om 11:50 schreef Saul Luizaga:
>>> #version 3.7;
>>>
>>> Error Message:
>>> POV-Ray\v3.8-beta\Insert Menu\Basic shapes.pov" line 7: Parse Error: 
>>> Expected 'numeric expression', undeclared identifier 'Typ' found instead
>>>
>>> This error is on many files.
>>> Is there a way to automate the replacement of this word with another 
>>> that works?
>>>
>>>
>> This is a Friedrich Lohmueller file, part of the original (Windows) 
>> download package. To use it directly, you need to uncomment line 5:
>> Â Â Â Â Â Â  //#declare
Typ = 62; // for testing
>>
>> Initially, when you install POV-Ray, you have (somewhere) the 
>> possibility to generate thumbnails for the complete Insert Menu. I 
>> don't remember however, how to start that :-( It was created by 
>> Friedrich and made part of the POV-Ray download package.
>>
> Yes thank you and Bold Eagle, it's a Windows build, I uninstalled a 29 
> Dec 2021 v3.8.0b2 and it doesn't ha that line, looks like is something 
> developers want to introduce in the final 3.8, so it comes only on the 
> latest beta builds; but thanks for the help
> 
But if I find the line again, I'll comment it out, thanks again


-- 
El software de antivirus Avast ha analizado este correo electrÃ³nico en
busca de virus.
https://www.avast.com/antivirus

[Saul Luizaga] Re: typ error [1364 days 21 hours and 42 minutes ago]

Thu, 14 Jul 2022 10:10:59 GMT

On 11/07/2022 08:08, Thomas de Groot wrote:
> Op 11-7-2022 om 11:50 schreef Saul Luizaga:
>> #version 3.7;
>>
>> Error Message:
>> POV-Ray\v3.8-beta\Insert Menu\Basic shapes.pov" line 7: Parse Error: 
>> Expected 'numeric expression', undeclared identifier 'Typ' found instead
>>
>> This error is on many files.
>> Is there a way to automate the replacement of this word with another 
>> that works?
>>
>>
> This is a Friedrich Lohmueller file, part of the original (Windows) 
> download package. To use it directly, you need to uncomment line 5:
>  Â Â Â Â Â  //#declare Typ = 62;
// for testing
> 
> Initially, when you install POV-Ray, you have (somewhere) the 
> possibility to generate thumbnails for the complete Insert Menu. I don't 
> remember however, how to start that :-( It was created by Friedrich and 
> made part of the POV-Ray download package.
> 
Yes thank you and Bold Eagle, it's a Windows build, I uninstalled a 29 
Dec 2021 v3.8.0b2 and it doesn't ha that line, looks like is something 
developers want to introduce in the final 3.8, so it comes only on the 
latest beta builds; but thanks for the help


-- 
El software de antivirus Avast ha analizado este correo electrÃ³nico en
busca de virus.
https://www.avast.com/antivirus

[Saul Luizaga] Re: typ error [1364 days 21 hours and 43 minutes ago]

Thu, 14 Jul 2022 10:10:21 GMT

On 11/07/2022 08:08, Thomas de Groot wrote:
> Op 11-7-2022 om 11:50 schreef Saul Luizaga:
>> #version 3.7;
>>
>> Error Message:
>> POV-Ray\v3.8-beta\Insert Menu\Basic shapes.pov" line 7: Parse Error: 
>> Expected 'numeric expression', undeclared identifier 'Typ' found instead
>>
>> This error is on many files.
>> Is there a way to automate the replacement of this word with another 
>> that works?
>>
>>
> This is a Friedrich Lohmueller file, part of the original (Windows) 
> download package. To use it directly, you need to uncomment line 5:
>  Â Â Â Â Â  //#declare Typ = 62;
// for testing
> 
> Initially, when you install POV-Ray, you have (somewhere) the 
> possibility to generate thumbnails for the complete Insert Menu. I don't 
> remember however, how to start that :-( It was created by Friedrich and 
> made part of the POV-Ray download package.
> 
Yes thank you and Bold Eagle, it's a Windows build, I uninstalled a 29 
Dec 2021 v3.8.0b2 and it doesn't ha that line, looks like is something 
developers want to introduce in the final 3.8, so it comes only on the 
latest beta builds; but thanks for the help


-- 
El software de antivirus Avast ha analizado este correo electrÃ³nico en
busca de virus.
https://www.avast.com/antivirus

[Thomas de Groot] Re: typ error [1367 days 19 hours and 45 minutes ago]

Mon, 11 Jul 2022 12:08:13 GMT

Op 11-7-2022 om 11:50 schreef Saul Luizaga:
> #version 3.7;
> 
> Error Message:
> POV-Ray\v3.8-beta\Insert Menu\Basic shapes.pov" line 7: Parse Error: 
> Expected 'numeric expression', undeclared identifier 'Typ' found instead
> 
> This error is on many files.
> Is there a way to automate the replacement of this word with another 
> that works?
> 
> 
This is a Friedrich Lohmueller file, part of the original (Windows) 
download package. To use it directly, you need to uncomment line 5:
       //#declare Typ = 62; // for testing

Initially, when you install POV-Ray, you have (somewhere) the 
possibility to generate thumbnails for the complete Insert Menu. I don't 
remember however, how to start that :-( It was created by Friedrich and 
made part of the POV-Ray download package.

-- 
Thomas

[Bald Eagle] Re: typ error [1367 days 21 hours and 18 minutes ago]

Mon, 11 Jul 2022 10:35:00 GMT

Saul Luizaga <sau### [at] gmailcom> wrote:
> #version 3.7;
>
> Error Message:
> POV-Ray\v3.8-beta\Insert Menu\Basic shapes.pov" line 7: Parse Error:
> Expected 'numeric expression', undeclared identifier 'Typ' found instead
>
> This error is on many files.
> Is there a way to automate the replacement of this word with another
> that works?

I don't seem to have that file in my Insert Menu directory.

/usr/share/qtpovray-3.8/Insert Menu/Animation.pov
/usr/share/qtpovray-3.8/Insert Menu/Attributes.pov
/usr/share/qtpovray-3.8/Insert Menu/Basic shapes.pov
/usr/share/qtpovray-3.8/Insert Menu/Camera.pov
/usr/share/qtpovray-3.8/Insert Menu/Colors.pov
/usr/share/qtpovray-3.8/Insert Menu/CSG_Material.pov
/usr/share/qtpovray-3.8/Insert Menu/Images.ini
/usr/share/qtpovray-3.8/Insert Menu/Images.pov
/usr/share/qtpovray-3.8/Insert Menu/Include.pov
/usr/share/qtpovray-3.8/Insert Menu/IncludeFiles_own.pov
/usr/share/qtpovray-3.8/Insert Menu/Lights.pov
/usr/share/qtpovray-3.8/Insert Menu/Loops_sweep_spline.pov
/usr/share/qtpovray-3.8/Insert Menu/Material.pov
/usr/share/qtpovray-3.8/Insert Menu/Math functions.pov
/usr/share/qtpovray-3.8/Insert Menu/Meshmaker.pov
/usr/share/qtpovray-3.8/Insert Menu/Metals.pov
/usr/share/qtpovray-3.8/Insert Menu/Normal.pov
/usr/share/qtpovray-3.8/Insert Menu/No_XXX.pov
/usr/share/qtpovray-3.8/Insert Menu/Patterns.pov
/usr/share/qtpovray-3.8/Insert Menu/Photons_and_Radiosity.pov
/usr/share/qtpovray-3.8/Insert Menu/Random.pov
/usr/share/qtpovray-3.8/Insert Menu/Ready made scenes.pov
/usr/share/qtpovray-3.8/Insert Menu/Shapes2.pov
/usr/share/qtpovray-3.8/Insert Menu/Shapes3.pov
/usr/share/qtpovray-3.8/Insert Menu/Shear_Transform.pov
/usr/share/qtpovray-3.8/Insert Menu/Sky.pov
/usr/share/qtpovray-3.8/Insert Menu/Special shapes.pov
/usr/share/qtpovray-3.8/Insert Menu/Stones_and_Granites.pov
/usr/share/qtpovray-3.8/Insert Menu/Tex_Mat.pov
/usr/share/qtpovray-3.8/Insert Menu/Transform.pov
/usr/share/qtpovray-3.8/Insert Menu/Woods.pov

Maybe you copy-pasted the file and the "Typ" is part of a commented line?

Other than that, no idea.
I'm sure you could try some regular expression replacement technique - no idea
how to do that in Win/Dos.   Maybe a text editor/word processor...

Best to find out what the actual problem is first.

[Saul Luizaga] typ error [1367 days 22 hours and 3 minutes ago]

Mon, 11 Jul 2022 09:50:27 GMT

#version 3.7;

Error Message:
POV-Ray\v3.8-beta\Insert Menu\Basic shapes.pov" line 7: Parse Error: 
Expected 'numeric expression', undeclared identifier 'Typ' found instead

This error is on many files.
Is there a way to automate the replacement of this word with another 
that works?


-- 
El software de antivirus Avast ha analizado este correo electrÃ³nico en
 busca de virus.
https://www.avast.com/antivirus

[The Traveler] Is this version still moving forward? [1413 days 14 hours and 43 minutes ago]

Thu, 26 May 2022 17:10:00 GMT

Howdy all.
Just wondering if this beta is still moving towards a release candidate. Povray
has always had somewhat long intervals between releases, so, just askin'.

Cheers.

[jr] Re: Ambient and diffuse for include files? [1492 days 17 hours and 38 minutes ago]

Tue, 8 Mar 2022 14:15:00 GMT

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.

[Bald Eagle] Re: Ambient and diffuse for include files? [1492 days 20 hours and 8 minutes ago]

Tue, 8 Mar 2022 11:45:00 GMT

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.

[Thomas de Groot] Re: Ambient and diffuse for include files? [1493 days and 30 minutes ago]

Tue, 8 Mar 2022 07:23:28 GMT

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

[Cousin Ricky] Ambient and diffuse for include files? [1493 days 13 hours and 20 minutes ago]

Mon, 7 Mar 2022 18:33:29 GMT

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?

[William F Pokorny] Concerns with the tiling pattern's numerical sta... [1500 days 20 hours and 49 minutes ago]

Mon, 28 Feb 2022 11:03:45 GMT

Documenting.

As 'a few' might recall, I hit issues in the tiling patterns while using 
them to create isosurfaces. Bugs on the tile edges. To the set of tests 
cases I created, I'd I fixed all the code problems or, addressed my own 
stupidity where the problems were with my test set up.

In coming back to the tiling patterns for some povr testing, I 
suddenly(1) picked up 'new' isosurface issues with tiling's 13 and 14. 
On more digging, it looks like there are generic issues in these two, 
similar, patterns. Issues I fear exist in other tiling patterns too, but 
I've not gone looking for more grief as yet.

(1) - Used a different image resolution.

What I see thus far... Rendering tiling 14 at a resolution of 1000x1000 
with no AA, I get the attached image. Whether the artifacts appear or 
not and to a degree where they appear depends upon resolution, rendering 
aspect ratios, AA/jitter settings, pattern transforms and incoming ray 
spacial orientations.

In looking at the code I noticed it uses a c++ switch statement where no 
default was set up. On adding defaults which throw I can see we are 
fairly often missing all the case statements when, for example, I render 
with a ratio of 1000x999, with AA - with many common situations. But, 
this just one internal issues (I've isolated three).

More generally, we are getting noise on the changes in the value slopes. 
With stronger AA and typical situations the noise won't be very visible 
(or might even disappear) - at the expense of additional rendering time. 
However, it calls into question whether these patterns are generally 
safe in applications like isosurfaces where we cannot tolerate such 
noise.

In the code I see potential numerical problems. I've twiddled. I can 
make some artifacts better - while making others worse. Thus far it's a 
game of 'whack a mole.' :-(

The only general solution coming to mind is to multiply sample about 
each 'Evaluate' position and toss the value outlier(s). Not an approach 
that's free.

Internal sampling as an option? I don't know... Going to let the issue 
bang around in my head for a while. Hmm, maybe an extended approach to 
tiling using explicit polygons/edges to delineate the ramped value 
regions and any edge values. switch/case selection by evaluation-point 
inside polygon test as a start. Something prior to any ramped value 
calculation? ...We could even make these tiling patterns 1-n discrete 
patterns - by option - that way I think...

Bill P.

[Alain Martel] Re: weird white stain with beta povray v3.8.0 (n... [1535 days 18 hours and 52 minutes ago]

Mon, 24 Jan 2022 13:01:33 GMT

Le 2022-01-24 Ã  03:05, Kenneth a Ã©critÂ :
>> Alain Martel <kua### [at] videotronca> wrote:
>>>
>>> Have you tried to replace that large sphere with a sky_sphere ? Or even
>>> a simple background statement if the pigment is solid ?
>>
>> Good suggestions. I tried both of those as a substitute for the large sphere--
>> and now there are NO bright rad-patch artifacts, in either case!
> 
> Well, I spoke too soon. The reason I didn't see any patches-- or any rad/media
> interaction at all-- was because my sky_sphere color and emission color were
> just too dim to produce them. In my most recent test code posted earlier, use
> the sky_sphere at rgb 0.1, and try emission 1*<0.1,1.0,0.1> to see the media
> cylinders, then emission 250*<0.1,1.0,0.1> to see the bright patches again.
> 
> So that media object being half-embedded seems to be the real problem... along
> with rad's 'media ON' switch.
> 
> But I find it strange that the sky_sphere produces its own particular radiosity
> brightness, versus the enclosing-sphere object imparting its *variable* rad
> brightness depending on its size.
> 
> A mystery for now.
> 
> 
> 
> 

New suggestion :
Scale your media container by <0.5, 1, 1> and move them up so that it is 
entirely above the surface. Even leave a tiny gap between it and the 
surface.

[Kenneth] Re: weird white stain with beta povray v3.8.0 (n... [1535 days 23 hours and 43 minutes ago]

Mon, 24 Jan 2022 08:10:00 GMT

> Alain Martel <kua### [at] videotronca> wrote:
> >
> > Have you tried to replace that large sphere with a sky_sphere ? Or even
> > a simple background statement if the pigment is solid ?
>
> Good suggestions. I tried both of those as a substitute for the large sphere--
> and now there are NO bright rad-patch artifacts, in either case!

Well, I spoke too soon. The reason I didn't see any patches-- or any rad/media
interaction at all-- was because my sky_sphere color and emission color were
just too dim to produce them. In my most recent test code posted earlier, use
the sky_sphere at rgb 0.1, and try emission 1*<0.1,1.0,0.1> to see the media
cylinders, then emission 250*<0.1,1.0,0.1> to see the bright patches again.

So that media object being half-embedded seems to be the real problem... along
with rad's 'media ON' switch.

But I find it strange that the sky_sphere produces its own particular radiosity
brightness, versus the enclosing-sphere object imparting its *variable* rad
brightness depending on its size.

A mystery for now.

[Kenneth] Re: weird white stain with beta povray v3.8.0 (n... [1536 days 14 hours and 8 minutes ago]

Sun, 23 Jan 2022 17:45:00 GMT

Alain Martel <kua### [at] videotronca> wrote:
> Le 2022-01-21 à 09:52, Kenneth a écrit :
> > // the large sky-sphere
> > sphere{0, 1
> > pigment{rgb .1}
> >      finish{ambient 0 diffuse 0 emission 1}
> >      scale 8000 // change to 50
> >     // hollow on // does not seem to be necessary-- the media objects and
> >                  // rad patches show up anyway
> >      no_image
> > }
>
> Have you tried to replace that large sphere with a sky_sphere ? Or even
> a simple background statement if the pigment is solid ?
> Some options :
>
> background{ rgb 0.1 }
>
> sky_sphere{
>  pigment{ rgb 0.1 }
>    }
>

Good suggestions. I tried both of those as a substitute for the large sphere--
and now there are NO bright rad-patch artifacts, in either case! So that sphere
(and its scale) seems to be causing a real/mysterious problem.

I tried one more simple test of that sphere: *creating* it with a radius of 8000
vs. *scaling* it to be so. But that didn't solve the problem.

Thanks Alain; this result *might* indicate a bug, regarding use of such an
actual sphere along with radiosity's 'media ON' switch.

[Alain Martel] Re: weird white stain with beta povray v3.8.0 (n... [1538 days 13 hours and 59 minutes ago]

Fri, 21 Jan 2022 17:54:13 GMT

Le 2022-01-21 Ã  09:52, Kenneth a Ã©critÂ :
> // the large sky-sphere
> sphere{0, 1
> pigment{rgb .1}
>      finish{ambient 0 diffuse 0 emission 1}
>      scale 8000 // change to 50
>     // hollow on // does not seem to be necessary-- the media objects and
>                  // rad patches show up anyway
>      no_image
> }

Have you tried to replace that large sphere with a sky_sphere ? Or even 
a simple background statement if the pigment is solid ?
Some options :

background{ rgb 0.1 }

sky_sphere{
	pigment{ rgb 0.1 }
   }

sky_sphere{
  pigment{plnar{
	[0 rgb 0.1]
	[1 rgb 0]
	}
    }

[Alain Martel] Re: weird white stain with beta povray v3.8.0 (n... [1538 days 14 hours and 5 minutes ago]

Fri, 21 Jan 2022 17:47:57 GMT

Le 2022-01-21 Ã  11:10, Thomas de Groot a Ã©critÂ :

> Is there a reason why the sky sphere has emission 1 ? It is a night 
> scene, so I would use emission 0 or emission0.01......
> 

Emission 1 and rgb value of 0.1.
If it was rgb 1, then, a small emission value would be required.

[Thomas de Groot] Re: weird white stain with beta povray v3.8.0 (n... [1538 days 15 hours and 43 minutes ago]

Fri, 21 Jan 2022 16:10:04 GMT

Op 21-1-2022 om 15:52 schreef Kenneth:
> Alain Martel <kua### [at] videotronca> wrote:
>>
>> WHY put that light so far away ? Why not use a much closer one...
> 
> I agree. And from more tests, I see that the sky-sphere's gigantic size has a
> great deal to do with those super-bright radiosity patches-- which surprised me.
> 
> I ran an animation test using my posted 'simplified' code, while changing that
> sphere scale from 8000 (which is not *too* large) down to 50. At 8000, the rad
> patches are very bright; at 50, they are MUCH less bright. Currently, I don't
> know why that should happen-- so I came up with yet another very simple test
> scene of my own(!), which I post here. No light_sources in it. It produces the
> same weird effect; change the sphere scale to see the difference. (I've also
> attached an image example; if you can't see it here, it will nevertheless appear
> in the 'image digest'.) Note that all of the scene's color values are purposely
> very low.
> 
> What this tells me is that any scene with a media object in it, surrounded by
> another larger rad-emitting object like that sphere, may show some unexpected
> rad/media interactions somewhere, depending on the *scale* of the larger object
> and the proximity of the media object to others. It's 'as if' the sphere is
> causing brighter radiosity lighting from its colors, the larger it gets. I have
> no other guess or explanation at this point. It makes me wonder if certain
> radiosity values need tweaking, depending on how large a typical rad-emitting
> 'sky' sphere is (for example.)
> 
> Of course, one of the major reasons for the bright rad patches in all of the
> posted scenes here is that the media objects are halfway-embedded in the
> 'ground'... so there's a proximity effect at work. But I wonder if subtle flaws
> might also be occurring in 'typical' media/radiosity scenes that would be
> similar to Warren's.
> 
> ----
> #version 3.8;
> #declare RAD_ON = 1;
> #declare P_start = 64 / image_width;
> #declare P_end_final = 4 / image_width;
> 
> global_settings{
> assumed_gamma 1.0
> 
> #if(RAD_ON)
> radiosity{ // mostly Warren's settings
> pretrace_start P_start
> pretrace_end   P_end_final
> error_bound 0.2
> minimum_reuse 0.15 // Ken
> maximum_reuse 0.151 // Ken
> nearest_count 9
> count 50
> recursion_limit 1
> always_sample off
> //gray_threshold 0.6
> brightness 1
> adc_bailout 0.01/2
> normal on
> media on // [If OFF, it ELIMINATES the super-bright radiosity patches.]
>           }
> #end
> }
> 
> camera {
>    perspective
>    location  <15, 70, -140>
>    look_at   <0, 0,  -10>
>    right     x*image_width/image_height
>    angle 40
> }
> 
> // the large sky-sphere
> sphere{0, 1
> pigment{rgb .1}
>      finish{ambient 0 diffuse 0 emission 1}
>      scale 8000 // change to 50
>     // hollow on // does not seem to be necessary-- the media objects and
>                  // rad patches show up anyway
>      no_image
> }
> 
> box{0,1 translate -.5 scale <100,.01,100>
> pigment{rgb <.3,.3,1>}
> }
> 
> merge{ // or union
> cylinder{-45*x,45*x,.3}
> cylinder{-45*x,45*x,.3 rotate 120*y}
> cylinder{-45*x,45*x,.3 rotate 240*y}
> hollow
> pigment{rgbt 1}
> interior{
>   media{
>    emission .003*<.1,1,.1>
>    method 3
>    intervals 1
>    samples 30
>    }
>   }
>   //translate ... *y
> }
> 

Is there a reason why the sky sphere has emission 1 ? It is a night 
scene, so I would use emission 0 or emission0.01......

-- 
Thomas

[Kenneth] Re: weird white stain with beta povray v3.8.0 (n... [1538 days 16 hours and 58 minutes ago]

Fri, 21 Jan 2022 14:55:00 GMT

Alain Martel <kua### [at] videotronca> wrote:
>
> WHY put that light so far away ? Why not use a much closer one...

I agree. And from more tests, I see that the sky-sphere's gigantic size has a
great deal to do with those super-bright radiosity patches-- which surprised me.

I ran an animation test using my posted 'simplified' code, while changing that
sphere scale from 8000 (which is not *too* large) down to 50. At 8000, the rad
patches are very bright; at 50, they are MUCH less bright. Currently, I don't
know why that should happen-- so I came up with yet another very simple test
scene of my own(!), which I post here. No light_sources in it. It produces the
same weird effect; change the sphere scale to see the difference. (I've also
attached an image example; if you can't see it here, it will nevertheless appear
in the 'image digest'.) Note that all of the scene's color values are purposely
very low.

What this tells me is that any scene with a media object in it, surrounded by
another larger rad-emitting object like that sphere, may show some unexpected
rad/media interactions somewhere, depending on the *scale* of the larger object
and the proximity of the media object to others. It's 'as if' the sphere is
causing brighter radiosity lighting from its colors, the larger it gets. I have
no other guess or explanation at this point. It makes me wonder if certain
radiosity values need tweaking, depending on how large a typical rad-emitting
'sky' sphere is (for example.)

Of course, one of the major reasons for the bright rad patches in all of the
posted scenes here is that the media objects are halfway-embedded in the
'ground'... so there's a proximity effect at work. But I wonder if subtle flaws
might also be occurring in 'typical' media/radiosity scenes that would be
similar to Warren's.

----
#version 3.8;
#declare RAD_ON = 1;
#declare P_start = 64 / image_width;
#declare P_end_final = 4 / image_width;

global_settings{
assumed_gamma 1.0

#if(RAD_ON)
radiosity{ // mostly Warren's settings
pretrace_start P_start
pretrace_end   P_end_final
error_bound 0.2
minimum_reuse 0.15 // Ken
maximum_reuse 0.151 // Ken
nearest_count 9
count 50
recursion_limit 1
always_sample off
//gray_threshold 0.6
brightness 1
adc_bailout 0.01/2
normal on
media on // [If OFF, it ELIMINATES the super-bright radiosity patches.]
         }
#end
}

camera {
  perspective
  location  <15, 70, -140>
  look_at   <0, 0,  -10>
  right     x*image_width/image_height
  angle 40
}

// the large sky-sphere
sphere{0, 1
pigment{rgb .1}
    finish{ambient 0 diffuse 0 emission 1}
    scale 8000 // change to 50
   // hollow on // does not seem to be necessary-- the media objects and
                // rad patches show up anyway
    no_image
}

box{0,1 translate -.5 scale <100,.01,100>
pigment{rgb <.3,.3,1>}
}

merge{ // or union
cylinder{-45*x,45*x,.3}
cylinder{-45*x,45*x,.3 rotate 120*y}
cylinder{-45*x,45*x,.3 rotate 240*y}
hollow
pigment{rgbt 1}
interior{
 media{
  emission .003*<.1,1,.1>
  method 3
  intervals 1
  samples 30
  }
 }
 //translate ... *y
}

[Kenneth] Re: weird white stain with beta povray v3.8.0 (n... [1538 days 17 hours and 48 minutes ago]

Fri, 21 Jan 2022 14:05:00 GMT

Thomas de Groot <tho### [at] degrootorg> wrote:
>
> ...but while renders were
> different, the (small) patches remained. I think that (3) might be an
> important issue here, but point (1) is really baffling.
>
> Good work, Kenneth!
>

Thanks. This has been my most intense 'detective work' in a long time-- and I'm
still thinking about all of it! That sphere problem really bugs me, but I think
I've discovered something interesting about it.

I LIKE a challenge (??) :-O

[Alain Martel] Re: weird white stain with beta povray v3.8.0 (n... [1539 days 14 hours and 12 minutes ago]

Thu, 20 Jan 2022 17:41:03 GMT

Le 2022-01-20 Ã  08:20, Kenneth a Ã©critÂ :
> // This light is NOT the cause of the bright radiosity patches.
> light_source{<-2,4,-3 >*1000000 color srgb <0.5,0.5,0.6>*0.75 }
> 

WHY put that light so far away ? Why not use a much closer one, but with 
the parallel attribute ?

When an object or light is situated at a distance in the million units 
range, you can get unexpected behaviour.

Alternative light that will get the exact same result :
light_source{<-2,4,-3 >*1000 color srgb <0.5,0.5,0.6>*0.75 parallel}

[Thomas de Groot] Re: weird white stain with beta povray v3.8.0 (n... [1539 days 15 hours and 44 minutes ago]

Thu, 20 Jan 2022 16:09:40 GMT

Op 20-1-2022 om 14:20 schreef Kenneth:
> I decided to go through all of the scene's include files-- turning off all of
> the light sources, correcting any out-of-gamut srgb colors to 1.0 max, and
> eliminating every object except the pentagram and the ground.
> 
> And I was still seeing the bright radiosity patches :-(
> 
> So I made my own VERY simplified scene-- posted below-- using just the bare
> necessities of Warren's code plus a few simplifications... and finally
> discovered what I think are the root causes of those bright patches. There are
> THREE reasons, as far as I can tell:
> 
> 1) The sky-sphere object is the primary cause. Comment-out that sphere, and the
> problem patches disappear.
> 
> 2) Radiosity's 'media ON' switch is also a primary problem; turn that OFF and
> the patches disappear.
> 
> 3) The media-pentagram is, I think, halfway embedded in the ground; that seems
> to definitely be adding to the problem, for some reason. Move it even slightly
> upward (like William P. mentioned), and the number of bright patches greatly
> decreases. Not completely, though, as 1) and 2) still produce some patches at
> random.
> 
> I don't know what is going on with rad's 'media on' switch; but the sky-sphere
> problem does not make any sense to me, as its colors are only 0.3 maximum...
> certainly not 'super bright'.
> 
> Maybe others here have some additional clues?
> 
[snip]

I have been very silent on this topic until now. A bit short on time.

I also came across your point (2) so thought it might (at least) be a 
radiosity/media problem. Then I thought that maybe the very thin value 
of the pentagram cylinders might play a role, so I made the cylinder 
radii much thicker while also setting intervals and samples to more 
default values and playing with sample values, but while renders where 
different, the (small) patches remained. I think that (3) might be an 
important issue here, but point (1) is really baffling.

Good work, Kenneth!

-- 
Thomas

[Kenneth] Re: weird white stain with beta povray v3.8.0 (n... [1539 days 18 hours and 28 minutes ago]

Thu, 20 Jan 2022 13:25:00 GMT

I decided to go through all of the scene's include files-- turning off all of
the light sources, correcting any out-of-gamut srgb colors to 1.0 max, and
eliminating every object except the pentagram and the ground.

And I was still seeing the bright radiosity patches :-(

So I made my own VERY simplified scene-- posted below-- using just the bare
necessities of Warren's code plus a few simplifications... and finally
discovered what I think are the root causes of those bright patches. There are
THREE reasons, as far as I can tell:

1) The sky-sphere object is the primary cause. Comment-out that sphere, and the
problem patches disappear.

2) Radiosity's 'media ON' switch is also a primary problem; turn that OFF and
the patches disappear.

3) The media-pentagram is, I think, halfway embedded in the ground; that seems
to definitely be adding to the problem, for some reason. Move it even slightly
upward (like William P. mentioned), and the number of bright patches greatly
decreases. Not completely, though, as 1) and 2) still produce some patches at
random.

I don't know what is going on with rad's 'media on' switch; but the sky-sphere
problem does not make any sense to me, as its colors are only 0.3 maximum...
certainly not 'super bright'.

Maybe others here have some additional clues?

---------
// 1/19/22-- reduced version of Warren's 'HallowHouseScene' code,
// by Ken Walker

#version 3.7;

#declare RAD_ON = true;
#declare P_start = 64 / image_width;
#declare P_end_final = 4 / image_width;
#declare GroundScale = < 80, 1, 160 >;

global_settings{
assumed_gamma 1.0

#if(RAD_ON)
radiosity{ // mostly Warren's settings
pretrace_start P_start
pretrace_end   P_end_final
error_bound 0.2
minimum_reuse 0.09 // Ken
maximum_reuse 0.091 // Ken
nearest_count 9
count 800
recursion_limit 1
always_sample off
gray_threshold 0.6
brightness 1
adc_bailout 0.01/2
normal on
media on // [If OFF, that ELIMINATES the super-bright radiosity patches.]
         }
#end
}

camera{
 location<-24,6,-24>
 look_at <6, 5, 0>
}


background{color srgb 0.05}

// This light is NOT the cause of the bright radiosity patches.
light_source{<-2,4,-3 >*1000000 color srgb <0.5,0.5,0.6>*0.75 }


#declare SkyPigment =
pigment{
    gradient y
    color_map{
        [0.0 color srgb 0]
        [0.75 color srgb <0.075, 0.075, 0.15>]
             }
}

// ---- THIS SPHERE IS THE MAIN CAUSE OF THE SUPER-WHITE RAD PATCHES (along
// with 'media on' in the rad block) ---

sphere{0, 1
    pigment{ SkyPigment }
    finish{ diffuse 0 emission <1,1,0.95>*0.3}
    scale 4000000
    hollow on
    no_shadow
    no_image
    no_reflection
}

#declare RedCol = color srgb <255,40,0 >/255;
#declare OrangeCol = color srgb <255,155,0 >/255;
#declare Clear = color srgbft <0,0,0,0,1>;
#declare FireMix =
density{
    wrinkles
    density_map{
        [0.4 RedCol ]
        [0.5 OrangeCol]
        [0.6 RedCol]
        }
     }

#declare PointsNumber = 5;
#declare PentagramRadius = 4;
#declare PentagramScaleFactor = 12/PentagramRadius/2;
#declare LineRadius = 0.01;

#declare PentagramCirclePoints = array[PointsNumber]
{<0,0,0>, <0,0,0>, <0,0,0>, <0,0,0>, <0,0,0> }

#for( It, 0, PointsNumber - 1 )
#declare PentagramCirclePoints[It] = <0,0,PentagramRadius>;
#declare PentagramCirclePoints[It] = vrotate(PentagramCirclePoints[It],
< 0,360/PointsNumber*It,0>);
#end

//Link pentagram points
#declare Pentagram =
union{
torus{ PentagramRadius, LineRadius sturm }
cylinder{ PentagramCirclePoints[0], PentagramCirclePoints[2], LineRadius }
cylinder{ PentagramCirclePoints[0], PentagramCirclePoints[3], LineRadius }
cylinder{ PentagramCirclePoints[1], PentagramCirclePoints[3], LineRadius }
cylinder{ PentagramCirclePoints[1], PentagramCirclePoints[4], LineRadius }
cylinder{ PentagramCirclePoints[2], PentagramCirclePoints[4], LineRadius }
     pigment{ color srgbft <0, 0, 0, 0, 1> }
     hollow
     no_shadow
     interior{
         media{
             emission
             color srgb 8 // This is not the major problem; change
                          // to 0.1 to see
             samples 30
             intervals 1
             density{bozo scale 0.1}
  }
 }
    //translate (.03 - .04*clock)*y // moving the pentagram away from the
    // GROUND reduces the number of super-bright radiosity splotches--
    // I think the pentagram is halfway embedded in the ground.
}


#declare brown1_srgb = color srgb <122, 72, 57> / 255;
#declare brown2_srgb = color srgb <126, 76, 62> / 255;
#declare brown3_srgb = color srgb <114, 62, 53> / 255;
#declare brown4_srgb = color srgb <102, 53, 43> / 255;
#declare brown5_srgb = color srgb <93 , 43, 38> / 255;

#macro T_5var_Wrinkles( multiplicateur, Col1, Col2, Col3, Col4, Col5)
texture{
      pigment{
       wrinkles
       color_map{
          [0.0 Col3*multiplicateur]
          [0.125 Col2*multiplicateur]
          [0.25 Col1*multiplicateur]
          [0.375 Col2*multiplicateur]
          [0.5 Col3*multiplicateur]
          [0.675 Col4*multiplicateur]
          [0.75 Col5*multiplicateur]
          [0.875 Col4*multiplicateur]
          [1.0 Col3*multiplicateur]
                     }
          scale 0.005
             }
           }
#end

#macro Pig_5colors_Wrinkles( multiplicateur, Col1, Col2, Col3, Col4, Col5)
      pigment{
           wrinkles
           color_map{
          [0.0 Col3*multiplicateur]
          [0.125 Col2*multiplicateur]
          [0.25 Col1*multiplicateur]
          [0.375 Col2*multiplicateur]
          [0.5 Col3*multiplicateur]
          [0.675 Col4*multiplicateur]
          [0.75 Col5*multiplicateur]
          [0.875 Col4*multiplicateur]
          [1.0 Col3*multiplicateur]
                    }
         scale 0.005
         }
#end

#declare T_brown2 = T_5var_Wrinkles(1.12  ,brown1_srgb, brown2_srgb,
brown3_srgb, brown4_srgb, brown5_srgb)
#declare GrayPig = Pig_5colors_Wrinkles(1.12, color srgb 0.6, color srgb 0.65,
color srgb 0.7, color srgb 0.75, color srgb 0.8)
#declare BrownPig = Pig_5colors_Wrinkles(1.12  ,brown1_srgb, brown2_srgb,
brown3_srgb, brown4_srgb, brown5_srgb)

#declare FinalGroundPig =
pigment{
    gradient y
    pigment_map{
         [0.0 GrayPig ]
         [0.1 BrownPig ]
               }
}

// simpler substitution for Warren's height_field ground
#declare WholeGround =
plane{y,0
texture{pigment{FinalGroundPig}}
}

WholeGround

#local Norm = < 0, 0, 0>;
#local StartPos = < -12, 100, -11>;
#local FinalPos = trace( WholeGround, StartPos, -y, Norm );
#if( Norm.x != 0 | Norm.y != 0 | Norm.z != 0 )
object{ Pentagram scale PentagramScaleFactor translate FinalPos }
#end

[Warren] Re: weird white stain with beta povray v3.8.0 (n... [1540 days 20 hours and 8 minutes ago]

Wed, 19 Jan 2022 11:45:00 GMT

> "Bald Eagle" <cre### [at] netscapenet> wrote:
> BTW, I never did a complete *finished* render of this code. Running it as-is
> with no changes, the render almost stalls about 2/3 of the way through-- and
> this on my 8 core/16 thread machine! I never did figure out the cause. The
> pumpkin lights? The candles? Something is causing my machine to churn through
> almost endless calculations. For my tests, I had to turn off at least the
> pumpkins.

Hello / Hi
The scene stalls at 2/3 percent because of the well isosurface (it is a cylinder
parametric function with an add of customized crackle pattern. In addition, I
deleted the heavy-weight tree mesh in the archive posted in 'binaries' forum
section. I you want the complete scene or just take a look at the final image,
you should take a look at my web site:
"https://www.ant01.fr/index.php/graphismes/stills-natures-mortes-avec-povray".
But I didn't update the archive you can download from there.
Since the first posts of Kenneth and William F. Pokorny , I tested the changes
they suggested (replace srgb with rgb in some cases mainly) but the renders were
not exempt of bugs, unfortunately, excepted for some renders with povray
v3.7.0.8.

I think I pointed out a bug, but I've no idea of where it comes from.

[Kenneth] Re: weird white stain with beta povray v3.8.0 (n... [1541 days 17 hours and 18 minutes ago]

Tue, 18 Jan 2022 14:35:00 GMT

"Bald Eagle" <cre### [at] netscapenet> wrote:
>
> Good detective work!  :)
>
Thanks, Cousin Walker! I've been experimenting a LOT with rad over the past 6
months, kind of 'deconstructing' its many variables and how they interact. Test
after test after...

I have not really taken a deep look at Warren's code; there's a lot of
'busy-ness' in the many include files to chew through.

I think the 'heart' shape is due to just a particular juxtaposition of objects
and lights, as 'processed' by the rad settings. They can take on some pretty
weird shapes sometimes, depending on scene geometry.

BTW, I never did a complete *finished* render of this code. Running it as-is
with no changes, the render almost stalls about 2/3 of the way through-- and
this on my 8 core/16 thread machine! I never did figure out the cause. The
pumpkin lights? The candles? Something is causing my machine to churn through
almost endless calculations. For my tests, I had to turn off at least the
pumpkins.

[Bald Eagle] Re: weird white stain with beta povray v3.8.0 (n... [1541 days 19 hours and 53 minutes ago]

Tue, 18 Jan 2022 12:00:00 GMT

Good detective work!  :)

Are they "hearts" or --- nephroids?

Is there some sort of "reflection" effect, esp with the circle, that would give
rise to this?

Can the symbol be raised / lowered, scaled, lines widened/narrowed to show an
effect on the artifacts?

Does the same artifact show up with a square or an ellipse...?

[Kenneth] Re: weird white stain with beta povray v3.8.0 (n... [1541 days 22 hours and 3 minutes ago]

Tue, 18 Jan 2022 09:50:00 GMT

"Kenneth" <kdw### [at] gmailcom> wrote:

>
> That's because of the scene's radiosity settings...
> My image examples are from an animation test. I changed minimum_reuse to 0.09...
> and I now see LOTS of such artifacts...

Forgot to mention that I changed the scene's rad 'count' from 800 to 80 for
these test renders, just to make quicker tests.

[Kenneth] Re: weird white stain with beta povray v3.8.0 (n... [1542 days 1 hour and 53 minutes ago]

Tue, 18 Jan 2022 06:00:00 GMT

"Kenneth" <kdw### [at] gmailcom> wrote:
>
> Strange as it seems, if I simply eliminate your  +bs8  on the command line, I
> never see the artifact at 1280X960...well, not in 15 render attempts,
> anyway. I have no idea why that would matter.

Forget that; it's probably of no real consequence...because I think I've solved
at least part of the problem (the large heart-shaped artifact).
>
> ...I am seeing inconsistent results from
> render to render, even at the problematic 1280X960 render size. Sometimes the
> heart-shaped stain is there, sometimes not.
>

That's because of the scene's radiosity settings. I noticed that there was no
maximum_reuse value given, which means that it defaults to 0.2-- which is quite
large and can result in large splotchy artifacts-- the heart shape, for example.

My image examples are from an animation test. I changed minimum_reuse to 0.09...
and I now see LOTS of such artifacts. The reason why my earlier tests seemed
inconsistent is because of the random nature of such 'splotches' from render to
render, given the values used; and it just happened that the scene's rad
settings were sometimes producing only ONE *major* artifact...or none. The sizes
of such splotches vary according to the 'spread' between the minimum_reuse and
maximum_reuse values.

I also did a test with these rad values:
minimum_reuse 0.03
maximum_reuse 0.031

This produces even more splotches, all of the same (smaller) size.

It's obvious that these super-bright artifacts are showing up along the 'lines'
of the pentagram. The remainder of the problem must be that some of its srgb
colors are 'greater than 1.0' as was mentioned earlier, and are interacting
weirdly with radiosity; or that the scene's lights and fade_powers are somehow
too bright.

Apparently, radiosity is picking up a super-bright color from *somewhere*, and
using it in its calculations.

[Kenneth] Re: weird white stain with beta povray v3.8.0 (n... [1542 days 5 hours and 3 minutes ago]

Tue, 18 Jan 2022 02:50:00 GMT

[Running v3.8.0 beta 1 in Windows 10]

This is a very tricky problem to diagnose; I am seeing inconsistent results from
render to render, even at the problematic 1280X960 render size. Sometimes the
heart-shaped stain is there, sometimes not.

[Warren wrote:]
// There are other things to consider:
// First off, set the boolean 'PlaceWell' (line 19 of main pov file) to false,
// to get a faster rendering, the heart shape artifact being always there.

Even with that change, I still get inconsistent results.

Interestingly, I commented-out this code block in your main file to see what
would happen; it's your lamp-placement block, I think...

#for( It, 0, PositionsNum - 1, 1 )
 ...
 #end
#end

..... but I still see the (inconsistent) artifact.

That still leaves your pumpkins and candles in the scene-- with *their* lights.
Maybe those include files would be a place to look? Perhaps you could try
plugging in some crazy values in certain places, to try and *force* the artifact
to always show up and to look even worse.

Strange as it seems, if I simply eliminate your  +bs8  on the command line, I
never see the artifact at 1280X960...well, not in 15 render attempts, anyway. I
have no idea why that would matter.

[Cousin Ricky] Re: weird white stain with beta povray v3.8.0 (n... [1543 days 3 hours and 7 minutes ago]

Mon, 17 Jan 2022 04:46:33 GMT

On 2022-01-16 14:46 (-4), William F Pokorny wrote:
> 
> In many places you are using the srgb keyword with channel values
> outside the 0-1 range. My povr branch doesn't allow this because any
> 'srgb calculation' outside the 0-1 range is wacky. See post elsewhere
> for details. If you need values outside 0-1, use rgb to exactly specify
> what you want for internal linear values.

For what it's worth, these are the out-of-domain sRGB calls, evaluated
under assumed_gamma 1:

customTextures.inc:
  srgb < 1, 0.9, 0.65> * 1.3 = rgb <1.8233, 1.4313, 0.6829>
  srgb < 1, 0.9, 0.65> * 1.15 = rgb <1.3758, 1.0815, 0.5186>
pentagramObject.inc:
  srgb 8 = rgb <131.4473, 131.4473, 131.4473>
  srgb 3 = rgb <12.8298, 12.8298, 12.8298>
pumpkin.inc:
  srgb < 1.5, 1, 0> = rgb <2.5372, 1.0000, 0.0000>

The post elsewhere with details:
https://news.povray.org/povray.general/thread/%3Cweb.60649d9bb9b7dccdd98418916e066e29%40news.povray.org%3E/

[William F Pokorny] Re: weird white stain with beta povray v3.8.0 (n... [1543 days 13 hours and 6 minutes ago]

Sun, 16 Jan 2022 18:46:53 GMT

On 1/14/22 6:06 AM, Warren wrote:
> Cousin Ricky <ric### [at] yahoocom> wrote:
>> On 2022-01-13 10:06 (-4), Warren wrote:
>>> Hi,
>>> I post a message here, because I get a weird render with povray 3.8.0 beta 1 of
>>> a scene with the following resolution : 1280x960 (see attached image with this
>>> message) , you can see a white stain that has the shape of a heart near the
>>> pentagram. When I render this same scene with stable v3.7.0 the white stain
>>> doesn't appear. And even weird, when I render this scene with povray "3.8.0
>>> beta1" but with the resolution of 640x480, I don't get this white stain in the
>>> final image.
>>
>> What I've found so far:
>>   - The artifact varies with the image size.  A 960x720 render leaves an
>>     oblong stain on the upper left vertex.
>>   - The artifact isn't completely absent with 640x480.  At 640x480, tiny
>>     white spots appear along the veins of the pentagram, but they are
>>     absent in a 3.7 render.  I presume that this means you did not put
>>     them there deliberately, and that they are related to the big heart-
>>     shaped stain.
>>   - 3.8 beta 2 does not solve the problem.
> 
> There are other things to consider:
> - First off, set the boolean 'PlaceWell' (line 19 of main pov file) to false, to
> get a faster rendering, the heart shape artifact being always there.
> - Changing the minimum_reuse value from '0.015' to '0.01' make the 'heart shaped
> artifact' to disappear, but the little white stains you talked about are there,
> it seems.
> 

The following might, or might not, be of help to you with official 
versions of POV-Ray.

I took a quick look at at this bug with my current povr branch and found 
along with some recent bounding code changes it got me to a more stable 
fail for a bug I've been chasing for years. Details posted in the v4.0 
group.

My povr branch is now considerably different than official POV-Ray 
offerings, but after translating the pentagram up by 2x the thread 
radius(a) I got away from the 'white regions.' I never saw the heart 
shaped one - no idea why not in povr. Image attached.

(a) - Media needs clean start and stop intervals. Near coincident 
shape/surfaces can cause confusion and leave intervals open - and with 
emission media this results in extremely bright regions.

Where you had media I moved from min, max samples and interval 
specifications to just 'samples 10'.

In many places you are using the srgb keyword with channel values 
outside the 0-1 range. My povr branch doesn't allow this because any 
'srgb calculation' outside the 0-1 range is wacky. See post elsewhere 
for details. If you need values outside 0-1, use rgb to exactly specify 
what you want for internal linear values.

includes/outdoorsLamp.inc -> debug statement line 218 uses LampZpos and 
it should be LampZPos.

Bill P.

[Warren] Re: weird white stain with beta povray v3.8.0 (n... [1545 days 20 hours and 43 minutes ago]

Fri, 14 Jan 2022 11:10:00 GMT

Cousin Ricky <ric### [at] yahoocom> wrote:
> On 2022-01-13 10:06 (-4), Warren wrote:
> > Hi,
> > I post a message here, because I get a weird render with povray 3.8.0 beta 1 of
> > a scene with the following resolution : 1280x960 (see attached image with this
> > message) , you can see a white stain that has the shape of a heart near the
> > pentagram. When I render this same scene with stable v3.7.0 the white stain
> > doesn't appear. And even weird, when I render this scene with povray "3.8.0
> > beta1" but with the resolution of 640x480, I don't get this white stain in the
> > final image.
>
> What I've found so far:
>  - The artifact varies with the image size.  A 960x720 render leaves an
>    oblong stain on the upper left vertex.
>  - The artifact isn't completely absent with 640x480.  At 640x480, tiny
>    white spots appear along the veins of the pentagram, but they are
>    absent in a 3.7 render.  I presume that this means you did not put
>    them there deliberately, and that they are related to the big heart-
>    shaped stain.
>  - 3.8 beta 2 does not solve the problem.

There are other things to consider:
- First off, set the boolean 'PlaceWell' (line 19 of main pov file) to false, to
get a faster rendering, the heart shape artifact being always there.
- Changing the minimum_reuse value from '0.015' to '0.01' make the 'heart shaped
artifact' to disappear, but the little white stains you talked about are there,
it seems.

[Cousin Ricky] Re: weird white stain with beta povray v3.8.0 (n... [1546 days 6 hours and 16 minutes ago]

Fri, 14 Jan 2022 01:37:05 GMT

On 2022-01-13 10:06 (-4), Warren wrote:
> Hi,
> I post a message here, because I get a weird render with povray 3.8.0 beta 1 of
> a scene with the following resolution : 1280x960 (see attached image with this
> message) , you can see a white stain that has the shape of a heart near the
> pentagram. When I render this same scene with stable v3.7.0 the white stain
> doesn't appear. And even weird, when I render this scene with povray "3.8.0
> beta1" but with the resolution of 640x480, I don't get this white stain in the
> final image.

What I've found so far:
 - The artifact varies with the image size.  A 960x720 render leaves an
   oblong stain on the upper left vertex.
 - The artifact isn't completely absent with 640x480.  At 640x480, tiny
   white spots appear along the veins of the pentagram, but they are
   absent in a 3.7 render.  I presume that this means you did not put
   them there deliberately, and that they are related to the big heart-
   shaped stain.
 - 3.8 beta 2 does not solve the problem.

[Alain Martel] Re: weird white stain with beta povray v3.8.0 (n... [1546 days 15 hours and 39 minutes ago]

Thu, 13 Jan 2022 16:14:26 GMT

Le 2022-01-13 Ã  09:06, Warren a Ã©critÂ :
> Hi,
> I post a message here, because I get a weird render with povray 3.8.0 beta 1 of
> a scene with the following resolution : 1280x960 (see attached image with this
> message) , you can see a white stain that has the shape of a heart near the
> pentagram. When I render this same scene with stable v3.7.0 the white stain
> doesn't appear. And even weird, when I render this scene with povray "3.8.0
> beta1" but with the resolution of 640x480, I don't get this white stain in the
> final image. Usually I'm cautious before I claim this is a bug and that the
> error is not between the keyboard and the chair, but there is something wrong
> there.
> Regards,
> Antoine.

Yes, there is something wrong. Now, a few questions :
Is there a resolution where it just start to show up ?
Did you try at 800x600, 1024x768, 1600x1200 ?
Did you try at some different aspect ratio, like 800x800 or 1600x800 ?

You should post the scene file to povray.binaries.scene-files
Be sure to include any custom .inc files and image used. If there are 
more than a single file used, zip them together.
That way, we can try to reproduce your issue.

[Warren] weird white stain with beta povray v3.8.0 (not w... [1546 days 17 hours and 43 minutes ago]

Thu, 13 Jan 2022 14:10:00 GMT

Hi,
I post a message here, because I get a weird render with povray 3.8.0 beta 1 of
a scene with the following resolution : 1280x960 (see attached image with this
message) , you can see a white stain that has the shape of a heart near the
pentagram. When I render this same scene with stable v3.7.0 the white stain
doesn't appear. And even weird, when I render this scene with povray "3.8.0
beta1" but with the resolution of 640x480, I don't get this white stain in the
final image. Usually I'm cautious before I claim this is a bug and that the
error is not between the keyboard and the chair, but there is something wrong
there.
Regards,
Antoine.

[Mr] Re: Visual Studio 2017 or 2019 [1563 days 22 hours and 53 minutes ago]

Mon, 27 Dec 2021 09:00:00 GMT

"Mr" <nomail@nomail> wrote:
> "Mr" <nomail@nomail> wrote:
> > I also tried adding the following as a *.reg file, but the result doesn't
> > change:
> [...]
>
> I was very surprised to find out here that I could move this a step further by
> just adding a \help directory at the same lavel as my compiled \bin64 dir,
> couldn't this be created by default ?
>
> I had found the tip here,
>
https://wiki.povray.org/content/Documentation:Windows_Section_3#Non-Standard_Installations

Sorry, things were actually simpler than I thought, since every such
prerequisite folder already existed in the "distribution" folder, I just had to
run the built exe once with /INSTALL command line parameter followed by
distribution folder. This adds every needed registry key, and the render then
worked as smoothly as one could expect!

[Mr] Re: Visual Studio 2017 or 2019 [1568 days 16 hours and 48 minutes ago]

Wed, 22 Dec 2021 15:05:00 GMT

"Mr" <nomail@nomail> wrote:
> I also tried adding the following as a *.reg file, but the result doesn't
> change:
[...]

I was very surprised to find out here that I could move this a step further by
just adding a \help directory at the same lavel as my compiled \bin64 dir,
couldn't this be created by default ?

I had found the tip here,
https://wiki.povray.org/content/Documentation:Windows_Section_3#Non-Standard_Installations

[Mr] Re: Visual Studio 2017 or 2019 [1570 days 17 hours and 8 minutes ago]

Mon, 20 Dec 2021 14:45:00 GMT

"Mr" <nomail@nomail> wrote:
> "jr" <cre### [at] gmailcom> wrote:
> > hi,
> >
> > "Mr" <nomail@nomail> wrote:
> > > ...
> > > Thus my question now is... Is there any Windows geared alternative procedure
> > > where one can build pov from some readme, AND use it, even if it has never been
> > > installed?
> >
> > @Alessio Sangalli (as an alternative to running a VM):
> >
> > not certain about POV-Ray working without "installing", it does need its .inc
> > etc files.  to answer your question - yes, I found Cygwin works well under MS
> > Windows, and since that gives you a fairly complete UNIX-like environment, you
> > can do a regular install from source.
> > <https://www.cygwin.com/>
> >
> >
> > regards, jr.
>
> My final goal is to have pov sources delivered along inside another (licence
> compatible) program and have both build at the same time on Windows or Linux
> without adding so many prerequestites. Using Cygwin is not an option for this,
> But I don't mind how long or convoluted the launching command could get... So on
> windows, after compiling in D:\pov\povray I try from command line:
>
> D:\pov\povray>.\windows\vs2015\bin64\pvengine64-avx
> +I.\distribution\scenes\advanced\grenadine.pov +L.\distribution\include
> +L.\distribution\scenes\advanced\grenadine /INSTALL
> D:\pov\povray\windows\vs2015\bin64 D:\pov\povray\distribution\include
>
> And still get the same message, so the registry key seem to be really the
> necessary bits are they or is it cmedit ?

I also tried adding the following as a *.reg file, but the result doesn't
change:

Windows Registry Editor Version 5.00
[HKEY_CLASSES_ROOT\.pov]
"(Default)"="POV-Ray.Scene"
"PerceivedType"="text"

[HKEY_CLASSES_ROOT\.Scene]
"(Default)"="POV-Ray scene source file"

[HKEY_CLASSES_ROOT\.Scene\DefaultIcon]
"(Default)"="D:\pov\povray\distribution\platform-specific\windows\Icons\POV-Ray.Scene-XP.ico"

[HKEY_CLASSES_ROOT\POV-Ray.Scene\shell\Render]
"(Default)"="Render with POV-Ray 3.8"

[HKEY_CLASSES_ROOT\POV-Ray.Scene\shell\Render\command]
"(Default)"="D:\pov\povray\windows\vs2015\bin64\pvengine64-avx.exe" /render "%1"

[Mr] Re: Visual Studio 2017 or 2019 [1570 days 23 hours and 3 minutes ago]

Mon, 20 Dec 2021 08:50:00 GMT

"jr" <cre### [at] gmailcom> wrote:
> hi,
>
> "Mr" <nomail@nomail> wrote:
> > ...
> > Thus my question now is... Is there any Windows geared alternative procedure
> > where one can build pov from some readme, AND use it, even if it has never been
> > installed?
>
> @Alessio Sangalli (as an alternative to running a VM):
>
> not certain about POV-Ray working without "installing", it does need its .inc
> etc files.  to answer your question - yes, I found Cygwin works well under MS
> Windows, and since that gives you a fairly complete UNIX-like environment, you
> can do a regular install from source.
> <https://www.cygwin.com/>
>
>
> regards, jr.

My final goal is to have pov sources delivered along inside another (licence
compatible) program and have both build at the same time on Windows or Linux
without adding so many prerequestites. Using Cygwin is not an option for this,
But I don't mind how long or convoluted the launching command could get... So on
windows, after compiling in D:\pov\povray I try from command line:

D:\pov\povray>.\windows\vs2015\bin64\pvengine64-avx
+I.\distribution\scenes\advanced\grenadine.pov +L.\distribution\include
+L.\distribution\scenes\advanced\grenadine /INSTALL
D:\pov\povray\windows\vs2015\bin64 D:\pov\povray\distribution\include

And still get the same message, so the registry key seem to be really the
necessary bits are they or is it cmedit ?

[jr] Re: Visual Studio 2017 or 2019 [1573 days 16 hours and 33 minutes ago]

Fri, 17 Dec 2021 15:20:00 GMT

hi,

"Mr" <nomail@nomail> wrote:
> ...
> Thus my question now is... Is there any Windows geared alternative procedure
> where one can build pov from some readme, AND use it, even if it has never been
> installed?

@Alessio Sangalli (as an alternative to running a VM):

not certain about POV-Ray working without "installing", it does need its .inc
etc files.  to answer your question - yes, I found Cygwin works well under MS
Windows, and since that gives you a fairly complete UNIX-like environment, you
can do a regular install from source.
<https://www.cygwin.com/>

regards, jr.

[Mr] Re: Visual Studio 2017 or 2019 [1576 days 16 hours and 18 minutes ago]

Tue, 14 Dec 2021 15:35:00 GMT

clipka <ano### [at] anonymousorg> wrote:
> Am 20.06.2021 um 12:29 schrieb Mr:
>
> > I'll close and re-popen the project and try harder to spot any information at
> > the step when I pick platform toolset v142.
>
> Could you have VS 2019 auto-convert the projects to toolset v142, save
> the resulting projects, and post some of them over on
> `povray.beta-test.binaries`?
>
> `povray.vcxproj` and `povbase.vcxproj` should be helpful. Maybe also
> `povray.sln`.
>
> > Could it be that some libraries had relative paths and then the Github system
> > not having the same reference point for relative paths ?
>
> No, I don't think that's it. My money is on some project setting that
> needs to be changed along with the toolset, that we don't account for.

Hi, since then, I tried compiling for some machine that had never been exposed
to POV and got the same error message ("Cannot find Home entry in registry"):
This is to be expected when I did not do the pre requisite step of installing
any version from any previous official installer first.

However this was on purpose, as I had hoped to ultimately operate the build and
missing details of its installation process from some other package build. So
having to install a pre built package prior to build the provided sources would
not be a possible hack.

Thus my question now is... Is there any Windows geared alternative procedure
where one can build pov from some readme, AND use it, even if it has never been
installed? Is it likely that the unix prebuild.sh / make install steps are not
yet mimicked under Windows but might be with the help of the git sh tool ?
(sorry if this last point makes no sense I'm trying guesses in the dark.)

[jr] Re: v3.8 beta 2 command line option parsing [1589 days and 28 minutes ago]

Thu, 2 Dec 2021 07:25:00 GMT

hi,

"Chris R" <car### [at] comcastnet> wrote:
> ...
> On the command line (windows) I use: Declare=test_case=1.1 ...

recent discussion:
<https://news.povray.org/povray.bugreports/thread/%3Cweb.60fea0b2e0f64d045e0fed26cde94f1%40news.povray.org%3E/>


regards, jr.

[Chris R] v3.8 beta 2 command line option parsing [1589 days 16 hours and 53 minutes ago]

Wed, 1 Dec 2021 15:00:00 GMT

I'm a little slow on the uptake picking up beta 2, so I just noticed this issue.

There is a note in the changelog for this release about floating point precision
parsing command line options being reverted back to v3.6 semantics.  I note that
this is causing things to break in my v3.7 and higher scenes (the only version I
have used recently).

The code in question:

#switch(test_case)
#case(1.1)
   #declare camera_location=<0, 0, 0>;
....
#break
#end

On the command line (windows) I use: Declare=test_case=1.1 and the case is not
picked up in my switch.  Printing the value of test_case out with str() and a
precision of 7 or higher, I see trailing non-zero values that are causing this.

I have a work-around to truncate the value to 3 decimal places, as I never use
more than that to designate a test case number, but thought I'd pass this along
as it can be difficult to debug in a scene.

-- Chris Rath

[William F Pokorny] Re: v3.8 beta 2 seg fault. 32 bit raspbian os on... [1646 days 11 hours and 24 minutes ago]

Tue, 5 Oct 2021 20:28:49 GMT

On 8/27/21 5:04 AM, William F Pokorny wrote:
> On 8/26/21 3:19 PM, William F Pokorny wrote:
>> The code there has a hard LL literal assuming long long int is 64 bits.
> 
> Blast it, I meant to write:
> 
> "The code there has a hard LL literal assuming POV_LONG is 64 bits."
> 
> With C++11 'long long int' and 'unsigned long long int' are always at 
> least 64 bits.
> 

In working on documentation for my povr branch changes I noticed the 
issue here is essentially github issue #384.

"vfesession.cpp:342 overflow in conversion from long long int to
long int on m68k #384"

https://github.com/POV-Ray/povray/issues/384

I've for a month or so in those handful of configuration files simply 
had the lines:

// C++11 required. We can set following macros directly.
#define POV_LONG  std::int_least64_t
#define POV_ULONG std::uint_least64_t

over the conditional logic which was there.

This looks to be what clipka recommended in responding to #384.

Bill P.

[William F Pokorny] Re: v3.8 beta 2 seg fault. 32 bit raspbian os on... [1685 days 22 hours and 49 minutes ago]

Fri, 27 Aug 2021 09:04:32 GMT

On 8/26/21 3:19 PM, William F Pokorny wrote:
> The code there has a hard LL literal assuming long long int is 64 bits.

Blast it, I meant to write:

"The code there has a hard LL literal assuming POV_LONG is 64 bits."


With C++11 'long long int' and 'unsigned long long int' are always at 
least 64 bits.

Bill P.

[William F Pokorny] v3.8 beta 2 seg fault. 32 bit raspbian os on 64 ... [1686 days 12 hours and 33 minutes ago]

Thu, 26 Aug 2021 19:19:44 GMT

While I was doing a long overdue disk back up for my main machine, I 
decided to try a compile of the beta 2 release on my raspberry pi 4 4GB- 
which happened to be running the more common 32bit rasbian os(1).

The configure and compile went mostly OK, except I had trouble getting a 
tiff development library installed - for reasons not related to POV-Ray 
and which I've not sorted. There are a lot of extra 'notes' from the 
compiler over the usual warnings which can probably be turned off, but I 
didn't chase these.

We get an almost immediate segfault trying to run even stuff like povray 
--help which comes from vfe/vfesession.cpp. I expect others would follow 
should one get to where we start to render anything.

---
We have four unix flavor configuration files in:

unix/povconfig/syspovconfig_bsd.h
unix/povconfig/syspovconfig_gnu.h
unix/povconfig/syspovconfig_posix.h

and

unix/povconfig/syspovconfig_osx.h

All have nearly identical set up code that I've changed - in povr - to:

//-----------
#if (0)  // Use simpler c++11 method TODO remove 0 if no issues
#if defined(_POSIX_V6_LPBIG_OFFBIG) || defined(_POSIX_V6_LP64_OFF64)
     // Below NOT true 32 raspbian os on 64bit raspberry pi 4 hardware.
     // long is at least 64 bits.
     #define POV_LONG long
#elif defined(_POSIX_V6_ILP32_OFFBIG) || defined(_POSIX_V6_ILP32_OFF32)
     // long is 32 bits.
     #define POV_LONG long long
#else
     // Unable to detect long size at compile-time, assuming less than 
64 bits.
     #define POV_LONG long long
#endif

#define POV_ULONG unsigned POV_LONG

#else   //----------------------------

// C++11 required so we can just set macros directly.
#define POV_LONG  std::int_least64_t
#define POV_ULONG std::uint_least64_t
#endif  // Use simpler c++11 method
//-------------

(1) - There is now a 64bit raspbian os mostly aimed at the newer 8GB 
models and there has been for quite a while 64bit Ubuntu versions for 
the raspberry pi 4. Not everyone with a raspberry pi will hit this 
issue, but many with a raspberry pi 4 will.

The issue can be guessed at from the code comments; It turns out that 
first test can be true and the 'long int' not be at 64 bits as the code 
comment states. The C++11 standard guarantees 'long long int' is at 
least 64bits, but 'long int' can be only 32 bits and this we get with 
the raspbian 32 bit os.

Aside: We have code since the move to c++11 taking POV_LONG and 
POV_ULONG to always be 64 bits - the bit in vfesession.cpp is just the 
first tripped upon where this not true. The code there has a hard LL 
literal assuming long long int is 64 bits.

Bill P.

[ingo] return dict from macro [1690 days 14 hours and 15 minutes ago]

Sun, 22 Aug 2021 17:37:47 GMT

http://news.povray.org/povray.general/thread/%3CXnsAD0BC42BCF8Aseed7%
40news.povray.org%3E/

The bug I reported here still exist in the beta.

Ingo

-- 
https://ingoogni.nl

[jr] Re: POV-Ray v3.8.0-beta.2 [1699 days 15 hours and 48 minutes ago]

Fri, 13 Aug 2021 16:05:00 GMT

hi,

clipka <ano### [at] anonymousorg> wrote:
> Then that's good, because no such split is actually intended to be implied.

</phew>  cheers.


regards, jr.

[clipka] Re: POV-Ray v3.8.0-beta.2 [1699 days 17 hours and 36 minutes ago]

Fri, 13 Aug 2021 14:17:16 GMT

Am 13.08.2021 um 15:30 schrieb jr:
> hi,
> 
> clipka <ano### [at] anonymousorg> wrote:
>> Am 13.08.2021 um 14:21 schrieb jr:
>>
>>> puzzled what the point of adding '-src'
>>> to archive and directory would be, are there any binaries for not-Windows?
>>
>> Pretty much just conveying the notion that, in contrast to the `povwin-`
>> stuff, this one is not a binary.
> 
> since, in another thread, you professed an interest in *NIX-ness (just
> "hampered" because locked in to one tool set ;-)), know then that splitting a
> s/ware in to separate "-dev", "-doc", "-src", whatnot, is a Linux thing, not
> *NIX.  and even then mostly the distributions which target the "Redmond Boy with
> unruly streak".

Then that's good, because no such split is actually intended to be implied.

Just the plain old fact that you need to compile the whole shebang 
before it will do anything useful.

User documentation and sample scenes are included (or should be, at any 
rate), for instance.

As for the "Redmond Boy with unruly streak", I wouldn't even know what 
you're referring to.

[jr] Re: POV-Ray v3.8.0-beta.2 [1699 days 18 hours and 18 minutes ago]

Fri, 13 Aug 2021 13:35:00 GMT

hi,

clipka <ano### [at] anonymousorg> wrote:
> Am 13.08.2021 um 14:21 schrieb jr:
>
> > puzzled what the point of adding '-src'
> > to archive and directory would be, are there any binaries for not-Windows?
>
> Pretty much just conveying the notion that, in contrast to the `povwin-`
> stuff, this one is not a binary.

since, in another thread, you professed an interest in *NIX-ness (just
"hampered" because locked in to one tool set ;-)), know then that splitting a
s/ware in to separate "-dev", "-doc", "-src", whatnot, is a Linux thing, not
*NIX.  and even then mostly the distributions which target the "Redmond Boy with
unruly streak".

> > (what is different? :-))
> Well, I _could_ point you to the `changelist.txt` in the root directory...

I did look at 'ChangeLog', which referred me to 'revisions.txt'.  will have a
look at 'changelist.txt' later.

> Really I just thought after 4 weeks it might be time for another beta,
> even though the changes weren't very numerous. Also, it had that
> glorious `datetime` "fix" in it that I wanted to get out for testing,
> and that turns out to be doing absolutely zilch because there was
> nothing to fix in the first place...

tja.  well, anyway, "onwards and upwards", beta.3.

regards, jr.

[clipka] Re: POV-Ray v3.8.0-beta.2 [1699 days 18 hours and 53 minutes ago]

Fri, 13 Aug 2021 13:00:17 GMT

Am 13.08.2021 um 14:21 schrieb jr:

> puzzled what the point of adding '-src'
> to archive and directory would be, are there any binaries for not-Windows?

Pretty much just conveying the notion that, in contrast to the `povwin-` 
stuff, this one is not a binary.


> (what is different? :-))

Well, I _could_ point you to the `changelist.txt` in the root directory...

Really I just thought after 4 weeks it might be time for another beta, 
even though the changes weren't very numerous. Also, it had that 
glorious `datetime` "fix" in it that I wanted to get out for testing, 
and that turns out to be doing absolutely zilch because there was 
nothing to fix in the first place...

[jr] Re: POV-Ray v3.8.0-beta.2 [1699 days 19 hours and 28 minutes ago]

Fri, 13 Aug 2021 12:25:00 GMT

hi,

clipka <ano### [at] anonymousorg> wrote:
> Let us know of any gripes you may have with that version.
>
> Also, feel free to remind us of any gripes you had with the previous
> beta that haven't been addressed satisfactorily yet (I'm quite sure
> there are some).

thanks, builds with only one (same 'trace.cpp') warning.  'datetime(now)' as
before, the '+rtr +kla' test scene still gives me an empty preview window.  the
'declare=X=Y' still mangles the value. puzzled what the point of adding '-src'
to archive and directory would be, are there any binaries for not-Windows?

(what is different? :-))

> Pro Tip: A GitHub issue report
> (https://github.com/POV-Ray/povray/issues) is the best way to make sure
> we're keeping proper tabs on whatever your gripe may be.

well, this is an amateur reporting.  ;-)

regards, jr.

[Cousin Ricky] Re: Call to Arms: Datetime [1700 days 6 hours and 5 minutes ago]

Fri, 13 Aug 2021 01:48:10 GMT

On 2021-08-11 7:08 AM (-4), clipka wrote:
> 
> I need your help to test the different variants of the code (especially
> (1) and (2)) on your machines, and let me know:
> 
> - What behavior you are observing for code variant (1);
> - what behavior you are observing for code variant (2);
> - what operating system you are using; and
> - what version of boost POV-Ray has been compiled with.

These are my results at 8:59 p.m. local time:

Version                   datetime(now)         Time Zone  Boost
-------                   -------------         ---------  -----
3.7.0                (1)  2021-08-13 00:59:36Z     GMT     1.53
3.8.0-alpha.9893777  (1)  2021-08-13 00:59:36Z     GMT     1.66
3.8.0-alpha.9945627  (1)  2021-08-13 00:59:37Z     GMT     1.66
3.8.0-alpha.10013324 (1)  2021-08-13 00:59:38Z     GMT     1.66
3.8.0-alpha.10064268 (2)  2021-08-12 20:59:39Z  local/std  1.66
3.8.0-beta1          (1)  2021-08-13 00:59:40Z     GMT     1.66
3.8.0-beta2          (3)  2021-08-13 00:59:41Z     GMT     1.66

My OS is openSUSE Leap 15.0 (GNU/Linux).  However, the latest version of
openSUSE is Leap 15.3, and I wouldn't know if the behavior is the same.

I also suspect that I do not have the latest version of Boost, but my
computer is actively thwarting my every attempt to upgrade the OS, and
is now without access to any active repositories.

> Bonus questions:
> 
> - Using genuine POV-Ray, have you ever, and beyond doubt, observed
> behavior (B) during times when DST was in effect in your time zone?

My locale does not observe DST.

[clipka] Re: `datetime(now)` issue - suggestions for a so... [1700 days 14 hours and 15 minutes ago]

Thu, 12 Aug 2021 17:38:17 GMT

Am 12.08.2021 um 14:16 schrieb William F Pokorny:

> A now_for_datetime can be sloppy to the order most concerns we've 
> pointed out are OK. It could always use the local machine's epoch and 
> local setting - aligning with other local tools in the machine/OS 
> environment. Something easier for users to use date time wise.

Um - nope.

Juging from my experience with trying to get the `datetime` and `now` 
stuff sorted out, a `now` based on local time will only be a source of 
utter confusion.

What would that value even represent?

The only sensible formulation is a "time units since D-Day H-Hour".

Such a D-Day H-Hour would have well-defined DST semantics, either 
explicitly by definition or implicitly by user expectation. If D-Day was 
2000-01-01, H-Hour was 00:00, and the value was advertised as local 
time, then users would expect H-Hour to imply local non-DST in the 
northern hemisphere, local DST in the southern hemisphre, or non-DST if 
their time zone does not observe DST at all.

So if some user were to compute a point in time of, say, 2000-07-01 
00:00 local time - would that be D-Day H-Hour plus exactly 182*24 hours, 
or 1 hour more or less due to DST?


That won't fly. Not in the "easier for the user" sort of way, at any rate.

And certainly not in the "easier for the programmer" sort of way either, 
that much I can guarantee already.


> Imagine a large, long running, parser characterization job for all the 
> 'things' for which we want to track relative performance. The 
> information from which we, perhaps, stick in a big table via jr's new 
> macro and publish. Regular timing results useful to users and developers.

And that will be utterly useless if the functionality to actually 
implement the timing measurements takes considerable time compared to 
what we actually want to measure.

For such an endeavor, things need to have the lightest footprint in 
parser itself that we can possibly create. Ideally, it would just be a 
single (and possibly even very short) token. What that statement would 
trigger can be a bit more complex, because it will be compiled, rather 
than having to be parsed.

Possibly a job for a dedicated build, that adds a single-character token 
just for the purpose, and which isn't functional in release builds. "@" 
isn't used anywhere, for example.

This could trigger one or more performance metrics to be logged whenever 
"@" is encountered, and the result dumped once parsing (or rendering) 
has completed. Maybe a fixed number of characters to follow (say, 4), to 
be logged along with it. The resulting dump could then be correlated 
with the scene later.

If you want precise results, that would be the road to give you the most 
reliable data.

[William F Pokorny] Re: `datetime(now)` issue - suggestions for a so... [1700 days 19 hours and 27 minutes ago]

Thu, 12 Aug 2021 12:25:54 GMT

On 8/12/21 7:59 AM, clipka wrote:
> Am 11.08.2021 um 14:57 schrieb William F Pokorny:
> 
>> Of note for POV-Ray v3.8 and onward is that the Fn_TimePt00, 
>> Fn_TimePt00 method for capturing time points should work in v3.8 beta 
>> 1, but it doesn't because when 'now' was added, the support for it was 
>> not added to parser_strings.cpp alongside pi, tau, etc. This a stand 
>> alone 'now' issue.
> 
> I think you mean `parser_functions.cpp`?

I did, sorry.

As for what you say below... We're not going to agree. Plus, I need to 
run to other stuff for the day.

The token 'now' is what it is when the parse sees it. It's no different 
than 'pi' in that regard. Why create inconsistent behavior for users?

> 
> There's a point to be made in keeping it that way: If we allow `now` in 
> a function, what value should it evaluate to? The point of time when the 
> function is parsed and compiled, or the one when it is invoked?
> 
> Since the answer to both alternatives is probably "yes" (depending on 
> the use case), allowing it at all in functions _will_ cause confusion.
> 
> For e.g. `pi` and `tau`, by contrast, the answer is easy: "Who cares, 
> it's the same either way."
> 
> 
> Also, if you design a function to return current date and time encoded 
> in a different time format (say, POSIX timestamp), it's easy to just add 
> another parameter, and pass `now` when invoking that function. (*)
> 
> And while a function that evaluates to a different value upon each 
> invocation during render _may_ sound like a fun idea, I'm quite sure its 
> applicability is pretty much limited to being a novelty.
> 
> 
> (*Speaking of extra parameters: Passing the number of seconds in a day 
> as a _parameter_...??!)

[William F Pokorny] Re: `datetime(now)` issue - suggestions for a so... [1700 days 19 hours and 37 minutes ago]

Thu, 12 Aug 2021 12:16:27 GMT

On 8/11/21 2:07 PM, clipka wrote:
> If people want precise performance metrics, anything based on a real 
> time clock - even `std::chrono::steady_clock` - is a poor choice of tool 
> anyway. In general, I would guess that the task/thread scheduling jitter 
> introduces far more noise into the measurements than the occasional 
> system clock adjustment. CPU time would be a far better candidate for 
> such things.
> 
> 
> Also note that for the purpose of performance metrics, we already 
> provide measurements of the total parsing time, both real time and CPU 
> time.
> 
> If you think we should provide more tools for performance measurements, 
> I would argue that some `#split_time` directive to print out the current 
> parser stats would make more sense than some basic building block that 
> users would have to build additional SDL code around, that in turn would 
> potentially skew the results, to actually put to use.
> 
> But I don't see any dire need for such a feature.

First, thanks for the detailed response.

I remain of the opinion POV-Ray would be better positioned with two 
'now's with a 'now_for_datetime' and a 'now_for_timing'.

A now_for_datetime can be sloppy to the order most concerns we've 
pointed out are OK. It could always use the local machine's epoch and 
local setting - aligning with other local tools in the machine/OS 
environment. Something easier for users to use date time wise.

As to timing things inside the parser. My initial reaction was similar 
to yours. The idea rattled around a while inside the cavity behind my 
eyes, and, I started to think that certain sorts of timing 
characterizations are likely simpler/better-done within the parser.

The parser, in being single threaded, is at some advantage timing wise 
for using only a one thread.

---
Something which gets asked every now and again, is whether POV-Ray could 
provide some idea as to the relative expense of certain features over 
others.

Instead of timing some block of user SDL code, imagine instead a parser 
only job which first characterizes the cost of an empty loop and - to 
the degree it can - other "wrapper" costs. We then start inserting 
things to characterize in that loop/wrapper. Single patterns in turn as 
called via functions. Functions themselves one at a time. Or trace() 
operations against base shapes/surfaces one at a time. Or particular 
parser functions one a time. Or whatever else. In many respects the 
parser can more easy isolate particular functionality than can be 
accomplished via other methods.

Imagine a large, long running, parser characterization job for all the 
'things' for which we want to track relative performance. The 
information from which we, perhaps, stick in a big table via jr's new 
macro and publish. Regular timing results useful to users and developers.

This the sort of parser timing application which I believe requires a 
more stable and dedicated 'now_for_timing'. But, yep, it's just another 
idea at this point - except for now having povr's timer specific 
f_clock() feature in hand.

Bill P.

[clipka] Re: `datetime(now)` issue - suggestions for a so... [1700 days 19 hours and 53 minutes ago]

Thu, 12 Aug 2021 11:59:53 GMT

Am 11.08.2021 um 14:57 schrieb William F Pokorny:

> Of note for POV-Ray v3.8 and onward is that the Fn_TimePt00, Fn_TimePt00 
> method for capturing time points should work in v3.8 beta 1, but it 
> doesn't because when 'now' was added, the support for it was not added 
> to parser_strings.cpp alongside pi, tau, etc. This a stand alone 'now' 
> issue.

I think you mean `parser_functions.cpp`?

There's a point to be made in keeping it that way: If we allow `now` in 
a function, what value should it evaluate to? The point of time when the 
function is parsed and compiled, or the one when it is invoked?

Since the answer to both alternatives is probably "yes" (depending on 
the use case), allowing it at all in functions _will_ cause confusion.

For e.g. `pi` and `tau`, by contrast, the answer is easy: "Who cares, 
it's the same either way."


Also, if you design a function to return current date and time encoded 
in a different time format (say, POSIX timestamp), it's easy to just add 
another parameter, and pass `now` when invoking that function. (*)

And while a function that evaluates to a different value upon each 
invocation during render _may_ sound like a fun idea, I'm quite sure its 
applicability is pretty much limited to being a novelty.


(*Speaking of extra parameters: Passing the number of seconds in a day 
as a _parameter_...??!)

[jr] Re: Call to Arms: Datetime [1700 days 20 hours and 18 minutes ago]

Thu, 12 Aug 2021 11:35:00 GMT

hi,

clipka <ano### [at] anonymousorg> wrote:
> ...
> The thing is, with time zone set to UTC+0 when DST is not in effect, you
> just can't tell.

well,the system knows.  and also a good reason, imo, to have a (run time)
configuration option to tell POV-Ray.

re WFP's 'datetime(now,"%c")', I agree and see a trailing space char, as if the
'Z' had simply been overwritten.

regards,jr.

[clipka] Re: POV-Ray v3.8.0-beta 1 - Parse error using "%... [1700 days 20 hours and 25 minutes ago]

Thu, 12 Aug 2021 11:27:59 GMT

Am 12.08.2021 um 13:01 schrieb William F Pokorny:

> Hmmm, just had a thought about that line of code in parser_strings.cpp:
> 
> setlocale(LC_TIME,"");
> 
> I didn't play with that at all. Wondering at the moment what happens if 
> we move that call ahead of:
> 
> std::tm t = 
> boost::posix_time::to_tm(boost::posix_time::from_time_t(timestamp));
> 
> Could it be we are not getting some fields because at that call we are 
> effectively running: setlocale(LC_TIME,"C") ?

If that were the case, then

     #declare ThrowAway = datetime(now);
     #debug concat(datetime(now),"\n")

should change the behavior, since the first invocation of `datetime` 
should switch the time locale to the system default, and we're never 
switching it back, so the next invocation of `datetime` should start 
with the system default time locale already selected.

But I'd be surprised if that would work. By definition, `std::time_t` is 
positively supposed to represent universal time in some way or form, so 
converting that to `std::tm` should still result in "yeah, here's your 
date information, but as for DST, well, that's not really applicable 
here at all because UTC."


I thknk what should really happen is that we should perform the 
conversion from `std::time_t` to `std::tm` via `std::gmtime()` when 
converting for UTC, and via `std::localtime()` when converting for local 
time. I'm quite confident that the latter should set the DST flag as 
appropriate. And it will also definitely take care of adjusting for time 
zone, so we can use a `now` that's always based on UTC.

The povr code also using `std::localtime()` confirms that this should 
indeed actually work.

[William F Pokorny] Re: POV-Ray v3.8.0-beta 1 - Parse error using "%... [1700 days 20 hours and 52 minutes ago]

Thu, 12 Aug 2021 11:01:22 GMT

On 8/11/21 5:55 PM, clipka wrote:
> Should it though?

Understanding what you are saying below, my answer is still, yes, 
because it is what my locale does if the information is available. In 
other words POV-Ray's %c result should match what my 'date' command 
returns.

Aside: IIRC, there's a huge text file with all sorts of locale 
information in it that gets used to create code for compilers and the 
like. I've never tried to find it. I do sort of wonder what it looks like.

Hmmm, just had a thought about that line of code in parser_strings.cpp:

setlocale(LC_TIME,"");

I didn't play with that at all. Wondering at the moment what happens if 
we move that call ahead of:

std::tm t = 
boost::posix_time::to_tm(boost::posix_time::from_time_t(timestamp));

Could it be we are not getting some fields because at that call we are 
effectively running: setlocale(LC_TIME,"C") ?

> The C (and by extension C++) standard mandates that `strftime` replace 
> `%c` with "the locale’s appropriate date and time representation". 
> That's it, no other specification for it. Whether that is to include any 
> time zone information is, I would argue, up to "the locale". For the `C` 
> locale, for instance, the standard specifically mandates that a timezone 
> specifier is NOT included in the "%c" replacement text.
> 
> Also, even if the locale does happen to include a `%Z`, it makes sense 
> that it also gets replaced by an empty string, just like an explicit `%Z`.
> 
>> // (***) Above issue and time not the actual utc time.
> 
> Not at all surprised there.
> Should match your local non-DST time.
> 
>> As I believe I mentioned somewhere else, I'm not sure what all doesn't 
>> work with respect to formatting given the boost code being used 
>> doesn't   set up all the fields needed to use the complete set of 
>> strftime() formatting.
> 
>  From all of my understanding, only the timezone identifier (either 
> explicitly, or implicitly such as via `%c`) should suffer.
> 
> 
> Okay, I guess the takeway lesson here is that as implemented up to (and 
> including) v3.8.0-beta-1, your system doesn't seem to have enough 
> information to decide what timezone is applicable, presumably because 
> the info whether DST is in effect for the date isn't explicitly set, and 
> your runtime library's `strftime` function does not make any attempt to 
> figure it our for itself.
> 
> Which begs the question, what exactly does povr do differently?

The povr code looks like:

         std::time_t tt;
         if (FractionalDays <= -1e5)  // (****)
         {
             tt = std::time(nullptr);
         }
         else
         {
             tt = std::mktime(&t);
         }
         setlocale(LC_TIME,""); // Get the local preferred format
         vlen = strftime(val, PARSE_NOW_VAL_LENGTH, FormatStr, 
std::localtime(&tt));

Suppose, if you were to use something like it, you might make use too of 
std::gmtime() - depending on settings.

(****) - Yep, my old brain failed too to remember my own trigger for 
generating the time_t information immediately. At one point I was 
thinking of using any value prior to epoch, but apparently I didn't.

Bill P.

[clipka] Re: Call to Arms: Datetime [1700 days 20 hours and 55 minutes ago]

Thu, 12 Aug 2021 10:58:14 GMT

Am 11.08.2021 um 13:08 schrieb clipka:

> regarding the `datetime(now)` issue, I need more information from you 
> folks, to make sure I'm not hunting a phantom.

The data I've gotten so far supports my suspicion, so I'd like to take 
this call to arms into a different mode of operation.

Anyone who hasn't replied so far, but wants to assist in this, I'd just 
like you to confirm that the following holds for your system, too:

--
When using either POV-Ray v3.7 or v3.8.0-beta.1 (sic! I don't care about 
beta.2 in this context), `datetime(now)` returns a string that matches 
the current time as UTC (frequently referred to as "GMT", and being 
equal to London local time when DST is not in effect), with a trailing 
literal "Z" (which "happens" to be the ISO timezone code for UTC).

(please specify operating system, POV-Ray version and timezone when 
replying.)
--

Unless someone reports otherwise, my preliminary verdict is as follows:

- There never was a bug in the first place (well, not this one anyway) 
that would show on some _systems_ and not on others. Instead, there was 
a bug that would show on some _versions_ of POV-Ray and not on others.

- `datetime()` and `now` had always been working exactly as intended and 
documented, starting with its introduction in v3.7.0.0, until...

- it was actually borked by me in v3.8.0-alpha.10064268 when I rewrote 
the code to use C++11 features instead of boost, to no longer require 
the boost datetime library.

- The new code would instead have `now` report time since 2000-01-01 
00:00 local time, instead of UTC, while `datetime` would continue to 
expect UTC and thus printed a wrong time (and still explicitly claiming 
it to be UTC). That time would happen to match local time, but only when 
DST was not in effect (in the northern hemisphere; in the southern 
hemisphere, the behavior regarding DST would presumably be the other way 
round).

- With the rollback to earlier v3.8.0 code, we also switched back to the 
properly working `now` code, so the bug was already absent again in 
v3.8.0-beta.1; and my attempt to fix it in v3.8.0-beta.2 presumably did 
nothing at all, except waste time (both mine in developing it and yours 
in rendering scenes making use of `now`, which take a tiny bit longer to 
parse with the "fix").


Crucially, this means that the borked behavior hasn't been around very 
long (comparatively), so there isn't really much pressure to do anything 
at all in the name of backward compatibility.

It also means that I can be reasonably sure that a solution which works 
on my Windows machine will also work on your Lunix machines.


What's still left for me to do is:

* Investigate that other (probably entirely unrelated) problem regarding 
DST when using a non-default format string in `datetime`, specifically 
when using `%z` or `%Z` to display local timezone information.

* For convenience, provide a means for users to actually get a local 
date out of `datetime` (and one that respects DST, for that matter).

[clipka] Re: Call to Arms: Datetime [1700 days 23 hours and 34 minutes ago]

Thu, 12 Aug 2021 08:19:33 GMT

Am 12.08.2021 um 09:11 schrieb Ton:

> With beta 2 I have the same issue, datetime is 12 hours behind.
> date = 2021-08-12 07:03:48Z

Technically that's not an issue at all: The trailing "Z" is the official 
ISO timezone code for UTC. And that's exactly how `datetime` is intended 
and documented to work.

We're already working on a solution though to get proper local time to 
you people (with correct DST and all the bells & whistles) as an 
alternative.

[Ton] Re: Call to Arms: Datetime [1701 days and 38 minutes ago]

Thu, 12 Aug 2021 07:15:00 GMT

"Ton" <ton### [at] gmailcom> wrote:
> datetime(now)
> 2021-08-12 00:14:08Z
>
> $ date
> Thu 12 Aug 2021 12:14:26 NZST
>
> My time zone is New Zealand, Standard Time (it's winter here)
>
> Persistence of Vision(tm) Ray Tracer Version 3.8.0-beta.1.unofficial (g++ 9 @
> x86_64-pc-linux-gnu)
>
>   Boost 1.71, http://www.boost.org/
>
> $ uname -a
> Linux Pavilion 5.8.0-59-generic #66~20.04.1-Ubuntu SMP Thu Jun 17 11:14:10 UTC
> 2021 x86_64 x86_64 x86_64 GNU/Linux
>
> Cheers
> Ton

With beta 2 I have the same issue, datetime is 12 hours behind.
date = 2021-08-12 07:03:48Z

$ date
Thu 12 Aug 2021 19:03:48 NZST

Persistence of Vision(tm) Ray Tracer Version 3.8.0-beta.2.unofficial (g++ 9 @
x86_64-pc-linux-gnu)

Cheers
Ton

[clipka] Re: Call to Arms: Datetime [1701 days and 46 minutes ago]

Thu, 12 Aug 2021 07:06:51 GMT

Am 12.08.2021 um 08:43 schrieb jr:

>> Thanks, that's an important piece of the puzzle. If I'm not having a
>> total brain fart, this means that (A) and (C) are indistinguishable on
>> your system.
> 
> UTC + "British" time are the same from October to March.  not sure about
> "indistinguishable", utilities like 'date' always use/display a time zone.

What I mean is this: Would you have any way of telling whether _POV-Ray_ 
is displaying local non-DST, or whether it is instead displaying UTC?

Even if it _did_ append time zone information, you still couldn't tell 
whether the two pieces of information would actually be related. For all 
you know, POV-Ray could take UTC and independently append a string that 
happens to represent your proper time zone - or it could take non-DST 
local time and append a string that happens to look like a UTC time zone 
identifier (which is literally what happens in scenario (C)).

Or it _could_ take UTC and append a string that happens to look like a 
UTC time zone identifier (which is literally what happens in scenario (A)).

The thing is, with time zone set to UTC+0 when DST is not in effect, you 
just can't tell.

[jr] Re: Call to Arms: Datetime [1701 days 1 hour and 8 minutes ago]

Thu, 12 Aug 2021 06:45:00 GMT

hi,

clipka <ano### [at] anonymousorg> wrote:
> Am 11.08.2021 um 18:17 schrieb jr:
>
> >> Information about what time zone you've set up on your system would also
> >> be of interest (at least if it's very close to UTC; if it's far off,
> >> "not even close to UTC" is all I'd need to know).
> >
> > v close, GMT.  currently on "British Summer Time" (Wed 11 Aug 17:15:45 BST
> > 2021).
>
> Thanks, that's an important piece of the puzzle. If I'm not having a
> total brain fart, this means that (A) and (C) are indistinguishable on
> your system.

UTC + "British" time are the same from October to March.  not sure about
"indistinguishable", utilities like 'date' always use/display a time zone.


regards, jr.

[Thomas de Groot] Re: Call to Arms: Datetime [1701 days 1 hour and 36 minutes ago]

Thu, 12 Aug 2021 06:17:25 GMT

Op 11/08/2021 om 16:18 schreef clipka:
> Am 11.08.2021 um 14:13 schrieb Thomas de Groot:
>> I don't know if the following is answering your questions but anyway, 
>> these are the versions I have currently accessible on my laptop:
> 
> Information about your actual time zone would have been helpful, but I 
> have enough material to make an educated guess about that.
> 
Sorry for that; I always get confused when timezones are involved ;-). 
Seems I am at UTC+2 at the moment.

>> The third one is deviant. No idea about "boost version".
> 
> When you start up POV-Ray for Windows, the initial message pane content 
> will list the boost version close to the bottm. But with the Windows 
> versions being distributed as binaries I can reconstruct that piece of 
> information myself, so no worries there.

Well, learned something new today it seems. :-)
[never too old, never too old...]

-- 
Thomas

[BayashiPascal] Re: Call to Arms: Datetime [1701 days 2 hours and 18 minutes ago]

Thu, 12 Aug 2021 05:35:00 GMT

Hi clipka,

Here is what I get:

```
#version 3.8;
#warning concat("\ndatetime(now) is ", datetime(now), "\n")
```
gives:
```
Persistence of Vision(tm) Ray Tracer Version 3.8.0-beta.1.unofficial (g++ 7 @
 x86_64-pc-linux-gnu)
....
File 'test.pov' line 2: Parse Warning:  datetime(now) is 2021-08-12 05:20:38Z
```

`date` gives `2021/8/12 thursday 14:20:38 JST` (I am in Japan, output edited to
remove the japanese characters, and there is no DST here)

Hope it will help,
Pascal



clipka <ano### [at] anonymousorg> wrote:
> Folks,
>
> regarding the `datetime(now)` issue, I need more information from you
> folks, to make sure I'm not hunting a phantom.
>
>
> As far as I can tell, there may be as many as three variants of behavior
> out there, with `datetime(now)` returning the current time as either...:
>
> (A) UTC time,
>
> (B) LOCAL time, properly respecting daylight savings time, or
>
> (C) LOCAL time, IGNORING daylight savings time,
>
> with all variants appending a literal "Z" (intended to indicate UTC, but
> being bonkers in cases (B) and (C)).
>
>
> There are also two variants of the source code out there... well,
> actually three by now:
>
> (1) Some old boost-based source code;
>
> (2) some newer C++11-based code; and
>
> (3) a variant of (1) with a fix to enforce behavior (A).
>
>
> These variants were used in the following POV-Ray versions:
>
> v3.7.0.0 - v3.8.0-alpha.10013324 (2019-01-14):
> Variant (1)
>
> v3.8.0-alpha.10064268 (2019-02-19) - v3.8.0-alpha.11272893 (last alpha):
> Variant (2)
>
> v3.8.0-beta.1:
> Variant (1) again
>
> v3.8.0-beta.2:
> Variant (3)
>
>
> I need your help to test the different variants of the code (especially
> (1) and (2)) on your machines, and let me know:
>
> - What behavior you are observing for code variant (1);
> - what behavior you are observing for code variant (2);
> - what operating system you are using; and
> - what version of boost POV-Ray has been compiled with.
>
> Bonus questions:
>
> - Using genuine POV-Ray, have you ever, and beyond doubt, observed
> behavior (B) during times when DST was in effect in your time zone?
>
>
> (Please disregard derivatives such as rpov in this test/poll. They have
> no impact whatsoever on the question I'm eager to get answers to.)
>
>
> I have a hunch that I may have been looking in a completely wrong
> direction in this matter.

[Ton] Re: Call to Arms: Datetime [1701 days 7 hours and 28 minutes ago]

Thu, 12 Aug 2021 00:25:00 GMT

datetime(now)
2021-08-12 00:14:08Z

$ date
Thu 12 Aug 2021 12:14:26 NZST

My time zone is New Zealand, Standard Time (it's winter here)

Persistence of Vision(tm) Ray Tracer Version 3.8.0-beta.1.unofficial (g++ 9 @
x86_64-pc-linux-gnu)

  Boost 1.71, http://www.boost.org/

$ uname -a
Linux Pavilion 5.8.0-59-generic #66~20.04.1-Ubuntu SMP Thu Jun 17 11:14:10 UTC
2021 x86_64 x86_64 x86_64 GNU/Linux

Cheers
Ton

[clipka] Re: POV-Ray v3.8.0-beta 1 - Parse error using "%... [1701 days 9 hours and 57 minutes ago]

Wed, 11 Aug 2021 21:55:43 GMT

Am 11.08.2021 um 22:37 schrieb William F Pokorny:

> //---
>    #debug concat("%z ---> <",datetime(now,"%z"),">\n")
>    #debug concat("%Z ---> <",datetime(now,"%Z"),">\n")
>    // For the lines above
>    // 3.7.0.8  - Invalid formatting code in format string, or
>    //           
resulting string too long.
>    // v3.8 b 1 - Invalid formatting code in format string, or
>    //           
resulting string too long.
>    // ~master  - Invalid formatting code in format string, or
>    //           
resulting string too long.
>    // povr     - %z ---> <-0400>
>    //            %Z --->
<EDT>

Hah!

This one took me a while, and I was on the verge of asserting that 
`strftime` must be broken on your machine. Because whatever `strftime` 
does, it should NOT be reporting an error when confronted with these 
parameters.

The kicker is: It doesn't.

What happens it that - for _some_ reason - `strftime` can't properly 
determine the time zone (e.g. because it doesn't know whether DST is in 
effect or not).

In that case, it is contractually obliged to replace `%z` or `%Z` with 
an empty string.

Which, in this very special case, leads to a completely empty result string.

Which means that `strftime` return a value of 0, because that's what it 
does if it doesn't encounter a fatal error: It returns the number of 
characters placed in the result string.

Zero.

Which also happens to be the value it is contractually obliged to return 
if it runs out of space to write the result string to.

So POV-Ray panics, imagining there to be a serious problem when there is 
none.


>    #debug concat("%z ---> <",datetime(now,"%c %z"),">\n")
>    #debug concat("%Z ---> <",datetime(now,"%c %Z"),">\n")
>    // For the lines above
>    // 3.7.0.8  - %z ---> <Wed 11 Aug 2021 07:58:53 PM  >
>    //            %Z --->
<Wed 11 Aug 2021 07:58:53 PM  > (**)
>    // v3.8 b 1 - %z ---> <Wed 11 Aug 2021 07:58:53 PM  >
>    //            %Z --->
<Wed 11 Aug 2021 07:58:53 PM  > (**)
>    // ~master  - %z ---> <Wed 11 Aug 2021 03:05:50 PM  > (***)
>    //            %Z --->
<Wed 11 Aug 2021 03:05:50 PM  > (***)
>    // povr (*) - %z ---> <Wed 11 Aug 2021 03:05:50 PM EDT -0400>
>    //            %Z --->
<Wed 11 Aug 2021 03:05:50 PM EDT EDT>
> 
> // (*) The time isn't accounting for dst though %z,%Z correct.

> // (**) The %c should include a %Z string of its own and does not.

Should it though?
The C (and by extension C++) standard mandates that `strftime` replace 
`%c` with "the locale’s appropriate date and time representation". 
That's it, no other specification for it. Whether that is to include any 
time zone information is, I would argue, up to "the locale". For the `C` 
locale, for instance, the standard specifically mandates that a timezone 
specifier is NOT included in the "%c" replacement text.

Also, even if the locale does happen to include a `%Z`, it makes sense 
that it also gets replaced by an empty string, just like an explicit `%Z`.

> // (***) Above issue and time not the actual utc time.

Not at all surprised there.
Should match your local non-DST time.

> As I believe I mentioned somewhere else, I'm not sure what all doesn't 
> work with respect to formatting given the boost code being used doesn't 
>   set up all the fields needed to use the complete set of strftime() 
> formatting.

 From all of my understanding, only the timezone identifier (either 
explicitly, or implicitly such as via `%c`) should suffer.


Okay, I guess the takeway lesson here is that as implemented up to (and 
including) v3.8.0-beta-1, your system doesn't seem to have enough 
information to decide what timezone is applicable, presumably because 
the info whether DST is in effect for the date isn't explicitly set, and 
your runtime library's `strftime` function does not make any attempt to 
figure it our for itself.

Which begs the question, what exactly does povr do differently?

[William F Pokorny] Re: POV-Ray v3.8.0-beta 1 - Parse error using "%... [1701 days 11 hours and 15 minutes ago]

Wed, 11 Aug 2021 20:37:58 GMT

On 8/11/21 11:10 AM, clipka wrote:
> Can you elaborate on the "%z %Z don't work"?

Some. The failures are varied depending upon the format string.

SDL:

//---
   #debug concat("%z ---> <",datetime(now,"%z"),">\n")
   #debug concat("%Z ---> <",datetime(now,"%Z"),">\n")
   // For the lines above
   // 3.7.0.8  - Invalid formatting code in format string, or
   //            resulting string too long.
   // v3.8 b 1 - Invalid formatting code in format string, or
   //            resulting string too long.
   // ~master  - Invalid formatting code in format string, or
   //            resulting string too long.
   // povr     - %z ---> <-0400>
   //            %Z ---> <EDT>

   #debug concat("%z ---> <",datetime(now,"%c %z"),">\n")
   #debug concat("%Z ---> <",datetime(now,"%c %Z"),">\n")
   // For the lines above
   // 3.7.0.8  - %z ---> <Wed 11 Aug 2021 07:58:53 PM  >
   //            %Z ---> <Wed 11 Aug 2021 07:58:53 PM  > (**)
   // v3.8 b 1 - %z ---> <Wed 11 Aug 2021 07:58:53 PM  >
   //            %Z ---> <Wed 11 Aug 2021 07:58:53 PM  > (**)
   // ~master  - %z ---> <Wed 11 Aug 2021 03:05:50 PM  > (***)
   //            %Z ---> <Wed 11 Aug 2021 03:05:50 PM  > (***)
   // povr (*) - %z ---> <Wed 11 Aug 2021 03:05:50 PM EDT -0400>
   //            %Z ---> <Wed 11 Aug 2021 03:05:50 PM EDT EDT>

// (*) The time isn't accounting for dst though %z,%Z correct.
// (**) The %c should include a %Z string of its own and does not.
// (***) Above issue and time not the actual utc time.

#error "Parse test. Stop early."
//---

As I believe I mentioned somewhere else, I'm not sure what all doesn't 
work with respect to formatting given the boost code being used doesn't 
  set up all the fields needed to use the complete set of strftime() 
formatting.

Bill P.

[clipka] Re: Call to Arms: Datetime [1701 days 13 hours and 35 minutes ago]

Wed, 11 Aug 2021 18:18:26 GMT

Am 11.08.2021 um 13:08 schrieb clipka:

> These variants were used in the following POV-Ray versions:
> 
> v3.7.0.0 - v3.8.0-alpha.10013324 (2019-01-14):
> Variant (1)
> 
> v3.8.0-alpha.10064268 (2019-02-19) - v3.8.0-alpha.11272893 (last alpha):
> Variant (2)
> 
> v3.8.0-beta.1:
> Variant (1) again
> 
> v3.8.0-beta.2:
> Variant (3)

For the records, the v3.8.0-x.freetype versions (which seem to have 
gained more popularity than I'd have expected) should be using the 
following source code variants:

v3.8.0-x.freetype.1 - v3.8.0-x.freetype.2:
Variant (1)

v3.8.0-x.freetype.3 - v3.8.0-x.freetype.4:
Variant (2)

[clipka] Re: Call to Arms: Datetime [1701 days 13 hours and 42 minutes ago]

Wed, 11 Aug 2021 18:11:16 GMT

Am 11.08.2021 um 18:17 schrieb jr:

>> Information about what time zone you've set up on your system would also
>> be of interest (at least if it's very close to UTC; if it's far off,
>> "not even close to UTC" is all I'd need to know).
> 
> v close, GMT.  currently on "British Summer Time" (Wed 11 Aug 17:15:45 BST
> 2021).

Thanks, that's an important piece of the puzzle. If I'm not having a 
total brain fart, this means that (A) and (C) are indistinguishable on 
your system.

[clipka] Re: `datetime(now)` issue - suggestions for a so... [1701 days 13 hours and 46 minutes ago]

Wed, 11 Aug 2021 18:07:32 GMT

Am 11.08.2021 um 14:57 schrieb William F Pokorny:

> In your preamble, you didn't mention 'now' being used as an SDL timing 
> mechanism. It's something people do today and it carries risk with 
> respect to any particular timing result. The reasons is we are using the 
> system_clock for 'now' which can be updated at any time moving forward 
> or backward - synchronization with time servers, etc.
> 
> We don't warn against timing use of 'now' in the documentation as far as 
> I know. Perhaps we should?

I don't think there's much sense to warn of using `now` in this capacity 
in particular.

If people want a rough idea of how long the individual pieces of their 
scene take to parse, for example to decide what portions of their scene 
to try and optimize, `now` is probably good enough. It's not like system 
clocks are typically corrected umpteen times a day, or changed by huge 
values.

Also, given that `now` has days as its unit of measure, and the docs 
make no promises about its precision other than that it is "seconds or 
better", I think that's enough of a warning to not use it for 
microseconds precision measurements if anything serious depends on it.

If people want precise performance metrics, anything based on a real 
time clock - even `std::chrono::steady_clock` - is a poor choice of tool 
anyway. In general, I would guess that the task/thread scheduling jitter 
introduces far more noise into the measurements than the occasional 
system clock adjustment. CPU time would be a far better candidate for 
such things.


Also note that for the purpose of performance metrics, we already 
provide measurements of the total parsing time, both real time and CPU time.

If you think we should provide more tools for performance measurements, 
I would argue that some `#split_time` directive to print out the current 
parser stats would make more sense than some basic building block that 
users would have to build additional SDL code around, that in turn would 
potentially skew the results, to actually put to use.

But I don't see any dire need for such a feature.


> In povr's f_clock() the up front returned time comes from steady_clock 
> instead - which on my Ubuntu 20.04 machine appears to be a monotonic 
> clock since the last reboot/boot.

That's what `steady_clock` is for. If it wasn't monotonic, it would 
violate the C++ specs.

But being monotonic and steady, it is obviously no good as a building 
block for getting the time of day as a string (and conversion to an 
absolute date may also be a pain).


> Of note for POV-Ray v3.8 and onward is that the Fn_TimePt00, Fn_TimePt00 
> method for capturing time points should work in v3.8 beta 1, but it 
> doesn't because when 'now' was added, the support for it was not added 
> to parser_strings.cpp alongside pi, tau, etc. This a stand alone 'now' 
> issue.

Then that sounds like a bug to me, or at least an issue.


> Putting more of the whole plan/implementation on the table because I see 
> secondary 'concerns' such as POV-Ray's Y2K epoch not lining up with any 
> unix like system I've ever used - all have been at Jan 1, 1970. This 
> makes understanding the values POV-Ray is generating and using harder to 
> work with.

This was a deliberate choice, based on various considerations:


* The value was to be exposed to the user, allowing them to assign it to 
other variables, as well as perform arithmetics on it (such as adding a 
day or an hour before converting to a date/time string, or computing the 
number of minutes the parsing took and inserting that value as text in 
the image; or computing a value from scratch to be later represented as 
a date/time string).

This inevitably meant that the format would have to be based on a 
floating-point representation.

This in turn meant that the maximum possible absolute precision would 
not be constant, but vary depending on the distance from whatever "zero 
point" we would choose. So it would be advantageous to choose a "zero 
point" close to the time we live in.


* The value should have a precision of seconds in the worst case, but 
higher precision if possible.


* With POV-Ray being a platform-agnostic project at heart, I did not 
want to give preference for any existing platform-specific time 
representation format - neither POSIX' native seconds-since-1970 
timestamp format, nor Windows' native 100ns-intervals-since-1601 format. 
The only format I would have considered would have been a format defined 
as part of the C/C++ standard. Had I followed that route, I would have 
ended up using 1900 as the basis, as that's the only epoch year that had 
been explicitly specified by the official C/C++ standard at the time 
(see the `std::tm` structure). The POSIX epoch hasn't made it into the 
official C/C++ standard until C++20, and even then only for non-C 
features for now.

Also remember that back then (2013 or earlier), POSIX time wasn't nearly 
as ubiquitous as it is today.


* I did want a format that would be easy for users to understand, and

* I specificially did want a format that would be easily convertible to 
POSIX time.

While the latter would seem to clearly speak in favor of POSIX time 
itself, in conjunction with the previous point it actually speaks 
AGAINST it; here's why:

POSIX time is often cited as being the number of seconds that have 
elapsed since 1970-01-01 00:00 UTC.
That is NOT the case.
As a matter of fact, POSIX time is currently about 30 seconds short of 
that value.

Instead, POSIX time is the number of _days_ that have elapsed since that 
point in time, plus the number of seconds that have elapsed since 00:00 
UTC of the current (UTC) day.
(Modulo one or two other minor quirks.)
The difference being that this method does not include leap seconds.

By specifying the format of `now` to give a number of days, rather than 
seconds, we're avoiding this subtle difference between what peopole 
_think_ POSIX time is, and what it _actually_ is.
(As a minor snag, on days with leap seconds we're actually off by up to 
1 second in the value reported, but those days are rare.)


Now with using days instead of seconds for the `now` format, some math 
would be required to convert to or from POSIX time anyway; so 
introducing a constant offset in addition to the seconds-per-day factor 
was anything but a big deal.

Year 2000 made for a far nicer epoch than 1970, or 1961, or even 1900. 
And it was closer to "home", meaning we'd have more headroom in terms of 
precision for longer time in the future.

(Year 2000 also had the benefit that UTC was already defined in its 
current form then. In 1970 it wasn't, so the POSIX time value 0 is 
somewhat ambiguous. Not that it matters, as current dates are still 
well-defined.)


* Speaking of conversion, If it would turn out that users wanted to 
convert to or from POSIX time frequently, enough so that it would 
warrant support from our side, the format choisen would have made it 
trivial to provide an official include file to define a function or 
macro to convert between the two formats. And other then-competing 
formats besides.


> Unix commands like date have some nice options:
> 
> date --date='TZ="America/Los_Angeles" 09:00 next Mon' +"%s"
> 
> but we cannot use the results directly in POV-Ray. Hmm, maybe an 
> explicit unix time to y2k seconds type for f_clock...

What's wrong with a simple conversion function?

Why put all the burden on the building block that has the primary job of 
getting the current date and time in _some_ format?

That's a difficult enough job as it is. Leave conversion stuff to 
separate dedicated functions. It's also a difficult enough job.

There is _no_ reason whatsoever to mix them. Just as there is _no_ 
reason whatsoever to cram `now` and `datetime` in a single monolithic 
function, as the original design would have had it.


> Aside:
> Supposing datetime fixed to support %z %Z, and 'now' returning always a 
> no dst utc or local time you can fairly easily adjust the fractional day 
> value to account for dst of say an hour with:
> 
> #declare DSToffset = (1/24);

Yeah, no.
I'm already working on a solution that is far simpler for the user.


> (1) - The C++/Boost (plus time.h etc) date/time options go on forever. I 
> don't begin to understand them all and it looks like c++20 is aiming to 
> revamp/extend a lot of it. Coding wise. I tried to stick mostly with c.

Yeah, it makes for fun reading. Especially the parts where you go, 
"yeah, you got THIS functionality here, and THAT functionality there, 
but all of this doesn't give me THAT THING I REALLY WANT, which should 
be far more trivial to implement than THIS and THAT?! And probably just 
as common a use case."

Case in point:

There are two functions to convert `std::time_t` to a `std::tm` 
structure: One giving you the UTC representation, the other giving you 
the local time representation.

There is also a function to convert a `std::tm` in local time 
representation to `time_t`.

But where is the **** function that will allow me to populate a 
`std::tm` with a UTC representation and convert *THAT* to `time_t`? That 
would have to be even easier to implement!
So how else do I get a `time_t` representation of 2000-01-01 00:00 UTC?!

And no, just casting 30 years' worth of seconds to `time_t` is NOT the 
proper way to do it folks, because `time_t` is NOT guaranteed to use 
POSIX representation. Not even in C++20.


I've now decided that the cleanest way of doing it (in pure C++11 
without boost anyway) may be to convert 2000-01-01 00:00 local time to 
`time_t`, convert that into UTC, convert that back again to `time_t` 
pretending it to be local time, compute the difference to the first 
`time_t` obtained, and subtract the result from that first `time_t`.

Behold - 2000-01-01 00:00 UTC as `time_t`. Easy as pi. Or half a tau. 
Anyway, irrational. Transcendental even.

[jr] Re: Call to Arms: Datetime [1701 days 15 hours and 33 minutes ago]

Wed, 11 Aug 2021 16:20:00 GMT

clipka <ano### [at] anonymousorg> wrote:
> Am 11.08.2021 um 14:29 schrieb jr:
>
> > I get, for Slackware 14.[12] systems, '(c)'; tried with 3.7.0.8 and 3.7.1 (alpha
> > and rc), and various 3.8.0, from alpha 9945627 to beta.1.  same for 3.7.0.8 on a
> > Debian VM.  all but Debian "unofficial" versions built from tarballs.
>
> How is beta.2 doing in this respect? Does that at least give (A) as
> intended?

have not yet downloaded/built beta.2, sorry.


> Also, can you dig up what version of boost is being used by POV-Ray in
> your case?

the Debian VM uses v1.67, on Slackware it's v1.54 + v1.59.


> Information about what time zone you've set up on your system would also
> be of interest (at least if it's very close to UTC; if it's far off,
> "not even close to UTC" is all I'd need to know).

v close, GMT.  currently on "British Summer Time" (Wed 11 Aug 17:15:45 BST
2021).


regards, jr.

[clipka] Re: Call to Arms: Datetime [1701 days 16 hours and 8 minutes ago]

Wed, 11 Aug 2021 15:45:17 GMT

Am 11.08.2021 um 14:29 schrieb jr:

> I get, for Slackware 14.[12] systems, '(c)'; tried with 3.7.0.8 and 3.7.1 (alpha
> and rc), and various 3.8.0, from alpha 9945627 to beta.1.  same for 3.7.0.8 on a
> Debian VM.  all but Debian "unofficial" versions built from tarballs.

How is beta.2 doing in this respect? Does that at least give (A) as 
intended?

Also, can you dig up what version of boost is being used by POV-Ray in 
your case?


Information about what time zone you've set up on your system would also 
be of interest (at least if it's very close to UTC; if it's far off, 
"not even close to UTC" is all I'd need to know).

[Alain Martel] Re: Call to Arms: Datetime [1701 days 16 hours and 15 minutes ago]

Wed, 11 Aug 2021 15:38:40 GMT

Le 2021-08-11 Ã  11:36, Alain Martel a Ã©critÂ :
> Le 2021-08-11 Ã  07:08, clipka a Ã©critÂ :
> 
>> Bonus questions:
>>
>> - Using genuine POV-Ray, have you ever, and beyond doubt, observed 
>> behavior (B) during times when DST was in effect in your time zone?
>>
>>
>> (Please disregard derivatives such as rpov in this test/poll. They 
>> have no impact whatsoever on the question I'm eager to get answers to.)
>>
>>
>> I have a hunch that I may have been looking in a completely wrong 
>> direction in this matter.
> 
> I get (C) using v3.8.0-x.freetype.3+AV693.MSVC14.windows, 64bits under 
> Windows 10.
> Local time ignoring DST with an appended Â«ZÂ».
My time zone is Eastern, MontrÃ©al, QuÃ©bec.

[Alain Martel] Re: Call to Arms: Datetime [1701 days 16 hours and 17 minutes ago]

Wed, 11 Aug 2021 15:36:01 GMT

Le 2021-08-11 Ã  07:08, clipka a Ã©critÂ :

> Bonus questions:
> 
> - Using genuine POV-Ray, have you ever, and beyond doubt, observed 
> behavior (B) during times when DST was in effect in your time zone?
> 
> 
> (Please disregard derivatives such as rpov in this test/poll. They have 
> no impact whatsoever on the question I'm eager to get answers to.)
> 
> 
> I have a hunch that I may have been looking in a completely wrong 
> direction in this matter.

I get (C) using v3.8.0-x.freetype.3+AV693.MSVC14.windows, 64bits under 
Windows 10.
Local time ignoring DST with an appended Â«ZÂ».

[clipka] Re: LDD to POV ? [1701 days 16 hours and 33 minutes ago]

Wed, 11 Aug 2021 15:19:49 GMT

Am 11.08.2021 um 16:36 schrieb Denver Dave:
> clipka <ano### [at] anonymousorg> wrote:
>> Am 07.08.2021 um 07:08 schrieb Denver Dave:
>>> 3.8 doesn't work with LDD - POV converter,
>>> but that's fine. Might be on the converter side.
>>
>> Can you be any more specific?
> 
> Well, v3.7 connects to converter thru callback
> as I understand it - 3.7 works fine, 3.8 does not.
> ( can't locate the ldd include files )

Maybe it's just a matter of setting up v3.8's master `povray.ini`?

v3.8 should be using its own dedicated copy of that file rather than 
sharing it with v3.7's, so you would need to set it up again if LDD 
needs anything to be done to it.

[clipka] Re: POV-Ray v3.8.0-beta 1 - Parse error using "%... [1701 days 16 hours and 42 minutes ago]

Wed, 11 Aug 2021 15:10:46 GMT

Am 11.08.2021 um 15:09 schrieb William F Pokorny:

> wrapper script. The latter (now)- with the original boost code does 
> return utc - but the %z %Z options in datetime don't work. Sticking with 
> v3.8 beta <n> as is - at least as far as my Ubuntu machine goes - is an 
> OK option I think.

Can you elaborate on the "%z %Z don't work"?

Note that placing `%z` or `%Z` in the string passed to `strftime()` 
doesn't magically alter how that function interprets the data it 
receives. It just inserts the identifier for whatever timezone the 
system has been configured to use, period. It is the responsibility of 
the software developer (which in this particular case and current state 
of affairs eventually means the scene author) to make sure that the data 
passed to `strftime()` is local time when using `%z` or `%Z` (or no 
timezone identifier at all, for that matter) and UTC when appending a 
literal `Z` to indicate UTC.

There is one additional caveat in that an additional data field needs to 
be set up properly in order for `%z` or `%Z` to print the proper 
timezone information when DST would be in effect at the point in time 
specified. If that is not done, the timezone printed will not properly 
adapt to DST.
Since the code was designed for UTC, the DST field was never really 
considered, and may be set up completely wrong.

If the "don't work" symptoms you observed can't be explained by either 
of the above caveats, then I'd like to learn more about it.


> Complete aside... I have a vague recollection of a compile time 
> environment variable for some compiler which let users select whether 
> std::time() - the 'c' time - would return utc or local time. But, maybe 
> it was a fever dream... :-)

Maybe what you remember was actually a preprocessor macro in some 
software package, to let it know what was implemented in the library?

The boost source code hints that an obscure IDE for embedded system 
development called Metrowerks CodeWarrior would use local time, rather 
than utc, throughout the date/time-related portions of its C library.

[Denver Dave] Re: LDD to POV ? [1701 days 17 hours and 13 minutes ago]

Wed, 11 Aug 2021 14:40:00 GMT

clipka <ano### [at] anonymousorg> wrote:
> Am 07.08.2021 um 07:08 schrieb Denver Dave:
> > 3.8 doesn't work with LDD - POV converter,
> > but that's fine. Might be on the converter side.
>
> Can you be any more specific?

Well, v3.7 connects to converter thru callback
as I understand it - 3.7 works fine, 3.8 does not.
( can't locate the ldd include files )

[clipka] Re: Call to Arms: Datetime [1701 days 17 hours and 34 minutes ago]

Wed, 11 Aug 2021 14:18:55 GMT

Am 11.08.2021 um 14:13 schrieb Thomas de Groot:
> I don't know if the following is answering your questions but anyway, 
> these are the versions I have currently accessible on my laptop:

Information about your actual time zone would have been helpful, but I 
have enough material to make an educated guess about that.

> The third one is deviant. No idea about "boost version".

When you start up POV-Ray for Windows, the initial message pane content 
will list the boost version close to the bottm. But with the Windows 
versions being distributed as binaries I can reconstruct that piece of 
information myself, so no worries there.

[William F Pokorny] Re: Call to Arms: Datetime [1701 days 18 hours and 39 minutes ago]

Wed, 11 Aug 2021 13:14:33 GMT

On 8/11/21 7:08 AM, clipka wrote:
> Bonus questions:
> 
> - Using genuine POV-Ray, have you ever, and beyond doubt, observed 
> behavior (B) during times when DST was in effect in your time zone?

No.

Bill P.

[William F Pokorny] Re: POV-Ray v3.8.0-beta 1 - Parse error using "%... [1701 days 18 hours and 44 minutes ago]

Wed, 11 Aug 2021 13:09:21 GMT

On 8/11/21 7:13 AM, clipka wrote:
> Am 28.07.2021 um 15:16 schrieb William F Pokorny:
> 
>> Just to toss it out there, for as long as I've used datetime(now) as in:
>>
>> #version 3.8;
>> #debug concat("v3.8 default -> ",datetime(now),"\n")
> 
> Can you put some estimate on "as long as I've used datetime(now)"? 
> Further back than 2019?

Guessing 2018 or there about - certainly your new c++11 code over the 
boost stuff - but I don't remember the exact timing. We could look at 
the commit messages I guess.

> 
> If so, can you remember whether you already got local time out of the 
> function back then, or whether it could originally have been UTC after all?

Yes, as I said in answer to Cousin_Ricky, I tripped myself up on using 
the v3.8 branch point for povr as v3.8 beta 1 due a screw up in my 
wrapper script. The latter (now)- with the original boost code does 
return utc - but the %z %Z options in datetime don't work. Sticking with 
v3.8 beta <n> as is - at least as far as my Ubuntu machine goes - is an 
OK option I think.

Other changes to now/datetime could wait for v4.0. But, I'm not sure 
what others see for v3.8.

Complete aside... I have a vague recollection of a compile time 
environment variable for some compiler which let users select whether 
std::time() - the 'c' time - would return utc or local time. But, maybe 
it was a fever dream... :-)

Bill P.

[William F Pokorny] Re: `datetime(now)` issue - suggestions for a so... [1701 days 18 hours and 56 minutes ago]

Wed, 11 Aug 2021 12:57:06 GMT

On 8/8/21 6:54 PM, clipka wrote:
> We have established that the `datetime(now)` combo is both currently 
> broken (on some systems), and has some shortcomings in its design (on 
> all systems, both broken and otherwise).
> 
> 
> I think the key issues in finding any satisfactory solution are the 
> following:
...

Suppose I'd lean toward (C.2) with (A.1) for what you've proposed.

FWIW.
----
In June I worked some on datetime() to support an internal always local 
clock now, but as importantly to make work the %z and %Z formatting 
options whether the fractional days were coming from now or being 
generated on the fly. The last bit, I failed initially to recall on 
mentioning the trailing 'Z' with a non utc time result.

Beyond the initial changes, I had plans for a new f_clock() internal 
function. Admittedly, my aim was in part to insulate povr from whatever 
'now' was doing, but there were additional reasons. Due your post, I've 
worked up an initial version of f_clock() much earlier than planned to 
test how crazy my plans were and to help clarify my thoughts.

---
In your preamble, you didn't mention 'now' being used as an SDL timing 
mechanism. It's something people do today and it carries risk with 
respect to any particular timing result. The reasons is we are using the 
system_clock for 'now' which can be updated at any time moving forward 
or backward - synchronization with time servers, etc.

We don't warn against timing use of 'now' in the documentation as far as 
I know. Perhaps we should?

In povr's f_clock() the up front returned time comes from steady_clock 
instead - which on my Ubuntu 20.04 machine appears to be a monotonic 
clock since the last reboot/boot.

Suppose the following povr SDL:

//---
#declare Fn_TimePt00 = function (sec_in_day) { now*sec_in_day }
#declare TimePt00 = f_clock(0,0,0);
#debug concat("f_clock(0,0,0) ",str(f_clock(0,0,0),9,9),"\n")
#for (I,0,3000000,1)
     #declare Dummy = 1.0;
#end
#declare Fn_TimePt01 = function (sec_in_day) { now*sec_in_day }
#declare TimePt01 = f_clock(0,0,0);
#debug concat("f_clock(0,0,0) ",str(f_clock(0,0,0),9,9),"\n")

#debug "\n"
#declare SecInDay = (24*60*60);
#debug concat("Fn_TimePt00 ",str(Fn_TimePt00(SecInDay),9,9),"\n")
#debug concat("Fn_TimePt01 ",str(Fn_TimePt01(SecInDay),9,9),"\n")
#debug concat("Fn_TimePt01 - Fn_TimePt00 ",
     str(Fn_TimePt01(SecInDay)-Fn_TimePt00(SecInDay),9,9),"\n")

#debug "\n"

#debug concat("TimePt00 ",str(TimePt00,9,9),"\n")
#debug concat("TimePt01 ",str(TimePt01,9,9),"\n")
#debug concat("TimePt01 - TimePt00 ",
     str(TimePt01-TimePt00,9,9),"\n")
#debug "\n"

#error "Parsing test. Stop early."
//---

The povr branch generates:

f_clock(0,0,0) 234835.462146713
Parsing 17764K tokens
f_clock(0,0,0) 234838.496408219

Fn_TimePt00 681978977.077232242
Fn_TimePt01 681978980.111495137
Fn_TimePt01 - Fn_TimePt00 3.034262896

TimePt00 234835.462139445
TimePt01 234838.496401535
TimePt01 - TimePt00 3.034262090

Of note for POV-Ray v3.8 and onward is that the Fn_TimePt00, Fn_TimePt00 
method for capturing time points should work in v3.8 beta 1, but it 
doesn't because when 'now' was added, the support for it was not added 
to parser_strings.cpp alongside pi, tau, etc. This a stand alone 'now' 
issue.

The other current return types from f_clock() are:

1 - Whole seconds to system wall clock since Y2K.
2 - Fractional days to system wall clock since Y2K (The povr 'now').
3 - Difference between machine epoch and y2k epoch in seconds.
4 - Convert local seconds since machine epoch to utc.

The second argument is whether to account for dst, or not, for types 1,2,3.

The third and last argument is the local seconds argument for return 
type utc. The method for this turned out uglier than hoped, though it 
appears to work.

I don't consider the form of f_clock final - in povr, as often as not, 
just trying outs ideas. A type to directly return seconds since machine 
epoch might be nice. Maybe other stuff. We'll see.

---
Putting more of the whole plan/implementation on the table because I see 
secondary 'concerns' such as POV-Ray's Y2K epoch not lining up with any 
unix like system I've ever used - all have been at Jan 1, 1970. This 
makes understanding the values POV-Ray is generating and using harder to 
work with.

Unix commands like date have some nice options:

date --date='TZ="America/Los_Angeles" 09:00 next Mon' +"%s"

but we cannot use the results directly in POV-Ray. Hmm, maybe an 
explicit unix time to y2k seconds type for f_clock...

---
I'll end with my view our 'now' is trying to be both a timer and a 
time/date input and I'm not sure these are completely compatible. Most 
of the time/date stuff which works for dst uses only seconds resolution 
as far as I know(1).

---
Aside:
Supposing datetime fixed to support %z %Z, and 'now' returning always a 
no dst utc or local time you can fairly easily adjust the fractional day 
value to account for dst of say an hour with:

#declare DSToffset = (1/24);

#debug concat("now + (1/24) ",
datetime(now+DSToffset,"%Y-%m-%d %H:%M:%S %z"),"\n")

#debug concat("now + (1/24) ",
datetime(now+DSToffset,"%Y-%m-%d %H:%M:%S %Z"),"\n")

FWIW.

Bill P.

(1) - The C++/Boost (plus time.h etc) date/time options go on forever. I 
don't begin to understand them all and it looks like c++20 is aiming to 
revamp/extend a lot of it. Coding wise. I tried to stick mostly with c.

[jr] Re: Call to Arms: Datetime [1701 days 19 hours and 23 minutes ago]

Wed, 11 Aug 2021 12:30:00 GMT

hi,

clipka <ano### [at] anonymousorg> wrote:
> Folks,
>
> regarding the `datetime(now)` issue, I need more information from you
> folks, to make sure I'm not hunting a phantom.
>
>
> As far as I can tell, there may be as many as three variants of behavior
> out there, with `datetime(now)` returning the current time as either...:
>
> (A) UTC time,
>
> (B) LOCAL time, properly respecting daylight savings time, or
>
> (C) LOCAL time, IGNORING daylight savings time,
>
> with all variants appending a literal "Z" (intended to indicate UTC, but
> being bonkers in cases (B) and (C)).

I get, for Slackware 14.[12] systems, '(c)'; tried with 3.7.0.8 and 3.7.1 (alpha
and rc), and various 3.8.0, from alpha 9945627 to beta.1.  same for 3.7.0.8 on a
Debian VM.  all but Debian "unofficial" versions built from tarballs.


regards, jr.

[Thomas de Groot] Re: Call to Arms: Datetime [1701 days 19 hours and 39 minutes ago]

Wed, 11 Aug 2021 12:13:42 GMT

I don't know if the following is answering your questions but anyway, 
these are the versions I have currently accessible on my laptop:

Using win10

v3.7.0 local time (daylight-saving): 13:36 datetime(now): 11:36:53Z

v3.8.0-alpha.9893777+av622.msvc14.win64 local time (daylight-saving): 
13:42 datetime(now): 11:42:52Z

v3.8.0-x.freetype.4+av723.msvc14.win64 local time (daylight-saving): 
13:47 datetime(now): 12:47:09Z

v3.8.0-beta.1+gh6.msvc14.win64 local time (daylight-saving): 13:51 
datetime(now): 11:51:38Z

v3.8.0-beta.2+gh7.msvc14.win64 local time (daylight-saving): 13:54 
datetime(now): 11:54:14Z

The third one is deviant. No idea about "boost version".

Thomas


Op 11-8-2021 om 13:08 schreef clipka:
> Folks,
> 
> regarding the `datetime(now)` issue, I need more information from you 
> folks, to make sure I'm not hunting a phantom.
> 
> 
> As far as I can tell, there may be as many as three variants of behavior 
> out there, with `datetime(now)` returning the current time as either...:
> 
> (A) UTC time,
> 
> (B) LOCAL time, properly respecting daylight savings time, or
> 
> (C) LOCAL time, IGNORING daylight savings time,
> 
> with all variants appending a literal "Z" (intended to indicate UTC, but 
> being bonkers in cases (B) and (C)).
> 
> 
> There are also two variants of the source code out there... well, 
> actually three by now:
> 
> (1) Some old boost-based source code;
> 
> (2) some newer C++11-based code; and
> 
> (3) a variant of (1) with a fix to enforce behavior (A).
> 
> 
> These variants were used in the following POV-Ray versions:
> 
> v3.7.0.0 - v3.8.0-alpha.10013324 (2019-01-14):
> Variant (1)
> 
> v3.8.0-alpha.10064268 (2019-02-19) - v3.8.0-alpha.11272893 (last alpha):
> Variant (2)
> 
> v3.8.0-beta.1:
> Variant (1) again
> 
> v3.8.0-beta.2:
> Variant (3)
> 
> 
> I need your help to test the different variants of the code (especially 
> (1) and (2)) on your machines, and let me know:
> 
> - What behavior you are observing for code variant (1);
> - what behavior you are observing for code variant (2);
> - what operating system you are using; and
> - what version of boost POV-Ray has been compiled with.
> 
> Bonus questions:
> 
> - Using genuine POV-Ray, have you ever, and beyond doubt, observed 
> behavior (B) during times when DST was in effect in your time zone?
> 
> 
> (Please disregard derivatives such as rpov in this test/poll. They have 
> no impact whatsoever on the question I'm eager to get answers to.)
> 
> 
> I have a hunch that I may have been looking in a completely wrong 
> direction in this matter.


-- 
Thomas

[clipka] Re: POV-Ray v3.8.0-beta 1 - Parse error using "%... [1701 days 20 hours and 39 minutes ago]

Wed, 11 Aug 2021 11:13:43 GMT

Am 28.07.2021 um 15:16 schrieb William F Pokorny:

> Just to toss it out there, for as long as I've used datetime(now) as in:
> 
> #version 3.8;
> #debug concat("v3.8 default -> ",datetime(now),"\n")

Can you put some estimate on "as long as I've used datetime(now)"? 
Further back than 2019?

If so, can you remember whether you already got local time out of the 
function back then, or whether it could originally have been UTC after all?

[clipka] Call to Arms: Datetime [1701 days 20 hours and 44 minutes ago]

Wed, 11 Aug 2021 11:08:47 GMT

Folks,

regarding the `datetime(now)` issue, I need more information from you 
folks, to make sure I'm not hunting a phantom.


As far as I can tell, there may be as many as three variants of behavior 
out there, with `datetime(now)` returning the current time as either...:

(A) UTC time,

(B) LOCAL time, properly respecting daylight savings time, or

(C) LOCAL time, IGNORING daylight savings time,

with all variants appending a literal "Z" (intended to indicate UTC, but 
being bonkers in cases (B) and (C)).


There are also two variants of the source code out there... well, 
actually three by now:

(1) Some old boost-based source code;

(2) some newer C++11-based code; and

(3) a variant of (1) with a fix to enforce behavior (A).


These variants were used in the following POV-Ray versions:

v3.7.0.0 - v3.8.0-alpha.10013324 (2019-01-14):
Variant (1)

v3.8.0-alpha.10064268 (2019-02-19) - v3.8.0-alpha.11272893 (last alpha):
Variant (2)

v3.8.0-beta.1:
Variant (1) again

v3.8.0-beta.2:
Variant (3)


I need your help to test the different variants of the code (especially 
(1) and (2)) on your machines, and let me know:

- What behavior you are observing for code variant (1);
- what behavior you are observing for code variant (2);
- what operating system you are using; and
- what version of boost POV-Ray has been compiled with.

Bonus questions:

- Using genuine POV-Ray, have you ever, and beyond doubt, observed 
behavior (B) during times when DST was in effect in your time zone?


(Please disregard derivatives such as rpov in this test/poll. They have 
no impact whatsoever on the question I'm eager to get answers to.)


I have a hunch that I may have been looking in a completely wrong 
direction in this matter.

[jr] Re: `datetime(now)` issue - suggestions for a so... [1703 days 15 hours and 48 minutes ago]

Mon, 9 Aug 2021 16:05:00 GMT

hi,

clipka <ano### [at] anonymousorg> wrote:
> Am 09.08.2021 um 12:53 schrieb jr:
>
> > a better suggestion would have been:
> >
> >    [locale]
> >    tz = {local|utc}
> >    lang = en_GB.utf8
> >
> > as you say, conf provides environment type info.  given that 'strftime()' uses
> > locale, a setting to provide a preference/default could be useful.  (POV-Ray
> > appears to use the locale already, anyway)
>
> No, that's not really it.
>
> You don't need to tell POV-Ray whether your system HAS a time zone or
> not. Because your system DOES, period. Even if that timezone happens to
> be UTC.

:-)  ("divided by a common language")


> In the context of the issue, you have to tell POV-Ray whether you want
> to operate in the context of that time zone, or rather prefer to operate
> in a context that is universal across time zones.

exactly.  hence tell POV-Ray, in .conf ideally, what the system/user preference
is, ie whether 'now' ought to mean "local" or "utc", unless overridden.


> ...
> As I said, the INI file mechanism would be the way to go for such purposes.

perhaps.


regards, jr.

[clipka] POV-Ray v3.8.0-beta.2 [1703 days 18 hours and 41 minutes ago]

Mon, 9 Aug 2021 13:11:56 GMT

Almost made it within 4 weeks:

https://github.com/POV-Ray/povray/releases/tag/v3.8.0-beta.2


Let us know of any gripes you may have with that version.

Also, feel free to remind us of any gripes you had with the previous 
beta that haven't been addressed satisfactorily yet (I'm quite sure 
there are some).

Pro Tip: A GitHub issue report 
(https://github.com/POV-Ray/povray/issues) is the best way to make sure 
we're keeping proper tabs on whatever your gripe may be.


Happy Testing!

[Mr] Re: POV-Ray v3.8.0-beta.1 issue #410 [1703 days 19 hours and 28 minutes ago]

Mon, 9 Aug 2021 12:25:00 GMT

clipka <ano### [at] anonymousorg> wrote:

> And to be frank, the GitHub infrastructure around the repo has been
> quite an asset in the development work ever since. With the manpower
> available to us, it would have been impossible to set up (let alone
> maintain!) anything even remotely like it on our own turf.
[...]
> We also got some feedback and contributions via GitHub that we might not
> have gotten otherwise. Certainly not on as large a scale as in CompuServ
> times, but still.
>
> Among those who got into touch with us were the folks who maintain the
> "homebrew" packages to provide *NIX software for MacOS. Which put
> official MacOS compatibility back on the menu, after it had already
> dropped off the back of the truck in the years prior.
[...]

> The issue tracker also proved useful, if only because it meant we no
> longer had to waste time keeping spammers out of our self-hosted bug
> tracker.
[...]
> And a developers' manual, just because we could. I had already set up a
> few scripts and configs for that purpose years ago for my own use, but
> never got around to setting up a channel for publishing the generated
> documents.
[...]
> Even whether beta.1 would be out yet, without GitHub's ease of deploying
> software, is anybody's guess. It might still be in the pipeline between
> me and Chris Cason. Or I might still be procrastinating about even
> actually running the build process on my local machine. Having GitHub
> run it is so much easier and leaves far less room for PEBCAK errors,
> once the process has been set up.
>
>
> There's no fault in being somewhat suspicious of 3rd party services like
> GitHub. But let that not blind you to their benefits.
>
> Division of labour has been one of the most efficient strategies in the
> history of humanity, and this is just another application of that principle.

Thanks for taking the time to explicit all of this ! I wasn't aware that a (3.7)
Homebrew package was available and just added it to the informal wiki
page(https://wiki.povray.org/content/HowTo:Install_POV#Mac_OS.2FX). May we send
the maintainers for it some kind of notification /request about the 3.8 alpha ?

[clipka] Re: `datetime(now)` issue - suggestions for a so... [1703 days 19 hours and 50 minutes ago]

Mon, 9 Aug 2021 12:02:52 GMT

Am 09.08.2021 um 13:56 schrieb clipka:

>> Would it be a bad thing to have localtime (), utctime (), and timezone 
>> () as
>> completely separate functions?
> 
> If you can describe a system of such functions that works consistently, 
> and is reasonably foolproof to use, then I'd be happy to take it into 
> consideration.

(Also, remember that `now` and `datetime` already exist, and we should 
make at least some good faith effort to make them consistent - both with 
respect to themselves, as well as each other, and any additional time 
related stuff we may want to add - and rid them from any undesired 
quirks if possible.)

[clipka] Re: `datetime(now)` issue - suggestions for a so... [1703 days 19 hours and 57 minutes ago]

Mon, 9 Aug 2021 11:56:38 GMT

Am 09.08.2021 um 13:17 schrieb Bald Eagle:

>> - The current broken variant of the behavior has been around for quite a
>> while, and people have been using it. From their perspective, the only
>> thing wrong about the broken behavior is that there's a trailing "Z"
>> behind the default date/time strings generated.
> 
> Why not keep it the way it is an have an option/flag for removing the Z?

Because the current status is inconsistent. It currently does different 
things on different systems.

Just adding a flag to suppress the trailing "Z" seems a bit daft to me, 
as it just dumps all the responsibility into the user's lap to get 
things working properly, when we could just as well implement a 
mechanism that does everything right out of the box, while not being any 
more complex - from the user's point of view.


> Gotta head out in a few, so only briefly:
> A lot of this seems complicated, and I personally dislike too many options and
> settings.

Maybe you're confuzzled by the fact that I've described impementation 
details, not just what the user sees in a standard use case.


> Would it be a bad thing to have localtime (), utctime (), and timezone () as
> completely separate functions?

If you can describe a system of such functions that works consistently, 
and is reasonably foolproof to use, then I'd be happy to take it into 
consideration.

As it currently stands, this sounds like a system with a couple of 
building blocks but no mortar to properly tie them together, so the user 
has to mix their own and hope that it's suited for the task.

Pitfalls are plenty in the world of time and timezones, so I'd prefer 
users not have to worry about it themselves (unless they know what they 
are doing and consciously decide to do their own worrying).


> No idea what to do about daylight savings time
> since it's such a bad idea that there are people organizing and petitioning to
> get rid of it all together.

For the time being (no pun intended), daylight savings time does exist 
as an undeniable fact of life we have to put up with. If we try to 
ignore it, we will produce a program that breaks at least half of the 
time in half of the world.

[clipka] Re: `datetime(now)` issue - suggestions for a so... [1703 days 20 hours and 20 minutes ago]

Mon, 9 Aug 2021 11:33:01 GMT

Am 09.08.2021 um 12:53 schrieb jr:

> a better suggestion would have been:
> 
>    [locale]
>    tz = {local|utc}
>    lang = en_GB.utf8
> 
> as you say, conf provides environment type info.  given that 'strftime()' uses
> locale, a setting to provide a preference/default could be useful.  (POV-Ray
> appears to use the locale already, anyway)

No, that's not really it.

You don't need to tell POV-Ray whether your system HAS a time zone or 
not. Because your system DOES, period. Even if that timezone happens to 
be UTC.

In the context of the issue, you have to tell POV-Ray whether you want 
to operate in the context of that time zone, or rather prefer to operate 
in a context that is universal across time zones.

And that doesn't differ based on what system you're running POV-Ray on. 
It differs based on what you want to do with POV-Ray.


As for specifying _details_ about the locale, such as the actual time 
zone, language or whatnot, that isn't much of a thing either. Your 
system has a default locale, and there's a standard interface for making 
use of that. And there's little to no point in using a different one for 
POV-Ray (except possibly on a per-scene basis, but in that case 
`povray.conf` wouldn't be the right place anyway).


>> Also, it is definitely a setting that individual scenes should be able
>> to override. ...
> 
> sure, thought setting a convenient default, and override in 'datetime()'s second
> arg, if required.

As I said, the INI file mechanism would be the way to go for such purposes.

[Bald Eagle] Re: `datetime(now)` issue - suggestions for a so... [1703 days 20 hours and 33 minutes ago]

Mon, 9 Aug 2021 11:20:00 GMT

> - The current broken variant of the behavior has been around for quite a
> while, and people have been using it. From their perspective, the only
> thing wrong about the broken behavior is that there's a trailing "Z"
> behind the default date/time strings generated.

Why not keep it the way it is an have an option/flag for removing the Z?

Gotta head out in a few, so only briefly:
A lot of this seems complicated, and I personally dislike too many options and
settings.

Would it be a bad thing to have localtime (), utctime (), and timezone () as
completely separate functions?  No idea what to do about daylight savings time
since it's such a bad idea that there are people organizing and petitioning to
get rid of it all together.

[jr] Re: `datetime(now)` issue - suggestions for a so... [1703 days 20 hours and 58 minutes ago]

Mon, 9 Aug 2021 10:55:00 GMT

hi,

clipka <ano### [at] anonymousorg> wrote:
> Am 09.08.2021 um 09:07 schrieb jr:
> > hi,
> >
> > clipka <ano### [at] anonymousorg> wrote:
> >> We have established that the `datetime(now)` combo is both currently
> >> broken (on some systems), and has some shortcomings in its design (on
> >> all systems, both broken and otherwise).
> >>
> >>
> >> I think the key issues in finding any satisfactory solution are the
> >> following:
> >> ...
> >
> > could make a "fine" setting for 'povray.conf', eg:
> >
> >    [timezone]
> >    ; local
> >    utc
>
> I disagree.

I do too, now.  :-)

> `povray.conf` is there to tie the *NIX front-end(!) of your POV-Ray
> installation in to your *NIX run-time environment, and nothing more.
> Mainly to let the binary know where to find its auxiliary files
> (includes, primarily), and what directories never to access even if a
> scene says pretty please with a cherry on top.

a better suggestion would have been:

  [locale]
  tz = {local|utc}
  lang = en_GB.utf8

as you say, conf provides environment type info.  given that 'strftime()' uses
locale, a setting to provide a preference/default could be useful.  (POV-Ray
appears to use the locale already, anyway)


> There's also no such file in POV-Ray for Windows; such information is
> handled entirely differently there.

ok, did not know that.


> Also, it is definitely a setting that individual scenes should be able
> to override. ...

sure, thought setting a convenient default, and override in 'datetime()'s second
arg, if required.


regards, jr.

[clipka] Re: `datetime(now)` issue - suggestions for a so... [1703 days 22 hours and 33 minutes ago]

Mon, 9 Aug 2021 09:20:18 GMT

Am 09.08.2021 um 09:07 schrieb jr:
> hi,
> 
> clipka <ano### [at] anonymousorg> wrote:
>> We have established that the `datetime(now)` combo is both currently
>> broken (on some systems), and has some shortcomings in its design (on
>> all systems, both broken and otherwise).
>>
>>
>> I think the key issues in finding any satisfactory solution are the
>> following:
>> ...
> 
> could make a "fine" setting for 'povray.conf', eg:
> 
>    [timezone]
>    ; local
>    utc

I disagree.

`povray.conf` is there to tie the *NIX front-end(!) of your POV-Ray 
installation in to your *NIX run-time environment, and nothing more. 
Mainly to let the binary know where to find its auxiliary files 
(includes, primarily), and what directories never to access even if a 
scene says pretty please with a cherry on top.

There's also no such file in POV-Ray for Windows; such information is 
handled entirely differently there.

Also, it is definitely a setting that individual scenes should be able 
to override. Because in the end it will usually be the scene author who 
knows best whether they want some date or time displayed in their scene 
in local or UTC format - and it might change from scene to scene, or 
even between different portions of the scene.

If anything, one could argue that there should be an INI setting to 
specify the default, which in turn would make it configurable globally 
via the master `povray.ini`.

But the more places we want to add to tweak the setting, the more work 
it is to implement, and for the time being I'd like to keep it simple, 
and leave the implementation of such an INI default as an exercise to 
the reader, so to speak.

[jr] Re: `datetime(now)` issue - suggestions for a so... [1704 days and 43 minutes ago]

Mon, 9 Aug 2021 07:10:00 GMT

hi,

clipka <ano### [at] anonymousorg> wrote:
> We have established that the `datetime(now)` combo is both currently
> broken (on some systems), and has some shortcomings in its design (on
> all systems, both broken and otherwise).
>
>
> I think the key issues in finding any satisfactory solution are the
> following:
> ...

could make a "fine" setting for 'povray.conf', eg:

  [timezone]
  ; local
  utc


regards, jr.

[jr] Re: POV-Ray v3.8.0-beta.1 issue #410 [1704 days and 43 minutes ago]

Mon, 9 Aug 2021 07:10:00 GMT

hi,

ingo <ing### [at] tagpovrayorg> wrote:
> in news:web.610ef2315f6dda2a5e0fed26cde94f1@news.povray.org jr wrote:
>
> > fwiw: <https://www.fossil-scm.org/home/doc/trunk/www/fossil-v-git.wiki>
> >
>
> :) I've been using it a lot for years now. ...

</tap-nose>  :-)


regards, jr.

[clipka] Re: `datetime(now)` issue - suggestions for a so... [1704 days 8 hours and 40 minutes ago]

Sun, 8 Aug 2021 23:12:51 GMT

Am 09.08.2021 um 00:54 schrieb clipka:

> I hereby present the following alternative approaches as possible 
> solutions:

My personal preferences lean heavily towards (A), with a perspective to 
change over to (A.1) later if daylight savings time does indeed turn out 
to be a problem.

(A) explicitly includes provisions to let people know that the `local` 
mode may still be subject to change, for this exact reason.


The reason for any DST issues would be that, in order for stuff to work 
nicely, the time zone of the timestamp "zero point" (2000-1-1 00:00) 
probably needs to match the time zone applicable for (a) the point in 
time represented by the timestamp, or (b) the point in time at which the 
scene is parsed (and I'm not sure which of the two). Either way, since 
2000-1-1 is outside the DST period for most time zones, there is reason 
to expect things to break down when invoking `datetime(now)` during the 
DST period, since the DST time zone typically doesn't match the regular 
time zone.

Since UTC does not have a DST variant, this is a non-issue if our 
numeric timestamps are always UTC-based.

[clipka] `datetime(now)` issue - suggestions for a solution [1704 days 8 hours and 59 minutes ago]

Sun, 8 Aug 2021 22:54:37 GMT

We have established that the `datetime(now)` combo is both currently 
broken (on some systems), and has some shortcomings in its design (on 
all systems, both broken and otherwise).


I think the key issues in finding any satisfactory solution are the 
following:


- The current broken variant of the behavior has been around for quite a 
while, and people have been using it. From their perspective, the only 
thing wrong about the broken behavior is that there's a trailing "Z" 
behind the default date/time strings generated.

- Probably the most common use case for the `datetime(now)` combo would 
ideally have it report local time (matching the broken behavior), rather 
than UTC as originally intended and documented.

- Aside from this combo, the use cases for the `now` pseudo-variable may 
actually give more weight for UTC-based behavior.

- It would be excessively complex to make the `now` pseudo-variable 
convey timezone information to `datetime` (especially considering that 
one might want to do arithmetics on it first, or store it in another 
variable, or any other scenario where it would have to have numeric 
value semantics).

- We can't have both at the same time.


I hereby present the following alternative approaches as possible solutions:


(A) Timezone Global Setting
---------------------------

- A `timezone` global setting is added, with possible values being 
either `local` or `utc`.

- In `local` mode, `now` returns a local time based value on all 
systems, and the `datetime` format string defaults to `%Y-%m-%d 
%H:%M:%S` (note the absence of any time zone specifier whatsoever; see 
notes below for reasons).

- In `utc` mode, `now` returns a UTC based value on all systems, and the 
`datetime` format string defaults to `%Y-%m-%d %H:%M:%SZ` (as it 
currently does; note the presence of a literal "Z" time zone specifier 
to explicitly indicate UTC).

- For now, choosing `timezone local` will prompt a warning that the 
behavior with respect to daylight savings time needs further testing, 
may be subject to change, and is to be regarded as experimental.

- If `timezone` is not explicitly specified, it will default to `utc` 
(being the originally intended and documented behavior), with the first 
use of `now` or `datetime` prompting a warning that the behavior may not 
be as expected.

- In deviation of the above, if `#version 3.7` is specified, and in the 
absence of an explicit `timezone` setting, the behavior of `now` and 
`datetime` will match the current behavior (i.e. `now` will exhibit 
`utc` or `local` mode behavior depending on platform, while `datetime` 
will invariably exhibit `utc` mode behavior), and the warning will be 
somewhat different, in that it will indicate that the behavior is 
specifically for backward compatibility and may lead to bogus results on 
some systems and/or unexpected results on others.

- Switching between modes will be supported, but since values obtained 
from `now` in one mode would lead to bogus results when used in 
`datetime` (with default format string) in the other mode, a warning 
will be issued if there is any switch between a use of `now` and a 
subsequent use of `datetime` without an explicit format string.


NOTES:

- The most common `local` mode use cases presumably don't need an 
explicit time zone specifier, so including a trailing "%z" or "%Z" in 
the default format string would only unnecessarily add another instance 
of time zone handling that could turn out to have pitfalls of its own. 
Users who need such information are still free to include such suffixes 
by specifying a custom format string.

PROS:

- The default `datetime` format string is automatically adapted to 
whatever mode the user chooses.

CONS:

- It might turn out that `local` mode can't be made to work properly due 
to issues related to daylight savings time.

VARIANTS:

(A.1) Alternatively, `now` could be implemented to always return UTC 
based values, with `datetime` instead automatically adding a timezone 
offset when in `local` mode. This variant should be safe from potential 
daylight saving times issues, and the mode could be switched at will 
without exercising any extra caution. However, it would also mean the 
user couldn't easily probe for the time zone offset.


(B) Timezone Pseudo-Variable
----------------------------

- A `timezone` pseudo-variable is added, evaluating to the timezone 
offset to UTC in fractions of a day.

- `now` will be fixed to return a UTC based value on all systems (unless 
`#version 3.7` is specified, in which case behavior will be as currently 
implemented, while prompting a warning if the result differs from fixed 
behavior),

- `datetime` will continue to work as currently implemented, i.e. using 
a string that implies an UTC-based timestamp. A warning might be issued 
if no explicit format string specified and the timestamp parameter is 
anything other than pure `now`.

- Local date/time strings can thus be generated using 
`datetime(now+timezone,FORMAT)`


PROS:

- No switching between modes needed.
- The solution should be immune to daylight savings time issues.

CONS:

- The value of the timezone variable would have unexpected units (days 
instead of hours).
- Getting local date/time strings would always require am explicit 
format string.

VARIANTS:

(B.1) Have `datetime` default to specifying no timezone information 
whatsoever. This variant would avoid the need to specify an explicit 
format string to produce proper local date/time strings. However, it 
would produce misleading results for `datetime(now)` as the absence of a 
timezone specifier would erroneously imply local time when it would 
actually be UTC.

(B.2) Have `now` return local time instead of UTC, and use 
`now-timezone` to get UTC. This variant would avoid the need to specify 
an explicit format string to produce proper local date/time strings, 
while still getting sane (albeit local time) results from 
`datetime(now)`. However, this approach might turn out to not work 
properly due to potential daylight savings time issues.


(C) Datetime mode parameter
---------------------------

This approach is somewhat similar to (A.1):

- `now` will be fixed to return a UTC based value on all systems (unless 
`#version 3.7` is specified, in which case behavior will be as currently 
implemented, while prompting a warning if the result differs from fixed 
behavior),

- An optional timezone mode parameter is added to `datetime`, with 
possible values being either `local` or `utc`, the default being `utc`.

- In `local` mode, `datetime` automatically adds a timezone offset to 
the timestamp parameter (which is always presumed to be based on UTC), 
and the format string defaults to `%Y-%m-%d %H:%M:%S` (note the absence 
of any time zone specifier whatsoever).

- In `utc` mode, `datetime` takes the timestamp parameter as-is, and the 
format string defaults to `%Y-%m-%d %H:%M:%SZ` (as it currently does; 
note the presence of a "Z" time zone specifier to explicitly indicate UTC).


PROS:

- The default `datetime` format string is automatically adapted to 
whatever mode the user chooses.
- The solution should be immune to daylight savings time issues.

CONS:

- The presumably more frequent use case, `local` mode, would always 
require to specify the mode parameter.

VARIANTS:

(C.1) The default of the mode parameter could be specified to be `local` 
rather than `utc`. This would avoid the need to explicitly specify the 
parameter in the presumably more common `local` use case. However, for 
backward compatibility it would require that `datetime` behave 
differently when `#version 3.7` is specified, and would still require 
specifying the mode parameter each time `utc` mode is desired.

(C.2) This approach could be combined with (A.1), using the global 
setting as the default when `datetime` is used without an explicit mode 
parameter. This would avoid the need to explicitly specify the parameter 
each time `local` mode is desired, while at the same also avoiding the 
need to make `datetime` behavior subject to `#version` setting.

[ingo] Re: POV-Ray v3.8.0-beta.1 issue #410 [1704 days 11 hours and 7 minutes ago]

Sun, 8 Aug 2021 20:46:10 GMT

in news:web.610ef2315f6dda2a5e0fed26cde94f1@news.povray.org jr wrote:

> fwiw: <https://www.fossil-scm.org/home/doc/trunk/www/fossil-v-git.wiki>
> 

:) I've been using it a lot for years now. Every ctrl-S from many 
programms or crtl-B from the editor creates a new entry in the proper 
fossil. 

-- 
https://ingoogni.nl

[clipka] Reasons (was: Re: POV-Ray v3.8.0-beta.1 issue #4... [1704 days 23 hours and 36 minutes ago]

Sun, 8 Aug 2021 08:17:25 GMT

Am 07.08.2021 um 22:50 schrieb jr:

> fwiw: <https://www.fossil-scm.org/home/doc/trunk/www/fossil-v-git.wiki>

Judging by that description, it looks like it would actually have been 
an inferior choice for us.

POV-Ray has a tradition of being forked, for various purposes, and we 
see that as something to be encouraged. Notable examples from the past 
include MegaPOV, MCPov, and that Special Relativity version of POV-Ray 
someone once made. Post-v3.7 examples include UberPOV, Hgpovray(*), 
qtpov and rpov.

I can't speak for the other fork authors, but to me as the author of 
UberPOV, the simplicity with which changes from official POV-Ray could 
be merged in on a semi-regular basis, while at the same time preventing 
UberPOV's own changes to spill back into the official POV-Ray repo, was 
a great help, and an encouraging factor in the decision to even start 
that fork in the first place. And I guess other people's experience is 
similar (*Hgpovray being an exception here, as the author deliberately 
chose to use a versioning system he's more familiar with).


Some additional points where Fossil would be a poor choice:

- "Drive-by contributions" is something we want to encourage, not 
discourage.

- "Trust over hierarchy" is a luxury we can't afford: POV-Ray's internal 
architecture is so convoluted and complex, our goals of what we want 
that architecture to eveolve into so different from the current status, 
and the road there so vaguely visible, that it is unreasonable to expect 
even the best developers to reliably make good design decisions when 
developing fixes, features or whatever. So no matter how much trust we 
place in their integrity and capabilities, it is prudent we don't just 
accept the result of their work based on implicit trust alone.

[jr] Re: POV-Ray v3.8.0-beta.1 issue #410 [1705 days 10 hours and 58 minutes ago]

Sat, 7 Aug 2021 20:55:00 GMT

hi,

clipka <ano### [at] anonymousorg> wrote:
> ...
> Fossil? The first time I've ever heard of it was when you just brought
> it up.

a bit like music, there's always artists one has never heard of :-).

fwiw: <https://www.fossil-scm.org/home/doc/trunk/www/fossil-v-git.wiki>


regards, jr.

[Ash Holsenback] Re: POV-Ray v3.8.0-beta.1 issue #410 [1705 days 16 hours and 43 minutes ago]

Sat, 7 Aug 2021 15:10:32 GMT

On 8/7/21 9:26 AM, Chris Cason wrote:
> On 7/08/2021 19:58, Ash Holsenback wrote:
>> curator role that i didn't really sign up for. hell...  i /still/ need 
>> to finish debugging the php / mysql changes to wikidocgen ( after 
>> server crash ) so that ought to be a clue as to my motivation.
> 
> I can take a look at that if you like. Was going to spend Sunday doing 
> server maintenance.
> 
> -- Chris

appreciate the offer... i'll manage. my only excuse is being lazy.

[Chris Cason] Re: POV-Ray v3.8.0-beta.1 issue #410 [1705 days 18 hours and 26 minutes ago]

Sat, 7 Aug 2021 13:26:45 GMT

On 7/08/2021 19:58, Ash Holsenback wrote:
> curator role that i didn't really sign up for. hell...  i /still/ need 
> to finish debugging the php / mysql changes to wikidocgen ( after server 
> crash ) so that ought to be a clue as to my motivation.

I can take a look at that if you like. Was going to spend Sunday doing 
server maintenance.

-- Chris

[clipka] Re: POV-Ray v3.8.0-beta.1 issue #410 [1705 days 18 hours and 45 minutes ago]

Sat, 7 Aug 2021 13:08:17 GMT

Am 07.08.2021 um 11:58 schrieb Ash Holsenback:
> On 8/6/21 1:46 PM, clipka wrote:
>> To cram that content into the Wiki would have required writing import 
>> scripts. And I have 0 - zero, zilch - knowledge about the Wiki import 
>> format, while presumably Jim has just as much knowledge about the 
>> format generated by said tool (beyond the fact that it's HTML, of 
>> course).
> 
> don't even /try/ to involve me. haven't you guys noticed that i've not 
> been replying to the documentation updates / corrections that y'all have 
> been flinging over the wall. i've been trying to step away from the 
> curator role that i didn't really sign up for. hell...  i /still/ need 
> to finish debugging the php / mysql changes to wikidocgen ( after server 
> crash ) so that ought to be a clue as to my motivation.

Sounds like great fun...
Not.

Don't worry, all I wanted to hint at was that even the two people who 
would know most about the matter are nowhere close to a position of just 
flicking a switch and magically importing those developers' docs into 
the Wiki. And that therefore, given all the other considerations 
besides, it makes no sense whatsoever to invest any time into even trying.

[Chris Cason] Re: POV-Ray v3.8.0-beta.1 issue #410 [1705 days 19 hours and 29 minutes ago]

Sat, 7 Aug 2021 12:24:19 GMT

On 7/08/2021 18:12, clipka wrote:
> Did I mention that I do not have access to the POV-Ray web server? Nor 
> do I really care to get such access. It's not the kind of work I want to 
> put on my plate. I'm no good at it.

Yeah I don't blame you. Before the crash the old system was hanging on 
with chewing gum and sticky-tape. Now that we're up to date with all the 
latest libs and PHP version it's a little more amenable to having 
another person edit stuff, but it's still very much a case of 'ssh into 
the server and edit the PHP pages with VI'. All pages require 
interleaving of PHP and HTML as the website theme and individual page 
sections are pulled in from a common PHP library.

Oh, and there's no staging environment so all edits go live instantly 
:). If I forget to close a PHP statement or leave off a semicolon the 
entire page breaks (or the entire site if it's one of our include files ...)

I could set up a staging environment now that I've got plenty of disk 
space and have started managing the website with git, but I didn't think 
there was a pressing need (and your above comment confirms that).

-- Chris

[Warren] Re: Windows XP compatibility [1705 days 21 hours and 43 minutes ago]

Sat, 7 Aug 2021 10:10:00 GMT

clipka <ano### [at] anonymousorg> wrote:
> Am 06.08.2021 um 21:04 schrieb Warren:
>

> Also, I may be misunderstanding things, but I presume CMake does not
> natively cater to a project that has, in some sense, completely
> different applications for different target platforms, which "only"
> share a common core.

You can mark out parts in a 'CMakeLists.txt' file like for example:

if( UNIX )
//Do these things only for Unix OSes
endif( UNIX )

if( WIN32 )
//Only for Windows OSes
endif( WIN32 )

And you also can make sub project like I do for the games I'm currently
developping like in this tree example: (directory based interpretation)

CMakeLists.txt in main project directory
|
|--'editor' sub directory that contains also a 'CMakeLists.txt' file that
generates an executable based partly on some others static libraries below, to
edit levels for the game
|--'inGame' sub directory that contains a 'CMakeLists.txt' that will build a
static library which is the game core
|--sdl2_wrapper : another static library that wraps the well known SDL2 library
so that it becomes RAII / RFID compliant ( C++ )
|--'game' generates the game excutable based on other libraries

That said I agree with you when you say CMake for now, can't generate a build
process based on a directory that may contains all the sources. But I make up
for that with a couples of commands in Ubuntu in a script shell:

#!/bin/bash
#List the sources and headers of 'inGame' directory
#
find ../sources/inGame -type f -name "*.h" > lists/inGameHeaders.txt
find ../sources/inGame -type f -name "*.cpp" > lists/inGameSources.txt
#
sed 's#../sources/inGame/#\t\t#g' -i lists/inGame*.txt

The last sed command adds two tabulation chars ('\t') so that when I paste the
txt file content , I have a suitable indentation.
And as concrete example here is a simple CMakeLists.txt :

cmake_minimum_required(VERSION 3.8)

project("game_${SQUARE_SIZE}" LANGUAGES CXX)

if(UNIX)
 include(GNUInstallDirs)
endif(UNIX)

set(HEADERS
  sources/generic/loadings/makeTextTextures.h
  sources/levels/contexts/demoLevel.h
  #This is a comment
  #Other files there
)

set(SOURCES
  sources/generic/loadings/makeTextTextures.cpp
  sources/levels/contexts/level.cpp
  #This is a comment
  #Other files there
)

add_executable( ${PROJECT_NAME}
    WIN32
    ${SOURCES}
    ${HEADERS}
    ${INC_DIRS}
)

target_include_directories(${PROJECT_NAME}
        PUBLIC ${SDL2_INCLUDE_DIRS}
        PUBLIC ${SDL2_IMAGE_INCLUDE_DIRS}
        PUBLIC ${SDL2_TTF_INCLUDE_DIRS}
        PUBLIC ${SDL2_MIXER_INCLUDE_DIRS}
        PUBLIC sources
        PUBLIC ../commonFiles/sources
        PUBLIC ../generic/sources
        PUBLIC ../inGame/sources
)

target_link_libraries( ${PROJECT_NAME}
      ${SDL2_LIBRARIES}
      ${SDL2_IMAGE_LIBRARIES}
      ${SDL2_TTF_LIBRARIES}
      ${SDL2_MIXER_LIBRARIES}
      "mercenaries_common_${SQUARE_SIZE}"
      "mercenaries_generic_${SQUARE_SIZE}"
      "mercenaries_inGame_${SQUARE_SIZE}"
)

set_target_properties( ${PROJECT_NAME}
      PROPERTIES
      CXX_STANDARD 20
      CXX_STANDARD_REQUIRED YES
      CXX_EXTENSIONS ON
      LINKER_LANGUAGE CXX
)

if( UNIX )
 math(EXPR SCREENWIDTH "${SQUARE_SIZE} * 20" OUTPUT_FORMAT DECIMAL )
 install(TARGETS ${PROJECT_NAME}
  RUNTIME DESTINATION
"/media/antoine/projetsLinux/final/MercenariesProject/Mercenaries${SCREENWIDTH}"
 )
endif(UNIX)

//-----------------End of CMakeLists.txt file
If you wonder what '${SQUARE_SIZE}' stands for, this is the logical size of a
tile in my game. In fact I use a combination of bash script files and povray to
make all textures in my game according to a given size of Tiles textures (the
size is passed to every shell scripts that compute the final size of the povray
image size that renders). Only one script to run and then some hours later, all
the textures I want are created. All I have to do then is to compile the
binaries with the same tile size that I give while running 'cmake' in command
line later.

[Ash Holsenback] Re: POV-Ray v3.8.0-beta.1 issue #410 [1705 days 21 hours and 55 minutes ago]

Sat, 7 Aug 2021 09:58:05 GMT

On 8/6/21 1:46 PM, clipka wrote:
> To cram that content into the Wiki would have required writing import 
> scripts. And I have 0 - zero, zilch - knowledge about the Wiki import 
> format, while presumably Jim has just as much knowledge about the format 
> generated by said tool (beyond the fact that it's HTML, of course).

don't even /try/ to involve me. haven't you guys noticed that i've not 
been replying to the documentation updates / corrections that y'all have 
been flinging over the wall. i've been trying to step away from the 
curator role that i didn't really sign up for. hell...  i /still/ need 
to finish debugging the php / mysql changes to wikidocgen ( after server 
crash ) so that ought to be a clue as to my motivation.

[clipka] Re: LDD to POV ? [1705 days 23 hours and 40 minutes ago]

Sat, 7 Aug 2021 08:13:24 GMT

Am 07.08.2021 um 07:08 schrieb Denver Dave:
> 3.8 doesn't work with LDD - POV converter,
> but that's fine. Might be on the converter side.

Can you be any more specific?

[clipka] Re: POV-Ray v3.8.0-beta.1 issue #410 [1705 days 23 hours and 41 minutes ago]

Sat, 7 Aug 2021 08:12:07 GMT

Am 07.08.2021 um 09:23 schrieb jr:

>>>> And a developers' manual...
...
>> To cram that content into the Wiki would have required writing import
>> scripts. And I have 0 - zero, zilch - knowledge about the Wiki import
>> format, while presumably Jim has just as much knowledge about the format
>> generated by said tool (beyond the fact that it's HTML, of course).
> 
> well, adding a link to the "suite of full-fledged HTML pages" certainly would
> not be too .. taxing.

It still requires to put that army of HTML pages _somewhere_ first.

Did I mention that I do not have access to the POV-Ray web server? Nor 
do I really care to get such access. It's not the kind of work I want to 
put on my plate. I'm no good at it.


>>> sure.  true also of alternatives, like eg 'fossil'.
>>
>> Now I think you're confusing the technological platform (such as Git)
>> with a particular service based on that platform (such as GitHub).
> 
> perhaps, though it seems comparable to me.

Not really.

Technically, they might not differ that much.

In terms of how widespread they are though (and therefore how familiar 
potential contributors might be with them, and how easy it might be to 
find a compatible tool that they would feel comfortable using), Git and 
Fossil are worlds apart.

You can't take two steps in open source development these days without 
stumbling across Git. There's not a single modern development tool out 
there without at least one Git plug-in (except for tools that have Git 
support already built in, or don't provide any plug-in interface at 
all). And the choice of tools for Git is so plentiful that it does 
include quite a few that cater to people who don't have their brain 
wired "the proper git way".

Fossil? The first time I've ever heard of it was when you just brought 
it up.

[jr] Re: POV-Ray v3.8.0-beta.1 issue #410 [1706 days and 23 minutes ago]

Sat, 7 Aug 2021 07:30:00 GMT

hi,

clipka <ano### [at] anonymousorg> wrote:
> Am 06.08.2021 um 15:43 schrieb jr:
> ...
>> [not] using a VM with a BSD or some Linux...
>
> I did resort to working with a VM for some time for testing code for
> *NIX compatibility, but given my low knowledge level of the *NIX world I
> found it rather a hassle compared to my Windows jockey mouse-pusher
> comfort zone. Particularly the process of transferring the
> version-to-test to the test VM kept bothering me.

directory trees/drives can be shared.


> Nowadays I have the Windows Subsystem for Linux at my disposal if needs
> be, which feels a bit more integrated. For instance, I can pop up an
> Ubuntu terminal from my Windows explorer, taking me straight to a
> specific directory on my Windows file system.
>
> It still is a thing I try to avoid though.

</shakes-head>  :-)


> ... So even if I can't avoid
> a detour through the *NIX world entirely, I'll need to spend less time
> there because I already know what I'm about to encounter there.

don't really agree.  for instance, there never has been a functional, let alone
conceptual, equivalent of X on MS Windows.  (was glad to read (in 'INSTALL'?)
that the preview X window proper may be brought back)


>>> And a developers' manual...
>> moot, of course, but wonder whether publishing that to the wiki would have been
>> so very different (time+effort-wise).
>
> Abso-bloody-lutely.
>
> The Wiki is primarily designed to host content entered manually via the
> Wiki interface itself.
>
> I presume there are also channels for bulk uploads of content, but
> they'd have to be in a format supported by the Wiki.
>
> The developers' manual is currently a guesstimated 90% automatically
> generated from the source code, and 10% manually edited information,
> compiled by a dedicated tool that generates either a suite of
> full-fledged HTML pages or a single PDF.
>
> To cram that content into the Wiki would have required writing import
> scripts. And I have 0 - zero, zilch - knowledge about the Wiki import
> format, while presumably Jim has just as much knowledge about the format
> generated by said tool (beyond the fact that it's HTML, of course).

well, adding a link to the "suite of full-fledged HTML pages" certainly would
not be too .. taxing.

agree on editing aspects etc, though that doesn't apply for generated stuff.


>> ... my browser has to divulge all sorts of info about the system
>> it's running on.
>
> Does it though? Or is it just set to freely do that, and the other end
> takes the liberty to make use of that?
>
> If you were to bar your browser from divulging that information, would
> you really hit a brick wall?

is besides the point.  I think that the onus is on the site to only ask for what
 is needed.  personally, I take what I need, I do not grab more/everything just
because I can, and expect (of course) the same from others.

my "solution" to this is to use a dedicated machine[*] for all browsing.

[*] a Chromebook, so I have an option to "powerwash" if needed.


>> ... captcha ...
>
> It's been ages since I've seen an issue reporting page that doesn't
> require you to at least disclose your e-mail address. Which is all for
> the better in my opinion, because as a developer I want a chance to
> contact the issue reporters, in case I have further questions.

sure, email would be ok (even with verification ;-)).


>> sure.  true also of alternatives, like eg 'fossil'.
>
> Now I think you're confusing the technological platform (such as Git)
> with a particular service based on that platform (such as GitHub).

perhaps, though it seems comparable to me.


regards, jr.

[Denver Dave] LDD to POV ? [1706 days 2 hours and 43 minutes ago]

Sat, 7 Aug 2021 05:10:00 GMT

3.8 doesn't work with LDD - POV converter,
but that's fine. Might be on the converter side.

[clipka] Re: Windows XP compatibility [1706 days 10 hours and 52 minutes ago]

Fri, 6 Aug 2021 21:00:43 GMT

Am 06.08.2021 um 21:04 schrieb Warren:

> I think you should consider the 'CMake' tool. It is used in more and more
> projects, and with its scripting language allows the user to choose the building
> process, that can be (not exhaustive):
> -Compile the project with a Makefile under Windows or Linux
> -Compile the project under Windows with a Visual Studio Solution.
> -Other compilations solutions...
> -Setup some files (else than the generated binaries) in the standard directories
> of differents OSes, /usr/local/share or C:\Program Files\'project dir' for
> example.
> 
> All you need to do is to write one or several files named 'CMakeLists.txt' and
> use the CMake script language. I use CMake in my games projects, it is present
> in many Unix standard repositories and is of course available for Windows and is
> free.
> 
> One good point is that you must write only one 'CMakeLists.txt' file per
> binary/project even if you target several OSes.

The not so good point is that we must write one `CMakeLists.txt`.

Since we're primarily developing on Windows using Visual Studio 
(specifically VS 2015), that's not a thing that is directly supported by 
our primary IDE.

Most notably, _each and every_ change to the set of files that make up 
the POV-Ray source code (be it the addition of a new file, the removal 
of an obsolete one, or the renaming or moving of a file) since the 
release of POV-Ray v3.7.0.0 was done from the seat of a Visual Studio 
jockey.

And as things stand at the moment, VS is the _only_ place we need to 
maintain _any_ such lists of files that need compiling: The current 
Autotools-based process generates its own list on the fly using a fully 
automatic system. (Unless you get a *NIX-specific source tarball, in 
which case that step has already happened).

 From what I've seen of CMake on the other hand, it seems to be 
incapable(*) of such stunts, which I find extremely disappointing for a 
supposedly modern build system. To have a directory sub-tree entirely 
devoted to the software's source code, such that every file in there is 
to be compiled, seems such a trivially common use case to me that I find 
it ridiculous that a modern build system doesn't address it.

(*While there are workarounds that promise to accomplish something like 
that, the CMake authors themselves explicitly state that those 
workarounds don't actually... work.)


Also, I may be misunderstanding things, but I presume CMake does not 
natively cater to a project that has, in some sense, completely 
different applications for different target platforms, which "only" 
share a common core.


All in all, I don't see CMake solving _any_ problem we might currently 
have, while at the same time it would be moving any necessary day-to-day 
maintenance to a place where it is less accessible to us.

Things might change if we add an official third "incarnation" (as I like 
to call them) besides POV-Ray for Windows and POV-Ray for Unix, such as 
a Qt-based portable GUI version of POV-Ray, a Mac-specific one, or 
whatever. But until then, switching over to CMake seems to be more pain 
than gain.


At any rate, CMake won't do anything to help with the original topic of 
this thread, namely XP compatibility.

[Warren] Re: Windows XP compatibility [1706 days 12 hours and 43 minutes ago]

Fri, 6 Aug 2021 19:10:00 GMT

clipka <ano### [at] anonymousorg> wrote:
> Am 19.07.2021 um 05:22 schrieb HKarsten:

[...]
> We prefer targeting multiple build tools, to increase support.
[...]

Hello,
I think you should consider the 'CMake' tool. It is used in more and more
projects, and with its scripting language allows the user to choose the building
process, that can be (not exhaustive):
-Compile the project with a Makefile under Windows or Linux
-Compile the project under Windows with a Visual Studio Solution.
-Other compilations solutions...
-Setup some files (else than the generated binaries) in the standard directories
of differents OSes, /usr/local/share or C:\Program Files\'project dir' for
example.

All you need to do is to write one or several files named 'CMakeLists.txt' and
use the CMake script language. I use CMake in my games projects, it is present
in many Unix standard repositories and is of course available for Windows and is
free.

One good point is that you must write only one 'CMakeLists.txt' file per
binary/project even if you target several OSes.

[clipka] Re: POV-Ray v3.8.0-beta.1 issue #410 [1706 days 14 hours and 7 minutes ago]

Fri, 6 Aug 2021 17:46:04 GMT

Am 06.08.2021 um 15:43 schrieb jr:

>> My *NIX expertise is very low, that's why I'm not doing much for *NIX.
>>
>> That doesn't mean I don't care. It just means I can't do.
> 
> glad to read this.  (very) probably I read too much into things.  (like your
> post re declare=X=Y syntax, where you wrote using a "faux Windows command line";
> cannot imagine a shortage of (computing) resource on your side, so wondered why
> isn't he using a VM with a BSD or some Linux, then a "real" command-line would
> be at hand)

I did resort to working with a VM for some time for testing code for 
*NIX compatibility, but given my low knowledge level of the *NIX world I 
found it rather a hassle compared to my Windows jockey mouse-pusher 
comfort zone. Particularly the process of transferring the 
version-to-test to the test VM kept bothering me.

Nowadays I have the Windows Subsystem for Linux at my disposal if needs 
be, which feels a bit more integrated. For instance, I can pop up an 
Ubuntu terminal from my Windows explorer, taking me straight to a 
specific directory on my Windows file system.

It still is a thing I try to avoid though.


So if you see an error with POV-Ray's *NIX command line interface, why 
wouldn't I test it with the Windows pseudo-command line first? If the 
error is there as well, chances are I can fix it from within my comfort 
zone, and don't need to add stress to my life by taking another stroll 
in the *NIX world.

Even if the error I find should turn out to be located in the 
Windows-specific portion of the code, chances are the problem with the 
Unix side of things is very similar in nature. So even if I can't avoid 
a detour through the *NIX world entirely, I'll need to spend less time 
there because I already know what I'm about to encounter there.


>> And a developers' manual, just because we could. I had already set up a
>> few scripts and configs for that purpose years ago for my own use, but
>> never got around to setting up a channel for publishing the generated
>> documents.
> 
> moot, of course, but wonder whether publishing that to the wiki would have been
> so very different (time+effort-wise).

Abso-bloody-lutely.

The Wiki is primarily designed to host content entered manually via the 
Wiki interface itself.

I presume there are also channels for bulk uploads of content, but 
they'd have to be in a format supported by the Wiki.

The developers' manual is currently a guesstimated 90% automatically 
generated from the source code, and 10% manually edited information, 
compiled by a dedicated tool that generates either a suite of 
full-fledged HTML pages or a single PDF.

To cram that content into the Wiki would have required writing import 
scripts. And I have 0 - zero, zilch - knowledge about the Wiki import 
format, while presumably Jim has just as much knowledge about the format 
generated by said tool (beyond the fact that it's HTML, of course).


Also, the Wiki is not really designed to handle information that may 
change over time.

That's already a bit of a hassle when it comes to changes to the user 
manual as new features are added to the scene language, or limitations 
are lifted, or other some such.

The information in the developers' manual can be even more 
version-specific, especially in times where I'm again doing one of my 
refactoring sprees where I re-arrange parts of the internal 
architecture, or throw away and re-write entire sections of the code.


>> There's no fault in being somewhat suspicious of 3rd party services like
>> GitHub. But let that not blind you to their benefits.
> 
> personally, my main "beef" with such sites is that in order to orient myself and
> look at some info, my browser has to divulge all sorts of info about the system
> it's running on.

Does it though? Or is it just set to freely do that, and the other end 
takes the liberty to make use of that?

If you were to bar your browser from divulging that information, would 
you really hit a brick wall?

> and a requirement to create an account just to comment/add an
> issue? when a captcha to confirm it's not a bot would do.  (the IP address is
> logged anyway)

It's been ages since I've seen an issue reporting page that doesn't 
require you to at least disclose your e-mail address. Which is all for 
the better in my opinion, because as a developer I want a chance to 
contact the issue reporters, in case I have further questions.

And a system hosting hundreds - nay, thousands upon thousands - of 
projects, some of which carry big names? Nope, just a captcha won't cut 
it. Even if you can effectively protect against spam that way (which I 
doubt for sites of a certain magnitude), you couldn't protect against 
trolling. And in such a scenario, trolling would happen, period. Maybe 
not to all projects, but to some. Especially the high-profile ones.

(Also, I for one am repulsed by sites that make me count traffic lights 
or bridges or whatever just to get access to them.)

>> Division of labour has been one of the most efficient strategies in the
>> history of humanity, and this is just another application of that principle.
> 
> sure.  true also of alternatives, like eg 'fossil'.

Now I think you're confusing the technological platform (such as Git) 
with a particular service based on that platform (such as GitHub).

Back when we made the decision, we had our reasons to pick Git as the 
technological platform, and once that had been settled, to choose GitHub 
as the hosting service. I can elaborate why those two specifically, if 
you are interested.

The main point though is that the decision has been made. Whether it is 
the _perfect_ choice is a moot question: Unless some pressing need crops 
up, the hassle of migrating even to a different hosting service - let 
alone an entirely different technological platform - far outweighs any 
benefit such a move might provide in the long run. Let alone that other 
hosting services and platforms also tend to have their downsides.

[jr] Re: POV-Ray v3.8.0-beta.1 issue #410 [1706 days 18 hours and 3 minutes ago]

Fri, 6 Aug 2021 13:50:00 GMT

hi,

clipka <ano### [at] anonymousorg> wrote:
> Am 05.08.2021 um 18:02 schrieb jr:
>
> > anyway, the whole thing makes me wonder why you .. bother.  *NIX-ness is not a
> > high priority for you, I feel, so why even have tarballs?  would just "git
> > clone" not be preferential?
>
> I think that's a severe misunderstanding.
>
> My *NIX expertise is very low, that's why I'm not doing much for *NIX.
>
> That doesn't mean I don't care. It just means I can't do.

glad to read this.  (very) probably I read too much into things.  (like your
post re declare=X=Y syntax, where you wrote using a "faux Windows command line";
cannot imagine a shortage of (computing) resource on your side, so wondered why
isn't he using a VM with a BSD or some Linux, then a "real" command-line would
be at hand)

> > (this rant is "tainted" -- probably -- by your mentioning that even the POV-Ray
> > development code resides "in the cloud" now rather than on own(ed) server(s))
>
> It has been ever since we moved to a Git-based solution, right at the
> time of the 3.7.0.0 release.
> ...
> We also got some feedback and contributions via GitHub that we might not
> have gotten otherwise. Certainly not on as large a scale as in CompuServ
> times, but still.
>
> Among those who got into touch with us were the folks who maintain the
> "homebrew" packages to provide *NIX software for MacOS. Which put
> official MacOS compatibility back on the menu, after it had already
> dropped off the back of the truck in the years prior.

additional channels of communication is useful.

> ...
> And a developers' manual, just because we could. I had already set up a
> few scripts and configs for that purpose years ago for my own use, but
> never got around to setting up a channel for publishing the generated
> documents.

moot, of course, but wonder whether publishing that to the wiki would have been
so very different (time+effort-wise).

> ...
> There's no fault in being somewhat suspicious of 3rd party services like
> GitHub. But let that not blind you to their benefits.

personally, my main "beef" with such sites is that in order to orient myself and
look at some info, my browser has to divulge all sorts of info about the system
it's running on.  and a requirement to create an account just to comment/add an
issue? when a captcha to confirm it's not a bot would do.  (the IP address is
logged anyway)

> Division of labour has been one of the most efficient strategies in the
> history of humanity, and this is just another application of that principle.

sure.  true also of alternatives, like eg 'fossil'.

regards, jr.

[clipka] Re: POV-Ray v3.8.0-beta.1 issue #410 [1706 days 21 hours and 20 minutes ago]

Fri, 6 Aug 2021 10:33:34 GMT

Am 05.08.2021 um 18:02 schrieb jr:

> anyway, the whole thing makes me wonder why you .. bother.  *NIX-ness is not a
> high priority for you, I feel, so why even have tarballs?  would just "git
> clone" not be preferential?

I think that's a severe misunderstanding.

My *NIX expertise is very low, that's why I'm not doing much for *NIX.

That doesn't mean I don't care. It just means I can't do.

> (this rant is "tainted" -- probably -- by your mentioning that even the POV-Ray
> development code resides "in the cloud" now rather than on own(ed) server(s))

It has been ever since we moved to a Git-based solution, right at the 
time of the 3.7.0.0 release.

And to be frank, the GitHub infrastructure around the repo has been 
quite an asset in the development work ever since. With the manpower 
available to us, it would have been impossible to set up (let alone 
maintain!) anything even remotely like it on our own turf.

As a matter of fact, *NIX-ness might have been the feature to benefit 
most. With the dev team stocked pretty much with pure Windows jockeys, 
automated test builds were the only thing that had us on our toes 
regarding *NIX-incompatibilities. Setting up such facilities on our own 
would have required quite the effort.

Automated test builds also helped a lot to get us through the times when 
C++11 and clang both started to see widespread use, sending additional 
ripples across the boost library, and opened up new portability pitfalls 
due to incomatibilities between ever shifting boost versions, certain 
constructs that turned out to no longer work in C++11, and the like. 
With us Windows jockeys having no (or only cumbersome) access to a truly 
C++11-compatible (let alone C++11-strict) development environment back 
then, the availability of not just one but three(!) independent 
free-for-open-source hosted build test services was invaluable to keep 
POV-Ray compatible with all the fast-changing world of C++ back then, 
both the established and the emerging.

We also got some feedback and contributions via GitHub that we might not 
have gotten otherwise. Certainly not on as large a scale as in CompuServ 
times, but still.

Among those who got into touch with us were the folks who maintain the 
"homebrew" packages to provide *NIX software for MacOS. Which put 
official MacOS compatibility back on the menu, after it had already 
dropped off the back of the truck in the years prior.

The issue tracker also proved useful, if only because it meant we no 
longer had to waste time keeping spammers out of our self-hosted bug 
tracker.

And the fact that *NIX tarballs are back on the menu is also courtesy of 
GitHub, because as we now migrated all the automated build tests from 
3rd party services to GitHub's new own, we found that we could easily do 
additional stuff whenever we were to auto-build Windows binaries. Even 
stuff that would require a *NIX machine to run. (Or a MacOS machine, for 
that matter, but that's not a thing that has manifested so far). So we 
added *NIX tarballs to that build process.

And a developers' manual, just because we could. I had already set up a 
few scripts and configs for that purpose years ago for my own use, but 
never got around to setting up a channel for publishing the generated 
documents.

Which is another boon of GitHub: It is so much easier to set up a new 
release there, with any arbitrary set of associated downloadables, than 
it would be on our own web server.

Which is what has gotten you folks each and every alpha release since 
v3.7.0.0. I have no access to the web server to bundle up and publish 
releases there, and I wouldn't have dared to bother Chris with anything 
other than betas or better. Let alone that it would have taken a couple 
of days minimum (if not weeks) for each such release to eventually make 
it onto some downloadable page.

I wouldn't even have seen the benefit of such releases in the first 
place. It was more a matter of, "hey, we can do this on a regular basis 
with almost zero effort, so why not."

And I won't even mention the occasional experimental build, such as the 
OpenType support builds.

Even whether beta.1 would be out yet, without GitHub's ease of deploying 
software, is anybody's guess. It might still be in the pipeline between 
me and Chris Cason. Or I might still be procrastinating about even 
actually running the build process on my local machine. Having GitHub 
run it is so much easier and leaves far less room for PEBCAK errors, 
once the process has been set up.


There's no fault in being somewhat suspicious of 3rd party services like 
GitHub. But let that not blind you to their benefits.

Division of labour has been one of the most efficient strategies in the 
history of humanity, and this is just another application of that principle.

[jr] Re: POV-Ray v3.8.0-beta.1 issue #410 [1707 days 15 hours and 48 minutes ago]

Thu, 5 Aug 2021 16:05:00 GMT

hi,

clipka <ano### [at] anonymousorg> wrote:
> Am 05.08.2021 um 16:31 schrieb jr:
>
> > 'README.md' in the top-level dir is newer, still suggest that should become
> > "the" new 'README'; then only 'README.unix' needs moving up.
>
> No, not really. `README.md` is specificially aimed at someone looking at
> the entire repository package (or, even more to the point, someone
> looking at the repository on GitHub).

then, surely, it should be on github, and not in the archive; a paragraph in the
'README' with repository url would suffice (to my thinking).

> The `README` in the Unix-specific package should be aimed specifically
> at someone looking at that particular tarball.

agree.  and that tarball will already have been downloaded.  so I'd be looking
for intro/overview + general instructions - only.

anyway, the whole thing makes me wonder why you .. bother.  *NIX-ness is not a
high priority for you, I feel, so why even have tarballs?  would just "git
clone" not be preferential?

(this rant is "tainted" -- probably -- by your mentioning that even the POV-Ray
development code resides "in the cloud" now rather than on own(ed) server(s))

regards, jr.

[clipka] Re: POV-Ray v3.8.0-beta.1 issue #410 [1707 days 16 hours and 38 minutes ago]

Thu, 5 Aug 2021 15:15:37 GMT

Am 05.08.2021 um 16:31 schrieb jr:

> 'README.md' in the top-level dir is newer, still suggest that should become
> "the" new 'README'; then only 'README.unix' needs moving up.

No, not really. `README.md` is specificially aimed at someone looking at 
the entire repository package (or, even more to the point, someone 
looking at the repository on GitHub).

The `README` in the Unix-specific package should be aimed specifically 
at someone looking at that particular tarball.

[jr] Re: POV-Ray v3.8.0-beta.1 issue #410 [1707 days 17 hours and 18 minutes ago]

Thu, 5 Aug 2021 14:35:00 GMT

hi,

clipka <ano### [at] anonymousorg> wrote:
> Am 05.08.2021 um 12:05 schrieb jr:
>
> > the 'ChangeLog', 'AUTHORS', 'COPYING', 'NEWS', and 'README*' files ought to
> > "migrate" to the archive's top-level directory.
>
> That's where they currently are in the tarball, are they not?

I was looking at the /unix/ files (only).  duplicates can just be deleted.  the
'README.md' in the top-level dir is newer, still suggest that should become
"the" new 'README'; then only 'README.unix' needs moving up.

regards, jr.

[clipka] Re: POV-Ray v3.8.0-beta.1 issue #410 [1707 days 17 hours and 54 minutes ago]

Thu, 5 Aug 2021 13:59:15 GMT

Am 05.08.2021 um 12:05 schrieb jr:

> the 'ChangeLog', 'AUTHORS', 'COPYING', 'NEWS', and 'README*' files ought to
> "migrate" to the archive's top-level directory.

That's where they currently are in the tarball, are they not?

[jr] Re: POV-Ray v3.8.0-beta.1 issue #410 [1707 days 21 hours and 43 minutes ago]

Thu, 5 Aug 2021 10:10:00 GMT

"jr" <cre### [at] gmailcom> wrote:
> ...
> ah, found the 'README.*'s -- once I looked in the correct directory.  (will get
> back on these in a couple of days)

the 'NEWS' file makes it clear the release is source only, so 'README.bin' could
simply be deleted.  the 'README' and 'README.md' files are, essentially,
identical. suggest updating the 'Dependencies' and 'Generating configure..'
sections in 'README.md', and rename that to 'README'.  the 'README.unix' too
needs some updating (from v3.6); I think that file will become (more) relevant
again (cf X support).

the 'ChangeLog', 'AUTHORS', 'COPYING', 'NEWS', and 'README*' files ought to
"migrate" to the archive's top-level directory.

regards, jr.

[jr] Re: POV-Ray v3.8.0-beta.1 issue #410 [1709 days 1 hour and 18 minutes ago]

Wed, 4 Aug 2021 06:35:00 GMT

hi,

clipka <ano### [at] anonymousorg> wrote:
> Am 03.08.2021 um 18:04 schrieb jr:
>
> > the 'install' and 'README.*' weren't included in the 'povunix' tarball.  the
> > '*.x?m' files could go under '/usr/share/pixmaps/', I suggest.
>
> I'm not 100% sure about the `README.*` files off the top of my head, but
> `install` should be present in the main folder of the tarball as `INSTALL`.

ah, found the 'README.*'s -- once I looked in the correct directory.  (will get
back on these in a couple of days)


regards, jr.

[clipka] Re: POV-Ray v3.8.0-beta.1 issue #410 [1709 days 13 hours and 30 minutes ago]

Tue, 3 Aug 2021 18:23:20 GMT

Am 03.08.2021 um 18:04 schrieb jr:

> the 'install' and 'README.*' weren't included in the 'povunix' tarball.  the
> '*.x?m' files could go under '/usr/share/pixmaps/', I suggest.

I'm not 100% sure about the `README.*` files off the top of my head, but 
`install` should be present in the main folder of the tarball as `INSTALL`.

[jr] POV-Ray v3.8.0-beta.1 issue #410 [1709 days 15 hours and 48 minutes ago]

Tue, 3 Aug 2021 16:05:00 GMT

hi,

> The unix folder in our repo is littered with various files ...
> Make recommendations how to get them back up to snuff if they
> could still be of use.

regarding 'unix/icons/*.png'.  I think they could be installed under
'/usr/share/icons/', perhaps '/usr/share/icons/POV_Ray/'?  would require
organising them by size, and renaming, to accommodate the existing conventions.
benefit: would be available in "desktop environments" (Gnome/KDE/etc).

the 'install' and 'README.*' weren't included in the 'povunix' tarball.  the
'*.x?m' files could go under '/usr/share/pixmaps/', I suggest.

(either '/usr/share/' or '/usr/local/share/' would do.)


regards, jr.

[Alain Martel] Re: POV-Ray v3.8.0-beta 1 - Parse error using "%... [1712 days 16 hours and 43 minutes ago]

Sat, 31 Jul 2021 15:10:15 GMT

Le 2021-07-30 à 19:13, clipka a écrit :
> Am 30.07.2021 um 23:38 schrieb Cousin Ricky:
> 
>>> I realize only now that I accidently implemented the wrong behavior
>>> (judging by the documentation, and intent so far).
>>
>> The 3.8 documentation say 'now' should return GMT, and on my GNU/Linux
>> box, it (pre-beta) does return UTC or GMT.  Are you proposing a change
>> in behavior?
> 
> I think I do, yes.
> 
> The current behavior appears to be quite inconsistent across platforms 
> and systems and whatnot.

In my case, #debug concat("v3.8 default -> ",datetime(now),"\n")
returns the current local time with an extraneous «Z» appended at the end.
Running the Windows version under Windows 10.

The default formatting string do end with «%SZ». I think that it should 
end with «%S%Z».

[tth] Re: POV-Ray v3.8.0-beta 1 - Parse error using "%... [1712 days 17 hours and 50 minutes ago]

Sat, 31 Jul 2021 14:03:13 GMT

On 7/28/21 3:16 PM, William F Pokorny wrote:

> #version 3.8;
> #debug concat("v3.8 default -> ",datetime(now),"\n")
> 
> I've gotten back:
> 
>   v3.8 default -> 2021-07-28 08:11:16Z
> 
> because the default format strings has a 'Z' on the end where I suspect 
> ' %Z' was intended.

Z is for Zulu Time Zone, often used in aviation and the
military as another name for UTC +0.

tTh

-- 
+-------------------------------------------------------------------+
|                      sphinx of black quartz, judge my vow.        |
+-------------------------------------------------------------------+

[William F Pokorny] Re: POV-Ray v3.8.0-beta 1 - Parse error using "%... [1712 days 23 hours and 34 minutes ago]

Sat, 31 Jul 2021 08:18:55 GMT

On 7/30/21 7:13 PM, clipka wrote:
> Am 30.07.2021 um 23:38 schrieb Cousin Ricky:
> 
>>> I realize only now that I accidently implemented the wrong behavior
>>> (judging by the documentation, and intent so far).
>>
>> The 3.8 documentation say 'now' should return GMT, and on my GNU/Linux
>> box, it (pre-beta) does return UTC or GMT.  Are you proposing a change
>> in behavior?
> 
> I think I do, yes.
> 
> The current behavior appears to be quite inconsistent across platforms 
> and systems and whatnot.

Cousin Ricky is onto something; Me screwing up with respect to v3.8 beta 
1 results. :-(

I maintain "many" versions of POV-Ray which I run with wrapper scripts 
that are careful to strip any $HOME directory or environment variable 
customizations - so I'm always testing the native code and set up.

When I grabbed and compiled:
https://github.com/POV-Ray/povray/releases/tag/v3.8.0-beta.1

I created a 'p380b1' wrapper script, but I screwed up and pointed it to 
the v3.8 compile directories for the commit from off of which I'm basing 
my povr stuff. All my testing of v3.8 beta 1 over the last couple weeks 
has been against something closer to the current master branch. 
#@%^$^%$&!!! The version is clearly there in the text output, which I 
ignore 99.99% of the time...

What this means is the 'now' command I was running as v3.8 beta 1 was 
the newer(1) c++11 version. It's that one not returning the utc/gmt/zulu 
time making the default 'Z' format suffix wrong.

(1) - Though I've been running primarily that one for years - so I was 
seeing what I expected to see as datetime(now) output.

---
I think, Christoph, an option - if you want to minimize v3.8 release 
change - would be to let things go as they are. This would mean a hard 
UTC datetime() result without working %z and %Z format options (others?).

I agree with your thinking the behavior of 'now' should updated, but 
this could be delayed to v4.0.

Bill P.

[clipka] Re: POV-Ray v3.8.0-beta 1 - Parse error using "%... [1713 days 8 hours and 40 minutes ago]

Fri, 30 Jul 2021 23:13:23 GMT

Am 30.07.2021 um 23:38 schrieb Cousin Ricky:

>> I realize only now that I accidently implemented the wrong behavior
>> (judging by the documentation, and intent so far).
> 
> The 3.8 documentation say 'now' should return GMT, and on my GNU/Linux
> box, it (pre-beta) does return UTC or GMT.  Are you proposing a change
> in behavior?

I think I do, yes.

The current behavior appears to be quite inconsistent across platforms 
and systems and whatnot.

[Cousin Ricky] Re: POV-Ray v3.8.0-beta 1 - Parse error using "%... [1713 days 10 hours and 14 minutes ago]

Fri, 30 Jul 2021 21:38:49 GMT

On 2021-07-30 2:29 PM (-4), clipka wrote:
> 
> - When users see a date or time, they will usually expect it to indicate
> local time. To achieve that, the parameter passed to `datetime()` would
> have to be of local time flavor.
> 
> This speaks heavily in favor of making `now` return local time, as
> opposed to UTC.
> 
> 
> I think it can be argued that local time is of far more relevance to
> most users than UTC.
> 
> [snip]
> 
> Actually, no - in this case `now` returning local time is not a
> Unix/Linux bug (or, more to the point, not a "boost on Unix/Linux bug"),
> but rather proper intrinsic behavior of the new implementation I chose.
> 
> I realize only now that I accidently implemented the wrong behavior
> (judging by the documentation, and intent so far).

The 3.8 documentation say 'now' should return GMT, and on my GNU/Linux
box, it (pre-beta) does return UTC or GMT.  Are you proposing a change
in behavior?

[clipka] Re: POV-Ray v3.8.0-beta 1 - Parse error using "%... [1713 days 13 hours and 24 minutes ago]

Fri, 30 Jul 2021 18:29:34 GMT

Am 30.07.2021 um 16:00 schrieb William F Pokorny:

> In my testing your fix gives me the utc time as a hard coded result - 
> and it's the only datetime string I can get with 'now'.
> 
> 2021-07-30 12:48:35Z
> 
> What about local datetime strings with %z or %Z? The secondary issue I'd 
> forgotten I hit back in June with the boost code is that:
> 
> std::tm t = 
> boost::posix_time::to_tm(boost::posix_time::from_time_t(timestamp));
> 
> doesn't set up the %Z and %z capability. Using both in the string format 
> option gives me: "2021-07-30 12:48:35".
> 
> One can set up those fields by calling strftime() with an argument of:
> std::localtime(&t), here getting EDT/-0400, but the date and time string 
> is still strictly UTC - so it's not particularly useful except maybe to 
> work backward to the actual time zone date and time in a uncommon / 
> awkward way and to do that you'd need to know the data/time was UTC no 
> matter the EDT or -0400 in the returned string.

That would require making `now` a more complicated beast than just a 
numeric value, as we can't transport timezone information in that format.

I'm not going there. Not in v3.8, at any rate. Nor am I going the povr 
route of hacking something into `datetime` to make it look up the 
current time on its own when it gets passed some magic value. Retrieving 
the current time is precisely the job of `now`.


As it currently stands, we have no sane way (in v3.8) of achieving all 
the following ideal goals:

- Have separate mechanisms to get the current point in time (`now`), and 
print a point in time (`datetime`).

- Have a simple "phrase" (combo of the above) to automatically print the 
given point in time as UTC, without extra effort, and in a way that it 
won't be mistaken for local time.

- Have a simple "phrase" (combo of the above) to automatically print the 
given point in time as local time, without extra effort, and in a way 
that it won't be mistaken for UTC.


I think the following arguments lead to the sanest solution:

- If we have `datetime` default to a string that explicitly prints any 
time zone information (as we currently do), then for the default to be 
not blatantly wrong, we limit ourselves to one "flavor" of point-in-time 
information: Either local ("%z" suffix), or UTC ("Z" suffix). If on the 
other hand we omit the time zone entirely from the default, the output 
will, for both flavors, be at least not entirely wrong.

This speaks heavily in favor of not including any time zone suffix at 
all by default, i.e. dropping the "Z" we're currently appending.

- When users see a date or time, they will usually expect it to indicate 
local time. To achieve that, the parameter passed to `datetime()` would 
have to be of local time flavor.

This speaks heavily in favor of making `now` return local time, as 
opposed to UTC.


I think it can be argued that local time is of far more relevance to 
most users than UTC.

Should someone come up with any use case that needs access to the 
current time in UTC, then possible workarounds would be:

- for the user to hard-code time zone offset into their scene file;

- for the user to design the scene such that time zone offset can be 
passed via `Declare=` INI file setting;

- for us to provide some `timezone` pre-defined variable that evaluates 
to the time zone offset in days, ready to be subtracted from `now` to 
give UTC, or a `utc()` function that converts from local time to UTC. (I 
would lean towards the latter, as the former variable would not be in 
the common format of hours, which might give rise to confusion.)


> I guess I see a place for a hard coded 'now' UTC/Z result - and as 
> accurate an internal time/timer as we can get (is your fix at odds with 
> timer use?).

I'm not sure what you mean by "at odds with timer use".

What I can say is that the fix does not compromise timer precision, if 
that's what you mean.


> Aside 1: A reminder that in newer(to be v4.0) code, you moved 'now' off 
> boost completely. This is in fact is the code povr uses - meaning any 
> unix/linux 'bug' is in that code too.

Actually, no - in this case `now` returning local time is not a 
Unix/Linux bug (or, more to the point, not a "boost on Unix/Linux bug"), 
but rather proper intrinsic behavior of the new implementation I chose.

I realize only now that I accidently implemented the wrong behavior 
(judging by the documentation, and intent so far).

It's not the worst of accidents though. I'd like to consider it a Bob 
Ross moment.


> Aside 2: The Parse_Datetime() code has too that use of:
> 
> setlocale(LC_TIME,"");
> 
> the full implications of which made me a little nervous along with the 
> etting being afterward persistent.

You and me both, bro.

> So after the strftime() call I added:
> 
> setlocale(LC_TIME,"C");

Without any additional safety net, that would actually be 
counter-productive: `setlocale` is not thread-safe; so if we ever run 
multiple parser threads in parallel, and they come across the same piece 
of code nearly at the same time, your "cleanup" could throw the other 
thread off the rails.

The good news is that the above call only sets the time-specific 
portions of the locale, which we don't mess with anywhere else. So 
ideally we should call `setlocale(LC_TIME,"")` somewhere on program 
startup, and never look back.


> (a) Lying some. Unsure what might happen with the boost variant over the 
> pure c++11 one for now, but the latter didn't account for daylight 
> savings adjustments which also makes datetime(), %z and %Z less than 
> precisely useful.

The v4.0 variant doesn't respect daylight savings zone? Yikes!

That'll be another problem to solve then.

[William F Pokorny] Re: POV-Ray v3.8.0-beta 1 - Parse error using "%... [1713 days 17 hours and 52 minutes ago]

Fri, 30 Jul 2021 14:00:59 GMT

On 7/29/21 5:43 PM, clipka wrote:
> Can someone test whether the fix in this pull request actually solves 
> the time zone issue?
> 
> https://github.com/POV-Ray/povray/pull/433
> 
> It should cause `datetime(now)` to print UTC (as opposed to local) time, 
> while still incrementing significantly faster than once per second.
> 
> 
> What I'm doing there is query another timer to get a second opinion. 
> While that timer is of lower precision (seconds instead of 
> microseconds), it should reliably give proper UTC. So by using that as a 
> reference, we can adjust the high-precision timer accordingly by a 
> multiple of 15 minutes, to give us high-precision UTC.

First, what the -1e5 argument to datetime() does in the povr branch is 
flip to code inside Parser::Parse_Datetime which uses std::time(nullptr) 
over the argument - POV-Ray's 'now' is not relevant.

---
In my testing your fix gives me the utc time as a hard coded result - 
and it's the only datetime string I can get with 'now'.

2021-07-30 12:48:35Z

What about local datetime strings with %z or %Z? The secondary issue I'd 
forgotten I hit back in June with the boost code is that:

std::tm t = 
boost::posix_time::to_tm(boost::posix_time::from_time_t(timestamp));

doesn't set up the %Z and %z capability. Using both in the string format 
option gives me: "2021-07-30 12:48:35".

One can set up those fields by calling strftime() with an argument of:
std::localtime(&t), here getting EDT/-0400, but the date and time string 
is still strictly UTC - so it's not particularly useful except maybe to 
work backward to the actual time zone date and time in a uncommon / 
awkward way and to do that you'd need to know the data/time was UTC no 
matter the EDT or -0400 in the returned string.

---
I guess I see a place for a hard coded 'now' UTC/Z result - and as 
accurate an internal time/timer as we can get (is your fix at odds with 
timer use?). I don't see it as what most people will want with 
datetime(). This why I coded up a more traditional std::time(nullptr) as 
an optional mode of datetime()(a).

Aside 1: A reminder that in newer(to be v4.0) code, you moved 'now' off 
boost completely. This is in fact is the code povr uses - meaning any 
unix/linux 'bug' is in that code too.

Aside 2: The Parse_Datetime() code has too that use of:

setlocale(LC_TIME,"");

the full implications of which made me a little nervous along with the 
etting being afterward persistent. So after the strftime() call I added:

setlocale(LC_TIME,"C");

to return the setting to the C++ start up default. In a scan of the code 
I didn't pick up any other adjustments to the default locale.

Bill P.

(a) Lying some. Unsure what might happen with the boost variant over the 
pure c++11 one for now, but the latter didn't account for daylight 
savings adjustments which also makes datetime(), %z and %Z less than 
precisely useful.

[Thomas de Groot] Re: POV-Ray v3.8.0-beta.1 [1714 days 1 hour and 56 minutes ago]

Fri, 30 Jul 2021 05:57:15 GMT

Op 29/07/2021 om 21:54 schreef clipka:
> Am 29.07.2021 um 17:45 schrieb Thomas de Groot:
>> I still do not understand this parse warning as I do *not* run a 
>> version 3.5 scene. Does it refer to POV-Ray includes which /mention/ 
>> version 3.5?
>> functions.inc seem to be the only include file containing this.
>>
>> Just a short explanation would be enough about this mysterious warning.
> 
> It's a bug in `functions.inc`: At the start it claims that it needs only 
> v3.5, but later it uses the `deprecated` keyword, which wasn't 
> introduced until v3.7.
> 
> In other words, if someone were to use genuine POV-Ray v3.5, and render 
> the scene with that very same include file, they'd get an error message.
> 
> The fact that POV-Ray warns about such scenarios is a brand new feature 
> of v3.8.0-beta.1.

OK. Thanks for this. I shall just close my eyes ;-)

-- 
Thomas

[clipka] Re: POV-Ray v3.8.0-beta 1 - Parse error using "%... [1714 days 10 hours and 9 minutes ago]

Thu, 29 Jul 2021 21:43:55 GMT

Can someone test whether the fix in this pull request actually solves 
the time zone issue?

https://github.com/POV-Ray/povray/pull/433

It should cause `datetime(now)` to print UTC (as opposed to local) time, 
while still incrementing significantly faster than once per second.


What I'm doing there is query another timer to get a second opinion. 
While that timer is of lower precision (seconds instead of 
microseconds), it should reliably give proper UTC. So by using that as a 
reference, we can adjust the high-precision timer accordingly by a 
multiple of 15 minutes, to give us high-precision UTC.

[clipka] Re: POV-Ray v3.8.0-beta.1 [1714 days 11 hours and 59 minutes ago]

Thu, 29 Jul 2021 19:54:36 GMT

Am 29.07.2021 um 17:45 schrieb Thomas de Groot:
> I still do not understand this parse warning as I do *not* run a version 
> 3.5 scene. Does it refer to POV-Ray includes which /mention/ version 3.5?
> functions.inc seem to be the only include file containing this.
> 
> Just a short explanation would be enough about this mysterious warning.

It's a bug in `functions.inc`: At the start it claims that it needs only 
v3.5, but later it uses the `deprecated` keyword, which wasn't 
introduced until v3.7.

In other words, if someone were to use genuine POV-Ray v3.5, and render 
the scene with that very same include file, they'd get an error message.

The fact that POV-Ray warns about such scenarios is a brand new feature 
of v3.8.0-beta.1.

[Thomas de Groot] Re: POV-Ray v3.8.0-beta.1 [1714 days 16 hours and 8 minutes ago]

Thu, 29 Jul 2021 15:45:03 GMT

I still do not understand this parse warning as I do *not* run a version 
3.5 scene. Does it refer to POV-Ray includes which /mention/ version 3.5?
functions.inc seem to be the only include file containing this.

Just a short explanation would be enough about this mysterious warning.

Thanks,

Thomas

Op 19-7-2021 om 14:17 schreef Thomas de Groot:
> Rendering a 3.8 version scene which includes functions.inc, I get the 
> following parse warning:
> 
> "functions.inc" line 167: Parse warning: use of POV-Ray v3.7 keyword 
> ('deprecated') detected in alleged v3.5 scene.
> 
> The only place were version 3.5 is mentioned is precisely at the start 
> of functions.inc:
> 
> #ifndef(Functions_Inc_Temp)
> #declare Functions_Inc_Temp = version;
> #version 3.5;
> ...
> #end
> 
> At the mentioned line 167 of this /new/ functions.inc shipped with the 
> beta, a /new/ if statement has been introduced, not there in previous 
> versions:
> 
> #if (Functions_Inc_Temp < 3.8)
>  Â Â Â  #declare deprecated once "f_enneper was broken
prior to v3.8; 
> results will most likely differ."
> 
Â Â Â Â Â Â Â Â Â Â Â Â 
f_enneper = function { internal(18) }
> #else
>  Â Â Â  #declare f_enneper = function { internal(18) }
> #end
> 
> 


-- 
Thomas

[clipka] Re: POV-Ray v3.8.0-beta 1 - Parse error using "%... [1714 days 18 hours and 59 minutes ago]

Thu, 29 Jul 2021 12:54:35 GMT

Am 29.07.2021 um 13:45 schrieb William F Pokorny:

> Supposing the SDL:
> 
>     #debug concat("",datetime(now),"\n")
>     #debug concat("",datetime(-100000),"\n") // (*)
> 
> And the 'date' command on my Ubuntu 20.04 computer returning:
> 
>      Thu 29 Jul 2021 07:15:12 AM EDT
> 
> The v3.8 branch returns:
> 
>      2021-07-29 06:15:12Z  <-- Not current Zulu time... (**)
>      1726-03-18 00:00:00Z
> 
> The povr branch returns:
> 
>      2021-07-29 06:15:13 -0400 <-- Not my current dst time. Offset
wrong.
>      2021-07-29 07:15:13 -0400 <-- This is correct.
> 
> Bill P.

Oh hooray.

So, after some digging, it turns out that on Linux machines, 
`boost::posix_time::microsec_clock::universal_time()` does specifically 
*NOT* do what it was designed to do (at least with the boost version 
we're bundling for Windows builds).

> (*) The -100000 days is somewhat arbitrary. Just needs to be earlier 
> than the unix epoch time to trigger the dst aware mode.

I have no idea what you're saying there. What do you need to trigger, 
and why?

[William F Pokorny] Re: POV-Ray v3.8.0-beta 1 - Parse error using "%... [1714 days 20 hours and 8 minutes ago]

Thu, 29 Jul 2021 11:45:12 GMT

On 7/28/21 5:53 PM, clipka wrote:
> Am 28.07.2021 um 15:16 schrieb William F Pokorny:
> 
>> Just to toss it out there, for as long as I've used datetime(now) as in:
>>
>> #version 3.8;
>> #debug concat("v3.8 default -> ",datetime(now),"\n")
>>
>> I've gotten back:
>>
>>   v3.8 default -> 2021-07-28 08:11:16Z
>>
>> because the default format strings has a 'Z' on the end where I 
>> suspect ' %Z' was intended. In the povr branch I changed to ' %z' as I 
>> think the time offset more general.
> 
> The `datetime` function with default values works as documented:
> 
> "The default for the STRING parameter format is %Y-%m-%d %H:%M:%SZ"
> 
> 
> I'm not the author of that functionality, but according to my 
> understanding, this is entirely intentional:
> 
> Since the information provided by "now" is based on UTC, and the 
> `strftime` conversion specifiers are time zone agnostic(*), the printed 
> date and time are also with respect to UTC.
> 
> In full compliance with ISO 8601, this is indicated by appending a 
> literal uppercase `Z` right after the time, which is the official time 
> zone designator for UTC.
> 
> 
> (*)Except for `%Z` or `%z` of course.
> 
> Speaking of which: Appending either of those instead of "Z" would 
> actually give a wrong time, unless you first convert `now` to local time.
> 
> Also, per ISO 8601 any time zone designator should be appended to the 
> time without any intervening space.

Supposing the SDL:

    #debug concat("",datetime(now),"\n")
    #debug concat("",datetime(-100000),"\n") // (*)

And the 'date' command on my Ubuntu 20.04 computer returning:

     Thu 29 Jul 2021 07:15:12 AM EDT

The v3.8 branch returns:

     2021-07-29 06:15:12Z  <-- Not current Zulu time... (**)
     1726-03-18 00:00:00Z

The povr branch returns:

     2021-07-29 06:15:13 -0400 <-- Not my current dst time. Offset wrong.
     2021-07-29 07:15:13 -0400 <-- This is correct.

Bill P.

(*) The -100000 days is somewhat arbitrary. Just needs to be earlier 
than the unix epoch time to trigger the dst aware mode.

(**) Using %Z would add EDT instead of EST (locally), which is also 
correct. Though any given reader must know what the local %Z dst is no 
matter where povray/datetime(now) was run or where they live
compared to the person who did run it.

[clipka] Re: POV-Ray v3.8.0-beta 1 - Parse error using "%... [1714 days 21 hours and 24 minutes ago]

Thu, 29 Jul 2021 10:29:32 GMT

Am 29.07.2021 um 10:35 schrieb jr:

>>> also, while on 'povr', I
>>> ran into trouble viewing font glyphs >= chr(256).
>>
>> True my text{} isn't POV-Ray's exactly... Is this something unique to
>> the povr branch? Off the top of my head, this likely normal unless using
>> a unicode string specifications.
> 
> not so sure now whether 'povr' or 'povray' cause "a problem", see attached,
> 'povr' on right.  did a quick check with a Tk text and that confirms the 'povr'
> output.

povr is based on those rolled-back alpha versions, right? Then color me 
unsurprised.

Did I ever, maybe in passing, mention that POV-Ray v3.7's behavior 
(which we strive to emulate in v3.8) regarding non-ASCII characters and 
fonts is seriously borked?


> also, Tdg, while testing my macro (thanks, Thomas), found fonts where 'chr(32)'
> display as exclamation marks; with both POV-Ray alpha and yr 'povr'.  have not
> yet checked to find out why (have to install one or two of the fonts first).

It is theoretically possible for fonts to provide a non-empty glyph for 
the ASCII "space" character. I guess this could go unnoticed in most 
programs, as they would typically use operating systems calls to render 
text, which in turn could conveivably give special treatment to ASCII 
"space" by simply inserting a gap according to the character's width.

I think POV-Ray does not currently do that, and instead treats "space" 
like any other character, i.e. it may or may not have a visible glyph.


But I think we're digressing a bit from the original thread...

[jr] Re: POV-Ray v3.8.0-beta 1 - Parse error using "%... [1714 days 23 hours and 13 minutes ago]

Thu, 29 Jul 2021 08:40:00 GMT

hi,

William F Pokorny <ano### [at] anonymousorg> wrote:
> ...
>> also, while on 'povr', I
>> ran into trouble viewing font glyphs >= chr(256).
>
> True my text{} isn't POV-Ray's exactly... Is this something unique to
> the povr branch? Off the top of my head, this likely normal unless using
> a unicode string specifications.

not so sure now whether 'povr' or 'povray' cause "a problem", see attached,
'povr' on right.  did a quick check with a Tk text and that confirms the 'povr'
output.

also, Tdg, while testing my macro (thanks, Thomas), found fonts where 'chr(32)'
display as exclamation marks; with both POV-Ray alpha and yr 'povr'.  have not
yet checked to find out why (have to install one or two of the fonts first).

regards, jr.

[clipka] Re: POV-Ray v3.8.0-beta 1 - Parse error using "%... [1715 days 10 hours ago]

Wed, 28 Jul 2021 21:53:02 GMT

Am 28.07.2021 um 15:16 schrieb William F Pokorny:

> Just to toss it out there, for as long as I've used datetime(now) as in:
> 
> #version 3.8;
> #debug concat("v3.8 default -> ",datetime(now),"\n")
> 
> I've gotten back:
> 
>   v3.8 default -> 2021-07-28 08:11:16Z
> 
> because the default format strings has a 'Z' on the end where I suspect 
> ' %Z' was intended. In the povr branch I changed to ' %z' as I think the 
> time offset more general.

The `datetime` function with default values works as documented:

"The default for the STRING parameter format is %Y-%m-%d %H:%M:%SZ"


I'm not the author of that functionality, but according to my 
understanding, this is entirely intentional:

Since the information provided by "now" is based on UTC, and the 
`strftime` conversion specifiers are time zone agnostic(*), the printed 
date and time are also with respect to UTC.

In full compliance with ISO 8601, this is indicated by appending a 
literal uppercase `Z` right after the time, which is the official time 
zone designator for UTC.


(*)Except for `%Z` or `%z` of course.

Speaking of which: Appending either of those instead of "Z" would 
actually give a wrong time, unless you first convert `now` to local time.

Also, per ISO 8601 any time zone designator should be appended to the 
time without any intervening space.

[William F Pokorny] Re: POV-Ray v3.8.0-beta 1 - Parse error using "%... [1715 days 12 hours and 19 minutes ago]

Wed, 28 Jul 2021 19:34:17 GMT

On 7/28/21 11:38 AM, jr wrote:
> hi,
> 
> William F Pokorny <ano### [at] anonymousorg> wrote:
...
>> because the default format strings has a 'Z' on the end where I suspect
>> ' %Z' was intended. In the povr branch I changed to ' %z' as I think the
>> time offset more general.
>>
>>    v3.8 (povr) default -> 2021-07-28 08:15:15 -0400
> 
> is this new?  because does not work for me, see below.  

Relatively, I guess. Looks like I updated this with a commit on:

Date:   Fri Jun 11 06:18:44 2021 -0400

where I changed datetime() to optionally generate a time accounting for 
the local daylight savings time datetime(-100000) after getting myself 
tangled up due the generated datetime() string not aligning to my local 
-dst adjusted - computer time. Only %z %Z appear to be dst aware with 
datetime() otherwise.

So... The Z to ' %z' is an update not yet published.

> also, while on 'povr', I
> ran into trouble viewing font glyphs >= chr(256).  

True my text{} isn't POV-Ray's exactly... Is this something unique to 
the povr branch? Off the top of my head, this likely normal unless using 
a unicode string specifications.

---
Aside:

In povr, I'm leaning in a direction of eliminating the text{} object... 
Or, at least, not further updating it.

Christoph has been playing with freetype and making the text{} internals 
prisms as you know. I'm thinking perhaps all characters/glyphs should 
just be include-able objects only where we'd use SDL macros to do all 
the placements for a string -- get POV-Ray, at the core, completely out 
of the text formatting game and push that sort of thing into SDL.

If you look at the text oriented macros shipped today - like 
Circle_Text(), for example, they are actually doing a lot of work to 
pull apart text{} strings character by character. When I do isosurface 
stuff with text{} strings, I often do the same to get to single 
'characters' for better performance. Effectively, pulling text{} objects 
apart - or internally doing this - for most work is a painfully 
backwards way to approach things in my opinion.

Bill P.

[jr] Re: POV-Ray v3.8.0-beta 1 - Parse error using "%... [1715 days 16 hours and 13 minutes ago]

Wed, 28 Jul 2021 15:40:00 GMT

hi,

William F Pokorny <ano### [at] anonymousorg> wrote:
> Just to toss it out there, for as long as I've used datetime(now) as in:
>
> #version 3.8;
> #debug concat("v3.8 default -> ",datetime(now),"\n")
>
> I've gotten back:
>
>   v3.8 default -> 2021-07-28 08:11:16Z
>
> because the default format strings has a 'Z' on the end where I suspect
> ' %Z' was intended. In the povr branch I changed to ' %z' as I think the
> time offset more general.
>
>   v3.8 (povr) default -> 2021-07-28 08:15:15 -0400

is this new?  because does not work for me, see below.  also, while on 'povr', I
ran into trouble viewing font glyphs >= chr(256).  (and thanks for raising the
"constant rounding" thing)

regards, jr.

jr@swift:6:wfp$ c### [at] tpov

#version 3.8;

global_settings {assumed_gamma 1}
box {0,1}

#declare s_ = datetime(now);

#debug concat("datetime v3.8 default: '",s_,"'.\n")

jr@swift:7:wfp$ povr t.pov -gr -gs -d -f
Persistence of Vision(tm) Ray Tracer   (see --license)
Copyright 1991-2021 Persistence of Vision Raytracer Pty. Ltd.
Version 3.8.0-x.povr_1984d6ea.unofficial
  (g++ 5.5.0 @ x86_64-slackware-linux-gnu)
This is an unofficial version compiled by: <jr### [at] swiftlan>

Dynamic optimizations:
  CPU detected: Intel,SSE2,AVX,AVX2,FMA3
  Noise generator: avx2fma3-intel (hand-optimized by Intel)

==== [Parsing...] ==========================================================
datetime v3.8 default: '2021-07-28 15:31:42Z'.
==== [Rendering...] ========================================================
POV-Ray finished

[William F Pokorny] Re: POV-Ray v3.8.0-beta 1 - Parse error using "%... [1715 days 18 hours and 37 minutes ago]

Wed, 28 Jul 2021 13:16:08 GMT

On 7/25/21 4:33 AM, jr wrote:
> hi,
> 
> Thomas de Groot <tho### [at] degrootorg> wrote:
> 
> (thanks, could not post this as I have no MS Windows machine)
> 
> 
>> #declare seed_ = val(datetime(now,"%s"));
> 
> just to confirm, this works on all Linux systems I have access to, incl a Debian
> VM with (oldest) POV-Ray-3.7.0.8.
> 

Just to toss it out there, for as long as I've used datetime(now) as in:

#version 3.8;
#debug concat("v3.8 default -> ",datetime(now),"\n")

I've gotten back:

  v3.8 default -> 2021-07-28 08:11:16Z

because the default format strings has a 'Z' on the end where I suspect 
' %Z' was intended. In the povr branch I changed to ' %z' as I think the 
time offset more general.

  v3.8 (povr) default -> 2021-07-28 08:15:15 -0400

Bill P.

[jr] Re: POV-Ray v3.8.0-beta 1 - Parse error using "%... [1716 days 16 hours and 38 minutes ago]

Tue, 27 Jul 2021 15:15:00 GMT

hi,

clipka <ano### [at] anonymousorg> wrote:
> Am 26.07.2021 um 10:34 schrieb jr:
>> #declare seed_ = mod((now-int(now))*1e16,1e9);
>
> - Variable name should use uppercase as the first letter. Just saying.

:-)  I can live with camelcase like 'fooBarBaz' but..


> - No need for `mod`, as the seeding via `#declare MyRNG = seed(seed_);`
> already effectively does a `mod` operation with a modulus of 2^32 (ca. 4e9).
>
> - Taking the time of day, rather than the running total, is a smart move
> I probably wouldn't have thought of, and had me thinking thrice to
> figure out whether it even has any advantage. (My preliminary
> conclusion: I think it does.)
>
> - Multiplying with 1e16 seems excessive. The value is given in days, and
> has a precision of microseconds at best; 8.64e10 would be the ideal
> factor in that case. Some systems may even provide timers as slow as one
> tick mer millisecond, in which case there would be little point in using
>   a factor larger than 8.64e6.
>
> There might be some point in multiplying with a very large number and
> then applying `mod`, so that seeds quickly diverge. But that doesn't
> work when the multiplying factor is a multiple of the modulus - you'd
> ideally want coprime values for that, otherwise you're not shuffling
> around information, you're just ditching digits.

I guess that ("ditching digits") was the idea.  take away the "constant" part,
shift the decimal point by 16 positions (I was looking at 'now' with
'str(now,0,16)', and all positions are in use/change), then "truncate".


> ...
> The following might do nicely:
>
>      #declare seed_ = (now-int(now))*(1e9+1);

it does (and I'll be using that).  output is more like using "%s", ie
incrementing, than with the "diverging" 'mod()'.


AM: yes, 'pi', neat, though not for this project.  thanks.


regards, jr.

[Alain Martel] Re: POV-Ray v3.8.0-beta 1 - Parse error using "%... [1716 days 17 hours and 13 minutes ago]

Tue, 27 Jul 2021 14:40:25 GMT

Le 2021-07-26 à 14:46, clipka a écrit :
> Am 26.07.2021 um 10:34 schrieb jr:
> 
>> demo scene TdG mentioned simply needs a (fairly) reliable unique seed 
>> for the
>> RNG, whenever it's rendered.  made a couple of quick tests with 'now', 
>> and am
>> thinking of using something like the following to replace the
>> 'datetime(now,"%s")', and would appreciate comment(s):
>>
>> #declare seed_ = mod((now-int(now))*1e16,1e9);
> 
> - Variable name should use uppercase as the first letter. Just saying.
> 
> - No need for `mod`, as the seeding via `#declare MyRNG = seed(seed_);` 
> already effectively does a `mod` operation with a modulus of 2^32 (ca. 
> 4e9).
> 
> - Taking the time of day, rather than the running total, is a smart move 
> I probably wouldn't have thought of, and had me thinking thrice to 
> figure out whether it even has any advantage. (My preliminary 
> conclusion: I think it does.)
> 
> - Multiplying with 1e16 seems excessive. The value is given in days, and 
> has a precision of microseconds at best; 8.64e10 would be the ideal 
> factor in that case. Some systems may even provide timers as slow as one 
> tick mer millisecond, in which case there would be little point in using 
>   a factor larger than 8.64e6.
> 
> 
> There might be some point in multiplying with a very large number and 
> then applying `mod`, so that seeds quickly diverge. But that doesn't 
> work when the multiplying factor is a multiple of the modulus - you'd 
> ideally want coprime values for that, otherwise you're not shuffling 
> around information, you're just ditching digits.
> 
> This should be easy to accomplish by using any odd (in the literal 
> sense) multiplier, while ditching your own mod and relying on the 
> inbuilt mod 2^32 operation. I have a hunch that numbers with a 
> well-balanced number of binary ones and zeros would be ideal.
> 
> The following might do nicely:
> 
>      #declare seed_ = (now-int(now))*(1e9+1);

When I want coprimes, I often plug in pi in the mix, or use two values 
that differ by 1. It could be something like :

#declare Seed_ = mod(now*pi*100000000, 87654321);

[clipka] Re: POV-Ray v3.8.0-beta 1 - Parse error using "%... [1717 days 13 hours and 7 minutes ago]

Mon, 26 Jul 2021 18:46:34 GMT

Am 26.07.2021 um 10:34 schrieb jr:

> demo scene TdG mentioned simply needs a (fairly) reliable unique seed for the
> RNG, whenever it's rendered.  made a couple of quick tests with 'now', and am
> thinking of using something like the following to replace the
> 'datetime(now,"%s")', and would appreciate comment(s):
> 
> #declare seed_ = mod((now-int(now))*1e16,1e9);

- Variable name should use uppercase as the first letter. Just saying.

- No need for `mod`, as the seeding via `#declare MyRNG = seed(seed_);` 
already effectively does a `mod` operation with a modulus of 2^32 (ca. 4e9).

- Taking the time of day, rather than the running total, is a smart move 
I probably wouldn't have thought of, and had me thinking thrice to 
figure out whether it even has any advantage. (My preliminary 
conclusion: I think it does.)

- Multiplying with 1e16 seems excessive. The value is given in days, and 
has a precision of microseconds at best; 8.64e10 would be the ideal 
factor in that case. Some systems may even provide timers as slow as one 
tick mer millisecond, in which case there would be little point in using 
  a factor larger than 8.64e6.


There might be some point in multiplying with a very large number and 
then applying `mod`, so that seeds quickly diverge. But that doesn't 
work when the multiplying factor is a multiple of the modulus - you'd 
ideally want coprime values for that, otherwise you're not shuffling 
around information, you're just ditching digits.

This should be easy to accomplish by using any odd (in the literal 
sense) multiplier, while ditching your own mod and relying on the 
inbuilt mod 2^32 operation. I have a hunch that numbers with a 
well-balanced number of binary ones and zeros would be ideal.

The following might do nicely:

     #declare seed_ = (now-int(now))*(1e9+1);

[Cousin Ricky] Re: POV-Ray v3.8.0-beta 1 - Parse error using "%... [1717 days 16 hours and 59 minutes ago]

Mon, 26 Jul 2021 14:54:21 GMT

On 2021-07-26 4:34 AM (-4), jr wrote:
> 
> and perhaps improve description of 'now'.

The 'now' keyword is documented in the float built-in variables section
of the 3.8 reference manual (as it should be), but unlike most of the
other variables in that section, the word 'now' is not its own header,
so it is easy to miss.  (The same is true of the 'version' keyword.)

The documentation of 'datetime' could use a cross reference to the 'now'
description.

[jr] Re: POV-Ray v3.8.0-beta 1 - Parse error using "%... [1717 days 23 hours and 13 minutes ago]

Mon, 26 Jul 2021 08:40:00 GMT

hi,

clipka <ano### [at] anonymousorg> wrote:

I thank you for the (detailed) clarification re status of "%s" (and yr time).  I
dug up a PDF (N1256, Committee Draft 7.9.2007) and was shocked (sort of) to find
no mention of "%s".

and also a big thank you for writing "..in POV-Ray, `now` already is a numeric
value..", this has cleared up a complete misunderstanding.  the documentation
says 'now' is a "keyword" and only illustrates its use in a 'datetime()' call.
I had not realised that 'now' can be used outside 'datetime()'.  :-)  so the
demo scene TdG mentioned simply needs a (fairly) reliable unique seed for the
RNG, whenever it's rendered.  made a couple of quick tests with 'now', and am
thinking of using something like the following to replace the
'datetime(now,"%s")', and would appreciate comment(s):

#declare seed_ = mod((now-int(now))*1e16,1e9);

> It might be worth weaving the following information into the
> documentation of our "datetime" function:

and perhaps improve description of 'now'.

regards, jr.

[clipka] Re: POV-Ray v3.8.0-beta 1 - Parse error using "%... [1718 days 9 hours and 52 minutes ago]

Sun, 25 Jul 2021 22:00:58 GMT

It might be worth weaving the following information into the 
documentation of our "datetime" function:

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

Which codes are supported depends on the platform POV-Ray is compiled 
an/or running on.

In POV-Ray v3.7, the following codes can be expexted to work reliably:

a,A,b,B,c,d,H,I,j,m,M,p,S,U,w,W,x,X,y,Y,Z,%

In POV-Ray v3.8, the following additional codes can be expexted to work 
reliably:

a,A,b,B,c,C,d,D,e,F,g,G,h,H,I,j,m,M,n,p,r,R,S,t,T,u,U,V,w,W,x,X,y,Y,z,Z,%

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

(Side note: The C99/C++11 standards define additional two-letter codes 
starting with E or O; while those should also work in POV-Ray v3.8, 
their result _will_ differ between systems, depending on the language 
settings of the computer.


(Also, note to self and fellow developers: It may be worth adding a 
check in POV-Ray itself, to verify whether the formatting string 
submitted is actually portable across platforms, and warn if it isn't.)

[clipka] Re: POV-Ray v3.8.0-beta 1 - Parse error using "%... [1718 days 10 hours and 26 minutes ago]

Sun, 25 Jul 2021 21:27:37 GMT

Am 25.07.2021 um 23:23 schrieb clipka:

> For ISO/IEC 9899:1999, that forms the main basis for C++, I only have 

That was supposed to read "... the main basis for C++11". Which is the 
minimum language revision required to build POV-Ray v3.8.

(In POV-Ray v3.7, which requires C++99 as the minimum language version, 
the earlier C89 standard would apply, which is even more limited.)

[clipka] Re: POV-Ray v3.8.0-beta 1 - Parse error using "%... [1718 days 10 hours and 30 minutes ago]

Sun, 25 Jul 2021 21:23:38 GMT

Am 25.07.2021 um 15:28 schrieb jr:

> do you have a reference for the "non-standard", please?  cannot see a mention on
> the pages I looked at, including
> <https://man7.org/linux/man-pages/man3/strftime.3.html>.

(1)

The official reference for the fact that it's non-standard would be the 
official documentation of the C and C++ standards: ISO/IEC 9899 and 
ISO/IEC 14882, respectively, in whatever revision of the language you're 
looking at. Of those, the C documentation is the more interesting, as 
the C++ standard only defines it by reference.

The non-standard status of "%s" is documented in ISO-IEC 9899 by 
absence: It is not mentioned, therefore it is non-standard.

I do not have access to an authoritative copy of any revision of ISO/IEC 
9899 aside a PDF copy of good old ANS/ISO 9899-1990, but there the 
relevant information would be found on page 174, in section 7.12.3.5, 
"The strftime function"

For ISO/IEC 9899:1999, that forms the main basis for C++, I only have 
access to drafts (access to authoritative ISO/IEC standard documents 
requires a license fee). In a PDF titled "ISO/IEC Committee Draft - May 
6, 2005 ISO/IEC 9899:TCs" (which to the best of my knowledge differs 
from ISO/IEC 9899:1999 only in "bugfixes"), the relevant information 
would be found on page 7.23.3.5, "Tthe strftime function".

In the official ANSI PDF release of ISO/IEC 14882:2011(E), the relevant 
information can be found on page 619, section 20.11.8 [date.time] "Date 
and time functions", but it only references the C standard. (The 
footnote explicitly listing conversion specifies from C seems to be 
intended to only explicitly affirm that C++11 supports those specifiers 
added in C99, rather than the smaller set in C89.)


(2)

The page I've linked to, "cppreference.com", is dedicated to faithfully 
documenting the official standard in a more accessible format, and has 
proven quite reliable in being true to the standards and their versions.

The page you're citing documents what is implemented in Linux' glibc. It 
is not authoritative about what to expect from `strftime` on a 100% pure 
standard-conformant system.


(3)

The page you liked to, under "%s", also lists effectively the same 
information as the other man page source I cited:

--------------------------------------------------------------
%s     The number of seconds since the Epoch, 1970-01-01 00:00:00
               +0000 (UTC). (TZ) (Calculated from mktime(tm).)
--------------------------------------------------------------

Again, note the "(TZ)" here. In the section titled "CONFORMING TO", it 
also explains what this "(TZ)" marker means, again just like the man 
page source I cited:

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

        SVr4, C89, C99.  There are strict inclusions between the set of
        conversions given in ANSI C (unmarked), those given in the Single
        UNIX Specification (marked SU), those given in Olson's timezone
        package (marked TZ), and those given in glibc (marked GNU),
        except that %+ is not supported in glibc2.  On the other hand
        glibc2 has several more extensions.  POSIX.1 only refers to ANSI
        C; POSIX.2 describes under date(1) several extensions that could
        apply to strftime() as well.  The %F conversion is in C99 and
        POSIX.1-2001.

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

In other words:
- If it is marked "(GNU)", it is supported by glibc.
- If it is marked "(TZ)", it is supported by glibc and "Olson's timezone 
package"
- If it is marked "(SU)", it is supported by glibc and "Olson's timezone 
package", and standardized for Unix in the Single UNIX Specification.
- If it is unmarked, it is supported by glibc and "Olson's timezone 
package", and standardized for Unix in the Single UNIX Specification and 
ANSI C (which in this case appears to mean ANSI-standard C in general, 
not specifically C89 as would usually be the case. ).


(4)

It may be worth noting that Linux' strftime is _not_ in violation of the 
C (and, by extension, C++) standard, which explicitly states: "If a 
conversion specilier is not one of the above. the behavior is 
undefined." In other words, "%s" may crash the program, produce "F*** 
you" as output, or convert the time to a decimal rendition of the number 
of seconds between the very start of 1970 and the specified time. Any of 
these behaviors are acceptable per the C/C++ standard.

[jr] Re: POV-Ray v3.8.0-beta 1 - Parse error using "%... [1718 days 18 hours and 23 minutes ago]

Sun, 25 Jul 2021 13:30:00 GMT

hi,

clipka <ano### [at] anonymousorg> wrote:
> Am 25.07.2021 um 09:45 schrieb Thomas de Groot:
>
> > #declare seed_ = val(datetime(now,"%s"));
> ...
> Conforming To
>
> SVr4, C89, C99. ...
> TL;DR:
>
> "%s" is a non-standard extension to the `strftime` format, that is not
> universally supported.

do you have a reference for the "non-standard", please?  cannot see a mention on
the pages I looked at, including
<https://man7.org/linux/man-pages/man3/strftime.3.html>.

regards, jr.

[clipka] Re: POV-Ray v3.8.0-beta 1 - Parse error using "%... [1718 days 19 hours and 9 minutes ago]

Sun, 25 Jul 2021 12:44:15 GMT

Am 25.07.2021 um 09:45 schrieb Thomas de Groot:

> #declare seed_ = val(datetime(now,"%s"));

> "POV-Ray's documentation says the "..optional STRING parameter should
> conform to the same formatting as that of the strftime() C function."
> and (lowercase) "%s" is documented as described and used.Â  I assume
> that the Windows 'strftime()' does not provide that option?Â  else it
> would be a POV-Ray on Windows bug, I guess."

 From the Linux man page on die.net (https://linux.die.net/man/3/strftime):
--------------------------------------------------------------
%s

The number of seconds since the Epoch, 1970-01-01 00:00:00 +0000 (UTC). 
(TZ)
--------------------------------------------------------------

For information on what "(TZ)" means, see further on that page:

--------------------------------------------------------------
Conforming To

SVr4, C89, C99. There are strict inclusions between the set of 
conversions given in ANSI C (unmarked), those given in the Single UNIX 
Specification (marked SU), those given in Olson's timezone package 
(marked TZ), and those given in glibc (marked GNU), except that %+ is 
not supported in glibc2. On the other hand glibc2 has several more 
extensions. POSIX.1 only refers to ANSI C; POSIX.2 describes under 
date(1) several extensions that could apply to strftime() as well. The 
%F conversion is in C99 and POSIX.1-2001.
--------------------------------------------------------------

For a list of values officially supported by standard C/C++, see 
https://en.cppreference.com/w/c/chrono/strftime.


TL;DR:

"%s" is a non-standard extension to the `strftime` format, that is not 
universally supported.


Also note that in POV-Ray, `now` already is a numeric value (albeit in 
days, and with 0 corresponding to 2000-1-1, 00:00:00 am UTC). It should 
be trivial to convert to a Unix timestamp without the use of `datetime` 
and `val`, using simple scalar math.

[kurtz le pirate] Re: POV-Ray v3.8.0-beta 1 - Parse error using "%... [1718 days 21 hours and 35 minutes ago]

Sun, 25 Jul 2021 10:18:07 GMT

On 25/07/2021 10:33, jr wrote:

> just to confirm, this works on all Linux systems I have access to, incl a Debian
> VM with (oldest) POV-Ray-3.7.0.8.

Ok on Mac.


#declare DateString = datetime(now,"%s");
#debug concat("DateString     = ",DateString,"\n")

#declare DateNum = val(datetime(now,"%s"));
#debug concat("DateNum        = ",str(DateNum,0,0),"\n")

#declare LongDateString = datetime(now,"%A %e %B %Y %H:%M:%S");
#debug concat("LongDateString = ", LongDateString,"\n")


Result :

DateString     = 1627201022
DateNum        = 1627201022
LongDateString = Sunday 25 July 2021 10:17:02



-- 
Kurtz le pirate
Compagnie de la Banquise

[jr] Re: POV-Ray v3.8.0-beta 1 - Parse error using "%... [1718 days 23 hours and 18 minutes ago]

Sun, 25 Jul 2021 08:35:00 GMT

hi,

Thomas de Groot <tho### [at] degrootorg> wrote:

(thanks, could not post this as I have no MS Windows machine)


> #declare seed_ = val(datetime(now,"%s"));

just to confirm, this works on all Linux systems I have access to, incl a Debian
VM with (oldest) POV-Ray-3.7.0.8.


regards, jr.

[Thomas de Groot] POV-Ray v3.8.0-beta 1 - Parse error using "%s" i... [1719 days and 7 minutes ago]

Sun, 25 Jul 2021 07:45:46 GMT

I am currently testing a macro by jr.: tabulated.inc. In one of his demo 
scenes he uses the following line:

#declare seed_ = val(datetime(now,"%s"));

Using Windows10, and POV-Ray v3.8.0-beta 1, I get the following error:

Parse Error: Invalid formatting code in format string, or resulting 
string too long.

I contacted jr. about this and he answered the following:

"POV-Ray's documentation says the "..optional STRING parameter should
conform to the same formatting as that of the strftime() C function."
and (lowercase) "%s" is documented as described and used.  I assume
that the Windows 'strftime()' does not provide that option?  else it
would be a POV-Ray on Windows bug, I guess."

I mention this error also on behalf of jr. I am not sure about which 
system jr. uses, obviously not Windows, but he will jump in if you need 
to know.

-- 
Thomas

[clipka] Re: Windows XP compatibility [1719 days 14 hours and 5 minutes ago]

Sat, 24 Jul 2021 17:48:16 GMT

As a side note:

Those of you running XP could do us a favor and try what happens if you 
run the installer anyway.


While the NSIS docs claim that the installers we're creating with that 
tool should be compatible with any 32-bit version of Windows all the way 
back to Windows 95. it might be worth verifying nonetheless.


Of course the binaries won't run properly, but that's an entirely 
different matter.

[clipka] Re: Windows XP compatibility [1719 days 14 hours and 14 minutes ago]

Sat, 24 Jul 2021 17:39:15 GMT

Am 22.07.2021 um 15:16 schrieb Mr:

> I am surprised, we are not even talking about dropping windows XP or 32 bits
> compatibility, right?
...
> Correct me if I'm wrong, but the POV core team contingent, does not seem so
> close from being as numerous and ressourcefull of a community as these ones. So
> it sounds reasonable to lower such maintenance burdens on existing developers
> temporarily to allow for a later regrowth of ubiquity which is indeed POV's
> strongest "selling points". If it does have to happen one day, Now is also a
> better time than ever to do such very mild support drops, one at a time, before
> POV 4 gets on the rails and too many breakage at once may feel hard.

The point is, currently there is no truly pressing need to ditch XP 
support (or 32 bit, for that matter).

What we can do, for example, is to proceed as follows:

- Use VS 2019 for the binaries we distribute with the regular 
installers, in hopes that it will give us the best in terms of 
performance. This would make those binaries require at least Windows Vista.

- Use VS 2017 (which is the last version of Visual Studio that should be 
capable of building XP-compatible binaries) for a separate set of 
XP-compatible binaries, to be distributed in a separate installer.


Right now, we've encountered nothing more than a road bump trying to 
compile cmedit.dll in an XP-compatible fashion.

Had the feedback to our question regarding XP been "...(crickets)...", 
we might just have left it at that and not bothered to investigate any 
further. Or maybe only later, after the official v3.8.0 release.

I'm sure it's not a major obstacle, just something somewhere not 
entirely set up properly. Nobody has tried building the cmedit.dll since 
v3.7.0.0, so it might just be something we happen to have borked in the 
meantime.


Even if the problem should turn out to be something larger, there are 
enough other options we could try. In the worst case, there's a clear 
path of having XP users deal with a minor inconvenience most probably 
wouldn't even notice, or possibly mistake for a feature.


(As a side note, the v3.8.0.beta.1 has been compiled with VS 2015, due 
to some other road bump encountered also with respect to cmedit.dll)

[clipka] Re: Windows XP compatibility [1719 days 14 hours and 44 minutes ago]

Sat, 24 Jul 2021 17:08:43 GMT

Am 19.07.2021 um 05:22 schrieb HKarsten:

> As far as I understood, you wound use new features in PovRay, that can run under
> Windows only. PovRay will run on Linux, BSD, MACOS and so forth.

(That sentence doesn't parse in my mind; for clarification: I presume 
you meant "... you wouldn't use...")

That's not entirely true. We try to do this for all of the "main" source 
code. However, we provide different front-ends for different run-time 
environments.

All of those front-ends use _some_ features that are not covered by the 
pure ISO/IEC standard C/C++ language and libraries we're currently 
developing for.

> This means,
> 
> 1) you don't need to use a programming-environment that is limited to a hand of
> operating-systems only. If you use an older programming-environment your
> application is till running on newer systems.

Technically, we need to use a programming environment that is limited to 
whatever operating systems it was designed for. So limits always exist.

We prefer targeting multiple build tools, to increase support.

> 2) another option is to compile a new PovRay statically under Cygwin. Statically
> means, cygwin.dll has to be in the same folder, as PovRay's exe-file and it will
> run under XP with no cygwin-environment installed.

I'm not entirely familiar with Cygwin, but it is my understanding that 
it is intended to take software that expects a Unix run-time 
environment, and runs it on a Windows system.

Note that we currently provide a graphical user interface for Windows, 
but none for Unix. So going for Cygwin would mean depriving the Windows 
users of the UI they currently get.

> Is it than impossible to implement new features to PovRay by taking the source
> of PovRay 3.7 and the programming-environment that was compiling it for good and
> just add these features?? What could it be for you, NEED to have a new
> programming-environment for this?

Had the POV-Ray developers for all these 30 years bought into the 
paradigm you are proposing there, the following would have happened:


-- SCENARIO 1 --

(1) The code would have continued to use C, not C++. Probably good old 
ANSI C (aka C89), to be precise.

(2) Development would have been slower. Far slower, I reckon.

(3) Bugs would be far more common, including crashes, memory leaks, and 
cases where the program would just seem to go berserk for no immediately 
apparent reason.

(4) The code would be a pain to read and wrap your head around.

(5) Implementing multi-core support might not have happened.

(6) OpenEXR support might not have happened.

Here's a very short summary of a few reasons why:

* C is a very low-leve language, making it very verbose in practice, 
making it very clunky. There are a lot of things that you need to do 
explicitly in C that you can let the compiler handle for you 
automatically in C++. This is expecially true since the introduction of 
standardized smart pointers - first in boost, later in TR1, and finally 
in C++11 - which have made development a lot easier.

* The verbosity also leads to a lot of room to accidently forget things 
or get things wrong. If you explicitly need to take care of each and 
every little detail, missing it just once may spell disaster for your 
software.

* POV-Ray does a lot of maths on non-trivial and non-standard data 
types, such as 2D and 3D vectors, 3D rays (defined by an origin and a 
direction), RGB colours, RGBFT colours and matrices. C operations on 
such data types look clunky compared to C++. For instance, in C an 
arbitrary piece of code might look something like this:

     colour_add(A, B, C);
     colour_mul(A, 0.5);
     colour_sub(A, D);

Whereas in C++, if you do a bit of homework up front, the same code 
might end up looking like this:

     A = (B + C) * 0.5 + D;

* ANSI C did not provide support for multithreading out of the box. To 
the contrary, several functions of the runtime libraries were inherently 
unsafe for use in threads. To make use of threads, operating system 
specific libraries would have to be used, both for the thread management 
itself, as well as any thread-unsafe functions. And since the 
implementation of those operating system libraries naturally differs, 
the code would have needed to somehow work around that, trying to 
abstract away the implementation details.

* As for OpenEXR, that library is written purely in C++, and requires 
C++ to call. And although it would presumably have been possible to 
write a C/C++ hybrid wrapper around the things we use from that library, 
and POV-Ray is designed to compile without it, this would have given it 
a much different feel: OpenEXR, as it is now, is an integral part of 
POV-Ray, and omitting it would be considered the exception. In a C-based 
POV-Ray, it might be considered more of a purely optional thing, 
something you should generally not rely on being present. And it might 
never have made it into POV-Ray proper for that reason.

As a matter of fact, the most recent versions of OpenEXR not only 
require C++, but at least C++11.


-- SCENARIO 2 --

(1) The code would have continued to use C, not C++. To start with, it 
would probably have been good old ANSI C (aka C89).

(2) The code would have slowly morphed to include newer language 
features, and nobody would have noticed until someone actually tried to 
compile the new code on an onld platform.

(3) Optionally, the code might have slowly morphed into C++ after all, 
without anybody even realizing.

Here's a very short summary of a few reasons why:

* Developers tend to not use the oldest platforms and compilers around, 
and may not be aware of what features were or were not available in the 
older versions of the language.

In other words, it is difficult to develop strictly for a stable old 
platform when you have new tools at your disposal.

* For some time, POV-Ray developers might have almost exclusively used 
Visual Studio for their own development and testing. If my memory 
doesn't deceive me, there was also a time - which might well have 
coincided - when Visual Stidio technically only supported C++, not C, so 
a developer wouldn't have notice they had slipped in the occasional 
pieces of C++, which wouldn't compile on a strict C compiler.


-- SCENARIO 3 --

(1) POV-Ray proper would have died out at least 10 years ago, because 
this is a hobbyist project and nobody enjoys working with clunky old 
languages when there are so much more elegant and almost equally 
performant languages out there.

(2) Optionally, some people might have started a C++ branch of POV-Ray, 
breaking compatibility to enjoy the more elegant code.


-- ALSO --

No, it IS NOT possible to stick to the same build environment used for 
POV-Ray v3.7.0.0. That would have been VS 2010.

I'm not entirely sure it would run on my computer.

I'm sure I currently don't have it installed.

I'm sure it would need a license to install, which I probably still own, 
but might not be able to dig up. If the licensing server would even 
still be available.

I'm sure it would not create binaries for target platforms later than 
Windows 7 or Windows Server 2008 R2, respectively.

I'm sure there will eventually come a time when Microsoft will release a 
Windows version that will exhibit compatibility issues with binaries 
targeting Windows 7 or Windows Server 2008 R2, respectively. At that 
time, both the build environment and binaries created with it will cease 
to run on then-modern systems.


And had peolpe stuck to the build environment they had used back in the 
times of POV-Ray 1.0, my guess is that they would today be in the 
situation that the good old DOS compilers, while presumably still able 
to run from the command prompt, might have difficulty building binaries 
that run on Windows 10 at all - let alone in 64 bit mode. Or making use 
of AVX. And performance may be poor compared to binaries optimized by 
modern compilers.


All this is not to say that we have any intention of abandoning an 
existing user base - but there are reasons why we may have no other 
viable choice.

Eventually.

Not today.

[Mr] Re: Windows XP compatibility [1721 days 18 hours and 33 minutes ago]

Thu, 22 Jul 2021 13:20:00 GMT

clipka <ano### [at] anonymousorg> wrote:
> Am 18.07.2021 um 17:24 schrieb HKarsten:
> > By the way, I fully support Leroy at this point: PovRay is an old program. I am
> > using it since 1991! And there are a lot of tools, running under DOS, Win95,
> > Win2K.
> > So what if you can run PovRay on Vista, or Win7 up to Win10 or Win11 only?
> > Do you like to run an emulator within an emulator to run your tools one day?
>
> The problem is that as time goes on, there comes a point where we want
> to add new features that we can't implement without breaking
> compatibility with (a) those old operatings systems and/or (b) even the
> newest build tools we can find that still target those operating systems.
>
> One day, the Visual Studio 2017 toolkit will no longer be supported by
> Microsoft, and some time thereafter we will no longer have access to a
> sufficiently secure build environment featuring that piece of software.
> When that happens, that'll be the day when we will definitely have to
> cease supporting XP for good.
>
> You just can't expect to forever have access to the latest and greatest
> new POV-Ray features on the oldest and coldest operating systems.
>
>
> So what's the solution to continue to use those old tools? Well, use a
> matching POV-Ray version, obviously. One from those olden golden days.
>
> That, or indeed run those tools under DOS-Box. I'm not sure how that
> emulator works, but it surely will have ways to export and import files
> from it, right?
>
>
> But the point has been taken: There are still POV-Ray users out there
> who want XP support, so we'll see what we can do.
>
> That's why we've asked.

I am surprised, we are not even talking about dropping windows XP or 32 bits
compatibility, right?

"
Note that the choice between XP-compatibility and performance is a
matter of the build tool used (Visual Studio 2010 will generate
XP-compatible binaries, while Visual Studio 2015 will generate faster
ones), so 64-bit XP-compatible binaries /can/ still be built from the
source code, as can faster 32-bit binaries.
"

And even if we were: So many other software have just recently made much bolder
moves with successfull results:  Blender dropped 32 bits support, Python even
dropped Windows 7 support! Don't get me wrong. I don't mean POV should just do
what others do, and as a user I love being able to compile POV on as many
platforms as possible. But if it slows down the overall innovation, which in
turns prevents from attracting many potential users and developers. that's not
the safest bet, because more users would then anyway be able to port, adapt,
test (and re-iterate) the sources to more platforms, legacy included.

Correct me if I'm wrong, but the POV core team contingent, does not seem so
close from being as numerous and ressourcefull of a community as these ones. So
it sounds reasonable to lower such maintenance burdens on existing developers
temporarily to allow for a later regrowth of ubiquity which is indeed POV's
strongest "selling points". If it does have to happen one day, Now is also a
better time than ever to do such very mild support drops, one at a time, before
POV 4 gets on the rails and too many breakage at once may feel hard.

[jr] Re: Windows XP compatibility [1723 days 19 hours and 43 minutes ago]

Tue, 20 Jul 2021 12:10:00 GMT

hi,

"HKarsten" <nomail@nomail> wrote:
> Hi jr, :)
> If I would have a system, small enough, this would be an option.
> Several times I tried to virtualized my System. Sometimes the drivers are poor
> and  my 3D-Programms, like 3DS-Max, or Maya does not run properly or other
> things happened.

persist.  ;-)  VmWare definitely, and VirtualBox etc likely too, "can do".


> And I still didn't find a host-system, small enough for not being in the way.
> So: as long as my System can run natively, it turned out to be the best way.
> BTW: my 2003 is a pure offline System. It never was connected to the internet
> for even a fragment of a second, and it never will be.

good policy.  even for current systems, in some cases.


> For being connected, I an using Puppy-linux:
> distrowatch.com/table.php?distribution=puppy
>
> Its running from RAM, so if it's going to be compromised, next time booting it
> has forgotten all about it.

yes, I like (the development of) "live" distributions, they all share that
advantage.


> For my 3D-Printer the sclicer is not running on XP for example, and I have to
> use my Linux for it. It's pain in the as to do a reboot just for slicing!
>
> Having a PovRay as plain-static cygwin-exe would be the much nicer way, instead
> of rebooting the machine.

I probably misunderstand, but why then not compile that "slicer" (and or povray)
under cygwin?



regards, jr.

[Bald Eagle] Re: Windows XP compatibility [1724 days 9 hours and 13 minutes ago]

Mon, 19 Jul 2021 22:40:00 GMT

clipka <ano### [at] anonymousorg> wrote:

> You just can't expect to forever have access to the latest and greatest
> new POV-Ray features on the oldest and coldest operating systems.
>
>
> So what's the solution to continue to use those old tools? Well, use a
> matching POV-Ray version, obviously. One from those olden golden days.
>
> That, or indeed run those tools under DOS-Box. I'm not sure how that
> emulator works, but it surely will have ways to export and import files
> from it, right?

So, just thinking out loud:

This whole legacy workflow / tool-chain that he's got going as an example of why
it would be nice to have a growing collection of analogous in-house tools to
perform the scene-building part of the workflow, instead of parting-it-out to
whatever third-party external software things might be available.

I remember Sam Benge posted a very nice pile of rocks/grains that he made using
a dataset generated with Voro++.  It would be nice to have the crackle pattern
points and knobs exposed to the SDL so we had something like that - since making
piles of rocks is something people invariably try to do in POV-Ray.

Chris Cason was generous enough to purchase the rights to Moray so that someday
we can have a GUI modeler for the things that modelers are good for.  And a
modeler like Moray is irrefutably desireable and (in)directly used in
raytracing.

I know that the current paradigm is that "POV-Ray is a raytracer", but creating
the things that will be raytraced by POV-Ray I think is an integral part of the
POV-Ray experience.  And the more "pieces" we own in our own little toolbox, the
less will be lost to changes in OS's, 3rd-party blackbox software, licensing
changes, and other links in the scene-creation chain.

I know that I have suggested a few things in the past that at first glance
"don't have much relation to raytracing", but I do hold firm in my opinion that
they would be valuable scene-creation and modification tools. There are many
people who are, or were, enthusiastic POV-Ray enthusiasts, and would likely be
happy to donate/license the use of their already-written code for various
algorithms to use in future distributions.

Some might even be winding down their careers in computer science and related
fields, and would find contributing new features to the POV-Ray codebase an
enjoyable and rewarding activity.

[HKarsten] Re: Windows XP compatibility [1724 days 13 hours and 3 minutes ago]

Mon, 19 Jul 2021 18:50:00 GMT

Hi jr, :)
If I would have a system, small enough, this would be an option.
Several times I tried to virtualized my System. Sometimes the drivers are poor
and  my 3D-Programms, like 3DS-Max, or Maya does not run properly or other
things happened.
And I still didn't find a host-system, small enough for not being in the way.
So: as long as my System can run natively, it turned out to be the best way.
BTW: my 2003 is a pure offline System. It never was connected to the internet
for even a fragment of a second, and it never will be.

For being connected, I an using Puppy-linux:
distrowatch.com/table.php?distribution=puppy

Its running from RAM, so if it's going to be compromised, next time booting it
has forgotten all about it.

For my 3D-Printer the sclicer is not running on XP for example, and I have to
use my Linux for it. It's pain in the as to do a reboot just for slicing!

Having a PovRay as plain-static cygwin-exe would be the much nicer way, instead
of rebooting the machine.

Best rgds,
Holger

[Thomas de Groot] Re: POV-Ray v3.8.0-beta.1 [1724 days 19 hours and 36 minutes ago]

Mon, 19 Jul 2021 12:17:24 GMT

Rendering a 3.8 version scene which includes functions.inc, I get the 
following parse warning:

"functions.inc" line 167: Parse warning: use of POV-Ray v3.7 keyword 
('deprecated') detected in alleged v3.5 scene.

The only place were version 3.5 is mentioned is precisely at the start 
of functions.inc:

#ifndef(Functions_Inc_Temp)
#declare Functions_Inc_Temp = version;
#version 3.5;
...
#end

At the mentioned line 167 of this /new/ functions.inc shipped with the 
beta, a /new/ if statement has been introduced, not there in previous 
versions:

#if (Functions_Inc_Temp < 3.8)
     #declare deprecated once "f_enneper was broken prior to v3.8; 
results will most likely differ."
              f_enneper = function { internal(18) }
#else
     #declare f_enneper = function { internal(18) }
#end


-- 
Thomas

[jr] Re: Windows XP compatibility [1724 days 22 hours and 33 minutes ago]

Mon, 19 Jul 2021 09:20:00 GMT

hi,

"HKarsten" <nomail@nomail> wrote:
> ...
> If you can't use all this within one system, it's going to become something
> between difficult to freaky.

that's an impressive list of POV-Ray's you've got.  somewhat disagree with yr
argument(s) though.  Windows Server 2003 was "put out to pasture" ten years ago,
and the world has kept turning.  if you used VmWare (for example), you could
turn your existing machine into a VM, and yr Win2003 becomes just "another"
window on yr desktop.

regards, jr.

[HKarsten] Re: Windows XP compatibility [1725 days 4 hours and 28 minutes ago]

Mon, 19 Jul 2021 03:25:00 GMT

Hi clipka :)

As far as I understood, you wound use new features in PovRay, that can run under
Windows only. PovRay will run on Linux, BSD, MACOS and so forth.
This means,

1) you don't need to use a programming-environment that is limited to a hand of
operating-systems only. If you use an older programming-environment your
application is till running on newer systems.

2) another option is to compile a new PovRay statically under Cygwin. Statically
means, cygwin.dll has to be in the same folder, as PovRay's exe-file and it will
run under XP with no cygwin-environment installed.

Is it than impossible to implement new features to PovRay by taking the source
of PovRay 3.7 and the programming-environment that was compiling it for good and
just add these features?? What could it be for you, NEED to have a new
programming-environment for this?

Best rgds,
Holger

[clipka] Re: Windows XP compatibility [1725 days 15 hours and 6 minutes ago]

Sun, 18 Jul 2021 16:47:27 GMT

Am 18.07.2021 um 17:24 schrieb HKarsten:
> By the way, I fully support Leroy at this point: PovRay is an old program. I am
> using it since 1991! And there are a lot of tools, running under DOS, Win95,
> Win2K.
> So what if you can run PovRay on Vista, or Win7 up to Win10 or Win11 only?
> Do you like to run an emulator within an emulator to run your tools one day?

The problem is that as time goes on, there comes a point where we want 
to add new features that we can't implement without breaking 
compatibility with (a) those old operatings systems and/or (b) even the 
newest build tools we can find that still target those operating systems.

One day, the Visual Studio 2017 toolkit will no longer be supported by 
Microsoft, and some time thereafter we will no longer have access to a 
sufficiently secure build environment featuring that piece of software. 
When that happens, that'll be the day when we will definitely have to 
cease supporting XP for good.

You just can't expect to forever have access to the latest and greatest 
new POV-Ray features on the oldest and coldest operating systems.


So what's the solution to continue to use those old tools? Well, use a 
matching POV-Ray version, obviously. One from those olden golden days.

That, or indeed run those tools under DOS-Box. I'm not sure how that 
emulator works, but it surely will have ways to export and import files 
from it, right?


But the point has been taken: There are still POV-Ray users out there 
who want XP support, so we'll see what we can do.

That's why we've asked.

[HKarsten] Re: Windows XP compatibility [1725 days 16 hours and 23 minutes ago]

Sun, 18 Jul 2021 15:30:00 GMT

By the way, I fully support Leroy at this point: PovRay is an old program. I am
using it since 1991! And there are a lot of tools, running under DOS, Win95,
Win2K.
So what if you can run PovRay on Vista, or Win7 up to Win10 or Win11 only?
Do you like to run an emulator within an emulator to run your tools one day?

The oldest program I am using is called "HLA" it's a DOS program. I can run
under DOS-Box, or still under Server2003 in a window. I am using it to produce
high-quality 16-Bit Grayscale High-Field-Maps with craters.
Just think of High-Fields for a moment: Most of the tools, producing 16-Bit
special PovRay-TGA-format! Which of these tools can run in a 64-Bit System??

You would need to forget about most of these tools. But these have just NO
replacement! The only one I know is "World Machine" and it's NO replacement for
HLA! It's just something more within the collection of possibilities. If you are
using high-field-tools, in fact you need to use everything you can get out there
from the last 30 years!

If you can't use all this within one system, it's going to become something
between difficult to freaky.

Best rgds, :)
Holger

[HKarsten] Re: Windows XP compatibility [1725 days 17 hours and 13 minutes ago]

Sun, 18 Jul 2021 14:40:00 GMT

Hi people :)
PovRay is one of the most important programs I am using WindowsServer2003 for.
The system  is almost fully XP-compatible, but has the ability to support up to
64GB RAM and 16 Cores. Still it's a 32BIT-Version of Windows, means that every
running  Program can use 4GB Ram only. And it runs XP-Compatible programs ONLY!

Rendering with older versions of PovRay means, running lots  and lots of
instances, each rendering another frame for example.

Within WindowsServer2003 I am running  the following versions of Povray:
PovRay3.1
PovRay3.1-MegaPOV 0.7
PovRay3.5
PovRay3.5 Dens
PovRay3.5-ML
PovRay3.5-Slime
PovRay3.6
PovRay3.6 Mc
PovRay3.6-MegaPOV 1.2.1
PovRay3.6-PovMan
PovRay3.7
PovRay3.7-Uber

All these version are in use and there running BECAUSE of an old version of
Windows! If a newer version of Povray would NOT run it, I won't be able to use
it!

Please continue running PovRay on XP!

Thanx a lot!
:) Holger

[ingo] Re: spline in, out array bug [1727 days 20 hours and 11 minutes ago]

Fri, 16 Jul 2021 11:42:15 GMT

>in news:60f1546d$1@news.povray.org William F Pokorny wrote:
>> On 7/15/21 4:56 PM, clipka wrote:

Thanks.

-- 
https://ingoogni.nl

[William F Pokorny] Re: spline in, out array bug [1727 days 22 hours and 11 minutes ago]

Fri, 16 Jul 2021 09:42:05 GMT

On 7/15/21 4:56 PM, clipka wrote:
> Am 15.07.2021 um 13:29 schrieb William F Pokorny:
> 
>> Looks like a problem with spline{} block parsing when passing a spline 
>> id. The current Parse_Spline() code expects the spline type token to 
>> exist otherwise it assumes the intent was a linear spline.
>>
>> A fix is to add some dynamic_cast 'type checking' to:
>>
>> GenericSpline *Parser::Parse_Spline()
> 
> Fortunately, there's a more elegant solution: The `GenericSpline` class 
> has a virtual member function, `Clone()`, that is implemented by each 
> subclass to return a newly constructed copy of whatever the actual type 
> of the object is.
> 
> So the code in question can remain as simple as:
> 
>  Â Â Â  if (!New)
>  Â Â Â  {
> 
Â Â Â Â Â Â Â 
if (Old)
> 
Â Â Â Â Â Â Â Â Â Â Â 
New = Old->Clone();
> 
Â Â Â Â Â Â Â 
else
> 
Â Â Â Â Â Â Â Â Â Â Â 
New = new LinearSpline();
>  Â Â Â  }
> 
> Will you do the honors, or shall I?

Please go ahead.

I'll be updating my own pile of code to your cleaner fix - thank you.

Bill P.

[clipka] Re: spline in, out array bug [1728 days 10 hours and 57 minutes ago]

Thu, 15 Jul 2021 20:56:27 GMT

Am 15.07.2021 um 13:29 schrieb William F Pokorny:

> Looks like a problem with spline{} block parsing when passing a spline 
> id. The current Parse_Spline() code expects the spline type token to 
> exist otherwise it assumes the intent was a linear spline.
> 
> A fix is to add some dynamic_cast 'type checking' to:
> 
> GenericSpline *Parser::Parse_Spline()

Fortunately, there's a more elegant solution: The `GenericSpline` class 
has a virtual member function, `Clone()`, that is implemented by each 
subclass to return a newly constructed copy of whatever the actual type 
of the object is.

So the code in question can remain as simple as:

     if (!New)
     {
         if (Old)
             New = Old->Clone();
         else
             New = new LinearSpline();
     }

Will you do the honors, or shall I?

[William F Pokorny] Re: spline in, out array bug [1728 days 20 hours and 24 minutes ago]

Thu, 15 Jul 2021 11:29:03 GMT

On 7/15/21 5:54 AM, ingo wrote:
> In the scene below is spline is defined and then put into an array. When
> it is pulled out of the array it always is a linear spline, instead of
> the original 'curvy' spline. This used not to be the case as one of the
> meshmaker macro's depends on doing this since 3.5.
> 
> I cannot trace back where this behaviour originated as I only have 3.8
> alpha's and beta's here and all show this behaviour. (running win10)
> 
> 
> ---%<------%<------%<---
> #version 3.8;
> 
> global_settings {assumed_gamma 1.0}
> camera {location <0,3.5,-12> look_at <0,1.5,0> angle 40}
> light_source {<500,500,-500> rgb <0.8,0.9,1>}
> 
> #declare A1=spline {
>     cubic_spline
>     -0.5, < 1,-1, 0>
>      0.0, < 1, 0, 0>
>      0.5, < 2, 1, 0>
>      1.0, < 1, 2, 0>
>      1.5, < 1, 3, 0>
> }
> 
> #declare An=array[1]{
>     spline{A1},
> }
> 
> #declare M=500;
> union {
>    #declare Spl=spline{An[0]};
>    #for(I,0,50)
>     sphere {Spl(I/50), 0.04 no_shadow pigment {rgb 1}}
>    #end
> }
> ---%<------%<------%<---
> 
> 

Looks like a problem with spline{} block parsing when passing a spline 
id. The current Parse_Spline() code expects the spline type token to 
exist otherwise it assumes the intent was a linear spline.

A fix is to add some dynamic_cast 'type checking' to:

GenericSpline *Parser::Parse_Spline()

in parser_expressions.cpp so it looks something like:

     if (!New)
     {
         if (Old)
         {
             if (dynamic_cast<LinearSpline *>(Old)!=nullptr)
                 New = new LinearSpline(*Old);
             else if (dynamic_cast<QuadraticSpline *>(Old)!=nullptr)
                 New = new QuadraticSpline(*Old);
             else if (dynamic_cast<CatmullRomSpline *>(Old)!=nullptr)
                 New = new CatmullRomSpline(*Old);
             else if (dynamic_cast<NaturalSpline *>(Old)!=nullptr)
                 New = new NaturalSpline(*Old);
             else
                 throw POV_EXCEPTION_STRING("Internal Error. Pointer to 
existing spline not of a known type.");
//          New = new LinearSpline(*Old); // <-- what is done currently.
         }
         else
             New = new LinearSpline();
     }

Bill P.

[ingo] spline in, out array bug [1728 days 21 hours and 58 minutes ago]

Thu, 15 Jul 2021 09:54:59 GMT

In the scene below is spline is defined and then put into an array. When 
it is pulled out of the array it always is a linear spline, instead of 
the original 'curvy' spline. This used not to be the case as one of the 
meshmaker macro's depends on doing this since 3.5.

I cannot trace back where this behaviour originated as I only have 3.8 
alpha's and beta's here and all show this behaviour. (running win10) 


---%<------%<------%<---
#version 3.8;

global_settings {assumed_gamma 1.0}
camera {location <0,3.5,-12> look_at <0,1.5,0> angle 40}
light_source {<500,500,-500> rgb <0.8,0.9,1>}

#declare A1=spline {
   cubic_spline
   -0.5, < 1,-1, 0>
    0.0, < 1, 0, 0>
    0.5, < 2, 1, 0>
    1.0, < 1, 2, 0>
    1.5, < 1, 3, 0>
}

#declare An=array[1]{
   spline{A1},
}

#declare M=500;
union {
  #declare Spl=spline{An[0]};
  #for(I,0,50)
   sphere {Spl(I/50), 0.04 no_shadow pigment {rgb 1}}
  #end
}
---%<------%<------%<---


-- 
https://ingoogni.nl

[Leroy] Re: Windows XP compatibility [1729 days 13 hours and 28 minutes ago]

Wed, 14 Jul 2021 18:25:00 GMT

"Rafael" <Rof### [at] hotmailcom> wrote:
> I work a lot with POVRay and Windows XP. Generally my own software try to be
> compatible with 32 bit version. It is very useful for me to test compatibility
> with old versions (PovRay 3.5 in DOS mode). My personal opinion: I think it will
> be useful to future Hardware of ALL of countries of the planet.

I use XP also. DOS not so much. I have programed a lot of support programs for
POV. All 32 bit window programs. I now have a windows 10 64 bit computer that
will run all those XP programs. I would like to be able to write a 64 bit
program but as of right now my site is down and I just don't want to.

[Rafael] Windows XP compatibility [1729 days 13 hours and 48 minutes ago]

Wed, 14 Jul 2021 18:05:00 GMT

I work a lot with POVRay and Windows XP. Generally my own software try to be
compatible with 32 bit version. It is very useful for me to test compatibility
with old versions (PovRay 3.5 in DOS mode). My personal opinion: I think it will
be useful to future Hardware of ALL of countries of the planet.

[clipka] POV-Ray v3.8.0-beta.1 [1732 days 19 hours and 56 minutes ago]

Sun, 11 Jul 2021 11:56:51 GMT

It's official now:

https://github.com/POV-Ray/povray/releases/tag/v3.8.0-beta.1


A note to Unix users:

We're now providing Unix-specific source code packages again. We 
recommend that you build from the `povunix-*.tar.gz` tarball, rather 
than the "Source code (tar.gz)" or "Source code (zip)" packages or the 
raw repo contents.


A note to Windows XP users:

Let us know if there are still any of you out there. Otherwise we'll 
presume that Vista (and higher) support should be enough for everybody.


Happy Testing!

[clipka] Re: Finish block dispersion handling. v3.8 (and ... [1738 days 16 hours and 45 minutes ago]

Mon, 5 Jul 2021 15:08:39 GMT

Am 05.07.2021 um 15:14 schrieb Kenneth:

> Basic yet informative! :-)  Those "Unmatched brackets..." warnings seem to be
> 'generic' at times IIRC, causing me to scratch my head in wonder.

Yes, that's why they're categorized as "possible parse error", rather 
than "parse error".

Essentially, that's POV-Ray saying, "I've encountered _something_ I 
haven't expected here at all; did you perhaps forget a closing `}`? No? 
Well, then never mind, and let's see what other complaints I may raise 
that might be more helpful."

[Kenneth] Re: Finish block dispersion handling. v3.8 (and ... [1738 days 18 hours and 38 minutes ago]

Mon, 5 Jul 2021 13:15:00 GMT

clipka <ano### [at] anonymousorg> wrote:
> Am 05.07.2021 um 14:25 schrieb Kenneth:
>
> > 1) Using ONLY dispersion and dispersion_samples in a finish{}block, PLUS an
> > interior{ior} block:
> >
> > Possible Parse Error: Unmatched {
> > ....
> > Parse Error: No matching }, dispersion found instead
> >
> > [This warning message makes no sense, IMO]
>
> It does, because `dispersion` does not belong in `finish`, and never did.

Hmm. It would be nicer for us plebeians if the message said, "The dispersion
keyword is not allowed in a finish block. Use it in an interior block instead."

Basic yet informative! :-)  Those "Unmatched brackets..." warnings seem to be
'generic' at times IIRC, causing me to scratch my head in wonder.

> Using `ior` in `finish` _was_ valid official syntax at some point, and
> you only get a warning for it. Using `dispersion` alongside of it has
> _never_ been valid in `finish`, and you get an error for even trying.
>

Aha! My methodology was wrong. Thanks.

[clipka] Re: Finish block dispersion handling. v3.8 (and ... [1738 days 19 hours and 14 minutes ago]

Mon, 5 Jul 2021 12:39:23 GMT

Am 05.07.2021 um 14:25 schrieb Kenneth:

> 1) Using ONLY dispersion and dispersion_samples in a finish{}block, PLUS an
> interior{ior} block:
> 
> Possible Parse Error: Unmatched {
> ....
> Parse Error: No matching }, dispersion found instead
> 
> [This warning message makes no sense, IMO]

It does, because `dispersion` does not belong in `finish`, and never did.

> 2) Using BOTH ior and dispersion/dispersion_samples in a finish{} block, but NO
> interior {} block:
> 
> Parse Warning: Index of refraction value should be specified in 'interior{...}'
> statement...   Use of this syntax may not be backwards compatible with earlier
> versions of POV-Ray.
> Possible Parse Error: Unmatched {
> ....
> Parse Error: No matching }, dispersion found instead
> 
> [The 'Parse Warning' part of this message seems to indicate that such syntax can
> (or could) be used at some point in the past...but it completely fails in 3.8xx
> -- which makes the 'backwards-compatible' part of the warning no longer
> necessary or even meaningful now. In other words, how can such syntax be used at
> all now if it produces a fatal error anyway? ]

Using `ior` in `finish` _was_ valid official syntax at some point, and 
you only get a warning for it. Using `dispersion` alongside of it has 
_never_ been valid in `finish`, and you get an error for even trying.

> If the 'dispersion' feature was newly added in v3.5-- and was apparently usable
> in a finish{} block at that point(?)-- at what point in POV-ray's later
> development did such syntax start causing *fatal* errors?

Refraction parameters had been deprecated in `finish` even before 
`dispersion` was added to the set of refraction parameters. Using the 
latter in `finish` would _always_ have raised a fatal error: Originally 
because `dispersion` wasn't a thing at all, and later because once it 
became a thing, refraction parameters in `finish` had already ceased to 
be a thing.

[Kenneth] Re: Finish block dispersion handling. v3.8 (and ... [1738 days 19 hours and 23 minutes ago]

Mon, 5 Jul 2021 12:30:00 GMT

[Windows 10, running a v3.8xx 'experimental' pvengine  that piggybacks on
v3.7.0]

Both of these examples produce fatal errors:

1) Using ONLY dispersion and dispersion_samples in a finish{}block, PLUS an
interior{ior} block:

Possible Parse Error: Unmatched {
....
Parse Error: No matching }, dispersion found instead

[This warning message makes no sense, IMO]

2) Using BOTH ior and dispersion/dispersion_samples in a finish{} block, but NO
interior {} block:

Parse Warning: Index of refraction value should be specified in 'interior{...}'
statement...   Use of this syntax may not be backwards compatible with earlier
versions of POV-Ray.
Possible Parse Error: Unmatched {
....
Parse Error: No matching }, dispersion found instead

[The 'Parse Warning' part of this message seems to indicate that such syntax can
(or could) be used at some point in the past...but it completely fails in 3.8xx
-- which makes the 'backwards-compatible' part of the warning no longer
necessary or even meaningful now. In other words, how can such syntax be used at
all now if it produces a fatal error anyway? ]

----------

I tried the same constructs in v3.7.0, and got the same fatal errors and warning
messages.

If the 'dispersion' feature was newly added in v3.5-- and was apparently usable
in a finish{} block at that point(?)-- at what point in POV-ray's later
development did such syntax start causing *fatal* errors?

[clipka] Re: Sample Scene Files [1739 days 19 hours and 29 minutes ago]

Sun, 4 Jul 2021 12:24:28 GMT

Am 04.07.2021 um 09:41 schrieb ingo:

> Just noticed that there seem to be no demo scenes for the meshmaker
> include file. It's a bit hard to build something from just the docs.
> 
> I have several demos. I'll adapt and assemble them and then post them

Awesome! Make sure you document your authorship, and that you're willing 
to license your work under the Creative Commons Attribution-ShareAlike 
3.0 Unported License (CC-BY-SA 3.0).

> where? (lost track of the various discussions)

If you feel like it, how about preparing a pull request for them?

Otherwise, `povray.binaries.scene-files` would be a good place.

[ingo] Re: Sample Scene Files [1740 days and 12 minutes ago]

Sun, 4 Jul 2021 07:41:23 GMT

in news:web.60cd041ea18f97d91f9dae3025979125@news.povray.org Bald Eagle
wrote: 

> Hi folks,

Just noticed that there seem to be no demo scenes for the meshmaker 
include file. It's a bit hard to build something from just the docs.

I have several demos. I'll adapt and assemble them and then post them 
where? (lost track of the various discussions)

Ingo

-- 
https://ingoogni.nl

[Kenneth] Re: Technical verification build "v3.8.0-beta.667" [1740 days 18 hours and 23 minutes ago]

Sat, 3 Jul 2021 13:30:00 GMT

"Kenneth" <kdw### [at] gmailcom> wrote:

>
> When I finish testing this beta and uninstall it, I'll check the Windows
> registry to see if the process was clean and complete.

Sorry for the delay.

So after uninstalling this 667 beta from my Windows 10 Pro machine, and
deleting its remaining folder from the Documents\POV-Ray main folder, there are
still some vestiges of it remaining in the registry. Rather than try to describe
these, I instead made screenshots of the various locations, which I hope are
useful. (Btw, I also deleted the 667 beta's installation .exe file from
'downloads'.) I re-booted my machine several times before starting the
registry search.

I used these search phrases:
3.8-beta
3.8.0-beta
3.8-orgn
3.8.0-orgn

Those last two are 'ROT13'-encrypted registry entries that Windows uses in
certain places (a 'feature' that I've only recently become aware of).

I am certainly no expert at understanding the workings of the registry, so I
don't know if any/all of these are problematic or not (regarding running my
v3.7.0 and/or the v3.8 'experimental' pvengin64 installations that piggyback on
it.) I'll assume that I can delete all of the found entries with no ill effects.

A few of the registry entries were so lengthy text-wise that I couldn't capture
them completely.

[Thomas Debe] Re: Technical verification build "v3.8.0-beta.66... [1741 days 18 hours and 52 minutes ago]

Fri, 2 Jul 2021 13:01:35 GMT

Hello !
After a
make && make check
I call unix/povray --benchmark
call
The scene renders not only slowly (rendered pixels) but also stalls.
I also just wanted to point out, because clang is available for Linux, 
Windows and is system compiler on FreeBSD and MacOS X.

regards
Thomas Debe

[clipka] Re: Finish block dispersion handling. v3.8 (and ... [1742 days 18 hours and 25 minutes ago]

Thu, 1 Jul 2021 13:27:57 GMT

Am 01.07.2021 um 13:37 schrieb William F Pokorny:
> Expect not much of an issue given how long it's been this way, but, FWIW...
> 
> ---
> For backward compatibility we support some interior keywords in the 
> finish block too. The related finish variables are Temp_Caustics, 
> Temp_IOR, Temp_Dispersion and Temp_Refract.
> 
> The documentation doesn't indicate dispersion was ever previously 
> supported for the finish block, but we have partial code for it.
> 
> The finish block parsing is missing for Temp_Dispersion. User's having 
> scenes with finish block dispersion get syntax errors.
> 
> Taking the ior as being specified in the finish block, if a user were to 
> specify dispersion in the interior block, as our documentation 
> indicates, they get confusing results due this code in object.cpp:
> 
> if (Finish->Temp_IOR >= 0.0)
> {
>  Â Â Â  Object->interior->IOR = Finish->Temp_IOR;
>  Â Â Â  Object->interior->Dispersion =
Finish->Temp_Dispersion;
> }
> 
> The defaulted Finish->Temp_Dispersion value (1.0) is used and the user 
> has no way to override the default due the lack of finish { dispersion } 
> parsing.

Refraction settings seem to have been officially moved from `finish` to 
the then-new `interior` in POV-Ray v3.1.

Dispersion was only added later, in POV-Ray v3.5. My guess is that 
whoever added the feature has probably considered whether to extend the 
old in-finish syntax to also support dispersion, but came to no definite 
conclusion, and therefore designed the mechanism under the hood to 
easily support such an extension, but that extension never materialized.

> And, yes, users can mix the interior vs finish block definitions 
> supported in both blocks in confusing ways. We don't warn that 
> conflicting definitions are a problem, and, such conflicts are not 
> flagged during parsing. A finish block ior>0.0 overrides any ior set in 
> the interior block.

A finish block ior >0.0 does trigger a warning, which should be enough 
of an indication for anyone to notice that they're doing an oopsie. If 
they're deliberately continuing to use an entirely undocumented feature 
despite earning warnings, I'd argue that we're not their baby-sitters.

> ---
> Aside:
> The compatibility warning message when you specify, for example, ior in 
> the finish block is misleading. All about backwards compatibility when 
> the concern is, I believe, forward compatibility.
> 
> Index of refraction value should be specified in 'interior{...}' statement.
> Use of this syntax may not be backwards compatible with earlier versions 
> of POV-Ray.

The intention of the message is to say, "when you use this syntax, the 
behavior of this version may not be backwards compatible with that of 
earlier versions".

I'd be happy to hear a better phrasing.

[William F Pokorny] Re: Technical verification build "v3.8.0-beta.66... [1742 days 20 hours and 11 minutes ago]

Thu, 1 Jul 2021 11:42:01 GMT

On 6/29/21 4:15 AM, Thomas Debe wrote:
> I don't only compile but also test the runtime behavior of povray. In 
> this context I noticed with clang builds of povray that the compiler 
> flag -ffast-math has a degrading runtime behavior (more than four times 
> longer runtime). This is not caused by the noise code and can't be 
> explained at first, -Ofast has the same behavior.

What scene(s) were you running when you saw the performance degrade? 
I've not seen this behavior - but I compile with clang more than I run 
with clang compiled code.

FWIW. With respect to -Ofast and g++, I've seen inconsistent results. 
Compiles are more often than not slower with the flag than without. 
Never swings in performance as large as 4x though.

As for the 4x difference, a wild guess is clang is handling some 
'-fast-math' allowed, undefined behavior, differently than gcc.

Bill P.

[William F Pokorny] Finish block dispersion handling. v3.8 (and v3.7). [1742 days 20 hours and 16 minutes ago]

Thu, 1 Jul 2021 11:37:40 GMT

Expect not much of an issue given how long it's been this way, but, FWIW...

---
For backward compatibility we support some interior keywords in the 
finish block too. The related finish variables are Temp_Caustics, 
Temp_IOR, Temp_Dispersion and Temp_Refract.

The documentation doesn't indicate dispersion was ever previously 
supported for the finish block, but we have partial code for it.

The finish block parsing is missing for Temp_Dispersion. User's having 
scenes with finish block dispersion get syntax errors.

Taking the ior as being specified in the finish block, if a user were to 
specify dispersion in the interior block, as our documentation 
indicates, they get confusing results due this code in object.cpp:

if (Finish->Temp_IOR >= 0.0)
{
     Object->interior->IOR = Finish->Temp_IOR;
     Object->interior->Dispersion = Finish->Temp_Dispersion;
}

The defaulted Finish->Temp_Dispersion value (1.0) is used and the user 
has no way to override the default due the lack of finish { dispersion } 
parsing.

And, yes, users can mix the interior vs finish block definitions 
supported in both blocks in confusing ways. We don't warn that 
conflicting definitions are a problem, and, such conflicts are not 
flagged during parsing. A finish block ior>0.0 overrides any ior set in 
the interior block.

---
Aside:
The compatibility warning message when you specify, for example, ior in 
the finish block is misleading. All about backwards compatibility when 
the concern is, I believe, forward compatibility.

Index of refraction value should be specified in 'interior{...}' statement.
Use of this syntax may not be backwards compatible with earlier versions 
of POV-Ray.

Bill P.

[clipka] Re: Technical verification build v3.8.0-beta.x.c... [1742 days 21 hours and 57 minutes ago]

Thu, 1 Jul 2021 09:55:51 GMT

Am 29.06.2021 um 12:07 schrieb clipka:
> We would like your feedback...
> 
> - whether you do indeed see the expected behavior (and if not, what 
> divergent behavior you are seeing)
> - what version of Windows you are using
> - which of the three POV-Ray binaries is actually being run on your 
> system (32-bit, 32-bit SSE2 or 64-bit; see version information in the 
> Message Window)

So far, we have the following results:

- Windows 10: Ok
- Windows 8.1: Ok

Still to be checked:

- Windows 8
- Windows 7
- Windows Vista

- Windows Server 2019
- Windows Server 2016
- Windows Server 2012 R2
- Windows Server 2012
- Windows Server 2008 R2
- Windows Server 2008

While I'm sure we won't get test results for all of these, we'd really 
like some results for Vista. If it works there, I guess we can 
confidently expect it to work on the other versions in between as well.


Happy Testing!
Christoph

[clipka] Re: Pixels since installation [1743 days 3 hours and 58 minutes ago]

Thu, 1 Jul 2021 03:54:56 GMT

Am 30.06.2021 um 23:55 schrieb Mike Horvath:
> It might be fun if POV-Ray kept track of how many pixels have been 
> rendered since installation.

Yes, that sounds like a fun project to procrastinate on instead of 
working on the beta... ;)

[Mike Horvath] Pixels since installation [1743 days 9 hours and 58 minutes ago]

Wed, 30 Jun 2021 21:55:32 GMT

It might be fun if POV-Ray kept track of how many pixels have been 
rendered since installation.


Mike

[clipka] Re: Technical verificationbuildv3.8.0-beta.x.cme... [1743 days 20 hours and 44 minutes ago]

Wed, 30 Jun 2021 11:09:24 GMT

Am 30.06.2021 um 11:11 schrieb Thomas de Groot:

> In the present case, download was interrupted with the message:
> "This file is not commonly downloaded"

Ah! Yes, that makes sense. It _is_ indeed a file that is not commonly 
downloaded. An unsigned executable, none the less. So a download filter 
has every reason to have some level of mistrust.

[Thomas de Groot] Re: Technical verification buildv3.8.0-beta.x.cm... [1743 days 22 hours and 42 minutes ago]

Wed, 30 Jun 2021 09:11:40 GMT

Op 30-6-2021 om 10:06 schreef Thomas de Groot:
> I shall come back later on this when I find out the truth. ;-)
> 
In Firefox, when downloading a file, you get an icon in the toolbar saying:
"Display the progress of ongoing downloads (Ctrl+J)"

In the present case, download was interrupted with the message:
"This file is not commonly downloaded"

and you can go to a menu with explanation about safety and viruses, and 
the possibility to go on downloading or delete the file.

First time I experienced this.

-- 
Thomas

[Thomas de Groot] Re: Technical verification build v3.8.0-beta.x.c... [1743 days 23 hours and 45 minutes ago]

Wed, 30 Jun 2021 08:08:35 GMT

Op 30-6-2021 om 09:06 schreef clipka:
> Am 30.06.2021 um 08:59 schrieb Thomas de Groot:
> 
>>> (4) Copy `povcmax32.dll` and `povcmax64.dll` (but _no_ other DLLs, 
>>> not even `povcmax32-sse2.dll`) from the `.../POV-Ray/v3.7/bin` 
>>> directory of your existing v3.7 installation into the corresponding 
>>> directory of the new installation.
>>>
>> OK
>> (Some extra grumbling about admins rights)
> 
> Something along the lines of, "to copy any stuff into this directory, 
> you need admin rights; do you think you deserve those rights (Yes/No)?", 
> I presume?
> 
> As you probably guessed already, that's perfectly normal at that step.
> 
Yes, that was the message.

> 
> Thanks for testing.

Happy to be of service :-)

-- 
Thomas

[Thomas de Groot] Re: Technical verification build v3.8.0-beta.x.c... [1743 days 23 hours and 47 minutes ago]

Wed, 30 Jun 2021 08:06:03 GMT

Op 30-6-2021 om 09:00 schreef clipka:
> Am 30.06.2021 um 08:48 schrieb Thomas de Groot:
> 
>>> The update povwin-v3.8.0-beta.x.cmedit.669-setup.exe does not 
>>> download (correctly). I only get an empty file: 0 bytes. Using Win10.
>>>
>>
>> OK. Skip that. Firefox blocked the download.
> 
> Did FF give any particular reason for that? And how did you get past it?

To tell the truth, I am a bit mystified. It happened on my other laptop 
(not the present one I am using) and apparently there is there an 
extension/add-on there which 'controls' the downloads. Very first time I 
got an action from it by the way. I need to go back there and see what 
it is exactly; it does not reside on the present laptop and I cannot 
find it (rapid browse) in the Firefox add-ons or extensions.

Anyway, when I found out it blocked the download, I could tell it to 
download anyway, and it did.

I shall come back later on this when I find out the truth. ;-)

-- 
Thomas

[clipka] Re: Technical verification build v3.8.0-beta.x.c... [1744 days and 47 minutes ago]

Wed, 30 Jun 2021 07:06:08 GMT

Am 30.06.2021 um 08:59 schrieb Thomas de Groot:

>> (4) Copy `povcmax32.dll` and `povcmax64.dll` (but _no_ other DLLs, not 
>> even `povcmax32-sse2.dll`) from the `.../POV-Ray/v3.7/bin` directory 
>> of your existing v3.7 installation into the corresponding directory of 
>> the new installation.
>>
> OK
> (Some extra grumbling about admins rights)

Something along the lines of, "to copy any stuff into this directory, 
you need admin rights; do you think you deserve those rights (Yes/No)?", 
I presume?

As you probably guessed already, that's perfectly normal at that step.


Thanks for testing.

[clipka] Re: Technical verification build v3.8.0-beta.x.c... [1744 days and 52 minutes ago]

Wed, 30 Jun 2021 07:00:55 GMT

Am 30.06.2021 um 08:48 schrieb Thomas de Groot:

>> The update povwin-v3.8.0-beta.x.cmedit.669-setup.exe does not download 
>> (correctly). I only get an empty file: 0 bytes. Using Win10.
>>
> 
> OK. Skip that. Firefox blocked the download.

Did FF give any particular reason for that? And how did you get past it?

[Thomas de Groot] Re: Technical verification build v3.8.0-beta.x.c... [1744 days and 54 minutes ago]

Wed, 30 Jun 2021 06:59:35 GMT

Op 29/06/2021 om 12:07 schreef clipka:
> Hi folks,
> 
> another not-quite-beta in our series of "let's not test POV-Ray itself, 
> but all the stuff that surrounds its compilation, deployment and 
> installation":
> 
> https://github.com/POV-Ray/povray/releases/tag/v3.8.0-beta.x.cmedit.669
> 
> This time, we would like you to test-drive an update to the editor DLL 
> mechanism:
> 
> 
> (0) Make sure you have an existing POV-Ray v3.7 installation.
> 
OK

> (1) Make sure to _uninstall_ any of the previous technical verification 
> builds. Most notably, make sure there are no editor DLLs left in the 
> `.../POV-Ray/v3.8-beta/bin` directory that might have somehow found 
> their way there.
> 
OK

> (2) Install the version published at the URL above, _declining_ the 
> installer's offer to download the editor DLLs.
> 
OK

> (3) Run the newly installed POV-Ray version, verifying that it offers 
> you to download the editor DLLs (_decline_ again), and that you can't 
> use the editor.
> 
OK

> (4) Copy `povcmax32.dll` and `povcmax64.dll` (but _no_ other DLLs, not 
> even `povcmax32-sse2.dll`) from the `.../POV-Ray/v3.7/bin` directory of 
> your existing v3.7 installation into the corresponding directory of the 
> new installation.
> 
OK
(Some extra grumbling about admins rights)

> (5) Run the newly installed POV-Ray version, verifying that it does 
> _not_ offer you to download the editor DLLs anymore, and that its editor 
> is now fully functional.
> 
OK

> 
> We would like your feedback...
> 
> - whether you do indeed see the expected behavior (and if not, what 
> divergent behavior you are seeing)
Initially a bit of confusion coming from protesting Firefox and admin, 
but finally worked as expected.

> - what version of Windows you are using
Windows 10

> - which of the three POV-Ray binaries is actually being run on your 
> system (32-bit, 32-bit SSE2 or 64-bit; see version information in the 
> Message Window)
64-bit (as expected)

> Happy testing!
> Christoph

You are welcome.

-- 
Thomas

[Thomas de Groot] Re: Technical verification build v3.8.0-beta.x.c... [1744 days 1 hour and 4 minutes ago]

Wed, 30 Jun 2021 06:48:43 GMT

Op 30/06/2021 om 08:29 schreef Thomas de Groot:
> Op 29/06/2021 om 12:07 schreef clipka:
>> Hi folks,
>>
>> another not-quite-beta in our series of "let's not test POV-Ray 
>> itself, but all the stuff that surrounds its compilation, deployment 
>> and installation":
>>
>> https://github.com/POV-Ray/povray/releases/tag/v3.8.0-beta.x.cmedit.669
>>
> 
> The update povwin-v3.8.0-beta.x.cmedit.669-setup.exe does not download 
> (correctly). I only get an empty file: 0 bytes. Using Win10.
> 

OK. Skip that. Firefox blocked the download.


-- 
Thomas

[Thomas de Groot] Re: Technical verification build v3.8.0-beta.x.c... [1744 days 1 hour and 23 minutes ago]

Wed, 30 Jun 2021 06:29:52 GMT

Op 29/06/2021 om 12:07 schreef clipka:
> Hi folks,
> 
> another not-quite-beta in our series of "let's not test POV-Ray itself, 
> but all the stuff that surrounds its compilation, deployment and 
> installation":
> 
> https://github.com/POV-Ray/povray/releases/tag/v3.8.0-beta.x.cmedit.669
> 

The update povwin-v3.8.0-beta.x.cmedit.669-setup.exe does not download 
(correctly). I only get an empty file: 0 bytes. Using Win10.

-- 
Thomas

[clipka] Technical verification build v3.8.0-beta.x.cmedi... [1744 days 21 hours and 46 minutes ago]

Tue, 29 Jun 2021 10:07:02 GMT

Hi folks,

another not-quite-beta in our series of "let's not test POV-Ray itself, 
but all the stuff that surrounds its compilation, deployment and 
installation":

https://github.com/POV-Ray/povray/releases/tag/v3.8.0-beta.x.cmedit.669

This time, we would like you to test-drive an update to the editor DLL 
mechanism:


(0) Make sure you have an existing POV-Ray v3.7 installation.

(1) Make sure to _uninstall_ any of the previous technical verification 
builds. Most notably, make sure there are no editor DLLs left in the 
`.../POV-Ray/v3.8-beta/bin` directory that might have somehow found 
their way there.

(2) Install the version published at the URL above, _declining_ the 
installer's offer to download the editor DLLs.

(3) Run the newly installed POV-Ray version, verifying that it offers 
you to download the editor DLLs (_decline_ again), and that you can't 
use the editor.

(4) Copy `povcmax32.dll` and `povcmax64.dll` (but _no_ other DLLs, not 
even `povcmax32-sse2.dll`) from the `.../POV-Ray/v3.7/bin` directory of 
your existing v3.7 installation into the corresponding directory of the 
new installation.

(5) Run the newly installed POV-Ray version, verifying that it does 
_not_ offer you to download the editor DLLs anymore, and that its editor 
is now fully functional.


We would like your feedback...

- whether you do indeed see the expected behavior (and if not, what 
divergent behavior you are seeing)
- what version of Windows you are using
- which of the three POV-Ray binaries is actually being run on your 
system (32-bit, 32-bit SSE2 or 64-bit; see version information in the 
Message Window)


Background:

Due to licensing issues, we previously distributed both the 
`cmedit*.dll` and `povcmax*.dll` in an installer package separate form 
the POV-Ray installer. However, this required us to provide new editor 
installers for each new "generation" of POV-Ray that installed in a new 
spearate directory (`v3.7-beta` vs. `v3.7` vs. `v3.8-beta`, and so on), 
even though each time we only need to update `cmedit*.dll`, and even 
though only `povcmax*.dll` is subject to those licensing issues.

There were reasons to do it this way, but we think we have managed to 
find a way around those reasons. We now like to enlist your help to 
confirm that this approach works for all versions of Windows that the 
binaries are intended to support.

If it does indeed work as intended, we will distribute the `cmedit` 
module in the main POV-Ray installer, and package only `povcmax*.dll` in 
the separate editor installer, which can subsequently be left unchanged 
for future versions. Furthermore, our plan is to have the POV-Ray 
installer try to automatically "steal" those DLLs from an existing older 
POV-Ray installation.


Happy testing!
Christoph

[Thomas Debe] Re: Technical verification build "v3.8.0-beta.66... [1744 days 23 hours and 38 minutes ago]

Tue, 29 Jun 2021 08:15:40 GMT

Hello !

>> Yes I can confirm the behavior for clang-10,clang-11 and clang-12.
> 
> "Yes" as in "yes, that's specific to the Unix source package", or as in 
> "yes, they also occur when building from the 'raw' repository source"?
> 
> It can't be both, and to invesigate the matter it would help to know 
> which of the two is the case.

I am sorry, but both packages are affected.

MD5SUM:
8e2b067662f6543885e65b71e4ef1377  povunix-v3.8.0-beta.668.tar.gz
8509e003a48ee55d0068c17064186269  povray-3.8.0-pre-beta.668.tar.gz

povunix:
Compilation settings:
   Build architecture:  x86_64-pc-linux-gnu
   Built/Optimized for: x86_64-pc-linux-gnu
   Compiler vendor:     gnu
   Compiler version:    clang++-10 10.0.1
   Compiler flags:      -pipe -Wno-multichar -Wno-write-strings 
-march=znver2 -mtune=znver2 -O2 -mfma -mavx -mavx2 -pthread
   Libraries:           -lSDL -L/usr/lib64 -lSDL -lpthread -lXpm  -lSM 
-lICE -lX11  -lIlmImf -lIlmImf-2_5 -lImath-2_5 -lHalf-2_5 -lIex-2_5 
-lIexMath-2_5 -lIlmThread-2_5 -pthread  -lIlmThread -ltiff -ljpeg -lpng 
-lz -lrt -lm -lboost_thread -lboost_system -lamdlibm -lm -pthread

No output for optimized noise.

Now with additional CXX-Flag -fgnuc-version=5 as Bill P. suggested.

Compilation settings:
   Build architecture:  x86_64-pc-linux-gnu
   Built/Optimized for: x86_64-pc-linux-gnu
   Compiler vendor:     gnu
   Compiler version:    clang++-10 10.0.1
   Compiler flags:      -pipe -Wno-multichar -Wno-write-strings 
-march=znver2 -mtune=znver2 -O2 -fgnuc-version=5 -mfma -mavx -mavx2 -pthread
   Libraries:           -lSDL -L/usr/lib64 -lSDL -lpthread -lXpm  -lSM 
-lICE -lX11  -lIlmImf -lIlmImf-2_5 -lImath-2_5 -lHalf-2_5 -lIex-2_5 
-lIexMath-2_5 -lIlmThread-2_5 -pthread  -lIlmThread -ltiff -ljpeg -lpng 
-lz -lrt -lm -lboost_thread -lboost_system -lamdlibm -lm -pthread

Output:


Dynamic optimizations:
   CPU detected: AMD,SSE2,AVX,AVX2,FMA3
   Noise generator: avx-generic (compiler-optimized)

This -fgnuc version=5 causes __GNUC__ to be defined by the clang 
compiler. The query of the compiler
is done in unix/povconfig/syspovconfig.h.

 From the clang documentation:

-fgnuc-version=

     This flag controls the value of __GNUC__ and related macros. This 
flag does not enable or disable any GCC extensions implemented in Clang. 
Setting the version to zero causes Clang to leave __GNUC__ and other 
GNU-namespaced macros, such as __GXX_WEAK__, undefined.

With the background of

http://news.povray.org/povray.unix/thread/%3C5b92aa0d%40news.povray.org%3E/

building POV-Ray with clang instead of gcc

I would recommend to include clang in unix/povconfig/syspovconfig.h. 
Clang has the ability to handle this since version 3.1.

I don't only compile but also test the runtime behavior of povray. In 
this context I noticed with clang builds of povray that the compiler 
flag -ffast-math has a degrading runtime behavior (more than four times 
longer runtime). This is not caused by the noise code and can't be 
explained at first, -Ofast has the same behavior.

regards
Thomas Debe

[clipka] Re: Technical verification build "v3.8.0-beta.66... [1746 days 8 hours and 33 minutes ago]

Sun, 27 Jun 2021 23:20:22 GMT

Am 27.06.2021 um 14:33 schrieb Thomas Debe:
> Hello !
> Sorry for the delay !
> 
> Am 24.06.21 um 13:19 schrieb clipka:
> ..
>> Can you please double-check whether these problems are specific to the 
>> Unix source package (povunix-v3.8.0-beta.668.tar.gz), or whether they 
>> also occur when building form the "raw" repository source 
>> (https://github.com/c-lipka/povray/archive/refs/tags/v3.8.0-pre-beta.668.tar.gz)? 
>>
> Yes I can confirm the behavior for clang-10,clang-11 and clang-12.

"Yes" as in "yes, that's specific to the Unix source package", or as in 
"yes, they also occur when building from the 'raw' repository source"?

It can't be both, and to invesigate the matter it would help to know 
which of the two is the case.

> ..
>> Yes - and that is very much deliberate. When AMD provided us with the 
>> AVX/FMA4 optimized code back in mid-2017, they also did some thorough 
>> performance testing on a very diverse farm of ~20 AMD and ~25 Intel 
>> machines, and ended up strongly recommending to specifically *NOT* use 
>> the AVX2/FMA3 optimized code (which had been provided by Intel years 
>> earlier) on AMD processors, but rather give preference to the portable 
>> code, in a variant compiler-optimized for AVX.
> 
> The real background was probably a bug in the FMA3 implementation of the 
> first Ryzen [1].

No, it was a general lack of performance they also observed for older 
FMA3-enabled CPUs. Unless AMD provided us with falsified data, the 
numbers were quite clear.

> The Ryzen was the first processor from AMD to support FMA3. And FMA4 is 
> not officially supported via the CPU flags.

Ryzen was the first to support FMA4. Which did indeed not survive for 
long, at least not officially.

AMD have had FMA3-capable CPUs in their portfolio since 2012, 6 years 
earlier.

> In german:
> [1] 
>
https://www.heise.de/newsticker/meldung/AMD-bestaetigt-FMA3-Bug-bei-Ryzen-3658407.html


That bug did not manifest in performance issues (as far as I know, 
anyway), but in total CPU lockups. We have no indication that this bug 
was ever triggered by POV-Ray's Intel-optimized noise generator.

Also, I'm rather sure the people we had been dealing with at AMD 
expected the Ryzen to support FMA4, so even if the FMA3 bug had been a 
known issue back then and they therefore wanted to avoid running into it 
in POV-Ray, recommending their AVX/FMA4 optimization would have appeared 
to do the job. There would not have been any need to also discourage 
AVX2/FMA3 on AMD CPUs in general.


>>> Solution:
>>>
>>> bool CPUInfo::IsIntel()
>>> {
>>> Â Â return gpData->cpuidInfo.vendorId == kCPUVendor_Intel|| 
>>> kCPUVendor_AMD;
>>> }
>>
>> Um... no, that would be broken on multiple levels. For starters, it 
>> fails to do what you probably intend it to do (it actually makes the 
>> function always return `true`, even if the vendor is neither Intel nor 
>> AMD).
> 
> Like :
> bool CPUInfo::IsIntel()
>  Â {
>  Â Â  return true;
>  Â }
> ????

Yes, that's what the above code boils down to.

The `==` equality test operator binds stronger than the `||` boolean OR 
operator, and constitutes a boolean expression sometimes evaluating as 
true and sometimes as false. The expression to the right of the `||` is 
just an enum constant though, which is automatically promoted to its 
corresponding int value (which is non-zero). Due to its C heritage, C++ 
allows that int value to be used as a boolean, in which case any value 
other than zero is interpreted as "true".

So effectively you have

   return
     (gpData->cpuidInfo.vendorId == kCPUVendor_Intel) ||
     (kCPUVendor_AMD != 0);


Even if you were to put parentheses around the kCPUVendor* codes, it 
would not do what you'd expect:

   return
     gpData->cpuidInfo.vendorId ==
       (kCPUVendor_Intel || kCPUVendor_AMD);

is _not_ asking whether vendorId is any one of these values, but rather 
whether it is equal to the integer representation of the boolean OR of 
the boolean interpretation of the two enum constants' integer IDs:

   return
     gpData->cpuidInfo.vendorId == (
       ( (kCPUVendor_Intel != 0) || (kCPUVendor_AMD != 0) ) ? 1 : 0
     );

So if at least one of the enum constants of kCPUVendor_Intel or 
kCPUVendor_AMD happens to have a non-zero associated int value (which is 
indeed the case), then the function returns true if the vendor ID is 1. 
If on the other hand both enum constants would have an associated int 
value of 0, the function would return true if the vendor ID was 0.


In C++, what you presumably mean would have to be written as:

   return
     ( gpData->cpuidInfo.vendorId == kCPUVendor_Intel ) ||
     ( gpData->cpuidInfo.vendorId == kCPUVendor_AMD );

[Thomas Debe] Re: Technical verification build "v3.8.0-beta.66... [1746 days 19 hours and 20 minutes ago]

Sun, 27 Jun 2021 12:33:04 GMT

Hello !
Sorry for the delay !

Am 24.06.21 um 13:19 schrieb clipka:
..
> Can you please double-check whether these problems are specific to the 
> Unix source package (povunix-v3.8.0-beta.668.tar.gz), or whether they 
> also occur when building form the "raw" repository source 
> (https://github.com/c-lipka/povray/archive/refs/tags/v3.8.0-pre-beta.668.tar.gz)? 
> 
Yes I can confirm the behavior for clang-10,clang-11 and clang-12.
..
> Yes - and that is very much deliberate. When AMD provided us with the 
> AVX/FMA4 optimized code back in mid-2017, they also did some thorough 
> performance testing on a very diverse farm of ~20 AMD and ~25 Intel 
> machines, and ended up strongly recommending to specifically *NOT* use 
> the AVX2/FMA3 optimized code (which had been provided by Intel years 
> earlier) on AMD processors, but rather give preference to the portable 
> code, in a variant compiler-optimized for AVX.

The real background was probably a bug in the FMA3 implementation of the 
first Ryzen [1].
The Ryzen was the first processor from AMD to support FMA3. And FMA4 is 
not officially supported via the CPU flags.
In german:
[1] 
https://www.heise.de/newsticker/meldung/AMD-bestaetigt-FMA3-Bug-bei-Ryzen-3658407.html

>> Solution:
>>
>> bool CPUInfo::IsIntel()
>> {
>> Â Â return gpData->cpuidInfo.vendorId == kCPUVendor_Intel||
kCPUVendor_AMD;
>> }
> 
> Um... no, that would be broken on multiple levels. For starters, it 
> fails to do what you probably intend it to do (it actually makes the 
> function always return `true`, even if the vendor is neither Intel nor 
> AMD).

Like :
bool CPUInfo::IsIntel()
  {
    return true;
  }
????

regards
Thomas Debe

[William F Pokorny] Re: Technical verification build "v3.8.0-beta.66... [1749 days 18 hours and 31 minutes ago]

Thu, 24 Jun 2021 13:21:54 GMT

On 6/23/21 11:20 PM, Thomas Debe wrote:
> 1.) Problem:
> Build povunix-v3.8.9-beta.668.tar.gz Compiler clang-x:
> Optimized Noise-Functions not compiled !
> Clang defines __clang__ Not __GNUC__
> 
> Solution :
> File :Â  unix/povconfig/syspovconfig.h
> 
> Z 169ff:Â  #if defined (__clang__)
> 
Â Â Â Â Â Â Â Â Â Â Â 
#define HAVE_ASM_AVX
> 
Â Â Â Â Â Â Â Â Â Â Â 
#define HAVE_ASM_AVX2
> 
Â Â Â Â Â Â Â Â Â Â Â 
#define HAVE_ASM_FMA3
> 
Â Â Â Â Â Â Â Â Â Â Â 
#define HAVE_ASM_FMA4
> 
Â Â Â Â Â Â Â Â 
#endif
> 
> Z. 179: // most notably platform-specific optimized implementations.
> 
Â Â Â Â Â Â Â 
#if defined (__GNUC__) || defined(__clang__)

With respect to this, remember POV-Ray is, on unix/linux, a gnu tooling 
targeted build. If using clang, it would be normal to use the 
clang/clang++ flag '-fgnuc-version=5', say if your clang supports all 
the variations. Though using my povr branch, I do get the intel hand 
optimizations on my i3 doing clang compiles.

---
Aside: Long been on my list to look at some of the disable build 
configurations Christoph added when enabling the noise optimizations for 
unix/linux. This a new to v3.8 feature for unix/linux users!

It all works to what I can test without and AMD CPU. For example, to 
turn off all the AMD/Intel hand optimizations you build with the 
compiler flags:

-DDISABLE_OPTIMIZED_NOISE_AVXFMA4 -DDISABLE_OPTIMIZED_NOISE_AVX2FMA3 and 
-DDISABLE_OPTIMIZED_NOISE_AVX

On my i3 which has avx I then get a portable avx instruction optimized 
noise(1). If I want that gone too - so I only get whatever optimizations 
the compiler would give me I add:

-DDISABLE_OPTIMIZED_NOISE_AVX_PORTABLE

Pretty cool. I've never set it up, but these configurations make it 
relatively easy to create a set load modules with the differing 
optimizations. We could, for example, look for more of the optimized 
noise performance outliers - scenes where the hand optimized code looked 
to be somewhat slower.

Bill P.

(1) - For those with avx2, wonder what OPTIMIZED_NOISE_AVX2_PORTABLE 
might offer...

[clipka] Re: Technical verification build "v3.8.0-beta.667" [1749 days 19 hours and 35 minutes ago]

Thu, 24 Jun 2021 12:18:34 GMT

Am 24.06.2021 um 13:56 schrieb Kenneth:

> So far, yes, that seems to be the case, if I understand "changing settings". For
> example, under OPTIONS:SCRIPT I/O RESTRICTIONS in the 667 beta, I changed some
> of the stuff there from my usual v3.7 settings and rendered a few scenes, closed
> the program, then checked 3.7 to see if *its* settings had changed: nope, all
> good so far. Ditto the respective quickres render settings. Is this what you
> mean?

Yup.

[Kenneth] Re: Technical verification build "v3.8.0-beta.667" [1749 days 19 hours and 53 minutes ago]

Thu, 24 Jun 2021 12:00:00 GMT

clipka <ano### [at] anonymousorg> wrote:

>
> I presume everything else works fine though - e.g. you can render an
> existing scene using "Render / Select File and Render" (if that's not
> the case, let me know).

[Kenneth]
Ah yes, that does work. (I had never used that particular feature before, ha)
> >
> > Also, for what it's worth, the 667 beta installation does not seem to
> > mess with my v3.7.0 version...
>
> It's more the tiny things that we'd be looking for; most notably, when
> you change settings in the v3.8.0-beta, then close it and open v3.7
> instead, the settings of the latter should be entirely unaffected - and
> vice versa.

So far, yes, that seems to be the case, if I understand "changing settings". For
example, under OPTIONS:SCRIPT I/O RESTRICTIONS in the 667 beta, I changed some
of the stuff there from my usual v3.7 settings and rendered a few scenes, closed
the program, then checked 3.7 to see if *its* settings had changed: nope, all
good so far. Ditto the respective quickres render settings. Is this what you
mean?

When I finish testing this beta and uninstall it, I'll check the Windows
registry to see if the process was clean and complete.

[William F Pokorny] Re: Technical verification build "v3.8.0-beta.66... [1749 days 20 hours ago]

Thu, 24 Jun 2021 11:53:31 GMT

On 6/23/21 7:28 PM, clipka wrote:
> Hi folks,
> 
> This one is specifically for the Unix jockeys among you:
> 
> https://github.com/c-lipka/povray/releases/tag/v3.8.0-pre-beta.668
> 
> 
...

Nice Christoph! Done only spot testing thus far, but looking good.

  g++ (Ubuntu 9.3.0-17ubuntu1~20.04) 9.3.0  (old Intel i3)

I'll try and squeeze in more testing based off the v3.8.0 unix tar ball 
over the coming weeks.

Bill P.

[clipka] Re: Technical verification build "v3.8.0-beta.66... [1749 days 20 hours and 34 minutes ago]

Thu, 24 Jun 2021 11:19:37 GMT

Am 24.06.2021 um 05:20 schrieb Thomas Debe:
> Am 24.06.21 um 01:28 schrieb clipka:
> Hallo Christoph !
> 
> 1.) Problem:
> Build povunix-v3.8.9-beta.668.tar.gz Compiler clang-x:
> Optimized Noise-Functions not compiled !
> Clang defines __clang__ Not __GNUC__

(I presume that's a typo and you mean povunix-v3.8.0-beta.668.tar.gz.)

Can you please double-check whether these problems are specific to the 
Unix source package (povunix-v3.8.0-beta.668.tar.gz), or whether they 
also occur when building form the "raw" repository source 
(https://github.com/c-lipka/povray/archive/refs/tags/v3.8.0-pre-beta.668.tar.gz)?

> 
> Solution :
> File :Â  unix/povconfig/syspovconfig.h
> 
> Z 169ff:Â  #if defined (__clang__)
> 
Â Â Â Â Â Â Â Â Â Â Â 
#define HAVE_ASM_AVX
> 
Â Â Â Â Â Â Â Â Â Â Â 
#define HAVE_ASM_AVX2
> 
Â Â Â Â Â Â Â Â Â Â Â 
#define HAVE_ASM_FMA3
> 
Â Â Â Â Â Â Â Â Â Â Â 
#define HAVE_ASM_FMA4
> 
Â Â Â Â Â Â Â Â 
#endif
> 
> Z. 179: // most notably platform-specific optimized implementations.
> 
Â Â Â Â Â Â Â 
#if defined (__GNUC__) || defined(__clang__)
> 
> 2.) Problem Optimized Noise-Function Compiler: gcc-10
> Povray-Output :
> 
Â Â Â Â Â Â Â Â Â Â Â Â Â Â 
....
> 
> Dynamic optimizations:
>  Â  CPU detected: AMD,SSE2,AVX,AVX2,FMA3
>  Â  Noise generator: avx-generic (compiler-optimized)
> 
> CPU: AMD Ryzen 2700
> cat /proc/cpuinfo | grep avx :Â  se4_1 sse4_2 movbe popcnt aes xsave avx
..
>  Â avx2
>  Â fma
> 
> So it should work with Intels implementation, but there is an vendor 
> check in :
> 
> platform/x86/cpuid.cpp

Yes - and that is very much deliberate. When AMD provided us with the 
AVX/FMA4 optimized code back in mid-2017, they also did some thorough 
performance testing on a very diverse farm of ~20 AMD and ~25 Intel 
machines, and ended up strongly recommending to specifically *NOT* use 
the AVX2/FMA3 optimized code (which had been provided by Intel years 
earlier) on AMD processors, but rather give preference to the portable 
code, in a variant compiler-optimized for AVX.

That was the recommendation for the Windows builds, anyway, but unless I 
see numbers from extensive and thorough analysis of Linux builds, I 
presume Linux compilers are on a similar level when it comes to 
automatic optimization.

There was even some suspicion that Intel might, back in the days, have 
custom-tailored their optimized code specifically to work poorly on AMD 
machines.


If you're seeing performance improvements with Intel's AVX2/FMA3 
hand-optimized code, then by all means use it; but I would recommend 
that you double-check whether it even does any good at all.


> Solution:
> 
> bool CPUInfo::IsIntel()
> {
>  Â return gpData->cpuidInfo.vendorId == kCPUVendor_Intel|| kCPUVendor_AMD;
> }

Um... no, that would be broken on multiple levels. For starters, it 
fails to do what you probably intend it to do (it actually makes the 
function always return `true`, even if the vendor is neither Intel nor 
AMD). And even if it worked as you intend, it would break the whole 
purpose of `CPUInfo::IsIntel()` - namely to detect whether the vendor 
*is*, as a matter of fact, *genuine* Intel.

If it should indeed be the case that modern AMD processors also prefer 
Intel's AVX2/FMA3 hand-optimized code, then what we'd really want to 
change is just the matrix in `platform/x86/optimizednoise.cpp`, which 
tells POV-Ray - based on the CPU features (and vendor!) we detect - what 
optimized noise implementation to use.

[clipka] Re: Technical verification build "v3.8.0-beta.667" [1749 days 21 hours and 40 minutes ago]

Thu, 24 Jun 2021 10:13:12 GMT

Am 24.06.2021 um 11:00 schrieb Kenneth:
> I just tried installing the 667 beta. It appears to load all of its appropriate
> files into its own folders in the the correct places, both  in "Documents" and
> in C:Program Files\POV-ray\  Unfortunately, although the program does start
> successfully, it doesn't actually do anything. (The only thing that works is the
> main HELP file.)
> [...]

TL;DR: You can't create or edit any scene with POV-Ray v3.8.0-beta.667.

I presume everything else works fine though - e.g. you can render an 
existing scene using "Render / Select File and Render" (if that's not 
the case, let me know).

Well, that's way better than beta-666 then, which _genuinely_ didn't 
"actually do anything". It's just perfectly normal behavior for a 
POV-Ray installation without the editor component.

Which we still need to re-build to work nicely with the v3.8.0 betas.


> Also, for what it's worth, the 667 beta installation does not seem to mess with
> my v3.7.0 version; I just fired it up (actually running one of the piggybacked
> 3.8xx experimental versions with it), and all seems well; no problems that I've
> noticed so far.

It's more the tiny things that we'd be looking for; most notably, when 
you change settings in the v3.8.0-beta, then close it and open v3.7 
instead, the settings of the latter should be entirely unaffected - and 
vice versa.

> I have not yet tried to UN-install the 667 beta; I thought I would wait to see
> if the 'proper' editor download is available and hiding somewhere...  ;-)

Not yet. And when it is, we'll probably have a proper beta.1 ready, and 
would strongly recommend uninstalling that beyond-devilish beta.667 
first before installing the beta.1

[Kenneth] Re: Technical verification build "v3.8.0-beta.667" [1749 days 22 hours and 48 minutes ago]

Thu, 24 Jun 2021 09:05:00 GMT

clipka <ano### [at] anonymousorg> wrote:
> Am 18.06.2021 um 20:43 schrieb clipka:
>
> > If you're feeling particularly bold and daring, feel free to test-drive
> > this INSTALLER for us:
 [snip]
> Well, turns out the binaries will not identify as anything - nor
> actually _do_ anything at all, for not really well-explained reasons.
> Which is a bit disappointing on a couple of levels.
>
> The binaries in the following installer should be a bit better-behaved,
> obediently identifying as "v3.8.0-beta.667" - otherwise same deal:
>
> https://github.com/c-lipka/povray/releases/tag/v3.8.0-pre-beta.667
>

Hi, Christoph! It is great to see you back on the newsgroups; you have been
missed indeed. I did read your initial/'new'  post from May 2021-- but only last
night! :-0  Welcome back!

I've been away from the newsgroups and POV-Ray for several months myself; 'real
life' got in the way, as it usually does.

ANYWAY...

I'm running Windows 10 Pro, pre-installed on my new Lenovo desktop computer (8
cores/16 threads). Windows 10.0.19041 (build 19041)

I just tried installing the 667 beta. It appears to load all of its appropriate
files into its own folders in the the correct places, both  in "Documents" and
in C:Program Files\POV-ray\  Unfortunately, although the program does start
successfully, it doesn't actually do anything. (The only thing that works is the
main HELP file.)

There seems to be a problem with the separately-downloaded  'editor' component.
At least, the beta  seems to need that, and an info box comes up asking for it
to be downloaded before the beta will start. And curiously, as soon as I clicked
the 'yes' box there to go to the 'editor'  webpage, the beta automatically
started up! Odd but interesting.

The problem *seems* to be that the beta's main installer is directing us to a
webpage with the wrong 'editor' executable-- for 3.7 rather than 3.8.  The URL
of that webpage looks to be correct:

www.povray.org/download/wineditdll/3.8.0-beta.667

.... but the only editor available there is for "version 3.7.0.0 (released 6
November 2013)"

I tried installing that one anyway, but I think  it attempted to load its DLL's
into my 3.7.0 folder (however,  its own install process said the DLL files were
'skipped', so I don't think they were installed, and didn't over-write what may
have already been in my 3.7 folders.)

So at this point, it looks like the 667 beta *installed* OK, but there's no
'editor' to make it work. (BTW, I ran into the same problem earlier this year,
when trying to download and run v3.7.1 beta 9 again; the separate editor
component didn't work this time, strangely. But maybe that's off-topic here.)

Also, for what it's worth, the 667 beta installation does not seem to mess with
my v3.7.0 version; I just fired it up (actually running one of the piggybacked
3.8xx experimental versions with it), and all seems well; no problems that I've
noticed so far.

I have not yet tried to UN-install the 667 beta; I thought I would wait to see
if the 'proper' editor download is available and hiding somewhere...  ;-)

[Thomas Debe] Re: Technical verification build "v3.8.0-beta.66... [1750 days 4 hours and 33 minutes ago]

Thu, 24 Jun 2021 03:20:37 GMT

Am 24.06.21 um 01:28 schrieb clipka:
Hallo Christoph !

1.) Problem:
Build povunix-v3.8.9-beta.668.tar.gz Compiler clang-x:
Optimized Noise-Functions not compiled !
Clang defines __clang__ Not __GNUC__

Solution :
File :  unix/povconfig/syspovconfig.h

Z 169ff:  #if defined (__clang__)
             #define HAVE_ASM_AVX
             #define HAVE_ASM_AVX2
             #define HAVE_ASM_FMA3
             #define HAVE_ASM_FMA4
          #endif

Z. 179: // most notably platform-specific optimized implementations.
         #if defined (__GNUC__) || defined(__clang__)

2.) Problem Optimized Noise-Function Compiler: gcc-10
Povray-Output :
                ....
		
Dynamic optimizations:
   CPU detected: AMD,SSE2,AVX,AVX2,FMA3
   Noise generator: avx-generic (compiler-optimized)

CPU: AMD Ryzen 2700
cat /proc/cpuinfo | grep avx :  se4_1 sse4_2 movbe popcnt aes xsave avx ..
  avx2
  fma

So it should work with Intels implementation, but there is an vendor 
check in :

platform/x86/cpuid.cpp

Solution:

bool CPUInfo::IsIntel()
{
  return gpData->cpuidInfo.vendorId == kCPUVendor_Intel|| kCPUVendor_AMD;
}

I activated  CHECK_FUNCTIONAL in the optimized functions. No exception
arises. So I think it's ok.


Greetings
Thomas Debe

[clipka] Technical verification build "v3.8.0-beta.668" -... [1750 days 8 hours and 25 minutes ago]

Wed, 23 Jun 2021 23:28:39 GMT

Hi folks,

This one is specifically for the Unix jockeys among you:

https://github.com/c-lipka/povray/releases/tag/v3.8.0-pre-beta.668


I'd like to point your attention specifically to the 
`povunix-v3.8.9-beta.668.tar.gz` tarball, which contains a dedicated 
Unix source package with the following (alleged) features:

- a much leaner package (25 MB instead of 63 MB)
- no need to run that pesky `prebuild.sh`
- all the files in places where Linux gurus expect it

Please give it a spin to see if it does what it's meant to do.


There's also an auto-generated source documentaion in both HTML and PDF 
format (povray-*-sourcedoc-html.7z and povray-*-sourcedoc.pdf, 
respectively), in case you're curious.

(And of course a Windows installer, but there shouldn't be anything new 
to that.)


Have fun testing!
Christoph

[Mr] Re: Visual Studio 2017 or 2019 [1753 days 18 hours and 23 minutes ago]

Sun, 20 Jun 2021 13:30:00 GMT

clipka <ano### [at] anonymousorg> wrote:
> Am 20.06.2021 um 12:29 schrieb Mr:
>
> > I'll close and re-popen the project and try harder to spot any information at
> > the step when I pick platform toolset v142.
>
> Could you have VS 2019 auto-convert the projects to toolset v142, save
> the resulting projects, and post some of them over on
> `povray.beta-test.binaries`?
>
> `povray.vcxproj` and `povbase.vcxproj` should be helpful. Maybe also
> `povray.sln`.
>
> > Could it be that some libraries had relative paths and then the Github system
> > not having the same reference point for relative paths ?
>
> No, I don't think that's it. My money is on some project setting that
> needs to be changed along with the toolset, that we don't account for.

Also take into consideration that I made all the updates that were suggested by
VS at its startup and there were a couple along the past year. Even right now
there is one pending saying version 16.10.2 is now available that I was about to
click.

I just attached to this reply the requested files since I don't see
povray.beta.test.binaries in the http interface to newsgroups.

I added a couple of files that had similar names but different suffixes.

I never actually saved the files but when I made the conversion the first time
it seems to have done so and remembered the toolset, never asking me again if I
wanted to convert files made from an older version.

Don't hesitate to ask whatever else may be needed, and to my private email also
if you feel it's irrelevant to newsgroups... though most of the times such a
public searchable record can be nice for ulterior use.

[clipka] Re: Visual Studio 2017 or 2019 [1753 days 20 hours and 16 minutes ago]

Sun, 20 Jun 2021 11:37:34 GMT

Am 20.06.2021 um 12:29 schrieb Mr:

> I'll close and re-popen the project and try harder to spot any information at
> the step when I pick platform toolset v142.

Could you have VS 2019 auto-convert the projects to toolset v142, save 
the resulting projects, and post some of them over on 
`povray.beta-test.binaries`?

`povray.vcxproj` and `povbase.vcxproj` should be helpful. Maybe also 
`povray.sln`.

> Could it be that some libraries had relative paths and then the Github system
> not having the same reference point for relative paths ?

No, I don't think that's it. My money is on some project setting that 
needs to be changed along with the toolset, that we don't account for.

[clipka] Re: Visual Studio 2017 or 2019 [1753 days 20 hours and 24 minutes ago]

Sun, 20 Jun 2021 11:29:07 GMT

Am 20.06.2021 um 11:55 schrieb Mr:
> Is it only launching the GUI solution or also the "console" and "tests" which
> have unchecked boxes in my current configuration dependency list. And I haven't
> tried building those setups yet.

No, "console" and "tests" are entirely different beasts; neither of 
those is of any direct relevance to POV-Ray for Windows.

[Mr] Re: Visual Studio 2017 or 2019 [1753 days 21 hours and 18 minutes ago]

Sun, 20 Jun 2021 10:35:00 GMT

clipka <ano### [at] anonymousorg> wrote:

> Which leaves the question why we can't build nice working binaries on
> GitHub using the v142 (VS 2019) toolset.

I know nothing about it, but since not sure some stuff is not modified from your
initial settings when opening and converting toolset, let me just copy
(translate from french) some stuff that's in bold in my setup, in case it would
clue you:

Windows SDK version is 10.0
The C++ iso norm is c++14
The C version is MSVC project inherited.
MFC is set to use Standard Windows Library
Floating point model is on Precise (/fp:precise)
Activate type informations at run time (/GR) : set to yes
Whole code optimized for speed (/Ox)(/GL)(/Ot)

Security check is deactivated (/GS-)
Improved instruction set "undefined"
Startup banner removal set to yes (/nologo)
Forcing for loop scope conformity set on  (/Zc:forScope)
Preprocessor definitions :

$(PovBuildDefs)BOOST_ALL_NO_LIB;NDEBUG;WIN32;WIN32_LEAN_AND_MEAN;_WINDOWS;CLASSLIB_DEFS_H;NOMINMAX;ISOLATION_AWARE_ENAB
LED;_CRT_SECURE_NO_DEPRECATE;_SECURE_SCL=0;BUILDING_AMD64=1;COMMONCTRL_VERSION=0x500;_WIN32_WINNT=0x0501;%(Preprocessor
Definitions)

Expand inline function set to Whenever possible  (/Ob2)
Function  level linking deactivated (/Gy-)
Precompiled header, set to be in use (/Yu)
Precompiled header file set to winprecomp.h
Output precompiled header file set to $(IntDir)winprecomp.pch
Disable specific warnings set on with 4800;%(DisableSpecificWarnings)
Forced Include files set to winprecomp.h;%(ForcedIncludeFiles)
Warning level is 3 /WX-  (do  not consider warnings as errors)

Anything else you want me to check ?

I'll close and re-popen the project and try harder to spot any information at
the step when I pick platform toolset v142.

Could it be that some libraries had relative paths and then the Github system
not having the same reference point for relative paths ?

Maybe you could try submitting a totally different branch (such as HGpovray38 or
povr, to find out if the feedback is more verbose or the issue similar? )

[Mr] Re: Visual Studio 2017 or 2019 [1753 days 21 hours and 53 minutes ago]

Sun, 20 Jun 2021 10:00:00 GMT

clipka <ano### [at] anonymousorg> wrote:
> Am 19.06.2021 um 21:46 schrieb Mr:
>
> > /// @def POVRAY_IS_BETA should stay commented right ? (these @ are some comment
> > convention or actual code? sorry, I know nothing about compiled languages yet
> > :-)
>
> To a C++ compiler, anything from `//` to the end of the line is a
> comment (same deal as in POV-Ray's scene language), period. Tampering
> with them will not affect the compiled program.
>
> The `///` and `@def` are indeed comment conventions, namely of a tool
> named Doxygen.
>
> Doxygen is a tool similar to Javadoc, which can build HTML pages listing
> all of the software's functions and classes and methods and stuff. By
> its convention, any comment starting with `///` instead of `//` is
> (generally) a documentation of whatever C++ construct follows, and
> included in those HTML pages accordingly; and certain character
> sequences starting with `@` have special meaning according to that
> convention.
>
> (Specifically, `@def POVRAY_IS_BETA` means that the following
> Doxygen-style comment block is NOT related to the next C++ construct,
> but the preorpcessor macro `POVRAY_IS_BETA` - which happens to be the
> next C++ construct, but only if it isn't commented out.)
>
>
> > So I un-commented only line 114 of version.h and commented out line  128 and got
> > this error when running the same test scene : "Cannot Find Home entry in
> > registry (and cannot infer it)", screenshot attached.
>
> That error is to be expected in this situation when everything works
> "properly".
>
>
> Which leaves the question why we can't build nice working binaries on
> GitHub using the v142 (VS 2019) toolset.

Is it only launching the GUI solution or also the "console" and "tests" which
have unchecked boxes in my current configuration dependency list. And I haven't
tried building those setups yet.

[clipka] Re: Visual Studio 2017 or 2019 [1754 days 7 hours and 16 minutes ago]

Sun, 20 Jun 2021 00:37:08 GMT

Am 19.06.2021 um 21:46 schrieb Mr:

> /// @def POVRAY_IS_BETA should stay commented right ? (these @ are some comment
> convention or actual code? sorry, I know nothing about compiled languages yet
> :-)

To a C++ compiler, anything from `//` to the end of the line is a 
comment (same deal as in POV-Ray's scene language), period. Tampering 
with them will not affect the compiled program.

The `///` and `@def` are indeed comment conventions, namely of a tool 
named Doxygen.

Doxygen is a tool similar to Javadoc, which can build HTML pages listing 
all of the software's functions and classes and methods and stuff. By 
its convention, any comment starting with `///` instead of `//` is 
(generally) a documentation of whatever C++ construct follows, and 
included in those HTML pages accordingly; and certain character 
sequences starting with `@` have special meaning according to that 
convention.

(Specifically, `@def POVRAY_IS_BETA` means that the following 
Doxygen-style comment block is NOT related to the next C++ construct, 
but the preorpcessor macro `POVRAY_IS_BETA` - which happens to be the 
next C++ construct, but only if it isn't commented out.)


> So I un-commented only line 114 of version.h and commented out line  128 and got
> this error when running the same test scene : "Cannot Find Home entry in
> registry (and cannot infer it)", screenshot attached.

That error is to be expected in this situation when everything works 
"properly".


Which leaves the question why we can't build nice working binaries on 
GitHub using the v142 (VS 2019) toolset.

[Mr] Re: Visual Studio 2017 or 2019 [1754 days 12 hours and 3 minutes ago]

Sat, 19 Jun 2021 19:50:00 GMT

> clipka <ano### [at] anonymousorg> wrote:
> >
> > If they seem to work fine, please do me a favor and try again with
> > `#define POVRAY_IS_BETA` enabled and `#define POV_RAY_HOST_VERSION ...`
> > commented out in `source/base/version.h`.

/// @def POVRAY_IS_BETA should stay commented right ? (these @ are some comment
convention or actual code? sorry, I know nothing about compiled languages yet
:-)
So I un-commented only line 114 of version.h and commented out line  128 and got
this error when running the same test scene : "Cannot Find Home entry in
registry (and cannot infer it)", screenshot attached.

[Mr] Re: Visual Studio 2017 or 2019 [1754 days 12 hours and 23 minutes ago]

Sat, 19 Jun 2021 19:30:00 GMT

clipka <ano### [at] anonymousorg> wrote:
> Am 19.06.2021 um 16:25 schrieb Mr:
>
> >> does anyone happen to have VS 2017 and/or VS 2019 installed, and can try
> >> to compile POV-Ray with "Platform Toolset" changed from `v140` to `v141`
> >> or `v142`?
> >>
> >> I'd be interested to hear about your experience: Whether POV-Ray does
> >> compile - whether it runs as expected - and if not, what might prevent
> >> it from doing so.
> > Hello. In Visual Studio 2019, windows 10:
> > *Downloaded this :
> > https://github.com/POV-Ray/povray/archive/refs/heads/master.zip
> >
> > *unzipped and opened this  ...\povray-master\windows\vs2015\povray.sln with
> > option to auto update project toolset to v142
> >
> > *Choosing "Debug" ; and "x64" in the top bar solution config rolldowns.
> >
> > *changing     #define BUILT_BY "YOUR NAME (YOUR EMAIL)" line 128
> > and removing  #error line 129 right below it of
> > .....\povray-master\source\base\build.h
> >
> > *picking GUI in Windows tagrets and top menu Generate > Generate Solution
> >
> > * Waited a while and properly got pvengine64d.exe inside
> > .....\povray-master\windows\vs2015\bin64
> > Output message (originally in french)ended by :
> > ========== Cleanup : 21 succeeded, 0 failed, 2 were ignored ==========
> >
> > * Done a Generate > Cleanup solution and picked Release option before trying
> > that right now!  My computer is an I7 Q720, so should I try Release-AVX or
> > Release-SSE2 after that ?
>
> Thanks for helping dig into this.
>
> To be honest, I did expect it to compile. The big question is: Do the
> binaries actually do anything when you run them?
>
> Mainly interested in the "pure" Debug and Release builds.
>
>
> If they seem to work fine, please do me a favor and try again with
> `#define POVRAY_IS_BETA` enabled and `#define POV_RAY_HOST_VERSION ...`
> commented out in `source/base/version.h`.
>
> I'd also be interested to learn what "auto update project toolset" does
> to the project files, besides changing the toolset from `v140` to `v142`.

Both Debug and Release do render simple scene with radiosity, point
lamp,recursive AA, mesh2 cube, 1000 sphere_sweep union, over global single
scattering media using "version 3.7" statement.
Now trying your suggested changes, assuming both at once right?

[clipka] Re: Visual Studio 2017 or 2019 [1754 days 16 hours and 58 minutes ago]

Sat, 19 Jun 2021 14:54:54 GMT

Am 19.06.2021 um 16:25 schrieb Mr:

>> does anyone happen to have VS 2017 and/or VS 2019 installed, and can try
>> to compile POV-Ray with "Platform Toolset" changed from `v140` to `v141`
>> or `v142`?
>>
>> I'd be interested to hear about your experience: Whether POV-Ray does
>> compile - whether it runs as expected - and if not, what might prevent
>> it from doing so.
> Hello. In Visual Studio 2019, windows 10:
> *Downloaded this :
> https://github.com/POV-Ray/povray/archive/refs/heads/master.zip
> 
> *unzipped and opened this  ...\povray-master\windows\vs2015\povray.sln with
> option to auto update project toolset to v142
> 
> *Choosing "Debug" ; and "x64" in the top bar solution config rolldowns.
> 
> *changing     #define BUILT_BY "YOUR NAME (YOUR EMAIL)" line 128
> and removing  #error line 129 right below it of
> .....\povray-master\source\base\build.h
> 
> *picking GUI in Windows tagrets and top menu Generate > Generate Solution
> 
> * Waited a while and properly got pvengine64d.exe inside
> .....\povray-master\windows\vs2015\bin64
> Output message (originally in french)ended by :
> ========== Cleanup : 21 succeeded, 0 failed, 2 were ignored ==========
> 
> * Done a Generate > Cleanup solution and picked Release option before trying
> that right now!  My computer is an I7 Q720, so should I try Release-AVX or
> Release-SSE2 after that ?

Thanks for helping dig into this.

To be honest, I did expect it to compile. The big question is: Do the 
binaries actually do anything when you run them?

Mainly interested in the "pure" Debug and Release builds.


If they seem to work fine, please do me a favor and try again with 
`#define POVRAY_IS_BETA` enabled and `#define POV_RAY_HOST_VERSION ...` 
commented out in `source/base/version.h`.

I'd also be interested to learn what "auto update project toolset" does 
to the project files, besides changing the toolset from `v140` to `v142`.

[Mr] Re: Visual Studio 2017 or 2019 [1754 days 17 hours and 23 minutes ago]

Sat, 19 Jun 2021 14:30:00 GMT

clipka <ano### [at] anonymousorg> wrote:
> Hi folks,
>
> does anyone happen to have VS 2017 and/or VS 2019 installed, and can try
> to compile POV-Ray with "Platform Toolset" changed from `v140` to `v141`
> or `v142`?
>
> I'd be interested to hear about your experience: Whether POV-Ray does
> compile - whether it runs as expected - and if not, what might prevent
> it from doing so.
Hello. In Visual Studio 2019, windows 10:
*Downloaded this :
https://github.com/POV-Ray/povray/archive/refs/heads/master.zip

*unzipped and opened this  ...\povray-master\windows\vs2015\povray.sln with
option to auto update project toolset to v142

*Choosing "Debug" ; and "x64" in the top bar solution config rolldowns.

*changing     #define BUILT_BY "YOUR NAME (YOUR EMAIL)" line 128
and removing  #error line 129 right below it of
.....\povray-master\source\base\build.h

*picking GUI in Windows tagrets and top menu Generate > Generate Solution

* Waited a while and properly got pvengine64d.exe inside
.....\povray-master\windows\vs2015\bin64
Output message (originally in french)ended by :
========== Cleanup : 21 succeeded, 0 failed, 2 were ignored ==========

* Done a Generate > Cleanup solution and picked Release option before trying
that right now!  My computer is an I7 Q720, so should I try Release-AVX or
Release-SSE2 after that ?

[clipka] Re: Technical verification build "v3.8.0-beta.666" [1754 days 22 hours and 42 minutes ago]

Sat, 19 Jun 2021 09:11:14 GMT

Am 18.06.2021 um 22:47 schrieb Mike Horvath:
> IIRC the last few installers wouldn't prompt users for admin privileges. 
> You had to remember to do so manually. I think admin privileges were 
> required to successfully do the full install.

Please first try without.
 From what I'm seeing at my end, Windows should ask nicely.

[clipka] Technical verification build "v3.8.0-beta.667" [1754 days 22 hours and 55 minutes ago]

Sat, 19 Jun 2021 08:57:55 GMT

Am 18.06.2021 um 20:43 schrieb clipka:

> If you're feeling particularly bold and daring, feel free to test-drive 
> this INSTALLER for us:
> 
> https://github.com/c-lipka/povray/releases/tag/v3.8.0-pre-beta.666
> 
> The software therein will identify as "v3.8.0-beta.666", but it got that 
> label only for technical reasons, and is really more like a pre-beta, 
> and as a matter of fact, we don't care much how that version fares per 
> se: What we're really interested in is the installer.

Well, turns out the binaries will not identify as anything - nor 
actually _do_ anything at all, for not really well-explained reasons. 
Which is a bit disappointing on a couple of levels.

The binaries in the following installer should be a bit better-behaved, 
obediently identifying as "v3.8.0-beta.667" - otherwise same deal:

https://github.com/c-lipka/povray/releases/tag/v3.8.0-pre-beta.667


> Have Fun Testing!
> Christoph

Ditto.

[Thomas de Groot] Re: Sample Scene Files [1755 days and 58 minutes ago]

Sat, 19 Jun 2021 06:55:25 GMT

Op 18/06/2021 om 22:37 schreef Bald Eagle:
> Hi folks,
> 
> Given that there are a LOT of files that will need to be checked and/or
> rewritten, I think it would be a good idea to know who in the community is
> interested in upgrading some of the scenes, so that there is no inadvertent
> duplication of effort.
> 
I am certainly jumping on the band wagon indeed.

Caveat: I *really* (I mean /really/) need to finish the granite project 
first! :-) so forgive me if I do not give any or only scant comments on 
your ideas presently.


-- 
Thomas

[clipka] Visual Studio 2017 or 2019 [1755 days 1 hour and 39 minutes ago]

Sat, 19 Jun 2021 06:14:28 GMT

Hi folks,

does anyone happen to have VS 2017 and/or VS 2019 installed, and can try 
to compile POV-Ray with "Platform Toolset" changed from `v140` to `v141` 
or `v142`?

I'd be interested to hear about your experience: Whether POV-Ray does 
compile - whether it runs as expected - and if not, what might prevent 
it from doing so.

[clipka] Re: POV-Ray v3.8.0-x.freetype.4 [1755 days 10 hours and 5 minutes ago]

Fri, 18 Jun 2021 21:47:51 GMT

Am 18.06.2021 um 22:43 schrieb Mike Horvath:
> I'm curious, but will POV be able to render LaTeX? Or will it still be 
> better to convert LaTeX to SVG, and then use Inkscape to generate the 
> POV code from the SVG?

What?

I don't really see the connection between support for other font 
formats, and support for a complete (and complex) text document format.

Also, why specifically LaTeX? Why not EPS? RTF? PDF? ODF? DOCX? HTML?

I'll go out on a limb here and predict that POV-Ray will never be able 
to render any of these document formats. Not unless you write a suite of 
macros to do the job.


"Dammit Jim, I'm a 3D renderer, not a typesetting engine!"
   -- POV-Ray

[Mike Horvath] Re: Technical verification build "v3.8.0-beta.666" [1755 days 11 hours and 6 minutes ago]

Fri, 18 Jun 2021 20:47:25 GMT

IIRC the last few installers wouldn't prompt users for admin privileges. 
You had to remember to do so manually. I think admin privileges were 
required to successfully do the full install.


Mike

[Mike Horvath] Re: POV-Ray v3.8.0-x.freetype.4 [1755 days 11 hours and 10 minutes ago]

Fri, 18 Jun 2021 20:43:32 GMT

I'm curious, but will POV be able to render LaTeX? Or will it still be 
better to convert LaTeX to SVG, and then use Inkscape to generate the 
POV code from the SVG?


Mike

[Bald Eagle] Sample Scene Files [1755 days 11 hours and 13 minutes ago]

Fri, 18 Jun 2021 20:40:00 GMT

Hi folks,

Given that there are a LOT of files that will need to be checked and/or
rewritten, I think it would be a good idea to know who in the community is
interested in upgrading some of the scenes, so that there is no inadvertent
duplication of effort.

After thinking about this for a while, I had the following ideas:

Since there is a list of technical specifications, perhaps the best way to
affirm that all required items exist and have the appropriate syntax and values
is to have a standard header for all of the files, listing each item, affirming
it is correct, and who checked it.

Dovetailing with this idea is that all of the files should be upgraded
aesthetically so they don't look simplistic or dated - but also that they should
all follow a common theme or "look" - marketing people would call this
"branding".

I mention this, because prior to launching into crafting a ton of scene files,
I'm thinking that perhaps the most efficient way to do this would be to have a
script prepend such a header to each file, and also have a common include file
to set up the basics of the scene, such that all the scenes will have a similar
look, and later tweaks to colors, textures, etc would easily propagate
throughout the whole of the sample scene collection.

Perhaps in the header we could have
#declare Author = "My Name";
and then the include file could be invoked after that and use the sample scene
file author's name as part of a screen.inc branding mask.

I know there are more complex scenes and other scene types where this may either
not work or have to be specially adapted, but I wanted to get some feedback from
the community, and see if we could gauge the interest and coordinate our efforts
to get the most done with the least amount of work, and still produce a nice,
updated collection of files for the current release.

There are likely several people who all have their own versions and improvements
on some of the Insert Menu files, and it would be great to share files, compare
notes, add some nice improvements, and fix some of the existing issues.

- Bill "Bald Eagle" Walker




Those interested probably want to read through the following:
https://wiki.povray.org/content/Documentation:Unix_Section_3#Rendering_the_Sample_Scenes

and perhaps someone should give the referenced shell scripts a look, just to be
on the safe side.

Is there a repository for the source files for the documentation illustrations?
Some of those might prove handy as a starting point for writing new sample
scenes.

[Bald Eagle] Build info [1755 days 11 hours and 43 minutes ago]

Fri, 18 Jun 2021 20:10:00 GMT

When I run my usual version of POV-Ray, I get:

Persistence of Vision(tm) Ray Tracer Version 3.8.0-alpha.unofficial (g++
 -std=gnu++11 5.4.0 @ x86_64-pc-linux-gnu)
This is an unofficial version compiled by:
 Bald Eagle
 The POV-Ray Team is not responsible for supporting this version.

in the text stream.

I'm working on the sample scenes, and was wondering if this information could be
made to be accessible/visible to the SDL.

'version_full' would contain "3.8.0-alpha.unofficial"
and 'owner' would contain "Bald Eagle"

Also useful would be a version of input_file ('file_path') that contains the
full path.

[clipka] Technical verification build "v3.8.0-beta.666" [1755 days 13 hours and 10 minutes ago]

Fri, 18 Jun 2021 18:43:41 GMT

Hi folks,

we're currently testing our build processes as we're spinning up for the 
beta phase of v3.8.0.

If you're feeling particularly bold and daring, feel free to test-drive 
this INSTALLER for us:

https://github.com/c-lipka/povray/releases/tag/v3.8.0-pre-beta.666

The software therein will identify as "v3.8.0-beta.666", but it got that 
label only for technical reasons, and is really more like a pre-beta, 
and as a matter of fact, we don't care much how that version fares per 
se: What we're really interested in is the installer.

Some things you might want to test:

- whether the software installs and runs fine on a "virgin" system that 
never had any other version of POV-Ray installed;

- whether the software installs and runs fine on a system that already 
has one or more other versions of POV-Ray installed, without interfering 
with any of them;

- whether the software uninstalls cleanly.

Also, please keep your eyes peeled for any unexpected behavior that 
might be related to the installation process.


If you're playing guinea pig on this one, please let us know a bit about 
the system you're testing this on, most notably OS version, what other 
versions of POV-Ray are installed, and of course your results. Even if 
everything works flawlessly, we'd like to hear about it.


Note that the binaries in this installer package are not XP-compatible. 
If you still use XP and are keen on seeing continued support for that 
platform, please let us know, and we'll try to get back to you with an 
XP-enabled version. It's extra effort for us though, so we won't be 
doing it unless you let us know that there's still some demand for it.


Have Fun Testing!
Christoph

[William F Pokorny] Re: POV-Ray v3.8.0 - Dropped Features [1761 days 16 hours and 30 minutes ago]

Sat, 12 Jun 2021 15:22:57 GMT

On 6/10/21 2:52 PM, clipka wrote:
> Hi folks,
> 
> A couple of features that were in the last v3.8.0-alpha releases will be 
> reverted as we prepare to enter beta phase:
> 
> 
> - Proper balancing of #end directives, braces, parentheses etc. will not 
> be checked.
> 
> - String literals will again be limited to 256 characters.
> 
> - `defined()`, `#ifdef()` and `#ifndef()` will again return `false` if 
> applied to reserved words.
> 
> - input file encoding will not be auto-detected.
> 
> - boost thread and system libraries will be required again.
> 
> 
> Also, the handling of the `#version` directive and the `version` 
> pseudo-variable are subject to review at this point.
> 
> 
> I _think_ that should be all.

Thanks for the summary, I wondered. Bummer about the boost libraries...

Bill P.

[clipka] POV-Ray v3.8.0 - Dropped Features [1763 days 13 hours and 1 minute ago]

Thu, 10 Jun 2021 18:52:21 GMT

Hi folks,

A couple of features that were in the last v3.8.0-alpha releases will be 
reverted as we prepare to enter beta phase:


- Proper balancing of #end directives, braces, parentheses etc. will not 
be checked.

- String literals will again be limited to 256 characters.

- `defined()`, `#ifdef()` and `#ifndef()` will again return `false` if 
applied to reserved words.

- input file encoding will not be auto-detected.

- boost thread and system libraries will be required again.


Also, the handling of the `#version` directive and the `version` 
pseudo-variable are subject to review at this point.


I _think_ that should be all.

[jr] Re: POV-Ray v3.8.0-alpha.11272893 [1764 days 16 hours and 3 minutes ago]

Wed, 9 Jun 2021 15:50:00 GMT

hi,

clipka <ano### [at] anonymousorg> wrote:
> ... 3.8.0-alpha.11272893

thanks.  compiles/builds, only a handful of warnings re OpenEXR (version 2.2.0,
here).


regards, jr.

[clipka] Re: POV-Ray v3.8.0-x.freetype.4 [1764 days 21 hours and 1 minute ago]

Wed, 9 Jun 2021 10:52:00 GMT

Am 09.06.2021 um 05:17 schrieb William F Pokorny:

> If v3.8 gets released more or less as is - especially with respect to 
> the parser and vm - it will be something like what v3.7 has been for the 
> next 5-10 years. It'll be the stable release 'most' people run. Some of 
> my play might still be of use to the POV-Ray community working around 
> such a stable v3.8 release.

The status quo of the parser is halfway between here and there, so 
especially with respect to the parser, releasing "as-is" won't be an option.

However, see the latest dev newsletter on this issue for the direction 
things are going to head. I guess it's effectively what you are asking for.


> Aside: I say all the above actually sort of wanting the freetype 
> improvements... It's cool, worthwhile work. I understand too, I'm not a 
> typical user.

Just to be clear: Those two recent releases don't bring any new 
features. They just introduce some fixes to the alpha development 
branch, and the experimental FreeType branch, respectively.

Frankly, they're more the result of me checking whether all our tools 
still work as they should than anything else. That, and me wanting to 
make a statement that POV-Ray development has officially been restarted.

[Paolo Gibellini] Re: POV-Ray v3.8.0-x.freetype.4 [1765 days 1 hour and 25 minutes ago]

Wed, 9 Jun 2021 06:28:37 GMT

clipka wrote on 07/06/2021 16:22:
> This is pretty much the same as the alpha just published, but with the 
> new `text` handling.
> 
> 
> https://github.com/POV-Ray/povray/releases/tag/v3.8.0-x.freetype.4
> 

Thank you, Clipka!

Paolo

[William F Pokorny] Re: POV-Ray v3.8.0-x.freetype.4 [1765 days 4 hours and 35 minutes ago]

Wed, 9 Jun 2021 03:17:48 GMT

On 6/7/21 10:22 AM, clipka wrote:
> This is pretty much the same as the alpha just published, but with the 
> new `text` handling.
> 

Related too, to the recent developer emails...

I want to say in a public forum - what would help folks like me most is 
an official release of v3.8 more or less exactly (with fixes) as it 
stood when you went on a walk-about years back Christoph!

Why did Tor Olav back out the use of your terrific v3.8 tuple SDL 
enhancement in his vectors.inc documentation? Because, he has to write 
examples to work with v3.7 for 'most' users.

Those of us wanting to make use of the substantial improvements made in 
v3.8 had no choice - after waiting around for a long time - but to treat 
your last v3.8 commit as an effective release. I've now got a mountain 
of stuff written against your last v3.8 commit. This is what it is.

To the degree you and other core developers 'move' the eventual v3.8 
release to be some cool newer, great 'thing,' - you, Chris and whoever 
else deciding - will be screwing those of us long exploiting v3.8 
features, over. I'm now way off in the weeds with source code, scenes 
and include files written mostly against how v3.8 master has now stood 
for YEARS.

If v3.8 gets released more or less as is - especially with respect to 
the parser and vm - it will be something like what v3.7 has been for the 
next 5-10 years. It'll be the stable release 'most' people run. Some of 
my play might still be of use to the POV-Ray community working around 
such a stable v3.8 release.

Plus! I'll be motivated to work on maintenance fixes to the then newer 
v3.8 stable branch as to some degree I'll need to to keep v3.8 compiling 
too. :-)

I'm not now much motivated to play or chase any later and greater 
'official' POV-Ray releases as I was doing for a long time. I'm sorry. 
I'm old. I have ideas with which I want to play - I made the decision to 
to break on v3.8 where it stalled.

Bill P.

Aside: I say all the above actually sort of wanting the freetype 
improvements... It's cool, worthwhile work. I understand too, I'm not a 
typical user.

[Ash Holsenback] Re: POV-Ray v3.8.0-x.freetype.4 [1765 days 7 hours and 10 minutes ago]

Wed, 9 Jun 2021 00:43:31 GMT

On 6/8/21 8:33 PM, clipka wrote:
> Am 08.06.2021 um 20:48 schrieb Ash Holsenback:
> 
>> checking for libfreetype version >= 2.4.0... 2.10.1, ok
>>
>> that last version check seems odd... i'm at 2.10.1 but it passed, and 
> 
> Why, yes, of course.
> 
> Remember that the actual version "2.10.1" is _not_ "two one zero one", 
> but "two ten one".
> 
> Which is greater-or-equal to the required version "2.4.0", which is "two 
> four zero".

lol... gotcha. old eye's saw 1 not 10 for some reason. there's a couple 
of ironies there that i won't even get into

[clipka] Re: POV-Ray v3.8.0-x.freetype.4 [1765 days 7 hours and 20 minutes ago]

Wed, 9 Jun 2021 00:33:09 GMT

Am 08.06.2021 um 20:48 schrieb Ash Holsenback:

> checking for libfreetype version >= 2.4.0... 2.10.1, ok
> 
> that last version check seems odd... i'm at 2.10.1 but it passed, and 

Why, yes, of course.

Remember that the actual version "2.10.1" is _not_ "two one zero one", 
but "two ten one".

Which is greater-or-equal to the required version "2.4.0", which is "two 
four zero".

[Ash Holsenback] Re: POV-Ray v3.8.0-x.freetype.4 [1765 days 13 hours and 5 minutes ago]

Tue, 8 Jun 2021 18:48:04 GMT

On 6/7/21 10:22 AM, clipka wrote:
> This is pretty much the same as the alpha just published, but with the 
> new `text` handling.
> 
> 
> https://github.com/POV-Ray/povray/releases/tag/v3.8.0-x.freetype.4
> 
> Differences to the Alpha:
> 
> - `text` now supports TrueType-, PostScript- amd OpenType fonts. For 
> now, the syntax remains unchanged, including the `ttf` keyword; the font 
> format is detected automagically.
> 
> - Fonts installed in the system can be accessed directly by replacing 
> `ttf FILENAME` with `sys FONTNAME`, optionally followed by `bold` and/or 
> `talic`; e.g. `text { sys "Arial" bold ... }`. (Windows version only for 
> now)
> 
> - `text` objects now render a bit faster.
> 
> Known caveats:
> 
> - Glyph positions may be slightly different. This is not a bug but a 
> feature, as the old code's glyph positioning algorithm wasn't quite right.
> 
> - Needs FreeType 2 on Unix, otherwise `text` primitive will be disabled 
> entirely. (Comes bundled with FreeType 2 source code for Windows builds.)
> 
> - The `internal NUMBER` mechanism for accessing fonts is currently 
> restricted to the `timrom.ttf` font.
> 
> 
> Differences to `v3.8.0-x.freetype.3`:
> 
> - `text` object performance restored, and even improved. (Turns out the 
> previous versions wasted time rendering whitespace, of all things.)
> 
> - Based on latest Alpha.
> 
> 
> Have fun testing!

checking whether to use the FreeType library... yes
checking for pkg-config... (cached) pkg-config
checking for FreeType's include path... -I/usr/include/freetype2
checking for library containing FT_Init_FreeType... -lfreetype
checking ft2build.h usability... yes
checking ft2build.h presence... yes
checking for ft2build.h... yes
checking for libfreetype version >= 2.4.0... 2.10.1, ok

that last version check seems odd... i'm at 2.10.1 but it passed, and 
built properly. no testing yet... time for an espresso

[Ash Holsenback] Re: POV-Ray v3.8.0-alpha.11272893 [1765 days 13 hours and 10 minutes ago]

Tue, 8 Jun 2021 18:43:20 GMT

On 6/7/21 8:14 AM, clipka wrote:
> It's been a while.
> 
> https://github.com/POV-Ray/povray/releases/tag/v3.8.0-alpha.11272893
> 
> 
> Not much new yet, just a few bugfixes and compatibility improvements:
> 
> - TGA transparency fixed (thanks Bill).
> 
> - Parser should no longer gang on `#undef` of a numeric variable.
> 
> - Unix build process should no longer gag on `#include <version>` 
> somewhere in the boost libraries on certain systems (primarily seen on 
> macOS).
> 
> 
> Also some older fixes that hadn't made it into a development release yet:
> 
> - Windows console version should no longer fail to build with some 
> complaints about `strdup` (though by now it might have other woes again).
> 
> - Fixed some Unix build issue related to the SDL library.
> 
> 
> Anyone who would rather test-drive a version with overhauled `text` 
> handling may want to wait a few moments, I'll release one of those later 
> today.

absolutely /no/ errors from prebuild.sh... likewise no hitches with 
configure and make.

btw: i'm on latest opensuse leap

[Mr] Re: POV-Ray v3.8.0-alpha.11272893 [1765 days 22 hours and 33 minutes ago]

Tue, 8 Jun 2021 09:20:00 GMT

clipka <ano### [at] anonymousorg> wrote:
> It's been a while.
>
> https://github.com/POV-Ray/povray/releases/tag/v3.8.0-alpha.11272893
>
>
> Not much new yet, just a few bugfixes and compatibility improvements:
>
> - TGA transparency fixed (thanks Bill).
>
> - Parser should no longer gang on `#undef` of a numeric variable.
>
> - Unix build process should no longer gag on `#include <version>`
> somewhere in the boost libraries on certain systems (primarily seen on
> macOS).
>
>
> Also some older fixes that hadn't made it into a development release yet:
>
> - Windows console version should no longer fail to build with some
> complaints about `strdup` (though by now it might have other woes again).
>
> - Fixed some Unix build issue related to the SDL library.
>
>
> Anyone who would rather test-drive a version with overhauled `text`
> handling may want to wait a few moments, I'll release one of those later
> today.

Great, thank you !

[Thomas de Groot] Re: POV-Ray v3.8.0-x.freetype.4 [1766 days 17 hours and 8 minutes ago]

Mon, 7 Jun 2021 14:45:17 GMT

Op 7-6-2021 om 16:22 schreef clipka:
> This is pretty much the same as the alpha just published, but with the 
> new `text` handling.
> 

Thank you indeed.

-- 
Thomas

[clipka] POV-Ray v3.8.0-x.freetype.4 [1766 days 17 hours and 31 minutes ago]

Mon, 7 Jun 2021 14:22:09 GMT

This is pretty much the same as the alpha just published, but with the 
new `text` handling.


https://github.com/POV-Ray/povray/releases/tag/v3.8.0-x.freetype.4

Differences to the Alpha:

- `text` now supports TrueType-, PostScript- amd OpenType fonts. For 
now, the syntax remains unchanged, including the `ttf` keyword; the font 
format is detected automagically.

- Fonts installed in the system can be accessed directly by replacing 
`ttf FILENAME` with `sys FONTNAME`, optionally followed by `bold` and/or 
`talic`; e.g. `text { sys "Arial" bold ... }`. (Windows version only for 
now)

- `text` objects now render a bit faster.

Known caveats:

- Glyph positions may be slightly different. This is not a bug but a 
feature, as the old code's glyph positioning algorithm wasn't quite right.

- Needs FreeType 2 on Unix, otherwise `text` primitive will be disabled 
entirely. (Comes bundled with FreeType 2 source code for Windows builds.)

- The `internal NUMBER` mechanism for accessing fonts is currently 
restricted to the `timrom.ttf` font.


Differences to `v3.8.0-x.freetype.3`:

- `text` object performance restored, and even improved. (Turns out the 
previous versions wasted time rendering whitespace, of all things.)

- Based on latest Alpha.


Have fun testing!

[ingo] Re: POV-Ray v3.8.0-alpha.11272893 [1766 days 18 hours and 22 minutes ago]

Mon, 7 Jun 2021 13:31:26 GMT

in news:60be0d8a$1@news.povray.org clipka wrote:

> It's been a while.
> 
> 

Thank you.

-- 
https://ingoogni.nl

[clipka] POV-Ray v3.8.0-alpha.11272893 [1766 days 19 hours and 39 minutes ago]

Mon, 7 Jun 2021 12:14:02 GMT

It's been a while.

https://github.com/POV-Ray/povray/releases/tag/v3.8.0-alpha.11272893


Not much new yet, just a few bugfixes and compatibility improvements:

- TGA transparency fixed (thanks Bill).

- Parser should no longer gang on `#undef` of a numeric variable.

- Unix build process should no longer gag on `#include <version>` 
somewhere in the boost libraries on certain systems (primarily seen on 
macOS).


Also some older fixes that hadn't made it into a development release yet:

- Windows console version should no longer fail to build with some 
complaints about `strdup` (though by now it might have other woes again).

- Fixed some Unix build issue related to the SDL library.


Anyone who would rather test-drive a version with overhauled `text` 
handling may want to wait a few moments, I'll release one of those later 
today.

[clipka] Re: v3.8 Clean up TODOs. kNoiseGen_Default switc... [1775 days 10 hours and 38 minutes ago]

Sat, 29 May 2021 21:15:00 GMT

William F Pokorny <ano### [at] anonymousorg> wrote:
> Documenting some cleanup which I think should happen on any resumption
> of v3.8 work. It's work I am doing in my cut down povr.
>
> In working on pattern / function handling changes (documented mostly in
> the non-web presented newsgroup povray.beta-test.binaries(1)) the
> following code caught my eye in the granite pattern:
>
>          switch (noise_generator)
>          {
>              case kNoiseGen_Default:  // <---- ????
>              case kNoiseGen_Original:
>                  temp = 0.5 - Noise (tv2, noise_generator);
>                  temp = fabs(temp);
>                  break;
>
>              default:
>                  temp = 1.0 - 2.0 * Noise (tv2, noise_generator);
>                  temp = fabs(temp);
>                  if (temp>0.5) temp=0.5;
>                  break;
>          }
>
> kNoiseGen_Default "Indicates that the scene's global settings noise
> generator should be used." It's not the local pattern noise default
> and should not be used as such. The coding is harmless to result, but
> not completely to performance - the case statement should be removed and
> also in wrinkles. Perhaps there are other such uses - turbulence??? Not
> looked.

I should note that the documentation of `kNoiseGen_Default` is probably not
authoritative. Judging by the comment style, it was probably added by me, and
I'm sure I did so to document my understanding of things at the time I added
them, which may have be flawed. (Of course, today I understand every jot of the
code...)

It is entirely possible that `kNoiseGen_Default` is used for multiple
independent things that use noise generators, and used in the documented sense
in some places, and in other senses elsewhere.

> The above issue got me looking more at the noise code and CPU specific
> optimizations. The AMD optimization file:
>
>        platform/x86/avxfma4/avxfma4noise.cpp
>
> is missing the #if CHECK_FUNCTIONAL test blocks comparing results to the
> non-optimized portable Noise and DNoise code which exists in the other
> optimization files. Looks like the check existed when Noise / DNoise was
> in texture.cpp - so this I think missed when the file above was created
> in the v3.8 / master branch.

To the best of my knowledge, the `CHECK_FUNCTIONAL` stuff is an artifact of the
approach Intel used on their end back in the days to make sure the optimized
code variants they provided for the AVX instruction sets were faithful to the
original unoptimized code, apparently testing the function "on the job" in a
living POV-Ray build, rather than in a dedicated testbed. when they later
adapted the code to optimize it for the AVX2/FMA3 instruction set, they seem to
have simply left it in there, or re-used it for the very same purpose. This is
also the reason why I never bothered to throw it out: Don't fuss with code that
some 3rd party provided for us, in case we ever want them to re-visit their
code.

Their counterparts at AMD, who provided the AVX/FMA4 optimizations, presumably
started from the original non-optimized noise, and did not use the same approach
for testing, so they had no reason to leave the same kind of artifacts in there.

> Lastly, I'll ramble a little about what look to me to be less than clear
> statements in comments about mean, media and ranges which led me to take
> detailed looks at the distributions on my machine

Welcome to my world: POV-Ray is full of old code that has not been documented at
all, documented vaguely, imprecisely, sometimes wrong or no longer in sync with
the code, and where it is highly precise it tends to also be utterly
incomprehensible for anyone but an expert in the field. And more often than not
the corresponding code is written for maximum performance on antiquated
compilers that provided little in the way of automated optimizations, so the
code itself also tends to be highly unintelligible.

The earliest pieces of the POV-Ray source code are 30 years old now.

[clipka] Re: Hello darkness (was Re: 3.8 and text {}) [1775 days 11 hours and 33 minutes ago]

Sat, 29 May 2021 20:20:00 GMT

Dick Balaska <dic### [at] buckosoftcom> wrote:

> I think really my only way out is to bite the bullet, surrender to
> clipka, and rework the whole shebang to gamma 1.0.

All that, only to suppress some parser warnings about `text`?

There had been some attempts to clean up character encoding related stuff (you
know, ASCII vs. Latin-1 vs. Windows-1252 vs. Windows-1251 vs. Mac OS Roman vs.
UTF-8 vs. UCS-2 vs. UTF-16 vs. Whatever-Have-You) that turned out to stretch its
dirty tentacles deep into the heart of the `text` code, revealing that the
POV-Ray default fonts are totally borked, etc etc...

The 2019 status of POV-Ray was right smack-bang in the middle of trying to get
to grips with all that madness. Unless I run away screaming again, the current
state of affairs with overzealous text-related warnings will settle down a bit.
For starters, I guess I could spare you a few warnings as long as you promise to
stick to ASCII characters only...

> It's only 90,984 lines of lovingly handcrafted SDL.  (And 17,047 lines
> of Java and 9,799 lines of c++ giving 68,245 separate images.)
>
> How hard can it be?
>
> [insert maniacal laughter here]

Not too shabby. That's actually in a similar ballbark as the POV-Ray back-end
(22k Base, 48k Core, 23k Parser, 5k POVMS, 7k miscellaneous Backend, last time
someone counted; for a total of about 105k lines of code).

Indeed, how hard can it possibly be...

[William F Pokorny] v3.8 Issues with dictionary copies. [1813 days 18 hours and 34 minutes ago]

Wed, 21 Apr 2021 13:18:54 GMT

Documenting fixes(***) for v3.8 dictionary bugs discussed in the thread:

http://news.povray.org/povray.general/thread/%3C607689e7%241%40news.povray.org%3E/

XnsAD0BC42BCF8Aseed7@news.povray.org

---

In symboltable.cpp Change:

SymbolTable::SymbolTable(const SymbolTable& obj)
{
     for (int i = SYM_TABLE_SIZE - 1; i >= 0; i--)
     {
         SYM_ENTRY* oldEntry = obj.mapHashTable[i];
         while (oldEntry)
         {
             SYM_ENTRY* newEntry = Copy_Entry(oldEntry);
             newEntry->next = obj.mapHashTable[i];
             mapHashTable[i] = newEntry;
             oldEntry = oldEntry->next;
         }
     }
}

to:

SymbolTable::SymbolTable(const SymbolTable& obj)
{
     for (int i = SYM_TABLE_SIZE - 1; i >= 0; i--)
     {
         mapHashTable[i] = nullptr; // ***
         SYM_ENTRY* oldEntry = obj.mapHashTable[i];
         while (oldEntry)
         {
             SYM_ENTRY* newEntry = Copy_Entry(oldEntry);
             newEntry->next = mapHashTable[i]; // ***
             mapHashTable[i] = newEntry;
             oldEntry = oldEntry->next;
         }
     }
}

Bill P.

[ingo] Re: File png/ppm gamma issues. v3.8. [1840 days and 18 minutes ago]

Fri, 26 Mar 2021 07:35:05 GMT

in news:605c323d@news.povray.org William F Pokorny wrote:

> OK.

Thanks for investigating Bill,

Ingo

[William F Pokorny] Re: File png/ppm gamma issues. v3.8. [1841 days 1 hour and 5 minutes ago]

Thu, 25 Mar 2021 06:48:29 GMT

On 3/22/21 7:34 AM, William F Pokorny wrote:
...
> 
> More on the png greyscale (single channel png) differences when I 
> decipher more.
> 

OK. In png.cpp there is a conditional block starting with:

...
else if ((color_type == PNG_COLOR_TYPE_GRAY) && (bit_depth <= 8))
...

and near the bottom of the block there is the conditional:

ImageDataType imagetype = options.itype;
if (imagetype == ImageDataType::Undefined)
{
     imagetype = has_alpha ?
	ImageDataType::GrayA_Int8 : ImageDataType::Gray_Int8;
}

and this should read:

ImageDataType imagetype = options.itype;
if (imagetype == ImageDataType::Undefined)
{
     imagetype = ImageDataType::Colour_Map;
}

The code is creating a color map type image in the way the conditional 
block previous does for 'actual' color mapped png images.

The bug is sitting there in v3.7 too, but I guess because greyscale 
output in v3.7 is 16 bit we don't trip it.

What this means is a valid work around for v3.8 based users is to 
specify bit depths >8 (9..16) greyscale out as that code appears to work OK.

Detail:
-------
That conditional block in question looks to be an attempt to 'pretend' 
<= 8 bit gray images are palleted images. It allows each of the 256 
valid greys to be gamma converted once instead of by pixel. The trouble 
is in setting the image type to either of those Gray*Int8 types, we end 
up getting the 'image' class's Image::SetIndexedValue method instead of 
the ColourMapImage class's Image::SetIndexedValue method (got to love c++).

This results in the incoming grey values not being used as index values 
into the created faked color map directly, but rather as indexes into 
code setting explicit RGBA values using the color map. The mystery to me 
is partly how the class mechanisms work at all(1) here and further that 
the result is as close as it is.

(1) - The compile should probably die here, but as the classes set up, 
somehow things don't.

There are some further questions too with this conditional block... 
First, for images with no mapped alpha channels, or single transparent 
color, the block isn't needed. It can be commented and the code already 
handling the >8 bit depths works too for <=8 bit depths with 'perhaps' 
some performance impact.

There are png encodings which can mark a particular color as transparent 
and this block 'perhaps' can handle some of them - though who knows. It 
looks to me like there is no actual png palette grey encoding, but 
rather only a color one. Further, the >8 bit grey scale READ code in 
POV-Ray does not handle single transparent colors that I can see. So 
guess on the surface, looks to me like grey encoding of more specialized 
palette or value transparency is iffy.

In my own code I've also added:

// PNG variously supports bit depths of 1,2,4,8 and 16. Below only
// depths of 8 and 16 look reliable to me.
POV_IMAGE_ASSERT((bit_depth == 8) || (bit_depth == 16));

to see if I turn up some of the odd encodings at some point and then I 
can perhaps look at what's happening in those cases.

(The above is the storage channel depth, not the 'value' bit depth 
(bucketing) v3.8 now allows to be set 1..16.)

There are in the current png library, methods which promote odd 
encodings and grey encodings to 8 or 16 bit rgb(a). Perhaps it's 
possible to make the current png read code simpler and more robust - if 
'perhaps' not quite as fast in some cases.

Lastly
------
Yes, this last bug a bit off in the weeds as most people writing grey 
pngs for height fields will probably use 16 bits. It's only those 
wanting to read <=8 bit png grey scale images.

Bill P.

[William F Pokorny] Re: File png/ppm gamma issues. v3.8. [1843 days 20 hours and 18 minutes ago]

Mon, 22 Mar 2021 11:34:52 GMT

On 3/20/21 1:31 PM, William F Pokorny wrote:
...
> 
> ---Â  png gamma issue.
...
> 
With respect to the current v3.8 not writing a png srgb gamma block 
unless somewhere File_Gamma is set to 'srgb', the current v3.7 looks to 
be OK. If the gamma correction used was srgb, explictly or not, the srgb 
block is always written.

Somewhere during the v3.71 / v3.8 work something changed - but I cannot 
pick up the cause just reading the code. And! this time I'm not going to 
spend 3-4 hours compiling different historical commits to try which 
commit broke things.

The fix in the png.cpp file is to change:

#if defined(PNG_WRITE_sRGB_SUPPORTED)
     if (options.encodingGamma &&
             typeid(*options.encodingGamma) == typeid(SRGBGammaCurve))
         png_set_sRGB(png_ptr, info_ptr, PNG_sRGB_INTENT_PERCEPTUAL);
#endif // PNG_WRITE_gAMA_SUPPORTED

to read:

#if defined(PNG_WRITE_sRGB_SUPPORTED)
     if ((!options.encodingGamma) ||
         (options.encodingGamma &&
          typeid(*options.encodingGamma) == typeid(SRGBGammaCurve)))
     {
         png_set_sRGB(png_ptr, info_ptr, PNG_sRGB_INTENT_PERCEPTUAL);
     }
#endif // PNG_WRITE_gAMA_SUPPORTED

With this update above the color render and viewer v3.8 outputs match 
whether File_Gamma explicitly set to srgb or not.

The grey scale too is better as shown in the attached image. The top row 
less the fix above and the bottom row with the fix. There is still 
something off related to non-grey defined colors in the render.pov 
result leading to different between render and viewer by as much as 
11/255(1). I don't understand what is happening there as yet...

(1) - Prior to the srgb gamma chunk fix the max color differences where 
9/255 at very low luminance.

With the previously posted grey output pgm/ppm fix, both the color and 
greyscale ppm outputs match so long as 'gamma=bt709' is used when 
defining the image_map (reading the POV-Ray created image file). The 
netpbm format doesn't encode the gamma on write - so you have no choice 
but to be explicit on the read if you want to be sure you match.

Aside 1: Don't trust ImgeMagick's identify command with respect to the 
srgb block being there or not. It's wrong when I run it. The iinfo 
command from the OpenImageIO package works OK. Or you can just edit the 
generated png with a text editor; this looks really ugly but if the sRGB 
chunk is being written you'll see 'sRGB' between the readable text 
'gAMA' and 'sBIT' right at the top. (Gimp, for me, is also not reporting 
all the meta data completely/correctly)

Aside 2: For those running stock v37/v38, I guess my recommendation 
would be to use linear gamma explicitly coded where you want to write an 
image file you'll later use (read) within POV-Ray. If only writing a png 
file, and using stock v3.8 be sure to use File_Gamma=srgb, if you want 
to be sure you have the srgb gamma block for downstream tools. Remember 
too Christoph corrected quite a lot post v3.7 in how the file gamma's 
are handled, but for color at least it looks to me like v3.7 png output 
OK. V3.7 image file input is another matter.

More on the png greyscale (single channel png) differences when I 
decipher more.

Bill P.

[William F Pokorny] File png/ppm gamma issues. v3.8. [1845 days 14 hours and 22 minutes ago]

Sat, 20 Mar 2021 17:31:20 GMT

Recently in responding to a question about greyscale bit depths posted 
by Ingo in povray.general, I happened to notice it was impossible to set 
the grey scale gamma for output pgm/ppm files. We are in v3.8 always 
getting linear output though the bit depth changes of v3.8 appear to work.

The fix for this is to make changes the write function in ppm.cpp to 
look something like:

     // The official Netpbm standard mandates the use of the ITU-R-BT.709
     // transfer function, although it acknowledges the use of linear
     // encoding or the sRGB transfer function as alternative de-facto
     // standards.
     gamma = options.GetTranscodingGammaCurve(BT709GammaCurve::Get());

     // Greyscale or color output
     // TODO - the check for image container type is here to mimic
     // old code; do we still need it?
     if (image->IsGrayscale() || options.grayscale)
     {
         grayscale = true;
         if (plainFormat)
             file->printf("P2\n");
         else
             file->printf("P5\n");
     }
     else
     {
         if (plainFormat)
             file->printf("P3\n");
         else
             file->printf("P6\n");
     }

where the gamma setting is moved out of the else condition and above the 
if/else conditional selecting greyscale or color output. With this 
change the pgm/ppm output matches the documented v3.8 behavior and that 
for png greyscale and color outputs.

---  png gamma issue.
I've mentioned elsewhere POV-Ray makes a pretty good viewer for >8 bit 
channel output files. While using POV-Ray as viewer it generates an 
output file if not suppressed. On a whim - aka asking for trouble - I 
decided to compare the original rendered output file with the viewer 
output file - these should match. They don't.

First looking at the POV-Ray png default color output and immediate 
input as an image_map in a viewer.

The short story is png output is hard coded to srgb unless overridden by 
a File_Gamma setting somewhere. However, this hard coded output doesn't 
trigger the generation of the correct srgb, encoding, information block 
in the png file, but rather a power law 2.2 gamma block. When the 
generated image is read it's done using a gamma correction which doesn't 
match that used to generate the image.

What this means in practice is shown in the attached image top row where 
the differences are multiplied by 50. The differences are small, but 
certainly there.

In addition, looking at the output files generated by the following 
commands and using iinfo to see the _gamma block encoding I see:

---
p380 render.pov +w400 +h400 +d -p +fn8 +ofn8

     oiio:ColorSpace: "GammaCorrected2.2"
     oiio:Gamma: 2.2

---
p380 render.pov +w400 +h400 +d -p +fn8 +ofn8_srgb File_Gamma=srgb

     oiio:ColorSpace: "sRGB"

---
p380 render.pov +w400 +h400 +d -p +fn8 +ofn8_1 File_Gamma=1.0

     oiio:ColorSpace: "linear"
     oiio:Gamma: 1


---
p380 render.pov +w400 +h400 +d -p +fn8 +ofn8_bt709 File_Gamma=bt709

     oiio:ColorSpace: "GammaCorrected1.9"
     oiio:Gamma: 1

Not worked out how to update the color png gamma code as yet. Or looked 
into similar pgm/ppm differences. Suppose a good near term rule would be 
to always specify the output and input gammas you want. When I do this 
the render result and the viewer result output images match as I think 
they should.

Aside: The bottom row of the attached image shows the greyscale 
differences which include the default png gamma out issue above - plus 
apparently more...

Bill P.

---
For those wanting to play at home:

//-------- render.pov
#version 3.8; // Simple scene to test file gamma behavior.
global_settings { assumed_gamma 1 }
#declare Grey50 = srgb <0.5,0.5,0.5>;
background { color Grey50 }
#declare Camera00 = camera {
     perspective
     location <3,3,-3.001>
     sky y
     angle 35
     right x*(image_width/image_height)
     look_at <0,0,0>
}
#declare White = srgb <1,1,1>;
#declare Light00 = light_source { <50,150,-250>, White }
#declare Red = srgb <1,0,0>;
#declare CylinderX = cylinder { -1*x, 1*x, 0.01 pigment { Red } }
#declare Green = srgb <0,1,0>;
#declare CylinderY = cylinder { -1*y, 1*y, 0.01 pigment { Green } }
#declare Blue = srgb <0,0,1>;
#declare CylinderZ = cylinder { -1*z, 1*z, 0.01 pigment { Blue } }
#include "functions.inc"
#declare Fn00 = function (x,y,z) { f_sphere(x,y/3,z,0.1) }
#declare Xfrm00 = transform {
     rotate z*30.0
     translate <0.5,0.0,0.0>
}
#declare FnXfrm00 = function { transform {Xfrm00 inverse} }
#declare Fn00x = function (x,y,z) {
     Fn00(FnXfrm00(x,y,z).x,FnXfrm00(x,y,z).y,FnXfrm00(x,y,z).z)
}
#declare Xfrm01 = transform {
     rotate z*60.0
     scale <1,3,1>
}
#declare FnXfrm01 = function { transform {Xfrm01 inverse} }
#declare Fn00xx = function (x,y,z) {
     Fn00x(FnXfrm01(x,y,z).x,FnXfrm01(x,y,z).y,FnXfrm01(x,y,z).z)
}
#declare Iso99 = isosurface {
     function { Fn00xx(x,y,z) }
     contained_by { box { -2.0,2.0 } }
     threshold 0
     accuracy 0.0005
     max_gradient 1.1
     pigment { color Green }
}

//--- scene ---
     camera { Camera00 }
     light_source { Light00 }
     object { CylinderX }
     object { CylinderY }
     object { CylinderZ }
     object { Iso99 }


//-------- viewer.pov
// p380 viewer.pov +w400 +h400 +d +p +fn8
// Replace three fn8.png strings below with whatever.
#version 3.8;
global_settings { assumed_gamma 1 }
#declare Grey50 = srgb <0.5,0.5,0.5>;
background { color Grey50 }
#declare VarOrthoMult =
     1.0/max(image_width/image_height,image_height/image_width);
#declare Camera01z = camera {
     orthographic
     location <0,0,-2>
     direction z
     right VarOrthoMult*x*max(1,image_width/image_height)
     up VarOrthoMult*y*max(1,image_height/image_width)
}
#macro ImageMap00(_HF)
   #if (_HF=0)
     image_map { "fn8.png"
   #else
      "fn8.png"
   #end
   #if (_HF=0)
      map_type 0
      once
    //interpolate 2 // No interpolation
     }
   #end
#end
#declare ImageMap00_P = pigment { image_map { "fn8.png" gamma 1 } }
#declare ImageMap00_Range = max_extent(ImageMap00_P);
#declare ImageMap00_NrmScale =
     <min(1,ImageMap00_Range.x/ImageMap00_Range.y),
      min(1,ImageMap00_Range.y/ImageMap00_Range.x),1>;
#declare Pigment00 = pigment {
     ImageMap00(0)
     translate <-0.5,-0.5,0>
     scale ImageMap00_NrmScale
}
#declare Fin00 = finish {
     ambient 0.0
     diffuse 0
     emission srgbft <1,1,1,0,0>
}
#declare Txtr00 = texture { pigment { Pigment00 } finish { Fin00 } }
#declare Plane00 = plane { z, 0 }
#declare Obj00 = object { Plane00 texture { Txtr00 } }

//--- scene ---
     camera { Camera01z }
     object { Obj00 }

[William F Pokorny] File png/ppm gamma issues v3.8. Part 1. [1845 days 14 hours and 31 minutes ago]

Sat, 20 Mar 2021 17:22:16 GMT

// The official Netpbm standard mandates the use of the ITU-R-BT.709
     // transfer function, although it acknowledges the use of linear
     // encoding or the sRGB transfer function as alternative de-facto
     // standards.
     gamma = options.GetTranscodingGammaCurve(BT709GammaCurve::Get());

     // Greyscale or color output
     // TODO - the check for image container type is here to mimic
     // old code; do we still need it?
     if (image->IsGrayscale() || options.grayscale)
     {
         grayscale = true;
         if (plainFormat)
             file->printf("P2\n");
         else
             file->printf("P5\n");
     }
     else
     {
         if (plainFormat)
             file->printf("P3\n");
         else
             file->printf("P6\n");
     }

where the gamma setting is moved out of the else condition and above the 
if/else conditional selecting greyscale or color output. With this 
change the pgm/ppm output matches the documented v3.8 behavior and that 
for png greyscale and color outputs.

I've mentioned elsewhere POV-Ray makes a pretty good viewer for >8 bit 
channel output files. While using POV-Ray as viewer it generates an 
output file if not suppressed. On a whim - aka asking for trouble - I 
decided to compare the original rendered output file with the viewer 
output file. These two POV-Ray generated images should match. They don't.

First, looking at the POV-Ray png default color output and immediate 
input as an image_map in a viewer.

The short story is png output is hard coded to srgb unless overridden by 
a File_Gamma setting somewhere. However, this hard coded output doesn't 
trigger the generation of the correct srgb, encoding-information block 
in the png file, but rather a power law 2.2 gamma block.

What this means in practice is shown in the attached image top row where 
the differences are multiplied by 50. The differences are mostly small, 
but certainly there.

In addition, looking at the output files generated by the following 
commands and using iinfo to see the _gamma block encoding I see:

---
p380 render.pov +w400 +h400 +d -p +fn8 +ofn8

     oiio:ColorSpace: "GammaCorrected2.2"
     oiio:Gamma: 2.2

---
p380 render.pov +w400 +h400 +d -p +fn8 +ofn8_srgb File_Gamma=srgb

     oiio:ColorSpace: "sRGB"

---
p380 render.pov +w400 +h400 +d -p +fn8 +ofn8_1 File_Gamma=1.0

     oiio:ColorSpace: "linear"
     oiio:Gamma: 1


---
p380 render.pov +w400 +h400 +d -p +fn8 +ofn8_bt709 File_Gamma=bt709

     oiio:ColorSpace: "GammaCorrected1.9"
     oiio:Gamma: 1.9

Not worked out how to update the color png gamma code as yet. Or looked 
into similar pgm/ppm differences. Suppose a good near term rule would be 
to always specify the output and input gamma you want. When I do this, 
the render result and the viewer result images match - as they should.

Aside: The bottom row of the attached image shows the greyscale 
differences which include the default png gamma out immediate issue 
above - plus apparently more with greyscale...

Bill P.

---
For those wanting to play at home:

//-------- render.pov
#version 3.8; // Simple scene to test file gamma behavior.
global_settings { assumed_gamma 1 }
#declare Grey50 = srgb <0.5,0.5,0.5>;
background { color Grey50 }
#declare Camera00 = camera {
     perspective
     location <3,3,-3.001>
     sky y
     angle 35
     right x*(image_width/image_height)
     look_at <0,0,0>
}
#declare White = srgb <1,1,1>;
#declare Light00 = light_source { <50,150,-250>, White }
#declare Red = srgb <1,0,0>;
#declare CylinderX = cylinder { -1*x, 1*x, 0.01 pigment { Red } }
#declare Green = srgb <0,1,0>;
#declare CylinderY = cylinder { -1*y, 1*y, 0.01 pigment { Green } }
#declare Blue = srgb <0,0,1>;
#declare CylinderZ = cylinder { -1*z, 1*z, 0.01 pigment { Blue } }
#include "functions.inc"
#declare Fn00 = function (x,y,z) { f_sphere(x,y/3,z,0.1) }
#declare Xfrm00 = transform {
     rotate z*30.0
     translate <0.5,0.0,0.0>
}
#declare FnXfrm00 = function { transform {Xfrm00 inverse} }
#declare Fn00x = function (x,y,z) {
     Fn00(FnXfrm00(x,y,z).x,FnXfrm00(x,y,z).y,FnXfrm00(x,y,z).z)
}
#declare Xfrm01 = transform {
     rotate z*60.0
     scale <1,3,1>
}
#declare FnXfrm01 = function { transform {Xfrm01 inverse} }
#declare Fn00xx = function (x,y,z) {
     Fn00x(FnXfrm01(x,y,z).x,FnXfrm01(x,y,z).y,FnXfrm01(x,y,z).z)
}
#declare Iso99 = isosurface {
     function { Fn00xx(x,y,z) }
     contained_by { box { -2.0,2.0 } }
     threshold 0
     accuracy 0.0005
     max_gradient 1.1
     pigment { color Green }
}

//--- scene ---
     camera { Camera00 }
     light_source { Light00 }
     object { CylinderX }
     object { CylinderY }
     object { CylinderZ }
     object { Iso99 }

//-------- viewer.pov
// p380 viewer.pov +w400 +h400 +d +p +fn8
// Replace three fn8.png below with render.png or whatever.
#version 3.8;
global_settings { assumed_gamma 1 }
#declare Grey50 = srgb <0.5,0.5,0.5>;
background { color Grey50 }
#declare VarOrthoMult =
     1.0/max(image_width/image_height,image_height/image_width);
#declare Camera01z = camera {
     orthographic
     location <0,0,-2>
     direction z
     right VarOrthoMult*x*max(1,image_width/image_height)
     up VarOrthoMult*y*max(1,image_height/image_width)
}
#macro ImageMap00(_HF)
   #if (_HF=0)
     image_map { "fn8.png"
   #else
      "fn8.png"
   #end
   #if (_HF=0)
      map_type 0
      once
    //interpolate 2 // No interpolation
     }
   #end
#end
#declare ImageMap00_P = pigment { image_map { "fn8.png" gamma 1 } }
#declare ImageMap00_Range = max_extent(ImageMap00_P);
#declare ImageMap00_NrmScale =
     <min(1,ImageMap00_Range.x/ImageMap00_Range.y),
      min(1,ImageMap00_Range.y/ImageMap00_Range.x),1>;
#declare Pigment00 = pigment {
     ImageMap00(0)
     translate <-0.5,-0.5,0>
     scale ImageMap00_NrmScale
}
#declare Fin00 = finish {
     ambient 0.0
     diffuse 0
     emission srgbft <1,1,1,0,0>
}
#declare Txtr00 = texture { pigment { Pigment00 } finish { Fin00 } }
#declare Plane00 = plane { z, 0 }
#declare Obj00 = object { Plane00 texture { Txtr00 } }

//--- scene ---
     camera { Camera01z }
     object { Obj00 }

[William F Pokorny] Re: Parsing issue. Density and blend_mode, blend... [1882 days 21 hours and 22 minutes ago]

Thu, 11 Feb 2021 10:31:17 GMT

On 2/11/21 2:23 AM, Thomas de Groot wrote:
> Op 11/02/2021 om 00:48 schreef William F Pokorny:
...
> 
> And this old fool here, was not even able to spot the typing error while 
> looking forcibly at it... :-/
> 

Thanks. Misery loves a little company, but I doubt you spent a full DAY 
missing the obvious!

The 'povr' branch now, for example on a color_map id typo, will issue 
the parse error:

   expecing first map entry '[...', 'CN'. found instead

rather than:

   Must have at least one color in color map.

This 'might' be enough to help me next time... :-)

Bill P.

[Thomas de Groot] Re: Parsing issue. Density and blend_mode, blend... [1883 days and 29 minutes ago]

Thu, 11 Feb 2021 07:23:52 GMT

Op 11/02/2021 om 00:48 schreef William F Pokorny:
> On 2/10/21 2:20 PM, William F Pokorny wrote:
>> On 2/10/21 2:50 AM, Thomas de Groot wrote:
>>> Op 09/02/2021 om 14:04 schreef William F Pokorny:
> ...
>>
>> In any case, this is starting to look like some sort of deeper parser 
>> issue. At the moment I'm baffled.
>>
> 
> It turns out this old fool cannot type or see very well... :-(
> 
> If I change 'blend_gama' to 'blend_gamma' all is good with color_maps.
> 
> I'm in the process now of adding new error messages to make clear the 
> problem is with a token blend* token (or passed id token) when that is 
> the issue - and not something with the color map entry count.
> 
> Not all a waste, fixed a couple peripheral issues like not accepting the 
> blend_map, blend_gamma in a density_map while I was otherwise chasing a 
> ghost of my own creation.
> 
> Bill P.
> 

And this old fool here, was not even able to spot the typing error while 
looking forcibly at it... :-/

-- 
Thomas

[William F Pokorny] Re: Parsing issue. Density and blend_mode, blend... [1883 days 8 hours and 5 minutes ago]

Wed, 10 Feb 2021 23:48:07 GMT

On 2/10/21 2:20 PM, William F Pokorny wrote:
> On 2/10/21 2:50 AM, Thomas de Groot wrote:
>> Op 09/02/2021 om 14:04 schreef William F Pokorny:
...
> 
> In any case, this is starting to look like some sort of deeper parser 
> issue. At the moment I'm baffled.
> 

It turns out this old fool cannot type or see very well... :-(

If I change 'blend_gama' to 'blend_gamma' all is good with color_maps.

I'm in the process now of adding new error messages to make clear the 
problem is with a token blend* token (or passed id token) when that is 
the issue - and not something with the color map entry count.

Not all a waste, fixed a couple peripheral issues like not accepting the 
blend_map, blend_gamma in a density_map while I was otherwise chasing a 
ghost of my own creation.

Bill P.

[William F Pokorny] Re: Parsing issue. Density and blend_mode, blend... [1883 days 12 hours and 32 minutes ago]

Wed, 10 Feb 2021 19:20:48 GMT

On 2/10/21 2:50 AM, Thomas de Groot wrote:
> Op 09/02/2021 om 14:04 schreef William F Pokorny:
>> This fails to parse:
> 
> Says: "Must have at least one color in color map"
> 
> Strange.
> 
> Otherwise, this is a nice feature which I had not been aware of (or 
> forgot about; so many features in POV....)
> 
Yes & yes.

Chased this one for most of the day - and still not got it.

For reasons still a mystery, it appears the issue is with just 
'blend_gamma'. If you you specify only blend_mode everything is OK. You 
can change blend_mode with no issue.

For some reason the blend_gamma token is not getting picked/seen up when 
specified inside the density (or maybe media) block - that is the real 
error despite the message.

I usually define my maps stand alone (this not an issue for me basically 
in normal work flow) so I wondered how general the issue. Only tested 
color_maps defined within a pigment - and there blend_gamma works as 
expected.

Complicating things some, there is code for the color map parsing apart 
from all other map parsing due trying to maintain compatibility with 
some aspect of v1.0 of POV-Ray. I'll probably dump that special version 
in the povr branch - if I an work out how.

In any case, this is starting to look like some sort of deeper parser 
issue. At the moment I'm baffled.

Bill P.

[Thomas de Groot] Re: Parsing issue. Density and blend_mode, blend... [1884 days and 3 minutes ago]

Wed, 10 Feb 2021 07:50:30 GMT

Op 09/02/2021 om 14:04 schreef William F Pokorny:
> This fails to parse:

Says: "Must have at least one color in color map"

Strange.

Otherwise, this is a nice feature which I had not been aware of (or 
forgot about; so many features in POV....)

-- 
Thomas

[William F Pokorny] Parsing issue. Density and blend_mode, blend_gam... [1884 days 18 hours and 48 minutes ago]

Tue, 9 Feb 2021 13:04:59 GMT

Documenting apparent bug with parsing and new to v3.8 blend_mode and 
blend_gamma options.

In playing some with a media scene Bald Eagle posted, had the thought to 
try the new to v3.8 blend_mode and blend_gamma options for his color map 
because I'd never used the features with media.

This fails to parse:

density {
     gradient x
     color_map {
         blend_mode 2 blend_gama 2.5
         [0.0 rgb 0.0]
         [1.0 rgb 1.0]
     } // end color_map
} // end density

while this works:

#declare CM = color_map {
      blend_mode 0 blend_gamma 2.5
      [0.0 rgb 0.0]
      [1.0 rgb 1.0]
} // end color_map

density {
     gradient x
     color_map { CM }
} // end density

Bill P.

[William F Pokorny] Re: v3.8 attempted load of radiosity file core d... [1886 days 17 hours and 55 minutes ago]

Sun, 7 Feb 2021 13:57:47 GMT

On 2/7/21 7:34 AM, Le_Forgeron wrote:
> Le 06/02/2021 Ã  21:11, William F Pokorny a Ã©critÂ :
...
> 
> Beware of leakage when opening fails.
> 
> I wonder if the change should not be a two-level check:
> 1. is the object != nullptr (as previous) ( if (fd != nullptr) )
> 2. is the read/open not in fail state ( if (*fd) )
> 
> The "delete fd;" being outside the second block.
> 
> The first block handle memory failure (or not, "new" would throw, and
> that is not catched locally).
> 
> So actually, I think your change of the test is correct, BUT the "delete
> fd;" must be moved outside the block too.
> 

Thank you! :-)

Just checked a delete of a null pointer is safe and it appears it is. To 
confirm, what I now have is:

IStream* fd = NewIStream(inputFile, POV_File_Data_RCA);
if (*fd)
{
...
}
delete fd;

Bill P.

[Le Forgeron] Re: v3.8 attempted load of radiosity file core d... [1886 days 19 hours and 19 minutes ago]

Sun, 7 Feb 2021 12:34:40 GMT

Le 06/02/2021 Ã  21:11, William F Pokorny a Ã©critÂ :
> On 12/7/20 12:16 PM, William F Pokorny wrote:
>> For future reference.
>>
>> On Ubuntu 18.04 g++9
>>
>> povray bogus.pov Radiosity_File_Name="RadSamples" +rfo +rfi
>>
>> coredumps unless the RadSamples file exists. The file can be empty
>> and things are fine but it must exist.
> ...
>>
> 
> This is a problem in source/core/lighting/radiosity.cpp. In the function
> RadiosityCache::Load change:
> 
> Â Â Â  if (fd != nullptr)
> Â Â Â  {
> 
> to
> 
> Â Â Â  if (*fd)Â  // Natural is (fd !=
nullptr), but IStream has overrides
> Â Â Â 
{Â Â Â Â Â Â Â Â 
// of !fd and *fd for testing.
> 
> Bill P.

Beware of leakage when opening fails.

I wonder if the change should not be a two-level check:
1. is the object != nullptr (as previous) ( if (fd != nullptr) )
2. is the read/open not in fail state ( if (*fd) )

The "delete fd;" being outside the second block.

The first block handle memory failure (or not, "new" would throw, and
that is not catched locally).

So actually, I think your change of the test is correct, BUT the "delete
fd;" must be moved outside the block too.

[William F Pokorny] Re: v3.8 attempted load of radiosity file core d... [1887 days 11 hours and 41 minutes ago]

Sat, 6 Feb 2021 20:11:44 GMT

On 12/7/20 12:16 PM, William F Pokorny wrote:
> For future reference.
> 
> On Ubuntu 18.04 g++9
> 
> povray bogus.pov Radiosity_File_Name="RadSamples" +rfo +rfi
> 
> coredumps unless the RadSamples file exists. The file can be empty
> and things are fine but it must exist.
...
> 

This is a problem in source/core/lighting/radiosity.cpp. In the function 
RadiosityCache::Load change:

     if (fd != nullptr)
     {

to

     if (*fd)  // Natural is (fd != nullptr), but IStream has overrides
     {         // of !fd and *fd for testing.

Bill P.

[jr] Re: v3.8 attempted load of radiosity file core d... [1947 days 17 hours and 18 minutes ago]

Tue, 8 Dec 2020 14:35:08 GMT

hi,

William F Pokorny <ano### [at] anonymousorg> wrote:
> On 12/7/20 3:42 PM, jr wrote:
> > William F Pokorny <ano### [at] anonymousorg> wrote:
> >> For future reference. ...
> > and not just under Ubuntu, same for Slackware (alpha.10064268).  :-(  of
> > interest perhaps, I found a scene which segfaults even when 'RadSamples' exists.
> >   also, the file, so far, remains empty for scenes tried.
>
> On remaining empty. My only guess is perhaps there is no radiosity set
> up in the scene? It "might" be with certain scenes default settings do
> nothing.

>
> I'm no radiosity expert, but I think in playing yesterday I picked up
> there is some sensitivity to scene scale. Meaning any given collection
> of radiosity settings might work better with a scene covering a range of
> +-10000 than one within a range of +-2 (1). Maybe I'm getting fooled /
> fooling myself - more work necessary to be sure.

haven't much time at present to play/explore, on to the todo list.

> If you have time to post more on the segfault when RadSamples exists, it
> might be useful when I look at fixing this for povr. In any case, I'll
> keep what you posted in mind.

I've a 'tube.inc' and 'tube_000.pov' (a 'nixie tube' implementation), posted
apparently by user "Thomas", the datestamps say 'May 19th 2020' (though likely
to be date the copy was created); cannot remember whether downloaded from here
or found elsewhere on the net, and searches so far w/out result.  can post a zip
(on the understanding not my code/no (copy)right/etc)


regards, jr.

[William F Pokorny] Re: v3.8 attempted load of radiosity file core d... [1947 days 19 hours and 36 minutes ago]

Tue, 8 Dec 2020 12:17:16 GMT

On 12/7/20 1:33 PM, Kenneth wrote:
> I agree, if I understand this correctly (extrapolating your comments to the v3.8
> Windows version.)
...
> [I hope I'm not misunderstanding your comments.]
> 
Thanks for the information. You understand - as much as I myself so. 
Which is perhaps not saying all that much... ;-)

Bill P.

[William F Pokorny] Re: v3.8 attempted load of radiosity file core d... [1947 days 19 hours and 41 minutes ago]

Tue, 8 Dec 2020 12:12:33 GMT

On 12/7/20 3:42 PM, jr wrote:
> hi,
> 
> William F Pokorny <ano### [at] anonymousorg> wrote:
>> For future reference.
>>
>> On Ubuntu 18.04 g++9
>>
>> povray bogus.pov Radiosity_File_Name="RadSamples" +rfo +rfi
>>
>> coredumps unless the RadSamples file exists. The file can be empty
>> and things are fine but it must exist. ...
> 
> and not just under Ubuntu, same for Slackware (alpha.10064268).  :-(  of
> interest perhaps, I found a scene which segfaults even when 'RadSamples' exists.
>   also, the file, so far, remains empty for scenes tried.
> 
> regards, jr.
> 
Thanks for testing.

On remaining empty. My only guess is perhaps there is no radiosity set 
up in the scene? It "might" be with certain scenes default settings do 
nothing.

I'm no radiosity expert, but I think in playing yesterday I picked up 
there is some sensitivity to scene scale. Meaning any given collection 
of radiosity settings might work better with a scene covering a range of 
+-10000 than one within a range of +-2 (1). Maybe I'm getting fooled / 
fooling myself - more work necessary to be sure.

If you have time to post more on the segfault when RadSamples exists, it 
might be useful when I look at fixing this for povr. In any case, I'll 
keep what you posted in mind.

Bill P.

[jr] Re: v3.8 attempted load of radiosity file core d... [1948 days 11 hours and 8 minutes ago]

Mon, 7 Dec 2020 20:45:07 GMT

hi,

William F Pokorny <ano### [at] anonymousorg> wrote:
> For future reference.
>
> On Ubuntu 18.04 g++9
>
> povray bogus.pov Radiosity_File_Name="RadSamples" +rfo +rfi
>
> coredumps unless the RadSamples file exists. The file can be empty
> and things are fine but it must exist. ...

and not just under Ubuntu, same for Slackware (alpha.10064268).  :-(  of
interest perhaps, I found a scene which segfaults even when 'RadSamples' exists.
 also, the file, so far, remains empty for scenes tried.

regards, jr.

[Kenneth] Re: v3.8 attempted load of radiosity file core d... [1948 days 13 hours and 18 minutes ago]

Mon, 7 Dec 2020 18:35:00 GMT

I agree, if I understand this correctly (extrapolating your comments to the v3.8
Windows version.)

The particular 'development version' I'm using that piggybacks on top of v3.7.0
does not accept the +rfo +rfi commands for some reason; but if I instead use
only these two .INI commands...

Radiosity_File_Name= *whatever*
Radiosity_From_File=on

.....it results in a failed render. Not an outright crash, but annoying. Of
course, it does not make much sense anyway to try reading data from a
non-existant(?) file. (I learned that the hard way, ha.) But if the LINUX builds
are actually crashing, that's not good!

Perhaps a fix would be for POV-ray to internally create a small 'blank' file on
start-up, with a 'dummy' name that is then overridden by Radiosity_File_Name?

[I hope I'm not misunderstanding your comments.]

[William F Pokorny] v3.8 attempted load of radiosity file core dumps. [1948 days 14 hours and 37 minutes ago]

Mon, 7 Dec 2020 17:16:03 GMT

For future reference.

On Ubuntu 18.04 g++9

povray bogus.pov Radiosity_File_Name="RadSamples" +rfo +rfi

coredumps unless the RadSamples file exists. The file can be empty
and things are fine but it must exist. We certainly should not
crash, and in my view given how +rfo always appends to any existing 
file, the user should not have to change the rfi flag use based on 
whether the file exists or not.

Bill P.

[jr] Re: v3.7 v3.8 image compare [2014 days 20 hours and 48 minutes ago]

Fri, 2 Oct 2020 11:05:01 GMT

hi,

William F Pokorny <ano### [at] anonymousorg> wrote:
> On 10/1/20 10:52 AM, jr wrote:
> >> "jr" <cre### [at] gmailcom> wrote:
> >> ...
> > the "problem" with the existing code is that the same command-line is built for
> > both (POV-Ray) executables.  to build version-specific command-lines I need
> > additional information about which CLI option came into use when.  so far I
> > have:
> >
> > v 3.8 - ac am3 cc ss
> >
> > v 3.7 - ag bm2 bs gp hr mi wt
> >
> > does anyone ("hey WFP"  ;-)) know of a list of new option switches, by POV-Ray
> > version?  can anyone (please) help by adding stuff I missed?  also, ideally, I'd
> > like info going back to at least v 3.5.  TIA.
> >
>
> The documentation for v3.8 is pretty good,

agree.

> but still over the past
> decade or more the tendency has been to leave the flag and ini parsing
> in place so old stuff keeps running. Sometimes you get a warning the
> feature is obsolete or something, but not always. What I see happening
> is folks continuing to use flags which have long not worked. To no large
> harm for long time users, but I think stuff like this is really
> confusing to newer users.

am surprised that there is no (simple) table of features/switches by version.

> The best I can easily offer is the povr source code and the files:

thanks.  "bedtime reading".  :-)

> ... If the flag no longer does anything, povr dies. ...

think that should be the default anyway, and for POV-Ray "proper".

> ...Remember any ini option can be specified on the command line and a few
> ini options have no short flags - File_Gamma is one of those I hit
> pretty often.

yes.  the "favourite" 'declare=X=Y' came in at 3.5, as did, apparently writing
jpg and tiff.

that's another item I'd like to establish a "time line" for -- output image
formats/options.

> I also change the flags as specified to lower case over upper ...

:-)

> ...
> Aside: I've played a little with now extended and perhaps eventually,
> replacement options parsing. One of the things you run into for example
> is someone can have coded up +am5 accidentally. No errors, no warnings.
> In v3.7 this, IIRC, defaults to am2. In recent v3.8, it defaults to am3.
> Folks can get differences in result and not easily know why (that AA
> changed is in the output - if you happen to have both handy to compare).
>
> With povr, if you specify +am5, you get:
>
> Command line parameter: +am5
> terminate called after throwing an instance of 'pov_base::Exception'
>    what():  Must have trailing integer values of 1,2 or 3 as in +am2.
> Aborted (core dumped)
>
> The core dump isn't ideal, but I'll take it over no error at all.

not ideal perhaps, but the correct course of action, imnsvho  :-).  and
(repeating myself) POV-Ray too ought to behave that way.

thanks for reply and pointers (to files).


regards, jr.


note if anyone's playing with the 'cmpimg' s/ware, below is a list of (three)
changes to 'mkcmpimg.tcl'[*] which will generate "diff" images (thanks, AH) too.

[*] reverse order so line numbers aren't affected.

# -----------------------------------------------------------------------------

insert as new line 130:
  ccmd $rcd(scene)


insert as new line 49ff:
proc ccmd {s} {
  global cfg rt
  set f1 [format %s_%s.png [lindex $rt(tags) 0] $s]
  set f2 [format %s_%s.png [lindex $rt(tags) 1] $s]
  set f3 [format cid_%s.png $s]
  set c [format $cfg(comp) $f1 $f2 $f3]
  set cmd [list exec -ignorestderr {*}$c]
  catch {{*}$cmd}
  return
}


insert as new line 9:
  comp  {compare %s %s -highlight-color red %s}

[William F Pokorny] Re: v3.7 v3.8 image compare [2015 days 10 hours and 35 minutes ago]

Thu, 1 Oct 2020 21:18:24 GMT

On 10/1/20 10:52 AM, jr wrote:
> "jr" <cre### [at] gmailcom> wrote:
>> "jr" <cre### [at] gmailcom> wrote:
>>> ...
>> more changes.  ...
> 
> the "problem" with the existing code is that the same command-line is built for
> both (POV-Ray) executables.  to build version-specific command-lines I need
> additional information about which CLI option came into use when.  so far I
> have:
> 
> v 3.8 - ac am3 cc ss
> 
> v 3.7 - ag bm2 bs gp hr mi wt
> 
> does anyone ("hey WFP"  ;-)) know of a list of new option switches, by POV-Ray
> version?  can anyone (please) help by adding stuff I missed?  also, ideally, I'd
> like info going back to at least v 3.5.  TIA.
> 

The documentation for v3.8 is pretty good, but still over the past 
decade or more the tendency has been to leave the flag and ini parsing 
in place so old stuff keeps running. Sometimes you get a warning the 
feature is obsolete or something, but not always. What I see happening 
is folks continuing to use flags which have long not worked. To no large 
harm for long time users, but I think stuff like this is really 
confusing to newer users.

The best I can easily offer is the povr source code and the files:

  <install>/source/frontend/processrenderoptions.cpp

and

  <install>/source/povms/povmsid.h

The former has the render options which work for povr and with the 
exception of the two real time rendering flags. If memory servers the 
rest at I think what does something in the current v3.8. I've taken a 
harder line with povr. If the flag no longer does anything, povr dies. 
Remember any ini option can be specified on the command line and a few 
ini options have no short flags - File_Gamma is one of those I hit 
pretty often.

I also change the flags as specified to lower case over upper because 
the case in processrenderoptions.cpp is what shows up in the error 
messages (though either case works) and lower case flags more natural in 
unix like environments I think.

For unix there are too the unix only flags (-y). povr -help to see 
those, and some of those like -authors are povr only critters.

The file povmsid.h is where other previous to me documented some 
features working, not or unused (or sometimes used only internally). I 
extended this convention by sticking some of my comments in there too. 
The IDs there correspond to options.

With older versions suppose these files might help. Documentation for 
those versions too as folks have tried to update to match, but probably 
like v3.8 there are flags floating around that no longer do anything. I 
don't have any ready docs for those.

Aside: I've played a little with now extended and perhaps eventually, 
replacement options parsing. One of the things you run into for example 
is someone can have coded up +am5 accidentally. No errors, no warnings. 
In v3.7 this, IIRC, defaults to am2. In recent v3.8, it defaults to am3.
Folks can get differences in result and not easily know why (that AA 
changed is in the output - if you happen to have both handy to compare).

With povr, if you specify +am5, you get:

Command line parameter: +am5
terminate called after throwing an instance of 'pov_base::Exception'
   what():  Must have trailing integer values of 1,2 or 3 as in +am2.
Aborted (core dumped)

The core dump isn't ideal, but I'll take it over no error at all.

This functionality might or might not be in the last tarball I posted - 
I don't remember. I do remember I haven't added the extended 
parsing/checking to all the flags as yet. There is too the unix flags 
getting handled and parsed somewhere else in the code. Not yet sure what 
to aim for in the end. :-)

Bill P.

[jr] Re: v3.7 v3.8 image compare [2015 days 16 hours and 58 minutes ago]

Thu, 1 Oct 2020 14:55:00 GMT

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

the "problem" with the existing code is that the same command-line is built for
both (POV-Ray) executables.  to build version-specific command-lines I need
additional information about which CLI option came into use when.  so far I
have:

v 3.8 - ac am3 cc ss

v 3.7 - ag bm2 bs gp hr mi wt

does anyone ("hey WFP"  ;-)) know of a list of new option switches, by POV-Ray
version?  can anyone (please) help by adding stuff I missed?  also, ideally, I'd
like info going back to at least v 3.5.  TIA.

regards, jr.

[jr] Re: v3.7 v3.8 image compare [2023 days 15 hours and 8 minutes ago]

Wed, 23 Sep 2020 16:45:00 GMT

"jr" <cre### [at] gmailcom> wrote:
> ...
> I've made several changes and the whole thing is now a two-step process: create
> a db, and run it.

more changes.  "installing" is a matter of setting a couple of directories and
listing available POV-Ray programs, essentially.  once set up, the POV-Rays and
database to use, plus a few runtime options, are chosen from an UI which
executes the "job".  comments and feedback, please.

the new archive is at:
<https://drive.google.com/file/d/10_S7EN-_3zm7wezQTBLVYeC79m2PUM3V/view?usp=sharing>

regards, jr.

[jr] Re: v3.7 v3.8 image compare [2029 days 14 hours and 33 minutes ago]

Thu, 17 Sep 2020 17:20:00 GMT

"jr" <cre### [at] gmailcom> wrote:
> ...
> the archive contains a 'readme.txt' detailing ...

I also forgot to include a whole paragraph regarding results, plus found typos.
I copy the amended 'readme' below, rather than posting another archive.

btw, to make the s/ware work with 'povr', requires the '/scenes/' directory to
contain directories only.  move 'biscuit.pov' into a sub-directory.  create a
'previews' directory (that is the "marker" the script looks for).  (I checked it
works, albeit with two identical 'povr' programs)

regards, jr.

# ------------------------------------------------------------------------
setting up, by script.

you will neeed to create two directories, one for the scripts, one for
the database(s); you could make both the same.

extract the archive in the script directory.

- cimkdb.sh

  the directories in lines 10 and 11 need to be changed to the above.
  'store_db' for the databases, 'store_ec' for external code/scripts.

  in line 34 you can change the "preferred" work directory for when
  jobs get run.  I use '/tmp/cmpimg/' because '/tmp/' is set up to
  "live" in RAM.

- cirundb.sh

  change 'store_ec' in line 11.

  the script always creates an archive of the run's data.  if that is
  unwanted, you could insert an 'exit 0' before line 66.

- init-db.sql

  there are a couple of defaults you may wish to adjust.  currently,
  jobs run without showing a display/render window, without limit on
  the number of worker threads, and generating log information; also,
  the set of "standard" (POV-Ray) CLI options is given here.
  see the comments for table 'misckv' to make necessary changes.

- mkcmpimg.tcl

  you will need to provide the names of the two POV-Ray executables
  which are to be compared, and you may need/want to use different
  "tags" to distinguish them.

  lines 14 and 15 contain the relevant data, both two-element lists.
  the tags are used as prefixes for the (temporary) image files.

how it works.

it is now a two step process.  create a database for a given POV-Ray
distribution '/scenes/' directory, and "run the database". in between,
you may wish to update individual scenes in the db, eg if specific
option switches are required.  the db files are always named with the
version number grabbed from the directory, but they can be renamed if
necessary.

for example (from the script directory):

  $ ./cimkdb.sh /usr/local/share/povray-3.7/scenes/

(an override for the default work directory can be given as second arg)

the database can now be run as often as required.

  $ ./cirundb.sh ~/.local/share/cmpimg/civ3.7.sqlite

you will have to substitute the path of course.

the results are left in the work directory.
if logging was not disabled, there will be two new files for every
"active" scene, eg 'biscuit.pov' now has 'ci_biscuit.png', output by
the 'montage' command, and 'ci_biscuit.txt.xz', which is POV-Ray's
'all_file' output, compressed.  (view with 'xzless')
a compressed archive of the work directory too is left in the work
directory.  it is named 'ciYYMMDDHHMM.tar.xz', where the date/time is
from when 'cirundb.sh' was started.

the work directory must be deleted before the next run.

run either script without any arguments to see the required command
line, including the options.

finally, there is, as yet, no documentation (although all scripts are
commented), and there is very little error handling, and no attempt at
making the scripts "resiliant".

a simple (GUI) frontend for database maintenance is (still) on the
drawing board; it is not high priority since everything can be done
easily using the 'sqlite3' shell.

[jr] Re: v3.7 v3.8 image compare [2029 days 19 hours and 43 minutes ago]

Thu, 17 Sep 2020 12:10:00 GMT

"jr" <cre### [at] gmailcom> wrote:
> William F Pokorny <ano### [at] anonymousorg> wrote:
> > ...
> > When I run comparisons I almost always run with one thread despite this
> > being slow. Otherwise some results - radiostiy involved ones for example
> > - can be quite different, same version and file, run to run.
> >
> > There is also the issues of all the jitter settings if you want to do
> > detailed automatic comparisons - these jitters all need to be off in
> > such cases. AA, area lights... Oh and you have to avoid some features
> > like crand (subsurface?).
>
> thank you!  will incorporate '-j' and think about '-wt'; optional perhaps?

I've made several changes and the whole thing is now a two-step process: create
a db, and run it.

see 'wtlimit'.  :-)

the archive contains a 'readme.txt' detailing the few edits needed to "install"
the code.  and I meant to mention in the 'readme' - the work directory must not
exist, ie must be deleted between successive runs.

<https://drive.google.com/file/d/10YPGxnYy0v5ph5DmNUJuYuq1NS_MOvUn/view?usp=sharing>

regards, jr.

[jr] v3.7 v3.8 image compare [2034 days 19 hours and 38 minutes ago]

Sat, 12 Sep 2020 12:15:00 GMT

hi,

I've simply cut'n'paste your reply here.

William F Pokorny <ano### [at] anonymousorg> wrote:
> On 9/11/20 9:29 PM, jr wrote:
> > "jr" <cre### [at] gmailcom> wrote:
> ...
> > two scenes actually fail for v3.8, but work for 3.7.  ...
> ...
> When you run, are you running v3.7 shipped scenes with v3.7 povray and
> v3.8 scenes with v3.8 povray? Some scenes are different v3.7 to v3.8 to
> fix issues or align with v3.8 changes.

no.  I understood CC to mean that one set of files gets compared with two
different executables.  only v3.7 '/scenes/' scenes are used.

> There are also new scenes in v3.8 where no comparison is possible. With
> these results should at least be run and looked over.

that would only mean replacing a few paths and the names of the executables,
more below.

at this point, as mentioned, it's v basic, no error handling, nothing, for now
I've simply .. thrown in a possible framework to see whether there's an use for
it.

> The allscene.sh script as I recall was not handling even all the v3.7
> base features and scenes, but been years since I was doing this sort of
> testing (when we pushed and dropped a v3.71).

the '/scripts/' stuff does not use the 'recommended' settings from the scene,
afaik.

> When I run comparisons I almost always run with one thread despite this
> being slow. Otherwise some results - radiostiy involved ones for example
> - can be quite different, same version and file, run to run.
>
> There is also the issues of all the jitter settings if you want to do
> detailed automatic comparisons - these jitters all need to be off in
> such cases. AA, area lights... Oh and you have to avoid some features
> like crand (subsurface?).

thank you!  will incorporate '-j' and think about '-wt'; optional perhaps?

there is no analysis of the (given) command-line options.  I'm thinking (and
would prefer) a simple UI utility to manipulate individual scene settings in the
database.
(directories can be enabled/disabled, which may be handy)

> A kind of testing I don't believe has been done for v3.8 (even in the
> v3.71 testing) - except maybe by Christoph - is to render to all the
> output file formats.

ok.

> Some of the outputs need a viewer (preferably not POV-Ray itself) which
> supports dithering and the higher bit depth outputs. Test here I guess
> would be do things look more or less OK output format to output format.
> We wouldn't need to run all the scenes for this testing. We might lean
> on one of the image packages to do conversions and comparisons, but
> running such programs can get pretty detailed if the outputs are not all
> linear.

that's for actual image compare.  there may also be milage in extracting
information from the output of, for instance, (ImageMagick) 'identify -verbose'.
 :-)

[v3.8 stuff snipped]

> Anyway. Please forgive the typos/breaks in thought. Rushing ahead of my
> first coffee.

looked productive to me.  :-)

> ...
> My last question is whether you are running the last v3.8 official
> pre-release or the master branch at last commit?

no, it's an 'unofficial' alpha.10064268.  re the below, would consider using a
more up-to-date version.

> There were fixes and other changes in the commits between the last
> official pre-release and what is in master today. Round about way to say
> we need to decide from what "commit" we are going to try and release. I
> think many of us are running code based off the last commit (Jerome, me,
> Dick?), but maybe most are running - can only run - the last pre-release?

again, although the scripts are (as yet) in no fit state, using a different
version of POV-Ray will only need changing a file name, and to use scenes
different from v3.7 also is just a matter of adjusting paths.  ideally those
data (names of exectuables, etc) ought to be in the db too; but then we'd need
to talk (re)design "properly".

regards, jr.

[William F Pokorny] v3.8 Clean up TODOs. New shadow_tolerance keyword. [2177 days 14 hours and 2 minutes ago]

Wed, 22 Apr 2020 17:50:52 GMT

It's the case today, when during shadow ray tracing the intersection 
depth is less than an internal shadow tolerance (SHADOW_TOLERANCE) of 
1e-3, POV-Ray ignores opaque intersections and sees through to the light 
source.

The tolerance exists because we often need to ignore same shape close 
intersections in shadow ray tracing either because we are picking up the 
same shape on surface intersection again due numerical issues, the 
surface is noisy and nearly parallel to the ray, or, the surface has a 
problematic curvature for shadow ray tracing.

In povr I'm adding a new shadow_tolerance keyword to the global_settings 
block which allows the shadow tolerance to be adjusted scene to scene. I 
think such a new keyword a good idea for any eventual v3.8 release 
baring better fixes.

The keyword often enough to get around shadow ray, see through issues. 
Longer term we need to figure out better ways to sort the shadow ray 
tracing for these extremely close intersections. (Shadow tracing opaque 
objects in the opposite direction a good start. Always, or upon tripping 
the shadow tolerance intersection skip.)

Attached is an isosurface scene using the new to povr f_mult1to8pairs to 
do a difference between two spheres. The smaller cutting into the larger 
while using a small value burn off to get rounded edges.

Straight up with a larger accuracy setting you get rings artefacts (not 
shown). The traditional way to try and solve this is to crank down on 
the gradient and the accuracy. Taking the accuracy to 0.0001 in this 
scene and we suddenly get a bright arc where there should be shadow. 
What is happening is the inside curvature is 'inconvenient' for the 
shadow ray tracing given the usual 1e-3 shadow tolerance.

In the middle image we use: global_settings { shadow_tolerance 1e-5 } 
and, presto, we get the correct result. The difference image on the 
right uses a multiplier of 3x to make the differences a little easier to 
see.

Bill P.

Aside: And the trouble makers amoung us are thinking about other ways 
the existing see through issue on shadow testing can corrupt results in 
subtle ways... :-)

Aside 2: I've been running with 1e-5 in povr for a while with the solver 
branch fixes. It's a better default. A few sor and lathe test scenes 
with near orthographic angles and the shipped cornell.pov scene are the 
only places where 1e-5 has been too small. If you have the other fixes 
to run at 1e-5, it fixes most all the scenes people have posted over 
time with bright speckles caused by the shadow ray see through issue/bug.

[William F Pokorny] Re: v3.8 Clean up TODOs. f_superellipsoid() / sh... [2177 days 19 hours and 23 minutes ago]

Wed, 22 Apr 2020 12:30:34 GMT

On 4/21/20 3:52 AM, jr wrote:
> hi,
> 
...
>>
>> The scale and range of a scene with respect to accuracy as an issue is
>> always there relative to the accuracy you have available.
> 
> naively, I'd assumed some kind of upgrade/development "policy" that sees all
> floats replaced with doubles, in time.
> Maybe. I'm not aware of any such policy, but I'm not a core developer.

The code base is internally mostly at double floats. There are a few 
places like bounding and color management where single floats get used. 
Done to save storage in the former I think or where the additional 
accuracy is of no practical value (to color results at least) in the 
later. On 'my' list to look at moving these to doubles.

For povr in the continuous pattern wave modification code I recently 
moved a few pattern stored values from singles to doubles. Partly to 
avoid the type conversions, but mostly because my grand plan is to flush 
out the function/pattern code so the interplay between functions and 
patterns is as seamless as it can be. I didn't want functions modified 
by a wave modifier to be getting single float parameters - in a way not 
visible to the user - when the reasonable assumption is everything is at 
double floats.

>> ...
>> Relatedly, I believe in going after better performance continually in
>> software tools - otherwise you're on the slippery slope to poky. :-)
> 
> hmm, I probably "sit on the fence" on that.  eg agree with you when it's a
> compiler or other s/ware which has to take h/ware developments into account, but
> kind of disagree for, say, programs not tied to h/ware, like 'sed'.
> 

I'm with you I think. I failed to be clear (I 'was' too flippant :-)). I 
am pushing for continual performance testing and especially an 
unwillingness to take much slowdown due changes over time without 
compensating improvements somewhere.

What has happened intentionally - or not - with POV-Ray moving v37 to 
v38 and the generic architecture compile shipped with linux 
distributions is a 30-40% slow down with certain common types of scenes.

https://github.com/POV-Ray/povray/issues/363

This after running down a lot of stuff like dynamic casts in the ray 
tracing code to recover performance seen in the benchmark scene.

In part the benchmark scene doesn't cover but a small slice of 
functionality in POV-Ray and mostly this was all that was getting run 
for performance testing.

I believe too, too many times we said this change is only a 1 or 2% slow 
down... Do enough of those in a year and you are well on to pokey at 
year end. The 1 or 2% slowdown at year end is relative to current 
performance. Many later changes, if looked at January 1st, might have 
been rejected out of hand as being too much of a slow down.

Aside: The GNU build methodology supports a code marking method for 
hardware optimized versions of functions that get picked/set at 'load 
time' depending upon your particular hardware or certain hardware 
capabilities. Both compiler and hand optimized code can be implemented 
in this way. Yes, this a reason my personal povr version is headed to a 
GNU only build(1) process. I want to play with this capability in povr 
proper.

Bill P.

(1) - Our current vector template class looks to be somewhat in the way 
of best 'compiler' hardware optimization...

[jr] Re: v3.8 Clean up TODOs. f_superellipsoid() / sh... [2178 days 23 hours and 58 minutes ago]

Tue, 21 Apr 2020 07:55:00 GMT

hi,

William F Pokorny <ano### [at] anonymousorg> wrote:
> On 4/18/20 4:12 PM, jr wrote:
> > ... the problem is/was the range of float not being enough.
>
> Not trying to be flippant, but I think it does when it does, and doesn't
> when it doesn't. It's a judgement.
>
> The scale and range of a scene with respect to accuracy as an issue is
> always there relative to the accuracy you have available.

naively, I'd assumed some kind of upgrade/development "policy" that sees all
floats replaced with doubles, in time.

> ...
> Relatedly, I believe in going after better performance continually in
> software tools - otherwise you're on the slippery slope to poky. :-)

hmm, I probably "sit on the fence" on that.  eg agree with you when it's a
compiler or other s/ware which has to take h/ware developments into account, but
kind of disagree for, say, programs not tied to h/ware, like 'sed'.

regards, jr.

[Bald Eagle] Re: v3.8 Clean up TODOs. Add jitter to isosurface. [2179 days 7 hours and 13 minutes ago]

Tue, 21 Apr 2020 00:40:00 GMT

William F Pokorny <ano### [at] anonymousorg> wrote:

> Perhaps the simplest set up for demonstrations is a f_sphere() sphere a
> light and an orthographic camera.

I ... may have noticed that.    :D

Very nice improvements.  Those should look great with some flashier functions.
:)

[William F Pokorny] v3.8 Clean up TODOs. Add jitter to isosurface. [2179 days 22 hours and 22 minutes ago]

Mon, 20 Apr 2020 09:31:14 GMT

Today, it can be nearly impossible to eliminate some isosurface accuracy 
artifacts no matter how small accuracy. The issue most often comes up 
with shadows and is related to issues with the internal hard coded 
shadow tolerance and shadow ray treatment.

Perhaps the simplest set up for demonstrations is a f_sphere() sphere a 
light and an orthographic camera.

In povr I've deleted the new to v38 isosurface polarity convenience 
feature(1) which was costing around 1% at scene with simpler functions.

Used the 1% from above to add the conditional for a new jitter feature 
for isosurfaces. It is just on or off and when on it jitters the 
accuracy value on each recursive solver descent by +-0.5 * 
(accuracy*0.96...7) which in testing ranges of jitter seems to work 
well. We'll see. Default is off so nothing changes unless it's turned on.

Image attached - and yes it was scaled down for size making the defects 
sometimes harder to see.

Some timing data below too. With jitter and AA you end up slower and 
faster - just depends.

Aside 1: Unsure whether it will be useful or not, but the jitter does 
slightly roughen the final surface. Might it be useful for surface 
effects? Blurred reflections of a sort?

Aside 2: On my list to bring out the shadow_tolerance as a global 
setting. Being able to twiddle with it can often fix see through opaque 
shape issues when the intersection depth is < the shadow tolerance. 
There is a core issue shadow ray issue no matter. One which can be fixed 
for many cases, but it's a relatively big job that's tangled with the 
shadow cache mechanism.

Bill P.

(1) - Polarity is/was an option not strictly necessary. There is too the 
question of whether grabbing the potential through an isosurface makes 
sense when you can - and probably should - work with the input function 
directly to get the 'potential' / the function values.

------
Timing results. Conditions slightly different than attached image.

--- Adaptive jitter
accuracy 0.0005 max_gradient 1.1
povr2 tmp.pov +w900 +h900 +a0.1 +am2 +r4 +p
24.142 -> 23.519   -2.58%
     tmpAM2_00j_a01_R4    24.142
     tmpAM2_09j_a01_R4    23.519  (Vastly better result and faster)
-
accuracy 0.0001 max_gradient 1.1 (No AA hard-ish to see circles)
povr2 tmp.pov +w900 +h900 +a0.1 +am2 +r4 +p
16.606 -> 19.020  +14.54%
     tmpAM2_00j_a01_R4a   16.606s
     tmpAM2_09j_a01_R4a   19.020s (Harder to see but better at a cost)



--- Fixed jitter to hard depth.  A render large and shrink approach.
accuracy 0.0005 max_gradient 1.1
povr2 tmp.pov +w900 +h900 +a0.0 +am1 +r6 +p
184.142 -> 186.095   +1.06%
     tmpAM1_00_R6.png  184.142
     tmpAM1_09_R6.png  186.095   (Faint circles gone at some cost)
-
accuracy 0.0001 max_gradient 1.1
211.89 -> 208.349    -1.67%
     tmpAM1_00_R6a.png  211.890  (No circles either case. In jitter
     tmpAM1_09_R6a.png  208.349  case get more feathered shadow as if
                                 surface has the slightest roughness)

[William F Pokorny] Re: v3.8 Clean up TODOs. f_superellipsoid() / sh... [2180 days 9 hours and 40 minutes ago]

Sun, 19 Apr 2020 22:13:06 GMT

On 4/18/20 4:12 PM, jr wrote:
> hi,
> 
> William F Pokorny <ano### [at] anonymousorg> wrote:
>> ...
>> Trick helps enough, I wonder if some other inbuilts could benefit from a
>> float over double option too.
> 
> does the .. cost of extra speed, in context, matter so much?  asking because
> (and perhaps I'm completely off-track) only today was a post (by user 'guarnio')
> where the problem is/was the range of float not being enough.
> 

Not trying to be flippant, but I think it does when it does, and doesn't 
when it doesn't. It's a judgement.

The scale and range of a scene with respect to accuracy as an issue is 
always there relative to the accuracy you have available.

With functions and isosurfaces, the speed of even very fast inbuilt 
functions matters because you mostly want to combine them with other 
functions to create whatever. The performance of all those functions 
mixed together mathematically is what can quickly get out of hand to the 
point of being practically unusable performance wise.

With functions and isosurfaces, we already have an object with user 
variable accuracy via the accuracy value passed which is often << 7/8 
digits (I typically use 0.0005). I've done some limited testing and the 
isosurface solver and - partly due the types of functional input - it 
cannot deliver more than 6-7 digits of accuracy max as a rule sometimes 
less. With other object types and solvers you can get up in the 11/12 
digit ranges though often less. All at doubles.

Relatedly, I believe in going after better performance continually in 
software tools - otherwise you're on the slippery slope to poky. :-)

Bill P.