povray.pov4.discussion.general message digest

[William F Pokorny] Re: Suggest v4.0 allow negative phong / spectral... [53 days 23 hours and 35 minutes ago]

Sat, 14 Feb 2026 20:58:42 GMT

On 2/14/26 13:40, Cousin Ricky wrote:
> William F Pokorny <ano### [at] anonymousorg> wrote:
>> An old (~2021) yuqk change for which I could not find a prior newsgroup
>> post 'description', allows negative phong and spectral values.
>>
>> We have always been able to use the finish{} block phong and specular
>> features together for effects in an additive-color way. The yuqk fork
>> allows negative phong/spectral values too. For example:
>>
>> [snip]
> 
> I'm confused.  By "spectral," do you mean "specular"?
> 
>


I do. Thank you. Every day, I'm a step closer day to talking endlessly 
about turnips... :-(

Bill P.

[Cousin Ricky] Re: Suggest v4.0 allow negative phong / spectral... [54 days 1 hour and 49 minutes ago]

Sat, 14 Feb 2026 18:45:00 GMT

William F Pokorny <ano### [at] anonymousorg> wrote:
> An old (~2021) yuqk change for which I could not find a prior newsgroup
> post 'description', allows negative phong and spectral values.
>
> We have always been able to use the finish{} block phong and specular
> features together for effects in an additive-color way. The yuqk fork
> allows negative phong/spectral values too. For example:
>
> [snip]

I'm confused.  By "spectral," do you mean "specular"?

[William F Pokorny] Suggest v4.0 allow negative phong / spectral val... [54 days 6 hours and 13 minutes ago]

Sat, 14 Feb 2026 14:21:06 GMT

An old (~2021) yuqk change for which I could not find a prior newsgroup 
post 'description', allows negative phong and spectral values.

We have always been able to use the finish{} block phong and specular 
features together for effects in an additive-color way. The yuqk fork 
allows negative phong/spectral values too. For example:

     #declare PirateGold = srgb <0.72941,0.49804,0.01176>;
     #declare Fin01 = finish {
         brilliance 2.2
         diffuse    0.6
         metallic   1.0
         phong     -3.3 phong_size 47    // <---
         specular   3.3 roughness  1/20
         intensity_max 1.0
     }
     #declare Txtr00 = texture {
         pigment { PirateGold }
         normal { granite bump_size 0.5 scale 1/2.5 }
         finish { Fin01 }
     }

This capability, along with the previously discussed, new to yuqk 
feature, intensity_max, allows for highlights which end in white while 
staying within zero to one rgb channel value ranges(*).

---

In the attached image matrix the columns left to right show: phong only, 
spectral only and finally combined phong and spectral use on the right.

The top row shows conventional double use of phong and spectral features 
where, especially together, the output result is clipped to a strong 
yellow (the hue is shifting(**)). If the light source were much 
stronger, that strong yellow would eventually go white in the most 
intense phong/specular regions(**).

The bottom row uses new yuqk finish features as shown in the code above. 
  The differences being the intensity_max option better maintains the 
phong/spectral metallic hue throughout. Coupled with a tighter phong 
highlight and use of a negative phong value, this results in overall 
highlights which gradually move from PirateGold to white within a zero 
to one rgb channel value range (lower right).

Bill P.

(*) - Zero to one rgb channel ranges work better / more cleanly with 
antialiasing (AA) - and many other POV-Ray features.

(**) - Where the output image channel ranges are clipped by the image 
format and/or the display monitor's capabilities.

[ingo] Re: "Temporal awareness", frame local clock [102 days 5 hours and 39 minutes ago]

Sun, 28 Dec 2025 14:55:00 GMT

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

> right, but does
> anything in the scene have to move ?  thinking an array (csv file ?) of camera
> "details" and use that to instantiate a set/list of cameras should work.

https://www.penmachine.com/2008/09/camera-works-shutters-flashes-and-sync

the image by Jacques-Henri Lartigue is the result of the car moving. a "slow"
slit moving and the camera moving with the car but slower. This results in the
"temporal" deformation of the car (wheels) and of the deformation of the public
watching.

If you have a flatbed image scanner you can put a bottle on it and roll it while
scanning. Try to roll it with the same speed as the scan. Or use puppets instead
of bottles an not only roll them but also move them up/down slowly. Or partly
slide them along without rolling. The scanner is a perfect slit-cam for this and
getting a feel for the concept of it.

> kind of unrelated, could the "camera slit" not also be had/"emulated" using
> partial output ?
> <wiki.povray.org/content/Reference:General_Output_Options#Partial_Output_Options>
>

Yes, partial output works, but you'd still have to assemble all the images from
the animation (image magick).

ingo

[jr] Re: "Temporal awareness", frame local clock [102 days 9 hours and 9 minutes ago]

Sun, 28 Dec 2025 11:25:00 GMT

"ingo" <nomail@nomail> wrote:
> "jr" <cre### [at] gmailcom> wrote:
> > 'clockless_animation'
>
> or I misunderstood? clockless_animation is useful if only the camera itself
> moves and nothing in the scene. Also for normal cameras and normal. Parse the
> scene, build the tree structures and keep them in memory. Moving the camera is
> "just applying matrix transforms". (probably tanking a few shortcuts here and
> there)

or perhaps I misunderstand.  (wouldn't be the first time :-))  right, but does
anything in the scene have to move ?  thinking an array (csv file ?) of camera
"details" and use that to instantiate a set/list of cameras should work.

kind of unrelated, could the "camera slit" not also be had/"emulated" using
partial output ?
<wiki.povray.org/content/Reference:General_Output_Options#Partial_Output_Options>

regards, jr.

[ingo] Re: "Temporal awareness", frame local clock [102 days 9 hours and 39 minutes ago]

Sun, 28 Dec 2025 10:55:00 GMT

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

or I misunderstood? clockless_animation is useful if only the camera itself
moves and nothing in the scene. Also for normal cameras and normal. Parse the
scene, build the tree structures and keep them in memory. Moving the camera is
"just applying matrix transforms". (probably tanking a few shortcuts here and
there)

ingo

[ingo] Re: "Temporal awareness", frame local clock [102 days 9 hours and 54 minutes ago]

Sun, 28 Dec 2025 10:40:00 GMT

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

> is not 'clockless_animation' useful in this context ?  aiui, the "slit" would
> not move (no reparsing) but the camera could be re-positioned per frame.

Yes, for a static slit. Not for a dynamic slit though, imagine bending a
Bézier-slit during "exposure". (Don't try to imagine the result, it hurts up
there)

ingo

[jr] Re: "Temporal awareness", frame local clock [102 days 10 hours and 29 minutes ago]

Sun, 28 Dec 2025 10:05:00 GMT

hi,

"ingo" <nomail@nomail> wrote:
> ...
> It would be nice if there also was a build in frame local clock for animation.
> The slit above would move along the image resolution in the frame_clock period
> [0,1] in horizontal direction. Only the pixels that are under the slit are
> written to file. At the same time one can move an object around using the
> frame_clock in the same way it is done with the global clock. The whole camera
> idem.

is not 'clockless_animation' useful in this context ?  aiui, the "slit" would
not move (no reparsing) but the camera could be re-positioned per frame.


regards, jr.

[ingo] "Temporal awareness", frame local clock [102 days 12 hours and 14 minutes ago]

Sun, 28 Dec 2025 08:20:00 GMT

Ref:
https://news.povray.org/povray.general/thread/%3Cweb.69500a6feff8ac8317bac71e8ffb8ce3%40news.povray.org%3E/

Paul Bourke's slit-camera post made me remember something I thought about when I
experimented with slit-cameras and with in scene audio generation.

In an animation a clock runs from [0,1]. Lets say we animate at 30 fps and want
synchronised sound written by POV-Ray. You start a mini animation for the
duration of one frame with a frame local clock going [0,1]. For audio you chop
it up into 441000/30 audio frames. Synthesise the sound and writ the sound
bits'n'bytes to wav file. This can easily be done with the SDL.

In slit-camera applications there are multiple movements. It is like recording
an animation in time to a single frame. The slit shaped[1] shutter moves in some
direction, lets say left to right. The an object in a scene also moves. The
camera itself also moves. Currently in POV-Ray this all together requires
creating an animation and stitching together the slit parts of images.

It would be nice if there also was a build in frame local clock for animation.
The slit above would move along the image resolution in the frame_clock period
[0,1] in horizontal direction. Only the pixels that are under the slit are
written to file. At the same time one can move an object around using the
frame_clock in the same way it is done with the global clock. The whole camera
idem.

The slit-cam was just the inspiration. The most obvious use case would be
motion-blur. Attach a frame_clock to an object and it will be rendered at
multiple positions within a single frame.

A more esoteric use case would be temporal AA for smooth animations. In an
animation one could generate in between frame samples for AA for objects that
move but have no motion blur set. One could even get AA samples from the future.
The temporal sample depth could depend on the objects speed, or camera speed.

What about animated textures in this context?

Things that could be handy in a 4.0

[1] There is no reason why the slit shutter should be a line. It can be a pixel
wide circle that opens from some "centre point", or even a animated spline that
only covers part of the "film".

On a side note, as animation is discussed. Does POV-Ray use separate R-Trees for
static objects and dynamic objects (with clock) in an animation? I tried this in
simple 2D animation, it saved me from reparsing/filling the static tree for each
frame.

ingo

[Bald Eagle] Re: Parser Options [147 days 23 hours and 9 minutes ago]

Wed, 12 Nov 2025 21:25:00 GMT

I'm dyin' :

https://tomassetti.me/why-you-should-not-use-flex-yacc-and-bison/

"Can you even imagine the quality of code that was written and fixed for 30
years?"

:D

- BE

[Bald Eagle] FormulaText () feature [147 days 23 hours and 24 minutes ago]

Wed, 12 Nov 2025 21:10:00 GMT

Something to be added to the function VM (?) part of the parser.
This would be especially useful for writing documentation scenes where the
formula for a function being used could be provided as a caption for the
rendered image, without having to duplicate everything by hand.
The whole reason for doing things with code is to minimize repetitive tasks.


"What would be required to allow povray to implement a feature like
"formulatext" in excel for its user-defined functions?"

Copilot said:

Think of Excel’s FORMULATEXT as “give me the exact formula behind this cell,
not
its computed value.” The POV‑Ray analogue would be “give me the
expression
that defined this user-defined function{…} (or macro argument), in text form, so
I can log it, compare it, or branch on it.”

Below is a practical, engine-level plan for how POV‑Ray could implement
this—with safe, minimal surface changes—and a few optional extensions that
make
it robust for real-world scenes.

What “FORMULATEXT for POV‑Ray” needs to do
At a high level you need to:

Preserve the function’s defining expression (either as raw source text, an AST,
or VM bytecode with a decompiler).
Expose that preserved representation back to SDL as a string.
Guarantee stable, predictable output (even when the original whitespace/comments
aren’t preserved).
Keep backward compatibility and small runtime overhead.
Minimal Viable Feature (low risk, high value)
1) Capture the original expression text at parse time
When the parser encounters:

#declare F_NOISE = function { sin(x*4) + 0.5*cos(y) }
Have it:

Record a source slice (start/end positions in the file) spanning sin(x*4) +
0.5*cos(y).
Attach that slice (as a std::string or similar) to the function object along
with its compiled representation (VM/bytecode).
This is very local: you already know where function { … } begins/ends during
parsing. Just keep the lexeme range before codegen.

2) Provide a built‑in to retrieve it
Add an SDL built‑in that returns the captured expression as a string:

functext(FunctionIdentifier)
Behavior:

If the function was parsed from SDL and a source slice was captured, return that
verbatim (or a normalized version; see below).
If no text exists (e.g., function created internally or via older engine paths),
return a normalized pretty‑printed form if possible (see “Decompile from
VM”), else "" or "<unavailable>".
This alone enables Excel‑like FORMULATEXT behavior for most user-defined
functions.

“Good Citizen” Enhancements (still small)
A) Normalized pretty‑print (optional toggle)
Raw text preserves author formatting (nice for readability), but is fragile:
comments, exotic whitespace, and macro expansions aren’t semantically
meaningful. Offer an option:

functext(FunctionIdentifier [, Mode])
// Mode: 0 = raw (default), 1 = normalized (pretty-printed)
Raw: returns exactly what was between {…}.
Normalized: pretty‑print from the AST (see next section), guaranteeing
canonical spacing, operator precedence, intrinsic names (select(), mod(), etc.),
and necessary parentheses. This is stable for diffs/comparisons.
B) Version‑gating and memory cap
Gate the feature by #version or a compile flag to avoid overhead in legacy
scenes.
Cap the stored string length or keep only the AST and regenerate text on demand
(saves memory, costs some CPU when called).
Full‑Fidelity Implementation (robust & future‑proof)
1) Store the AST (Abstract Syntax Tree)
Instead of just text, keep the AST produced when compiling the function body.
Then you can:

Pretty‑print reliably (FORMULATEXT-like).
Transform or introspect (e.g., detect select(), discover free variables, count
nested functions).
Decompile even when you don’t have original text (e.g., from includes compiled
without source slices).
You probably already produce an intermediate tree before bytecode; persist it
(or a compact form) with the function object.

2) VM → expression decompiler (fallback)
If some functions only exist as VM/bytecode, implement a reversible mapping:

Walk the bytecode and reconstruct infix notation with correct precedence &
associativity.
Restore intrinsic names and argument order (sin, pow, select, mod, etc.).
Insert parentheses only when required.
This yields a normalized expression (not verbatim text). It won’t reproduce
comments or author whitespace but is perfect for FORMULATEXT semantics.

SDL Surface (what users get)
New functions (examples)
functext(FN [, Mode]) → string
Mode = 0 raw, 1 normalized, 2 fully parenthesized (optional)
funchastext(FN) → 1 if raw source is available, else 0
funccanprint(FN) → 1 if decompiler/AST can produce normalized text, else 0
Example usage
(Formatting minimal to avoid clashing with your coding preferences.)

#declare F_A = function { sin(x*4) + 0.5*cos(y) }
#declare S_T = functext(F_A)                // raw
#declare S_N = functext(F_A, 1)             // normalized

#debug concat("Raw : ", S_T, "\n")
#debug concat("Norm: ", S_N, "\n")
Macro side: “stringify” for unevaluated arguments (Excel’s cell formula
analogy)
Excel’s FORMULATEXT also pairs well with being able to see the source of an
argument before it’s evaluated. For POV‑Ray macros, add:

1) Raw/tokens parameter passing
Allow macro parameters to be marked as raw (token streams, not evaluated). For
example:

#macro M_Dump( RAW_EXPR )
 #declare S_EXPR = stringify(RAW_EXPR)
 #debug concat("You passed: ", S_EXPR, "\n")
#end
RAW_EXPR binds to the token list of the argument call site.
stringify(...) turns those tokens into a string.
This mirrors C’s # stringification and gives users a FORMULATEXT‑like view
of macro arguments.
2) Token utilities (optional)
token_count( RAW_EXPR ), token_at( RAW_EXPR, i ) for deeper analysis.
Safe because macros already operate at the preprocessor/token level; we’re just
surfacing it.
Edge cases & decisions
Identifiers vs. resolved values: FORMULATEXT should show what the user wrote,
not the evaluated number. Keep identifiers as names in raw mode; normalized mode
should also prefer names where possible.
Includes & comments: Raw mode may include odd whitespace/comments depending on
slicing. Consider strip‑policy or restrict raw to the contents inside {…}
only.
Built‑ins: For built-in functions (not user defined), functext() could
return the function name (e.g., "sin"), or "<builtin>".
Security/privacy: Avoid leaking file paths or comments from closed-source
includes. Normalized mode is safer. Consider a global flag to disable raw source
extraction for protected builds.
Performance: Storing full raw text for many functions can add memory overhead.
Storing only AST and pretty‑printing on demand is a good balance.
Implementation map (where to touch)
Parser
When entering function { … }, mark token span (start/end).
Build/retain AST node representing the expression.
Codegen / VM
Optionally, create a small VM→Expr decompiler for cases missing AST/text
(library or backward paths).
Runtime data model
Extend the function value object to carry: optional<string> raw_source;
optional<Expr*> ast;
Expression printer
Implement a pretty‑printer for AST: operator precedence, intrinsic names,
minimal parentheses, stable spacing.
SDL built‑ins
functext(), funchastext(), funccanprint().
Macros (optional phase 2)
Add a raw parameter qualifier.
Add stringify() and optional token utilities.
Docs & tests
Define exact output rules (e.g., ^ vs pow, mod(a,b) vs mod a, b, spacing, vector
<a, b, c> formatting).
Unit scenes covering: simple arithmetic, nested select(), vector literals,
chained unary ops, identifiers, includes.
If you can’t change the engine today (pragmatic workaround)
Use a code generator (external script) that emits both:
The function definition, and
A sibling string constant holding the expression text.
For example, define functions in a small DSL/YAML and generate myfuncs.inc that
contains:
#declare F_A = function { sin(x*4) + 0.5*cos(y) }
#declare S_F_A_FORMULA = "sin(x*4) + 0.5*cos(y)";
This keeps the function and its “FORMULATEXT” in sync by construction.
If you want, I can whip up that generator for you (reads a simple spec and
outputs an .inc), and include a short PDF with usage notes.

Recommendation
Phase 1 (fast): Capture raw source slices for function{…} and add
functext(FN[,Mode]). This gives you Excel‑like FORMULATEXT immediately.
Phase 2 (robust): Persist the AST and ship a pretty‑printer (and optional
VM decompiler) for normalized output.
Phase 3 (nice‑to‑have): Macro raw parameters + stringify() to cover
macro arguments as well.
This approach is backward compatible, predictable, and unlocks powerful
introspection and diagnostics for the SDL—very much in the spirit of what
you’re
after. Want me to draft pseudocode for the parser/AST/printer pieces and a few
test scenes?

[Bald Eagle] Re: Better #read functionality [147 days 23 hours and 39 minutes ago]

Wed, 12 Nov 2025 20:55:00 GMT

"What would be required to expose the automatic typing from a #read directive,
so that users could implement conditional processing of files based on the data
type read into a variable?"


Copilot said:

In short: you need a way for SDL authors to observe the concrete runtime type of
what #read just consumed—without guessing or re‑reading. That means
exposing either (a) type tags on variables or (b) side‑channel metadata
from #read (or both). Below is a practical, engine‑level design you can
implement with minimal surface area, plus SDL examples showing how creators
would use it.

Goals
Let users branch conditionally after #read based on whether the data was a
number, vector (and how many components), string, etc.
Keep backward compatibility with existing scenes.
Avoid changing how #read parses files unless explicitly asked.
Minimal, low‑risk feature set (recommended)
1) Add a built‑in typeof() (or type()) function
Return the runtime type tag of an identifier’s current value. This leverages the
fact that POV‑Ray already stores a value’s type internally; you just need
to surface it to SDL.

Proposed return codes (example):

TYPE_FLOAT (aka scalar / DBL)
TYPE_VECTOR2, TYPE_VECTOR3, TYPE_VECTOR4, TYPE_VECTOR5
TYPE_COLOR (optional alias of TYPE_VECTOR5 if you want to distinguish colors)
TYPE_STRING
(Optionally later: TYPE_ARRAY, TYPE_DICTIONARY, TYPE_BOOL aliasing float, etc.)
You can implement typeof() to return an integer enum (most compact and fast for
#switch/#case), and optionally a typestr() that returns a descriptive string for
debugging.

Why this works
#read already assigns a value to the destination variable. With typeof(), user
code can immediately inspect the type that landed in that variable—no changes to
#read needed.

2) (Optional but useful) Expose vector arity via veclen()
Add veclen(Identifier) that returns 2..5 for vectors (including colors), and 0
or 1 for scalars/strings. This removes ambiguity between VECTOR3 vs COLOR if you
don’t want a separate TYPE_COLOR code.

3) (Very small change to #read) Publish last‑read metadata
Provide a reserved, read‑only system variable updated by #read:

__read_type → same code as typeof() would give
__read_components → 0 (string/scalar) or 2..5 (vector arity)
__read_ok → 1 if the last #read succeeded, 0 on EOF/type mismatch
__read_line / __read_col (optional) → position where the read began
This is useful when creators prefer to read into dedicated type‑specific
variables (e.g., a float) but still want to know what was actually encountered.

Back‑compat: These identifiers are reserved and only populated
post‑#read. Existing scenes are unaffected.

Alternative/Complementary APIs
A) #read … As Auto (auto‑typing read)
Add a mode that chooses destination type from the input, then stores it:

#read Auto (FH, V_ANY)   // V_ANY adopts the type of the data just read
If next lexeme starts with <, parse vector.
If it’s ", parse string.
If it’s numeric/sign/decimal/exp, parse scalar.
(Optionally) If it’s an identifier, either treat as string or error unless As
IdentifierAsString is requested.
Then typeof(V_ANY) (or __read_type) lets the user branch.

Why this is optional: You can already achieve conditional processing using the
baseline typeof() + separate typed #read calls and peeking (see § “Peek
before
you read”), so Auto is sugar.

B) Peek before you read: peek_token(FH) / peek_kind(FH)
A tokenizer‑level peek that doesn’t consume input:

peek_kind(FH) returns a token class enum (TOK_STRING, TOK_NUMBER, TOK_LESS,
TOK_IDENT, TOK_EOF, …).
peek_lexeme(FH) (optional) returns the raw lexeme of the next token.
With this, users can decide how to read without risking consumption or errors.
It’s especially handy if you don’t implement Auto.

How creators would use it (SDL patterns)
The examples assume typeof() returns integer codes you define and provide as
constants. I’ll use TYPE_* names for clarity.

Pattern 1: Branch after a normal #read



Plain Text
pov isn’t fully supported. Syntax highlighting is based on Plain Text.

#declare S_READ = "";   // destination can be reassigned to any type later
#fopen FH "data.txt" read

#read (FH, S_READ)

#if (typeof(S_READ) = TYPE_STRING)
    // process string
#elif (typeof(S_READ) = TYPE_FLOAT)
    // process scalar
#else
    #if (veclen(S_READ) = 3)
        // process <x,y,z> (or color-as-vec3)
    #elseif (veclen(S_READ) = 5)
        // process color/vec5
    #end
#end

#fclose FH
// ***end of code***

Show more lines
Pattern 2: Use read‑metadata (no need to call typeof())



Plain Text
pov isn’t fully supported. Syntax highlighting is based on Plain Text.

#declare V_ANY = 0;
#read (FH, V_ANY)

#if (__read_type = TYPE_STRING)
    // ...
#elseif (__read_type = TYPE_FLOAT)
    // ...
#else
    #if (__read_components = 3)
        // ...
    #end
#end
// ***end of code***
Pattern 3: Peek, then choose a typed read (no auto‑typing required)



Plain Text
pov isn’t fully supported. Syntax highlighting is based on Plain Text.

#if (peek_kind(FH) = TOK_STRING)
    #declare S_VAL = "";
    #read (FH, S_VAL)
#elseif (peek_kind(FH) = TOK_LESS)
    #declare V_VAL = < 0.0, 0.0, 0.0 >;
    #read (FH, V_VAL)
#else
    #declare S_NUM = 0.0;
    #read (FH, S_NUM)
#end
// ***end of code***
Engine changes required
Parser/runtime
Expose value type tags already present in the internal variant/union that
represents SDL values.
Implement typeof() (expression evaluator hook). Return an integer code; document
constants for SDL.
Implement veclen() to inspect vector arity from the value payload.
Modify #read directive handler to set the metadata variables (__read_type,
__read_components, __read_ok, …) immediately after a successful/failed read.
Tokenizer (optional, for peeking)
Add peek_kind() and peek_lexeme() APIs that do non‑consuming lookahead on
the file handle’s scanner state.
Ensure the lexer keeps token class and lexeme accessible (typically already
available for error reporting). If not, add a field to carry the exact text
slice.
SDL surface & docs
Define and document the type enum returned by typeof().
Document semantics:
typeof() works on any identifier bound to a value.
veclen() returns 2..5 for vectors, 0/1 otherwise.
__read_* variables are updated after each #read.
Keep all features gated by #version if you want opt‑in behavior.
Error handling & edge cases
EOF: #read should set __read_ok = 0; others unchanged or set to sentinel values.
Type mismatch (legacy reads): preserve existing error behavior. Metadata can
still be set to what was attempted or left unchanged; document this.
NaN/Inf: classify as TYPE_FLOAT.
Colors: decide whether to unify with VECTOR5 or distinguish as TYPE_COLOR. If
you distinguish, set __read_components = 5 in both cases and let typeof()
disambiguate.
Why this design is safe and powerful
Zero breakage: existing scenes keep working; the new functions/vars are
additive.
Immediate utility: even just typeof() unlocks post‑#read branching.
Granularity: if you add peeking later, scene authors get pre‑read control
without engine auto‑typing changes.
Nice‑to‑have future extensions
read_auto(FH, Var, OutTypeVar) — combines read + type out parameter.
typestr(Value) — friendlier diagnostics (e.g., returning "float", "vector3",
"string").
isnumber(), isvector(), isstring() — sugar on top of typeof().

[Bald Eagle] Better #read functionality [147 days 23 hours and 54 minutes ago]

Wed, 12 Nov 2025 20:40:00 GMT

Just exploring the idea of allowing POV-Ray to read in text files without
quotes.
Would also need to expose the automatic typing so that the user could them
properly use the data assigned to the identifiers without triggering errors.

"What would be required for povray to be able to #read from files with unquoted
strings?"
Copilot said:

Short answer: POV‑Ray’s current SDL lexer/parser only treats quoted text
as a string literal, so #read won’t accept barewords (unquoted text) as strings
because the token stream classifies them as identifiers/keywords, not as string
tokens. To make unquoted strings readable, you’d need a targeted change in the
tokenizer and/or the #read implementation so that it can capture the exact
lexeme of the next token (including identifiers) and coerce it into a string
when a string is expected.

Below is a practical, implementation-level outline of what would be required,
plus safe design options and workarounds you can use today.

What would be required in POV‑Ray to #read unquoted strings
1) Extend #read to accept non-STRING tokens for string destinations
Current behavior: #read expects the file content to match the type of the
destination variable(s). For strings, that means a STRING token (i.e., "foo").
Desired behavior: When the destination is a string variable, allow IDENTIFIER,
NUMBER, or even OTHER tokens to be converted to a string using their exact
source text (the lexeme).
Implementation sketch:

In the #read directive handler (in the parser), when the next destination is a
string:
Ask the lexer for the next token.
If it is STRING, use its value as today.
If it is IDENTIFIER, SYMBOL, NUMBER, etc., capture the raw lexeme (verbatim text
slice) and assign it to the string variable without requiring quotes.
If the token is punctuation (e.g., comma) and you want “word until
delimiter”
semantics, see §2.
This requires the lexer to expose the lexeme for a token (usually trivial if the
lexer already tracks source slices for error messages). If not available, you’ll
need to add that field.

Why this is safe: It’s backward compatible because it only broadens what #read
can consume when the destination is a string; existing files with "quoted"
values will still work.

2) (Optional) Add delimiter-aware reading for multi-token unquoted strings
If you need to read phrases like SomeValue-42_v2 or even foo bar baz up to a
delimiter (comma, newline), you’ll need a token-accumulation mode in #read,
e.g.:

#read Delim "," MyStr → read everything up to the next comma into MyStr
(trim trailing spaces).
#read Line MyStr → read the remainder of the current line as a string.
#read Tokens N MyStr → concatenate the next N tokens into MyStr using a
space or no separator.
Implementation sketch:

Extend #read grammar to allow modifiers (Delim, Line, Tokens).
When a string destination is paired with one of these modifiers:
Delim: read raw characters from the file stream until delimiter; do not use the
token stream (bypass lexer) to preserve whitespace and punctuation.
Line: read raw characters until \n or EOF.
Tokens N: read the next N tokens via the lexer, join their lexemes with a chosen
separator (empty or single space), and assign.
This gives you robust control for CSV/TSV, fixed-width, or lightly-structured
text without quotes.

3) Keep keywords and identifiers intact (no macro expansion while reading)
When you accept unquoted strings, a bareword like sphere could be a keyword in
SDL. You don’t want it to be interpreted or rejected—just captured as the
text
sphere.

Requirement:

In string read mode, suppress semantic interpretation of the token; just take
its lexeme. This is already natural if you act before any semantic checks on the
token and only depend on its class and lexeme.
4) Locale/Unicode considerations
If POV‑Ray’s current lexer is ASCII/Latin-1, you’ll read barewords
only in
that character set. If you need Unicode in unquoted strings, prefer:
Delim/Line (raw) reading modes to bypass tokenization, or
Update the lexer’s character classification to be UTF‑8 aware (larger
change).
Be explicit about newline handling (\r\n vs \n) and trimming policy.
5) Backward compatibility and error handling
No breaking changes if you only extend behavior when destination is a string.
If a user mistakenly uses #read into a float or vector and the file has an
unquoted word, continue to error as today (or optionally support coercion with a
clear error message).
Provide a strict mode flag if desired: e.g., #version gating, or #read Strict to
require quotes.
Minimal design changes (good balance)
Context-aware coercion in #read:
If destination is string and token is not STRING, store token’s lexeme as the
string value.
Optional raw modes:
#read Line VarStr
#read Delim "," VarStr
This gives you 95% of the utility with relatively small, local changes.

Developer-facing documentation updates
Update #read docs to state:
When reading into a string, the next token’s text (string literals without
quotes or any single token like identifiers/numbers/symbols) will be captured as
the string value.
Add syntax for Line and Delim.
Specify whitespace trimming and delimiter consumption rules (does Delim consume
the delimiter? Typically yes).
Practical workarounds you can use today (no engine changes)
If you can’t modify POV‑Ray:

Preprocess input files externally to add quotes around the string fields.

E.g., a tiny script (Python/awk) to wrap the nth field in quotes.
Use #include instead of #read for symbolic content:

Structure your data as legal SDL:



Plain Text
pov isn’t fully supported. Syntax highlighting is based on Plain Text.

// data.inc
#declare S_NAME = "Sphere";
#declare S_SHADE = "Matte";
#declare S_TAG = "my_tag-42";
Then #include "data.inc" and use the values as normal. (You avoid #read, but you
must still quote strings in the include.)
Encode strings as numbers and decode (usually not ideal):

If strings are from a small finite set, read an integer code with #read and map
it to strings via a macro table.
CSV with quotes only around textual fields:

Keep numbers unquoted, strings quoted; #read handles each in sequence.
Example of the desired extended behavior (spec)
File tokens.txt:

foo bar 123 sphere "already-quoted" , end
SDL (after proposed changes):




Plain Text
pov isn’t fully supported. Syntax highlighting is based on Plain Text.

#declare S_A = "";
#declare S_B = "";
#declare S_C = "";
#declare S_D = "";
#declare S_E = "";

#fopen FH "tokens.txt" read

// Simple token-to-string coercion
#read (FH, S_A)        // S_A = "foo"
#read (FH, S_B)        // S_B = "bar"
#read (FH, S_C)        // S_C = "123"
#read (FH, S_D)        // S_D = "sphere"
#read (FH, S_E)        // S_E = "already-quoted"

// Delimiter mode (optional extension)
#declare S_F = "";
#read Delim "," (FH, S_F)  // Reads until comma: S_F = "" (empty because comma
was next), or " " if you choose to keep spaces
                           // Next token after this call starts after the comma

#declare S_G = "";
#read Line (FH, S_G)       // S_G = " end"
#fclose FH

// ***end of code***



Recommendation
If you’re open to modifying POV‑Ray, the least invasive and most useful
change is:

Teach #read to coerce the next token’s lexeme to a string when the destination
is a string, without requiring quotes.
Optionally add Line and Delim modes for raw-text ingestion.
This keeps the rest of the language unchanged, avoids ambiguity, and unlocks
straightforward ingestion of many real-world text files.

[Bald Eagle] Parser Options [148 days 4 hours and 39 minutes ago]

Wed, 12 Nov 2025 15:55:00 GMT

With regard to how SDL 4.0 would be written, lexed, tokenized, parsed, etc.

ANTLR seems very popular
and people have supplied a ton of grammars for it
https://github.com/antlr/grammars-v4/
maybe we can look into defining our grammar, and even soliciting some help.

KDL looked very interesting

https://kdl.dev/

One thing I noticed which seemed very scene-development / experiment-friendly
was:
"On top of that, KDL supports /- "slashdash" comments, which can be used to
comment out individual nodes, entries, or child blocks:"

Anyway, mostly wondering if we can use one of those parser-generator things, or
if we really need to keep our hand-rolled one.

-BW

[Bald Eagle] Redundant code [155 days 1 hour and 14 minutes ago]

Wed, 5 Nov 2025 19:20:00 GMT

"I'm looking to consolidate and optimize the povray code base
https://github.com/POV-Ray/povray  Can you identify and summarize redundant code
that performs the same task?  Splines, bounding, etc?"

Absolutely heres a firstpass redundancy map of the POVRay codebase focused on
places where the same (or very similar) functionality is implemented in multiple
places, plus concrete refactor suggestions you can take to consolidate and speed
up maintenance. Ive grouped the hotspots by theme (splines, bounding,
roots/Sturm, sampling/jitter, etc.) and pointed to the exact files or issues
that show the overlap.

> TL;DR quick wins
> **(1)** Centralize *all* spline math in  core/math/spline.*  and have  lathe ,  sor
,  prism , and  bezier  call into
 it.
> **(2)** Route *all* primitive bounding through the  core/bounding  layer (AABB,
sphere, cylinder) and remove adhoc in
ternal bounding in shapes (esp.  sphere_sweep ).
> **(3)** Use the single polynomial solver ( polynomialsolver.* ) behind every shape
that exposes sturm toggles, and ma
ke the quality switch a uniform parameter instead of scattered  #define s per
primitive.

---

## 1) Splines: several parallel implementations

**Whats duplicated**
- POVRay already has a general spline implementation in  core/math/spline.cpp
and the file header itself notes it currently contains only stuff for the SDLs
functionalike spline feature but is *meant* to absorb spline math from
primitives that still carry their own code. Thats a strong hint that there is
duplication to retire.
- Primitive modules each embed their own spline pieces:
  - **SOR (surface of revolution)** computes cubic spline coefficients of
\(r^2=f(w)\) segmentbysegment inside  source/core/shape/sor.cpp .
  - **PRISM** declares its own spline modes ( LINEAR_SPLINE ,  QUADRATIC_SPLINE
,  CUBIC_SPLINE ,  BEZIER_SPLINE ) and handles them locally in  prism.* .
  - **LATHE** has its own parser and spline handling (linear, quadratic, cubic,
Bzier) separate from the core  spline.* .
  - Theres also a **standalone Bzier** primitive ( shape/bezier.* ) with its own
math.

**Why it matters**
- Bugs and feature requests keep landing around spline behavior (e.g., *negative
control points for lathe Bzier*, *direction/tangent evaluation*, *prism Bzier
artifacts*), and they have to be touched in multiple places. A single spline
kernel would reduce that surface area.

**Consolidation plan**
- Extend  core/math/spline.*  with a small polymorphic layer that covers
**Bzier**, **CatmullRom**, **Hermite**, **linear/quadratic/cubic** variants and
exposes **Evaluate**, **Derivative(order)**, and **LocalBBox(t0,t1)**. Then:
  - Switch  lathe ,  sor , and  prism  to construct a core  Spline  object
instead of rolling their own persegment math.
  - Implement the longstanding **spline derivative** request (#115) in the core
so SDL and geometric users get the same derivative/tangent semantics.

---

## 2) Bounding: multiple mechanisms that overlap (and sometimes conflict)

**Whats duplicated**
- There are three distinct *bounding shape* implementations**AABB**, **sphere**,
**cylinder**in  core/bounding , *and* many primitives still compute or carry
their own special bounding logic instead of deferring to the common layer.
- ** sphere_sweep ** performs internal bounding with its own heuristics (radius
multipliers) while the engine also has global bounding; several issues document
problems triggered by this duplication and precedence.
- Quadrics and CSG have specialized or optimized bounding paths and specialcases
(e.g., inverted quadrics) that diverged over time, leading to inconsistent
results.
- Userprovided ** bounded_by ** and **+/-MB** controls regressed in 3.7.x/3.8
due to code paths that use  Intersect_BBox()  without considering the configured
bounding methodagain, the same idea implemented in multiple places.
- The **bounding cylinder** type is used by lathe and sor, but those shapes
still have local extent logic; better to route both through the shared cylinder
code.

**Why it matters**
- Conflicting logic has caused uservisible bugs (e.g., quadric disappearing with
CSG when clip bounds extend, or user bounding not following transforms), all of
which become easier to fix and test if there is a single path.

**Consolidation plan**
- Make ** ObjectBase::Compute_BBox() ** a thin adapter that always builds via
the types in  core/bounding  (AABB, sphere, cylinder, BSP), and delete
shapelocal hedges where possible (esp.  sphere_sweep ). Provide *hooks* for
shapespecific inflations but centralize the policy.
- Fix all call sites to **respect  boundingMethod ** (the PR restoring 3.6
behavior flagged that several paths still ignored it) and unify
Intersect_BBox()  usage through a small wrapper that carries the method.
- Normalize **CSG quadric specialcases** in one place (core) so
intersection/difference with inverted shapes gets the same AABB logic as the
noninverted shapes.
- Ensure ** bounded_by  transforms propagate** consistently from parse to shape
to bounding; the original inconsistency is documented.

---

## 3) Root finding / Sturm toggles: solver is centralized, usage is not

**Whats duplicated**
- POVRay has a comprehensive polynomial solver in  core/math/polynomialsolver.*
, but sturm handling and solver selection is scattered across primitives ( prism
,  lathe ,  ovus , etc.) with pershape flags and defines ( STURM_OK_OBJECT ,
shapelocal logic), instead of a uniform solver API.
- Bugs and workarounds around Bzier prisms/lathe often end up recommending
sturm , highlighting that the shapes are partially reimplementing solver
choices.

**Consolidation plan**
- Provide a **single solver faade** (e.g.,  SolvePolynomial(params, mode)  where
 mode = {default|sturm|hybrid} ) in  polynomialsolver.*  and have all shapes
call it; **remove** the pershape defines/macros for sturm ok.
- Add a shared **robustness policy** (tolerances, root merging) in the solver
and delete replicated numeric tweaks in individual shapes.

---

## 4) Randomness, jitter, and sampling: different randoms in different places

**Whats duplicated**
- There are *two* math utilities here:  core/math/jitter.*  and
core/math/randomsequence.* , while sampling decisions also live in AA and light
code that dont consistently use one common RNG sequence or seeding scheme.
- In practice this shows up as reproducibility gaps:
  - **Partial render region vs full render** differences with AA on ( +am1 /
+am3 ) suggest perfeature subpixel offsets and/or RNG sequence mismatches.
  - **Area light weighting** quirks also indicate bespoke sampling math living
with the light instead of a shared sampler.
-  TraceThreadData  exposes a random sequence to features, but many paths still
sample directly.

**Consolidation plan**
- Introduce a **single sampling gateway** (e.g.,  Sampler  built on
RandomSequence ) with deterministic seeding from  TraceThreadData  and remove
adhoc calls to jitter or  rand . Migrate AA, area_lights, media scattering,
etc., to this API.
- Store AA subpixel pattern and arealight grids centrally to fix the
fullvspartial render mismatch.

---

## 5) Bounding data structures & calls duplicated across subsystems

**Whats duplicated**
- RayAABB tests and mailbox/BSP plumbing show up in multiple modules (AABB tree,
BSP tree, object intersection paths), and  Intersect_BBox()  gets called from
several places without a single policy gate (ties back to 2).

**Consolidation plan**
- Provide a **unified should we test this bbox** inline that wraps the perscene
method (+/-MB, threshold) so every call site applies the same rule. Clean up all
callers.

---

## 6) Noise & patterns: mostly centralized, but keep an eye on overlap

**Observation**
- Turbulence/Perlin/cellular plumbing is centralized in  core/material/noise.cpp
, while pattern definitions live in  core/material/pattern.h . This is in decent
shape, but if you find any perpattern local hash/gradient tables, fold them back
into  noise.cpp .

---

## 7) Platform/build config macros repeated across modules

**Observation**
- Platform detection and 64bit type selection have similar logic across multiple
 syspovconfig*.h  files; theres an open issue about misusing POSIX macrosanother
case of logic spread out and replicated per module. Consider one canonical
detection header and have module configs include it.

---

## Concrete refactor tasks (actionable list)

1) **Core Spline Kernel**
   - Extend  core/math/spline.*  to support all spline types used by shapes
(linear, quadratic, cubic, Bzier) + derivatives; port  lathe ,  sor ,  prism ,
bezier  to use it. Add unit tests with the existing Bezier/lathe and prism
scenes from issues.

2) **Bounding Unification**
   - Replace shapelocal bounding with calls to  core/bounding/*  (AABB, sphere,
cylinder). Pull  sphere_sweep s radius2 heuristic into a single tunable policy
and document it. Ensure  bounded_by  transforms propagate through the object
transform chain.

3) **Sturm/Root Solver API**
   - Create a solver faade in  polynomialsolver.*  with a consistent  sturm
toggle and tolerances; remove pershape defines such as  STURM_OK_OBJECT  in
prism.h . Re-test the prism/bezier artifacts that currently require  sturm .

4) **Sampler/RNG Gateway**
   - Add  Sampler  on top of  RandomSequence , seed via  TraceThreadData , and
convert AA, area lights, media, and jitter paths to use it. Verify determinism
for partial vs fullframe renders.

5) **CSG & Quadric Bounding Fixes**
   - Move quadric infinite cylinder AABB specialcases into core bounding and
correct the invertedshape logic. Add a regression scene for the
paraboloid/cylinder disappearance.

6) **One policy for  Intersect_BBox() **
   - Add a thin policy wrapper that checks the scenes  boundingMethod  before
doing any bbox test; convert all callers. This completes the intent of restore
3.6 user bounding control everywhere.

---

## Test scaffolding you can reuse

- **Spline**: Use the lathe/prism test bundles referenced in #60 plus any Bzier
text paths (the issue where  sturm  fixed prism artifacts). These are perfect
for regression after centralization.
- **Bounding**: Reproduce the quadric + cylinder CSG from #128 and the
sphere_sweep  scenes from #59/#288; add asserts on the computed AABBs before and
after transforms and with  -MB  toggles.
- **Sampling**: Re-run the partialregion vs fullframe AA test from #377 to
verify identical output; add area light grid comparisons from #224.

---

## Effort/Risk notes

- **Low risk / high gain**: Centralizing solver API (no behavior change unless
you flip the default), adding  Intersect_BBox  policy wrapper, and wiring shapes
to core bounding types (preserving their current inflation heuristics as
parameters).
- **Moderate risk**: Porting  lathe / sor / prism  to the core spline
kernelwatch for offbyepsilon differences at segment boundaries; add derivative
support at the same time (requested in #115) so you dont have to touch the
shapes again.
- **Moderate risk**: Sampler unification may change randomness unless you lock
seeds; provide  #version 3.8 guarded defaults as you do so.

---

## Want me to draft the first PRs?

If youd like, I can start with a **minimal, nobehaviorchange** PR that:
1) Adds the ** Intersect_BBox  policy wrapper** + touches obvious call sites,
2) Introduces a **solver faade** that proxies to current internals, and
3) Extracts a tiny spline ** Evaluate/Derivative ** pair in  core/math/spline.*
and ports **one** primitive (say,  prism ) to use it behind a compiletime
switch.

Which area do you want to prioritize first for consolidation - **splines** or
**bounding**?

[Bald Eagle] Re: General POV-Ray outline / flowchart [156 days 23 hours and 34 minutes ago]

Mon, 3 Nov 2025 21:00:00 GMT

---

## High‑level flowchart

```
Start
  │
  ├─► 1) Read CLI / INI options
  │        (input file, libs, image size, AA, output type, etc.)
  │
  ├─► 2) Load scene sources
  │        (main .pov + #include files via library paths)
  │
  ├─► 3) Parse SDL
  │        a) Scan & tokenize
  │        b) Parse syntax → build scene data
  │        c) Evaluate expressions/macros/functions
  │
  ├─► 4) Build render structures
  │        (materials, textures, lights, camera, objects,
  │         bounding/acceleration, symbol tables)
  │
  ├─► 5) Prepasses (optional)
  │        a) Radiosity pretrace
  │        b) Photon shooting/sorting
  │        c) Media setup
  │
  ├─► 6) Render view (multi-threaded)
  │        a) Partition image into rectangles/tiles
  │        b) For each pixel: primary ray(s)
  │        c) Intersections, shading, secondary rays
  │        d) AA sampling & filtering
  │
  ├─► 7) Post & output
  │        (gamma/display; write PNG/TGA/BMP/PPM; alpha/bit depth)
  │
  └─► End
```

---

## Expanded outline (what each stage does and where to look)

### 1) Read command‑line / INI options
- POV‑Ray merges options from the command‑line and `.ini` files:
input file (`+I`), library paths (`+L`), image size (`+W`, `+H`), display
preview (`+D`), anti‑aliasing (`+A`, `+AM`…), output format (`+F*`), bit
depth, alpha, partial regions, and more. These options drive both parsing and
rendering behavior.

### 2) Load scene sources
- The main scene file is opened, and any `#include` files are resolved using the
current working directory and configured library paths. Parsing options also
honor version switches affecting language compatibility.

### 3) Parse SDL into an internal scene
**Lexing & tokenization**
- **Scanner** reads raw characters (handles encoding, whitespace, comments) and
emits lexemes.
- **Tokenizer** converts lexemes into tokens (identifiers, numbers, strings,
keywords, operators).

**Syntax & semantic parsing**
- The **Parser** consumes tokens and constructs the in‑memory scene:
objects, CSG, transforms, textures/pigments/finishes, lights, cameras, media,
and control structures (`#declare`, `#local`, `#macro`, conditionals, loops). It
manages symbol tables and evaluates expressions; user‑defined functions
are compiled to an internal representation for evaluation.

> Where to look in the tree: `source/parser/*` for scanner/tokenizer/parser;
`reservedwords.*` for language tokens. The
 GitHub repo’s top level and `source-doc` folder offer pointers and build notes.

### 4) Build render‑time structures
- Parsed scene data are organized into runtime structures used by the renderer
(scene graph, object instances, materials). Spatial data structures and bounding
information are prepared to accelerate intersection tests; views and task queues
are initialized for multi‑threaded rendering. (See the rendering engine
overview and scene/view/task classes.)

### 5) Optional prepasses: global illumination & volumetrics
- **Radiosity** pretrace: samples indirect diffuse lighting and populates a
cache before (and during) final rendering. Controlled via `global_settings {
radiosity { … } }` parameters (e.g., `pretrace_start`, `error_bound`, `count`,
save/load data).
- **Photon mapping**: shoots photons from light sources, stores them
(surface/media photon maps), then sorts/builds lookup structures used during
shading for caustics and volumetric effects.
- **Media setup**: configures participating media (scattering/absorption) for
volumetric lighting and fog during the ray march in the render stage. (General
capability references via integration docs and engine overview.)

### 6) Rendering the image (core ray tracing loop)
**Block/rectangle scheduling (multi‑threaded)**
- The renderer splits the image into rectangles (tiles). Worker threads pull
rectangles from a queue, render them, and return results—improving CPU
utilization and cache behavior.

**Per‑pixel workflow**
1. Generate primary camera ray(s) through the pixel.
2. Traverse acceleration/bounding to find the nearest intersection.
3. Shade the hit point:
   - Direct lighting (light sampling, shadows/attenuation).
   - **Radiosity** (indirect diffuse) lookup/update if enabled.
   - **Photon map** estimates for caustics/volumetrics if enabled.
   - Reflections/refractions, fresnel, dispersion, normal/bump mapping,
procedural/textured pigments, media marching, etc.
4. Spawn secondary rays as needed (reflection/refraction/shadow/GI) with
recursion limits.
5. **Anti‑aliasing**: Depending on method, adaptively supersample pixels
when contrast exceeds threshold; recursive subdivision for `+AM2` vs.
non‑recursive `+AM1`. Jittering is optional.

### 7) Post‑processing & file output
- Apply display/gamma handling as configured; update interactive preview if
enabled. Output is then encoded in the requested format (e.g., PNG, TGA,
BMP/SYS, PPM) with chosen bit depth and optional alpha, controlled by
`Output_File_Type`, `Bits_Per_Color`, `Output_Alpha`, and `Output_to_File`.
Partial‑region rendering and resume/abort are also supported through
options.

---

## Quick cross‑reference (docs & source)

- **Official documentation hub** (3.7/3.6): tables of all runtime options &
language features.
- **Parsing options** (input file, includes, versioning):
- **Output file options** (formats, bit depth, alpha):
- **Display/preview & gamma**:
- **Anti‑aliasing** (threshold, methods, jitter):
- **Radiosity** (reference/how‑to):
- **Photon mapping** (implementation overview):
- **Rendering engine internals** (view, tiles, threads, trace pixel):
- **Repo root / status**:

---

[Bald Eagle] Re: General POV-Ray outline / flowchart [156 days 23 hours and 34 minutes ago]

Mon, 3 Nov 2025 21:00:00 GMT

Slightly more detailed

[Bald Eagle] General POV-Ray outline / flowchart [156 days 23 hours and 39 minutes ago]

Mon, 3 Nov 2025 20:55:01 GMT

A key foundational project for making 4.0 a reality is (IMHO) a clear
presentation of how we go from a plain ASCII text file to a final render saved
as some image file.

I'll be trying to incrementally document / explain how that all happens as a way
to explain it to myself.

[Bald Eagle] Re: Spline Editor [160 days 6 hours and 59 minutes ago]

Fri, 31 Oct 2025 13:35:00 GMT

ZIP

[Bald Eagle] Re: Dynamic Identifiers [160 days 7 hours and 4 minutes ago]

Fri, 31 Oct 2025 13:30:00 GMT

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

> Kindly request someone DL zip and repost it here to NG.

[Bald Eagle] Re: Sphere Sweep [161 days and 9 minutes ago]

Thu, 30 Oct 2025 20:25:00 GMT

What I'm also thinking here, is that if we can just map a multi-segment
centripetal Catmull-Rom spline onto whatever other spline that we want to
implement as a sphere_sweep, then we can just use the bounding cylinders that
I'm working on to bound each segment of the sphere_sweep.

I'm not sure what would happen if we try to do that with a spline that has cusps
or self-intersections - I guess it would just render like any other union {} of
objects.

In any event, it's worth a try.

- BE

[Bald Eagle] Re: Sphere Sweep [161 days and 29 minutes ago]

Thu, 30 Oct 2025 20:05:00 GMT

(a) C++ header for integrating into POV‑Ray
Download: cr_sweep_bounds.h
What it provides (header‑only, C++11):

centripetalKnots(P0,P1,P2,P3, alpha, T)
crSegmentToBezier(P0,P1,P2,P3, T, B) and crScalarToBezier(R0,R1,R2,R3, T, BR)
segmentAABB(B,BR) → AABB for one segment, inflated by r_max
sweepAABB(pts,rad,n, alpha=0.5) → global AABB for the entire sweep path

It’s written self‑contained (a tiny Vec3/AABB) so you can quickly test it;
when you wire it into POV‑Ray, swap Vec3 for Vector3d and AABB for the
engine’s bbox type and call it from SphereSweep::Compute_BBox() for
Catmull–Rom
segments. The rest of the object’s BVH building remains unchanged—only the
per‑segment bounding becomes tight and provably safe.

Why this is correct: centripetal Catmull–Rom eliminates common overshoot/cusp
issues in each segment (a source of bad bounds and artifacts with
uniform/chordal parameterizations), and Bézier’s convex‑hull property
guarantees the curve lies inside the hull of its four control points;
axis‑aligned boxing that hull, then Minkowski‑inflating by a safe
r_max, yields a conservative bound for the swept volume.
[forums.dev...nvidia.com], [news.povray.org]

[Bald Eagle] Sphere Sweep [161 days and 44 minutes ago]

Thu, 30 Oct 2025 19:50:00 GMT

"There have been long standing problems with reliably rendering the sphere_sweep
shape in povray.
https://github.com/POV-Ray/povray/blob/master/source/core/shape/spheresweep.h
https://github.com/POV-Ray/povray/blob/master/source/core/shape/spheresweep.cpp
Can you identify what the source of the problem is, and suggest fixes or
alternate, more modern methods for rendering this shape?"

Copilot said:

You're right—sphere_sweep has a long history of being hard to render robustly in
POV‑Ray. Looking at the current sources you linked (spheresweep.h/.cpp)
and the project’s own issue history and newsgroup threads, the recurring
problems fall into a few concrete buckets: bounding errors, numerical robustness
and root‑finding pitfalls, and algorithmic assumptions that break in edge
cases (especially with cubic splines and transformations). Below is a concise
diagnosis and then practical fixes or modern alternatives that work reliably in
production.

What’s going wrong (and where it comes from)
1) Fragile/incorrect automatic bounding
Heuristic bounding that is too tight. The internal bounder grows each modeling
sphere’s radius by a fixed fudge factor (historically “×2”), which
fails badly
when the path spans a large extent while radii are small; rays get culled early
and intersections are missed. This was called out in “Bounding issues related to
±MB and sphere_sweep’s internal bounding” (issue #59). In 3.7,
auto‑bounding was effectively always on, making the bad bounder
unavoidable; in 3.6 you could opt out.
github
User bounding control regression. A follow‑up PR restored 3.6‑style
user control (-MB/Bounding=off) precisely so troublesome sphere_sweeps could
render by disabling the bad auto‑bounder.
github
Transform bugs. With uniform negative scale (e.g., scale -1), the code
multiplied centers and radii by the scale without taking abs() for radii,
producing negative radii and a catastrophically wrong bounding box. The fix is
literally radius *= fabs(scale) in SphereSweep::Scale.
github
Spline extent. Core contributors note the bounder doesn’t account for splines
extending beyond control points, so the computed box can clip the real object;
recommendation: manually bound sphere_sweeps.
github
2) Intersection math that assumes “nice” pairs of hits
The implementation builds each sweep as segments with cubic polynomials for
center and radius and solves ray–segment intersections with a Bezier/Sturm
routine (bezier_01), then assumes intersections come in pairs with normals
pointing “away from the backbone.” The header documents this invariant for
Intersect_Segment/Find_Valid_Points, which is brittle for tangencies, grazing
rays, self‑overlaps, or near‑degenerate data. When the pairing
invariant fails, valid hits get culled or bogus hits pass through.
github
The code pre‑allocates fixed‑size arrays based on SPHSWEEP_MAX_ISECT
= (Num_Spheres + Num_Segments)*2 + 64. In pathological cases (tight curvature +
large scene) you can exceed this estimate and silently drop
intersections—another source of “vanishing” or “halo”
artifacts.
github
3) The infamous cubic_spline artifacts (disks, halos, “infinite” invisible
parts)
Users have reported a “disk” at the sweep center and faint hyperbolic halos
around the origin with cubic_spline; scaling sometimes just moves the artifacts.
The project tracked this for years (FS#81 → GH #147). Reports note
b_spline and linear_spline behave better, and cubic can slow the whole render
dramatically—as if an “invisible” huge object were being tested for
shading.
That aligns with the bad bounding + invalid intersection pairs story above.
povray
+1
Practitioners’ rule of thumb on the newsgroup has long been: avoid cubic
sphere_sweep and approximate with cones + spheres (capsules); it renders faster
and avoids these artifacts.
povray
4) “Tolerance” doesn’t address the root
The tolerance keyword in SDL (and DEPTH_TOLERANCE/ZERO_TOLERANCE constants in
code) controls self‑shadowing and z‑fighting style issues, not the
fundamental intersection/bounding bugs. Tweaking it rarely “fixes” cubic
halos.
povray
+1
The source shows those tolerances are tiny (1e‑6 to 1e‑4),
reasonable for biasing, but irrelevant if the bounder discards the ray or the
root finder mis‑classifies tangencies.
github
What I would change in the code (concrete, scoped fixes)
A) Make bounding safe by default, and controllable
Fix uniform negative scale (already proposed upstream): in SphereSweep::Scale,
multiply radii by fabs(scale) for the uniform case. This resolves the
disappearing/clipped object under scale -1.
github
Allow users to escape the auto‑bounder: keep the 3.6 behavior fully
restored (-MB, Bounding=off) so scenes can render correctly with manual
bounded_by { … }. This is already addressed by PR #288; make sure it’s
consistently respected everywhere intersections call Intersect_BBox.
github
Compute a conservative spline bound:
Sample the center/radius polynomials per segment using curvature‑aware
adaptive subdivision, and expand the box by max(r(t)) plus a small epsilon; or
Provide a user keyword (e.g., bound_inflate <factor>) to inflate
per‑segment bounds when the path extent ≫ radii (the exact heuristic
requested in #59). Either prevents “too tight” culling without hurting
normal
scenes.
github
B) Harden the intersection pipeline
Stop assuming perfect pairings. Update Find_Valid_Points to tolerate odd counts
from near‑tangencies by (a) classifying hits with sign of the surface
function or robust inside/outside tests and (b) merging roots within ε
along the ray. The header itself warns the current function requires paired
hits—relax this.
github
Use robust bracketing for root finding on [0,1] with interval subdivision
(fallback to bisection/Newton only inside brackets). The existing bezier_01(...,
sturm, tolerance, ...) suggests a Sturm‑sequence option; always enable
Sturm for cubic segments, and add a per‑segment subdivision fallback when
the derivative is near zero (grazing).
github
Dynamic intersection storage. Replace the SPHSWEEP_MAX_ISECT fixed buffer with a
std::vector (thread‑local reused scratch if performance demands) and
gracefully grow when predicting too few hits. That prevents silent drops of
valid intersections.
github
Diagnostics. Emit a one‑time warning when (a) the per‑segment root
solver returns more roots than expected, (b) the pairing logic repairs odd
counts, or (c) the bounder is inflating beyond a heuristic threshold. This helps
users recognize problematic sweeps.
If you don’t want to patch core: reliable ways to render sphere sweeps today
1) Approximate with capsules (cones/cylinders + end spheres)
Build a piecewise linear sweep: capped cylinder (or cone) between each pair of
centers, plus a sphere at every joint. This is what seasoned users do; it’s fast
and artifact‑free, and you can control resolution yourself.
povray

2) Use the Object Collection’s “SphereSweep” module (blobs or segments)
CousinRicky’s module wraps multiple stable approaches—blob fields and linear
segment approximations, plus extra spline types (Bézier, natural, quadratic) and
manual bounding helpers. It exists specifically because the native primitive is
“sometimes prone to artifacts and unreliable automatic bounding.”
github
+1

3) Render as an isosurface / SDF
Model the sweep as an implicit surface:

F
(
x
)
=
min
⁡
t
∈
[
0
,
1
]
∥
x
−
C
(
t
)
∥
−
r
(
t
)
=
0
F(x)=
t∈[0,1]
min

 ∥x−C(t)∥−r(t)=0
In POV‑Ray terms, implement an isosurface whose function returns the
minimum capsule distance over a polyline sampled from your spline. This is
robust and easy to bound (container box), just mind max_gradient. For modern
context and performance ideas, see SDF/sphere‑tracing literature.
povray
+2

4) Prefer b_spline or linear_spline over cubic_spline
Multiple reports show cubic is the worst offender (artifacts and performance),
whereas linear and b‑spline modes are much more stable. If you must use
the native primitive, this is the least painful path.
povray
+1

Practical scene‑side mitigations (when you must use the native primitive)
Manual bounding: wrap the sphere_sweep in a conservative bounded_by { box { … }
} and either set Remove_Bounds=off or a small Bounding_Threshold so
POV‑Ray keeps your box. This can both speed up and eliminate the “infinite
invisible part” side effects.
povray
Turn off auto‑bounding for that scene/object (-MB / Bounding=off) when you
see clipping/halos; that’s the official workaround precisely because the
internal bounder is buggy.
github
Avoid uniform negative scale on native sweeps unless you’re on a build with the
fabs() radius fix; otherwise you can get a shrunken/vanished object due to a bad
bounding box.
github
Tolerance: raising tolerance helps self‑shadowing “dark spots” but
won’t
cure cubic halos; use it only for acne.
povray
Prefer POV‑Ray 3.8+ branches where possible: some sphere_sweep artifacts
seen in 3.6/3.7 were fixed in the 3.8 development line according to newsgroup
posts; still, the fundamental caveats above remain.
povray
Pointers in the current code that reflect these issues
Assumptions about intersection pairs and normal orientation are explicit in the
public comments for Intersect_Sphere, Intersect_Segment and Find_Valid_Points.
Violating these assumptions yields invalid “cleanup.”
github
Tolerances and fixed intersection buffers (with SPHSWEEP_MAX_ISECT) are visible
in spheresweep.cpp; both are typical sources of robustness headaches in
ray–implicit intersections under curvature/tangency.
github

[Bald Eagle] NURBS (libraries) [161 days 6 hours and 49 minutes ago]

Thu, 30 Oct 2025 13:45:00 GMT

Unsure if we'd like to use external libraries, or roll our own, so that there
are no future licensing issues...

For a full C++ implementation of NURBS (Non-Uniform Rational B-Splines), there
are several well-maintained libraries you can explore. Here's a breakdown of the
most notable ones, including the files typically involved and example code
snippets:

✅ Recommended Library: TinyNURBS
GitHub: tinynurbs
License: BSD-3-Clause
Features: [github.com]

Header-only C++14 library
Supports rational and non-rational curves/surfaces
Knot insertion, evaluation, derivatives
OBJ I/O support

Key Files:

include/tinynurbs/curve.h – Curve definitions and operations
include/tinynurbs/surface.h – Surface definitions and operations
include/tinynurbs/utilities.h – Utility functions
tests/ – Unit tests and examples
CMakeLists.txt – Build configuration

Dependencies:

https://github.com/g-truc/glm (OpenGL Mathematics library)

Example Usage:
C++#include <tinynurbs/curve.h>#include <glm/glm.hpp>tinynurbs::Curve<float>
crv;crv.control_points = {glm::vec3(-1, 0, 0), glm::vec3(0, 1, 0), glm::vec3(1,
0, 0)};crv.knots = {0, 0, 0, 1, 1, 1};crv.degree = 2;if
(!tinynurbs::curveIsValid(crv)) {    std::cerr << "Invalid curve configuration!"
<< std::endl;}glm::vec3 pt = tinynurbs::curvePoint(crv, 0.5f);Show more lines

🧠 Advanced Option: libnurbs
Docs: libnurbs on DeepWiki
License: Modified BSD
Features: [deepwiki.com]

Full NURBS curve and surface evaluation
Knot insertion/removal
Degree elevation/reduction
Parameter search via BFGS
Serialization and visualization tools

Key Files:

src/curve.cpp, src/surface.cpp – Core implementations
include/libnurbs/curve.h, surface.h – API headers
math/ – Math utilities
tests/ – Unit and visual tests
README.md – Setup and usage guide


🧰 Legacy Option: NURBS++
Website: libnurbs.sourceforge.net
License: LGPL
Includes: [libnurbs.s...eforge.net]

Matrix and numerical libraries
NURBS curve/surface manipulation
Older codebase, but still functional

[kurtz le pirate] Re: Complex Numbers [161 days 10 hours and 29 minutes ago]

Thu, 30 Oct 2025 10:05:27 GMT

On 29/10/2025 20:39, Bald Eagle wrote:
> 
> Just exploring options at this point, and hoping the c++ programmers and
> dev-types (Jerome, WFP, etc) will look some of it over and be inspired, comment,
> and perhaps even try implementing.
> 



If I remember correctly, WFP has already added the complexes in a 
slightly more transparent way in version 4.0.







-- 
kurtz le pirate
compagnie de la banquise

[Bald Eagle] Re: Complex Numbers [162 days and 54 minutes ago]

Wed, 29 Oct 2025 19:40:00 GMT

"ingo" <nomail@nomail> wrote:

> #declare complexnumber = cmp<re, im>;
>
> it's kind of vector hence the vector notation and fits with the colour vectors
> rgb<1,1,1>. All the re and im <x, y> extraction code should be available in
> POV-Ray, it c++ after al ...(can't read it, always get lost)

I have written such SDL-side macros to use that type of formulation, however, I
was looking to see what needed to be changed / added at the source code level,
so it could be natively available, fast, useable in isosurfaces, and assignable
to POV-space cardinal axes.

(see threads with complex macros, and discussions about complex numbers with
clipka)

Just exploring options at this point, and hoping the c++ programmers and
dev-types (Jerome, WFP, etc) will look some of it over and be inspired, comment,
and perhaps even try implementing.

In the absence of anything else I'm just trying to relentlessly keep _pushing
forward_.

- BW

[ingo] Re: Complex Numbers [162 days 1 hour and 4 minutes ago]

Wed, 29 Oct 2025 19:30:00 GMT

"Bald Eagle" <cre### [at] netscapenet> wrote:
> "Given the code base at https://github.com/POV-Ray/povray, what would be
> required to fully implement robust  code to handle complex numbers - complete
> with addition, subtraction, division, multiplication, and exponentiation - using
> both complex and real numbers in any combination?"

#declare complexnumber = cmp<re, im>;

it's kind of vector hence the vector notation and fits with the colour vectors
rgb<1,1,1>. All the re and im <x, y> extraction code should be available in
POV-Ray, it c++ after al ...(can't read it, always get lost)

ingo

[Bald Eagle] Re: Complex Numbers [162 days 1 hour and 39 minutes ago]

Wed, 29 Oct 2025 18:55:00 GMT

Perfect—here’s a **ready-to-try** patch set, plus the tokenizer change for
the
**`i` suffix**, all bundled as a zip you can download.

**Download:**
[complex_povray_patch.zip](blob:https://m365.cloud.microsoft/a301547a-bdae-4511-b0ac-75d3eafa5175)

The zip contains:

- `patches/parser_expressions.patch` — unified diff to add complex-aware parsing
and arithmetic in `parser_expressions.cpp`.
- `patches/tokenizer_i_suffix.patch` — unified diff to:
  - add a new token `IMAGINARY_LITERAL_TOKEN` (e.g., `3i`, `2.5i`),
  - recognize `complex(`, `cis(`, `re`, `im`, `arg` tokens,
  - and (optionally) install the lower-case built-in constant `i` (0+1i).
- `src/base/complex.hpp` — a lightweight internal complex helper (using `DBL`),
referenced by the parser.
- `HOWTO.md` — step-by-step application and test notes.
- `README.md` — summary.

> The patches are written to be **fuzzy‑applicable** against the current
`master` layout. Exact line numbers may 
vary; search for the `// [COMPLEX]` markers if `patch` can’t place a hunk
cleanly. Core file names and locations are ba
sed on the public repo and current parser structure.

---

## 1) What’s in the `parser_expressions.cpp` patch

The patch:

- Adds `#include "base/complex.hpp"` so the parser can construct and operate on
complex values.
- Teaches the **primary expression** parser to recognize:
  - `IMAGINARY_LITERAL_TOKEN` → builds `0 + value·i`,
  - `complex(re, im)` → builds a complex literal,
  - `cis(theta)` → builds `cos θ + i sin θ`.
- Extends **binary operator** reduction to handle `+ - * /` when either side is
complex (promotes floats to complex).
- Extends **unary minus** for complex.
- Overloads **`pow()`** to return complex when any operand is complex; overloads
**`abs()`** to return magnitude for complex; implements **`re()`**, **`im()`**,
**`arg()`** returning floats.

Here’s the exact patch (also inside the zip):

```diff
*** a/source/parser/parser_expressions.cpp
--- b/source/parser/parser_expressions.cpp
***************
*** 1,10 ****
   // ... file prolog omitted for brevity ...
   #include "parser/parser.h"
   #include "parser/parser_expressions.h"
   #include "base/povassert.h"
   #include <cmath>
+  #include "base/complex.hpp" // [COMPLEX] draft include for Complex math

   using namespace pov;

--- 1,11 ----
   // ... file prolog omitted for brevity ...
   #include "parser/parser.h"
   #include "parser/parser_expressions.h"
   #include "base/povassert.h"
   #include <cmath>
+  #include "base/complex.hpp" // [COMPLEX] draft include for Complex math

   using namespace pov;

***************
*** 200,230 ****
-  // Existing atom/primary expression parsing here...
-  // switch (Tok.Type) { FLOAT_LITERAL_TOKEN, IDENT_TOKEN, ... }
+  // [COMPLEX] Recognize imaginary literal tokens (e.g., 3i) and complex/cis
constructors
+  Value Parser::ParsePrimary()
+  {
+      Token Tok = CurrentToken();
+      switch (Tok.Type)
+      {
+          case FLOAT_LITERAL_TOKEN:
+              NextToken();
+              return Value::FromFloat(Tok.Float);
+
+          case IMAGINARY_LITERAL_TOKEN: // new token from tokenizer suffix 'i'
+          {
+              NextToken();
+              pov::Complex z(0.0, Tok.Float);
+              return Value::FromComplex(z);
+          }
+
+          case COMPLEX_KW_TOKEN: // complex(
+          {
+              NextToken(); Expect(LPAREN_TOKEN);
+              DBL re = ParseFloatExpression();
+              Expect(COMMA_TOKEN);
+              DBL im = ParseFloatExpression();
+              Expect(RPAREN_TOKEN);
+              return Value::FromComplex( pov::Complex(re, im) );
+          }
+
+          case CIS_KW_TOKEN: // cis(
+          {
+              NextToken(); Expect(LPAREN_TOKEN);
+              DBL th = ParseFloatExpression();
+              Expect(RPAREN_TOKEN);
+              return Value::FromComplex( pov::cis(th) );
+          }
+
+          default:
+              return ParsePrimary_Existing(); // fall back to existing
implementation
+      }
+  }

***************
*** 420,490 ****
-  // Existing binary operator reduction
+  // [COMPLEX] Extend binary ops for complex + promotion from float
   Value Parser::ReduceBinaryOp(TokenType op, const Value& lhs, const Value&
rhs)
   {
-      // existing float/vector handling ...
+      if (lhs.kind == VALUE_COMPLEX || rhs.kind == VALUE_COMPLEX)
+      {
+          pov::Complex a = (lhs.kind == VALUE_COMPLEX) ? lhs.u.c :
pov::Complex(lhs.u.f, 0);
+          pov::Complex b = (rhs.kind == VALUE_COMPLEX) ? rhs.u.c :
pov::Complex(rhs.u.f, 0);
+
+          switch (op)
+          {
+              case PLUS_TOKEN:  return Value::FromComplex(a + b);
+              case MINUS_TOKEN: return Value::FromComplex(a - b);
+              case MULT_TOKEN:  return Value::FromComplex(a * b);
+              case DIV_TOKEN:   return Value::FromComplex(a / b);
+              default: break; // defer others to existing code
+          }
+      }
+      // existing float/vector handling follows ...
       return ReduceBinaryOp_Existing(op, lhs, rhs);
   }

***************
*** 500,560 ****
-  // Existing unary minus handling
+  // [COMPLEX] unary minus
   Value Parser::ReduceUnaryMinus(const Value& x)
   {
-      // existing code
+      if (x.kind == VALUE_COMPLEX)
+          return Value::FromComplex(-x.u.c);
+      return ReduceUnaryMinus_Existing(x);
   }

***************
*** 700,790 ****
-  // Existing function dispatch such as pow(), abs(), etc.
+  // [COMPLEX] overload pow/abs/re/im/arg
   Value Parser::CallPow(const Value& a, const Value& b)
   {
-      // existing float pow
+      if (a.kind == VALUE_COMPLEX || b.kind == VALUE_COMPLEX)
+      {
+          pov::Complex ac = (a.kind == VALUE_COMPLEX) ? a.u.c :
pov::Complex(a.u.f,0);
+          pov::Complex bc = (b.kind == VALUE_COMPLEX) ? b.u.c :
pov::Complex(b.u.f,0);
+          return Value::FromComplex( pov::cpow(ac, bc) );
+      }
+      return CallPow_Existing(a,b);
   }

   Value Parser::CallAbs(const Value& v)
   {
-      // existing float abs
+      if (v.kind == VALUE_COMPLEX)
+          return Value::FromFloat( pov::abs(v.u.c) );
+      return CallAbs_Existing(v);
   }

   Value Parser::CallRe(const Value& v)
   {
+      if (v.kind == VALUE_COMPLEX) return Value::FromFloat(v.u.c.r);
       SyntaxError("re() expects complex argument");
   }

   Value Parser::CallIm(const Value& v)
   {
+      if (v.kind == VALUE_COMPLEX) return Value::FromFloat(v.u.c.i);
       SyntaxError("im() expects complex argument");
   }

   Value Parser::CallArg(const Value& v)
   {
+      if (v.kind == VALUE_COMPLEX) return Value::FromFloat( pov::arg(v.u.c) );
       SyntaxError("arg() expects complex argument");
   }
```

> The file and function names follow the upstream files in `source/parser/` (see
repo). You’ll adjust any local naming 
differences (e.g., if your implementation names these helper methods differently).

---

## 2) How to implement the **`i` suffix** in the tokenizer

**Goal:** Treat `3i`, `2.5i`, `1e-3i`, etc., as **one token** of a new type
(e.g., `IMAGINARY_LITERAL_TOKEN`) so the parser can construct `0 + value·i`
without guessing or backtracking. This change happens right after scanning a
numeric literal—if the next char is `i` with **no intervening whitespace**, flip
the token type.

You also add convenient keyword tokens for `complex`, `cis`, `re`, `im`, `arg`
and (optionally) install a built‑in lower‑case `i` constant (equal
to `0+1i`) into the symbol table during parser initialization.

The included patch (`patches/tokenizer_i_suffix.patch`) makes all these changes.
Key parts:

```diff
*** a/source/parser/parser.h
--- b/source/parser/parser.h
***************
*** 150,175 ****
    enum TokenType {
        // ... existing tokens ...
        FLOAT_LITERAL_TOKEN = 1000,
+       IMAGINARY_LITERAL_TOKEN,   // [COMPLEX] e.g., 3i, 2.5i
        IDENT_TOKEN,
        // keywords ...
+       COMPLEX_KW_TOKEN,          // complex(
+       CIS_KW_TOKEN,              // cis(
+       RE_KW_TOKEN, IM_KW_TOKEN, ARG_KW_TOKEN,
    };
```

```diff
*** a/source/parser/parser_tokenizer.cpp
--- b/source/parser/parser_tokenizer.cpp
***************
*** 300,380 ****
    // After scanning a numeric literal (FLOAT_LITERAL_TOKEN), check for 'i'
suffix
    // with no intervening whitespace.
    if (token.Type == FLOAT_LITERAL_TOKEN)
    {
        int c = PeekChar();
        if (c == 'i' || c == 'I')
        {
            // verify there's no whitespace between number and 'i'
            if (!SawWhitespaceSinceLastChar())
            {
                GetChar(); // consume 'i'
                token.Type = IMAGINARY_LITERAL_TOKEN;
                // token.Float already holds the numeric part
                return token;
            }
        }
    }

    return token;
```

```diff
*** a/source/parser/reservedwords.cpp
--- b/source/parser/reservedwords.cpp
***************
*** 90,120 ****
    static const ReservedWord s_reserved[] = {
        // ... existing ...
+       { "complex", COMPLEX_KW_TOKEN },
+       { "cis",     CIS_KW_TOKEN },
+       { "re",      RE_KW_TOKEN },
+       { "im",      IM_KW_TOKEN },
+       { "arg",     ARG_KW_TOKEN },
+       { "i",       I_BUILTIN_TOKEN }, // lowercase imaginary unit constant
    };
```

```diff
*** a/source/parser/parser.cpp
--- b/source/parser/parser.cpp
***************
*** 500,560 ****
    void Parser::InstallBuiltins()
    {
        // existing built-ins (pi, version, etc.)
+       // [COMPLEX] install lowercase 'i' as a complex constant
+       Value zi; zi.kind = VALUE_COMPLEX; zi.u.c = pov::I;
+       Symbols->InsertBuiltin("i", zi);
    }
```

> The exact token/enum locations depend on your copy of `parser.h` and the tokenizer
structure. The intent is clear: (1
) add a new token for imaginary literals, (2) promote `complex`/`cis`/`re`/`im`/`arg`
to keyword tokens, (3) register `
i` as a built‑in symbol. See the upstream files for reference.

---

## 3) `complex.hpp` helper (included)

The parser and function dispatch rely on a minimal complex implementation that:

- uses **`DBL`** (POV‑Ray’s float type) consistently,
- provides robust division, principal `log`, `pow`, `sqrt`,
- and the helpers you need: `abs`, `arg`, `cis`, `re`, `im` via direct field
access.

This file sits at `source/base/complex.hpp` (path chosen to match existing base
headers, which are widely included by parser modules).

---

## 4) Apply & test quickly

1. Unzip into your working tree (anywhere).
2. Copy `src/base/complex.hpp` to `source/base/complex.hpp`.
3. Apply patches:

```bash
patch -p1 < patches/tokenizer_i_suffix.patch
patch -p1 < patches/parser_expressions.patch
```

4. Build.
5. Try a tiny SDL:

```pov
#declare Z1 = 2 + 3i;
#declare Z2 = complex(1, -2) + cis(pi/6);
#debug concat("Z1=", str(re(Z1),0,3), "+", str(im(Z1),0,3), "i\n")
```

If you plan to use complex **inside** `function { … }` blocks, you can either
(a) add complex to the Function VM as discussed previously, or (b) temporarily
reduce to floats with `abs/re/im/arg` until the VM is extended. The *parsing*
side is handled by these patches.

---

## Pointers to repo structure (for context)

- Parser & expression code lives under **`source/parser/`** (including
`parser_expressions.cpp`, tokenizer, and reserved words).
- SDL’s float and vector expression rules (which you’re extending) are
documented here; `pow()` is the standard way to exponentiate (no `^` operator),
which is why overloading `pow` is the right entry point.

---

If you want me to also generate a **reserved‑keyword scan test** and a
**couple of tiny SDL scenes** (e.g., “Newton fractal” or a small
`isosurface`
using `abs((x+i*y)^3-1)`), say the word and I’ll add them to the zip so you can
build & render as smoke tests.

[Bald Eagle] Re: Complex Numbers [162 days 1 hour and 44 minutes ago]

Wed, 29 Oct 2025 18:50:00 GMT

"Show a draft of complex.hpp
 and Sketch parser_expressions.cpp changes.  Since this will be implemented at
the source code level, lowercase i is the preferred embodiment, and should be a
reserved keyword.  The capitalized identifier is only a restriction for code
written in sdl to be scanned by the parser, to avoid lowercase reserved
keywords.  I would like both complex (a,b)+i as well as cis(theta) capability,
however the standard a+bi notation would be most preferred if not too difficult
to implement."




Awesome—here’s a *concrete* starting point you can drop into the tree, plus
a
sketch of the parser changes to support complex numbers, including:

- `complex(a,b)` and `cis(theta)` constructors,
- a **lower‑case** reserved keyword **`i`** (imaginary unit),
- and the **`a + b i`** notation via a numeric‑literal **suffix `i`** (so
`3i` becomes a single imaginary literal, not an identifier mash‑up).

I’ve kept the code idiomatic to POV‑Ray’s codebase (using `DBL`,
inline
math, no exceptions). Pointers to the exact files you’ll touch are included; see
notes and citations inline.

---

## 1) `base/complex.hpp` — draft header

Create a small, standalone header you can include from `base/types.h` or
directly from the parser. It avoids `std::complex` to keep numerics and ABI
under your control (but you *can* switch internally later).

```cpp
// File: source/base/complex.hpp
// Lightweight complex number support for POV-Ray parser & function VM.
// Depends only on <cmath> and POV-Ray's DBL typedef.

#ifndef POV_BASE_COMPLEX_HPP
#define POV_BASE_COMPLEX_HPP

#include <cmath>
#include "base/types.h" // for DBL

namespace pov {

struct Complex
{
    DBL r; // real
    DBL i; // imag

    // --- ctors ---
    constexpr Complex() : r(DBL(0)), i(DBL(0)) {}
    constexpr explicit Complex(DBL real) : r(real), i(DBL(0)) {}
    constexpr Complex(DBL real, DBL imag) : r(real), i(imag) {}

    // --- unary ---
    constexpr Complex operator+() const { return *this; }
    constexpr Complex operator-() const { return Complex(-r, -i); }

    // --- basic ops (component formulas) ---
    friend inline Complex operator+(const Complex& a, const Complex& b) { return
Complex(a.r + b.r, a.i + b.i); }
    friend inline Complex operator-(const Complex& a, const Complex& b) { return
Complex(a.r - b.r, a.i - b.i); }
    friend inline Complex operator*(const Complex& a, const Complex& b)
    {
        return Complex(a.r*b.r - a.i*b.i, a.r*b.i + a.i*b.r);
    }
    friend inline Complex operator/(const Complex& a, const Complex& b)
    {
        // Smith's algorithm for numerical stability
        DBL ar = std::fabs(b.r), ai = std::fabs(b.i);
        if (ar >= ai) {
            DBL t = b.i / b.r;
            DBL d = b.r + b.i * t;
            return Complex((a.r + a.i * t) / d, (a.i - a.r * t) / d);
        } else {
            DBL t = b.r / b.i;
            DBL d = b.r * t + b.i;
            return Complex((a.r * t + a.i) / d, (a.i * t - a.r) / d);
        }
    }

    // compound
    Complex& operator+=(const Complex& o){ r+=o.r; i+=o.i; return *this; }
    Complex& operator-=(const Complex& o){ r-=o.r; i-=o.i; return *this; }
    Complex& operator*=(const Complex& o){ DBL nr=r*o.r - i*o.i; i = r*o.i +
i*o.r; r = nr; return *this; }
    Complex& operator/=(const Complex& o){ *this = *this / o; return *this; }
};

// real–complex mixed ops
inline Complex operator+(const Complex& z, DBL x){ return Complex(z.r + x, z.i);
}
inline Complex operator-(const Complex& z, DBL x){ return Complex(z.r - x, z.i);
}
inline Complex operator*(const Complex& z, DBL x){ return Complex(z.r * x, z.i *
x); }
inline Complex operator/(const Complex& z, DBL x){ return Complex(z.r / x, z.i /
x); }

inline Complex operator+(DBL x, const Complex& z){ return Complex(x + z.r, z.i);
}
inline Complex operator-(DBL x, const Complex& z){ return Complex(x - z.r,
-z.i); }
inline Complex operator*(DBL x, const Complex& z){ return Complex(x * z.r, x *
z.i); }
inline Complex operator/(DBL x, const Complex& z){ return Complex(x, DBL(0)) /
z; }

// comparisons: only == / != are defined (lexical epsilon-like)
inline bool operator==(const Complex& a, const Complex& b)
{
    // Use POV-Ray float equal semantics elsewhere; here a simple exact compare.
    return (a.r == b.r) && (a.i == b.i);
}
inline bool operator!=(const Complex& a, const Complex& b){ return !(a==b); }

// --- elementary functions ---

inline Complex conj(const Complex& z){ return Complex(z.r, -z.i); }
inline DBL     abs (const Complex& z){ return std::hypot(z.r, z.i); } //
magnitude
inline DBL     arg (const Complex& z){ return std::atan2(z.i, z.r); }

// exp(x+iy) = exp(x) (cos y + i sin y)
inline Complex cexp(const Complex& z)
{
    DBL ex = std::exp(z.r);
    DBL cy = std::cos(z.i), sy = std::sin(z.i);
    return Complex(ex * cy, ex * sy);
}

// log z = ln|z| + i arg(z)  (principal branch)
inline Complex clog(const Complex& z)
{
    return Complex(std::log(abs(z)), arg(z));
}

// pow(z,w) = exp(w * log z)  (principal value)
inline Complex cpow(const Complex& z, const Complex& w)
{
    return cexp( Complex(w.r * clog(z).r - w.i * clog(z).i,
                         w.r * clog(z).i + w.i * clog(z).r) );
}

inline Complex csqrt(const Complex& z)
{
    // principal square root
    DBL m = abs(z);
    DBL s = std::sqrt( (m + std::fabs(z.r)) / DBL(2) );
    DBL d = (s == 0) ? 0 : (z.i / (2*s));
    return (z.r >= 0) ? Complex(s, d) : Complex(d, (z.i >= 0 ? s : -s));
}

// trig via Euler
inline Complex csin(const Complex& z)
{
    // sin(x+iy) = sin x cosh y + i cos x sinh y
    return Complex( std::sin(z.r) * std::cosh(z.i),
                    std::cos(z.r) * std::sinh(z.i) );
}

inline Complex ccos(const Complex& z)
{
    // cos(x+iy) = cos x cosh y - i sin x sinh y
    return Complex( std::cos(z.r) * std::cosh(z.i),
                   -std::sin(z.r) * std::sinh(z.i) );
}

inline Complex ctan(const Complex& z)
{
    return csin(z) / ccos(z);
}

// hyperbolic
inline Complex csinh(const Complex& z){ return (cexp(z) -
cexp(Complex(-z.r,-z.i))) * DBL(0.5); }
inline Complex ccosh(const Complex& z){ return (cexp(z) +
cexp(Complex(-z.r,-z.i))) * DBL(0.5); }
inline Complex ctanh(const Complex& z){ return csinh(z) / ccosh(z); }

// helper constructors
inline Complex cis(DBL theta) { return Complex(std::cos(theta),
std::sin(theta)); }      // e^{i θ}
inline Complex make_complex(DBL re, DBL im){ return Complex(re, im); }

static const Complex I(0.0, 1.0); // imaginary unit; lower-case 'i' will be
reserved in the parser

} // namespace pov

#endif // POV_BASE_COMPLEX_HPP
```

**Why this way?**
- Uses `DBL` consistently with parser math.
- Implements numerically stable division and a principal‑value `pow/log`,
matching how float `pow/log` are documented to behave for scalars today.

---

## 2) `parser_expressions.cpp` — sketch of changes

Below is a *surgical* diff‑style sketch showing where to add complex
support. It assumes:

- you add a new **value kind** `VALUE_COMPLEX`,
- a **token** for `IMAGINARY_LITERAL` (produced by the tokenizer when it sees
`123i`), and
- a **built‑in identifier** `i` bound to `pov::I`.

The existing parser has centralized expression handling with helper methods that
reduce binary operators, casting, etc. You’ll expand those switch statements.

### 2.1 Extend value representation

In (or near) `parsertypes.*`, add a complex arm to the variant; then include the
header.

```cpp
// parsertypes.h (illustrative)
enum ValueKind { VALUE_FLOAT, VALUE_VECTOR, VALUE_COLOR, VALUE_STRING, /*...*/,
VALUE_COMPLEX };

struct Value
{
    ValueKind kind;
    union {
        DBL    f;
        Vector v;   // existing
        // ...
        pov::Complex c;
    } u;
    // helpers...
    static Value FromComplex(const pov::Complex& z) {
        Value v; v.kind = VALUE_COMPLEX; v.u.c = z; return v;
    }
};
```

> You’ll also want `AsFloat()`, `AsComplex()`, etc., mirroring the float/vector
accessors you already have.

### 2.2 Recognize complex literals and the `i` keyword

In the tokenizer you’ll create `IMAGINARY_LITERAL` and a reserved word `i`.
Parser‑side:

```cpp
// parser_expressions.cpp : inside primary/atom expression parsing
switch (token.Type)
{
    case FLOAT_LITERAL_TOKEN:
        return Value::FromFloat(token.float_value);

    case IMAGINARY_LITERAL_TOKEN: // e.g. "3.5i" produced by tokenizer
        return Value::FromComplex(pov::Complex(0.0, token.float_value));

    case IDENT_TOKEN:
        if (token.is_builtin_i) { // lowercase 'i'
            return Value::FromComplex(pov::I);
        }
        // ... existing identifier handling ...
        break;

    case COMPLEX_KW_TOKEN: // "complex(" ... ")" treated as literal ctor
        // parse '(' expr ',' expr ')', both must be float-like
        {
            DBL re = ParseFloatExpression();
            Expect(COMMA_TOKEN);
            DBL im = ParseFloatExpression();
            Expect(RPAREN_TOKEN);
            return Value::FromComplex(pov::Complex(re, im));
        }

    case CIS_KW_TOKEN: // "cis("
        {
            DBL theta = ParseFloatExpression();
            Expect(RPAREN_TOKEN);
            return Value::FromComplex(pov::cis(theta));
        }
    // ...
}
```

*(Token names are illustrative; wire them to your actual enums. The important
part is: the parser sees both constructors as **literal** expressions, not as
general function calls.)*

### 2.3 Promotion helpers

Add small helpers to unify arithmetic:

```cpp
inline Value PromoteToComplex(const Value& v)
{
    if (v.kind == VALUE_COMPLEX) return v;
    if (v.kind == VALUE_FLOAT)  return Value::FromComplex( pov::Complex(v.u.f,
0.0) );
    // vectors/colors/strings are not implicitly promotable; throw parse error.
    SyntaxError("Complex arithmetic requires float or complex operands.");
    return v; // unreachable
}
```

### 2.4 Binary operators `+ - * /`

Extend the binary‑op reducer:

```cpp
Value Parser::ReduceBinaryOp(TokenType op, const Value& lhs, const Value& rhs)
{
    // Complex cases first (covers mixed real/complex via promotion)
    if (lhs.kind == VALUE_COMPLEX || rhs.kind == VALUE_COMPLEX)
    {
        pov::Complex a = (lhs.kind == VALUE_COMPLEX) ? lhs.u.c :
pov::Complex(lhs.u.f, 0.0);
        pov::Complex b = (rhs.kind == VALUE_COMPLEX) ? rhs.u.c :
pov::Complex(rhs.u.f, 0.0);

        switch (op) {
            case PLUS_TOKEN:  return Value::FromComplex(a + b);
            case MINUS_TOKEN: return Value::FromComplex(a - b);
            case MULT_TOKEN:  return Value::FromComplex(a * b);
            case DIV_TOKEN:   return Value::FromComplex(a / b);
            default: break; // fall through
        }
    }

    // ... existing float/vector operator logic ...
}
```

### 2.5 Unary minus

```cpp
Value Parser::ReduceUnaryMinus(const Value& x)
{
    if (x.kind == VALUE_COMPLEX) return Value::FromComplex( -x.u.c );
    if (x.kind == VALUE_FLOAT)  return Value::FromFloat( -x.u.f );
    // vectors/colors: existing behavior
    // ...
}
```

### 2.6 Function call dispatch (`pow`, `abs`, `re`, `im`, `arg`, `cis`, etc.)

Where scalar functions are resolved (typically in `parser_functions*.cpp`), add
the complex variants:

```cpp
// abs(z) : float magnitude when argument is complex; preserve float abs for
float
Value Parser::CallAbs(const Value& v)
{
    if (v.kind == VALUE_COMPLEX) return Value::FromFloat( pov::abs(v.u.c) );
    // existing float abs
}

// re(z) / im(z) / arg(z)
Value Parser::CallRe(const Value& v)
{
    if (v.kind == VALUE_COMPLEX) return Value::FromFloat( v.u.c.r );
    SyntaxError("re() expects a complex argument.");
}
Value Parser::CallIm(const Value& v)
{
    if (v.kind == VALUE_COMPLEX) return Value::FromFloat( v.u.c.i );
    SyntaxError("im() expects a complex argument.");
}
Value Parser::CallArg(const Value& v)
{
    if (v.kind == VALUE_COMPLEX) return Value::FromFloat( pov::arg(v.u.c) );
    SyntaxError("arg() expects a complex argument.");
}

// pow(a,b)
Value Parser::CallPow(const Value& a, const Value& b)
{
    if (a.kind == VALUE_COMPLEX || b.kind == VALUE_COMPLEX)
    {
        pov::Complex ac = (a.kind == VALUE_COMPLEX) ? a.u.c :
pov::Complex(a.u.f,0);
        pov::Complex bc = (b.kind == VALUE_COMPLEX) ? b.u.c :
pov::Complex(b.u.f,0);
        return Value::FromComplex( pov::cpow(ac, bc) );
    }
    // existing float pow
}
```

> The function catalog already enumerates float functions that are legal in
expressions and in `function{}` blocks; you
’ll extend the dispatcher tables to include `re, im, arg, complex, cis` and to
*overload* `abs/pow` for complex argumen
ts.

---

## 3) Tokenizer / reserved word notes (for `a + b i` and lowercase `i`)

While you asked for parser changes, **the `3i` case must be handled by the
tokenizer**; otherwise `3i` is a single (invalid) identifier token. Add:

- **A numeric‑literal suffix `i`** to produce `IMAGINARY_LITERAL_TOKEN`
with payload `float_value = 3.0` → parser converts to `0 + 3i`.
- **A reserved built‑in identifier `i`** mapped to the value `pov::I`
(0+1i) in the symbol table. This lives in `reservedwords.*` and
symbol‑table bootstrap.

Sketch in `parser_tokenizer.cpp` (where numeric literals are finalized):

```cpp
// After scanning a FLOAT_LITERAL: check for immediate 'i' suffix without
whitespace.
if (CurrentChar() == 'i' || CurrentChar() == 'I') {
    Advance(); // consume 'i'
    token.Type = IMAGINARY_LITERAL_TOKEN;
    token.float_value = scanned_number; // imag part only
    return token;
}
```

Add `i` to reserved words:

```cpp
// reservedwords.cpp
{ "i", I_BUILTIN_TOKEN }, // lowercase preferred embodiment (user request)
{ "complex", COMPLEX_KW_TOKEN },
{ "cis",     CIS_KW_TOKEN },
{ "re", RE_KW_TOKEN }, { "im", IM_KW_TOKEN }, { "arg", ARG_KW_TOKEN },
```

…and bind `I_BUILTIN_TOKEN` to a symbol initialized to
`Value::FromComplex(pov::I)` during parser init. (Compare how `pi`, `version`,
and other built‑ins are installed.)

---

## 4) SDL surface: how it looks after these changes

```pov
#declare Z1 = 2 + 3i;                 // suffix 'i' → imaginary literal
(parser builds 0+3i)
#declare Z2 = complex(1, -2) + cis(pi/6);
#declare R  = abs(Z1);                // float magnitude
#declare TH = arg(Z1);                // float angle

// Works in general expressions:
#debug concat("Z1=", str(re(Z1),0,3), "+", str(im(Z1),0,3), "i\n")

// Works inside function{} (if you also add VM support or wrappers; see earlier
plan)
isosurface {
  function { abs( (x + i*y) * (x - i*y) ) - 1 }
  contained_by { box { <-2,-2,-2>, <2,2,2> } }
  max_gradient 5
}
```

> Re: `function { … }` — the current function VM is float‑typed only;
to permit complex *inside* `function{}`, ei
ther (A) add complex to the VM (best), or (B) expose float‑returning wrappers
(e.g., `re(c_sin(x,y))`) until you 
wire complex through. See the earlier plan I sent for both paths.

---

## 5) Why this fits the codebase

- **Files to modify**: `source/parser/parser_expressions.cpp`,
`parser_functions*.cpp`, `parser_tokenizer.cpp`, `reservedwords.*`,
`parsertypes.*`, and `base/types.h` include path to `base/complex.hpp`. These
are the same modules that own expression parsing today.
- **Grammar alignment**: SDL’s float expression grammar already routes `pow`,
`abs`, etc., through function dispatch tables; you’re “just” adding
type‑overloads and two new literal forms (`complex()`/`cis()` and the `i`
suffix).

---

## 6) Next steps (I can help draft these too)

1. **Token/enum plumbing**: add `IMAGINARY_LITERAL_TOKEN`, `COMPLEX_KW_TOKEN`,
`CIS_KW_TOKEN`, and function tokens for `re/im/arg`. Wire into
`reservedwords.*`.
2. **Symbol bootstrap**: insert built‑in `i` into the global table at
parser init.
3. **Function VM**: choose Strategy A (native complex in VM) vs Strategy B
(float wrappers); A is the “full” path.
4. **Tests**: parser tests for `3i`, `2+3i`, `complex(…)`, `cis(…)`;
arithmetic
identities; `pow` branch‑cut sanity.
5. **Docs**: update “Float Expressions / Vector Expressions / User‑Defined
Functions” with the complex type & mixing rules.

---

If you want, I’ll produce a small patch that compiles: the new token IDs,
`reservedwords` lines, tokenizer suffix detection, plus a
minimally‑invasive `parser_expressions.cpp` change set (guarded by a
`#define POV_ENABLE_COMPLEX` flag) so you can try `2+3i`, `complex()`, and
`cis()` in the SDL right away.

**References**
- Source files you’ll be editing: `parser_expressions.cpp`, `parser.h/.cpp`,
`parser_tokenizer.cpp`, `reservedwords.*`, `parsertypes.*` (POV‑Ray
GitHub).
- Expression grammar & function catalog (float/vector) to be extended for
complex: POV‑Ray docs & wiki.
- Function include pattern (`functions.inc`) as a precedent for adding wrappers
if you stage VM work.

[Bald Eagle] Complex Numbers [162 days 1 hour and 54 minutes ago]

Wed, 29 Oct 2025 18:40:00 GMT

"Given the code base at https://github.com/POV-Ray/povray, what would be
required to fully implement robust  code to handle complex numbers - complete
with addition, subtraction, division, multiplication, and exponentiation - using
both complex and real numbers in any combination?"

Copilot said:


Reasoned for 72s

Great question, William. Short version: POV‑Ray doesn’t presently have a
native “complex” scalar type; expressions are typed as float, vector, color,
string, etc., and user‑defined functions (the ones you can put into
isosurface, pigments, etc.) are limited to float math with a fixed set of float
functions like pow, sin, exp (no complex overloading). To “fully implement
robust complex numbers” in the official code base you would need to introduce a
new value type end‑to‑end: tokenizer → parser/AST →
expression evaluator → function VM, plus SDL syntax, promotion rules,
built‑ins, tests, and docs. Below is a concrete implementation plan tied
to the current repo layout.
povray
+2

0) Where complex would fit into the current architecture
Repo & parser locations. The core language is implemented in source/parser/*
(tokenizer, reserved words, expression parsing and evaluation). You’ll be
touching parser_tokenizer.cpp, reservedwords.*, parser_expressions.cpp,
parser_functions*.cpp, parsertypes.*, and headers like base/types.h referenced
across parser modules.
github
+3
Current numeric universe. SDL knows about floats and vectors (2–5 components
using <…>), and many float functions (pow, sin, cos, exp, log, etc.).
There’s no
“complex” primitive or literal; vectors are not complex, and function syntax
is
float-only (even when used by isosurface).
povray
+2
Function engine. The “function VM” that powers isosurface, patterns, etc.,
accepts float functions and a separate path for vector/color functions; there’s
no complex category today. Extending it is part of “full” support.
povray
Workarounds used today. Scene authors who need complex math typically emulate it
with macros/includes (e.g., the community “complex functions” include),
which
proves demand but also highlights the lack of core support.
github
+1
1) Language & type design decisions (SDL)
1.1 Choose a literal & constructor syntax (avoid ambiguity with vectors)
Vectors use <x,y,z> and are heavily overloaded throughout SDL. To keep vectors
distinct, prefer one of these explicit constructors for complex literals:

complex(a, b) → parsed as a complex literal (not a function call).
Optional: cis(theta) as a literal constructor on the unit circle (i.e., cos
θ + i sin θ).
Do not reuse <a,b> (2‑component vector) for complex—vector expressions
already allow mixing with floats, and reinterpreting them would break semantics.
(The docs show 2–5 component vectors, and many places depend on that.)
povray

1.2 Imaginary unit
Add a built‑in constant I (uppercase to avoid accidental collisions with
user loop variables and to match your preference for non‑lowercase
identifiers) representing 0 + 1i. This is just a constant symbol in the symbol
table (like pi is a float built‑in), backed by the new complex type. The
reserved words table lives in reservedwords.*.
github

Using I enables familiar forms like Z = 3 + 2*I; while keeping scanning simple
(no implicit “2i” glue tokens).

1.3 Operators & promotion rules
Add full arithmetic overloading for + - * / with these rules:

Promotion: real ⊕ complex → promote real to complex with zero
imaginary part; result is complex.
Unary minus: preserves type.
Equality/ordering: Keep only = and != (compare both parts with float epsilon
rules); no <, <=, >, >= for complex.
Truthiness: z is “true” iff abs(z) != 0 (consistent with floats’
non‑zero
truthiness). The parser already handles boolean using float zero/non‑zero;
document the complex rule.
hws
1.4 Exponentiation
SDL does not have an ^/** operator; exponentiation uses pow(base, exponent).
Implement pow(Complex, Complex) with principal value; add overloads for
(Complex, Real), (Real, Complex). If you later want **, you must change the
grammar in parser_expressions.cpp to introduce a precedence tier (riskier; not
required for “full” capability because pow already exists).
hws

1.5 Complex built‑ins (names that won’t clash with float versions)

Complex → complex: c_conj(z), c_exp(z), c_log(z), c_sqrt(z),
c_sin/c_cos/c_tan/c_asin/c_acos/c_atan, c_sinh/c_cosh/c_tanh, c_pow(z, w)
(aliases to pow).
Complex → float: re(z), im(z), abs(z) (magnitude), arg(z) (principal
argument).
Constructors: complex(a, b), cis(theta).
Float functions exist today with these names (exp, log, sin, …). Using a c_
prefix avoids overload ambiguity in the function VM (see §3) while still letting
the parser resolve in expression context.
ijs

2) Core implementation (parser & evaluator)
2.1 New type in core headers

Add a struct Complex { DBL r, i; } (or reuse std::complex<DBL> internally and
expose a POD wrapper) in base/types.h. DBL is the engine’s float type and is
included by parser modules. Implement basic ops and utility functions.
github
2.2 Tokenizer & reserved words

parser_tokenizer.cpp / reservedwords.*:
Reserve complex, I, re, im, abs, arg, and the c_* family as
keywords/built‑ins.
Recognize complex( as starting a complex-literal token (to differentiate from a
generic function call).
github
2.3 Parser types & value representation

Extend the value/tagged‑union used by the parser and evaluator
(parsertypes.*) to carry a Complex variant alongside Float, Vector, Color,
String, etc.
Anywhere the parser currently sets or checks “numeric kind,” expand logic to
three kinds: Float, Vector, Complex (a fourth if you count Color). Keep
vectors/colors as‑is.
github
2.4 Expression evaluation

In parser_expressions.cpp implement binary/unary operator cases for complex
(including mixed real/complex with promotion).
Implement built‑ins (re, im, abs, arg, cis) and the c_ family in
parser_functions*.cpp.
Map pow dispatch based on operand types to complex exponentiation when any
operand is complex. Today pow(float,float) is wired via the float function
table; add a complex path.
github
+1
2.5 Printing & formatting

Extend str() or provide cstr(z) so #debug can print complex values intelligibly
(e.g., "(a,b)" or "a+bi"). The existing diagnostics assume float for many paths;
audit the %g style prints where needed.
github
3) Function VM (“user‑defined functions”) and isosurface
The function system accepts float functions; it exposes a grammar and function
set limited to floats (there’s also a vector function path for
transformations/splines). For full complex support inside function { … } you
need one of these strategies:
povray
+1

Strategy A — Add complex as a new function value kind (most complete)
Extend the function VM with a new COMPLEX function category (think analog of
VECTFUNCT_ID_TOKEN) and corresponding bytecode nodes supporting complex
temporaries and ops. Update the function grammar to allow complex expressions
(identifiers and temporaries of complex type). Update the compiler in fncode.cpp
accordingly.
Provide bridges so a complex function can be reduced to float via re(), im(),
abs(), arg() when the host expects float (e.g., isosurface threshold function).
This lets authors write expressions like:



Plain Text
pov isn’t fully supported. Syntax highlighting is based on Plain Text.

isosurface {
  function { abs( c_sin( x + I*y ) ) - 1 }  // ok: returns float
  contained_by { box { <-2,-2,-2>, <+2,+2,+2> } }
}
(Today function { … } only validates float functions; this expands that universe
cleanly.)
povray
Strategy B — Keep function VM float‑only; add float-returning wrappers
(faster to ship)
If you want to avoid VM changes initially, add float‑returning helpers
that take float pairs (re, im) and return a float:

c_abs_xy(x, y), c_arg_xy(x, y), and “result component” variants like
c_sin_re(x,y), c_sin_im(x,y), etc.
Then users can build complex flows in SDL at parse time, but inside function{}
they pass pairs and pull the part they need. It’s workable but not as ergonomic.
The official functions.inc already exposes many internal helpers via
internal(ID); you’d extend that catalog.
povray
+1
If the goal is “fully implement robust code,” I recommend Strategy A so
complex
works everywhere the float math works today.

4) Math semantics & numerics
DBL precision: Use DBL everywhere for real/imag parts. (DBL is the
project‑wide floating type used in parser/math.)
github
pow and branch cuts: Define principal values (log z principal branch; pow(a,b) =
exp(b*log a)). Document behavior near branch cuts and zero denominators
(returning NaNs consistent with DBL and propagating through). The float function
list already includes exp, log, pow; your complex versions should mirror those
names via the c_* family to avoid changing float semantics.
ijs
Performance: Consider inlining and possibly using std::complex<DBL> internally
for correctness (argument reduction, trig identities) while presenting a simple
POD at interfaces.
5) SDL integration details
Declarations: #declare Z = complex(1,2); should assign a complex value; extend
#declare/#local rvalue typing accordingly (this directive currently accepts
float, vector, color, string, object, …; you’ll add complex). Update
language
docs and allow a trailing semicolon like floats/vectors.
povray
Mixing types: Expressions like Z + 3, 3/Z, pow(Z, 2) must “just work” via
promotion.
Built‑ins already in use by vectors. SDL provides x, y, z, t, u, v as
vector built‑ins/dot items; do not repurpose them for complex components.
Use re()/im() accessors instead.
povray
No new operator needed. Keep exponentiation via pow(…); adding ^ requires
grammar and precedence changes in parser_expressions.cpp that ripple across the
evaluator.
github
+1
6) Parser & symbol table updates
Symbol kinds. Add a COMPLEX_ID_TOKEN (analogous to FLOAT_ID_TOKEN,
VECTFUNCT_ID_TOKEN, …) and wire it through the symbol table stack and lookups.
The DeepWiki summary of symbol handling gives a good overview of where these
live.
deepwiki
Reserved words. Add new keywords into reservedwords.* and ensure the tokenizer
maps them to the right token IDs.
github
7) Standard library & examples
Include files. Provide complex.inc with macro helpers and sugar (e.g., polar
form constructor, safe printing, clipping helpers).
Samples. Ship scenes demonstrating: arithmetic, mixed real/complex math, complex
powers, Newton fractals (via isosurface using abs(f(z))), and domain coloring.
(The community POV‑Ray‑complex‑functions repo is a great
source of sample ideas; it currently implements such features at the SDL macro
level.)
github
8) Backwards compatibility & doc updates
No behavior change for existing scenes. All new syntax (complex(…), I, c_*) is
additive.
Docs. Update:
Float/Vector Expressions chapters to mention complex and mixing rules.
User‑Defined Functions to either: (A) describe complex functions as a new
category; or (B) document the *_xy wrappers if you go with Strategy B. Current
docs list exactly which float functions are allowed; you’ll extend that list.
povray
+1
9) Testing
Unit tests for arithmetic identities (z + 0 = z, z*conj(z) = abs(z)^2, edge
cases around zeros/NaNs).
Parser tests for literals, promotions, and error messages.
Render tests (scenes) that verify isosurface behavior using
complex‑powered formulas (e.g., abs( c_pow(x+I*y, 3) - 1 ) surfaces).
10) File‑by‑file checklist (minimum viable “robust”)
base/types.h — add Complex and utilities.
github
source/parser/reservedwords.* — register complex, I, re, im, abs, arg, cis, c_*.
github
source/parser/parsertypes.* — add Complex to the variant/type tags.
github
source/parser/parser_tokenizer.cpp — treat complex( as literal; make I a
built‑in.
github
source/parser/parser_expressions.cpp — implement complex operators, promotions,
comparisons, truthiness.
github
source/parser/parser_functions*.cpp — register built‑ins (re, im, abs,
arg, cis, c_*) and dispatch pow to complex when needed.
github
source/parser/fncode.cpp (and related function VM) —
Strategy A: add complex bytecodes, temps, function kind, and grammar hooks.
Strategy B: add float wrappers c_*_xy.
deepwiki
distribution/include/complex.inc — ship helper macros; update functions.inc if
Strategy B is used. (The shipped functions.inc sets a precedent for exposing
complex helpers if you choose wrappers.)
github
Docs — update the sections “Float Expressions,” “Vector
Expressions,”
“User‑Defined Functions,” and the ToC for the new type.
hws
+3
11) Example (proposed SDL surface syntax)
(Using uppercase identifiers and no lowercase to match your style.)




Plain Text
pov isn’t fully supported. Syntax highlighting is based on Plain Text.

#declare Z1 = complex(2, 3);        // 2 + 3i
#declare Z2 = 5;                    // real
#declare Z3 = Z1 + Z2;              // (7 + 3i)
#declare Z4 = pow(Z1, complex(0.5, 0)); // sqrt as pow

#debug concat("Re(Z3)=", str(re(Z3),0,3),
              " Im(Z3)=", str(im(Z3),0,3), "\n")

isosurface{
  function { abs( c_exp( x + I*y ) - 1 ) - 0.5 }  // Strategy A
  contained_by { box { <-3,-3,-3>, <3,3,3> } }
  max_gradient 5
}
(If you ship Strategy B first, the function line becomes, e.g., c_abs_xy(
c_exp_re(x,y) - 1, c_exp_im(x,y) ) - 0.5.)
povray

12) Scope, risks, and a pragmatic path
Smallest coherent core: Items 1–6 and Strategy B for the function VM (no VM
surgery) deliver usable complex math across SDL expressions and in function{}
via _xy helpers.
Full robustness: Add Strategy A (complex value kind in VM) so complex
expressions can exist natively in function{} and be reduced to float with
abs/re/im/arg as needed.
Why not reuse vectors? Because vectors already have distinct semantics and
syntax (<…>, dot items x/y/z). Docs explicitly define their behavior and
operator overloading, and conflating them with complex would introduce ambiguity
(e.g., is <a,b> a UV, a color slice, or a complex?).
povray
Compatibility: All additions are opt‑in; no change to existing scenes or
shipped function sets (pow, sin, etc. keep float semantics).
ijs
13) References you’ll want handy
Repo & parser files: top‑level overview and source/parser/* modules.
github
+1
Expression grammar (float/vector) and function limitations: formal docs.
hws
+2
Function include catalog (functions.inc): pattern/internal function interface
(good model for adding complex helpers if you stage Strategy B).
github
+1
Community complex include for inspiration on naming and examples.
github
If you’d like, I can draft the exact token/type additions (new enum values, AST
node tweaks) and a minimal complex.hpp with numerically stable c_log/c_pow you
can drop into base/, then sketch the parser_expressions.cpp switch additions.
Also—do you prefer the complex(a,b) + I syntax only, or do you also want a polar
literal like cis(theta)?

[Bald Eagle] Re: Dynamic Identifiers [162 days 7 hours and 34 minutes ago]

Wed, 29 Oct 2025 13:00:01 GMT

Packaged as a zip in github fork format, hopefully for nearly immediate
implementation.

https://limewire.com/?referrer=pq7i8xx7p2

File hosting expires 7 days from now.
Kindly request someone DL zip and repost it here to NG.

- BE

[Bald Eagle] Spline Editor [163 days 2 hours and 19 minutes ago]

Tue, 28 Oct 2025 18:15:00 GMT

What would be required to add a cross-platform dynamic spline modeler to povray
that would allow the addition, deletion, and editing of control points with a
mouse to povray?
Copilot said:


Reasoned for 28s


Outlining development paths
Short answer: you don’t add mouse‑driven spline editing inside
POV‑Ray’s parser—POV‑Ray is a batch ray tracer with no
built‑in interactive modeling API. You either (A) build a companion,
cross‑platform spline modeler that writes POV‑Ray SDL (and
optionally auto‑re‑renders via the CLI), or (B) contribute to an
existing DCC host (e.g., the Blender ↔ POV‑Ray exporter) to get a
first‑class interactive experience and keep POV‑Ray as the renderer.
Below is a concrete, technical blueprint with specific POV‑Ray features
you’ll target, and the OS/tooling you’ll need.

What POV‑Ray already supports (and what it doesn’t)
Spline‑based geometry you will feed from an editor:
Prism: 2‑D curve in the x–z plane swept along y; supports linear_spline,
quadratic_spline, cubic_spline, bezier_spline, plus linear_sweep|conic_sweep.
povray
+2
Lathe: 2‑D curve rotated about the y‑axis; supports the same spline
modes.
povray
+1
Sphere_sweep: tubular geometry defined by centers + radii along
linear|b_spline|cubic_spline.
povray
+1
“Spline identifiers” (animation paths, etc.) with
linear|quadratic|cubic|natural_spline.
povray
SDL file I/O exists (read/write ASCII during parse, not “live UI”), e.g.,
#fopen/#read/#write. That’s useful for exporting/including data but not for
mouse interactivity inside POV‑Ray.
povray
+1
Execution model: POV‑Ray renders from files; the Windows build has some
special CLI flags (e.g., /RENDER, /EXIT) for automation; Unix builds are
console‑driven and can preview via SDL/text. There’s no general plugin API
for an interactive editor embedded in the core.
povray
+2
Implication: the most practical way is a separate, cross‑platform UI app
that edits control points and writes an include file the scene uses, then spawns
POV‑Ray to re‑render. (This is what legacy tools like Epspline did
for prism/lathe editing.)
mit

Architecture A — A stand‑alone, cross‑platform spline modeler that
“drives” POV‑Ray
1) UI & platform stack
Framework: Qt 6 (Widgets or QML) or Dear ImGui + SDL2; both are truly
cross‑platform (Win/macOS/Linux) and provide mouse picking, viewport
widgets, file dialogs.
Viewport: OpenGL/Vulkan for fast redraw of control polygons and curve previews.
Spline kernel: adopt TinySpline (ANSI‑C NURBS/B‑Spline/Bézier with
C++ wrapper; many language bindings) so you get robust operations (knot
insertion, evaluation, degree elevate/reduce, reparametrization, serialization).
github
+1
2) Geometry mapping to POV‑Ray
Lathe (rotate 2‑D profile around y): export control points in 2‑D
order with the proper spline tag
(linear_spline|quadratic_spline|cubic_spline|bezier_spline). The lathe’s curve
lies in the x–y plane and rotates about y.
povray
Prism (extrude along y): export 2‑D control points in x–z (POV‑Ray
defines prism polylines in x–z and sweeps along y). Include correct closing
rules for non‑linear splines to avoid “too few points” errors.
povray
+1
Sphere_sweep: export a list of centers + radii and your chosen interpolation
(linear_spline|b_spline|cubic_spline).
povray
Path splines: for cameras or animated controllers, output an SDL spline { ... }
for linear|quadratic|cubic|natural_spline.
povray
Provide a simple include contract, e.g., generate model_splines.inc with
#declare A1D_PROFILE=array[N]{<x,z>,...}; lathe{ cubic_spline N, A1D_PROFILE[0]
.... }, etc. The main .pov scene just #include’s it.
povray
+1

3) “Live” render loop
Export: save the include and a small scene INI.
Render: spawn POV‑Ray headless (pvengine.exe /RENDER file.pov /EXIT on
Windows; povray +Ifile.pov +H720 +W1280 ... on Unix/macOS). Show the rendered
image back in the app.
povray
+1
Hot‑reload: on every point edit (mouse drag/drop, add/delete), rewrite the
include and re‑invoke POV‑Ray at low resolution for a fast preview,
then optionally a full‑res pass on idle. (This mirrors what Epspline did:
a drawing canvas + POV settings + SDL export).
mit
4) File I/O & robustness
Accept/save JSON or your own format for all splines; use TinySpline’s
serialization if convenient.
github
When targeting prism/lathe: enforce closing semantics (linear auto‑closes,
others require explicit closure), and for prism warn the user the curve lives in
x–z & sweeps along y.
povray
For sphere_sweep: validate minimum number of spheres by mode (≥2 for
linear, ≥4 for b_spline/cubic_spline), and expose the tolerance knob if
users see self‑shadowing.
povray
5) Packaging & licensing
Ship as a separate application (no POV‑Ray code inside). Users point the
app to their POV‑Ray binary and libraries. This avoids re‑licensing
the renderer. (POV‑Ray 3.7+ source is under AGPL‑3.0;
bundling/derivatives of the core would pull you into AGPL obligations.)
github
+2
Architecture B — Build on the Blender ↔ POV‑Ray exporter instead of
reinventing a modeler
Blender already provides interactive splines, curve objects, and rich mouse
editing. There is a maintained POV‑Ray exporter (a.k.a. “POV@Ble”) for
Blender 4.x that writes POV code, supports many primitives, and lets you add
custom POV code where needed.
povray
+1
Users install POV‑Ray, enable the exporter add‑on, and render from
Blender; you can capture the generated .pov for inspection and
command‑line use.
stackexchange
If your primary goal is point‑and‑click spline editing, this path is
the least engineering effort and gives you modeling, snapping, transform tools,
and packaging for free.
blender

Scope checklist: what your modeler must implement
Interactive editing

Add/delete/move control points with handles; toggle open/closed curves; degree
(linear/quadratic/cubic) and B‑spline/Bezier mode; for NURBS, allow
per‑point weights (export as sampled points or rational → Bezier
conversion for POV targets). (Use TinySpline ops for knot insertion, elevation,
etc.)
github
Snapping & constraints (grid, angle, symmetry), curve reparameterization,
arc‑length sampling for even sweep tessellation (if you export mesh
fallbacks).
github
POV‑Ray export adapters

Lathe exporter (x–y points → lathe about y) and Prism exporter (x–z
points
→ sweep y) with correct closure per spline type.
povray
+1
Sphere_sweep exporter (centers + radii, correct mode/tolerance).
povray
Optional: Bicubic patch / mesh2 fallback for shapes that do not map neatly to
lathe/prism.
Render integration

INI & CLI generation; Windows pvengine.exe /RENDER … /EXIT and Unix/macOS povray
+I… variants; let users choose preview vs. final settings in the UI.
povray
+1
Include eco‑system

Generate a stable #declare API; e.g., #declare A1D_PROFILE = array[...] for
lathe, #declare A2D_SWEEP = array[...] for sphere_sweep; the main scene does
#include "model_splines.inc". (POV‑Ray can read files via #fopen/#read
too, but simple #include keeps scenes deterministic.)
povray
QA on spline semantics

Enforce POV’s minimum point counts per spline type and closing rules
(non‑linear splines are not auto‑closed). Provide on‑canvas
warnings before export.
povray
+1
If you really want it inside POV‑Ray
It’s possible but heavy:

You’d extend the front‑ends (Windows pvengine.exe, Unix VFE console layer)
to add an event loop, mouse input, and an interactive canvas. The Unix
documentation/source indicates the Unix build is a console app with optional
SDL/text preview; adding a cross‑platform GUI means substantial changes in
the VFE layer and new display backends.
deepwiki
+1
You’ll also need a spline kernel (e.g., port TinySpline) and a persistable
editor state, plus a way to regenerate SDL and re‑invoke the internal
parser on change.
Distributing binaries with such changes makes you a derivative; you’ll need to
comply with AGPL‑3.0 (source distribution of your modified renderer,
including network‑use clause). If you’d rather avoid that, keep the editor
external and just call the official POV‑Ray binary.
github
+1
Verdict: it’s far more practical to ship a stand‑alone editor or leverage
Blender+POV exporter, not to rewrite POV‑Ray as a modeler.

Minimum viable plan (6–10 weeks)
Week 1–2 — Foundations

Pick Qt 6 + OpenGL; integrate TinySpline (CMake/Conan/NuGet help available).
github
+2
Implement 2‑D editors for Lathe (x–y) and Prism (x–z) with point
add/delete/move; toggle spline type.
Week 3–4 — Export & POV‑Ray loop

Emit model_splines.inc; small driver .pov and .ini.
Implement spawn‑and‑preview for Windows (/RENDER, /EXIT) and Unix
(povray +I...).
povray
+1
Week 5–6 — Sphere_sweep + UX polish

3‑D editor for centers/radii; length‑based resampling; tolerance
control.
povray
Status panel with POV‑Ray warnings (e.g., non‑closed cubic spline).
povray
Week 7–10 — Nice‑to‑haves

NURBS weights in the editor (export hybrid: sample to cubic/Bezier when POV
primitive does not support NURBS).
Blender bridge (optional): let users send curves to Blender’s POV exporter and
render there.
povray
+1
Prior art you can study
Epspline, a GUI tool specifically for POV‑Ray prism/lathe editing,
documents workflows, UI patterns, and how exported SDL is structured—useful to
emulate.
mit
Blender’s POV‑Ray exporter (POV@Ble) shows a mature, maintained pipeline
for exporting POV primitives, including splines, custom code hooks, and
command‑line integration.
povray
+1
Quick prototype snippet (what your app would write)



Plain Text
pov isn’t fully supported. Syntax highlighting is based on Plain Text.

// model_splines.inc (generated)
#declare A1D_LatheProfile = array[6] { <0,0>, <1,1>, <3,2>, <2,3>, <2,4>, <0,4>
};
#declare OBJ_Lathe =
lathe {
  cubic_spline
  6,
  A1D_LatheProfile[0], A1D_LatheProfile[1], A1D_LatheProfile[2],
  A1D_LatheProfile[3], A1D_LatheProfile[4], A1D_LatheProfile[5]
  pigment { color rgb <0.8,0.8,0.9> }
}
…and your driver scene just does:




Plain Text
pov isn’t fully supported. Syntax highlighting is based on Plain Text.

#include "model_splines.inc"
camera { location <0, -10, 4> look_at 0 }
light_source { <30,-40,50> rgb 1 }
object { OBJ_Lathe }
(That matches POV’s lathe semantics: 2‑D points, rotated around y; cubic
splines require explicit closure if you want a closed profile.)
povray

Bottom line
Fastest path: a separate, cross‑platform editor that exports .inc + spawns
POV‑Ray.
Least work: extend Blender’s exporter workflow and let Blender be the
interactive modeler.
povray
+1
Hardest path: bake a GUI into POV‑Ray itself—requires front‑end
re‑engineering and AGPL compliance.
deepwiki
+1

[Bald Eagle] Dynamic Identifiers [163 days 2 hours and 44 minutes ago]

Tue, 28 Oct 2025 17:50:00 GMT

what would it take to enable the creation or referencing of object identifiers
in povray?  Something like the ability to cycle through "index_01" to "index_99"
with a #for loop, or to be able to create those identifiers and assign them
values using a #for loop?
Copilot said:
Copilot

Reasoned for 1s

Considering identifier creation constraints

Exploring dynamic identifiers in SDL
Short answer: You can’t build or reference identifiers dynamically in
today’s
SDL (e.g., no "index_"+str(I) to make index_01)—the parser requires literal
identifiers at parse time. The practical, supported way is to use arrays (or
generated include files) instead of synthesizing names. To make dynamic names
possible natively would require parser & symbol‑table changes (details
below).

Below I’ll show:

What SDL supports today and why a loop like index_01..index_99 can’t create/read
identifiers by name.
Workable patterns you can use now (arrays; auto‑generated includes).
What it would take to add dynamic identifiers to POV‑Ray (concrete options
and the scope of work, with rough effort).
1) What SDL allows today (and why “dynamic names” don’t work)
SDL’s identifiers are recognized by the tokenizer and bound by the parser at
parse time; there’s no operator to evaluate an identifier name from a string,
and directives like #declare, #local, #ifdef, #undef expect literal identifier
tokens (not strings).
povray
+1
The official language directives list includes #declare, #local, #macro, #while,
#switch/#case/#range, etc.—but no #for directive, and no directive takes a
string to “look up” a variable by name. (Looping is done with
#while/#range.)
File I/O directives (#fopen/#read/#write) also expect literals in the file being
read; you can read strings, floats, vectors—but you still cannot turn a read
string into an identifier to be resolved dynamically.
povray
Consequence: a loop like




Plain Text
pov isn’t fully supported. Syntax highlighting is based on Plain Text.

#for(I, 1, 99)           // (not a real SDL directive)
  #declare index_?? = ... // cannot build ?? from I
#end
``
isn’t possible as written because both #for and “string‑built
identifier
names” are unsupported. Use #while for looping and arrays for indexing.

2) Workable patterns you can use right now
Option A — Use arrays (recommended & fast)
Instead of index_01 … index_99, use one array:




Plain Text
pov isn’t fully supported. Syntax highlighting is based on Plain Text.

#declare A1D_INDEX = array[100];

#declare I = 1;
#while (I <= 99)
  #declare A1D_INDEX[I] = some_value(I); // whatever you compute
  #declare I = I + 1;
#end

// Using:
object { A1D_INDEX[42] }  // or scalar/vector/etc. depending on what you store
Arrays are first‑class in SDL and are the idiomatic substitute for a
family of numbered variables. You can nest arrays to emulate 2‑D
“namespaces” if needed.

Option B — Generate code (identifiers) before parsing
When you truly need separate identifiers (for human readability or library
conventions), auto‑generate an include file that contains the declarations
with literal names, then #include it.

Two ways:

Inside SDL: #fopen + #write to create a .inc file, then #include it. The file
you write must contain valid SDL with literal identifiers; on the next parse
pass, they exist.
povray
Outside SDL: use Pre_Frame_Command (INI) to run a script that writes a .inc (or
modifies inputs) before each frame is parsed; then #include it from your scene.
This is the officially supported “shell‑out before parse” hook.
stackoverflow
+1
Example (SDL‑only):




Plain Text
pov isn’t fully supported. Syntax highlighting is based on Plain Text.

#fopen OUT "gen_index.inc" write
#declare I = 1;
#while (I <= 99)
  #write (OUT, "#declare index_", str(I, -2, 0), " = ", I*I, ";\n")
  #declare I = I + 1;
#end
#fclose OUT

#include "gen_index.inc"  // now index_01 .. index_99 exist as identifiers
Note: str(I, -2, 0) is just formatting; the key is that the generated file
contains literal index_01 tokens. The dynamic part happens before the parser
sees them.
github

3) What it would take to add dynamic identifiers to POV‑Ray
There are several ways you could extend SDL to allow “build an identifier name
and then get/set it”. Each has different scope.

A) Add built‑ins for indirection (narrow change; low surface risk)
Introduce new functions that take strings and access the symbol table:

getvar("index_01") → returns the current value of that identifier
(scalar/vector/string/object handle).
setvar("index_"+str(I,-2,0), Value) → creates/updates the named identifier
in the current scope.
Optional: exists("name"), undef("name").
What changes:

Parser: recognize calls to these built‑ins and route them to a safe
symbol‑table API.
Symbol table: add LookupByString, AssignByString with scope rules matching
#declare/#local.
Type system: either return a tagged union (existing value representation) or
restrict to scalar/vector/string first.
Effort: ~2–3 weeks for a seasoned contributor (parser hooks, symbol table API,
error handling, tests, docs). This avoids new syntax and is easy to
version‑gate (e.g., require #version 3.9).
hws
+1

B) Allow computed identifiers in #declare/#local (bigger parser change)
Syntax idea:




Plain Text
pov isn’t fully supported. Syntax highlighting is based on Plain Text.

#declare @("index_"+str(I,-2,0)) = Value;
#local   @NameString = Value;   // where NameString is a string variable
What changes:

Tokenizer: keep as is (the @(...) starts an expression).
Parser: for #declare/#local, accept either an identifier or the @(<string-expr>)
form; evaluate the string, then call the same symbol‑table API as in A.
Update #undef/#ifdef to optionally accept @(<string>).
Effort: ~4–6 weeks (more rules in the parser, diagnostics for conflicts,
consistent behavior with scope). Make sure #ifdef short‑circuits safely
and retains good error recovery.
mankier

C) Add associative containers (maps) to SDL (clean, but new concept)
Rather than touching identifiers, add a first‑class map type:




Plain Text
pov isn’t fully supported. Syntax highlighting is based on Plain Text.

#declare M = map();
#declare I = 1;
#while (I <= 99)
  M["index_"+str(I,-2,0)] = compute(I);  // store values by string key
  #declare I = I + 1;
#end

object { M["index_42"] }   // retrieve later
What changes:

Value system: new container type.
Parser: literals & indexing syntax for maps; probably reuse string indexing
syntax as shown.
Runtime: storage, copy/clone semantics.
Effort: larger (6–10+ weeks); conceptually clean and safer than mutating the
global namespace, but more intrusive.

Compatibility & safety considerations
Version‑gate everything behind #version (and Version= in INI) so older
scenes are unaffected. Versioned parsing behavior is already standard in
POV‑Ray.
stackoverflow
Scope rules: new “indirection” must respect #local vs. #declare and macro
scoping. Define “current scope” precisely to avoid surprises. (The parser
today
has clear notions of these scopes.)
Error handling: good messages are essential (e.g., “setvar: illegal name”,
“shadowing a macro with a variable”). Existing scanner/parser already track
line/column; carry that through.
programmersought
Recommendation
For a minimal, robust feature that unlocks your use case:

Start with Option A (arrays) whenever possible—stable, fast, supported.
If human‑readable variable names are required, generate includes (Option B
above) using #write or Pre_Frame_Command. This is fully supported by today’s
engine.
povray
+1
If you want to propose a core enhancement, Option A (getvar/setvar/exists) is
the least invasive, easiest to review, and can ship behind #version without
breaking compatibility.
If you want, I can provide a tiny proof‑of‑concept patch sketch
(parser entry points and symbol‑table calls) for a getvar/setvar design
and a suite of SDL tests that mimic your index_01..index_99 loop.




parser.h
--- a/source/parser/parser.h
+++ b/source/parser/parser.h
@@
+#define POV_ENABLE_NAME_INDIRECTION 1   // PoC switch

Symbol table

--- a/source/parser/symboltable.h
+++ b/source/parser/symboltable.h
@@
 class SymbolTable {
 public:
   // existing API ...
+  // LOOKUP by raw string (UTF-8 accepted; convert to internal as needed)
+  bool LookupByString(const std::string& name, Value& out) const;
+  // ASSIGN into current scope; behavior mirrors #declare/#local resolution
+  bool AssignByString(const std::string& name, const Value& v, bool
localPreferred);
+  // EXISTS?
+  bool ExistsByString(const std::string& name) const;
+  // UNDEF
+  bool UndefByString(const std::string& name);
 };


--- a/source/parser/symboltable.cpp
+++ b/source/parser/symboltable.cpp
@@
 bool SymbolTable::LookupByString(const std::string& name, Value& out) const
 {
   // NOTE: convert to internal key type if needed
   const Identifier* id = FindIdentifierByAsciiName(name); // or create a helper
   if(!id) return false;
   return GetValueForIdentifier(*id, out);
 }

 bool SymbolTable::AssignByString(const std::string& name, const Value& v, bool
localPreferred)
 {
   Identifier* id = GetOrCreateIdentifierByAsciiName(name, localPreferred);
   if(!id) return false;
   return SetValueForIdentifier(*id, v); // follows existing assign rules
 }

 bool SymbolTable::ExistsByString(const std::string& name) const
 {
   const Identifier* id = FindIdentifierByAsciiName(name);
   return id != nullptr && HasValue(*id);
 }

 bool SymbolTable::UndefByString(const std::string& name)
 {
   Identifier* id = FindIdentifierByAsciiName(name);
   if(!id) return false;
   return UndefIdentifier(*id);
 }

parser.cpp
--- a/source/parser/parser.cpp
+++ b/source/parser/parser.cpp
@@
 Value Parser::ParseFunctionOrIdentifier()
 {
   // ... existing code that parsed an identifier name into `name` and saw '('
   if(IsFunctionCall()) {
     std::string fname = CurrentIdentifierText();  // e.g., "getvar"
     if( LanguageVersion() >= 3.9
         && POV_ENABLE_NAME_INDIRECTION
         && (fname == "getvar" || fname == "setvar" || fname == "exists" ||
fname == "undefvar"))
     {
         return ParseNameIndirectionBuiltin(fname);
     }
     // else fall through to regular function parsing
   }
   // normal path...
 }
``
--- a/source/parser/parser.cpp
+++ b/source/parser/parser.cpp
@@
 Value Parser::ParseNameIndirectionBuiltin(const std::string& fname)
 {
     ExpectToken('(');

     // parse first arg: any expression that must reduce to string *now*
     Value nameVal = ParseExpression();
     if(!nameVal.IsString())
         Error("First argument to %s(...) must be a string.", fname.c_str());

     std::string varName = nameVal.AsStdString();

     if(fname == "getvar") {
         ExpectMaybeCommaThen(')');
         Value out;
         if(!symtab.LookupByString(varName, out))
             Error("getvar(\"%s\"): undefined identifier.", varName.c_str());
         return out; // may be scalar, vector, string, object ref, etc.
     }
     else if(fname == "exists") {
         ExpectMaybeCommaThen(')');
         bool ok = symtab.ExistsByString(varName);
         return Value::FromFloat(ok ? 1.0 : 0.0);
     }
     else if(fname == "undefvar") {
         ExpectMaybeCommaThen(')');
         bool ok = symtab.UndefByString(varName);
         return Value::FromFloat(ok ? 1.0 : 0.0);
     }
     else if(fname == "setvar") {
         ExpectToken(',');
         Value rhs = ParseExpression();   // any kind of value
         ExpectToken(')');

         // localPreferred: true if inside a macro scope; you can refine rule
         bool localPreferred = InLocalScope();
         bool ok = symtab.AssignByString(varName, rhs, localPreferred);
         if(!ok)
             Error("setvar(\"%s\", ...): assignment failed.", varName.c_str());
         // setvar returns the assigned value (convenient for chaining)
         return rhs;
     }
     // unreachable
 }

[Bald Eagle] Object typing [163 days 3 hours and 4 minutes ago]

Tue, 28 Oct 2025 17:30:00 GMT

"Can you tell me how much work it would require to add object typing to povray's
sdl?  For instance, determining if something is a scalar, text, vector, or
something else (object)?"

Copilot said:


Reasoned for 1s

Planning types integration for SDL
Below is a practical engineering assessment of the work needed to add object
typing / runtime type introspection to POV‑Ray’s SDL—i.e., being able
to
query at parse time whether an identifier/expression is a scalar, string (text),
vector/color, or an object (mesh, CSG, camera, etc.), and to branch/validate
accordingly.

I’ll anchor this to the current 3.8 code organization (scanner → tokenizer
→ parser → symbol table → function VM) and the public
docs/source so you can see exactly what must change.
hws
+1

What “object typing” means in SDL
Today, SDL is dynamically typed and contextual: the parser decides what an
expression “is” from its syntactic form and where it appears (e.g., <…>
fits a
vector where one is expected; a sphere{…} block is an object literal). The
symbol table stores identifiers, macros, arrays, etc., but there’s no
first‑class, queryable “type” value exposed to users; you can’t
write #if
(type_of(X) = vector) out of the box. Adding this requires:

A stable type taxonomy visible to users (e.g., scalar, vector, color, string,
object, texture, pattern, transform, …).
Parser & symbol table changes so each value/expression has an associated runtime
type tag.
Built‑ins to query or test types (e.g., typeof(expr) returning an
integer/enum; predicates like is_scalar(expr)), and possibly typecase helpers in
SDL.
Diagnostics & compatibility so older scenes still parse identically.
The current pipeline (scanner/tokenizer, parser, symbol table, function VM) is a
good foundation: types can be added with minimal disruption if you keep
evaluation semantics unchanged and only enrich metadata.
programmersought
+2

Where the changes would go
1) Symbol table & value representation
Add a TypeTag to the core value/variant used for identifiers and expression
results. If values are currently represented as a tagged union in the parser
front‑end (e.g., float / string / vector / color / object pointers),
formalize the tag and propagate it everywhere an expression result is produced
or consumed.
Ensure arrays and macros carry either an element type (arrays) or signature
metadata (macros), or return “unknown/any” if you prefer gradual typing.
This is a contained but pervasive change (read: mechanical edits), because every
path that constructs a value must set the tag, and every path that consumes a
value can optionally use it for richer error messages. The Parser System and
symbol table are the touch points.
hws

2) Parser / expression typing
Extend expression nodes so each AST node carries a TypeTag after semantic
analysis. For literals it’s trivial (float, string, vector, etc.); for
identifiers and macro calls you’ll flow the type from symbol resolution; for
overloaded contexts (e.g., color vectors), keep compatibility but store the more
specific tag (color vs. vector) when known.
For object blocks (e.g., sphere{} / union{} / isosurface{}), mark the node with
type=object. This code lives in parser.cpp and specialized parsers (materials,
strings, etc.).
mankier
3) Built‑ins & directives
Introduce a function typeof(expr) that returns an integral code or string—e.g.,
TYPE_SCALAR=1, TYPE_VECTOR=2, TYPE_STRING=3, TYPE_OBJECT=100, etc.
(Version‑gate it under #version 3.8/3.9 to avoid conflicts).
Convenience predicates: is_scalar(x), is_string(x), is_vector(x), is_object(x),
…—implemented as thin wrappers around typeof.
Optional: a #switch(type_of(expr)) pattern in docs as a recommended idiom; the
directive itself already exists (#switch/#case/#end), so users can branch
without new syntax.
These hooks sit naturally alongside existing language directives & functions,
which the docs already treat as part of the “Language Directives / SDL
built‑ins” surface.

4) Function VM interop
If you keep typeof() and the predicates entirely parse‑time, you can
resolve them in the parser/evaluator without touching the function VM.
If you want typeof() inside function bodies executed by the VM, add a tiny VM
opcode that pushes the tag value for its argument (and ensure the VM’s value
model can pass vectors/strings/objects through as argument types). The VM
currently focuses on numeric functions; any vector/string support you add here
should be consistent with prior plans (e.g., vector VM work).
mankier
5) Diagnostics & tooling
With tags, the parser can emit richer errors (“expected vector, got string at
line…”) while preserving previous behavior in mixed contexts. The
scanning/tokenization already records position info; keep passing it through.
programmersought
Proposed user‑visible API
Minimal, compatible set:




Plain Text
p isn’t fully supported. Syntax highlighting is based on Plain Text.

// constants (documented values)
#declare TYPE_SCALAR = 1;
#declare TYPE_VECTOR = 2;
#declare TYPE_STRING = 3;
#declare TYPE_COLOR  = 4;
#declare TYPE_OBJECT = 100;

// built-ins
#declare T = typeof(MyValue);     // returns one of the TYPE_* codes
#declare OK = is_vector(MyValue); // predicate shortcuts
No syntax changes are required; the new functions are enough. (They plug into
existing #if/#switch.)

Effort estimate (with breakdown)
Assumes 1 experienced contributor who has already built POV‑Ray locally.
Add 25–40% if you’re new to the codebase.

Work item Files / areas Est. effort
Design: type taxonomy, public constants, version gates design note + docs 2–3
days
Value/Tag plumbing: add TypeTag to value/variant, set on literal creation,
identifier lookup, object/material constructors parser core, symbol table 6–8
days
Expression typing: annotate AST; flow types through operators & function calls;
keep legacy coercions parser.cpp, parser_expressions.cpp, helpers 6–10 days
Built‑ins: implement typeof() + is_*(); integrate into parser/evaluator;
optional VM opcode parser built‑ins; (optional) fncode.cpp 3–5 days
Diagnostics: improved error messages using tags parser 2–3 days
Tests: unit tests (expressions, arrays, macros, object blocks); golden scenes
new tests, tests/source 5–7 days
Docs: manual page updates & examples docs tree 2 days
Total: about 24–38 person‑days (~5–8 weeks part‑time, or
~3–4 weeks
full‑time).

Why this is plausible: the parser/tokenizer architecture is already modular and
well‑documented; you’re enriching metadata and adding a few
built‑ins rather than re‑architecting the pipeline. The large file
is parser.cpp (~10k lines), but changes are local and mechanical.
mankier

Compatibility strategy
No behavior change unless users call the new built‑ins.
Guard constants and functions behind #version (or the INI Version= option) so
legacy scenes are unaffected. (POV‑Ray already uses version gating for
parsing semantics.)
stackoverflow
Keep “color is a vector” behavior usable where historically accepted, but
expose
TYPE_COLOR so authors can distinguish if they want to.
Risks / tricky corners
Array/macro typing: You can either give arrays a declared element type (if
known) or return TYPE_ARRAY/TYPE_MACRO and let users decide. Starting with a
single “other” code for arrays/macros is simplest.
Implicit promotions: SDL permits convenient promotions (e.g., color ↔
vector). Be careful not to change evaluation; tags should inform diagnostics and
introspection, not alter coercions.
VM scope: Only needed if you promise typeof() inside VM‑executed user
functions; otherwise keep the feature in the parser/evaluator and you’re done.
mankier
Suggested phased approach
Phase 1 (lowest risk): implement TypeTag in parser values, typeof() + is_*() at
parse‑time only; improved error text.
Phase 2: document public constants and add tests across common constructs
(objects, textures, transforms, colors).
Phase 3 (optional): enable typeof() inside function VM bodies with a simple
opcode; add tags for vectors/colors if you’re already extending the VM for
vectors.
Phase 4 (optional): expose tags for additional categories
(texture/pigment/finish, transformation matrices).
Each phase is independently useful and shippable.

Sources & where to look in code
Parser system overview (scanner → tokenizer → parser → symbol
table / function VM) — good map of components you’ll touch.
hws
Core parser files: parser.cpp, parser_expressions.cpp, parser_functions*.cpp,
symboltable.*; tokenizer & reserved words: parser_tokenizer.cpp,
reservedwords.cpp; scanner: scanner.cpp. These are where you’ll add tags,
built‑ins, and diagnostics.
mankier
+2
Language directives / SDL reference — for integrating new built‑ins and
documenting behavior alongside existing directives and functions.
Parse options & version gating — how #version / Version= controls language
behavior today.
stackoverflow
Bottom line
Adding runtime type introspection to SDL is a small‑to‑medium
enhancement: mostly systematic parser/symbol‑table work plus a couple of
built‑ins and tests. If you keep typeof() at parse‑time, it’s a
clean, low‑risk improvement that makes macro libraries safer and more
expressive—without changing how existing scenes render.

[Bald Eagle] Adding vector-valued functions [163 days 3 hours and 4 minutes ago]

Tue, 28 Oct 2025 17:30:00 GMT

"Can you tell me how much work it would require to add the ability to evaluate
vector functions and vector swizzling to povray's function virtual machine?"

Copilot said:

Reasoned for 1s

Estimating effort for additions
Below is a realistic engineering assessment of what it would take to add (1)
true vector‑valued functions and (2) vector swizzling (e.g., .xzy, .yyx)
to POV‑Ray’s function virtual machine (VM), along with the parser and
code‑generation changes needed to surface them cleanly in SDL.

I’m assuming mainline 3.8 code as published on GitHub and its current
front‑end (scanner → tokenizer → parser) and back‑end
(function VM / evaluator). Where I say “VM,” I’m referring to the
byte‑code/IR executed for user functions defined in SDL (the code path
handled in fncode.cpp and the parser’s function rules).
mankier
+1

Executive summary
Scope: Medium—touches parser, tokenizer, reserved words, function code
generator, VM op set, and runtime math library.
Complexity: Mostly mechanical but non‑trivial because the current pipeline
is strongly scalar‑oriented; vectors are supported in SDL expressions, but
the function VM primarily evaluates scalar functions and relies on inlining or
ad‑hoc paths for vector math. Extending it cleanly implies adding
first‑class vector types and opcodes.
mankier
+1
Estimated effort (for an experienced contributor familiar with the code base):
~8–12 weeks part‑time (or ~4–6 weeks full‑time), including tests
and
docs. The lion’s share is careful integration, error reporting, and
backwards‑compatibility tests rather than algorithmic difficulty.
(Breakdown below.)
Where you have to make changes (top‑down)
1) Language & parser surface
Goals

Allow function definitions that return a vector and/or take vector arguments.
Extend expression typing so that vector expressions can be compiled to VM
bytecode.
Support swizzle selectors (e.g., V.x, V.xy, V.zxy, V.xxx) as l‑values (if
you want assignment) or at least r‑values.
Files / modules affected

Tokenizer/Reserved words: the dot accessor today is used in various contexts;
ensure tokenization allows chained component selectors on identifiers and
sub‑expressions (e.g., (A+B).xz). (parser_tokenizer.cpp,
reservedwords.cpp)
povray
Parser: add productions for:
function return type = vector (e.g., function { |x,y| <...> } today is scalar;
you’ll need a grammar that permits <expr,expr,expr> as the function’s body
or a
typed header).
Vector expressions inside function bodies compiled to VM (not just evaluated at
parse time). (parser.cpp, parser_expressions.cpp, parser_functions.cpp)
mankier
Semantic checks: arity/type mismatches; disallow swizzle lengths other than
1..4; enforce read‑only swizzles unless you implement write‑back.
The parser currently builds scene structures while parsing; for functions it
compiles to the function VM via fncode utilities. You’ll extend that
code‑generation path to emit vector instructions. (fncode.cpp and helpers)
mankier

2) Function VM & bytecode
Goals

Introduce a first‑class vector value type in the VM stack model (likely
3‑component float vectors; optionally 4D for color/alpha).
Add opcodes for: LOAD_VEC, BUILD_VEC3, SWZ1/2/3/4, VADD, VSUB, VMUL
(elementwise), VDOT, VCROSS, VLEN, VNORM, VCLAMP, VMIX, etc.
Define type promotion rules: scalar op vector (broadcast scalar), numeric
literals to vector, etc.
Extend the runtime math library to vectorize existing intrinsics where
appropriate (e.g., sin(vec) → component‑wise).
Files / modules affected

VM representation / code emitter: extend structures that describe opcodes and
the stack to accommodate vectors (size and alignment), and update the
interpreter loop to handle them. (fncode.cpp chiefly)
mankier
Parser→VM bridge: in the code that compiles expressions to VM IR/bytecode,
add cases for vector constants <x,y,z>, vector operators, and swizzles. (Parser
emits calls into fncode helpers.)
mankier
Standard library intrinsics: decide which built‑ins get vector overloads
in the VM (e.g., min, max, clamp, dot, cross, length, normalized, noise,
f_noise3d style). Ensure the overload set matches SDL expression semantics.
(Parser & VM dispatch)
mankier
3) Swizzling semantics
Read‑only swizzles are easy: treat V.xyz as an inline permutation/extract
instruction sequence producing a vector (1–4 comps) on the VM stack.
Writeable swizzles (V.xy = …) are trickier: you need l‑value analysis and
write‑back masks. Unless there is a strong need, start with r‑values
only.
Grammar‑wise you’ll parse a postfix selector list after a primary
expression. Tokenizer already recognizes .; you only need to validate the
character class {x,y,z}×(1..4) and build a small swizzle mask. (Tokenizer +
parser)
povray
+1

4) Type system & diagnostics
Add a minimal static type notion in the function compiler so errors like dot(
scalar , vector ) are caught at compile time rather than at run time.
Improve error messages (line/column from scanner are already tracked; keep
passing them through). (scanner.cpp, parser nodes)
programmersought
5) Backwards compatibility
Keep scalar‑only functions working as today.
Do not change existing precedence or numeric literal rules.
Gate any syntax that could be ambiguous behind #version 3.8+ or similar, just as
POV‑Ray already uses Version/#version to select language behavior.
stackoverflow
Work breakdown & effort estimate
Assumes one contributor with good C++ and some familiarity with POV‑Ray’s
code; add 25–40% if you’re new to the tree.

Task Main files Est. effort
Design: opcode set, stack layout, type rules, swizzle spec design doc 3–5 days
Tokenizer & Parser: swizzle selectors parser_tokenizer.cpp,
parser_expressions.cpp, parser_functions.cpp, parser.cpp 8–12 days
VM & bytecode: vector value type; opcodes; interpreter changes; emitter helpers
fncode.cpp (+ headers) 10–15 days
Intrinsics: implement vector overloads for common math ops; promote parser
overload resolution + VM 5–7 days
Tests: unit tests for new tests + tests/source 6–8 days
Docs: SDL reference docs tree 2–3 days
Total: ~34–50 person‑days (≈7–10 weeks part‑time). This
aligns
with the amount of code in the parser/VM and the care needed for versioned
behavior. (The parser core is >8k LOC; even small changes propagate.)
mankier

Risk & complexity hotspots
Mixed scalar/vector expressions: decide on promotion (broadcast scalars) and
forbidden mixes; mirror existing SDL expression behavior to avoid surprises.
(Parser + VM)
Noise/isosurface functions: Some built‑ins accept vectors already at
parse‑time. Ensure VM vectorization doesn’t diverge semantically from
existing evaluation. (Parser + core math calls)
mankier
Performance: The interpreter is scalar‑centric; vectors will push more
data per instruction. Consider packed ops to reduce opcode dispatch overhead
(e.g., VADD instead of three scalar ADDs). (VM)
mankier
Error recovery: swizzle typos (.xxw) must produce crisp errors and recover to
the next statement; lean on the existing reporting in scanner/parser.
programmersought
+1
Minimal viable path (recommended)
Phase A: Read‑only swizzles and vector returns/args for functions, plus
basic vector ops (+ - * with scalar broadcast, dot, cross, length, normalize).
Phase B: Extend intrinsics and add convenience ops (min/max/clamp/mix),
color‑vector aliases if desired.
Phase C: (Optional) writeable swizzles and 4‑component vectors (RGBA).
Phase D: micro‑opt (pack opcodes), more intrinsics, documentation polish.
Each phase is shippable and can be guarded behind a #version gate.


Example (what users would gain)

#version 3.8;

#declare F_NORMAL = function(u, v) {
  // Return a vector (unit normal on a wavy surface)
  #local p = <u, v, sin(2*pi*u)*cos(2*pi*v)>;
  // swizzle to drop z ripple into x,y direction and normalize
  normalize(<1,0,0>*p.x + <0,1,0>*p.y + <0,0,1>*p.z)
};

#declare F_SHADING = function(n) { // n is a vector
  // swizzle use: emphasize yz
  let k = dot(n.yz, <0.6, 0.8>);
  clamp(k, 0, 1)
};


Why the estimate is plausible

The code base already separates scanning/tokenization from parsing and has a
clear function code path (fncode.cpp)—you’re not re‑plumbing
everything,
just extending types/opcodes and codegen. [programmersought.com], [mankier.com]
SDL’s versioning mechanism (via #version/Version=) is in place to gate new
syntax/semantics, so you won’t need a bespoke feature switch system.
[stackoverflow.com]
DeepWiki overviews outline the front‑end pipeline
(scanner→tokenizer→parser→symbol table→function VM),
providing a reliable map of where to touch. [math.hws.edu],
[programmersought.com]

[Bald Eagle] Parser rewrite [163 days 3 hours and 14 minutes ago]

Tue, 28 Oct 2025 17:20:00 GMT

Just for kicks, I'm wondering how much we can shove at an AI and have it do a
lot of the complicated digging into the extant source, and how much we can have
it write a lot of the basic framework of 4.0


"given the source code for all of pov-ray, can you give a summary of what would
be needed to rewrite the parser?  Is there a short list of top formats (like
json) that would be most suitable for updating the SDL language?"

Copilot said:
(Reasoned for 14s)


Exploring additional formats
Below is a pragmatic roadmap for “what it would take” to rewrite the
POV‑Ray parser today, followed by a short list of modern interchange
formats that could complement—or partially replace—SDL, with pros/cons for
each.

1) What the current parser does (and why that matters)
POV‑Ray’s front‑end is a classic multi‑stage compiler
pipeline:

Scanner → breaks raw text into lexemes and tracks encoding, line/column,
newlines, comments.
deepwiki
Raw tokenizer / tokenizer → turns lexemes into tokens (identifiers,
keywords, literals, operators).
deepwiki
+1
Parser → consumes tokens, implements the SDL grammar (objects, textures,
directives, expressions), populates scene structures, manages the symbol table
(identifiers, macros), and invokes a function VM for user functions.
deepwiki
These pieces live under source/parser/ (e.g., parser.cpp, parser_tokenizer.cpp,
scanner.cpp, reservedwords.cpp). The parser is large (~10k LOC in parser.cpp
alone) and historically evolved, with hand‑coded recursive‑descent
rules intertwined with scene construction and semantic actions.
github

SDL itself mixes declarative scene data with imperative control (e.g.,
#if/#while/#macro/#read/#fopen), which is powerful but complicates formal
grammar extraction and pure data interchange.
povray
+1

2) A realistic plan to rewrite the parser
2.1. Extract and formalize the language
Write a formal grammar (EBNF or a PEG) for the current SDL, separating:

core scene constructs (camera, objects, textures),
expressions (numeric, vector, color), and
directives (#macro, #include, #if, #while, file I/O) that control
parse‑time evaluation.
This is not just academic; it makes it possible to drive a generator like
ANTLR/PEGTL or to validate a new hand‑written RD parser. The “Language
Directives” and “Scene Description Language” sections in the manual are
the
right starting point to catalog tokens and block forms.
povray
+1
Catalog reserved words & tokens from reservedwords.cpp, parser_tokenizer.cpp,
and the docs, then unit‑test the tokenizer’s behavior (number literals,
vectors <…>, strings, comments, include paths, version switches).
github
+1

2.2. Define clean internal representations
AST / IR: split the current “parse & build scene immediately” style into:

An AST for syntax (nodes for statements, object blocks, expressions).
A lowered scene IR (geometry, materials, transforms) created after macro
expansion and conditional evaluation.
The current parser interleaves semantic actions; refactoring to an AST enables
better error messages, tooling, and downstream transforms. (The docs describe
parsing → in‑memory scene; formalizing an intermediate stage is the
engineering step you add.)
deepwiki
Symbol table & evaluation model: SDL has macros and a function VM (user
functions) that run at parse‑time. You’ll want a dedicated evaluator that:

resolves identifiers, macro calls, arrays, functions,
controls directive flow (#if/#while/#read), and
emits deterministic side effects (file I/O guarded by policies).
The DeepWiki overview calls out the symbol table and function VM explicitly; a
clean evaluator boundary will keep the parser deterministic.
deepwiki
2.3. Build a modern front‑end
Choose an approach:

Regenerate using a parser generator (ANTLR, PEG) for maintainability, or
Hand‑written RD parser with tables for precedence/associativity (closest
to today; easiest to keep performance).
Either way, keep scanner/tokenizer modular (encoding, line/column tracking and
tokenizer error recovery are already separated in scanner.cpp /
parser_tokenizer.cpp).
deepwiki
+1
Error reporting: implement a diagnostic layer with:

multi‑line snippets and carets,
incremental recovery (skip to matching } / next directive),
versioned language switches (SDL has #version and command‑line Version=).
povray
+1
Compatibility shim: SDL is used in decades of content. Keep a legacy mode driven
by:

#version in scenes and Version=/+MV in INI/CLI,
behavior flags for older defaults (e.g., color/ambient defaults changed across
versions).
povray
2.4. Tooling & tests
Compliance corpus: scrape official docs’ examples and the tests/ directory; add
community scenes. Run golden‑image tests. The public docs and repo provide
the initial material.
povray
+1

Source mapping: carry filename/line/column for all AST nodes. Essential for IDEs
and better errors (and for a formatter).

Performance: measure with large include stacks; SDL allows many includes and
file I/O during parse. Keep I/O safe (opt‑in) and cache small includes
(similar to current library path search).
povray
+1

3) If you also want a “modernized SDL” (or an alternative syntax)
There are two distinct goals people conflate:

(A) Interchange format: a neutral way to feed scene data (no control flow) to
POV‑Ray.
(B) Full scripting language: everything SDL does today (macros, conditionals,
file I/O) but with a modern surface syntax.
A and B lead to very different choices.

3.1. For interchange (data‑only) scenes
If you only need declarative scene graphs—cameras, geometry, materials,
transforms—these are the strongest candidates:

JSON (or JSON5 / JSONC)

Pros: ubiquitous tooling; fast parsers; schemas (JSON Schema) to validate; easy
to generate from other apps.
Cons: no comments (plain JSON); expressions become strings; verbose for numeric
arrays unless compressed.
Fit: great as an IR serialization once expressions are resolved; pass
vectors/colors as arrays; include path lists as arrays.
Why suitable here: POV‑Ray already distinguishes parse‑time
evaluation from scene structures; JSON matches the post‑expansion IR.
deepwiki
YAML

Pros: comments; anchors/aliases for reuse; human‑friendlier than JSON for
big materials.
Cons: ambiguous edge cases; slower; indentation pitfalls; not ideal for large
numeric meshes.
Fit: comfortable authoring format if you want hand‑edited data; still
data‑only (no logic).
(You would still need an evaluator for expressions if you allowed them as
strings.)
TOML

Pros: simple, ini‑like; great for configs (global settings, render
options).
Cons: not geared toward deep nested geometry/material graphs.
Fit: super for render settings and library paths, less so for full scenes.
POV‑Ray already exposes many INI options for parsing and includes; TOML is
a natural successor for such settings.
povray
+1
glTF 2.0 (JSON + binary buffers)

Pros: industry standard for geometry/materials; supports PBR; efficient.
Cons: POV‑Ray’s material model and procedural textures differ from PBR;
cameras/lights differ; no SDL logic.
Fit: as an import path for meshes/materials; you still need a mapping to POV
textures/finishes.
XML

Pros: schemas (XSD), mature; good streaming.
Cons: verbose; falling out of favor for hand‑authoring; not better than
JSON/YAML here.
Fit: only if you need strict schemas and existing XML infra.
Takeaway: If you want a clean “data‑only” input, define a POV‑IR
schema (JSON) that matches the scene after macros/conditionals resolve. Use YAML
for authoring if desired; convert to JSON on ingest. This keeps the parser
rewrite focused on SDL → IR, while also enabling new non‑SDL inputs.
deepwiki

3.2. For a full scripting language (SDL replacement)
If you want to modernize the language itself—not just data—pure JSON/YAML
won’t
cut it; you need control flow, functions, modules, etc. Viable directions:

Keep SDL but tighten the grammar, add an official spec, and improve
diagnostics—lowest friction and maximum compatibility. (You can still add a
JSON‑IR input alongside.) The existing directive set is well documented
and widely used.
povray
+1
Embed a small, sandboxed language (e.g., Lua, WASM scriptlets) strictly for
compile‑time evaluation of parameters, not for geometry itself. The
current “function VM” conceptually does this already; an embedded VM would
formalize it.
deepwiki
Define a new PEG‑specified SDL‑2 with modules, namespacing, and
explicit expression evaluation semantics, plus a migration tool from legacy SDL.
(The GitHub repo, DeepWiki, and documentation provide the raw materials to write
a precise spec.)
github
+2
4) Minimal “shopping list” to actually do it
Language spec: EBNF/PEG, directive semantics, version gates. (Docs + reserved
words + source audit).
povray
+2
Tokenizer with thorough tests (numbers, vectors, strings, comments, encodings).
(Start from scanner.cpp / parser_tokenizer.cpp).
deepwiki
+1
AST for statements/expressions; evaluator for macros/conditions; IR scene graph.
(DeepWiki’s pipeline captures current responsibilities.)
deepwiki
Error/diagnostics with source mapping, recovery, and #version handling. (CLI/INI
version switches are already part of parsing options.)
povray
Compatibility mode + test corpus (docs examples + repo tests + community
scenes).
povray
+1
Optional: JSON‑IR loader and exporter; YAML authoring; glTF mesh/material
import.
5) A short ranked list of “top” formats to consider
If your goal is to update the SDL ecosystem with a clean data path, this is the
most practical mix:

JSON (or JSON5) for canonical POV‑IR (post‑macro scene) — fast,
unambiguous, schema‑friendly; ideal for tools, converters, CI.
deepwiki
YAML (authoring convenience) compiled to JSON‑IR at ingest —
human‑friendly with comments/anchors; accept only a curated subset to
avoid YAML gotchas.
TOML for render/parse configuration (what INI does today): library paths,
version flags, output settings. This aligns naturally with existing “Scene
Parsing Options”.
povray
+1
glTF as an import format for geometry/materials where PBR mapping is acceptable
(not a replacement for SDL materials).
JSON/YAML are not suitable to replace SDL’s macro/conditional features by
themselves; they are excellent to complement SDL with a modern, toolable data
format, while you keep—or gradually evolve—the scripting layer.

6) Suggested migration strategy
Phase 1: New tokenizer + error reporter plugged into today’s parser to improve
UX without semantics changes. (Drop‑in for
parser_tokenizer.cpp/scanner.cpp responsibilities.)
deepwiki
+1
Phase 2: AST + evaluator; keep emitting the current scene structures.
Phase 3: Add JSON‑IR input path. Start documenting the IR as the official
interface.
Phase 4: Consider SDL‑2 (PEG‑specified) or a sandboxed VM for
compile‑time logic; provide an auto‑formatter and linter.
Closing thought
Because SDL mixes data with control, the most maintainable path is to separate
concerns: a modern parser/evaluator for SDL (compatibility first), and a
data‑only IR (JSON) that tools can generate/consume. That gives you a
clear, testable core and lowers the cost of future surface‑syntax
experiments—all without breaking the long tail of existing scenes. The existing
code and documentation already delineate the pieces you need to formalize and
redesign.
github
+3

[Cousin Ricky] Re: Potential v4.0 bounding & clipping fixes / c... [171 days 1 hour and 39 minutes ago]

Mon, 20 Oct 2025 18:55:00 GMT

William F Pokorny <ano### [at] anonymousorg> wrote:
>
> Aside:
> ------
> In working on these updates I've run across more checking of the
> PATCH_OBJECT type. Reasonably sure I'm going to change patch-like
> objects now BASIC_OBJECT types to PATCH_OBJECT. My bet is this change
> will make for no functional changes beyond parser checks not allowing
> patch-like objects in certain operations where they should probably
> never have been allowed - like manual bounding.

Whatever you decide, be sure that plane remains available for bounding and
intersections.  I understand that plane gets special treatment in bounding
situations because it is so useful.

[Bald Eagle] Re: Potential v4.0 bounding & clipping fixes / c... [171 days 4 hours and 24 minutes ago]

Mon, 20 Oct 2025 16:10:00 GMT

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

> > In working on these updates I've run across more checking of the
> > PATCH_OBJECT type. Reasonably sure I'm going to change patch-like
> > objects now BASIC_OBJECT types to PATCH_OBJECT. My bet is this change
> > will make for no functional changes beyond parser checks not allowing
> > patch-like objects in certain operations where they should probably
> > never have been allowed - like manual bounding.

I do understand this.

However, let me just throw this out there for very long-term consideration.

After porting code from software packages like Mathematica, I find it
interesting the degree of flexibility their expressions have.

If there is a way that we can at the very least keep an eye on this potential, I
suggest that we do so.  Perhaps this may only be in code "stubs" or comments.

If something like a disc {} has an inside that POV-Ray can use under the hood,
then the user ought to have access to this as well.  And I would point out that
this may suggest changing the entire way that we approach defining and rendering
the shape.

Consider that I have a disc{}, and want to make future use of it in a way that
is not directly related to _rendering_ the disc.  I may want to do something
like illuminate the space above it with media.  It would be useful to be able to
bound the space above it.

Presumably the disc has an "inside" that is the cylindrical region below it in
the half-plane.  I ought to be able to easily make use of that.  And limit it
with a distance along that normal axis.  As well as the space above it
(trivially done with scale -Normal).  But then also have the disc {inverse} work
as well.

Maybe I want to align a thing with the disc.
Or limit something to with its radius.
or cut a hole in the ceiling above it.
or project it onto an axis or a plane.

It would be nice to be able to "expand" that disc into a cylinder {} of some
sort.  Or a line segment of its projection.
We can either do that with the native shape, or we can add tools to make this
data available in some other form.   I have suggested that we have a point{}
"shape", and being able to union {} those into a line segment would a useful
thing as well.  Because at present we have no way to (easily) apply translate,
rotate, and scale to such constructs.

We have the things - which are imperfectly and incompletely implemented,
but what I'd argue that we need are the tools to better make use of them in a
simple, nimble manner that doesn't require new, average, or even experienced
users to take a course in linear algebra, calculus, or spend 3 hours trying to
to come up with the proper search terms and find valid, relevant, comprehensible
results so that they can accomplish a conceptually simple geometric task.

So, I take no issue with simplification - as a first step towards straightening
out the code base.  However I'm a strong proponent of developing things in such
a manner that they can be expanded upon and used for more than the simplest and
most limited of purposes.

- BW

If we adopt the cylinder shape that I speculate about in the other thread, then
perhaps the end caps can define the entire shape.
We would have two surface normals and two radii, and so would be able to have
cylinders, cones, and not trigger a degenerate cylinder error.

As always, much to think about.

[William F Pokorny] Re: Potential v4.0 bounding & clipping fixes / c... [171 days 11 hours and 5 minutes ago]

Mon, 20 Oct 2025 09:28:40 GMT

On 10/13/25 21:37, William F Pokorny wrote:
> Aside:
> ------
> In working on these updates I've run across more checking of the 
> PATCH_OBJECT type. Reasonably sure I'm going to change patch-like 
> objects now BASIC_OBJECT types to PATCH_OBJECT. My bet is this change 
> will make for no functional changes beyond parser checks not allowing 
> patch-like objects in certain operations where they should probably 
> never have been allowed - like manual bounding.

I've adopted this change for R20 of yuqk.

---

I'm also attaching an image and the test scene I used to produce the sub 
images in it. Demonstrating a few ideas previously mentioned.

1) Creating a inside region (no-surfaces) object{} using clipped_by{} 
and going on to use that region to create 'cap surface shapes' and 'side 
surface shapes' all in SDL. Upper left.

2) The union of both surface shapes in (1) can be used over a slower 
merge{} where clean dual surface intersections are necessary for 
features like media (lower left).

3) As mentioned previously: The clipped_by{} object modifier uses shape 
inside test(s). The inside test for isosurface shapes is fast - and very 
well defined (upper right).

4) Using (3), demonstrating the creation of fragmented surfaces using a 
mod() like function in the isosurface{} used in as the clipped_by{} 
object against the target Int00 side surfaces shape (lower right).

Bill P.

[Bald Eagle] Prototype c++ for cone / cylinder [174 days 23 hours and 24 minutes ago]

Thu, 16 Oct 2025 21:10:00 GMT

Maybe we can test this to see how it performs vs what we're using now.

-BE

#include <Eigen/Dense>
#include <cmath>
#include <limits>

using namespace Eigen;

bool intersectCylinderWithCaps(
    const Vector3d& rayOrigin,
    const Vector3d& rayDir,     // Assumed normalized
    const Vector3d& cylBase,
    const Vector3d& cylAxis,    // Assumed normalized
    double radius,
    double height,
    double& tIn,
    double& tOut)
{
    Vector3d RC = rayOrigin - cylBase;
    Vector3d n = rayDir.cross(cylAxis);
    double ln = n.norm();

    bool hit = false;
    tIn = std::numeric_limits<double>::infinity();
    tOut = -std::numeric_limits<double>::infinity();

    // Side intersection
    if (ln > 1e-8) {
        n.normalize();
        double d = std::abs(RC.dot(n));
        if (d <= radius) {
            Vector3d O = RC.cross(cylAxis);
            double t = -O.dot(n) / ln;

            O = n.cross(cylAxis);
            O.normalize();
            double s = std::sqrt(radius * radius - d * d) / rayDir.dot(O);

            double t1 = t - s;
            double t2 = t + s;

            // Check if points are within cylinder height
            Vector3d p1 = rayOrigin + t1 * rayDir;
            Vector3d p2 = rayOrigin + t2 * rayDir;

            double h1 = (p1 - cylBase).dot(cylAxis);
            double h2 = (p2 - cylBase).dot(cylAxis);

            if (h1 >= 0 && h1 <= height) {
                tIn = std::min(tIn, t1);
                hit = true;
            }
            if (h2 >= 0 && h2 <= height) {
                tOut = std::max(tOut, t2);
                hit = true;
            }
        }
    }

    // Cap intersection
    for (int i = 0; i < 2; ++i) {
        double capZ = (i == 0) ? 0.0 : height;
        Vector3d capCenter = cylBase + cylAxis * capZ;
        double denom = rayDir.dot(cylAxis);

        if (std::abs(denom) > 1e-8) {
            double tCap = (capCenter - rayOrigin).dot(cylAxis) / denom;
            if (tCap >= 0) {
                Vector3d pCap = rayOrigin + tCap * rayDir;
                Vector3d v = pCap - capCenter;
                v -= cylAxis * v.dot(cylAxis); // Project onto cap plane
                if (v.norm() <= radius) {
                    tIn = std::min(tIn, tCap);
                    tOut = std::max(tOut, tCap);
                    hit = true;
                }
            }
        }
    }

    return hit;
}








#include <Eigen/Dense>
#include <cmath>
#include <limits>

using namespace Eigen;

bool intersectCone(
    const Vector3d& rayOrigin,
    const Vector3d& rayDir,     // Assumed normalized
    const Vector3d& coneBase,
    const Vector3d& coneAxis,   // Assumed normalized
    double baseRadius,
    double height,
    double& tIn,
    double& tOut)
{
    Vector3d apex = coneBase + coneAxis * height;
    Vector3d RC = rayOrigin - apex;

    double k = baseRadius / height;
    double k2 = k * k;

    // Project ray and cone axis
    double DdotA = rayDir.dot(coneAxis);
    double PdotA = RC.dot(coneAxis);

    Vector3d Dperp = rayDir - DdotA * coneAxis;
    Vector3d Pperp = RC - PdotA * coneAxis;

    double a = Dperp.dot(Dperp) - k2 * DdotA * DdotA;
    double b = 2 * (Dperp.dot(Pperp) - k2 * DdotA * PdotA);
    double c = Pperp.dot(Pperp) - k2 * PdotA * PdotA;

    double discriminant = b * b - 4 * a * c;
    bool hit = false;
    tIn = std::numeric_limits<double>::infinity();
    tOut = -std::numeric_limits<double>::infinity();

    if (std::abs(a) > 1e-8 && discriminant >= 0.0) {
        double sqrtDisc = std::sqrt(discriminant);
        double t1 = (-b - sqrtDisc) / (2 * a);
        double t2 = (-b + sqrtDisc) / (2 * a);

        for (double t : {t1, t2}) {
            if (t >= 0.0) {
                Vector3d p = rayOrigin + t * rayDir;
                double h = (p - coneBase).dot(coneAxis);
                if (h >= 0.0 && h <= height) {
                    tIn = std::min(tIn, t);
                    tOut = std::max(tOut, t);
                    hit = true;
                }
            }
        }
    }

    // Cap intersection (base only)
    double denom = rayDir.dot(coneAxis);
    if (std::abs(denom) > 1e-8) {
        double tCap = (coneBase - rayOrigin).dot(coneAxis) / denom;
        if (tCap >= 0.0) {
            Vector3d pCap = rayOrigin + tCap * rayDir;
            Vector3d v = pCap - coneBase;
            v -= coneAxis * v.dot(coneAxis); // Project onto base plane
            if (v.norm() <= baseRadius) {
                tIn = std::min(tIn, tCap);
                tOut = std::max(tOut, tCap);
                hit = true;
            }
        }
    }

    return hit;
}

[William F Pokorny] Re: Potential v4.0 bounding & clipping fixes / c... [177 days 18 hours and 53 minutes ago]

Tue, 14 Oct 2025 01:41:03 GMT

On 10/13/25 21:37, William F Pokorny wrote:
> For clipped_by{} the modes are:

Attached a couple images showing modes 2 and 3 of clipped_by{}.

The core SDL looking like:

#declare OO = object {
     sphere { 0, 0.5
         texture          { pigment {Green} normal { micro 0.5 } }
         interior_texture { pigment {Red}   normal { micro 0.5 } }
     }
     bounded_by { mode 1
                  sphere { <+0.3,+0.0,+0.0>, 0.25 }
                  sphere { <-0.3,+0.0,+0.0>, 0.25 }
                  sphere { <+0.0,+0.3,+0.0>, 0.25 }
                  sphere { <+0.0,-0.3,+0.0>, 0.25 }
                  sphere { <+0.0,+0.0,+0.3>, 0.25 }
                  sphere { <+0.0,+0.0,-0.3>, 0.25 }
     }
     clipped_by { mode 3
                  sphere { <+0.3,+0.0,+0.0>, 0.25 }
                  sphere { <-0.3,+0.0,+0.0>, 0.25 }
                  sphere { <+0.0,+0.3,+0.0>, 0.25 }
                  sphere { <+0.0,-0.3,+0.0>, 0.25 }
                  sphere { <+0.0,+0.0,+0.3>, 0.25 }
                  sphere { <+0.0,+0.0,-0.3>, 0.25 }
     }
     // Or: clipped_by { mode 3 bounded_by }
}

Bill P.

[William F Pokorny] Potential v4.0 bounding & clipping fixes / chang... [177 days 18 hours and 56 minutes ago]

Tue, 14 Oct 2025 01:37:41 GMT

In the last week plus I've implemented what I think is likely better 
bounded_by{} and clipped_by{} implementations when manually bounding / 
clipping.

It's been the case, since at least v3.7, that both bounded_by{} and 
clipped_by{} accept multiple shapes / objects. For example, we can code:

     #declare Iso00 = isosurface {...}
     #declare Obj00 = object {
         Iso00
         bounded_by { sphere { <+0.3,+0.0,+0.0>, 0.25 }
                      sphere { <-0.3,+0.0,+0.0>, 0.25 }
                      sphere { <+0.0,+0.3,+0.0>, 0.25 }
                      sphere { <+0.0,-0.3,+0.0>, 0.25 }
                      sphere { <+0.0,+0.0,+0.3>, 0.25 }
                      sphere { <+0.0,+0.0,-0.3>, 0.25 }
         }
     }

// ----------- or

     #declare Iso00 = isosurface {...}
     #declare Obj00 = object {
         Iso00
         bounded_by { sphere { <+0.3,+0.0,+0.0>, 0.25 } }
         bounded_by { sphere { <-0.3,+0.0,+0.0>, 0.25 } }
         bounded_by { sphere { <+0.0,+0.3,+0.0>, 0.25 } }
         bounded_by { sphere { <+0.0,-0.3,+0.0>, 0.25 } }
         bounded_by { sphere { <+0.0,+0.0,+0.3>, 0.25 } }
         bounded_by { sphere { <+0.0,+0.0,-0.3>, 0.25 } }
         // Multiple bounded_by{} blocks parse more slowly than above.
     }

I don't believe there is any documentation for this functionality and I 
don't recall any, intentional, use of multiple shapes in code I've seen. 
A reason is likely that today multiple shape implementations effectively 
do an intersection of inside regions and that limits the usefulness - as 
do other bounding issues in v3.7/v3.8 fixed in the yuqk fork.

What I'm doing for the next release of yuqk (R20) is adding an optional 
'mode' keyword to both bounded_by{} and clipped_by{} which must appear 
before the first shape / object.

For bounded_by{} the modes are:

     0 : intersection. (Traditional behavior)
         ray hits or inside all shapes (POV-Ray v3.7+ default)

     1 : union / any.
         ray hits or inside at least one of the shapes

For clipped_by{} the modes are:

     0 : intersection. (Traditional behavior)
         ray->surface intersection inside all shapes
         (POV-Ray v3.7+ default)

     1 : intersection inverse.
         ray->surface intersection outside (0)

     2 : any.
         ray->surface intersection inside at least one shape

     3 : any inverse.
         ray->surface intersection outside all shapes

The thought with 'mode 1' of bounded_by{} is that by using multiple 
shapes we can sometimes more accurately bound expensive shapes 
(isosurface{}s, parameteric{}s, sphere_sweep{}s, etc.) with multiple 
simple / fast shapes. In play using multiple sphere{}s to manually bound 
cone{}s/cylinder{}s, this idea works(*), but always at a loss in 
performance (10-25%) when the target shapes/objects are completely bounded.

(*) - The target shape's solvers run much less and the sphere's code 
more, but it looks like where the target is simple, (or the shape itself 
has good internal bounding), multiple bounding is likely not a 
performance win for the entire shape.

Attaching a couple images and the scene used to generate them. In both 
images, starting in the upper left and moving clockwise are: union{}, 
merge{}, intersection{} and difference{} results from the two 
bounded_by{} and clipped_by{} spheres. One showing results with 
coincident surfaces and the second where one result is expanded slightly 
to eliminate the coincident result.

I find all the results interesting and potentially useful, but we'll 
see. I'm new too, to what we might be able to do with the extended features.

Bill P.


Aside:
------
In working on these updates I've run across more checking of the 
PATCH_OBJECT type. Reasonably sure I'm going to change patch-like 
objects now BASIC_OBJECT types to PATCH_OBJECT. My bet is this change 
will make for no functional changes beyond parser checks not allowing 
patch-like objects in certain operations where they should probably 
never have been allowed - like manual bounding.

[Bald Eagle] Re: Suggest v4.0 sor{} fixes / changes. (yuqk R2... [196 days 4 hours and 39 minutes ago]

Thu, 25 Sep 2025 15:55:00 GMT

So I was trying to model an elegantly curved shape as a sor {}, and I noticed
that it was turning out pretty clunky.

And so one thing that I would recommend be added to the documentation is the
fact that a big difference between the sor {} and the lathe {} is the type of
splines used.

Catmull-Rom is an interpolation spline, and so probably needs a large number of
very exact control points to accurately mimic a smooth curve.

Whereas the cubic polynomial splines in the lathe are approximation splines,
which give a much smoother, "organic" curve.

The challenge there, is that the spline only passes through the endpoints of a
spline segment, and so accurately modeling any given curve is more challenging,
because one has to guess or do a lot of calculations to determine the proper
positioning of the inner control points.

Also, if one wants to model a glass, vase, bottle, or some other hollow shape
that has a given wall thickness, then that's something that can be done directly
with the lathe, rather than having to use CSG to subtract away the inside of the
"solid" sor.

- BW

[Bald Eagle] Re: Suggest v4.0 sor{} fixes / changes. (yuqk R2... [196 days 4 hours and 49 minutes ago]

Thu, 25 Sep 2025 15:45:00 GMT

"ingo" <nomail@nomail> wrote:

Very nice and concise explanation.  :)

> Any one ever peeked at the code of OpenScad? They have this or similar
> routinely,

I may have - ages ago.
If you USE OpenScad, you'll notice, IIRC, that you have to provide a sort of
step value for these things, which makes me think they just have a brute-force
iteration thing going on.

OpenScad is SO similar to POV-Ray that I often wonder if it's a forked
development project.  "POV-Ray for 3D printing"

[jr] Re: Suggest v4.0 sor{} fixes / changes. (yuqk R2... [198 days 2 hours and 9 minutes ago]

Tue, 23 Sep 2025 18:25:00 GMT

hi,

William F Pokorny <ano### [at] anonymousorg> wrote:
> On 9/22/25 13:44, jr wrote:
> >> ...
> > I'd hoped ... for some "evidence-based" words.
>
> First, let me say I don't really know what you are after. :-)

well, confidentially, that makes two of us.  </grin>


> And, Bill W, I saw your recent post responding to jr's post.

replied to below.


> which introduces a couple concepts. Those two concepts don't map
> directly to anything in the code - though users (including me) commonly
> use those terms(*).
>
> In the code we do track patch objects / shapes in the base object class
> with a flags integer for which the bit used is PATCH_OBJECT. The
> PATCH_OBJECT bit being on, when initially constructed, essentially means
> the shape does not, start, with an inside test which can return true.
>
> Patch class shapes are derived from a helper class called NonsolidObject
> which inherits from the base object class. That helper class currently
> sets an integer value that maps directly to the particular patch type.
> The additional information is never used that I see. Despite the class
> name it is way to track the patch type (TypeOfPatchObject would be a
> better class name I think, but, I lean toward it being deleted from the
> class hierarchy).
>
> Strictly speaking, all we have inside the ray tracer are ray-surface
> intersections. We can link functionality to those surfaces - that's
> it(**). Bill W, I agree shapes can situationally, appear to be solid,
> but it's always conditional in POV-Ray(***).

thank you, very much.  like BW I get much from your explanations; the 'aside's
often offer even "better value for money" :-).

> ...
> (***) - See attached image. Is the sphere solid in this situation? Code
> used:

what a teaser..  :-)

on the 'sor{}'.  I've decided to be "guided by" the 'open' keyword.  that is
accept that it can be described solid while "capped", but for documentation
purposes keep the current moniker; when that page gets updated (along with the
tutorial), we can add (maybe under "Finite Solid Primitives" ?) a sentence or
two on the "difficulties" finding defining words.


> > ... required "infrastructure" ...
> No. As Bill W suggested there might be some brute force ways to approach
> it. Where we have value field defined shapes, it should be we could come
> up with optimizations. Whether we could ever get to something which
> would work well enough for on the fly ray-surface intersections, I'm not
> sure.
> Mechanical engineers surely have software which can determine the
> rotational volume required for 3D things - whether any methods are fast
> enough to run real time (without massive parallelism) I have doubts, but
> who knows. I've not dug.

"on the fly" ?  </grin>  thanks though, I now think that, while we wait for a
new POV-Ray development and or the heat death of the universe, a macro will have
to do to simulate the "sweeping".



@Bald Eagle

> So you're using language to describe something that can simultaneously have two
fundamentally different attributes.

agree, the (English) language gets in the way.  we'll (need to) add a
"clarifying" paragraph.


> If it looks solid, and acts solid, then I would imagine that we could agree that
> it was solid.  If we need to specify "open" to make it (non-keyword) hollow,
> then what was it before we changed it to hollow?

"solid" argument :-).  see above.


> "If there are n points we will have n-3 segments."

_hiding_ in all that "formula stuff", thanks for the reference.


regards ,jr.

[ingo] Re: Suggest v4.0 sor{} fixes / changes. (yuqk R2... [198 days 2 hours and 49 minutes ago]

Tue, 23 Sep 2025 17:45:00 GMT

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

> I have looked into signed distance functions of meshes, and people have worked
> out how to do that, so it may very likely be possible.
>

first you'd have to make sure the winding per triangle/polygon is consisten
cw/ccw.

then you can look at the "general winding number" to find wheter inside or
outside the mesh and to find whether the mesh is closed.

If winding number is 1, inside mesh, else if 0 outside mesh, else mesh not
closed
The winding number should be consisten for all polygons, else the mesh is not
closed.

This can then turned into a signed distance value / field (SDF): distance = + /
- distance] negative distance = inside.

triangle [v1, v2, v3]
p = test point
a = v1 - p
b = v2 - p
c = v3 - p
num = dot(a, cross(b, c)) (the scalar triple product)
den = |a||b||c| + dot(a,b)*|c| + dot(b,c)*|a| + dot(c,a)*|b|
omega_triangle = 2 * atan2(num, den )
omega_mesh = sum(omega_triangle)
generalised winding number = omega_mesh / 4*PI

if you're shure th mesh is closed you can fall back to trace and count
intersections to determine inside/outside.

Any one ever peeked at the code of OpenScad? They have this or similar
routinely,

ingo

[Bald Eagle] Re: Suggest v4.0 sor{} fixes / changes. (yuqk R2... [198 days 6 hours and 44 minutes ago]

Tue, 23 Sep 2025 13:50:00 GMT

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

> > sorry, still "no good".  I'd hoped for something along the lines "reading the
> > code at ...", that is for some "evidence-based" words.
>
> First, let me say I don't really know what you are after. :-) And, Bill
> W, I saw your recent post responding to jr's post.

I think he was under the impression that there was some definitive code fragment
that would unambiguously establish the solidness of a primitive.

> We have in our documentation:
>
> https://wiki.povray.org/content/Reference:Interior#Empty_and_Solid_Objects
>
> which introduces a couple concepts. Those two concepts don't map
> directly to anything in the code - though users (including me) commonly
> use those terms(*).

Nice.  With regard to sor:  "By default all objects are assumed to be solid."
:P

"You should be aware that solid objects are conceptual things. If you clip away
parts of the sphere you will clearly see that the interior is empty and it just
has a very thin surface.

This is not contrary to the concept of a solid object used in POV-Ray. It is
assumed that all space inside the sphere is covered by the sphere's interior."

So, I'd say that we either have:
misleading documentation - with regard to the terminology used and the
implication of words
Code that needs to be rewritten to better represent objects to meet user
expectations
buggy code

or just a whole pile of things that collectively are "POV-Ray" and need to be
better hashed-out and better organized to more accurately represent what's going
on.   That's just the nature of an open source project that has organically
grown over the past 30 years.

> In the code we do track patch objects / shapes in the base object class
> with a flags integer for which the bit used is PATCH_OBJECT. The
> PATCH_OBJECT bit being on, when initially constructed, essentially means
> the shape does not, start, with an inside test which can return true.
>
> Patch class shapes are derived from a helper class called NonsolidObject
> which inherits from the base object class. That helper class currently
> sets an integer value that maps directly to the particular patch type.
> The additional information is never used that I see. Despite the class
> name it is way to track the patch type (TypeOfPatchObject would be a
> better class name I think, but, I lean toward it being deleted from the
> class hierarchy).

As I get deeper into these things, it's very helpful to read this kind of
brass-tacks explanation.

> Strictly speaking, all we have inside the ray tracer are ray-surface
> intersections. We can link functionality to those surfaces - that's
> it(**).

Mmmmmm - I think we have at least a little more than that.
We can conduct insidedness tests without actually raytracing anything, and
probably a few more things that I can't bring to mind atm.

> Bill W, I agree shapes can situationally, appear to be solid,
> but it's always conditional in POV-Ray(***).

Yes, but I'm trying to not step into the trap of incomplete / poorly implemented
 code, or code that has bugs that haven't yet been rooted out.
I'd like to approach these things from "what ought to be the case" in some sort
of "this is what other mature, production raytracing/rendering packages do / are
capable of" with some form of formal Boolean logical result.

> We have disc{} and height_field{} which are arguably patch objects that
> are not because someone created inside test code that can return true.
> With the height_field that inside test can be adjusted using water_level.

Aye, but I make a distinction in those cases - because
1. we have a convention for things like planes and discs where one side is
"inside" and the other side is "outside".  It's not unexpected that how a plane
works got extended to a circular subset of a plane - a disc.
and
2. we can conceptually extend/project the edges of a heightfield onto a plane,
which provides the boundaries for making the object solid.   What was once
hollow is now solid, because the user invoked a special keyword.
Just like when a user takes a solid of revolution which is assumed to be solid,
and makes it hollow by invoking the open keyword.  {zing!} :D

> We have mesh{} and mesh2{} which start as patch objects, but that status
> bit is cleared on seeing inside_vector.

Which makes sense, because it's only a small conceptual jump between having an
inflatable Stanford Bunny, and a solid one.

> We can effectively corrupt (or turn off) the inside test with many
> shapes by collapsing one dimension of the shape as with box {
> <-1,-1,0>,<1,1,0>}.

Yes - and I'm sure that if we closely analyzed what we are doing in source, and
what the meaning of our return values from the c++ functions are, then we might
discover that there are better ways to conceptually represent what we are doing,
which would allow us to straighten a lot of these funny things out.
I have a feeling that that would be a lot like how we deal with things like
i=sqrt(-1), pow (0, 0), representing 4th dimensional objects, etc.

It might not have made much sense at one time, but math matured.
There may have been more limited examples that initially got developed, but like
splines, more general forms were worked out that allow a broader range of things
to be represented by a single more general form.

And I think I would like to see a more general form for a lot of our primitives.
   That doesn't exclude us having more nimble single-purpose primitives for
speed and efficiency, but I think we would be well served to try and
conceptualize all of our shapes so that they can all be described by similar
attributes, data structures, and raytracing algorithms.
We have a lot of redundant code in the code base.

> We can perform CSG with patch objects so long as another shape in the
> CSG has a inside test which returns true in a way that covers at least
> part of the patch object's surface. The result has no effective inside
> test where it is later used in CSG.

Hmmm.  That would be an interesting case to render as an example.

> Where we have or 'intersect' / 'and' regions where inside tests are
> true, but the originating surfaces for the inside test are not in scope,
> nothing shows up unless we stick other surface(s) into that region.

I'll have to a lot of thinking on that one to understand what you mean.

> Code wise nothing stops us from:
>
> - Defining an inside test which can return true for existing patch
> objects where today the inside test always returns false.

Probably.   It's just that no one ever got around to writing the inside ()
function for that primitive.

> - Implementing functionality which twiddles with the behavior of the
> inside test for effects / modified CSG results.

I'm sure that there's all sorts of interesting tricks one can play with that!
:)

> - Adding a shape option which forces an existing inside test sometimes
> returning true to always return false - 'inside off', perhaps.

I would say that now we're deep into the details of the primitives and the
consequences of how they are evaluated, then we should begin compiling a list of
better terminology.

Having said that, something like no_inside would probably fit better with
current SDL keyword forms.

> (***) - See attached image. Is the sphere solid in this situation? Code
> used:

And here I was still thinking that Tekno Franansia was the Evil Supergenius!
Master Pokorny is a tricksy little hobbit, yes, yes, very tricksy, my Precious.

> ...
> #declare Sphere00 = sphere {
>      0, 0.7
>      texture { pigment { White } finish { ambient 0.02 } }
>      interior_texture {
>          pigment { rgb <1,0,1> }
>          finish { ambient 0.02 }
>      }
> }
> #declare Cyl00 = cylinder { 0.0, <1,1,-1>, 1 open }
>
> difference {
>      object { Sphere00 }
>      object { Cyl00 }
>      cutaway_textures
> }

Now, I would have to say that in this instance it seems that this might just be
the result of buggy code, because we have not formally worked out what the
"proper" CSG result ought to be, and made our code consistent with that.

Still - a very clever and unexpected result!

> > and agree that sweeping (whole) objects sounds like a cool/fun thing; does the
> > required "infrastructure" exist already (in part, at least) ?
>
> No. As Bill W suggested there might be some brute force ways to approach
> it. Where we have value field defined shapes, it should be we could come
> up with optimizations. Whether we could ever get to something which
> would work well enough for on the fly ray-surface intersections, I'm not
> sure.

I think we could - it would just a project of its own.
I have looked into signed distance functions of meshes, and people have worked
out how to do that, so it may very likely be possible.

> Mechanical engineers surely have software which can determine the
> rotational volume required for 3D things - whether any methods are fast
> enough to run real time (without massive parallelism) I have doubts, but
> who knows. I've not dug.

I would guess that those are either triangle-based (FEM) or some other similar
numerical method.

Once again I will briefly reiterate the need for some sort of editable to-do
list, program management software, or other means of logging ideas, references,
proofs of concept, partial or naive implementations in SDL, c++ or other
languages, etc.

Experiments that languish on my hard drive don't do the development of POV-Ray
any good.  Adding them to a collection of ideas, references, and functional code
would.

- BW

[William F Pokorny] Re: Suggest v4.0 sor{} fixes / changes. (yuqk R2... [198 days 14 hours and 43 minutes ago]

Tue, 23 Sep 2025 05:51:22 GMT

On 9/22/25 13:44, jr wrote:
>> ...
>> With respect to Bill W's suggestion that the sor acronym assignment
>> /alignment be changed to "solid of revolution", it just hits me as
>> wrong.
> sorry, still "no good".  I'd hoped for something along the lines "reading the
> code at ...", that is for some "evidence-based" words.

First, let me say I don't really know what you are after. :-) And, Bill 
W, I saw your recent post responding to jr's post.

We have in our documentation:

https://wiki.povray.org/content/Reference:Interior#Empty_and_Solid_Objects

which introduces a couple concepts. Those two concepts don't map 
directly to anything in the code - though users (including me) commonly 
use those terms(*).

In the code we do track patch objects / shapes in the base object class 
with a flags integer for which the bit used is PATCH_OBJECT. The 
PATCH_OBJECT bit being on, when initially constructed, essentially means 
the shape does not, start, with an inside test which can return true.

Patch class shapes are derived from a helper class called NonsolidObject 
which inherits from the base object class. That helper class currently 
sets an integer value that maps directly to the particular patch type. 
The additional information is never used that I see. Despite the class 
name it is way to track the patch type (TypeOfPatchObject would be a 
better class name I think, but, I lean toward it being deleted from the 
class hierarchy).

Strictly speaking, all we have inside the ray tracer are ray-surface 
intersections. We can link functionality to those surfaces - that's 
it(**). Bill W, I agree shapes can situationally, appear to be solid, 
but it's always conditional in POV-Ray(***).

---

We have disc{} and height_field{} which are arguably patch objects that 
are not because someone created inside test code that can return true. 
With the height_field that inside test can be adjusted using water_level.

We have mesh{} and mesh2{} which start as patch objects, but that status 
bit is cleared on seeing inside_vector.

We can effectively corrupt (or turn off) the inside test with many 
shapes by collapsing one dimension of the shape as with box { 
<-1,-1,0>,<1,1,0>}.

We can perform CSG with patch objects so long as another shape in the 
CSG has a inside test which returns true in a way that covers at least 
part of the patch object's surface. The result has no effective inside 
test where it is later used in CSG.

Where we have or 'intersect' / 'and' regions where inside tests are 
true, but the originating surfaces for the inside test are not in scope, 
nothing shows up unless we stick other surface(s) into that region.

---

Code wise nothing stops us from:

- Defining an inside test which can return true for existing patch 
objects where today the inside test always returns false.

- Implementing functionality which twiddles with the behavior of the 
inside test for effects / modified CSG results.

- Adding a shape option which forces an existing inside test sometimes 
returning true to always return false - 'inside off', perhaps.

(*) - Yes, there is too "Constructive Solid Geometry (CSG)." While 
'Solid' there might-have-been / may-still-be a decent choice, it is not 
completely accurate in the context of ray tracing.

(**) - Yeh, I'm lying a little. Media, for example, doesn't require any 
container, but it does require a terminating ray-surface intersection to 
be rendered. Fog is similar. Somewhere, for ray traced features, there 
is at least one effective surface. A feature might not be originally 
linked to a surface, but be work accomplished after the ray-surface 
intersection is determined - or faked (sky_sphere).

(***) - See attached image. Is the sphere solid in this situation? Code 
used:

...
#declare Sphere00 = sphere {
     0, 0.7
     texture { pigment { White } finish { ambient 0.02 } }
     interior_texture {
         pigment { rgb <1,0,1> }
         finish { ambient 0.02 }
     }
}
#declare Cyl00 = cylinder { 0.0, <1,1,-1>, 1 open }

difference {
     object { Sphere00 }
     object { Cyl00 }
     cutaway_textures
}
...

> 
> and agree that sweeping (whole) objects sounds like a cool/fun thing; does the
> required "infrastructure" exist already (in part, at least) ?

No. As Bill W suggested there might be some brute force ways to approach 
it. Where we have value field defined shapes, it should be we could come 
up with optimizations. Whether we could ever get to something which 
would work well enough for on the fly ray-surface intersections, I'm not 
sure.

Mechanical engineers surely have software which can determine the 
rotational volume required for 3D things - whether any methods are fast 
enough to run real time (without massive parallelism) I have doubts, but 
who knows. I've not dug.

Bill P.

[Bald Eagle] Re: Suggest v4.0 sor{} fixes / changes. (yuqk R2... [199 days 1 hour and 4 minutes ago]

Mon, 22 Sep 2025 19:30:00 GMT

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

> thanks.  I'd better wait for the next yuqk release, I don't think I'm ready for
> an answer to "three less ?" </grin>

https://wiki.povray.org/content/Reference:Surface_of_Revolution
"If there are n points we will have n-3 segments."

> I like the "can fill with" definition, feels "intuitive".

I hate it.   Because it is so very, very misleading.
Primarily because we can use SOLID objects as containers for media but still use
them in CSG.

So you're using language to describe something that can simultaneously have two
fundamentally different attributes.

There needs to be a checklist.
There also likely needs to be a reclassification of primitives.

Just going off the top of my head:
We have surfaces - and some may have an inside/outside whereas others may simply
have a normal vector/direction.
We have some objects that _can_ be closed (parametric) but might not be.  It
would great if the closed shape could be solid, but I'm not sure if there's a
way to always reliably determine if the parametric equations form a closed
shape.
As Jerome Grimbert quite properly pointed out when I was working on calculating
surface normals - the Mobius strip really throws a wrench into the works.

Then we have things that in my opinion ought to be fully solid, but for various
code limitations and unimplemented algorithms/features - aren't fully solid.
They're mostly solid.   This might be the case with sor {}
The point being, that we ought to have an explicit means of documenting in what
cases the object acts as a solid, and in what cases it doesn't (and why).
Because there's no reason the sor {} shouldn't be fully solid - since I can't at
the moment envision a case where the un-open sor would have to be hollow.

I think that the lathe - with the ability to intersect itself - might be tricky,
and should properly use the same crossing-number as the polygon to determine if
that section is inside or outside.

> > With respect to Bill W's suggestion that the sor acronym assignment
> > /alignment be changed to "solid of revolution", it just hits me as
> > wrong.
>
> sorry, still "no good".  I'd hoped for something along the lines "reading the
> code at ...", that is for some "evidence-based" words.

If it looks solid, and acts solid, then I would imagine that we could agree that
it was solid.  If we need to specify "open" to make it (non-keyword) hollow,
then what was it before we changed it to hollow?

> and agree that sweeping (whole) objects sounds like a cool/fun thing; does the
> required "infrastructure" exist already (in part, at least) ?

In a sense, yes.   The lathe sweeps a spline, or, if you consider the closed
spline a polygon - a 2D shape, then we already have that.   Anything that
projects outside of the 2D plane of the spline's control polygon is redundant
(it gets embedded inside the swept volume) and doesn't appear (assuming it's
smaller than the projected cross section).

If we're talking about "actually" revolving the whole solid object around an
axis and getting the swept volume as an object - I suppose one could project the
3D object onto a plane and get the maximal cross-sectional representation to
sweep (or just scale the object very small in one dimension), and it would have
flat start and end "caps".
If you wanted the 3D shape to define the ends of the swept volume, you could
instantiate the object at the start and end points to make the object bulge out
the ends.

Presumably we could write a simple macro to take that scaled object and
instantiate it around a circle using a loop in a union {}, and connect 2
instances of the 3D object.   Just like many people do with a union of spheres
and cylinders to make a substitute sphere-sweep.

There's likely a clever (and slightly painful) way to do it with an isosurface
and the object pattern.

Lots of interesting things to think about and experiment with.

- bw

[jr] Re: Suggest v4.0 sor{} fixes / changes. (yuqk R2... [199 days 2 hours and 49 minutes ago]

Mon, 22 Sep 2025 17:45:00 GMT

hi,

William F Pokorny <ano### [at] anonymousorg> wrote:
> On 9/21/25 13:44, jr wrote:
> > v confusing. ...
> Documentation needs to be created. :-) A quick answer is that the number
> of spline-segments for the sor{} is always 3 less than the number of
> points specified. The length of the boolean bit string for control over
> all spline-segments is therefore (8-3).

thanks.  I'd better wait for the next yuqk release, I don't think I'm ready for
an answer to "three less ?" </grin>

> ...
> Depends on stuff - and for the keyword 'hollow' there is a pile of stuff
> I know, I don't know. I've never done a deep dive on how the setting
> cascades throughout the code. There is some weirdness with how it works
> and, IIRC, Alain pointed out one of those in the last year or two for
> some situation where adding 'hollow' magically fixed things.
> The keyword 'hollow' means something closer to "You can stick media in
> this object" - except where it doesn't.

I like the "can fill with" definition, feels "intuitive".

> ...
> With respect to Bill W's suggestion that the sor acronym assignment
> /alignment be changed to "solid of revolution", it just hits me as
> wrong.

sorry, still "no good".  I'd hoped for something along the lines "reading the
code at ...", that is for some "evidence-based" words.

and agree that sweeping (whole) objects sounds like a cool/fun thing; does the
required "infrastructure" exist already (in part, at least) ?

regards, jr.

[William F Pokorny] Re: Suggest v4.0 sor{} fixes / changes. (yuqk R2... [199 days 20 hours and 29 minutes ago]

Mon, 22 Sep 2025 00:04:53 GMT

On 9/21/25 18:34, William F Pokorny wrote:
> when fully rotated about one more axes(*).

...when fully rotated about one OR more axes(*).

Bill P.

[William F Pokorny] Re: Suggest v4.0 sor{} fixes / changes. (yuqk R2... [199 days 21 hours and 59 minutes ago]

Sun, 21 Sep 2025 22:34:49 GMT

On 9/21/25 13:44, jr wrote:
> v confusing.  intervals (media) is a numeric value, your sor{} ones are string
> values.  how do those 5-char strings relate to the 8-element/point arrays ?

Documentation needs to be created. :-) A quick answer is that the number 
of spline-segments for the sor{} is always 3 less than the number of 
points specified. The length of the boolean bit string for control over 
all spline-segments is therefore (8-3).

For the lathe, the bit string length will differ depending upon the 
spline type. The same would be true for the sphere_sweep should the 
'intervals' feature be implemented there.

> on topic "sor{}" - is it "hollow" or "solid" as suggested ?  (I have an email
> thread "stalled" on this question :-))
One of my all time favorite streaming series is a show called "Patriot" 
on Amazon's Prime Video service.

https://en.wikipedia.org/wiki/Patriot_(TV_series)

On seeing questions, I often hear Michael Dorman's character saying 
"It's never that simple."

Depends on stuff - and for the keyword 'hollow' there is a pile of stuff 
I know, I don't know. I've never done a deep dive on how the setting 
cascades throughout the code. There is some weirdness with how it works 
and, IIRC, Alain pointed out one of those in the last year or two for 
some situation where adding 'hollow' magically fixed things.

The keyword 'hollow' means something closer to "You can stick media in 
this object" - except where it doesn't.

For the concept of solid, it mostly means the shape has a defined inside 
test in POV-Ray. That inside test can be kinda, arbitrarily, there at 
times - as is  the case with disc{}s, for example. Further, solid(as 
defined inside), doesn't necessarily mean closed-solid or 
surface-bounded-volume, which is often the stricter requirement for 
features like media and interior fading to work correctly.

With respect to Bill W's suggestion that the sor acronym assignment 
/alignment be changed to "solid of revolution", it just hits me as 
wrong. Perhaps this only due what I was exposed to over time. To me, 
when someone says "solid of revolution", it is the 3D volume a 3D object 
(a more mechanical thingy) requires when fully rotated about one more 
axes(*).

(*) - It would be an interesting way to define shapes in POV-Ray, if we 
work out how to do it(**).

(**) - I've wondered occasionally about adding an f_reuleaux_prism() 
inbuilt function and/or shape. The rotation of the defining triangle's 
center around a circle produces a nice, beveled "solid of revolution."

[jr] Re: Suggest v4.0 sor{} fixes / changes. (yuqk R2... [200 days 2 hours and 49 minutes ago]

Sun, 21 Sep 2025 17:45:00 GMT

hi,

William F Pokorny <ano### [at] anonymousorg> wrote:
> On 9/21/25 10:35, Kenneth wrote:
> > I noticed that you use the 'intervals' keyword in your SOR objects. ...
>
> The 'intervals' keyword is still there for media{} in yuqk and so it's
> added to the group of keywords with more than one meaning(*).
> ...
> In any case, the keyword 'intervals', like the functionality it enables,
> is at this point a v4.0 suggestion; something to play with. :-)

v confusing.  intervals (media) is a numeric value, your sor{} ones are string
values.  how do those 5-char strings relate to the 8-element/point arrays ?

on topic "sor{}" - is it "hollow" or "solid" as suggested ?  (I have an email
thread "stalled" on this question :-))

regards, jr.

[Kenneth] Re: Suggest v4.0 sor{} fixes / changes. (yuqk R2... [200 days 2 hours and 59 minutes ago]

Sun, 21 Sep 2025 17:35:00 GMT

William F Pokorny <ano### [at] anonymousorg> wrote:
>
> The 'intervals' keyword is still there for media{} in yuqk and so it's
> added to the group of keywords with more than one meaning(*).
>
> [snip]
> In any case, the keyword 'intervals', like the functionality it enables,
> is at this point a v4.0 suggestion; something to play with. :-)
>

Oops, I *just* read your earlier thread which explains your 'intervals' use:

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

My apologies for not seeing that before I posted here :-/

[William F Pokorny] Re: Suggest v4.0 sor{} fixes / changes. (yuqk R2... [200 days 4 hours and 15 minutes ago]

Sun, 21 Sep 2025 16:19:20 GMT

On 9/21/25 10:35, Kenneth wrote:
> I noticed that you use the 'intervals' keyword in your SOR objects. In the
> current official POV-ray syntax, that keyword is used only for media. In your
> yuqk fork, have you eliminated that keyword usage in your SDL media code, so
> that it only applies to an SOR shape now? Or has yuqk's media 'intervals' been
> changed to some other word, perhaps?

The 'intervals' keyword is still there for media{} in yuqk and so it's 
added to the group of keywords with more than one meaning(*).

I was first going to add a new keyword called 'segments' for this new 
functionality, but with the sor{} it's defining interior sub-regions 
alongside the 'surface segments'(**).

I've got hooks in place to add this kind of functionality to the 
lathe{}. There it might make more sense to use 'segments'. Unlike the 
sor{}, the interior regions cannot be cleanly broken up. With the 
lathe{}, the spline can fold back on itself - the inside is set by the 
whole spline.

In any case, the keyword 'intervals', like the functionality it enables, 
is at this point a v4.0 suggestion; something to play with. :-)

Bill P.

(*) - I have mostly been de-layering keyword meanings in yuqk. 
Introducing ip_ and it_ prefixes for pattern/perturbation and turbulence 
related keywords, respectively. This work fixes a number of bugs caused 
by keyword context overlaps in our official POV-Ray code.

There is too already a smaller ii_ prefix set for input/internal image 
keywords. I'm still thinking about other keyword prefix groupings like 
is_ for internal shape keywords; il_ for internal light_source keywords; 
ic_ for internal camera keywords; im_ for internal media keywords. We'll 
see.

(**) Functionality which makes the sor{} more useful as a csg helper 
function / shape. Functionality which opens up the ability to use on 
curve points as effective control points in the middle of the sor{} 
spline. Functionality which better enables two or more sor{} shapes to 
create off y axis surfaces of revolution with well defined inside regions.

In short, I'm coming away from this look/update of the sor{} thinking 
the it might be more useful than I originally thought!

[Kenneth] Re: Suggest v4.0 sor{} fixes / changes. (yuqk R2... [200 days 5 hours and 54 minutes ago]

Sun, 21 Sep 2025 14:40:00 GMT

[Running v3.8 beta 2 in Windows 10]

[Off-topic:]

Out of curiosity, I ran your code example (while eliminating your yuqk-specific
additions), just to see what the results would be.

I noticed that you use the 'intervals' keyword in your SOR objects. In the
current official POV-ray syntax, that keyword is used only for media. In your
yuqk fork, have you eliminated that keyword usage in your SDL media code, so
that it only applies to an SOR shape now? Or has yuqk's media 'intervals' been
changed to some other word, perhaps?

Just curious. :-D

[William F Pokorny] Re: Suggest v4.0 sor{} fixes / changes. (yuqk R2... [200 days 9 hours and 58 minutes ago]

Sun, 21 Sep 2025 10:36:12 GMT

On 9/15/25 19:49, William F Pokorny wrote:
> The idea with both 'caps' and 'intervals' is to add inbuilt ways for the 
> sor{} to be broken apart and the pieces textured, used in CSG or for 
> debug and modeling.

An additional change with the sor{} for R20 of yuqk is to allow sor 
references to existing sor identifiers - while permitting changes to the 
caps, open and intervals keyword settings(*). In other words, today, if 
you want two sor shapes where the only difference is the open setting, 
you have to create two complete sor{} blocks including the point list 
and the 'open' keyword or not.

It is the case today that using sor { Sor00 } is no different than 
object { Sor00 } in that both allow only differing object modifiers 
within the braces after the sor identifier.

There is also no type checking the identifier reference matches the type 
of the block wrapper itself. While the debug compile of yuqk has already 
implemented some type checking for text{} and ???, R20 of yuqk will 
always verify the ID type for the updated sor{}. It must to enable the 
keyword settings of a referenced sor ID to later be modified.

Attached an image and the scene file used to create the four sub images.

Bill P.

(*) - I thought I had the code for this in hand a week ago, but nope. I 
believe I've now got a clean implementation...

[William F Pokorny] Re: Suggest v4.0 sor{} fixes / changes. (yuqk R2... [205 days 20 hours and 29 minutes ago]

Tue, 16 Sep 2025 00:04:57 GMT

On 9/15/25 19:49, William F Pokorny wrote:
> The bug fixes(a) and control point relaxations for the sor{}...

Attached another image. Here in the top row showing inverted in y, 
positive in x control points - which are already legal in POV-Ray today.

The middle row shows negative in x, not inverted / flipped, control 
points as Bill W suggested be supported for the sor{}.

The bottom row shows the difference in result.

Bill P.

[William F Pokorny] Suggest v4.0 sor{} fixes / changes. (yuqk R20 v0... [205 days 20 hours and 44 minutes ago]

Mon, 15 Sep 2025 23:49:45 GMT

The bug fixes(a) and control point relaxations for the sor{} in the next
yuqk release were discussed in the thread:

https://news.povray.org/povray.documentation.inbuilt/thread/%3Cweb.689b6c79e72c05b2bc0c1c5925979125%40news.povray.org%3E/

The next yuqk release is also adding two new keywords to the sor{}. One
is 'caps' and the other is 'intervals'.

The caps changes align what was done for yuqk's text{} update:

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

The intervals keyword is followed by a string of 0 and 1 values which
allow particular sor{} curve segments to be kept or not.

The middle image row used:

intervals "10101"

which, left to right, indicates only the first, third and fifth of the
five total sor{} segments are to be used.

The idea with both 'caps' and 'intervals' is to add inbuilt ways for the
sor{} to be broken apart and the pieces textured, used in CSG or for
debug and modeling.

The second row rotates the sor by -10*x and the third row by -45*x to
better see the sor segments and caps, respectively.

Bill P.

(a) - Except for adjusting an older yuqk update removing the
too-generic, single value EPSILON use in the sor code. In recent testing
I found cases - like in the attached image - with tight, segment turns
where those A,B,C,D internal values needed to be zeroed at closer to the
old official POV-Ray EPSILON of 1e-10. I settled specifically on
4.4e-12, but things are being fudged here - so we'll see how the newer,
new zeroing limit holds up.

[Bald Eagle] Re: Docs and source code for various objects [217 days 6 hours and 44 minutes ago]

Thu, 4 Sep 2025 13:50:00 GMT

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

> I'm not opposed to better descriptions or feature names. That said, I
> don't see "solid of revolution" as better terminology. It might be just
> me though :-).

Because it looks and acts solid without any special treatment.
Regardless of caps or inside regions, if I can't see through the inside, and I
can use it in CSG, then it's solid.

If I apply the open keyword, then I can (depending on the specific location of
control points) see through it, not properly use it in CSG, and it's an
infinitely thin shell.

This is fun.  You play clipka, and I'll play Warp.  ;D

> Many shapes have caps, or not, while still having defined inside(0)
> regions. The cone, cylinder, prism, etc, have caps or not.
>
> The lathe does not include caps - and doesn't automatically close loops.
> Perhaps you are remembering prism{}s / polygon{}s which have code to
> close spline loops (linear_spline only?).

While I was very briefly making a lathe shape to contrast it with sor, I made a
square U shape, where I only supplied 8 points, not repeating the starting
point.   I didn't use an interior_texture, so I'll to try that when I get the
chance.

> I believe it relates to the sor not allowing folds in y. The defining
> points for the sor must be ever increasing or decreasing in y.

However, the documentation points out that you can use ANY point for the
"oof-spline" control points to set the tangent directions.  Haven't tried it
yet.

> With 2,3 and the sturm 'aside', I was - poorly - trying to point out the
> broad, sweeping statements about sor vs lathe performance, sturm vs not
> accuracy and performance mentioned in our documentation - and often in
> our forums - are iffy at best and sometimes outright wrong(a).

I'd probably have to try that with a much longer spline to really see.

> (a) - In yuqk, where many solver issues are fixed / refined and 'sturm'
> more reliably invokes the sturmian solver, or not, there is seldom any
> difference in accuracy between the dedicated <=4 order solvers and the
> sturmian solver. While 'sturm' is usually slower, it's often by not that
> much. Its also true for lower (<=4) order equations 'sturm' is,
> occasionally, faster than the fixed solvers! It depends on stuff.

Yes, it can get complicated, and I find myself looking into all of this solver
stuff myself, and reading about how others handle some of the quartic and higher
equations.  So far I've only written my own simple Newton-Raphson solver, and
copy-pasted the matrix multiplicative inverse method from source into SDL
(because why rewrite it...)

Thanks for chiming in - there's always more to be learned.
I wish I hadn't been so busy with graduate school in "the golden days" of
POV-Ray.  I also wish I had kept up with my programming skills.  I always feel
like I'm so very late in the game to be trying to make meaningful contributions.

- BW

[Mr] Re: Docs and source code for various objects [217 days 9 hours and 49 minutes ago]

Thu, 4 Sep 2025 10:45:00 GMT

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

> >> In any case we should
> >> look again at what was done for this feature in hgpovray38.
> >
> > Yes, always an excellent idea.  I can only unravel one code base at a time
> > (usually :D)

I tried to reach to LeFogeron, but failed. If anyone could... please attract his
attention to this discussion, trying to get him involved, so that more of the
povers who are really advanced in this area can actually also shed their light
on this topic!

[William F Pokorny] Re: Docs and source code for various objects [217 days 19 hours and 1 minute ago]

Thu, 4 Sep 2025 01:33:05 GMT

On 9/3/25 07:10, Bald Eagle wrote:
> William F Pokorny <ano### [at] anonymousorg> wrote:
> 
>> Why 'solid'?
> 
> Because that's the default case....> It also doesn't change the acronym sor {}.
> 
> I haven't rigorously experimented with the lathe object yet, but I've rendered a
> non-closed curve, and it was solid / automatically closed.

I'm not opposed to better descriptions or feature names. That said, I 
don't see "solid of revolution" as better terminology. It might be just 
me though :-).

Many shapes have caps, or not, while still having defined inside(0) 
regions. The cone, cylinder, prism, etc, have caps or not.

The lathe does not include caps - and doesn't automatically close loops. 
Perhaps you are remembering prism{}s / polygon{}s which have code to 
close spline loops (linear_spline only?).

(0) - Less caps, these shapes are all 'tricky' to use with features 
where clean ray->surface pairs / ray-intervals are expected - CSG included.

> 
>> 2) The polynomial order the solvers see with the lathe depends on the
>> type of spline used.
> 
> Well, yes. ("obviously") But the issue that I was trying to clarify was why the
> lathe always has to solve a polynomial that is twice the _degree_ of the spline
> segment being handled. (whereas the sor is happy to stick with the actual degree
> of the spline)

I believe it relates to the sor not allowing folds in y. The defining 
points for the sor must be ever increasing or decreasing in y. Beyond 
that (which you probably knew), you've done far more work than I have in 
trying to 'really' understand the particulars of the sor & lathe 
polynomial set up code / method(s).

> 
>>
>> 3) For the attached image the sor is on the left and the lathe on the
>> right. I'm using yuqk, so the solvers are changed from POV-Ray proper.
>>
>>       5
>>       <+1.5,-0.1>
>>       <+0.4,0.0>
>>       <+0.3,0.5>
>>       <+0.4,0.9>
>>       <+1.5,1.1>
> 
> Please do not mislead - you're clearly using a non-specified type of spline, and
> the open keyword.

With 2,3 and the sturm 'aside', I was - poorly - trying to point out the 
broad, sweeping statements about sor vs lathe performance, sturm vs not 
accuracy and performance mentioned in our documentation - and often in 
our forums - are iffy at best and sometimes outright wrong(a).

I included the sor vs lathe image to show I was using 'open' with the 
sor. The lathe doesn't do caps - and the performance numbers would be 
'unfair' to the sor otherwise. I noted too the lathe in the performance 
comparison was using cubic_spline (order 6).

(a) - In yuqk, where many solver issues are fixed / refined and 'sturm' 
more reliably invokes the sturmian solver, or not, there is seldom any 
difference in accuracy between the dedicated <=4 order solvers and the 
sturmian solver. While 'sturm' is usually slower, it's often by not that 
much. Its also true for lower (<=4) order equations 'sturm' is, 
occasionally, faster than the fixed solvers! It depends on stuff.

>> In any case we should
>> look again at what was done for this feature in hgpovray38.
> 
> Yes, always an excellent idea.  I can only unravel one code base at a time
> (usually :D)

Indeed, multiple code bases are hard to keep straight. :-(

I get tangled up all the time trying to remember differences - v3.7, 
v3.8 (at where yuqk forked), v3.8 as backed up to something different 
for our two beta releases - and the great many yuqk fork specific 
changes / fixes relative to all the official, v3.7 / v3/8, POV-Ray code 
releases.

Bill P.

[Bald Eagle] Re: Docs and source code for various objects [218 days 1 hour and 14 minutes ago]

Wed, 3 Sep 2025 19:20:00 GMT

"ingo" <nomail@nomail> wrote:

> Speresweeps can be lofts. Blob-sweeps are isosurfaces, marching thingies.

37 page paper to ... concatenate spheres and cylinders/cones.
Just like I've (re)written hundreds of times every time I want to graph
something.

But - what's that? They calculate the tangents between the spheres to smoothly
connect them?

And the manuscript was written in ... 2019?

https://news.povray.org/povray.binaries.images/thread/%3Cweb.5da27a2a65c96eb4eec112d0%40news.povray.org%3E/?ttop=445868
&toff=650&mtop=428668

https://news.povray.org/povray.text.scene-files/thread/%3Cweb.5dd1666f8983c4eb4eec112d0%40news.povray.org%3E/?ttop=4458
70&toff=50&mtop=429362

Must just be wild coincidence.
Just like that curvature of splines YT video.

But I do think that we can rewrite the spheresweep with some better code - both
analytically as well as tesselation.

- BW

[ingo] Re: Docs and source code for various objects [218 days 3 hours and 49 minutes ago]

Wed, 3 Sep 2025 16:45:00 GMT

regarding Voronoi:

Voronoi cells are connected.

This means one gets manifolds and the half edge mesh system chokes on that.

Voro++ uses the bag of cells approach. But there is no further relation between
the cells. That's a pity. While constructing the voronoi pattern we gather data
about neigbours. These can be put in a record/struct together with the vertex
and face data of the cell. This makes it possible to traverse through the voroni
cells. The halfe edge datastructure can still be used for the single cell mesh.
Simplified:

VornoiCell = object
  geometry: ConvexPolyhedron  // halfedgemesh or just array of vertices & faces
  seedPoint: Vec3
  neighbors: seq[CellID]     // adjacent cells
  sharedFaces: Table[CellID, FaceID]  // which face is shared with which
neighbour

VoronoiBag = objec
  cells: Table[CellID, VoronoiCell] // if cellId is ordered, seq[VoroinoCell]


Then I thought, what if we transpose the (half) edge to a higher dimension.
That/what would be a half face/facet mesh datastructure. Very implified:

type
  HalfFace = object
    face: Face                   // geometric face (vertices, normal, etc.)
    adjacentCell: CellID         // which cell this half-face belongs to
    twinHalfFace: HalfFaceID     // opposite half-face in neighboring cell
    nextAroundCell: HalfFaceID   // next face around this cell

  VoronoiMesh = object
    halfFaces: List<HalfFace>
    cells: List<Cell>            // each cell references its half-faces


pattern :
1D: vertices bind line segments
2D: edges bind faces
3D: faces bind volumes/cells
4D: volumes would bind 4D regions

Half-edge works for 2D as edges are the boundaries between faces
Half-face makes sense for 3D as faces are the boundaries between cells
Half-volume would work for 4D as volumes are the boundaries between 4D cells?

for n-dimensional mesh elements (n-1)-faces separate n-dimensional regions?


After some searching it is actually something that exists to create 3d connected
mesh' : OpenVolumeMesh
https://www.graphics.rwth-aachen.de/software/openvolumemesh/

The choice depends on the goal,

ingo

[ingo] Re: Docs and source code for various objects [218 days 5 hours and 24 minutes ago]

Wed, 3 Sep 2025 15:10:00 GMT

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

> Ah, libraries . . . and licenses.  :/

Politics and silo's :(

lofting in SDL:
https://news.povray.org/povray.binaries.utilities/thread/%3CXns94D4AF6BE46A0seed7%40news.povray.org%3E/?ttop=445117&tof
f=150

half edge mesh for for voronoi is a good one. In 2d each cell is a polygon, in
3d a mesh of polygons. Multiple connected cells may need some special design in
3d as most versions don't like manifolds, more than two faces connected to an
edge, so less than halve an edge. Can get messy. Wait, there's space between the
cells, are they ever touching/connected? If not it's just a "bag of cells" and
half edge works fine. I'll try it a bit ... mmm ... if jr. allows as he gave me
a job I still haven't finished.

Prisms/extrusions for text, yes of course.

Speresweeps can be lofts. Blob-sweeps are isosurfaces, marching thingies.

So it boils down to two well implemented algorithms to cover all shapes in mesh
form.

thanks for the links, I'll have a look,

ingo

[Bald Eagle] Re: Docs and source code for various objects [218 days 6 hours and 24 minutes ago]

Wed, 3 Sep 2025 14:10:00 GMT

"ingo" <nomail@nomail> wrote:

> The odd one out may be the sphere sweep
> depending on the kind of result one wants.

I'm guessing that we might be able to use what was learned in the whole tubular
function thread to rewrite the sphere sweep object code in triangle mesh form.

(Just because it would be cool, I'd like to see that hexagonal surface
tesselation used to cover surfaces, because the triangle mesh is just a subset
of that method)

> Text I've never looked in to, maybe lofting a mesh, kind of parametric. ('t
> would be nice to have the path of a glyph available in SDL for
> interpolation/spline)

Cousin Ricky and I have both manually converted text to splines.
Clipka was talking about converting all of the text to prisms.

> Lofting may be a mesh thing that has no equivalent in the "solid" world.

I had been interested in creating lofting some time back, but never had the
opportunity to bite into that. (yet...  ;) )

> Subdivision modelling. Iirc John VanSickle wrote a macro for it. I don't
> remember a POV-Ray patch that was able to do it, may have missed it.

http://news.povray.org/povray.news-submissions/message/%3C40a14e8c%40news.povray.org%3E/#%3C40a14e8c%40news.povray.org%
3E

https://news.povray.org/povray.advanced-users/thread/%3C53de2167%40news.povray.org%3E/

https://news.povray.org/povray.unofficial.patches/message/%3C40aeaf37%40news.povray.org%3E/#%3C40aeaf37%40news.povray.o
rg%3E

> For CSG there are mesh libraries.

Ah, libraries . . . and licenses.  :/

> I've been dabbling with Half Edge Mesh data structures in Nim. Once you have one
> it is relative easy to convert it to any mesh format. They are also useful for
> operations on mesh.

Very interested.
I've been wanting to do a user-controlled Voronoi pattern / object, and one of
the algorithms involves using a half-edge data structure.

- BE

[Bald Eagle] Re: Docs and source code for various objects [218 days 6 hours and 49 minutes ago]

Wed, 3 Sep 2025 13:45:00 GMT

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

> Aside: What 'sturm' actually does (or not) with any given shape where
> the keyword is supported is very muddy in the code / documentation

What _anything_ actually does is often very muddy in the code / documentation.

It shouldn't take me a week to unravel something like sor because there's a
complete absence of any explanatory / guiding comments.

Some people have this attitude that "Well, it just _expected_ that if you're
using a computer graphics package, that you'd at least know about XYZPDQ...."
But I'd say that from a developer's perspective, the comments ought to be in
there just as part of good coding practice, and not every c++ coder is going to
be a graphics expert or experienced mathematician.  I'm perpetually mystified as
to why someone would be expected to "just figure it out", when someone already
had it all figured out when they wrote the source code.

I would say that if POV-Ray still actually has an active user base, and we want
to actually make the push forward to 4.0 or 5.0 or whatever --- then folks
should take a peek into the code for their favorite object, one that they
understand the CG theory of, or one that they've always been curious about how
it worked - and make some notes about what the source code does and how.

Because even just having a patch version that consists of nothing more than
user-added commentary and theoretical references for all of the various
algorithms would be a big step forward for us, and a giant help to anyone we
might find willing to be a developer.

The comments don't even necessarily have to be IN "the code" - we could just
have a .h, a .cpp, and then an additional .doc or some other extension (.prd Pov
Ray Documentation) text file where everything can get hashed out and unfinished
work can be left as empty outline sections for others to continue work on.

If we had all of that available as an additional "developer documentation"
section of the distribution, then 1. our code would be far more well documented
than it currently is, 2. anyone debugging or adding to the code would be way
ahead of the curve rather than way behind, and 3. all of that theory and
under-the-hood operational stuff would be readily available as a resource to
point to when people on the forum ask the usual questions.

- BE

[ingo] Re: Docs and source code for various objects [218 days 7 hours and 34 minutes ago]

Wed, 3 Sep 2025 13:00:00 GMT

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

> That would be nice - though unsure if we could handle _everything_ that way.
> But keep talking - I'm listening.  :)
>
>

"everything", wrt mesh depending on the object, either Parametric or Marching
"Cubes" / Dual Contouring. Prism, SOR, Lathe, all mesh extrusion/rotation of
some kind (is kind of parametric). The odd one out may be the sphere sweep
depending on the kind of result one wants.

Text I've never looked in to, maybe lofting a mesh, kind of parametric. ('t
would be nice to have the path of a glyph available in SDL for
interpolation/spline)

Lofting may be a mesh thing that has no equivalent in the "solid" world.

Subdivision modelling. Iirc John VanSickle wrote a macro for it. I don't
remember a POV-Ray patch that was able to do it, may have missed it.

An other thing that comes with mesh is displacement mapping (combined with
subdivision or parametric) as is currently possible through the macro route an
using an image as a function.

For CSG there are mesh libraries.

"everything" wrt backend. When there would be a meshify option for objects, 3D
printing etc. would be easier. It would require testing for closed mesh' and
probably a few more things.

I've been dabbling with Half Edge Mesh data structures in Nim. Once you have one
it is relative easy to convert it to any mesh format. They are also useful for
operations on mesh.

Almost all of this is available in libraries, https://www.cgal.org/ for example.

ingo

[Bald Eagle] Re: Docs and source code for various objects [218 days 9 hours and 19 minutes ago]

Wed, 3 Sep 2025 11:15:00 GMT

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

> Why 'solid'?

Because that's the default case.
It's only not solid when you do the additional work to "hollow it out" with the
open keyword.
Let's say what we mean and mean what we say, rather than misleading the reader /
new user.

Calling it something slightly different but more accurate in the documentation
is (in my mind) better / more correct / proper, and leads to a better flow of
the documentation text when we get to invoking the keyword.
It also doesn't change the acronym sor {}.

I haven't rigorously experimented with the lathe object yet, but I've rendered a
non-closed curve, and it was solid / automatically closed.

> The 'Surface Of Revolution' terminology is, I think, the more common -
> for both objects.

I don't know what's "more common" but I'm less interested in what other people
do than the actual results of what our code does and how we describe it.
It's not (only) an infinitely thin surface - you can use it in CSG.  So why are
we calling it one?

> For me, 'lathe' implies solidness when we can create,
> for example, open shapes, torus shapes or many 2d profiles wrapped
> around the y axis at the same time.

I was renaming sor, not lathe.  I haven't gotten to scrutinizing the lathe yet,
so we'll see what I can learn / break with that one.

> Other random thoughts:
>
> 1) Both objects (mostly) end up as uni-variate polynomials (power series
> form) as fed to the solvers.

Seems right - I'm just doing this in 15-20 minute spurts, as the opportunities
arise.

> 2) The polynomial order the solvers see with the lathe depends on the
> type of spline used.

Well, yes. ("obviously") But the issue that I was trying to clarify was why the
lathe always has to solve a polynomial that is twice the _degree_ of the spline
segment being handled. (whereas the sor is happy to stick with the actual degree
of the spline)

>
> 3) For the attached image the sor is on the left and the lathe on the
> right. I'm using yuqk, so the solvers are changed from POV-Ray proper.
>
>      5
>      <+1.5,-0.1>
>      <+0.4,0.0>
>      <+0.3,0.5>
>      <+0.4,0.9>
>      <+1.5,1.1>

Please do not mislead - you're clearly using a non-specified type of spline, and
the open keyword.

> Aside: What 'sturm' actually does (or not) with any given shape where
> the keyword is supported is very muddy in the code / documentation - a
> little less so with the yuqk fork. For example, the sturmian solver is
> always used where the polynomial order is >4 no matter the use of
> 'sturm'. In official POV-Ray 'sturm' often doesn't control the inside
> test code when solving for polynomial's for roots, where in yuqk it more
> often (aways?) does. Further, in yuqk where 'sturm' is specified with
> lower order polynomials (order <= 4), the sturmian solver is used, where
> in official POV-Ray it often is not. In the official code base, there is
> too order reduction code (removed in yuqk) which routes equations to
> particular solver methods no matter the 'sturm' setting.

I have followed some of that code, and see all of that in there.
I recall posting something about the sturmian root solver in the past - couldn't
find it the last time I searched.

> As for parametrics, agree with much of what you suggest, but thinking
> maybe a stand alone program cleaner / better.

It may be, however I have a strong distaste for separable items, as well as
feeling that POV-Ray should have all of its own things as a starting point.

For example, just
> trundling through u,v coordinates forces very tiny steps (large numbers
> of triangles) universally where shapes / surfaces have sharp-ish edges /
> small features one wants maintained in the rendered result. Better would
> be optimizations of the initial mesh to reduce the size while
> maintaining 'sharp' / 'small' features

Yes, I've read some about doing just that.  I feel I'll be prepared to
understand further reading on that subject due to my work on surface curvature.

> - this sort of optimization
> should probably be done outside of SDL parsing.

It might _best_ be done that way, but I think not exclusively.
Let the user set an accuracy variable like in other shapes.

> In any case we should
> look again at what was done for this feature in hgpovray38.

Yes, always an excellent idea.  I can only unravel one code base at a time
(usually :D)

Ingo:

> A side effect that I would welcome, if we can generate internal mesh of objects,
> global meshify setting, we can do openGL pre-views.

Oh, yeah.  I hadn't thought about that!

> An other side effect, subdivision modelling, though purely by script it's not
fun.

I have dabbled with that in the past - and wasn't there a whole POV-Ray version
that had that sort of code in it?   May be time to revisit.

> If I could write POVRAY5, i'd look into language and parsers in such a way that
> it can spit out multiple things to serve multiple rendering back ends.

That would be nice - though unsure if we could handle _everything_ that way.
But keep talking - I'm listening.  :)

-BW

[ingo] Re: Docs and source code for various objects [218 days 12 hours and 34 minutes ago]

Wed, 3 Sep 2025 08:00:00 GMT

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

> What do you all think?  Discuss.

Yes.

But, for all objects. It means we'd need a whole mesh library (openMesh etc.?)
to build on.

quite a bit of "all" objects can be represented as parametric.
sphere(
  0, 1
  resolution = <60, 30>
)
resolution triggers the system to create the parametric sphere, instead of the
solid.

tracing parametrics "always" requires some form of iteration like Newton-Raphson
/ iterative root-finding, subdivision / bounding volume hierarchy, Bezier
clipping etc.

One can use a "coarse" mesh as starting point and then do subdivision to
subpixel level, using the parametric eq set.

A side effect that I would welcome, if we can generate internal mesh of objects,
global meshify setting, we can do openGL pre-views.

An other side effect, subdivision modelling, though purely by script it's not
fun.

If I could write POVRAY5, i'd look into language and parsers in such a way that
it can spit out multiple things to serve multiple rendering back ends.

ingo

[William F Pokorny] Re: Docs and source code for various objects [218 days 15 hours and 21 minutes ago]

Wed, 3 Sep 2025 05:13:20 GMT

On 9/2/25 20:09, Bald Eagle wrote:
> With regard to the documentation for sor {}, I felt it prudent to make a push
> for slightly altering how the shape is referred to.  I propose that SOLID of
> revolution is the proper expansion of "sor".
> https://wiki.povray.org/content/Reference:Surface_of_Revolution
> 
> What do you all think?

Why 'solid'?

Unsure what better name(s) might be, but both the sor and lathe objects 
are rotations of one or more 2d curve segments around the y axis. The 
sor object is 'solid' (has a well defined inside) only in the default 
case (less the 'open' keyword); The lathe only when the 2d curve(s) are 
carefully closed.

The 'Surface Of Revolution' terminology is, I think, the more common - 
for both objects. For me, 'lathe' implies solidness when we can create, 
for example, open shapes, torus shapes or many 2d profiles wrapped 
around the y axis at the same time.

Other random thoughts:

1) Both objects (mostly) end up as uni-variate polynomials (power series 
form) as fed to the solvers.

2) The polynomial order the solvers see with the lathe depends on the 
type of spline used.

3) For the attached image the sor is on the left and the lathe on the 
right. I'm using yuqk, so the solvers are changed from POV-Ray proper.

     5
     <+1.5,-0.1>
     <+0.4,0.0>
     <+0.3,0.5>
     <+0.4,0.9>
     <+1.5,1.1>

sor
---
21.43user 0.03system 0:06.11elapsed
25.28user 0.02system 0:07.06elapsed  (sturm)

lathe  (cubic_spline)
-----
26.33user 0.02system 0:07.27elapsed
26.30user 0.02system 0:07.31elapsed  (sturm)

Aside: What 'sturm' actually does (or not) with any given shape where 
the keyword is supported is very muddy in the code / documentation - a 
little less so with the yuqk fork. For example, the sturmian solver is 
always used where the polynomial order is >4 no matter the use of 
'sturm'. In official POV-Ray 'sturm' often doesn't control the inside 
test code when solving for polynomial's for roots, where in yuqk it more 
often (aways?) does. Further, in yuqk where 'sturm' is specified with 
lower order polynomials (order <= 4), the sturmian solver is used, where 
in official POV-Ray it often is not. In the official code base, there is 
too order reduction code (removed in yuqk) which routes equations to 
particular solver methods no matter the 'sturm' setting.

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

As for parametrics, agree with much of what you suggest, but thinking 
maybe a stand alone program cleaner / better. For example, just 
trundling through u,v coordinates forces very tiny steps (large numbers 
of triangles) universally where shapes / surfaces have sharp-ish edges / 
small features one wants maintained in the rendered result. Better would 
be optimizations of the initial mesh to reduce the size while 
maintaining 'sharp' / 'small' features - this sort of optimization 
should probably be done outside of SDL parsing. In any case we should 
look again at what was done for this feature in hgpovray38.

Other ideas logged. :-)

Bill P.

[Bald Eagle] Docs and source code for various objects [218 days 20 hours and 24 minutes ago]

Wed, 3 Sep 2025 00:10:00 GMT

Howdy folks,

For those of you playing along at home, I have recently gotten involved in
digging through the source code for sor {}, and therefore lathe {}, and by
extension, parametric {}.

With regard to the documentation for sor {}, I felt it prudent to make a push
for slightly altering how the shape is referred to.  I propose that SOLID of
revolution is the proper expansion of "sor".
https://wiki.povray.org/content/Reference:Surface_of_Revolution

What do you all think?  Discuss.

The fundamental difference between the sor and the lathe is that the sor is an
implicit equation, and therefore we can solve for intersection with a ray using
only equations of degree 3.   The lathe on the other hand, is a parametric
equation, and so we cannot simply plug in some <x, y, z> coordinate and
determine if that point is on the surface.  So we need to use some matrix math
to solve a system of linear equations, and the Pythagorean theorem to determine
how far away from the surface any given point is - which means that a degree 3
equation squared is now a degree 6 equation.

And that's why lathe is both more flexible, and slower.  Because we need to use
numerical methods (an approximation algorithm) to solve a 6th degree polynomial.

Parametrics are trivial to _construct_ - we just plug in a <u, v> coordinate,
and out pops an <x, y, z> point on space.  But they are very difficult to
raytrace.  We need to do the exact opposite of that.  When we project a ray from
the camera through a screen pixel out into POV-space, we need to determine if we
intersect the parametric.  Good luck.
Doing this tends to involve, long, drawn out subdivision schemes that take a lot
of time.  Which is why the parametric {} object is so notoriously SLOW.

However, we do have a set of macros that provides a very good workaround.  Use
the forward method of constructing a parametric to literally do that.  Step
through u and v, make a grid, and subdivide every quadrilateral into
triangle{}s.  Raytracing the triangles is then very fast, and (especially when
using smooth_triangle{}s) look indistinguishable from doing it the hard, slow
way.

I propose (as I have in the past) that we change the parametric {} to use a
triangle approximation, or create a new parametric2 object, just like we have
mesh and mesh2.
If that sounds like a lot of work - keep in mind that we already have just about
everything we need already - in the form of the bicubic_patch {} object.  It's a
parametric surface using control points, and gets converted into triangles in
source before rendering.

So we just copy/paste that code into a new object, rewrite it for a rotational
sweep, and it should be just as good as parametric {} but blindingly FAST in
comparison.  Which means that people will USE it, whereas almost nobody uses the
original parametric {} at all.

I'd also suggest that future work involve adding more spline types, or creating
some mechanism whereby the can be user_defined spline types.

We could also use some additional parametric surfaces in addition to the Bezier
surface (bicubic_patch), and different ways of sweeping splines.
(I need to test an idea using a "1D" spline in a conical sweep to make a
triangular surface that follows a spline.) but extensions of that would make
modeling certain specific surfaces that much easier.

- BE

[Leroy] Re: WFP - Polynomial root finding [226 days and 19 minutes ago]

Tue, 26 Aug 2025 20:15:00 GMT

William F Pokorny <ano### [at] anonymousorg> wrote:
> On 8/25/25 15:51, Leroy wrote:
> > I wonder if there is away to find roots for polynomials in n variables.
>
> Yep. :-) For example:
>
> https://en.wikipedia.org/wiki/System_of_linear_equations
>
> Bill P.

Ya I remember that System_of_linear_equations. In high school we had a problem
with 14 or more equations. But that was a long time ago. What I was thinking of
was one equation like X^2+xyz^3+... with more variables. If I was really
thinking I would not have ask that question because it was just dumb. Some times
I just don't think!

Have Fun!

[William F Pokorny] Re: WFP - Polynomial root finding [226 days 17 hours and 48 minutes ago]

Tue, 26 Aug 2025 02:46:11 GMT

On 8/25/25 15:51, Leroy wrote:
> I wonder if there is away to find roots for polynomials in n variables.

Yep. :-) For example:

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

Bill P.

[William F Pokorny] Re: WFP - Polynomial root finding [226 days 18 hours and 1 minute ago]

Tue, 26 Aug 2025 02:33:31 GMT

On 8/25/25 14:03, Bald Eagle wrote:
> 
> Just came across this article the other day.
> 
> I just skimmed this, so don't know if this will be a big help or not:
> 
> http://codebase.cemyuksel.com/soln/using_cypolynomial.html
> 
> Hopefully it's something you can easily and productively make use of.
> 
> - BW
> 

Thanks for the reference. On the surface it looks like not much new, but 
I didn't read the referenced paper.

The yuqk fork implements new New-Raphson solvers as lambda functions to 
polish roots internal to the solve_cubic(), solve_quartic() and 
polysolve() solvers. The method long used elsewhere in the POV-Ray 
source code too. The superellipsoid shape at least & more. Been too long 
(6-7 years) since I was heavily into re-fining the solvers.

Bill P.

[Leroy] Re: WFP - Polynomial root finding [227 days and 39 minutes ago]

Mon, 25 Aug 2025 19:55:00 GMT

"Bald Eagle" <cre### [at] netscapenet> wrote:
> Just came across this article the other day.
>
> I just skimmed this, so don't know if this will be a big help or not:
>
> http://codebase.cemyuksel.com/soln/using_cypolynomial.html
>
> Hopefully it's something you can easily and productively make use of.
>
> - BW

Interesting. Like you I skimmed it, but I quit looking after the code got down
to  Newton. It looks like the code is for finding roots of polynomials in 1
variable.
I wonder if there is away to find roots for polynomials in n variables.

Have Fun!

[Bald Eagle] WFP - Polynomial root finding [227 days 2 hours and 29 minutes ago]

Mon, 25 Aug 2025 18:05:00 GMT

Just came across this article the other day.

I just skimmed this, so don't know if this will be a big help or not:

http://codebase.cemyuksel.com/soln/using_cypolynomial.html

Hopefully it's something you can easily and productively make use of.

- BW

[Thorsten] Re: User changes. yuqk / v4. Options re-work sta... [294 days 4 hours and 20 minutes ago]

Thu, 19 Jun 2025 16:14:20 GMT

On 19.06.2025 13:29, William F Pokorny wrote:
> (*) - I've never gotten around to trying to get a build without vfe --> 
> unix & ALTMAIN going. Having a single threaded and minimal, 
> text-only(**) build would be useful / good to have.

It exists for a simple reason: That is what I used for a lot of early 
development of 3.7, testing on a iBook (MacOS with PowerPC) and Windows 
at the same time (but Chris did most of the Windows work).

Thorsten

[William F Pokorny] Re: User changes. yuqk / v4. Options re-work sta... [294 days 9 hours and 4 minutes ago]

Thu, 19 Jun 2025 11:29:45 GMT

On 6/18/25 14:46, Thorsten wrote:
> Chris Cason implemented vfe originally based on my SimpleFrontend, which 
> provides a single scene, single render backward-compatible interface 
> because at the time we didn't have time to adapt the legacy GUIs.

Thank you Thorsten!

I'd worked out the SimpleFrontend was mostly not used while working on 
the yuqk fork. However, given ALTMAIN, I took it as a, long ago, 
intended, fall-back build from the platform dependent vfe 
implementations(*).

Aside: The yuqk fork's simplefrontend.h is mostly commented today, but a 
couple parts are necessary for vfe and the unix/linux build.

Bill P.

(*) - I've never gotten around to trying to get a build without vfe --> 
unix & ALTMAIN going. Having a single threaded and minimal, 
text-only(**) build would be useful / good to have.

(**) - 'text' is an option of unix/linux builds, but as the preview display.

[Thorsten] Re: User changes. yuqk / v4. Options re-work sta... [295 days 1 hour and 47 minutes ago]

Wed, 18 Jun 2025 18:46:36 GMT

On 13.06.2025 22:34, William F Pokorny wrote:
> What I'm re-working in these last couple months is setting more things 
> up in the options parsing which runs prior to the virtual front end 
> (vfe) starting. The 10 or 12 'pretend keywords' / identifiers like 
> image_width are set as vfe starts today. Nothing with respect to that 
> will change any time soon due the re-worked options.

vfe is just a layer over the actual interface needed primarily for 
Windows. The actual main in povmain.cpp contains a minimal viable 
version of what is actually needed based on RenderFrontend, which does 
have all the states needed:

SceneId CreateScene(...) // create as many as you like
   StartParser(SceneId, ...) // run as many as you like
   ViewId CreateView(SceneId, ...) // create as many as you like
     StartRender(ViewId, ...) // run as many as you like

You can run multiple parsers and multiple renders all at the same time.

Chris Cason implemented vfe originally based on my SimpleFrontend, which 
provides a single scene, single render backward-compatible interface 
because at the time we didn't have time to adapt the legacy GUIs.

Thorsten

[William F Pokorny] Re: User changes. yuqk / v4. Options re-work sta... [300 days ago]

Fri, 13 Jun 2025 20:34:07 GMT

On 6/13/25 07:38, Thorsten wrote:
> There is a good reason these are identifiers and not keywords (any 
> more). The architecture had a lot of separation issues in POV-Ray 3.6, 
> MegaPOV and before that kept getting worse, and prohibited a lot of 
> features that are useful.
> 
> The most notable is that the scene and the rendering can be separated. 
> That is, you do not need to re-parse a potentially complex scene for 
> hours just the render it in a higher resolution. There isn't even a 
> reason to not move the camera after parsing (as the real-time ray- 
> tracing feature shows).
> 
> The main problem has always been that a GUI was never developed for 
> these features. So the question you probably want to ask yourself it if 
> it really makes sense to throw all this overboard for an extremely 
> complex command-line interface...?

As always thank you for the background. I think I followed most of what 
you wrote. I expect my inability to write clearly has led to some 
confusion too. I'm sure too, I don't see all the obstacles I might 
encounter or introduce as I try and complete this re-work...

It's also true my ideas for the user command-lind / ini 'options' in 
this thread are some of the least developed / refined of my re-work effort.

As you know, the only method which doesn't require near-complete 
re-parsing of scenes for each frame today is the rtr camera list one. It 
might be the view internal code aspect is further along that my quick 
read-overs have led me to think, but it's not something working today 
for users beyond setting up an initial 'view' / camera view.

In other words, I'm not aware of any 'working method' to implement your 
example of rendering a scene again at a higher resolution without 
re-running the entire render - including too the cli/ini options parsing(*).

(*) You can distort each animation's frame images by twiddling with the 
image_height and image_width identifier values if, for example, these 
'pretend keywords' have been used to defined the camera. But, this 
capability also touches on the exposure carried with the current 
implementation.

What I'm re-working in these last couple months is setting more things 
up in the options parsing which runs prior to the virtual front end 
(vfe) starting. The 10 or 12 'pretend keywords' / identifiers like 
image_width are set as vfe starts today. Nothing with respect to that 
will change any time soon due the re-worked options.

In aiming to move the global_settings{} block stuff into the 'options' 
cli/ini parsing code, for example, I am pushing more 'keywords' out of 
the parser and into the options parsing as flags / ini-options where 
they'll get digested once rather than for each frame as our code stands 
today.

With respect to this thread in particular and the cli/ini declare=<id>=
option, I'm talking about changing / extending what today might be done 
in an ini file with a set of lines like:

declare=Int00=111
declare=Int01=222
declare=Int02=333.456

and parsed during the options setting phase with, say, 
'include_ini=MyInts.ini'.

With the planned approach in this thread it would become instead a file 
with the lines:

Int00 111
Int01 222
Int02 333.456

and

+-ui_"MyInts.ini"

Except I can now type check the input values and they become something 
read only accessible as global integers inside the parser (via parser 
functions). There is, of course, some effective 'look up the value' 
process whether done via a function call or parser identifier access.

Aside: Though I don't plan to go this way at present, a hybrid approach 
is possible - whether declare=.=. or as this new alternate +-ui_ method 
- nothing stops us from setting identifiers Int00, Int01 and Int02 to 
integer values before the parser runs in addition to enabling the parser 
function accessible method or even in place of it.

Lastly, I've only ever really used POV-Ray on linux/unix/aix systems. 
I'm not familiar with the windows (or osx) POV-Ray GUIs and expect I'm 
largely ignorant of most GUI support implications in general.

A reminder the yuqk fork is a linux/unix only v4 playpen - though 
hopefully mac/osx compiles work too.

Bill P.

[Thorsten] Re: User changes. yuqk / v4. Options re-work sta... [300 days 8 hours and 55 minutes ago]

Fri, 13 Jun 2025 11:38:57 GMT

On 12.06.2025 05:21, William F Pokorny wrote:
> (*) - The declare feature identifiers, image_width, image_height and 
> maybe a half dozen more 'apparent keywords' are, internally, unprotected 
> identifiers. This is an opening for difficult SDL bugs. This said, I 
> don't plan to delete these 'apparent keywords' any time soon. I do plan 
> to remove the declare option.

There is a good reason these are identifiers and not keywords (any 
more). The architecture had a lot of separation issues in POV-Ray 3.6, 
MegaPOV and before that kept getting worse, and prohibited a lot of 
features that are useful.

The most notable is that the scene and the rendering can be separated. 
That is, you do not need to re-parse a potentially complex scene for 
hours just the render it in a higher resolution. There isn't even a 
reason to not move the camera after parsing (as the real-time 
ray-tracing feature shows).

The main problem has always been that a GUI was never developed for 
these features. So the question you probably want to ask yourself it if 
it really makes sense to throw all this overboard for an extremely 
complex command-line interface...?

[William F Pokorny] User changes. yuqk / v4. Options re-work status. [301 days 17 hours and 13 minutes ago]

Thu, 12 Jun 2025 03:21:27 GMT

User changes. yuqk / v4. Options re-work status.

The current output related option(s):

declare=<name>= <float or string> value only

become(s):

+-ub_   user_bool_filename=    string value only
+-ui_   user_int_filename=     string value only
+-uf_   user_flt_filename=     string value only
+-us_   user_str_filename=     string value only
+-uv2f_ user_vec2d_filename=   string value only
+-uv3f_ user_vec3d_filename=   string value only
+-uv4f_ user_vec4d_filename=   string value only
+-uv5f_ user_vec5d_filename=   string value only
+-um_   user_matrix_filename=  string value only

Add set of standard user boolean switch names.
  +-uof_00  user_on_off_00=   on|off

+-ux_    user_execute_filename= string value only
          (Thought is to let users create user input files
           with whatever scripting, programming language
           they wish during options parsing)

Only the rough outline above. No integrated code. (I have a couple 
standalone test file parsing programs running)

I'll mention here, one of the aims of these option updates is to make 
nearly all (all?) option settings available via new inbuilt functions in 
the parser(*). An option name string being passed as the query key. In 
limited testing this works, but I've not implemented / tried the vectors 
or matrix stuff above. Those will need more code to truly be integrated 
during parsing.

The overall thinking is to implement something more powerful than 
'declare=...'.

The filenames used would be space delimited and use ascii-string(fast) 
(or maybe std::string utf8) keys. The same inbuilt functions used as 
option settings at parse time would be used to access these values by 
key(**), while new inbuilt functions would be required to support vector 
/ matrix input (or direct use?).

Aside: Values set with these user files would be guaranteed, top level, 
read only, 'globals'. There are outstanding issues with the v3.8 global 
dictionary implementation that I've never gotten sorted. (I believe the 
local dictionary implementation in V3.8 is OK / clean.)

Bill P.

(*) - The declare feature identifiers, image_width, image_height and 
maybe a half dozen more 'apparent keywords' are, internally, unprotected 
identifiers. This is an opening for difficult SDL bugs. This said, I 
don't plan to delete these 'apparent keywords' any time soon. I do plan 
to remove the declare option.

(**) - Yes, need sanity checking to be sure users don't try to set 
'option strings' via any of these user input files...

[William F Pokorny] Misc. changes. yuqk / v4. options re-work status. [301 days 18 hours and 11 minutes ago]

Thu, 12 Jun 2025 02:22:40 GMT

The current output related option(s):

+-v  verbose        on|off
+-mv version        float   value only
+-wt work_threads   integer value only

become(s):

+-trk  track        on|off             (track_progress ?)
+-v    version      float  value only
+-wt   work_threads integer value only

Parsing code in place. May further twiddle.

Bill P.

[William F Pokorny] Quality changes. yuqk / v4. options re-work stat... [301 days 18 hours and 14 minutes ago]

Thu, 12 Jun 2025 02:19:44 GMT

The current output related option(s):

+-q  quality     integer  value only (1 to 12)
                  Has long not matched documentation.


become(s):


+-ambient       ambient      on|off  Modified
+-emission      emission     on|off  Modified
+-quick_colr    quick_colr   on|off   keep?
+-shadows       shadows      on|off
+-area_lights   area_lights  on|off
+-refractions   refractions  on|off
+-reflections   reflections  on|off
+-normals       normals      on|off
+-media         media        on|off
+-radiosity     radiosity    on|off  (in radiosity group?)
+-photons       photons      on|off  (in photons group?)
+-subsurface    subsurface   on|off  (in subsurface group?)

+-patterns        patterns        on|off  NEW (value_patterns?)
+-fog             fog             on|off  NEW (Break out depth?)
+-phong           phong           on|off  NEW
+-specular        specular        on|off  NEW
+-phong_odebla    phong_odebla    on|off  NEW
+-specular_odebla specular_odebla on|off  NEW
+-adc_bailout     adc_bailout     float   NEW

Only the rough outline above exists; No code. The quality level today 
gets unrolled into the top block of individual controls internally. So, 
the control code for these new options often already exists.

These options are all trace time things. Any actual implementation will 
likely have option names like trace_normals or similar to keep them 
grouped together.

Rather than a quality setting value, users could pick from shipped 
quality ini files. Like: quality_09.ini, etc.

Aside: When the radiosity and photons options were implemented, quite a 
few trace options ended up duplicated. I'll bet some like adc_bailout 
are pretty much always used at the core trace time adc_bailout setting - 
so I'll be looking at dropping replicates when I get to pushing the 
global radiosity{}, photons{} and subsurface{} blocks out of the parser 
and into the options setting code.

There is too area_illumination which is expensive and due a flag, but 
I'm unsure at the moment whether it ended up rolled into the area_lights 
quality control, so it's not yet listed above.

Aside 2: It seems odd we ended up with 'quality normal' control without 
something similar for by-passing the value pattern code.

Bill P.

[William F Pokorny] Scene changes. yuqk / v4. Options re-work status. [301 days 18 hours and 52 minutes ago]

Thu, 12 Jun 2025 01:42:28 GMT

The current output related option(s):

+-i   input_file_name
+-hi  include_header
+-ini include_ini
       pre_scene_command
       pre_scene_return
       post_scene_command
       post_scene_return


become(s):


+-sf_   scene_filename     string value only
+-sh_   scene_header       string value only
+-si_   scene_ini          string value only
+-ssi   scene_stdin        on|off             NEW
+-sn_   scene_name         string value only  NEW
+-sprc_ scene_pre_command  string value only
+-sprr_ scene_pre_return   string value only
+-spoc_ scene_post_command string value only
+-spor_ scene_post_return  string value only

Parsing code mostly there.

The stdin in option is a feature which has been requested over the 
years. I'll need to learn how other programs do this well. (I'll be 
thinking too about whether something similar might replace problematic 
parse_string hack).

We are often using the MS ini file editor syntax highlighting (without 
extra user set up Linux / Unix VIM users get the wrong syntax support 
too). Our .ini file format is similar, but not a strict match for it. I 
plan to start with much more restrictive .ini file support with the 
options changes above.

- No section support. Long ago, with much more restrictive file systems, 
there was a reason for this trick.

- All the .ini file inclusions will require using an ini option of flag. 
The yuqk fork has already implemented much of this change.

- No recursive inclusion (there was a thread some months back which 
touched on this being allow to some overall depth limit today). Also 
toying with not allowing ini files to include other ini files, but we'll 
see. It would make users ini option issues easier to debug/sort.

Bill P.

[William F Pokorny] Image changes. yuqk / v4. Options re-work status. [301 days 19 hours and 13 minutes ago]

Thu, 12 Jun 2025 01:20:46 GMT

The current output related option(s):

+-h  height                   integer  value only
+-w  width                    integer  value only
+-mi max_image_buffer_memory  integer  value only

become(s):

+-ih  image_height            integer  value only
+-iw  image_width             integer  value only
+-ibm image_buffer_max        integer  value only

Parsing code mostly there, nothing else.

Some ideas floating around about about fewer / different internal 
storage formats which would likely drive new options in this 
family/grouping.

One idea - mentioned a few places in the code by prior coders too - is 
having r,g,b plus rt gt bt channels internally rather than only one 
universal transmit (alpha channel) value as a result. It would likely 
make easier limited compositing of individual features in a way which 
would not fly well beyond the zero to one (represent-able) range. The 
phong, specular features - for example - would use up each of the 
individual transmit channels as they maxed out. (Yuqk has that 
experimental 'intensity_max' finish feature which comes at the problem 
in other ways).

An internal format which aligns more directly with our perceptual range 
for intensities and/or display/print gamuts is attractive (on the 
surface at least) too - especially when looking at some of the output 
curves we might support with the avif image format for example.

Bill P.

[William F Pokorny] Re: Render changes. yuqk / v4. Option re-work st... [305 days 5 hours and 34 minutes ago]

Sun, 8 Jun 2025 15:00:31 GMT

On 6/8/25 10:43, William F Pokorny wrote:
> +-rÂ Â Â Â 
renderÂ Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â 
on|offÂ Â Â Â Â Â Â Â Â Â Â Â Â Â 
NEW

Ugh. That line should have read:

  +-render render                 on|off               NEW

I think for the moment, I'll stop my status updates here. I'm now on the 
edge of the work I have implemented, parsing code, wise.

Bill P.

[William F Pokorny] Render changes. yuqk / v4. Option re-work status. [305 days 5 hours and 51 minutes ago]

Sun, 8 Jun 2025 14:43:23 GMT

The current render related options:

+-rp render_pattern
+-rs render_block_step
+-bs render_block_size
+-c  continue_trace
+-cc create_continue_trace_log
+-ec end_column    (pct and integer specs)
+-er end_row       (pct and integer specs)
+-sc start_column  (pct and integer specs)
+-sr start_row     (pct and integer specs)
      (Single, hard coded color conversion to gry)

become:

+-r     render                 on|off               NEW
+-rp    render_pattern         integer value only
+-rbstp render_block_step      integer value only
+-rbsz  render_block_size      integer value only
+-rc    render_continue        on|off
+-rcl   render_continue_log    on|off
+-rec   render_end_column      integer on|off plus value
+-rer   render_end_row         integer on|off plus value
+-rsc   render_start_column    integer on|off plus value
+-rsr   render_start_row       integer on|off plus value
+-rgm_  render_gry_method      string  value only  NEW
           (ci111,ci240,ci601,ci709,ci2020)

Aims / thinking :

- Mostly renaming.

- Adding flag indicating whether or not to run the render stage/module.

- Removing the percentage specifications for the start/end/col/row 
options. I "think" the yuqk fork fixed the last of the bugs due trying 
to accommodate the percentages and numbers on the same flag, but the 
code remains ugly. If it's decided later this feature essential, another 
set of flags which specifically supports it should be added.

- Biggest planned change is making the render/tracing color conversions 
to grey select-able at render time. Including here perhaps a development 
mode hard coding a dummy value - or, maybe, using the green channel 
directly. Maybe look too, at something better than our current grey 
weighted 'conserve_energy', for example.

- Off on the horizon is perhaps moving away from / extending or changing 
the render block mechanism. Thinking about optimizations for the 
'locality of references' and maybe a mode which skips blocks if they 
exceeds some multiple of all the average time used to render blocks thus 
far. I have in mind too multiple camera driven over-sampling methods 
which won't work with the current render blocks mechanism. Dreaming...

Code wise, the parsing code itself for these is only partly done.

Bill P.

[William F Pokorny] Re: Library changes. yuqk / v4. Option re-work s... [305 days 7 hours ago]

Sun, 8 Jun 2025 13:34:12 GMT

On 6/6/25 14:10, William F Pokorny wrote:
> yuqkpath_camerasÂ Â  +-yplit_

Proof that section isn't coded / is me just dreaming... Should have read:

yuqkpath_cameras +-ypcam_

Bill P.

[William F Pokorny] Unix option changes. yuqk / v4. Option re-work s... [305 days 10 hours and 11 minutes ago]

Sun, 8 Jun 2025 10:23:29 GMT

The current output related options:

--preview|-y

--authors|-authors
--generation
--help|-help|-h|-?
--libraries|-libraries
--license|-license
--version|-version|--V

$POVCON
$POVINC
$POVINI

become:

+-dm_ display_method

--authors
--compilation_settings
--generation
--help
--image_formats
--libraries
--license
--optimizations
--version

Aims / thinking :

- Yes. In general my options work is moving from the current yuqk fork 
options to what I think v4-ish ones should be. This more apparent with 
these basic 'unix' ones given the prior yuqk work long implemented.

- As with the existing yuqk implementation, trying to cut down on the 
routine defaulted output while providing users direct answers to 
specific requests for information.

- I'd extended yuqk's environment variable support initially, but I 
think it not strictly needed; It makes too for conceptual clutter both 
inside the code base and for users.

- These options are now fully part of the new options parsing module.

- No specific option for it, but there is change in error message when 
yuqk/povray called with no arguments.  In recent official POV-Ray 
versions we get two repeated messages about no input file (in yuqk one), 
but I believe a cleaner message suggesting the user try --help better.

Code wise, except for clearing out a couple prior ways to do these 
unix-ish options (and part of the optimizations reporting determined at 
run time(*)), is done.

Bill P.

(*) - The CPU specific, hand coded, optimizations.

I'm toying on and off with dropping this code from yuqk.

As mentioned in a bug posting, the code isn't working in official 
POV-Ray for recent (last several years) g++ builds. I implemented a 
patch in the yuqk code to fix this. This code is nice to have as a user, 
but it's also something more to support - which doesn't strictly need to 
be supported.

The reality is the hand coded optimizations we have are of much less 
general benefit to us than the official POV-Ray benchmark suggests... 
(The yuqk fork, long ago, dropped all the inbuilt benchmark support.)

There are too questions with with future CPU directions in that it looks 
like vendors are moving away from avx512 support, for example, in the 
lower end, user, CPUs. Guessing this power driven given the more cores / 
low power cores direction with user offerings. Maybe, it's part 
marketing too - adding reasons to go for server-ish class CPUs over 
something cheaper. In any case, the direction itself makes supporting 
CPU specific optimizations less attractive for those supporting the code 
bases to do it.

[William F Pokorny] output changes. yuqk / v4. Option re-work status. [305 days 20 hours and 19 minutes ago]

Sun, 8 Jun 2025 00:14:38 GMT

The current output related options:

     bits_per_color bits_per_colour
     grayscale_output greyscale_output
+-f output_file_type  (b|c|e|h|j|n|p|t)
+-fb +-fc +-fe +-fh +-fj +-fn +-fp +-ft
+-fbg +-fcg +-feg +-fhg +-fjg +-fng +-fpg +-ftg
+-fn1 +-fn2 +-fn3 +-fn4 +-fn5 +-fn6 +-fn7 +-fn8 +-fn9 +-fn10
+-fn11 +-fn12 +-fn13 +-fn14 +-fn15 +-fn16
+-fp1 +-fp2 +-fp3 +-fp4 +-fp5 +-fp6 +-fp7 +-fp8 +-fp9 +-fp10
+-fp11 +-fp12 +-fp13 +-fp14 +-fp15 +-fp16
+-fng1 +-fng2 +-fng3 +-fng4 +-fng5 +-fng6 +-fng7 +-fng8 +-fng9
+-fng10 +-fng11 +-fng12 +-fng13 +-fng14 +-fng15 +-fng16
+-fpg1 +-fpg2 +-fpg3 +-fpg4 +-fpg5 +-fpg6 +-fpg7 +-fpg8 +-fpg9
+-fpg10 +-fpg11 +-fpg12 +-fpg13 +-fpg14 +-fpg15 +-fpg16
   (We are currently cheating in not explicitly supporting a
    .pgm format though we write one to .ppm. OK due header encoding)
+-o +-o- output_to_file output_file_name  (out directory in this too)
    file_gamma  (srgb|bt709|bt2020,<float>)
    compression 0 or 1, 2-100
      (odd RLE compression mode with file type 'c' and 'compression')
      (odd ascii vs binary switch with 0 or 1 values for .ppm / .pgm)
+-th dither
      dither_method = (b2|b3|b4|bn|bnx|at|bk|d1|d2|fs|jn|s2|s3|st)
+-ua output_alpha


become (punch ones):


+-p     punch                    on|off
+-pa    punch_alpha              on|off
+-pbpc  punch_bits_per_channel   integer value only
+-pcm_  punch_compression_method string  value only
           (ascii,binary,rle)
+-pcv   punch_compression_value  float   value only 2-100
+-pd    punch_dither             on|off
+-pdm_  punch_dither_method      string  value only
           (b2|b3|b4|bn|bnx|at|bk|d1|d2|fs|jn|s2|s3|st)
+-pgc_  punch_gamma_curve        string  value only
           (srgb|bt709|bt2020|linear|power)
+-pgv   punch_gamma_value        float   value only
+-pgm_  punch_gry_method         string  value only
           (ci111,ci240,ci601,ci709,ci2020)
+-pgs   punch_gry_scale          on|off
+-pif_  punch_image_format       string  value only
           (bmp,exr,hdr,jpg,png,ppm,tga)
+-ppe_  punch_path_extension     string  value only
+-ppf_  punch_path_filename      string  value only
+-ppp_  punch_path_parent        string  value only
+-pps_  punch_path_stem          string  value only
+-ps    punch_stdout             on|off
+-pmd   punch_meta_data          on|off
+-pmf_  punch_meta_filename      string  value only

Initially I'll be mapping the above options back to existing 
functionality. Setting up for the longer term.

Aims / thinking :

- See display option set for notes on like options.

- The flag combinations are already a bit out of control even though we 
are are today writing both .pgm and .ppm formats to .ppm. I've use them 
quite a bit and I still get tangled up.

- Looking to add support for new / actual formats (.avif, depth(already 
coded in yuqk. Likely written as .pfm but maybe with a .depth 
extension), (flesh out .pfm real time capture in yuqk) true .pgm).

- With respect to the bit depth it sank in over time this is not 
completely an image format specific thing. The formats which officially 
support depth are still encoding the depths in one byte or two bytes 
stored fields (excepting .pgm .ppm ascii). A big part of the benefit of 
shallower depths is that the compression works much better. This itself 
useful while developing scenes / animations and it can be done 'inside' 
whatever bit depth(s) the image file supports.

- The punch_path_* set maps directly to c++17, std::filesystem features. 
Trying to get to less tangled, still optional, explicit control of 
output names.

- Unsure how the meta data stuff might work. I've not thought much about 
it. Some options there, but it's just intent/dreaming at present.

- In adding an explicit compression method, making it possible to 
support other compression methods available, today, in some image formats.

Code wise the parsing is mostly there, but nothing is wired up.

Bill P.

[William F Pokorny] Display changes. yuqk / v4. Option re-work status. [306 days 2 hours and 55 minutes ago]

Sat, 7 Jun 2025 17:38:39 GMT

The current display related options:

+-d     display
+-th    dither  (Same settings used for file output)
         dither_method (strings as below)
         display_gamma (srgb|bt709|bt2020|value)
-y, --preview
+-p     pause_when_done
+-ep    preview_end_size
+-sp    preview_start_size

become:

+-d     display                    =on|off
+-da    display_alpha              =on|off            NEW
+-dbpc  display_bits_per_channel   integer value only NEW
+-dd    display_dither             on|off             NEW
+-ddm_  display_dither_method      string  value only NEW
           (b2|b3|b4|bn|bnx|at|bk|d1|d2|fs|jn|s2|s3|st)
+-dgc_  display_gamma_curve        string  value only NEW
           (srgb|bt709|bt2020|linear|power)
+-dgv   display_gamma_value        float   value only NEW
+-dgm_  display_gry_method         string  value only NEW
           (ci111,ci240,ci601,ci709,ci2020)
+-dgs   display_gry_scale          on|off             NEW
+-dm_   display_method             string  value only NEW
           (x11,sdl,text)
+-dp    display_pause              on|off             NEW
+-dpes  display_preview_end_size   integer on|off Value NEW
+-dpss  display_preview_start_size integer on|off Value NEW
+-ds    display_stdout             on|off               NEW PLAY

Initially I'll be mapping the above options back to existing 
functionality. Setting up here for the longer term.

Aims / thinking :

- The alpha setting should show in the preview window too, but it's not 
happening today. (Change here likely tangled in how partial image 
renders are handled too with respect to image parts outside the partial)

- Setting up for a much more independent preview display module.

- Align the 'module' options reasonably well with an output (punch) 
module option set.

- The gamma / dither options are relatively costly, especially, where 
the frame renders are quick.

- Dithering for a preview display might well be different than that used 
for file output headed to a printer.

- Setting up more generally for other additional correction curves (wide 
gamut) with more value inputs.

- The preview display module/work could more easily use available gpus. 
Other open source software is doing this.

- We have stdout (pipe out) capability today with the overloaded +o- 
syntax, but thinking an implementation less tangled is better.

- The preview start and end stuff is really used only by the radiosity 
code today. With modern computers there isn't much need for this sort of 
mosaic preview. Capturing mosaic previews, however, is probably useful. 
No options for this are defined as yet - though I have some ideas.

- The different grey conversions are configurable as build options today 
in the yuqk code base. Plus, yuqk in using rgb channel intensities from 
bt709 as the default configuration differs from the channel intensities 
used by official POV-Ray which are near CCIR Recommendation 601-1, but 
different. There are too wide gamut flavors out there, but not yet in 
any POV-Ray version of which I'm aware.

- Thinking some about options for setting initial preview sizes 
differing from the image size. Maybe window positioning too. Early 
versions of POV-Ray had support for these as X11 based options.

- Thinking about a -into <window id> X11 capability. (About multiple 
intos from multiple cameras truth be told... Using POV-Ray for cheap and 
easy GUIs, but dreaming or having nightmares - not sure)


Code wise the parsing is mostly there, but nothing is wired up.

Bill P.

[William F Pokorny] Bounding changes. yuqk / v4. Option re-work stat... [306 days 4 hours and 35 minutes ago]

Sat, 7 Jun 2025 15:58:38 GMT

The current bounding related options:

+-b  bounding
+-bm bounding_method  (1|2)
+-mb bounding_threshold
      bsp_baseaccesscost
      bsp_childaccesscost
      bsp_isectcost
      bsp_maxdepth
      bsp_misschance
+-ur remove_bounds
+-su split_unions


become:

+-b      bounding                     = on|off
+-bm_    bounding_method              = string  valueonly
            (slab|bsp)
+-bt     bounding_threshold           = integer valueonly
+-bbbac  bounding_bsp_baseaccesscost  = float   valueonly
+-bbcac  bounding_bsp_childaccesscost = float   valueonly
+-bbic   bounding_bsp_isectcost       = float   valueonly
+-bbmd   bounding_bsp_maxdepth        = integer valueonly
+-bbmc   bounding_bsp_misschance      = float   valueonly
+-bruc   bounding_remove_user_coded   = on|off
+-bsu    bounding_split_unions        = on|off

Here mostly setting up for the future as I'd like to try some additional
bounding methods including a modification of the current bsp option.

There is some odd merge{} related bounding code which is to my eye too 
quick to push all the shapes in a merge into the infinite object bucket, 
but maybe I don't understand what is really happening or why.

The yuqk bounding is already somewhat different than that in the 
official code. It uses 64 bit floats over 32 bit floats for one - and
it restores the v3.6 and prior versions ability to turn bounding 
completely off which was lost (or removed?) in the v3.7 or v3.8 official 
code. FWIW, I guess.

Code wise the parsing is mostly there, but nothing is wired up.

Bill P.

[William F Pokorny] Re: animation, rtr changes. yuqk /v4. Option re-... [306 days 21 hours and 16 minutes ago]

Fri, 6 Jun 2025 23:17:55 GMT

On 6/6/25 19:00, William F Pokorny wrote:
> within a fixed scene->frame(*)

Forgot the footnote...

(*) There is in the code the structure: scene->frame(->view). However, 
the view related code looks to be more or less sitting there doing not 
much. My guess is the view code was originally aimed at a camera list 
like use too but was never fleshed out - but I'm guessing.

Bill P.

[William F Pokorny] animation, rtr changes. yuqk /v4. Option re-work. [306 days 21 hours and 34 minutes ago]

Fri, 6 Jun 2025 23:00:08 GMT

The real time raytracing runs within the frame's context and is 
therefore tangled with the animation mechanism.

The current animation related options:

+-k   clock
+-ki  initial_clock
+-kf  final_clock
+-kfi initial_frame
+-kff final_frame
+-kc  cyclic_animation
+-stp frame_step
+-sf  subset_start_frame
+-ef  subset_end_frame
       pre_frame_command
       pre_frame_return
       post_frame_command
       post_frame_return

become:

+-an      animation                        boolean  on|off    NEW
+-anm_    animation_method                 string   ValueOnly NEW
           (default|clock_only|frame_only|camera_list)
+-ancv    animation_clock_value            float    ValueOnly
+-anci    animation_clock_initial          float    ValueOnly
+-ancf    animation_clock_final            float    ValueOnly
+-anfv    animation_frame_value            integer  ValueOnly
+-anfi    animation_frame_initial          integer  ValueOnly
+-anff    animation_frame_final            integer  ValueOnly
+-anl     animation_loop                   boolean  on|off
+-anfs    animation_frame_step             integer  ValueOnly
+-ansfi   animation_subset_frame_initial   integer  ValueOnly
+-ansff   animation_subset_frame_final     integer  ValueOnly
+-anfprc_ animation_frame_pre_command      string   ValueOnly
+-anfprr_ animation_frame_pre_return       string   ValueOnly
+-anfpoc_ animation_frame_post_command     string   ValueOnly
+-anfpor_ animation_frame_post_return      string   ValueOnly

The current real time raytracing options:

+-rtr  real_time_raytracing
+-kla  clockless_animation
+-kc   cyclic_animation (As used too by yuqk's rtr)
+-rtc  real_time_capture

become:

+-ms   movieshow                bool   On|Off
+-msm_ movieshow_method         string valueonly
        (camera_list, image file list, etc)
+-msl  movieshow_loop           bool   On|Off
+-msfc movieshow_frame_capture  bool   On|Off
+-msfd movieshow_frame_delay    float  valueonly  NEW

Here too just the options parsing part is coded.

We have this thing called real time raytracing - and to a degree it is. 
Ours is purely camera list driven today. We are moving through a scene 
by changing cameras within a fixed scene->frame(*). Or in yuqk, it can 
be used to render and capture from say 6 different cameras within each 
frame of a running animation. The kinda thing where in video editing 
you'd finalize what camera views to paste together for a final video.

The camera list is created any time there are a list of camera{}s in a 
scene. In non-animations or regular animations you'll get a multiple 
cameras defined warning (and something about using the last one IIRC). 
If you turn on 'clockless_animation' you can flip to the first in the 
list an visa versa as a trick we can use today for command line 
switching between two cameras.

Part of the idea in adding in these changes is to flesh out this 
mechanism so that cameras from the list can be generally selected. And 
this relates to the idea of allowing the definition of camera lists 
prior to the parsing stage too.

Why 'movieshow'? Well the mechanism can, for example, be made to do flip 
book animations from a list of image files. Or if rendering animation 
frames, it could run a movieshow from the starting frame to the just 
finished one to provide a preview animation without having to encode 
anything as an animation.  I'd like to create some sort of ms specific 
clock value use-able with functions to enable more than just camera 
movement. I think the mechanism can be more than it is currently.

Bill P.

[William F Pokorny] Re: General stream changes . yuqk / v4. Option r... [307 days 1 hour and 45 minutes ago]

Fri, 6 Jun 2025 18:49:23 GMT

On 6/6/25 12:54, jr wrote:
> nightmares, I should not wonder..  will there be a "POV-Ray Yuqk option
> translate" ("Peyote" :-)) utility ?

:-) Yep. Pretty much every day working on this I feel like quitting 
again. But, I cannot shake that an options re-work needs to happen for 
v4 and the game I want to personally play, so I'm trying hard to push 
through to something 'new-working' this time around.

As for auto-translators I have thought about them, but more in the 
context of all the SDL changes I've made than with these options changes.

Those using the shipped vim highlighting will have an idea about most of 
what is now in error new or so on in SDL, but of course not everyone 
uses vim. Plus, I couldn't figure out how to get the (non-language 
based) syntax checking to flag certain things reliably.

My POV-Ray option sets are relatively small 10 or less - a page or two 
at most - so I think updates should mostly be quick with the new code 
telling me what to do. Do other have really huge option sets for some 
reason I missed?

The moves of the photon and radiosity block settings from the parser to 
options parsing will be more work, but also pretty much one for one by 
name(*). With these settings in options I guess the option sets will be 
larger as used, though, I hope in the end people will just be able to 
mostly reference different, say, radiosity quality levels by pre-shipped 
file settings.

Aside: One thing I should have mentioned is all of the different _level 
settings could be combined into two (one each for message/trouble). 
There are a bunch of them currently because it helps me while developing 
to be able to look at things by sets / types.

Bill P.

(*) - Expect some around long enough to know some the radiosity settings 
will be moving back into the options stage where they were initially.

[William F Pokorny] Anti-alias changes. yquk / v4. Option re-work st... [307 days 2 hours and 5 minutes ago]

Fri, 6 Jun 2025 18:28:48 GMT

The AA options:

+-a   antialias
       antialias_threshold
+-ac  antialias_confidence
+-ag  antialias_gamma
+-am  antialias_method
+-r   antialias_depth
+-rd  antialias_min_depth
+-ss  stochastic_seed
+-j   jitter
       jitter_amount

become:

+-a   antialias
+-at  antialias_threshold
+-ac  antialias_confidence
+-ag  antialias_gamma
+-am  antialias_method
+-ad  antialias_depth
+-adm antialias_depth_min
+-ajs antialias_jitter_seed
+-aj  antialias_jitter
+-aja antialias_jitter_amount

Here the parsing is in place, but it's not wired up.

Bill P.

[William F Pokorny] Library changes. yuqk / v4. Option re-work status. [307 days 2 hours and 24 minutes ago]

Fri, 6 Jun 2025 18:10:10 GMT

Replacing:

+-l library_path=

initially with:

+-ypdoc_  yuqkpath_doctxt
+-ypfon_  yuqkpath_fonts
+-ypinc_  yuqkpath_includes
+-ypopt_  yuqkpath_options
+-ypsce_  yuqkpath_scenes

These will likely be mapped back to the old, single library_path code 
internally at first. Only the parsing code is in place currently.

The primary reason for the different names is, while yuqk has been 
bending away from official POV-Ray code for a long time, this next 
release is breaking. New "library_path" support is required so not to be 
tangled at all with other POV-Ray (or older yuqk) builds/installs.

The options above more or less align with either the linux debian based 
official 'POV-Ray' package and install partitioning which already exists 
and/or directories which already exist in old-style / personal build 
installs.

---

A secondary reason to move toward additional library paths has to do 
with enabling later support for certain compiled / pre-digested things 
which the we can just reference in the parser:

yuqkpath_cameras   +-yplit_
yuqkpath_colors    +-ypcol_
yuqkpath_finishes  +-ypfin_
yuqkpath_pigments  +-yppig_
yuqkpath_textures  +-yptex_
yuqkpath_interiors +-ypint_
yuqkpath_materials +-ypmat_
yuqkpath_lights    +-yplit_
yuqkpath_images    +-ypimg_
yuqkpath_macros    +-ypmcr_
yuqkpath_ies       +-ypies_
yuqkpath_ldt       +-ypldt_
yuqkpath_meshes    +-ypmsh_

This last me just dreaming at this point, but other tools do support 
pre-read/compiled stuff in this sort of way and it's certainly been 
requested over time for images and large meshes, especially.

I think too it's easier to do some things like transformable user 
function cameras as compiled camera ray collections.

Bill P.

[jr] Re: General stream changes . yuqk / v4. Option r... [307 days 3 hours and 39 minutes ago]

Fri, 6 Jun 2025 16:55:00 GMT

hi,
William F Pokorny <ano### [at] anonymousorg> wrote:
> The options:
> All of the following:
> ...
> have been replaced with a message set of streams and a trouble set of
> streams further grouped by a 'modular grouping':
> ...
>
> The _level is ... except ...

</sigh>

> ...
> I have some dreams ...

nightmares, I should not wonder..  will there be a "POV-Ray Yuqk option
translate" ("Peyote" :-)) utility ?


regards, jr.

[William F Pokorny] General stream changes . yuqk / v4. Option rewor... [307 days 4 hours and 19 minutes ago]

Fri, 6 Jun 2025 16:15:22 GMT

The options:

All of the following:

+-ga all_console       all_file
+-gd debug_console     debug_file
+-gf fatal_console     fatal_file
+-gr render_console    render_file
+-gs statistic_console statistic_file
+-gw warning_console   warning_file
+-gp append_file

and

+-wl warning_level

have been replaced with a message set of streams and a trouble set of 
streams further grouped by a 'modular grouping':

+m_af_   -m_af_   message_animation_filename
+m_al    -m_al    message_animation_level
+t_af_   -t_af_   trouble_animation_filename
+t_al    -t_al    trouble_animation_level

+m_bf_   -m_bf_   message_bound_filename
+m_bl    -m_bl    message_bound_level
+t_bf_   -t_bf_   trouble_bound_filename
+t_bl    -t_bl    trouble_bound_level

+m_if_   -m_if_   message_image_filename
+m_il    -m_il    message_image_level
+t_if_   -t_if_   trouble_image_filename
+t_il    -t_il    trouble_image_level

+m_mf_   -m_mf_   message_master_filename
+m_ml    -m_ml    message_master_level
+t_mf_   -t_mf_   trouble_master_filename
+t_ml    -t_ml    trouble_master_level

+m_of_   -m_of_   message_options_filename
+m_ol    -m_ol    message_options_level
+t_of_   -t_of_   trouble_options_filename
+t_ol    -t_ol    trouble_options_level

+m_pf_   -m_pf_   message_parse_filename
+m_pl    -m_pl    message_parse_level
+t_pf_   -t_pf_   trouble_parse_filename
+t_pl    -t_pl    trouble_parse_level

+m_phof_ -m_phof_ message_photons_filename
+m_phol  -m_phol  message_photons_level
+t_phof_ -t_phof_ trouble_photons_filename
+t_phol  -t_phol  trouble_photons_level

+m_radf_ -m_radf_ message_radiosity_filename
+m_radl  -m_radl  message_radiosity_level
+t_radf_ -t_radf_ trouble_radiosity_filename
+t_radl  -t_radl  trouble_radiosity_level

+m_rf_   -m_rf_   message_render_filename
+m_rl    -m_rl    message_render_level
+t_rf_   -t_rf_   trouble_render_filename
+t_rl    -t_rl    trouble_render_level

+m_uf_   -m_uf_   message_user_filename
+m_ul    -m_ul    message_user_level
+t_uf_   -t_uf_   trouble_user_filename
+t_ul    -t_ul    trouble_user_level

The _level is a 0-8 value with 8 reporting everything and 0 nothing - 
except for the trouble streams where errors are always reported. Like 
the current code all stream output goes to stderr by default unless 
directed to a file.

Unlike, official POV-Ray output cannot be set up to be written to both 
stderr and to files. Lastly (lying), there is no all output file option. 
Lastly, the odd default naming when only using on|off strings over file 
names is being deleted.

The options parsing for these replacements streams is mostly there, but 
that's it. I have not wired them up so to speak. Additional groupings or
sub-groups might make sense too over time.

I have some dreams about versioning / version looping outputs by 
directories in general - for which there is currently no code at all, 
but with which these stream outputs would be tangled.

Bill P.

[William F Pokorny] New options module options for yuqk / v4 rework. [307 days 4 hours and 46 minutes ago]

Fri, 6 Jun 2025 15:48:03 GMT

===
+-o_c    options_capture           = on|off
+-o_cf_  options_capture_filename  =
+-o_cs_  options_capture_style     = flag|name
+-o_cm_  options_capture_mode      = set|agency|full


===
+-o_scm_ options_scan_mode         = (ascii|ascii_min_cntl|
                                       ascii_nocntl|posix_portable|
                                       unix|unix_shell_safe|
                                       utf8_RFC_3629)
+-o_scf_ options_scan_file         = <filename/path string>
+-o_sct_ options_scan_this         = <string>


===
+o_st -o_st options_state          = on|off
+o_stf_ -o_stf_                    = onoffplusvalue string
    options_state_filename          = valueonly string


===
+o_t -o_t options_test              = on|off
+o_tf_ -o_tf_                       = onoffplusvalue  str
    options_test_filename            = valueonly       str


===
+o_trc -o_trc options_trace         = on|off
+o_trcf_ -o_trcf_                   = onoffplusvalue  str
    options_trace_filename           = valueonly       str


Except for the capture options (which replace +-gi and create_ini), I'm 
mostly exposing internal module testing and tracing features as new user 
options.

Significant chunks of these are coded up, but there is still a lot to 
do.

Bill P.

[William F Pokorny] Status of yuqk / v4 options rework. [307 days 4 hours and 54 minutes ago]

Fri, 6 Jun 2025 15:40:09 GMT

I'll be much busier with real life in the coming 6-8 weeks. I believe it 
a good time for a status report.

My initial thought in early April motivated by ingo's meta thread and 
more bug reports, was to re-implement current keywords while generally 
addressing a list of issues rather than continuing to patch bugs, but as 
I got close-ish to that goal early in May, it sank in that for v4 - and 
all I want to try in yuqk - the options themselves must be re-worked 
more or less in total.

SO! I tore down what I'd done and started again. I'm still in refining 
things, but I'm getting closer to what a refined yuqk/V4 option set 
might be.

I've mentioned previously a yuqk goal is to eliminate default{} and 
global_settings{}; pushing those 'options' out of the parser and into
the options parsing and set up module.

As Chris has mentioned elsewhere, a goal for future major revisions is a 
more modular code structure. This itself drives options re-work / changes.

Aiming for utf8 support and moving file I/O to C++17's std::filesystem 
(Initially in just the options tangled code).

Where old option names might be used (and because I'll be suffering with 
these options changes too!) the new module reports errors for each old 
use case with information on what to use instead.

In separate threads to this forum I plan to detail the current option 
grouping changes so folks can think about them as a modules or groupings 
of functionality.

Lastly, if that Grizzly bear kills me during my wrestling match at the 
Alaskan, Heavy Drinking and Betting Club (AHDBC) in July, I'll have, at 
the very least, left some record of my options re-work effort thus far. 


Bill P.

[Mr] Re: POV-Ray's current internals [312 days 11 hours and 14 minutes ago]

Sun, 1 Jun 2025 09:20:00 GMT

"Mr" <m******r******at_hotmail_dot_fr> wrote:
> "ingo" <nomail@nomail> wrote:
> > Have a peek:
> > https://deepwiki.com/POV-Ray/povray
> >
> > ingo
>
> This looks precious. Any idea why are so many of the diagram boxes empty?

Sorry, the high contrast theme switched on laptop to save battery was destroying
visibility of these texts. :-D

[Mr] Re: POV-Ray's current internals [312 days 11 hours and 39 minutes ago]

Sun, 1 Jun 2025 08:55:00 GMT

"ingo" <nomail@nomail> wrote:
> Have a peek:
> https://deepwiki.com/POV-Ray/povray
>
> ingo

This looks precious. Any idea why are so many of the diagram boxes empty?

[jr] Re: POV-Ray's current internals [342 days 5 hours and 9 minutes ago]

Fri, 2 May 2025 15:25:00 GMT

"jr" <cre### [at] gmailcom> wrote:
> "ingo" <nomail@nomail> wrote:
> ...

and with "impeccable timing" Quanta has a "special issue" on all-things AI:
<https://mailchi.mp/quantamagazine.org/the-unraveling-of-space-time-4866529>


regards, jr.

[jr] Re: POV-Ray's current internals [342 days 8 hours and 29 minutes ago]

Fri, 2 May 2025 12:05:00 GMT

hi,

"ingo" <nomail@nomail> wrote:
> "jr" <cre### [at] gmailcom> wrote:
> > could you not use "our" wiki to house this .. project ?
> Sadly not, but one could link to it. ...

ah, ok, thanks for the explanation.  I made a link, for the time being from my
page, hope/trust it'll work..

regards, jr.

<https://wiki.povray.org/content/User:Jr#other_code>

[ingo] Re: POV-Ray's current internals [342 days 9 hours and 14 minutes ago]

Fri, 2 May 2025 11:20:00 GMT

"jr" <cre### [at] gmailcom> wrote:
> could you not use "our" wiki to house this .. project ?

Sadly not, but one could link to it. It's a "public service" from one of the AI
creators (https://devin.ai/) and on the deepwiki site there is no more info than
"paste a link here", as i did out of curiosity. I could not even find whether it
tracks updates to the source or that there is some kind of integration that
could be triggered.

The building of the document took some 10 minutes and failed twice. Not an easy
source to grok?

There's a lots of projects on the front page https://deepwiki.com/

ingo

[jr] Re: POV-Ray's current internals [342 days 10 hours and 29 minutes ago]

Fri, 2 May 2025 10:05:00 GMT

hi,

"ingo" <nomail@nomail> wrote:
> Have a peek:

first impressions - useful :-) only had a quick, cursory look but agree, it's
very nice.  could you not use "our" wiki to house this .. project ?


regards, jr.

[ingo] Re: POV-Ray's current internals [342 days 10 hours and 39 minutes ago]

Fri, 2 May 2025 09:55:00 GMT

Thorsten <tho### [at] trfde> wrote:
> On 02.05.2025 11:37, Thorsten wrote:
> > On 02.05.2025 09:21, ingo wrote:
> >> Have a peek:
> >> https://deepwiki.com/POV-Ray/povray
> >
> > This is cool.
>
> How much of this is AI generated, how much did you have to provide?

All of it is AI. Just provide a (github) link and wait.


ingo

[Thorsten] Re: POV-Ray's current internals [342 days 10 hours and 54 minutes ago]

Fri, 2 May 2025 09:40:33 GMT

On 02.05.2025 11:37, Thorsten wrote:
> On 02.05.2025 09:21, ingo wrote:
>> Have a peek:
>> https://deepwiki.com/POV-Ray/povray
> 
> This is cool.

How much of this is AI generated, how much did you have to provide?

[Thorsten] Re: POV-Ray's current internals [342 days 10 hours and 57 minutes ago]

Fri, 2 May 2025 09:37:04 GMT

On 02.05.2025 09:21, ingo wrote:
> Have a peek:
> https://deepwiki.com/POV-Ray/povray

This is cool.

[ingo] POV-Ray's current internals [342 days 13 hours and 9 minutes ago]

Fri, 2 May 2025 07:25:00 GMT

Have a peek:
https://deepwiki.com/POV-Ray/povray

ingo

[Bald Eagle] Re: Metadata [359 days 9 hours and 39 minutes ago]

Tue, 15 Apr 2025 10:55:00 GMT

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

> > (**) - Anything from simple value, vector, string storage (extended
> > 'declare' command capabilities) to a new, optional, first parse pass.
> > The entire 'first parse' result would be treated as persistent storage.
>
> that's a really good idea, 2-pass parsing, real "benefits" to be had.  and with
> the speed of modern machines, the user will not even notice.  nice.

We can in some respect do this via a self-including .pov file, with #if #else
#end or #switch blocks.
Identifiers that are assigned values at any stage of the parsing are persistent,
and can be modified as well.

- BW

[jr] Re: Metadata [359 days 12 hours and 14 minutes ago]

Tue, 15 Apr 2025 08:20:00 GMT

hi,

William F Pokorny <ano### [at] anonymousorg> wrote:
> On 4/14/25 07:47, jr wrote:
> >> ... I loose track of command line settings, camera settinges etc.
> > ... '~/.povray_history', to help with that.

> ...
> As to your particular '?' jr, Something like a ~/.povray_history is
> possible, but does it offer much over the terminal's command history?
> Such a file would be specific to 'povray' and I suppose more persistent?
> The generic, Linux / Unix history capability I do use heavily - to
> render again with the same flags.

I too use the BASH history, but may clear mine between "tasks".  and you're
right to question the "suitability" of a file-based approach.  perhaps the
command-line could be included when 'all_file=true', instead ?

> (**) - Anything from simple value, vector, string storage (extended
> 'declare' command capabilities) to a new, optional, first parse pass.
> The entire 'first parse' result would be treated as persistent storage.

that's a really good idea, 2-pass parsing, real "benefits" to be had.  and with
the speed of modern machines, the user will not even notice.  nice.

regards, jr.

[William F Pokorny] Re: Metadata [359 days 18 hours and 35 minutes ago]

Tue, 15 Apr 2025 01:59:13 GMT

On 4/14/25 07:47, jr wrote:
>> With a lot of test images and reuse of scenes I loose track of command line
>> settings, camera settinges etc.
> had me thinking that, at least for the *NIX builds, one could have POV-Ray dump
> its argv[] to a '~/.povray_history', to help with that.  (WFP ? :-))

Hi jr.

Phase of the moon maybe - or that many of us have tax time hangovers...

It happens, I'm about a week into another run at replacing the POV-Ray 
(yuqk), command line and ini parsing(*). I've patched bugs in the yuqk 
fork over time, but many remain.

The one probably most important for the metadata subject is that our 
current, to ini file, dump mechanism isn't covering all the options - no 
matter how options are set. Also, the thread count setting, for example, 
should probably not be captured, but always is.

The yuqk fork - given it's rapidly changing - should capture the 
particular release version too. I'm also pushing on ideas like creating 
persistent (perhaps never freed) stuff during the command line / ini 
parsing stage(**). I've not thought about how features like that might 
work with captured rendering states.

As to your particular '?' jr, Something like a ~/.povray_history is 
possible, but does it offer much over the terminal's command history? 
Such a file would be specific to 'povray' and I suppose more persistent? 
The generic, Linux / Unix history capability I do use heavily - to 
render again with the same flags.

Bill P.

(*) - I've started this effort several times over the past five years or 
so - and I've always bailed. Don't hold your breath.

(**) - Anything from simple value, vector, string storage (extended 
'declare' command capabilities) to a new, optional, first parse pass. 
The entire 'first parse' result would be treated as persistent storage.

[Bald Eagle] Re: Metadata [360 days 5 hours and 54 minutes ago]

Mon, 14 Apr 2025 14:40:00 GMT

"ingo" <nomail@nomail> wrote:

> Regarding state, maybe stop using the command line switches and start using the
> ini-file for it. That can be added in the DB / history.

I get all discombobulated with .ini files and .inc files.  I always start trying
to render the wrong file when I'm working on things.
I also need some sort of workflow roadmap that's laid out by people who already
use such tools, as I've been system-hopping due to HDD crashes and laptop
catastrophes - so I haven't ever had enough time to learn much command line fu,
or familiarize myself with the tools that are available.

So when I want to get something done, I want to stay "heads-up" and hammer out
the project, not be stuck "heads-down" trying install packages, learn
command-line tools, or basically sort out all of that low-level stuff.
It is, unfortunately, a self-reinforcing cycle.

> But with all that, I would still like some way to put user defined metadata from
> the scene file in the image.

https://news.povray.org/povray.windows/thread/%3Cweb.56d3b273af51b1d05e7df57c0%40news.povray.org%3E/?ttop=444751

Looks like you can use a post-render shell command to somehow insert the data
into the graphic file?
IIRC, there was a thread where I discussed using a shell command to overlay text
onto rendered frames . . .  it was a while ago.

- BW

[ingo] Re: Metadata [360 days 6 hours and 39 minutes ago]

Mon, 14 Apr 2025 13:55:00 GMT

"Bald Eagle" <cre### [at] netscapenet> wrote:
>
> What do we need to start making this work?
>

Regarding state, maybe stop using the command line switches and start using the
ini-file for it. That can be added in the DB / history.

To get a feel for such a thing and figure out what functionality is useful, set
up fossil on your workstation and use that. Create a working dir for a project
and add that to fossil. Then add everything you need to folders within your
working dir. This will get you one fossil file per project. Fossil is a general
tool, so it can do way more than needed, unless you want to start a forum for
every project.

You can set up a batch file that you use to start a render and that also first
commits the current state of the project to fossil. Or you use gui automation
tools to do the check in on `Alt+G` or the render button. (not sure how powerful
such tools are). Also for several editors there are fossil integration plug ins
available.

But with all that, I would still like some way to put user defined metadata from
the scene file in the image.

ingo

[Bald Eagle] Re: Metadata [360 days 7 hours and 24 minutes ago]

Mon, 14 Apr 2025 13:10:00 GMT

"jr" <cre### [at] gmailcom> wrote:
> hi,
>
> "ingo" <nomail@nomail> wrote:
> > "jr" <cre### [at] gmailcom> wrote:
> > > Tcl "starkit"s,
> >
> > https://sqlite.org/appfileformat.html
> > https://sqlite.org/affcase1.html
> >
> > What if one did something like the above. The database would contain the
> > complete current and past project in one file. Beside that one would have the
> > complete set of current versions as text files in the working dir(s). One could
> > feed POV-Ray the current text file(s) or the database and it would extract the
> > current version and render it.
>
> you're preaching to the converted </grin>.  personally, I (and I guess you)
> would like to see SQLite at the core of the "next-gen" POV-Ray.
>
>
>
> > Several of the editors out there are very configurable (language servers et al)
...
>
> but you're thinking way more "integrated" than self does.
>
>
> > With a lot of test images and reuse of scenes I loose track of command line
> > settings, camera settinges etc.
>
> had me thinking that, at least for the *NIX builds, one could have POV-Ray dump
> its argv[] to a '~/.povray_history', to help with that.  (WFP ? :-))
>
>
> regards, jr.

I like this.
A LOT.
https://sqlite.org/appfileformat.html  makes a great case, and it's very much
what I've been wanting / thinking about for a long time.

With regard to the editor and integrating things into the POV-Ray application, I
like that we can simply include an SQLite library into POV-Ray and be just about
done with it.
As for the editor, it seems to me that there has always been a very rigid
segregation between what POV-Ray DOES, and HOW the user gets / generates the
data for POV-Ray to raytrace.

I just got doing my taxes, and I had to go searching for this form, and that
table, and another Schedule, and ....
And by the time I was halfway through I was ready to declare the start of the
Second American Revolution.

Using POV-Ray can be very much like that, where I need to switch back and forth
between a drawing application, an image viewer, a spreadsheet, a PDF reader, and
my web browser in order to collect, digest, and curate the data that I need to
represent in SDL to make my scene.   Plus, I'm forever opening file folders to
open .inc files so that I can make sure I'm using the correct name of a texture
or macro, since I'm unsure of the exact placement of an underscore, or the
capitalization of the identifier.

It seems to me that with SQLite, one could use a very feature-rich editor that
could handle several file types in separate tabs, or no editor at all.

I very much like the versioning and history aspects of this as well, since one
can follow along to see the incremental changes to a scene (and even animate the
progress).  This would also allow _parallel_ versioning in a collaborative
project, so that various avenues toward the same end could be explored, and the
approaches compared and contrasted.

Further, it seems that since it's a relational database, we could easily have
documentation to pull up for keywords, macros, functions, etc., search for the
closest match to my misspelled texture or macro name, or perhaps even search for
search terms in the description of a macro or function to find what we need or
determine if it even exists at all.

And then, once the development of a scene is "complete" (is it ever?), one could
produce an optimized final version that has all of the unnecessary data stripped
out, and only the core dependencies retained.  (No one ever needs to include the
entirety of colors.inc)

And following up on jr's comments - one could likely store "state data" such as
resolution, antialiasing settings, and a host of other things for any given
"version" that one is working on.  I think it would also trivially allow the
much-requested _persistent_ values across animation frames.

And likely a lot more things that I haven't listed off the top of my head.

Am I properly understanding the capabilities?
Does what I propose make sense?

What do we need to start making this work?

- BW

[jr] Re: Metadata [360 days 8 hours and 44 minutes ago]

Mon, 14 Apr 2025 11:50:00 GMT

hi,

"ingo" <nomail@nomail> wrote:
> "jr" <cre### [at] gmailcom> wrote:
> > Tcl "starkit"s,
>
> https://sqlite.org/appfileformat.html
> https://sqlite.org/affcase1.html
>
> What if one did something like the above. The database would contain the
> complete current and past project in one file. Beside that one would have the
> complete set of current versions as text files in the working dir(s). One could
> feed POV-Ray the current text file(s) or the database and it would extract the
> current version and render it.

you're preaching to the converted </grin>.  personally, I (and I guess you)
would like to see SQLite at the core of the "next-gen" POV-Ray.

> Several of the editors out there are very configurable (language servers et al) ...

but you're thinking way more "integrated" than self does.

> With a lot of test images and reuse of scenes I loose track of command line
> settings, camera settinges etc.

had me thinking that, at least for the *NIX builds, one could have POV-Ray dump
its argv[] to a '~/.povray_history', to help with that.  (WFP ? :-))

regards, jr.

[ingo] Re: Metadata [360 days 13 hours and 49 minutes ago]

Mon, 14 Apr 2025 06:45:00 GMT

"jr" <cre### [at] gmailcom> wrote:
> Tcl "starkit"s,

https://sqlite.org/appfileformat.html
https://sqlite.org/affcase1.html

What if one did something like the above. The database would contain the
complete current and past project in one file. Beside that one would have the
complete set of current versions as text files in the working dir(s). One could
feed POV-Ray the current text file(s) or the database and it would extract the
current version and render it.

Several of the editors out there are very configurable (language servers et al),
I think one could write a program that makes the construct above feasible. With
a dedicated POV-Ray editor it should be no problem at all to work this way.

In similar vain for the documentation. Stick it in a database based ebook like
thing. When one "installes" an include file, its documentation should be added
to the database so it is available in the help reader. Keywords to the index and
with full text search and may be made available in the language server.

SQLite files are not small, but 7zip can do wonders to them (for distribution)

Just thoughts,

ingo

[jr] Re: Metadata [361 days 4 hours and 59 minutes ago]

Sun, 13 Apr 2025 15:35:00 GMT

hi,

tTh <tth### [at] noneinvalid> wrote:
> On 4/13/25 14:07, jr wrote:
> > ... scene code itself among the meta data ...
>     But what if your scene, like mine, is split into several
>     included files?

I suspect what BE has in mind is pretty close to Tcl "starkit"s, that is, some
underlying VFS which allows mounting zips / archives.  then it'd simply be your
whole project, with its own internal (sub-)directory structure, in a single
file; which I'd prefer, personally, but the "blob" could of course also be
embedded.  so much depends on what decisions will be taken wrt a future POV-Ray.

regards, jr.

[Bald Eagle] Re: Metadata [361 days 5 hours and 9 minutes ago]

Sun, 13 Apr 2025 15:25:00 GMT

tTh <tth### [at] noneinvalid> wrote:

>     But what if your scene, like mine, is split into several
>     included files?

Of course.
This is but a (simple) first step in implementing a suite of features.

What if you have meshes and HDRI light probes, and uv mapped image files, and
.....

We just proceed forward, one step at a time.

The simplest is just capturing that tricky equation, the thing that needed to be
twice differentiated, or meticulously translated to POV-Ray's crippled function
VM.  The laboriously developed texture that just captures that look.  Whatever.

Now it's saved as a part of the image that gets posted, and it's archived and
backed-up.

Then we can explore tar, gz, zip, 7z, and many other ways of collecting together
all of the elements to faithfully re-render any given scene.

- BW

[tTh] Re: Metadata [361 days 5 hours and 41 minutes ago]

Sun, 13 Apr 2025 14:53:08 GMT

On 4/13/25 14:07, jr wrote:

>> For a future version of POV-Ray it would be nice to write meta information to
>> the resulting image file.
> 
> agree.  Bald Eagle argues[*] for including the scene code itself among the meta
> data, worth considering since it could be stored compressed and wouldn't take
> much additional space.

    But what if your scene, like mine, is split into several
    included files?

-- 
**                                                            **
*                      tTh des Bourtoulots                     *
*                  http://maison.tth.netlib.re/                *
**                                                            **

[ingo] Re: Metadata [361 days 6 hours and 29 minutes ago]

Sun, 13 Apr 2025 14:05:00 GMT

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

> Also useful would be to disable overwrite of the default output filename and
> instead start writing Filename(1).png, Filename(2).png, etc.

Yes, that's an other one.

(An early version of 3DStudio had a `+` button to save the source file and thus
the rendering with an incremented number.)

ingo

[Bald Eagle] Re: Metadata [361 days 7 hours and 14 minutes ago]

Sun, 13 Apr 2025 13:20:00 GMT

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

> agree.  Bald Eagle argues[*] for including the scene code itself among the meta
> data, worth considering since it could be stored compressed and wouldn't take
> much additional space.
>
> [*] sorry, no ref.

Here's one of them:

https://news.povray.org/povray.binaries.images/message/%3Cweb.6076506a6a35d6561f9dae3025979125%40news.povray.org%3E/#%3
Cweb.6076506a6a35d6561f9dae3025979125%40news.povray.org%3E

To be 100% accurate, I argue for the OPTION or ABILITY to write the scene file
into the image.

Also useful would be to disable overwrite of the default output filename and
instead start writing Filename(1).png, Filename(2).png, etc.

Long time povvers know the dangers of rapid editing and rendering during scene
development.

- BW

[ingo] Re: Metadata [361 days 7 hours and 29 minutes ago]

Sun, 13 Apr 2025 13:05:00 GMT

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

> Bald Eagle argues[*] for including the scene code itself among the meta
> data, worth considering since it could be stored compressed and wouldn't take
> much additional space.
>

For that I would prefer an editor with build in support for fossil (and some
more), so we can have infinite redo and a tag for when an image is rendered. Of
course that editor also has the ability to read the scene file from the image
(and if it not exists create it ......)

ingo

[jr] Re: Metadata [361 days 8 hours and 24 minutes ago]

Sun, 13 Apr 2025 12:10:00 GMT

hi,

"ingo" <nomail@nomail> wrote:
> With a lot of test images and reuse of scenes I loose track of command line
> settings, camera settinges etc.
>
> For a future version of POV-Ray it would be nice to write meta information to
> the resulting image file.

agree.  Bald Eagle argues[*] for including the scene code itself among the meta
data, worth considering since it could be stored compressed and wouldn't take
much additional space.

[*] sorry, no ref.

regards, jr.

[Ilya Razmanov] Re: Metadata [361 days 12 hours and 9 minutes ago]

Sun, 13 Apr 2025 08:24:45 GMT

On 13.04.2025 8:41, ingo wrote:
> For a future version of POV-Ray it would be nice to write meta information to
> the resulting image file.

So far, you can manually write tEXt to PNG. I personally use TweakPNG, 
as a result even a web preview for my POVThread contains full text for 
isosurface used as basic element - it's small but took a lot of time to 
tweak, so I just didn't want to loose the exact parameters ;-)

BTW this would not work with ident-based Python-like format discussed 
here: tEXt loses formatting but keeps braces ;-)

-- 
Ilyich the Toad
https://dnyarri.github.io/

[ingo] Metadata [361 days 14 hours and 49 minutes ago]

Sun, 13 Apr 2025 05:45:00 GMT

With a lot of test images and reuse of scenes I loose track of command line
settings, camera settinges etc.

For a future version of POV-Ray it would be nice to write meta information to
the resulting image file.

#meta{
global settings
ini settings / switches
active_camera
user:"some text"
user:"some more text"
EXIF
IPTC
}

ingo

[ingo] Re: Curly braces replaced by indentations but on... [368 days 13 hours and 34 minutes ago]

Sun, 6 Apr 2025 07:00:00 GMT

"jr" <cre### [at] gmailcom> wrote:
> hi,
>
> "ingo" <nomail@nomail> wrote:
> > ...
> > a 4000x4000 image took 1 minute 7 seconds. Multi threaded works, the same image
> > takes 2 sec 968 ms.
> > Next, clean up and polish.
>
> had meant to comment on the image and the script, sorry for leaving it
> "hanging".  the app/library example certainly looks interesting, as does the
> result, and "no slouch" either :-).

While putting all the pieces together, the thing fell apart. The problem is that
the current set of macros in the nimscripter library does not allow to push
procs over the barrier (yet). When using a template it kind of works, but for
multi threading in the end it fails.

Regarding Nim, it's fun to use, sometimes fiddly and sometimes a bit rough
around the edges. It's under constant development by a very small team.

(just implemented https://paulbourke.net/fractals/bioblob/ in it, with export to
POV-Ray or JSON)

ingo

[jr] Re: Curly braces replaced by indentations but on... [369 days 5 hours and 19 minutes ago]

Sat, 5 Apr 2025 15:15:00 GMT

hi,

"ingo" <nomail@nomail> wrote:
> ...
> a 4000x4000 image took 1 minute 7 seconds. Multi threaded works, the same image
> takes 2 sec 968 ms.
> Next, clean up and polish.

had meant to comment on the image and the script, sorry for leaving it
"hanging".  the app/library example certainly looks interesting, as does the
result, and "no slouch" either :-).  RL (and in part lack of motivation) has so
far stopped me from revisiting the Nim  install etc, but I will keep watching
for further "developments" with interest.

regards, jr.

[ingo] Re: Curly braces replaced by indentations but on... [371 days 2 hours and 39 minutes ago]

Thu, 3 Apr 2025 17:55:00 GMT

"ingo" <nomail@nomail> wrote:
> "Mr" <m******r******at_hotmail_dot_fr> wrote:
>
> I'm working on a multithreaded version. It's about half way.
>

a 4000x4000 image took 1 minute 7 seconds. Multi threaded works, the same image
takes 2 sec 968 ms.

Next, clean up and polish.

ingo

[ingo] Re: Curly braces replaced by indentations but on... [371 days 3 hours and 19 minutes ago]

Thu, 3 Apr 2025 17:15:00 GMT

"Mr" <m******r******at_hotmail_dot_fr> wrote:

> The fact that it does work is already a huge achievement ! Ignoring the syntax I
> wonder, did you create the previous routines in POV originally? and if so, do
> you think there could be a way to compare fairly render times? Should rather
> only the parse to render ratio be considered ? with your approach, would
> separate builds have to be made afresh for every scene? About the nim script
> language, though it is said to have some removed functionality, is it still
> "Turing complete" ? ...Meaning, as much as POV/INC sdl?

The syntax can be adapted using macros. I've not tried it yet, only just started
with macros. But when you look at my code it is quite crude. It will be polished
a bit more.

No, I did it straight in Nim, but I have quite some graphics stuff in Nim to
build from. As render times are concerned, this is currently one thread and I'm
working on a multithreaded version. It's about half way.

Once done I'll compare a similar pattern, but POV-Ray will win as I so far have
no clue how to implement SIMD intrinsics. On my machine that would mean 24
thread each doing one calculation vs. 24 threads each doing ~8 calculations at
once.

One only has to build the renderer.nim once and then you can rewrite and render
many scripts on it without rebuilding.

Yes it is Turing complete, as far as I know. It has a bit of a problem with
pointers and c-libraries. It is a more capable language than POV-Ray SDL. Most
of Nim's "pure" libraries should work in script:
https://github.com/nim-lang/Nim/tree/devel/lib/pure

But, beware, I'm certainly no Nim specialist. Also, there are / must be other
languages that can do this. At least good old LISP can.

ingo

[Mr] Re: Curly braces replaced by indentations but on... [371 days 4 hours and 34 minutes ago]

Thu, 3 Apr 2025 16:00:00 GMT

"ingo" <nomail@nomail> wrote:
> "Mr" <m******r******at_hotmail_dot_fr> wrote:
> > "ingo" <nomail@nomail> wrote:
> > > "Mr" <m******r******at_hotmail_dot_fr> wrote:
>
> > I don't know enough to have an opinion about using a database oriented POV
> > workflow, which does sound very powerful, but I did have a look at the  overview
> > descriptions of the nim language, and though there are some aspects that I don't
> > naturally enjoy in its syntax, they probably are specifically the ones that
> > every one around here seem to be asking for, also the fact that it can be
> > interpreted and compiled... Well, wouldn't this make it suited to be a scene
> > description language that could get accelerated as a compiled version just
> > before parsing?
>
> Using Nim and a library nimscripter I made a simple image renderer, the way you
> suggested here. Most of the rendering procedures are compiled and are made
> available to the VM so they run at "max" speed. Math functions already run at
> max speed in the VM. This all is then available in the scripting language.
>
> In my little app you can create patterns from math functions and render those.
> You can add POV style like turbulence and gray scale mapping, instead of our
> color_map.
>
> You compile the render engine and then render the .nims scripts with it. Just
> like POV-Ray renders SDL, but without the need for writing a parser etc.
>
> It does work, but it is not a smooth path yet. Not every thing is possible
> (yet?) with this way of creating an app.
>
> https://gist.github.com/ingoogni/8e1f74f8ea7250da778a202648e96e9b
>
> the script for the image:
> ---%<------%<------%<---
> import math
>
> proc sincos(x, y: float): float =
>   return (1 + (sin(x) * cos(y))) * 0.5
>
>
> proc main() =
>
>   var img = initPGM("sincos.pgm")
>   img.gamma = srgb
>
>   let
>     gm = Pattern(
>       funk: sincos,
>       greymap: @[(0.0,0.0),(0.5,0.2),(0.8,0.7),(1.0,0.0)],
>       turbulence: (
>         strength: (x: 1.6, y: 2.2),
>         lambda: 2.5,
>         omega: 0.7,
>         octaves: 6
>       )
>     )
>     width = 640
>     height = 480
>     viewportWidth = 30.0
>     viewportHeight = 0.0
>     #viewportHeight = viewportWidth * (height / width)  # Maintain aspect ratio
>     grid = gm.render(width, height, viewportWidth, viewportHeight)
>
>   img.writePGM(grid)
>
>
> when isMainModule:
>   main()
> ---%<------%<------%<---

The fact that it does work is already a huge achievement ! Ignoring the syntax I
wonder, did you create the previous routines in POV originally? and if so, do
you think there could be a way to compare fairly render times? Should rather
only the parse to render ratio be considered ? with your approach, would
separate builds have to be made afresh for every scene? About the nim script
language, though it is said to have some removed functionality, is it still
"Turing complete" ? ...Meaning, as much as POV/INC sdl?

[ingo] Re: Curly braces replaced by indentations but on... [371 days 15 hours and 14 minutes ago]

Thu, 3 Apr 2025 05:20:00 GMT

William F Pokorny <ano### [at] anonymousorg> wrote:
> On 4/2/25 05:13, ingo wrote:
> >        turbulence: (
> >          strength: (x: 1.6, y: 2.2),
> >          lambda: 2.5,
> >          omega: 0.7,
> >          octaves: 6
> >        )
>
> Interesting. I'm impressed you implemented at 2D perlin turbulence() for
> this demo code!
>
> Bill P.

Sorry to disappoint you, a bit. I scaled down my "old" 3d version to 2d. The 3d
version is used in a slowly growing audio synthesis project where tiles with
patterns are used as the "sound source". I'm not realy happy with the
turbulence yet, it doesn't work as smooth as POV-Ray's implementation.

ingo

[William F Pokorny] Re: Curly braces replaced by indentations but on... [371 days 16 hours and 14 minutes ago]

Thu, 3 Apr 2025 04:20:20 GMT

On 4/2/25 05:13, ingo wrote:
>        turbulence: (
>          strength: (x: 1.6, y: 2.2),
>          lambda: 2.5,
>          omega: 0.7,
>          octaves: 6
>        )

Interesting. I'm impressed you implemented at 2D perlin turbulence() for 
this demo code!

Bill P.

[ingo] Re: Curly braces replaced by indentations but on... [372 days 11 hours and 19 minutes ago]

Wed, 2 Apr 2025 09:15:00 GMT

"Mr" <m******r******at_hotmail_dot_fr> wrote:
> "ingo" <nomail@nomail> wrote:
> > "Mr" <m******r******at_hotmail_dot_fr> wrote:

> I don't know enough to have an opinion about using a database oriented POV
> workflow, which does sound very powerful, but I did have a look at the  overview
> descriptions of the nim language, and though there are some aspects that I don't
> naturally enjoy in its syntax, they probably are specifically the ones that
> every one around here seem to be asking for, also the fact that it can be
> interpreted and compiled... Well, wouldn't this make it suited to be a scene
> description language that could get accelerated as a compiled version just
> before parsing?

Using Nim and a library nimscripter I made a simple image renderer, the way you
suggested here. Most of the rendering procedures are compiled and are made
available to the VM so they run at "max" speed. Math functions already run at
max speed in the VM. This all is then available in the scripting language.

In my little app you can create patterns from math functions and render those.
You can add POV style like turbulence and gray scale mapping, instead of our
color_map.

You compile the render engine and then render the .nims scripts with it. Just
like POV-Ray renders SDL, but without the need for writing a parser etc.

It does work, but it is not a smooth path yet. Not every thing is possible
(yet?) with this way of creating an app.

https://gist.github.com/ingoogni/8e1f74f8ea7250da778a202648e96e9b

the script for the image:
---%<------%<------%<---
import math

proc sincos(x, y: float): float =
  return (1 + (sin(x) * cos(y))) * 0.5

proc main() =

  var img = initPGM("sincos.pgm")
  img.gamma = srgb

  let
    gm = Pattern(
      funk: sincos,
      greymap: @[(0.0,0.0),(0.5,0.2),(0.8,0.7),(1.0,0.0)],
      turbulence: (
        strength: (x: 1.6, y: 2.2),
        lambda: 2.5,
        omega: 0.7,
        octaves: 6
      )
    )
    width = 640
    height = 480
    viewportWidth = 30.0
    viewportHeight = 0.0
    #viewportHeight = viewportWidth * (height / width)  # Maintain aspect ratio
    grid = gm.render(width, height, viewportWidth, viewportHeight)

  img.writePGM(grid)

when isMainModule:
  main()
---%<------%<------%<---

[Mr] Re: Curly braces replaced by indentations but on... [378 days 8 hours and 54 minutes ago]

Thu, 27 Mar 2025 11:40:00 GMT

John Campbell <jca### [at] lynnci-ncom> wrote:
> On 3/18/25 04:01, Mr wrote:
> > I'm sure more expert people in various languages will be able to teach me
> > something important from what is probably a naive question :  What if in POV 4
> > we had the possibility to use spaces or tabs as a synonym to what curly braces
> > currently do, but we could still use those braces themselves ?
> >
> > That way new comers would feel at first glance that the language is as easy to
> > learn as Python, and would rapidly understand as they do in Python, that what
> > matters is that they do know what scope they're in.
> >
> > and eventually, depending on *whichever* option gets to become the most popular
> > among core developers and power users, it can become a maintenance cost
> > reduction to drop one or the other?
> >
> > Inspiration for this idea? of course, python... I love how it has grown able to
> > do type annotations, switch cases, etc. and while across versions leverage many
> > advanced concepts teaching them to me as it went, and now they are there, I love
> > how a new comer could still pick it up exactly the way I did, with a human
> > readable almost fiction-book like syntax, and still produce scripts that do
> > work, syntactic-sugar-free.  BUT I know there must be a reason why those curly
> > braces are still there isn't there? so I trust people to tell me... maybe so
> > that POV acts as a launching pad to learn C-like languages in which it is itself
> > developed?
> >
>
> Significant whitespace is a terrible, terrible idea, and Guido should be
> smacked for it. Because we *knew* it was a terrible idea before Python
> was even a gleam in his eye. Makefiles taught us that years earlier.
>
> You ever had an entire build blow up because someone else on the dev
> team edited a file using different editor settings, and it introduced an
> *invisible* syntax error that took half a day to track down while
> everyone else's work ground to a halt? I have.
>
> --
> John Campbell
> jca### [at] lynnci-ncom

Sure it happens, until the ide is properly configured.

[John Campbell] Re: Curly braces replaced by indentations but on... [378 days 15 hours and 28 minutes ago]

Thu, 27 Mar 2025 05:05:49 GMT

On 3/18/25 04:01, Mr wrote:
> I'm sure more expert people in various languages will be able to teach me
> something important from what is probably a naive question :  What if in POV 4
> we had the possibility to use spaces or tabs as a synonym to what curly braces
> currently do, but we could still use those braces themselves ?
> 
> That way new comers would feel at first glance that the language is as easy to
> learn as Python, and would rapidly understand as they do in Python, that what
> matters is that they do know what scope they're in.
> 
> and eventually, depending on *whichever* option gets to become the most popular
> among core developers and power users, it can become a maintenance cost
> reduction to drop one or the other?
> 
> Inspiration for this idea? of course, python... I love how it has grown able to
> do type annotations, switch cases, etc. and while across versions leverage many
> advanced concepts teaching them to me as it went, and now they are there, I love
> how a new comer could still pick it up exactly the way I did, with a human
> readable almost fiction-book like syntax, and still produce scripts that do
> work, syntactic-sugar-free.  BUT I know there must be a reason why those curly
> braces are still there isn't there? so I trust people to tell me... maybe so
> that POV acts as a launching pad to learn C-like languages in which it is itself
> developed?
> 

Significant whitespace is a terrible, terrible idea, and Guido should be 
smacked for it. Because we *knew* it was a terrible idea before Python 
was even a gleam in his eye. Makefiles taught us that years earlier.

You ever had an entire build blow up because someone else on the dev 
team edited a file using different editor settings, and it introduced an 
*invisible* syntax error that took half a day to track down while 
everyone else's work ground to a halt? I have.

-- 
John Campbell
jca### [at] lynnci-ncom

[jr] Re: Curly braces replaced by indentations but on... [378 days 23 hours and 34 minutes ago]

Wed, 26 Mar 2025 21:00:00 GMT

hi,

"ingo" <nomail@nomail> wrote:
> "jr" <cre### [at] gmailcom> wrote:
> > wanted to take a look at nim but it's .. not for me.
>
> https://nim-lang.org/documentation.html
>
> installing on windows is ...

n/a.

> On freeBSD it's in ports/packages and it installed flawless for me.

I built a package for Slackware with the 2.2.0 source archive (high density !!
:-), expands from 7.5M to a little over 1930M), and  was "put off" by the
"litter"; building a package has never before added stuff outside the (/tmp)
designated locations, the nim build did (though that may be the maintainer's
doing, rather than an inherent thing).  also, "other, github-related gripes" ;-)

had not yet looked at FreeBSD, but will in the coming days, thx for the
reminder.

regards, jr.

[ingo] Re: Curly braces replaced by indentations but on... [379 days 1 hour and 4 minutes ago]

Wed, 26 Mar 2025 19:30:00 GMT

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

> wanted to take a look at nim but it's .. not for me.

https://nim-lang.org/documentation.html

installing on windows is straight forward except when the Anti Virus Maffia
starts to nag.

On freeBSD it's in ports/packages and it installed flawless for me.

https://nim-lang.org/install_unix.html


ingo

[jr] Re: Curly braces replaced by indentations but on... [379 days 3 hours and 19 minutes ago]

Wed, 26 Mar 2025 17:15:00 GMT

hi,

"ingo" <nomail@nomail> wrote:
> "Mr" <m******r******at_hotmail_dot_fr> wrote:
> [...] also the fact that it can be
> > interpreted and compiled... Well, wouldn't this make it suited to be a scene
> > description language that could get accelerated as a compiled version just
> > before parsing?
>
> Nims (the scripting language) does not support everything Nim does. I.i.r.c it
> does not work with dll's, etc. Interoperation with Nim the way you suggest is
> not easy, but it can be done. Nims is about as fast as Python, maybe a little
> bit slower.
>
> I do not see compilation as necessity, but it is certainly useful for include
> files that could be compiled to be plug-ins for POV-Ray. It may also be of use
> for animations.

wanted to take a look at nim but it's .. not for me.  after building the
package, not yet installed, nothing, I already find my ~/.cache directory having
a 'nim' subdirectory with tons of .. who-knows-what ?  and the main site, I
loved the look of the documentation page, but _every_ link you click, you wind
up on github ??  tja.  shame really, the idea of using macros to output SDL
appealed.

regards, jr.

[William F Pokorny] Suggest v4.0 text{} fixes / changes. (yuqk R19 v... [379 days 5 hours and 51 minutes ago]

Wed, 26 Mar 2025 14:42:41 GMT

I'm attaching yuqk fork documentation for its updated text{} object 
implementation (text.txt). Most subjects have been touched upon in other 
posts.

One not mentioned, is that the text{} and sphere{} objects have some new 
trial type checking in the debug compile of yuqk. I acted on the idea 
because text{} creates union{} or merge{} objects of single character 
text{} objects. Users cannot get at the underlying text{} objects. This 
means using text{TextID} isn't really correct - though it will mostly 
(always?) work.

Using the sphere{} as another example, it's possible today to code 
something like:

     #declare Light00 = light_source{...}
     ...
     #local SphereShiftedUp = sphere {Light00 translate ...}

and the parser will act on the light source identifier without complaint 
as a generic object.

The thinking is, perhaps, setting the parser up so users can use an 
object{} wrap where they don't care about the 'object' type being acted 
upon, but a sphere{} wrap when they want to be sure it's really a sphere 
identifier. Perhaps this a method of extending type checking over what 
is available with yuqk's setidtypes.inc and id_type(_id) capability.

(The internal method for this uses a dynamic_cast though - which is 
slow. Why this feature trial is only active in the debug compile of yuqk 
- which is already slower due the extra sanity checking it does.)

Sinking into the detail a bit more, the identifier definition and 
reference mechanisms today in the parser are less consistent than they 
should be.

We have cases where users can reference previously defined identifiers 
and modify only certain aspects of them creating a new object, texture 
or feature in an object oriented way; other cases where, for example, 
sphere{ID} is effectively the same as writing object{ID ...object 
modifiers...} - and cases like warp{}s where we'd like to be able to 
define an identifier for later reference but we cannot.

Bill P.

[William F Pokorny] Re: Suggest v4.0 experimental features [380 days 1 hour and 48 minutes ago]

Tue, 25 Mar 2025 18:46:19 GMT

On 3/25/25 14:10, Leroy wrote:
> I vote to add '#read_line' to
> the parsing stage. easy! peasy!

I've been thinking about something like #utf8_readline() and 
#utf8_writeline() in my yuqk fork playpen. These would fully support 
utf8 within the constraints of the Unicode BMP (2^16 characters).

In implementation they'd completely bypass all the input/output stuff 
and character set up in the POV-Ray source today. Every time I start to 
look at moving the current source to full utf8 support, I quickly get 
overwhelmed by the totality of conversion necessary.

Anyhow, the implementation of the two utf8_* functions would be ugly to 
start... Likely, they'd initially open and close the file on every call, 
for example.

Bill P.

[Leroy] Re: Suggest v4.0 experimental features [380 days 2 hours and 19 minutes ago]

Tue, 25 Mar 2025 18:15:00 GMT

"Leroy" <whe### [at] gmailcom> wrote:
> "Bald Eagle" <cre### [at] netscapenet> wrote:
> > #read by whole line - everything gets read into one long string.
> > This would allow user parsing of the string, regardless of data types,
> > structure, number of entries, etc.
>
> I like this Idea!
> I have been playing with pgn files, chess format file. They are fancy text
> files with a list of all the moves in a game with a lot of other information
> like the tournament, players, rankings and so on. It would be nice to read all
> that info and drop it line by line until I got to something I want.
>  Right now I do it by hand by copying text to another file and getting it sit up
> for POV to Read. I could write a C++ program to do it for me, but I like POV.
>  Right Now 3.8 can handle strings larger that 255 elements, But Can't load them
> from a file. (3.7 seem to handle strings the same way.)
>  If a line read is to complicated to do, for some reason, then a binary read
> would be almost as good. Say read so many bytes at time and return as a integer.
>
> Have Fun!

I went into the source code for the win3.6 and found that there is already a
line read function there. That reads a line and puts into a buffer. So all that
is needed is to figure out how to access the code. I vote to add '#read_line' to
the parsing stage. easy! peasy!

having Fun!

[ingo] Re: Curly braces replaced by indentations but on... [381 days 4 hours and 9 minutes ago]

Mon, 24 Mar 2025 16:25:00 GMT

"Mr" <m******r******at_hotmail_dot_fr> wrote:
[...] also the fact that it can be
> interpreted and compiled... Well, wouldn't this make it suited to be a scene
> description language that could get accelerated as a compiled version just
> before parsing?

Nims (the scripting language) does not support everything Nim does. I.i.r.c it
does not work with dll's, etc. Interoperation with Nim the way you suggest is
not easy, but it can be done. Nims is about as fast as Python, maybe a little
bit slower.

I do not see compilation as necessity, but it is certainly useful for include
files that could be compiled to be plug-ins for POV-Ray. It may also be of use
for animations.

ingo

[Mr] Re: Curly braces replaced by indentations but on... [381 days 7 hours and 24 minutes ago]

Mon, 24 Mar 2025 13:10:00 GMT

"ingo" <nomail@nomail> wrote:
> "Mr" <m******r******at_hotmail_dot_fr> wrote:
> >I'm not referring to type here which is another issue, just the
> > "declare" or "var" keyword... I don't see why it's important.
>
> A "big" difference is that in POV-Ray you have to tell a variable whether it is
> local or not. In many languages this is different. Every variable declared
> inside a block is local and it can't escape that block.
>
> So in Nim:
>
> var chicken = 1
>
> for i in 0 ..< 10:
>   let n = i + i
>   chicken += n
>
> echo chicken
> echo n # fails compilation, Error: undeclared identifier: 'n'
>
> it fails not because it is let (immutable), but because it's local.
>
> There is quite a body of research on what a good beginners language should look
> like. Python scores very high on these. One aspect in several of these
> researches made me chuckle, as I had the same problem decades ago. It is hard to
> grasp 'while' and 'for' loops (Warp wrote a tutorial on it). Using the keyword
> 'every 'makes it more understandable for novices. Another hard one is OOP except
> for the composition of records/objects.
>
> The main problem in POV-Ray is that there are two aspects to it, the 'scripting'
> part and the 'objects' part and that is actually well done. Compare it with the
> javascript 3D stuff, or Vapory https://github.com/Zulko/vapory . If one would
> repurpose an existing language for POV-Ray SDL then look for a language with
> extensive macro abilities to build a DSL so one can have a distinct render
> object sections an distinct script/code sections, similar to POV-Ray now.
>
> ingo

I don't know enough to have an opinion about using a database oriented POV
workflow, which does sound very powerful, but I did have a look at the  overview
descriptions of the nim language, and though there are some aspects that I don't
naturally enjoy in its syntax, they probably are specifically the ones that
every one around here seem to be asking for, also the fact that it can be
interpreted and compiled... Well, wouldn't this make it suited to be a scene
description language that could get accelerated as a compiled version just
before parsing?

[ingo] Re: Curly braces replaced by indentations but on... [383 days 7 hours and 9 minutes ago]

Sat, 22 Mar 2025 13:25:00 GMT

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

> Ah, and this is why if we could just have a Point *object*, then we could union
> that with an object and transform everything at once.  Inverse is already
> implemented.

Just as an idea,

#declare Thing = object{
  local_centre = <1,1,1>
  sphere{
   <2,2,2>, 1
   rotate <20,70, 3> #rotates around the origin
  }
  sphere{
    <0,0,0>, 1
    rotate_local <20,70,3> #rotates around the local_centre
  }
  rotate <33,33,3>
  rotate_local <-45,90,22>
}

global and local axis.

ingo

[ingo] Re: Curly braces replaced by indentations but on... [385 days and 54 minutes ago]

Thu, 20 Mar 2025 19:40:00 GMT

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

>
> Please enlighten me!
>

https://www.giuspen.net/cherrytree/   https://github.com/giuspen/cherrytree

https://tiddlywiki.com/ Single page web app

https://wikidpad.sourceforge.net/

An alternative way is simple text files in one directory and then a separate
directory structure with a tree of metadata tags. In those you keep the symbolic
links to documents that match the tag.

Going fancy, start your document with the tags. Write software that monitors the
tags dirs and when you copy a simlink to an other tag dir update the tags in the
original document. Same with deletions.I used such a system in the 90' and 00's
to manage my music collection.

....and that is just the beginning, if you keep the news group messages in mbox
you can simlink those too, your file syatem is a database after all .... ;)

ingo

[jr] Re: Curly braces replaced by indentations but on... [385 days 1 hour and 4 minutes ago]

Thu, 20 Mar 2025 19:30:00 GMT

hi,

"Bald Eagle" <cre### [at] netscapenet> wrote:
> "jr" <cre### [at] gmailcom> wrote:
> > I so agree, everything ought to have "sensible defaults" for all but location
> > (and perhaps size).
>
> (?)
> Well, considering the troubles people go through, 30 years in, I would say that
> a default location at the origin not only makes sense, but is desirable.
> [I always pause when I realize that torus {} doesn't take a vector location like
> sphere{}, and I have to translate it afterwards, and I still fail to provide a
> radius for cylinder when writing one from scratch.]
>
> Rotate and scale, when not at the origin, really mess with people's heads.

yes.  the "all but location" was just (habitual ?) personal perspective.


> (Which reminds me, I ought to write macros like Turn () and Resize () to
> translate objects to the origin, perform the inbuilt operation, and translate
> back to original location.  Macro names are just off the top of my head)
>
> Default sizes ought to be in reference to the unit cell, unless there's some
> specific reason to do otherwise.  Text {} defaults to 1. Image_map,
> height_field, and maybe others default to 1x1, df3 and maybe others default to
> the unit cube....
>
> I think that one of the basic themes for 4.0 ought to be consistency.
> In size, in uv-mapping vectors, in syntax, and whatever else we can manage.


regards, jr.

[Bald Eagle] Re: Curly braces replaced by indentations but on... [385 days 1 hour and 34 minutes ago]

Thu, 20 Mar 2025 19:00:00 GMT

"ingo" <nomail@nomail> wrote:

> https://www.zim-wiki.org/index.html  a desktop wiki fur such things. I has
> options /plugins for version control (even Fossil i.r.r.c)

Oh, heck yeah!!!
This is exactly the kind of thing I wanted to do - hyperlinked to documents and
files!  Potentially with multiple links to the same item.
You are a mind-reader, in a timely fashion.

> There are several similar tools like Zim

Please enlighten me!

- BW

[Bald Eagle] Re: Curly braces replaced by indentations but on... [385 days 2 hours and 14 minutes ago]

Thu, 20 Mar 2025 18:20:00 GMT

"ingo" <nomail@nomail> wrote:

> One (two) more of POV-Ray's internals that I would like to see made available in
> SDL, the objects current transformation matrix and it's inverse. But build in
> turn, resize would be nice to haves,

Ah, and this is why if we could just have a Point *object*, then we could union
that with an object and transform everything at once.  Inverse is already
implemented.

[ingo] Re: Curly braces replaced by indentations but on... [385 days 2 hours and 44 minutes ago]

Thu, 20 Mar 2025 17:50:00 GMT

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

> [...] I have way too many spreadsheets and little pieces
> of paper with scribbles . . .

https://www.zim-wiki.org/index.html  a desktop wiki fur such things. I has
options /plugins for version control (even Fossil i.r.r.c)

There are several similar tools like Zim

ingo

[ingo] Re: Curly braces replaced by indentations but on... [385 days 2 hours and 59 minutes ago]

Thu, 20 Mar 2025 17:35:00 GMT

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

> (Which reminds me, I ought to write macros like Turn () and Resize () to
> translate objects to the origin, perform the inbuilt operation, and translate
> back to original location.  Macro names are just off the top of my head)

One (two) more of POV-Ray's internals that I would like to see made available in
SDL, the objects current transformation matrix and it's inverse. But build in
turn, resize would be nice to haves,

ingo

[ingo] Re: Curly braces replaced by indentations but on... [385 days 3 hours and 4 minutes ago]

Thu, 20 Mar 2025 17:30:00 GMT

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

> @ingo.  very happily second that.  </grin>
>

Ssst, don't tell, but table definitions are type, except type has grown in more
encompassing direction.

- pascal
type a = record
   b: integer;
   c: char;
end;


- C
struct a {
   int b;
   char c;
};

- nim
type
   A = object
      b: int
      c: char


- nim
type
  RGB = array[5, float]

  Pattern = object
    pKind: ....

  Texture = object
    pattern: seq[Pattern]

  Material = object
    texture: seq[texture]

template rgb*(r, g, b, filter, transmit: float): RGB =
 [x, y, z, filter, transmit]

template `r=`*(colour: var RGB, value: float) = colour[0] = value
template `g=` ...

kind off....

another language that may be of interest is Phix http://phix.x10.mx/ where
everything is array based (https://rosettacode.org/wiki/Category:Phix)

ingo

[Bald Eagle] Re: Curly braces replaced by indentations but on... [385 days 3 hours and 54 minutes ago]

Thu, 20 Mar 2025 16:40:00 GMT

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

> I so agree, everything ought to have "sensible defaults" for all but location
> (and perhaps size).

(?)

Well, considering the troubles people go through, 30 years in, I would say that
a default location at the origin not only makes sense, but is desirable.
[I always pause when I realize that torus {} doesn't take a vector location like
sphere{}, and I have to translate it afterwards, and I still fail to provide a
radius for cylinder when writing one from scratch.]

Rotate and scale, when not at the origin, really mess with people's heads.
(Which reminds me, I ought to write macros like Turn () and Resize () to
translate objects to the origin, perform the inbuilt operation, and translate
back to original location.  Macro names are just off the top of my head)

Default sizes ought to be in reference to the unit cell, unless there's some
specific reason to do otherwise.  Text {} defaults to 1. Image_map,
height_field, and maybe others default to 1x1, df3 and maybe others default to
the unit cube....

I think that one of the basic themes for 4.0 ought to be consistency.
In size, in uv-mapping vectors, in syntax, and whatever else we can manage.

- BW

[jr] Re: Curly braces replaced by indentations but on... [385 days 4 hours and 19 minutes ago]

Thu, 20 Mar 2025 16:15:00 GMT

hi,

"Bald Eagle" <cre### [at] netscapenet> wrote:
> "ingo" <nomail@nomail> wrote:
> > object and material are just containers, lists/arrays..
> > there are a few specialised ordered lists with an operator attached, union,
> > intersect etc.
> >
> > A povObject/shape is like a specific composed dictionary/struct/record as is
> > texture. One could define it all in SQLite:
>
> > etc. etc. who needs type-systems and OOP if you have a database ;)

@ingo.  very happily second that.  </grin>

too, I think, organising the design around a db(ms) internally will make for
less complexity in the VM backend, and perhaps elsewhere (like providing the
"introspection" BE mentions to "the front").

> ...
> It would also be great if as many things as possible had some sort of default
> attached to it, so I could just invoke a sphere, and maybe it just had a
> POV-Unit diameter and default texture.

I so agree, everything ought to have "sensible defaults" for all but location
(and perhaps size).

regards, jr.

[Bald Eagle] Re: Curly braces replaced by indentations but on... [385 days 4 hours and 49 minutes ago]

Thu, 20 Mar 2025 15:45:00 GMT

"ingo" <nomail@nomail> wrote:

> object and material are just containers, lists/arrays..
> there are a few specialised ordered lists with an operator attached, union,
> intersect etc.
>
> A povObject/shape is like a specific composed dictionary/struct/record as is
> texture. One could define it all in SQLite:
>

> etc. etc. who needs type-systems and OOP if you have a database ;)

Yes,
Along those lines, I was also trying to look at the similarities of all of the
povObjects to see if we could have some more commonality under-the-hood.  It's
something clipka mentioned.  I have way too many spreadsheets and little pieces
of paper with scribbles . . .

It would also be great if as many things as possible had some sort of default
attached to it, so I could just invoke a sphere, and maybe it just had a
POV-Unit diameter and default texture.

- BW

[ingo] Re: Curly braces replaced by indentations but on... [385 days 5 hours and 54 minutes ago]

Thu, 20 Mar 2025 14:40:00 GMT

"jr" <cre### [at] gmailcom> wrote:
> hi,
>
> "ingo" <nomail@nomail> wrote:
> > ...
> >   object:
> >     sphere:
> >       center<0, 0, 0>
> >       radius<1>
> >       material:
>
> JSON has been mentioned elsewhere as a replacement (?) or as a component of the
> "new SDL".  it would (I guess) make a real good storage format for objects (like
> above), or materials/textures libraries, etc.
>

object and material are just containers, lists/arrays..
there are a few specialised ordered lists with an operator attached, union,
intersect etc.

A povObject/shape is like a specific composed dictionary/struct/record as is
texture. One could define it all in SQLite:

CREATE TABLE IF NOT EXISTS sphere(
  //centre: ah, there is no vector type but we could crate a table for that
         id INTEGER PRIMARY KEY NOT NULL,
       name TEXT UNIQUE,
     centre INTEGER REFERENCES vector(id),
     radius REAL DEFAULT 1.0,
   material INTEGER REFERENCES material(id)
)STRICT;

CREATE TABLE IF NOT EXISTS vector(
    id INTEGER PRIMARY KEY NOT NULL, // or use a string formatted as '<x,y,z>'?
     x REAL NOT NULL,
     y REAL NOT NULL,
     z REAL NOT NULL
)STRICT;

etc. etc. who needs type-systems and OOP if you have a database ;)

ingo

[ingo] Re: Curly braces replaced by indentations but on... [385 days 6 hours and 54 minutes ago]

Thu, 20 Mar 2025 13:40:00 GMT

"Mr" <m******r******at_hotmail_dot_fr> wrote:

> Would everyone around here also frown at this?

Kind of ;)  formatting is meditative moment, time for contemplating on the code
at hand. The language server for my editor auto formats on save, it is extremely
annoying as the result is ugly and I have not found how to turn it off.

ingo

[jr] Re: Curly braces replaced by indentations but on... [385 days 6 hours and 59 minutes ago]

Thu, 20 Mar 2025 13:35:00 GMT

hi,

"ingo" <nomail@nomail> wrote:
> ...
>   object:
>     sphere:
>       center<0, 0, 0>
>       radius<1>
>       material:
>         texture:
>           color<1, 0, 0>
>           reflectivity<0.2>
>
>   object:
>     plane:
>       normal<0, 1, 0>
>       distance<-1>
>       material:
>         texture:
>           color<0.2, 0.8, 0.2>
>           reflectivity<0.1>

JSON has been mentioned elsewhere as a replacement (?) or as a component of the
"new SDL".  it would (I guess) make a real good storage format for objects (like
above), or materials/textures libraries, etc.

regards, jr.

[jr] Re: Curly braces replaced by indentations but on... [385 days 7 hours and 19 minutes ago]

Thu, 20 Mar 2025 13:15:00 GMT

hi,

Ilya Razmanov <ily### [at] gmailcom> wrote:
> On 20.03.2025 14:42, Mr wrote:
> > as only a couple of new features, and a formatting tool such as black ?
> With Python, all these autoformatters like 'black' drive me mad ...

while every project and organisation, it seems, is compelled to issue formatting
guidance/rules, one can "escape" from all of that, using the "pre-Gen-Z" ;-)
tool (note, singular) 'indent'.
eg <https://man.openbsd.org/indent.1>

regards, jr.

[Ilya Razmanov] Re: Curly braces replaced by indentations but on... [385 days 8 hours and 11 minutes ago]

Thu, 20 Mar 2025 12:22:48 GMT

On 20.03.2025 14:42, Mr wrote:
> as only a couple of new features, and a formatting tool such as black ?

With Python, all these autoformatters like 'black' drive me mad by 
compressing all my comprehensions down to one line. To me, even well 
formatted 3D list comprehensions with slicing and some 'if' and function 
inside are hard to understand, so when formatting gets 'blacked', I 
can't understand things I wrote five minutes ago.

-- 
Ilyich the Toad
https://dnyarri.github.io/

[Mr] Re: Curly braces replaced by indentations but on... [385 days 8 hours and 49 minutes ago]

Thu, 20 Mar 2025 11:45:00 GMT

Tor and Ingo, You are right ! I had even forgotten about those eventualities
since the guiding principle in Python for me has indeed become the PEP (with
quite some personal choice for when to apply it or not :-D ! It's so much
enforced by all collective projects however (git repo settings play a role in
this too)... and also luckily the auto formatting tools such as Black/Snake8/
etc,  That I forgot I may have taken different habits if I had kept learning
python by myself all along. It works well once you have used some of this at
least once... but before, it's true the language does have room for shooting
yourself in the foot. All this makes me think of another Idea then :
What if POV 4 was not developed as a version of the language itself but rather
as only a couple of new features, and a formatting tool such as black ?

Would everyone around here also frown at this?

[ingo] Re: Curly braces replaced by indentations but on... [385 days 13 hours and 34 minutes ago]

Thu, 20 Mar 2025 07:00:00 GMT

"Mr" <m******r******at_hotmail_dot_fr> wrote:

> In python you can only have tab sized (4 spaces) indents like this[...]

in addition to Tor Olav's evil tabs, a tab is just a '\t' symbol like a '\n' or
'\r'. You can tell your editor to use any tab size >0 you like. Python just
looks at the '\t' not at what your editor thinks how wide a tab is.

But that's not all, Python also looks at spaces for indentation. The mixing of
tabs and spaces is what makes things messy. Something that easily happens when
copying code. So set your editor to always convert tabs to spaces, the length is
up to your preference.

ingo

[Tor Olav Kristensen] Re: Curly braces replaced by indentations but on... [385 days 18 hours and 44 minutes ago]

Thu, 20 Mar 2025 01:50:00 GMT

"Mr" <m******r******at_hotmail_dot_fr> wrote:
>...
> In python you can only have tab sized (4 spaces) indents like this, which looks
> more tidy/less error prone (though I understand people would like more
> flexibility and perhaps more compact concision) :
>...
>    object:
>        sphere:
>            center<0, 0, 0>
>            radius<1>
>            material:
>                texture:
>                    color<1, 0, 0>
>                reflectivity<0.2>
>...

Hi Mr

Python allows 1 or more extra leading spaces for each indentation level.
So you can actually write code like this:

for x in range(10):
  for y in range(10):
      for z in range(10):
              print(f'<{x}, {y}, {z}>')
  if (x % 2) == 1:
          print('---------')

what is recommended in pep8 is another matter:

    PEP 8 – Style Guide for Python Code
    https://peps.python.org/pep-0008/#indentation

And BTW: Tabs are evil!

--
Tor Olav
http://subcube.com
https://github.com/t-o-k

[Mr] Re: Curly braces replaced by indentations but on... [385 days 20 hours and 24 minutes ago]

Thu, 20 Mar 2025 00:10:00 GMT

"ingo" <nomail@nomail> wrote:
> "Kenneth" <kdw### [at] gmailcom> wrote:
>
>   camera:
>     location<0, 2, -15>
>     lookat<0, 0, 0>
>     up<0, 1, 0>
>     fov<60>
>
>   light:
>     location<500, 100, -50>
>     color<1, 1, 1>
>     intensity<1.0>
>
>   object:
>     sphere:
>       center<0, 0, 0>
>       radius<1>
>       material:
>         texture:
>           color<1, 0, 0>
>           reflectivity<0.2>
>
>   object:
>     plane:
>       normal<0, 1, 0>
>       distance<-1>
>       material:
>         texture:
>           color<0.2, 0.8, 0.2>
>           reflectivity<0.1>
>
> ;)
>
> ingo

In python you can only have tab sized (4 spaces) indents like this, which looks
more tidy/less error prone (though I understand people would like more
flexibility and perhaps more compact concision) :

   camera:
       location<0, 2, -15>
       lookat<0, 0, 0>
       up<0, 1, 0>
       fov<60>

   light:
       location<500, 100, -50>
       color<1, 1, 1>
       intensity<1.0>

   object:
       sphere:
           center<0, 0, 0>
           radius<1>
           material:
               texture:
                   color<1, 0, 0>
               reflectivity<0.2>

   object:
       plane:
           normal<0, 1, 0>
           distance<-1>
           material:
               texture:
                   color<0.2, 0.8, 0.2>
               reflectivity<0.1>

[ingo] Re: Curly braces replaced by indentations but on... [386 days 1 hour and 9 minutes ago]

Wed, 19 Mar 2025 19:25:00 GMT

"Kenneth" <kdw### [at] gmailcom> wrote:

  camera:
    location<0, 2, -15>
    lookat<0, 0, 0>
    up<0, 1, 0>
    fov<60>

  light:
    location<500, 100, -50>
    color<1, 1, 1>
    intensity<1.0>

  object:
    sphere:
      center<0, 0, 0>
      radius<1>
      material:
        texture:
          color<1, 0, 0>
          reflectivity<0.2>

  object:
    plane:
      normal<0, 1, 0>
      distance<-1>
      material:
        texture:
          color<0.2, 0.8, 0.2>
          reflectivity<0.1>

;)

ingo

[ingo] Re: Suggest v4.0 experimental features [386 days 1 hour and 14 minutes ago]

Wed, 19 Mar 2025 19:20:00 GMT

"Bald Eagle" <cre### [at] netscapenet> wrote:
> #read by whole line - [...]

// is the simple one, once you have detected it just skip to end of line.

/* is trickier, you have to scan characters until you find */ and then POV-Ray
supports nested multiline comments. So if you find a second /* in a comment you
either have to start a counter or use recursion otherwise you'll miss the true
end of the comment.

Lots of parsers are clever, they can skip parts of words when they are sure that
there is no other option than that specific keyword even if they are only half
way parsing that word. But in the end you still have to visit a lot of
characters.

My POV-Ray HTML highlighter (https://ingoogni.nl/download/) parses a POV-Ray
file using regular expressions, not the most elegant way to do it. It properly
handles the nested comments.

ingo

[Kenneth] Re: Curly braces replaced by indentations but on... [386 days 1 hour and 34 minutes ago]

Wed, 19 Mar 2025 19:00:00 GMT

"Bald Eagle" <cre### [at] netscapenet> wrote:
> "Kenneth" <kdw### [at] gmailcom> wrote:
>
> > ...it could break all of our
> > old scenes, going back decades.
>
> Aye, lad.  But we're talking about POV-Ray 4.0, dontchaknow.
> Let's cast off the shackles of "backward compatibility" and do something NEW!
>
> It's not like the old versions will be deleted from the fabric of reality.
>

A new(?) language with new syntax rules. Arrggghh. I have enough trouble trying
to understand the NEW remote control for my recently-installed NEW AND
IMPROVED(?) cable-TV box. :-[

> > Personally, I have always liked the fact that POV-ray's SDL syntax did not
> > impose any meaning on tabs or spaces; it would have been one more 'layer of
> > abstraction' to add to the learning of the syntax...

In other words, code-writing in POV has always been more 'relaxed' and not so
exacting; no need to worry about spaces or tabs... which I like to use liberally
:-) Of course, others might complain that this 'feature' produces a LESS
structured/exacting environment, in the context of other languages. But it sure
makes code-writing easier, in my humble opinion.

[Bald Eagle] Re: Curly braces replaced by indentations but on... [386 days 2 hours and 14 minutes ago]

Wed, 19 Mar 2025 18:20:00 GMT

"Kenneth" <kdw### [at] gmailcom> wrote:

> If spaces and tabs were to suddenly have real meaning in POV 4, and depending on
> how we each write POV code-- the layout of the text-- it could break all of our
> old scenes, going back decades.

Aye, lad.  But we're talking about POV-Ray 4.0, dontchaknow.
Let's cast off the shackles of "backward compatibility" and do something NEW!

It's not like the old versions will be deleted from the fabric of reality.

> For example, I personally write code with tabbed indents, just to make the
> various constructs clear in my mind. Like...
>
> sphere{0,1
>      texture{
>           pigment{rgb 1}
>           finish{...}
>             }
>      normal{...}
>       }

I do it just to make jr twitch to the verge of seizures.
Other times I simply do things because I think they're a CAPITAL IDEA.

I think the real value of opening and terminating symbols is their utility for
future delinters and debuggers.
I have already expressed my support for MORE different kinds of brackets and
parentheses, as well as #endif, #endwhile, #endfor, #endmacro, etc.

- BW

[Leroy] Re: Suggest v4.0 experimental features [386 days 2 hours and 14 minutes ago]

Wed, 19 Mar 2025 18:20:00 GMT

"Bald Eagle" <cre### [at] netscapenet> wrote:
> #read by whole line - everything gets read into one long string.
> This would allow user parsing of the string, regardless of data types,
> structure, number of entries, etc.

I like this Idea!
I have been playing with pgn files, chess format file. They are fancy text
files with a list of all the moves in a game with a lot of other information
like the tournament, players, rankings and so on. It would be nice to read all
that info and drop it line by line until I got to something I want.
 Right now I do it by hand by copying text to another file and getting it sit up
for POV to Read. I could write a C++ program to do it for me, but I like POV.
 Right Now 3.8 can handle strings larger that 255 elements, But Can't load them
from a file. (3.7 seem to handle strings the same way.)
 If a line read is to complicated to do, for some reason, then a binary read
would be almost as good. Say read so many bytes at time and return as a integer.

Have Fun!

[Kenneth] Re: Curly braces replaced by indentations but on... [386 days 2 hours and 29 minutes ago]

Wed, 19 Mar 2025 18:05:00 GMT

"Mr" <m******r******at_hotmail_dot_fr> wrote:
>
> What if in POV 4
> we had the possibility to use spaces or tabs as a synonym to what curly braces
> currently do, but we could still use those braces themselves ?
>

If spaces and tabs were to suddenly have real meaning in POV 4, and depending on
how we each write POV code-- the layout of the text-- it could break all of our
old scenes, going back decades.

For example, I personally write code with tabbed indents, just to make the
various constructs clear in my mind. Like...

sphere{0,1
     texture{
          pigment{rgb 1}
          finish{...}
            }
     normal{...}
      }

This is especially helpful to me in very complex scenes. (Others here probably
have their own ways of writing such stuff.)

If those tabs or spaces were to take on a syntactical importance going forward,
it would wreak havoc with old scenes. Chaos! :-(

Personally, I have always liked the fact that POV-ray's SDL syntax did not
impose any meaning on tabs or spaces; it would have been one more 'layer of
abstraction' to add to the learning of the syntax, in my opinion. I am not a
'programmer' in the strict sense, though, so I don't know how other languages'
syntax rules make it easier or harder for beginners to learn those languages.
POV's syntax 'made sense' to me from the get-go.

[William F Pokorny] Re: Addressing the secrete rotation in text{} ob... [386 days 3 hours and 17 minutes ago]

Wed, 19 Mar 2025 17:17:24 GMT

On 3/19/25 03:52, jr wrote:
> 'msgothic.ttc' (eg) works for me (alpha.9945627, beta.2) while 'NotoSansCJK.ttc'
> crashes, yuqk reports 'Invalid TT font headers...'.  looks like it all depends
> on the people putting together the TTF/TTC file(s).

In an offline discussion, jr helped me work through my own confusion 
with the .ttc support in POV-Ray.

I tried the 'CJK' .ttc fonts blindly on seeing the .ttc suffix.

Well, it turns out OpenType fonts also use the .ttc suffix and POV-Ray 
doesn't support them. I didn't know. My Ubuntu distribution puts the 
OpenType fonts in another directory:

/usr/share/fonts/opentype/noto/NotoSansCJK-Regular.ttc

rather than:

/usr/share/fonts/truetype/

but I didn't notice...

---

If you are on linux and have the .ttc collection in a personal directory 
you can use the 'file' command:

file NotoSansCJK-Regular.ttc

and it will kick out text about the file. Part of which will includes 
detail on the internal font types stored. For example:

NotoSansCJK-Regular.ttc: OpenType font collection data, 1.0, 10 fonts, 
at 0x34 OpenType Font data, 16 tables, 1st "BASE"

or 'file LiberationMono-Regular.ttf' :

LiberationMono-Regular.ttf: TrueType Font data, 18 tables, 1st "FFTM", 
30 names, Macintosh

---

So, I'm leaving the .ttc support in place with yuqk and I'll add yuqk 
documentation that the POV-Ray support for .ttc files is only for 
TrueType collections.

Bill P.

[Bald Eagle] Suggest v4.0 experimental features [386 days 3 hours and 34 minutes ago]

Wed, 19 Mar 2025 17:00:00 GMT

#read by whole line - everything gets read into one long string.
This would allow user parsing of the string, regardless of data types,
structure, number of entries, etc.

matrix <>, but allowing x, y, and z in the definitions of the coefficients.
This would allow the desirable but elusive non-linear scaling of primitives, and
well as other interesting transformations such as progressive rotations.
With this, we could "effortlessly" do things with primitives that are currently
only possible with isosurfaces.

Speed parsing - I believe that we currently have mechanisms in the parser to
pretty much ignore everything between /* and */, and anything that starts with
//

The idea would be to selectively / switchably mimic that behavior in order to
"scan" an include file and not have to character-by-character parse every
(unneeded) line.
Kinda like the dreaded GOTO, but since we're progressively parsing a file in a
linear fashion, I think it's appropriate and would be ok.
This is related to the Monolithic Include File idea - I'd want to have the
parser "glance" at the beginning of each line, and skip it until it reached a
block of code that I actually wanted to include.
Perhaps there could be a "file section" designator, where the parser skips
everything, until it hits that. Like fseek ()

junk
junk
junk
[Parse this]
code
code
[end parsing
junk
junk
eof

Might be a better way to do that, but the key is that everything can reside in a
single include file, and there won't be a million puzzle pieces to get lost.

I had also once suggested support for other file formats to allow "bundling".
Like .tar

Not like this is an original idea:
https://news.povray.org/povray.programming/thread/%3C36C0CEFC.41AEA1BD%40bravo436.chem.mcgill.ca%3E/

- BW

[ingo] POV-Ray style syntax raytracer in Nim macro's [386 days 6 hours and 9 minutes ago]

Wed, 19 Mar 2025 14:25:00 GMT

After the discussion on curly braces in this group, I thought why not ask Claude
and see what it comes up with. One single question an a lot of code. Untested,
I'll do that later and report. To get an impression, here's a link:

https://claude.ai/share/892580c7-7e34-4724-a572-3274961c4447

It didn't follow everything I asked, but it does not look bad.

ingo

[jr] Re: Addressing the secrete rotation in text{} ob... [386 days 12 hours and 39 minutes ago]

Wed, 19 Mar 2025 07:55:00 GMT

hi,

William F Pokorny <ano### [at] anonymousorg> wrote:
> ...
> Question.
>
> Has anyone successfully used a true type collection (.ttc file) with
> recent (V3.7/V3.8) official POV-Ray versions?
>
> These always crash with the .ttc files I have easy access to. Namely,
> large CJK collections. These are also not capturing multiple styles, but
> region specific glyph differences - maybe that is somehow an issue for
> the current code.
> ...

'msgothic.ttc' (eg) works for me (alpha.9945627, beta.2) while 'NotoSansCJK.ttc'
crashes, yuqk reports 'Invalid TT font headers...'.  looks like it all depends
on the people putting together the TTF/TTC file(s).

regards, jr.

[ingo] Re: Curly braces replaced by indentations but on... [386 days 13 hours and 54 minutes ago]

Wed, 19 Mar 2025 06:40:00 GMT

"Mr" <m******r******at_hotmail_dot_fr> wrote:
>I'm not referring to type here which is another issue, just the
> "declare" or "var" keyword... I don't see why it's important.

A "big" difference is that in POV-Ray you have to tell a variable whether it is
local or not. In many languages this is different. Every variable declared
inside a block is local and it can't escape that block.

So in Nim:

var chicken = 1

for i in 0 ..< 10:
  let n = i + i
  chicken += n

echo chicken
echo n # fails compilation, Error: undeclared identifier: 'n'

it fails not because it is let (immutable), but because it's local.

There is quite a body of research on what a good beginners language should look
like. Python scores very high on these. One aspect in several of these
researches made me chuckle, as I had the same problem decades ago. It is hard to
grasp 'while' and 'for' loops (Warp wrote a tutorial on it). Using the keyword
'every 'makes it more understandable for novices. Another hard one is OOP except
for the composition of records/objects.

The main problem in POV-Ray is that there are two aspects to it, the 'scripting'
part and the 'objects' part and that is actually well done. Compare it with the
javascript 3D stuff, or Vapory https://github.com/Zulko/vapory . If one would
repurpose an existing language for POV-Ray SDL then look for a language with
extensive macro abilities to build a DSL so one can have a distinct render
object sections an distinct script/code sections, similar to POV-Ray now.

ingo

[William F Pokorny] Re: Addressing the secrete rotation in text{} ob... [386 days 15 hours and 55 minutes ago]

Wed, 19 Mar 2025 04:38:57 GMT

On 3/13/25 14:05, William F Pokorny wrote:
> I'm starting to think pulling the patch altogether might be a better 
> long trial. A user can always add the rotation. In fact, likely a 
> cleaner, more minimal rotation about just the z axis) when artefacts 
> show up.

For the record.

After some testing where I did not see any axis aligned seams / 
artefacts, I've decided to pull the text{} rotation patch from the 
parser. This no-patch trial will start with release R19 of my yuqk
playpen fork rather than just making the rotation smaller.

---

Question.

Has anyone successfully used a true type collection (.ttc file) with 
recent (V3.7/V3.8) official POV-Ray versions?

These always crash with the .ttc files I have easy access to. Namely, 
large CJK collections. These are also not capturing multiple styles, but 
region specific glyph differences - maybe that is somehow an issue for 
the current code.

The support for .ttc files was always limited to the first packaged .ttf 
font found in the collection. We have no ability to pick which font in a 
collection gets used. I'm considering dropping support for reading true 
type collection files near term in the yuqk fork, but if it is working 
for others, maybe I leave it as is.

Bill P.

[Mr] Re: Curly braces replaced by indentations but on... [386 days 20 hours and 49 minutes ago]

Tue, 18 Mar 2025 23:45:00 GMT

Ilya Razmanov <ily### [at] gmailcom> wrote:
> On 18.03.2025 20:07, kurtz le pirate wrote:
> > Nothing good about pyhton.
> > Definitely bad language.
>
> Well, I'm not considering it especially bad, and even use it for my
> POV-Ray scene creating stuff. But I'm not considering it extremely good
> and easy either, and all this indentation stuff is definitely not what I
> like, specifically. After all, if you take a look at my Python-based
> img2mesh POV export stuff, you'll see something like:
>
> resultfile.write(f'\n    triangle {{<{x_out(x, 0)}, {y_out(y, 0)},
> map({v1})> <{x_out(x, 1)}, {y_out(y, 0)}, map({v2})> <{x_out(x, 0.5)},
> {y_out(y, 0.5)}, map({v0})>}}')
>
> and don't tell me it is low on braces ;-)
>
> --
> Ilyich the Toad
> https://dnyarri.github.io/

As I mentioned Python does have an obscure syntax for the advanced features
indeed the @, etc...  I was referring only to entry level first scripts that one
can do on day one, and dictionaries (Python's curly brace use) are not necessary
for these first baby steps. This makes it a language you can teach to kids...
not as much as scratch of course, so maybe David Buck's project is the way to go
for that.
(https://www.kickstarter.com/projects/pigeontalk/pigeontalk-a-programming-environment-to-explore-computing)

Back on topic, I'm honestly surprised by the hate for space based indentation
here ! I thought, given they are doing exactly what these curly braces do in a
less forgiving but in what subjectively appears to me to be a more pleasing and
print-friendly look. they would not be that despised... I was wrong apparently.

But to me current curly braces feel almost like the python @ or the "morse"
operator
:=  somewhat rough ... Would anyone have any other suggestions than these {...}
then?

"ingo" <nomail@nomail> wrote:
> Ilya Razmanov <ily### [at] gmailcom> wrote:
>
> > ...and those newcomers will quickly find themselves producing mixed
> > syntaxis, then trying to understand what the heck is this.

When thinking of people who learn programming, I assumed a first time user tends
to pick one alternative, not burden with mixing two options for one meaning,
where you are right is that the copy pasting practice would make it very hard to
keep things not mixed. unless a parsing warning maybe could reduce the
inconvenience.

> What Python has shown is that readability counts and that there is very little
> need for line noise, arrows, squiggles and what not. In some aspects Nim takes
> it even further. And the they broke it with the @ and type stuff in python and
> {.pragmas.} in Nim.
>
> POV-Ray has a lot of '#', I never liked that, nor the constant need to
> #declare/#local. In Nim and probably others too, that is solved in an elegant
> way :
>
> var
>   chicken ...
>   swan ...
>   duck ...

I, too, find '#',  ugly, And I also especially dislike having to type "end" for
anything... I wouldn't mind that much typing var before listing several
variables together but before any one of them seems tedious. Also is anything
wrong in declaring a variable without saying its a variable? using equal sign or
column. (I'm not referring to type here which is another issue, just the
"declare" or "var" keyword... I don't see why it's important.

[Ilya Razmanov] Re: Curly braces replaced by indentations but on... [387 days and 51 minutes ago]

Tue, 18 Mar 2025 19:43:00 GMT

On 18.03.2025 20:07, kurtz le pirate wrote:
> Nothing good about pyhton.
> Definitely bad language.

Well, I'm not considering it especially bad, and even use it for my 
POV-Ray scene creating stuff. But I'm not considering it extremely good 
and easy either, and all this indentation stuff is definitely not what I 
like, specifically. After all, if you take a look at my Python-based 
img2mesh POV export stuff, you'll see something like:

resultfile.write(f'\n    triangle {{<{x_out(x, 0)}, {y_out(y, 0)}, 
map({v1})> <{x_out(x, 1)}, {y_out(y, 0)}, map({v2})> <{x_out(x, 0.5)}, 
{y_out(y, 0.5)}, map({v0})>}}')

and don't tell me it is low on braces ;-)

-- 
Ilyich the Toad
https://dnyarri.github.io/

[Ilya Razmanov] Re: Curly braces replaced by indentations but on... [387 days 1 hour and 1 minute ago]

Tue, 18 Mar 2025 19:33:06 GMT

On 18.03.2025 13:54, ingo wrote:

> For the rest of it, a well designed language should need "no" tooling.
And it should look like obscene Russian, for my convenience. That means 
it must be flexible and extendable beyond any recognition.

-- 
Ilyich the Toad
https://dnyarri.github.io/

[ingo] Re: Curly braces replaced by indentations but on... [387 days 1 hour and 39 minutes ago]

Tue, 18 Mar 2025 18:55:00 GMT

"jr" <cre### [at] gmailcom> wrote:
> I'd like to see you post a bit of "mocked up" scene code to illustrate the
> benefits; I guess you'd like something like 'union box 0 1 sphere 0 .5 ' ?

clipka once proposed a YAML like structure. I didn't like that at all, fun
thing, many macro generated DSL's made in Nim use that kind of syntax.

ingo

[Alain Martel] Re: Curly braces replaced by indentations but on... [387 days 2 hours and 12 minutes ago]

Tue, 18 Mar 2025 18:22:15 GMT

Le 2025-03-18 Ã  04:01, Mr a Ã©critÂ :
> I'm sure more expert people in various languages will be able to teach me
> something important from what is probably a naive question :  What if in POV 4
> we had the possibility to use spaces or tabs as a synonym to what curly braces
> currently do, but we could still use those braces themselves ?
>

That would be a pretty BAD idea. It'll make the code uselessly hard to 
understand, introduce a LOT of ambiguity. That can only lead to code 
that is nearly to totally impossible to debug.

[kurtz le pirate] Re: Curly braces replaced by indentations but on... [387 days 3 hours and 27 minutes ago]

Tue, 18 Mar 2025 17:07:27 GMT

On 18/03/2025 10:00, Ilya Razmanov wrote:

> ...and those newcomers will quickly find themselves producing mixed 
> syntaxis, then trying to understand what the heck is this.
> 
> And, frankly, I don't see anything good about Python identation. To me 
> it only takes more screen space than necessary, produce weird linewraps 
> on display, and so on. I believe everything one need to control brackets 
> and braces of all kinds it syntax highlight, and, ideally, a linter. 
> Well, we already have a POV extension for VSCode, it's not perfect but I 
> think it's a way to go, it would be definitely better than spending time 
> for creating new POV editor. So we may get syntax highlight and stuff 
> this way. What as to linter and stuff like that, that's a different 
> story and more complicated one.
> 
              ____
     .__     /_   |
   __|  |___  |   |
  /__    __/  |   |
     |__|     |___|



Nothing good about pyhton.
Definitely bad language.



After that, of course, everyone has their own preferences and affinities.





-- 
kurtz le pirate
compagnie de la banquise

[jr] Re: Curly braces replaced by indentations but on... [387 days 8 hours and 44 minutes ago]

Tue, 18 Mar 2025 11:50:00 GMT

hi,

"Mr" <m******r******at_hotmail_dot_fr> wrote:
> I'm sure more expert people in various languages will be able to teach me
> something important from what is probably a naive question :  What if in POV 4
> we had the possibility to use spaces or tabs as a synonym to what curly braces
> currently do, but we could still use those braces themselves ?

I'd be interested to learn what (tangible) gain(s) you see in that.


> That way new comers would feel at first glance that the language is as easy to
> learn as Python, and would rapidly understand as they do in Python, that what
> matters is that they do know what scope they're in.

right, and Icelanders and Germans could simply switch to English :-).


>
> and eventually, depending on *whichever* option gets to become the most popular
> among core developers and power users, it can become a maintenance cost
> reduction to drop one or the other?
>
> Inspiration for this idea? of course, python... I love how it has grown able to
> do type annotations, switch cases, etc. and while across versions leverage many
> advanced concepts teaching them to me as it went, and now they are there, I love
> how a new comer could still pick it up exactly the way I did, with a human
> readable almost fiction-book like syntax, and still produce scripts that do
> work, syntactic-sugar-free.  BUT I know there must be a reason why those curly
> braces are still there isn't there? so I trust people to tell me... maybe so
> that POV acts as a launching pad to learn C-like languages in which it is itself
> developed?

I'd like to see you post a bit of "mocked up" scene code to illustrate the
benefits; I guess you'd like something like 'union box 0 1 sphere 0 .5 ' ?

fwiw, even _if_ I thought Python a good language I'd endorse Ilya's view:
"...and those newcomers will quickly find themselves producing mixed syntaxis,
then trying to understand what the heck is this."


regards, jr.

[ingo] Re: Curly braces replaced by indentations but on... [387 days 9 hours and 39 minutes ago]

Tue, 18 Mar 2025 10:55:00 GMT

Ilya Razmanov <ily### [at] gmailcom> wrote:

> ...and those newcomers will quickly find themselves producing mixed
> syntaxis, then trying to understand what the heck is this.

As I use Nim, I agree with this aspect very much. I chose Nim because it looks
like Python, but it is nothing like it. It takes a while to forget Python, but
then it's all fine.

For the rest of it, a well designed language should need "no" tooling. Imagine
that all books where printed colour coded, verbs in green etc. And then users
start to nag that it should be printed in dark mode .... Colour does not matter
for me as I mostly have set Windows to greyscale, Ctrl+win+C.

What Python has shown is that readability counts and that there is very little
need for line noise, arrows, squiggles and what not. In some aspects Nim takes
it even further. And the they broke it with the @ and type stuff in python and
{.pragmas.} in Nim.

POV-Ray has a lot of '#', I never liked that, nor the constant need to
#declare/#local. In Nim and probably others too, that is solved in an elegant
way :

var
  chicken ...
  swan ...
  duck ...

[Bald Eagle] Re: Curly braces replaced by indentations but on... [387 days 9 hours and 39 minutes ago]

Tue, 18 Mar 2025 10:55:00 GMT

Ilya Razmanov <ily### [at] gmailcom> wrote:

So we may get syntax highlight and stuff

Was anyone aware that in the ini directory, there is a file named
"user-keywords.txt" ?


"
# user-defined keywords may be placed in this file
# these keywords do not affect parsing or SDL; they are only used by the editor
# for syntax highlighting and keyword completion (i.e. ctl-space or tab)
#
# the syntax is one keyword per line. spaces are not permitted within keywords
# (leading or trailing spaces are allowed but will be stripped). any line
containing
# more than one token will be ignored, as well any line starting with a '#'.
"

:O

(I haven't tried it yet)

[Ilya Razmanov] Re: Curly braces replaced by indentations but on... [387 days 11 hours and 34 minutes ago]

Tue, 18 Mar 2025 09:00:33 GMT

On 18.03.2025 11:01, Mr wrote:
> I'm sure more expert people in various languages will be able to teach me
> something important from what is probably a naive question :  What if in POV 4
> we had the possibility to use spaces or tabs as a synonym to what curly braces
> currently do, but we could still use those braces themselves ?
> 
> That way new comers would feel at first glance that the language is as easy to
> learn as Python, and would rapidly understand as they do in Python, that what
> matters is that they do know what scope they're in.

...and those newcomers will quickly find themselves producing mixed 
syntaxis, then trying to understand what the heck is this.

And, frankly, I don't see anything good about Python identation. To me 
it only takes more screen space than necessary, produce weird linewraps 
on display, and so on. I believe everything one need to control brackets 
and braces of all kinds it syntax highlight, and, ideally, a linter. 
Well, we already have a POV extension for VSCode, it's not perfect but I 
think it's a way to go, it would be definitely better than spending time 
for creating new POV editor. So we may get syntax highlight and stuff 
this way. What as to linter and stuff like that, that's a different 
story and more complicated one.

-- 
Ilyich the Toad
https://dnyarri.github.io/

[Mr] Curly braces replaced by indentations but only a... [387 days 12 hours and 29 minutes ago]

Tue, 18 Mar 2025 08:05:00 GMT

I'm sure more expert people in various languages will be able to teach me
something important from what is probably a naive question :  What if in POV 4
we had the possibility to use spaces or tabs as a synonym to what curly braces
currently do, but we could still use those braces themselves ?

That way new comers would feel at first glance that the language is as easy to
learn as Python, and would rapidly understand as they do in Python, that what
matters is that they do know what scope they're in.

and eventually, depending on *whichever* option gets to become the most popular
among core developers and power users, it can become a maintenance cost
reduction to drop one or the other?

Inspiration for this idea? of course, python... I love how it has grown able to
do type annotations, switch cases, etc. and while across versions leverage many
advanced concepts teaching them to me as it went, and now they are there, I love
how a new comer could still pick it up exactly the way I did, with a human
readable almost fiction-book like syntax, and still produce scripts that do
work, syntactic-sugar-free.  BUT I know there must be a reason why those curly
braces are still there isn't there? so I trust people to tell me... maybe so
that POV acts as a launching pad to learn C-like languages in which it is itself
developed?

[William F Pokorny] Re: Addressing the secrete rotation in text{} ob... [391 days 19 hours and 12 minutes ago]

Fri, 14 Mar 2025 01:21:36 GMT

On 3/13/25 15:44, Bald Eagle wrote:
>> Centering the text{} object about the origin
>> lessons the chance the secret rotation will cause a problem.
> I've certainly learned that you're not spelling that correctly.
> 
>> The left render shows the result for the current secrete rotation of
>> <0.001,0.001,0.001>.
> It must be a small glandular thing.

Oh my... I laughed out loud. +11  :-)

Bill P.

[Bald Eagle] Re: Addressing the secrete rotation in text{} ob... [392 days and 49 minutes ago]

Thu, 13 Mar 2025 19:45:00 GMT

William F Pokorny <ano### [at] anonymousorg> wrote:
> Centering the text{} object about the origin
> lessons the chance the secret rotation will cause a problem.

I've certainly learned that you're not spelling that correctly.

> The left render shows the result for the current secrete rotation of
> <0.001,0.001,0.001>.

It must be a small glandular thing.

Thanks for uncovering this and pointing it out.
It explains something that I've noticed and ignored, when messing up text via
the coincident surface phenomenon.  There's always been half of the text visible
in this sort of diagonal partition.  Since the text is actually rotated, albeit
by a small amount, this makes perfect sense.

- BW

[William F Pokorny] Addressing the secrete rotation in text{} object [392 days 2 hours and 29 minutes ago]

Thu, 13 Mar 2025 18:05:31 GMT

In an offline email exchange with jr, I drifted off into a discussion 
(OK, it was more of a monologue) about how the text{} object has a 
secrete rotation to avoid axis aligned numerical issues. The rotation is 
the equivalent of a user specifying - always - 'rotate 
<0.001,0.001,0.001>' on text{} objects.

It's something that was added to the parse code at some point. It's 
there in v3.7 - probably earlier versions too. The v3.8 source added a 
TODO note about trying to find some better approach.

For the next release of the yuqk fork (R19) I've currently reduced the 
rotation to: 'rotate <0.0001,0.0001,0.0001>' as a longer trial, but I'm 
having second thoughts (*).

After setting up some more formal test code, I'm left unsure of the best 
way to proceed - in no small part because I don't know what really 
caused the issues for which the patch was applied. If anyone remembers 
anything, please pass it along.

I'm starting to think pulling the patch altogether might be a better 
long trial. A user can always add the rotation. In fact, likely a 
cleaner, more minimal rotation about just the z axis) when artefacts 
show up.

Attached is an image and a yuqk scene file where I've set the thickness 
of the text objects at 1e-6; Artifacts show up even at a thickness of 
1.0. The rotation is effectively another issue that can bite or not 
depending on many things. Centering the text{} object about the origin 
lessons the chance the secret rotation will cause a problem.

The left render shows the result for the current secrete rotation of 
<0.001,0.001,0.001>.

In the middle no secrete rotation is applied.

On the right, the current R19 rotation of <0.0001,0.0001,0.0001>. It 
helps, but I think not in a way that really addresses the issue and, who 
knows, maybe it's not large enough for the situation for which the patch 
was added.

Bill P.

(*) - Another thing I played with was to add a counter / inverse 
rotation in SDL to the secrete one in an attempt to get back to no 
rotation. While it sometimes works, there is too much numerical noise in 
rotating and un-rotating (on combining the two opposing matrices). The 
overall results were less stable.

[Bald Eagle] Re: Macros and other code snippets [394 days 6 hours and 39 minutes ago]

Tue, 11 Mar 2025 13:55:00 GMT

"Leroy" <whe### [at] gmailcom> wrote:
Leroy: See (*)

>  The main problem is some of the code from the earlier versions uses tricks to
> do what newer versions do more efficiently.Like the Array_function I wrote to
> fake the mixed array of version 3.8. I also wrote code to fake the reflection of
> light before Radiosity.

I'm probably just going to start making directories and putting in .txt, .inc,
..pov, and zip/7z/tar.gz files

That way at least things _exist_, are collected into a directory tree, and can
be preserved - whether organized or not.

After that, I'll consider what ought to be an include file, an Insert Menu file,
or something that's more along the lines of a reference graphic or collection of
files that amount to a tutorial.

 * I don't see what you've done as a "problem" - working around old limitations
involves applying creative solutions to accomplish a task.  Those are still very
valuable examples for people to draw inspiration from.  They are not wasted
effort, and ought to be included in a POV-Ray reference library.

The most important thing is to preserve things that are useful and will be used.
Other things can be added to collection as people uncover things and submit them
for inclusion.

- BE

[William F Pokorny] Re: Suggest v4.0 f_bezier_2d_...() functions. (y... [403 days 3 hours and 20 minutes ago]

Sun, 2 Mar 2025 17:13:49 GMT

On 3/1/25 16:52, William F Pokorny wrote:
> On the right the purple spheres are the completely constant x,y second 
> derivative...

Should've read: ..."u,v third derivative"...

I also wasn't consistent in using u,v rather than x,y throughout.

Argh, the writing I inflict on you all :-(.

Bill P.

[William F Pokorny] Re: Suggest v4.0 f_bezier_2d_...() functions. (y... [403 days 22 hours and 41 minutes ago]

Sat, 1 Mar 2025 21:52:52 GMT

On 3/1/25 11:24, Tor Olav Kristensen wrote:
> But I can't figure out how to interpret the two bottom graphs in the
> attached images.

I'm uncomfortable with how to represent the derivative graphs where they 
turn completely or partially constant.

I needed to normalize returned u,v values to get the scales into 
somewhat similar ranges for viewing - which corrupts them some too. The 
derivative plots sometimes end up being sets of values more the any sort 
of curve. We are looking at spheres at u,v locations.

On the lower left in white are the first derivative x,y points as 
spheres. The yellow is the second derivative and here all the values 
overlap the y axis.

On the right the purple spheres are the completely constant x,y second 
derivative values returned. The spheres are all at the same location.

---

While working on the code for these inbuilt functions I set up some 
plots using isosurfaces to graph where I took care to align the 'x' and 
't' values while evenly spacing the control points. For me these plots 
make more intuitive sense because I can plot v vs u. Let me see if I 
still have some of those around...

Found one. Quadratic, Cubic on the top. Quartic, Quintic on the bottom.
The cyan is the Bezier curve itself. The slate blue is the normalized 
derivative. The white the second derivative - where it crosses the u 
axis at y==zero we have the inflection points of the first derivative curve.

Aside: Thanks for your post on Jean Gallier's online material. I made a 
note of it. I have a hard copy of that curves and surfaces book. I found 
it, less immediately useful than I'd hoped - because I'm a maths hack. :-)

Bill P.

[Tor Olav Kristensen] Re: Suggest v4.0 f_bezier_2d_...() functions. (y... [404 days 4 hours and 4 minutes ago]

Sat, 1 Mar 2025 16:30:00 GMT

William F Pokorny <ano### [at] anonymousorg> wrote:
> Adding the inbuilt functions: f_bezier_2d_linear()
> f_bezier_2d_quadratic() f_bezier_2d_cubic() f_bezier_2d_quartic() and
> f_bezier_2d_quintic() to the next yuqk release (R19).
>
> The functions take and return single float packed 2d vectors in a
> double's space for control points and return values. Calculations are at
> double float accuracy internal to each functions code. The t parameter
> is passed as a double.
>
> The calculation and return mode settings:
>    0=<u,v> at t.
>    1=<u',v'> at t.             (Tangent normalized)
>    2=<normal u,normal v> at t. ((1) rotated for normal)
>    3=<u',v'> at t.             (Tangent / velocity)
>    4=<u'',v''> at t.           (Acceleration / change in tangent)
>    5=<u''',v'''> at t.         (Jerk / change in acceleration)
>
> Attaching images showing all six calculation and return modes for
> f_bezier_2d_cubic() f_bezier_2d_quartic() and f_bezier_2d_quintic().
>...

Hi Bill

That is Interesting.

But I can't figure out how to interpret the two bottom graphs in the
attached images.

--
Tor Olav
http://subcube.com
https://github.com/t-o-k

[00face] Re: Macros and other code snippets [406 days 3 hours and 44 minutes ago]

Thu, 27 Feb 2025 16:50:00 GMT

"Bald Eagle" <cre### [at] netscapenet> wrote:
> As part of trying to organize my thoughts and assemble a collection of useful
> macros and code snippets, I made a big list in a spreadsheet, but would like to
> have something that's more generally useful and easier to update / navigate.
>
> I'm thinking about something along the lines of a directory tree that then gets
> zipped, and can be either unzipped into an existing pov-ray directory tree for
> use,
> or unzipped into a development folder for collaborative editing, updating with
> newer versions of old macros, insert menu items, or didactic demonstrative scene
> files (newer versions are added into the directory, retaining the older
> versions).
>
> No idea when I'll get everything organized and zipped, but I figured I would
> alert the general readership and solicit submissions - since we're all aware how
> things which ought to be archived tend to disappear.
>
> I should probably make a folder for archived websites like Mike Williams' and
> Chris Colefax's stuff.
>
> - BE

Can't wait to see it :)

[Bald Eagle] Re: Suggest v4.0 f_bezier_2d_...() functions. (y... [406 days 4 hours and 24 minutes ago]

Thu, 27 Feb 2025 16:10:00 GMT

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

> :-) just...

Yes, it's a sublimely phrased complement to "All you gotta do is..."  ;)

> Thanks for posting this code. I have no feel for it at the moment, but
> would like to play. Longer term, I'll ponder the suggestions.
>
> Initial reaction is I'm unsure how to nicely handle inputs and results
> if made inbuilt today.

Not sure.  I don't play under the hood as frequently as I probably should.
And I certainly don't write things to GO under the hood (yet).
All I can think of off-the-cuff is that the current matrix <> stores FOUR 3D
vectors.  Perhaps that can be (ab)used.

> And, I doubt whether these things really need to
> be inbuilt functions? With the curves and derivatives themselves I
> wanted to be able to use them within the VM at render time.

All of this is with an eye of playing with the 48,000+ Bezier patch POV-Planet
and subdivisions.  L.O.D and various Bezier-patch debugging functions could be
useful at render time to overlay wireframe grids, make curvature-dependent
textures, interpolate colors and textures - you name it.  Can't do any of that
at render time with macros (unless we're doing the old, painful,
make-a-function-with-a-macro thing, which is also SLOOOOOOW)

> Maybe these could be shipped macros in a core include file...

They could be, but source-level methods integrated into the VM would be
something I think any good CG package would be expected to have.
Also, clipka was mentioning converting all of our text-rendering into prism {}
objects, and having an inbuilt Bezier library already implemented might be part
of making such a thing happen.
Plus, you know the POV-Ray type of experimenter - any and every feature will be
put to uses that none of us could ever expect.

Let's say that I wanted to take a sphere {} and make it into a QuadSphere made
out of Bezier patches. This would be nearly effortless if I took a circumscribed
cube and applied Bezier functions to the 4 vertices, and there were other spline
functions to solve for missing control points. (linear, spherical, etc.)

I'm just mentioning this at the present time because your mind is in this space,
you're coding that section of yuqk, and "the iron is hot".

Likely you'd have a blast doing all sorts of experiments once you had the tools
to play with.

- BW

[William F Pokorny] Re: Suggest v4.0 f_bezier_2d_...() functions. (y... [406 days 5 hours and 23 minutes ago]

Thu, 27 Feb 2025 15:11:20 GMT

On 2/27/25 09:21, Bald Eagle wrote:
> (and heck, while we're at it, why not just throw in 2 functions to degree
> elevate and degree reduce a Bezier spline)

:-) just...

Thanks for posting this code. I have no feel for it at the moment, but 
would like to play. Longer term, I'll ponder the suggestions.

Initial reaction is I'm unsure how to nicely handle inputs and results 
if made inbuilt today. And, I doubt whether these things really need to 
be inbuilt functions? With the curves and derivatives themselves I 
wanted to be able to use them within the VM at render time.

Maybe these could be shipped macros in a core include file...

Bill P.

[Bald Eagle] Re: Suggest v4.0 f_bezier_2d_...() functions. (y... [406 days 6 hours and 9 minutes ago]

Thu, 27 Feb 2025 14:25:00 GMT

(and heck, while we're at it, why not just throw in 2 functions to degree
elevate and degree reduce a Bezier spline)

untested, not generalized (but I think you can see the pattern):

#macro DegreeElevateBezier(P0, P1, P2, P3)
  // Calculate the new control points for the quartic Bézier spline
  #local Q0 = P0;
  #local Q1 = (1/4)*P0 + (3/4)*P1;
  #local Q2 = (1/2)*P1 + (1/2)*P2;
  #local Q3 = (3/4)*P2 + (1/4)*P3;
  #local Q4 = P3;

  // Return the new control points
  array[5] {Q0, Q1, Q2, Q3, Q4}
#end

#macro DegreeReduceBezier(Q0, Q1, Q2, Q3, Q4)
  // Calculate the new control points for the cubic Bézier spline
  #local P0 = Q0;
  #local P1 = (4/3)*Q1 - (1/3)*Q0;
  #local P2 = (4/3)*Q3 - (1/3)*Q4;
  #local P3 = Q4;

  // Return the new control points
  array[4] {P0, P1, P2, P3}
#end

[Bald Eagle] Re: Suggest v4.0 f_bezier_2d_...() functions. (y... [406 days 6 hours and 24 minutes ago]

Thu, 27 Feb 2025 14:10:00 GMT

William F Pokorny <ano### [at] anonymousorg> wrote:
> Adding the inbuilt functions: f_bezier_2d_linear()
> f_bezier_2d_quadratic() f_bezier_2d_cubic() f_bezier_2d_quartic() and
> f_bezier_2d_quintic() to the next yuqk release (R19).
>
> The functions take and return single float packed 2d vectors in a
> double's space for control points and return values. Calculations are at
> double float accuracy internal to each functions code. The t parameter
> is passed as a double.

Of use would also be a function that takes a t parameter and splits an extant
curve into 2 splines that are, over their combined lengths, equivalent to the
original Bezier curve.

I tested this in excel, and it works nicely.

#macro SplitBezier (P0, P1, P2, P3, t)
  #local Q0 = P0 + t * (P1 - P0);
  #local Q1 = P1 + t * (P2 - P1);
  #local Q2 = P2 + t * (P3 - P2);

  #local R0 = Q0 + t * (Q1 - Q0);
  #local R1 = Q1 + t * (Q2 - Q1);

  #local S = R0 + t * (R1 - R0);

  // First segment: P0 to S
  #declare Segment1 = array[4] {P0, Q0, R0, S};

  // Second segment: S to P3
  #declare Segment2 = array[4] {S, R1, Q2, P3};

  Segment1, Segment2
#end

// Example usage
#declare P0 = <0, 0, 0>;
#declare P1 = <1, 2, 0>;
#declare P2 = <2, 2, 0>;
#declare P3 = <3, 0, 0>;
#declare t = 0.5;

#declare Segments = SplitBezier (P0, P1, P2, P3, t);
#declare Segment1 = Segments[0];
#declare Segment2 = Segments[1];

[William F Pokorny] Re: Suggest v4.0 default items [407 days 20 hours and 45 minutes ago]

Tue, 25 Feb 2025 23:48:52 GMT

On 2/25/25 09:22, Bald Eagle wrote:
> It's unclear if something can be done with how the rainbow {} effect gets
> implemented.
> 
> I'm unsure if any other sorts of optical effects are direction-vector
> controlled, (aoi? slope?) but allowing transforms on rainbow {} (and maybe even
> sky_sphere) might be interesting for future optical projects or artistic effects
> that are difficult or impossible to achieve otherwise.

The sky_shpere{} isn't a real thing so there is nothing to transform. 
Whacking the pigment{} is it given the set up.

The rainbow{} feature was deleted from the yuqk{} fork. It's little 
used, and has internal issues I didn't want to fix. Partly too, the 
current code in official releases is implemented in a way which adds 
overhead all the time to all renders(*).

For yuqk, if I get back to taking up looking at rainbow / glory effects 
I want to start fresh. My bet is there are ways to fake some or all of 
the effects (One idea is multiple color fog{}s and invisible shapes), 
but I've not spent any time trying.

Bill P.

(*) - The fog{} feature adds constant overhead too, but it's much more 
useful.

[Leroy] Re: Macros and other code snippets [407 days 22 hours and 49 minutes ago]

Tue, 25 Feb 2025 21:45:00 GMT

"Bald Eagle" <cre### [at] netscapenet> wrote:
> "Bald Eagle" <cre### [at] netscapenet> wrote:
> > As part of trying to organize my thoughts and assemble a collection of useful
> > macros and code snippets, I made a big list in a spreadsheet,
>
> Just so you know what's already on the list (some may be cryptic abbreviated
> notes):
>
That's a large undertaking. I get a headache just thinking about it. I just
transfer all my old POV from my XP to the new win10. It been at least a year and
I still don't have it even half way organize. The main thing I haven't tackled
is the many versions of POV (3.0 to 3.7)that I have code for. To make matters
worse I now have 3.8.
 The main problem is some of the code from the earlier versions uses tricks to
do what newer versions do more efficiently.Like the Array_function I wrote to
fake the mixed array of version 3.8. I also wrote code to fake the reflection of
light before Radiosity.

 Enough of my problems, I hope you do well in organizing things.

Have Fun!

[Bald Eagle] Re: Macros and other code snippets [408 days 3 hours and 49 minutes ago]

Tue, 25 Feb 2025 16:45:00 GMT

"Bald Eagle" <cre### [at] netscapenet> wrote:
> As part of trying to organize my thoughts and assemble a collection of useful
> macros and code snippets, I made a big list in a spreadsheet,

Just so you know what's already on the list (some may be cryptic abbreviated
notes):

Drop-Down Insert Menu
 Wireframe shapes
 Basic scene
 Text
 Mathematical text
 axes
 dependencies
 Dodecahedron normals
 Icosahedron normals
 trace ()

Function graphing
Parametric mesh
Parametric mesh2
Read / Write to/from file
Isosurface Evaluate
Heightfield correcting macro
Image_map in memory from a function
Analytical Geometry include
irid
3-point lighting
transparent background
Data structures
Vector math
matrices
Solve geometric problems
Scene layout tools
Matrix determinants
Minimum visible sphere radius
Analytical tangents between 2 circles
Numerical pigment patterns
Catenary
Full-color pigment
f_Identifier - function
v_Identifier - vector quantity
s_Identifier - scalar quantity
C_Identifier - color
P_Identifier - Pigment
T_Identifier - Texture
L_Identifier - a loop variable: #for (L_Identifier, 0, 10)
Point transforms
eval_pigment ()
now ()
trace ()
orthographic
macro names
Use cases
Sorting
Array macros
srgb
GitHub repositories
Wiki accounts
Barycentric coordinates
Stacks
Pipes
Normal maps
Vector swizzling
Prism macro for 3D vectors
reflected ray macro/function
multiple result trace ()
Lerp
invLerp
Remap
convex hull
Trig functions
bitwise XOR
lucida-sans-unicode.ttf
arial-unicode-ms.ttf
Rendering with ini files
2-pass radiosity
Monolithic include file   snip out used parts to make Scene_standalone?
Keyword examples
example scenes
convolution
FFT
camera location
point object
bicubic patch texture interpolation
no absolute zeros in pigments
Test Object
Standard render rig for comparisons
Thomas Fester posts
vector object - position + normal
Gray code
decimal to binary
Media macros
Ini file SECTIONS
input file name
use pattern to get B&W pigment
Hilbert curves
for each macro  (thread)
jr's macros
pov earth macros
area light macro  area light setup thread
comparison of numeric values in functions
Fractracer
lohmueller include translations
Mike Williams function thickening

Include files
 Chris Colefax
 GALAXY
 TILE GENERATOR
 COMPRESSED MESH macro
 CITY GENERATOR
 LIQUID SPRAY
 OBJECT EXPLODER
 BRUSHED METAL
 LENS EFFECTS
 OBJECT BENDER
 COILS
 SPIDERWEB

 Rune
 PARTICLE SYSTEM
 ELECTRICITY
 INVERSE KINEMATICS for necks/tentacles
 ILLUSION

[Bald Eagle] Macros and other code snippets [408 days 5 hours and 9 minutes ago]

Tue, 25 Feb 2025 15:25:00 GMT

As part of trying to organize my thoughts and assemble a collection of useful
macros and code snippets, I made a big list in a spreadsheet, but would like to
have something that's more generally useful and easier to update / navigate.

I'm thinking about something along the lines of a directory tree that then gets
zipped, and can be either unzipped into an existing pov-ray directory tree for
use,
or unzipped into a development folder for collaborative editing, updating with
newer versions of old macros, insert menu items, or didactic demonstrative scene
files (newer versions are added into the directory, retaining the older
versions).

No idea when I'll get everything organized and zipped, but I figured I would
alert the general readership and solicit submissions - since we're all aware how
things which ought to be archived tend to disappear.

I should probably make a folder for archived websites like Mike Williams' and
Chris Colefax's stuff.

- BE

[Bald Eagle] Re: Suggest v4.0 default items [408 days 6 hours and 9 minutes ago]

Tue, 25 Feb 2025 14:25:00 GMT

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

> The top row comes from today's v3.8 beta 2, where the right column added
> '+mv3.8' to fix a v3.8 defaulting issue (see below).

So, your ellipsoid there reminded me:

Philip Laven pointed out that due to the conditions that give rise to the glory
effect, the rainbow is virtually never circular.
I tried scaling the rainbow {} "object" but as I expected, that didn't work.

I had to scale the camera, which means that to do it properly / realistically,
then everything in the scene needs to be enclosed in a union {}, the camera
scaled, and the union scaled with the inverse of the camera transform.

Currently, we can scale and otherwise transform the pigment of a sky_sphere:
https://wiki.povray.org/content/Reference:Sky_Sphere

It's unclear if something can be done with how the rainbow {} effect gets
implemented.

I'm unsure if any other sorts of optical effects are direction-vector
controlled, (aoi? slope?) but allowing transforms on rainbow {} (and maybe even
sky_sphere) might be interesting for future optical projects or artistic effects
that are difficult or impossible to achieve otherwise.

- BW

[Kenneth] Re: Suggest v4.0 default items [408 days 8 hours and 59 minutes ago]

Tue, 25 Feb 2025 11:35:00 GMT

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

> (***) - As clipka used to point out, 'default{}' (like
> global_settings{})  isn't really a language directive, but a keyword
> driven block. These should be specified without the leading '#', but
> official releases of POV-Ray continue to support the old syntax.

I didn't know that a #default could be used without the leading #, at least in
the v3.8 betas. Interesting.
>
> Aside: The camera{} defaulting is tangled with the default{} block and
> #version setting and it's partly broken in v3.8. One must specify +mv3.8
> (or use an ini setting for the version) to get the intended v3.8 camera
> defaulting. Ah, probably adding camera{} at the very bottom of the scene
> file would work as a user fix too - it was an ordering / timing bug.

Yes, specifying an empty camera{} does correct the v3.8 'broken' camera default,
just like adding +mv3.8. And apparently, it can go anywhere in the scene.

Although, I can't say that I understand *why* it works.  When there is NO
specified camera in the scene (thus a 'default' camera being used), it should be
the same 'default' entity as the empty  camera{} statement (?)...yet the two
behave differently.

[William F Pokorny] Re: Suggest v4.0 f_kappa_2d() function. (yuqk R1... [409 days 23 hours and 33 minutes ago]

Sun, 23 Feb 2025 21:00:48 GMT

On 2/23/25 09:07, Bald Eagle wrote:
> William F Pokorny <ano### [at] anonymousorg> wrote:
> 
>> This a general helper function / technique to match any two curves at
>> their endpoints given you have the means to calculate the first and
>> second derivatives for both curves being glued together at (t).
> 
> Are f' and f" arguments to the function?

Could be, but see below.

> 
>> The function will calculate and return 'k(t)' or the 'radius of
>> curvature' (1.0/k(t)).
>>
>> Attaching images showing on the left k(t), and on the right the 'radius
>> of curvature' at t, as the length of the normal vectors for a
>> f_bezier_2d_cubic() curve.
> 
...
> 
> Do you plug f_bezier_2d_cubic() into your function and it calculates the
> derivatives?  Can you plug in, say, Perlin Noise, and have that work?
> 

Sort of.

No. The capability isn't that general - and limited to 2D (*).

With the f_bezier_2d_* functions and, for example, f_catenary() from a 
few releases back, the function which generates the curve has too 
calculation modes inbuilt for the first and second derivatives - and 
sometimes the third as well.

So the typical set up would be something like:

//...
#declare FnBez_2d = function (ro_t,ro_mode) {
     f_bezier_2d_cubic(
           f_enc2x_f32(-1.0,0),
           f_enc2x_f32(-1/2,0.5),
           f_enc2x_f32(+1/2,-0.5),
           f_enc2x_f32(1.0,0),
           ro_t,ro_mode
     )
}
#declare U02 = union {
     #for (I,0,SphCnt,4)
...
         #declare D1 = FnBez_2d(I/SphCnt,3); // Calc raw 1st derivative
         #declare D2 = FnBez_2d(I/SphCnt,4); // Calc raw 2nd derivative
         #declare Kappa = f_kappa_2d(D1,D2,0); // Pass the values
...
     #end
     texture { pigment { Frostbite } finish {emission 1.0} }
}
//...

Where you have a univariate polynomial for the curve, it's not too bad 
to calculate the derivative polynomials as Alain pointed out.

Bill P.

(*) Lying some as by measuring local deltas we could probably come up 
with D1 & D2 values which would be in the ballpark to some sampling 
accuracy.

[Alain Martel] Re: Suggest v4.0 f_kappa_2d() function. (yuqk R1... [410 days 5 hours and 1 minute ago]

Sun, 23 Feb 2025 15:32:54 GMT

Le 2025-02-23 Ã  09:07, Bald Eagle a Ã©critÂ :
> William F Pokorny <ano### [at] anonymousorg> wrote:
> 
>> This a general helper function / technique to match any two curves at
>> their endpoints given you have the means to calculate the first and
>> second derivatives for both curves being glued together at (t).
> 
> Are f' and f" arguments to the function?
> 
>> The function will calculate and return 'k(t)' or the 'radius of
>> curvature' (1.0/k(t)).
>>
>> Attaching images showing on the left k(t), and on the right the 'radius
>> of curvature' at t, as the length of the normal vectors for a
>> f_bezier_2d_cubic() curve.
> 
> That's pretty slick.
> (If you add f'", then you can match RATE of curvature, so that reflections are
> smooth as well.)
> 
> 
> Do you plug f_bezier_2d_cubic() into your function and it calculates the
> derivatives?  Can you plug in, say, Perlin Noise, and have that work?
> 
> You've been busy!  :)
> 
> - BW
> 
f' and f" being first and second derivatives, it's easy to calculate 
them on the fly.

Let say that you have f(x) = 7x^2+-3x+6,
  then, f'(x) = 7x-3,
  and f"(x) = 7

[Bald Eagle] Re: Suggest v4.0 f_kappa_2d() function. (yuqk R1... [410 days 6 hours and 24 minutes ago]

Sun, 23 Feb 2025 14:10:00 GMT

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

> This a general helper function / technique to match any two curves at
> their endpoints given you have the means to calculate the first and
> second derivatives for both curves being glued together at (t).

Are f' and f" arguments to the function?

> The function will calculate and return 'k(t)' or the 'radius of
> curvature' (1.0/k(t)).
>
> Attaching images showing on the left k(t), and on the right the 'radius
> of curvature' at t, as the length of the normal vectors for a
> f_bezier_2d_cubic() curve.

That's pretty slick.
(If you add f'", then you can match RATE of curvature, so that reflections are
smooth as well.)

Do you plug f_bezier_2d_cubic() into your function and it calculates the
derivatives?  Can you plug in, say, Perlin Noise, and have that work?

You've been busy!  :)

- BW

[William F Pokorny] Re: Suggest v4.0 f_kappa_2d() function. (yuqk R1... [410 days 6 hours and 43 minutes ago]

Sun, 23 Feb 2025 13:51:05 GMT

On 2/23/25 08:43, William F Pokorny wrote:
> Attaching images showing on the left k(t), and on the right the 'radius 
> of curvature' at t

Dang. Posted the wrong image... Correct one attached.

Bill P.

[William F Pokorny] Suggest v4.0 f_kappa_2d() function. (yuqk R19 v0... [410 days 6 hours and 51 minutes ago]

Sun, 23 Feb 2025 13:43:28 GMT

Adding the inbuilt f_kappa_2d() function to the upcoming release (R19) 
of yuqk).

This a general helper function / technique to match any two curves at 
their endpoints given you have the means to calculate the first and 
second derivatives for both curves being glued together at (t).

The function will calculate and return 'k(t)' or the 'radius of 
curvature' (1.0/k(t)).

Attaching images showing on the left k(t), and on the right the 'radius 
of curvature' at t, as the length of the normal vectors for a 
f_bezier_2d_cubic() curve.

Bill P.

[ingo] Re: POV-Ray is "PIEware" [410 days 8 hours and 29 minutes ago]

Sun, 23 Feb 2025 12:05:00 GMT

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

Nice.

I remember using the tri-scan macro, but it got lost somewhere in the last
decade.

ingo

[William F Pokorny] Re: Suggest v4.0 default items [410 days 13 hours and 35 minutes ago]

Sun, 23 Feb 2025 06:59:25 GMT

On 2/22/25 17:26, Bald Eagle wrote:
> DEFAULT_DIRECTIVE:
>    #default {DEFAULT_ITEM }
> DEFAULT_ITEM:
>    TEXTURE | PIGMENT | NORMAL | FINISH

IIRC supported too is a radiosity{} setting - importance I think - and a 
default camera{} can be set. The documentation isn't up to date.

> 
> Maybe this ought to include
> 
> interior_texture
> ior
> 
> possibly others
> 

Others have suggested interior{} be made available. I believe because an 
ior setting of other than the defaulted 1.0 value is necessary for many 
of the new to v3.8 albedo / finish{} level fresnel features to work as 
implemented / intended.

---

FWIW. The plan with yuqk is to eliminate the 'default' directive / 
keyword altogether(***). There are a number of issues with it. My belief 
is version defaults need to be fixed for other downstream features to 
work reliably. I know, it's handy and many of us use the feature.

With ior the long term plan for yuqk is to implement two ior settings. 
One in finish{} (*) which would be the surface ior and the other ior 
still in the interior{} block which would be used for ray traveling 
within object effects. After which, the interior{} blocks would resume 
being optionally attached to objects where in v3.8 / V3.7? they always 
exist (**).

(*) - One can specify an ior in the finish{} block today in official 
POV-Ray releases due an effort to maintain backward compatibility. IIRC, 
  a warning is issued. The yuqk code has a start on the new finish { ior 
} capability, but it's not completely implemented. The default finish { 
ior value } value will be 1.5 - so the new v3.8 finish{} features would 
be set up to work correctly without need to change ior settings.

(**) - I have some guesses, but I'm unsure exactly why we ended up with 
interior{} blocks always attached to objects.

(***) - As clipka used to point out, 'default{}' (like 
global_settings{})  isn't really a language directive, but a keyword 
driven block. These should be specified without the leading '#', but 
official releases of POV-Ray continue to support the old syntax.

The following code was used for the attached images:

//--------------
#version 3.8;

global_settings { assumed_gamma 1.0 }
default { finish {ior 1.5 emission 1.0} camera {} }

sphere { <0,0,2> 0.5 pigment { rgbt <1,0,0,0.9> } hollow }

plane { y, -5 pigment { checker } }
//--------------

The top row comes from today's v3.8 beta 2, where the right column added 
'+mv3.8' to fix a v3.8 defaulting issue (see below).

On the bottom row is yuqk's current result (+mv3.8 not being required as 
yuqk correctly handles the camera{} defaulting).

With yuqk the finish{ ior 1.5 } is partly implemented so it doesn't set 
the interior{} block's ior as do official releases. In other words we 
see no refraction in the yuqk result from the finish {ior 1.5} setting. 

Bill P.

Aside: The camera{} defaulting is tangled with the default{} block and 
#version setting and it's partly broken in v3.8. One must specify +mv3.8 
(or use an ini setting for the version) to get the intended v3.8 camera 
defaulting. Ah, probably adding camera{} at the very bottom of the scene 
file would work as a user fix too - it was an ordering / timing bug.

[Bald Eagle] Suggest v4.0 default items [410 days 22 hours and 4 minutes ago]

Sat, 22 Feb 2025 22:30:00 GMT

DEFAULT_DIRECTIVE:
  #default {DEFAULT_ITEM }
DEFAULT_ITEM:
  TEXTURE | PIGMENT | NORMAL | FINISH

Maybe this ought to include

interior_texture
ior

possibly others

[William F Pokorny] Suggest v4.0 f_bezier_2d_...() functions. (yuqk ... [410 days 23 hours and 54 minutes ago]

Sat, 22 Feb 2025 20:40:23 GMT

Adding the inbuilt functions: f_bezier_2d_linear() 
f_bezier_2d_quadratic() f_bezier_2d_cubic() f_bezier_2d_quartic() and 
f_bezier_2d_quintic() to the next yuqk release (R19).

The functions take and return single float packed 2d vectors in a 
double's space for control points and return values. Calculations are at 
double float accuracy internal to each functions code. The t parameter 
is passed as a double.

The calculation and return mode settings:
   0=<u,v> at t.
   1=<u',v'> at t.             (Tangent normalized)
   2=<normal u,normal v> at t. ((1) rotated for normal)
   3=<u',v'> at t.             (Tangent / velocity)
   4=<u'',v''> at t.           (Acceleration / change in tangent)
   5=<u''',v'''> at t.         (Jerk / change in acceleration)

Attaching images showing all six calculation and return modes for 
f_bezier_2d_cubic() f_bezier_2d_quartic() and f_bezier_2d_quintic().

Bill P.


Extra Detail
------------

The code approach settled upon will I believe easily map to 3D vectors 
excepting the normal mode (2) calculations. Holding off though, I'd like 
to play with this new 2d code for a while and, as inbuilt functions, 
we'd end up working in a three, 21bit, float packed, reduced range for 
the easy 3D adoption.

---

IIRC, Bald Eagle asked whether the derivatives weren't lower orders of 
the Bezier curve itself. I currently believe the answer to be, yes, with 
qualifications.

First, there are compensating factors for each derivative order based 
upon the initial Bezier curve:

Quadratic derivative factors:
   '   --> 2
   ''  --> 2
   ''' --> DNA

Cubic derivative factors:
   '   --> 3
   ''  --> 6
   ''' --> 6

Quartic derivative factors:
   '   --> 4
   ''  --> 12
   ''' --> 24

Quintic derivative factors:
   '   --> 5
   ''  --> 20
   ''' --> 60

I used 1/(factors above) multipliers to better view the raw 1st, 2nd and 
3rd derivative value curves(*) (modes 4,5 and 6) together. The 
derivative value curves(*) tend to get much larger as the derivative 
order increases.

Second, some algebra is required to come up with the new P' factors for 
each derivative Bezier curve.

(*) - The curves are showing the entire sample set of values as spheres. 
The strict sphere(t) curve may have folds where parts of the apparent 
curve are getting retraced.

---

[Bald Eagle] Re: POV-Ray is "PIEware" [411 days and 29 minutes ago]

Sat, 22 Feb 2025 20:05:00 GMT

I also found this (!)
But haven't had the opportunity to look it over.

http://news.povray.org/povray.binaries.scene-files/thread/%3C38CB12D0.732F7F15@enter.net%3E/?ttop=321382&toff=950

[Bald Eagle] Re: POV-Ray is "PIEware" [411 days and 39 minutes ago]

Sat, 22 Feb 2025 19:55:00 GMT

"ingo" <nomail@nomail> wrote:

> But, I think your method, trace, move by epsilon, trace, should work. You'd get
> all the object/ empty space transitions. Depending on the goal, instead of
> tracing from the camera, you could scan from one surface of the bounding box to
> the opposite. Store all intersections in arrays of arrays. For test render each
> point as a small sphere.
>
> ingo

[William F Pokorny] Suggest v4.0 f_lcm() function. (yuqk R18 v0.6.12... [434 days 15 hours and 37 minutes ago]

Thu, 30 Jan 2025 04:57:23 GMT

Adding new f_lcm() inbuilt function to the yuqk fork.

#include "functions.inc"

#debug "\n"
#debug concat("f_lcm      2 ",str(f_lcm(2,3,5,7,11,13,1),7,0)," \n")
#debug concat("f_lcm      6 ",str(f_lcm(2,3,5,7,11,13,2),7,0)," \n")
#debug concat("f_lcm     30 ",str(f_lcm(2,3,5,7,11,13,3),7,0)," \n")
#debug concat("f_lcm    210 ",str(f_lcm(2,3,5,7,11,13,4),7,0)," \n")
#debug concat("f_lcm   2310 ",str(f_lcm(2,3,5,7,11,13,5),7,0)," \n")
#debug concat("f_lcm  30030 ",str(f_lcm(2,3,5,7,11,13,6),7,0)," \n")
#debug concat("f_lcm     24 ",str(f_lcm(2,3,4,6, 8,12,6),7,0)," \n")
#debug concat("f_lcm     24 ",str(f_lcm(2,3,4,6, 8,12,5),7,0)," \n")
#debug concat("f_lcm     12 ",str(f_lcm(2,3,4,6, 8,12,4),7,0)," \n")
#debug concat("f_lcm     12 ",str(f_lcm(2,3,4,6, 8,12,3),7,0)," \n")
#debug "\n"

#error "Not error, stopping early"

Bill P.

[William F Pokorny] Re: Suggest v4.0 f_round() and f_gcd() functions... [435 days and 19 minutes ago]

Wed, 29 Jan 2025 20:15:25 GMT

On 1/29/25 13:52, Bald Eagle wrote:
> William F Pokorny <ano### [at] anonymousorg> wrote:
> 
>> Anyhow. I can add f_lcm(). Do you have applications in mind?
> 
> https://news.povray.org/web.6692e0a94551427b1f9dae3025979125%40news.povray.org
> 
> But I have also seen some crazy patterns in Desmos using lcm and gcd.
> 
> - BW
> 
>

Thanks.

Cool. Now that I see it, I vaguely remember your post! :-)

Bill P.

[Bald Eagle] Re: Suggest v4.0 f_round() and f_gcd() functions... [435 days 1 hour and 39 minutes ago]

Wed, 29 Jan 2025 18:55:00 GMT

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

> Anyhow. I can add f_lcm(). Do you have applications in mind?

https://news.povray.org/web.6692e0a94551427b1f9dae3025979125%40news.povray.org

But I have also seen some crazy patterns in Desmos using lcm and gcd.

- BW

[William F Pokorny] Re: Suggest v4.0 f_round() and f_gcd() functions... [435 days 3 hours and 19 minutes ago]

Wed, 29 Jan 2025 17:15:26 GMT

On 1/29/25 10:34, Bald Eagle wrote:
> William F Pokorny <ano### [at] anonymousorg> wrote:
>> Adding new f_round() and f_gcd() inbuilt functions to the yuqk fork. I
>> believe the f_round() function will be useful. Less sure of the f_gcd()
>> function, but it's there to try.
> 
> gcd is useful.
> 
> https://news.povray.org/web.6692de0293217bca1f9dae3025979125%40news.povray.org
> 
> https://news.povray.org/web.66a51e9b3bd24dfe1f9dae3025979125%40news.povray.org
> 
> Any chance at adding f_lcm()?
> 
> - BW
> 

I apparently missed that first post when you made it.

The second I remember because I used that scene to start chasing some 
bug. A bug-ball I apparently dropped. At the moment I cannot for the 
life of me remember what it was about. :-(

Anyhow. I can add f_lcm(). Do you have applications in mind?

Bill P.

[Bald Eagle] Re: Suggest v4.0 f_round() and f_gcd() functions... [435 days 4 hours and 59 minutes ago]

Wed, 29 Jan 2025 15:35:00 GMT

William F Pokorny <ano### [at] anonymousorg> wrote:
> Adding new f_round() and f_gcd() inbuilt functions to the yuqk fork. I
> believe the f_round() function will be useful. Less sure of the f_gcd()
> function, but it's there to try.

gcd is useful.

https://news.povray.org/web.6692de0293217bca1f9dae3025979125%40news.povray.org

https://news.povray.org/web.66a51e9b3bd24dfe1f9dae3025979125%40news.povray.org

Any chance at adding f_lcm()?

- BW

[William F Pokorny] Suggest v4.0 f_round() and f_gcd() functions. (y... [435 days 16 hours and 2 minutes ago]

Wed, 29 Jan 2025 04:32:16 GMT

Adding new f_round() and f_gcd() inbuilt functions to the yuqk fork. I 
believe the f_round() function will be useful. Less sure of the f_gcd() 
function, but it's there to try.

Attached and image generated with the attached scene file.

Bill P.

[Bald Eagle] Re: SDL2 [447 days 1 hour and 34 minutes ago]

Fri, 17 Jan 2025 19:00:00 GMT

https://github.com/jaafersheriff/CPU-Ray-Tracer

[Bald Eagle] Re: SDL2 [447 days 2 hours and 4 minutes ago]

Fri, 17 Jan 2025 18:30:00 GMT

https://nim-lang.org/blog/2020/06/30/ray-tracing-in-nim.html

[Bald Eagle] Re: SDL2 [447 days 6 hours and 34 minutes ago]

Fri, 17 Jan 2025 14:00:00 GMT

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

> diagrams and charts, _yes_.  to add.

[jr] Re: SDL2 [447 days 12 hours and 19 minutes ago]

Fri, 17 Jan 2025 08:15:00 GMT

hi,

pushed for time currently, sorry for omission(s).

"ingo" <nomail@nomail> wrote:

thx for the Nim ref.

> ...
> For writing, syntax and usability testing, of a new SDL language one could write
> a small language, parser and SDL1 transpiler. With a subset of SDL a lot can be
> testet. The output can be the simplest form of current POV-Ray SDL with loops
> enrolled etc.

and Bald Eagle wrote:
> At this juncture, we really need a functional flowchart showing exactly HOW
> POV-Ray goes from the SDL in .pov file to the final rendered image.

diagrams and charts, _yes_.  to add.

I do think the "new POV-Ray" should ship with built-in "schizophrenia" ;-).  if
a version number of less than n.n is given, or the version is missing, the job
goes to the old parser/POV-Ray as of 3.8 (?), else it'll be a version indicating
"SDL2" and the new code takes over.

we need to start with the outline of the "backend", the render engine.  aiui, a
(LL)Virtual Machine is (was?) supposed to be "platform".  as the design of the
LLVM firms up we'll get the (first cut at the) "API".

once there's a specialised rendering "API", we can start thinking about language
features for, I hope, a SDL which compiles[*] to the LLVM low-level
instructions.

[*] many scripting languages, including PHP and Tcl, compile "just-in-time".

with a bit of luck almost all of this can (and should) be "transparent" to us
"end-users".

regards, jr.

[ingo] Re: SDL2 [447 days 14 hours and 14 minutes ago]

Fri, 17 Jan 2025 06:20:00 GMT

"Bald Eagle" <cre### [at] netscapenet> wrote:
> Also, in the above referenced book, they discuss how most commercial /
> production raytracers convert everything to triangles before rendering.

The ability to mesh-ify a scene, objects etc. is extremely useful. It would
explicitly break POV-Ray into two parts, a SDL and a raytracer. The SDL side can
be used for other rendering back ends, OpenGL previews or complete renderings,
3d printing etc. One can use a kind of hybrid style of SDL coding, start solid,
go to mesh and do subdivisions and other mesh wizardry.

For writing, syntax and usability testing, of a new SDL language one could write
a small language, parser and SDL1 transpiler. With a subset of SDL a lot can be
testet. The output can be the simplest form of current POV-Ray SDL with loops
enrolled etc.

ingo

[Bald Eagle] Re: SDL2 [447 days 23 hours and 49 minutes ago]

Thu, 16 Jan 2025 20:45:00 GMT

Also, in the above referenced book, they discuss how most commercial /
production raytracers convert everything to triangles before rendering.

I think it would be a useful feature to have, and it's certainly a
long-requested one.

It would enable folks to save files as meshes, and allow 3D printing of scenes.

Obviously, this would be difficult or impossible for things like fractals,
media, etc.

I also found this:
http://news.povray.org/povray.binaries.utilities/thread/%3C41605076@news.povray.org%3E/

in case anyone wanted to try a marching cubes utility!  :)

- BW

(Who knows what else lurks in the archives)

[Bald Eagle] Re: SDL2 [447 days 23 hours and 54 minutes ago]

Thu, 16 Jan 2025 20:40:00 GMT

https://web.archive.org/web/20060116142746/http://research.orf.cx/lj2004.html

[Bald Eagle] Re: SDL2 [448 days and 4 minutes ago]

Thu, 16 Jan 2025 20:30:00 GMT

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

> > Do we think that there's a way to export POV-Ray's "Abstract Syntax Tree" or
> > whatever we use after the scene has been parsed and lexed?
>
> Disclaimer. I am no parser / (POV-Ray parsing) expert...
>
> ... Suppose maybe code could be hacked and whacked to export something
> for, say, the expression parsing alone.
>
> Beyond that, my bet is it would be difficult to do without a significant
> investment of time - and the result won't be clean. I certainly don't
> have anything in hand. Maybe others have made runs at such work and have
> something more?

Right, but at the moment we really don't have anything, so even the most
imperfect / incomplete thing would be a step forward.

Do you know if the AST is - - - assembled into some kind of data structure in
memory right before rendering, and that's what the render phase operates upon?
Perhaps that data structure could just be barfed out so that we could take a
gander at it.

> Today's POV-Ray / yuqk parsers are convoluted and tangled with the
> raytracing code itself. I see the current parsers as more like
> semi-direct text to scene translators.

Right - this is the part that I don't understand.  How does the parser and
raytracing code get entangled like that?  Even a small example where two are
intertwined would help.  Just point to line #'s nnn-NNN in such-and-such a file.

> > Comparing and contrasting a new parser with one that's being developed would be
> > a useful debugging tool, and a way to measure progress and completion.
> >
>
> In offline discussions with jr, we discussed some approaches to a brand
> new parser and with a POV-Ray 4.0 (or 5.0). There is value to thinking
> hard about what Scene Description Language 2.0 should be and perhaps
> writing potential parsers for it that interface to something. I'd lean
> toward that 'something' being a limited set of today's SDL while working
> up what we want any language implementation to be. (Perhaps flattened /
> un-nested SDL using very few language directives)

Likewise, we've had several discussions and brainstorming sessions.
However before we start talking about a new SDL, I think we need to understand
the parsing lexing part.
I actually feel confident enough to write a lot of the actual raytracing code
myself - and luckily, I don't think there will need to be a lot of it
(re)written.
By flattened un-nested SDL, you're suggesting something akin to writing a scene
in another language and having it generate every instance of a thing that would
be in a loop in current SDL.  So if I had a loop that instantiated 100 spheres,
what we'd be doing is writing out the code for all 100 spheres individually to
be parsed.

> Much in the POV-Ray source code needs/could-use work/refining. This
> includes the core functionality itself - and the core feature set is
> where I've been focused for the better part of a decade now.

So you've added features to SDL.
We are all curious about exactly what needs to happen to fully accomplish such a
task.
See such an explanation by Leigh Orf at:
https://dl.acm.org/doi/fullHtml/10.5555/1029015.1029017
Apparently there are specific things that need to be done in several files to
make this happen.

- BW

[William F Pokorny] Re: SDL2 [448 days and 51 minutes ago]

Thu, 16 Jan 2025 19:42:38 GMT

On 1/16/25 11:48, Bald Eagle wrote:
> Ingo:  Thanks for the reminder about Nim.
> There's some pretty good ideas in there.
> I'm hoping we can begin to figure something out in this coming year.
> 
> 
> https://pbrt.org/
> 
> https://pbr-book.org/3ed-2018/contents
> 
> https://pbr-book.org/3ed-2018/Scene_Description_Interface
> I found this quite interesting, especially the part discussing immediate mode vs
> retained mode style.
> 
> William Pokorny: you might find some of the stuff in "Utilities" useful.
> 

Thanks for the reminder. I spent some time years back looking over that 
book and code, but confess to not having gone back to it for five years 
plus. Certainly good ideas there-in.

> 
> Do we think that there's a way to export POV-Ray's "Abstract Syntax Tree" or
> whatever we use after the scene has been parsed and lexed?

Disclaimer. I am no parser / (POV-Ray parsing) expert...

... Suppose maybe code could be hacked and whacked to export something 
for, say, the expression parsing alone.

Beyond that, my bet is it would be difficult to do without a significant 
investment of time - and the result won't be clean. I certainly don't 
have anything in hand. Maybe others have made runs at such work and have 
something more?

Today's POV-Ray / yuqk parsers are convoluted and tangled with the 
raytracing code itself. I see the current parsers as more like 
semi-direct text to scene translators.

> 
> Comparing and contrasting a new parser with one that's being developed would be
> a useful debugging tool, and a way to measure progress and completion.
> 

In offline discussions with jr, we discussed some approaches to a brand 
new parser and with a POV-Ray 4.0 (or 5.0). There is value to thinking 
hard about what Scene Description Language 2.0 should be and perhaps 
writing potential parsers for it that interface to something. I'd lean 
toward that 'something' being a limited set of today's SDL while working 
up what we want any language implementation to be. (Perhaps flattened / 
un-nested SDL using very few language directives)

Much in the POV-Ray source code needs/could-use work/refining. This 
includes the core functionality itself - and the core feature set is 
where I've been focused for the better part of a decade now.

I'm working inside out, functionality-wise, and deal with yuqk's parser 
derivative only to the degree I must to support this clean up (move to 
more solid functionality) push.

I don't have the bandwidth mentally / physically to do much more than 
what I'm doing already with core features and yuqk parser 'adjustments'. 

My hope is some of what I'm doing will be useful directly as code and 
help make clearer what the parsing / functionality should be for any 
v4.0 / v5.0. yuqk as a resource / reference.

Stuff popping into my head
--------------------------
Aside: Somewhat near term I plan to move the global_settings radiosity 
(and later photon) set up out of the parser altogether. I think much 
about these features should always have been ini set up items - not 
having anything to do with the parser!

Aside: I think we could pick up a chunk of performance by adding a step 
between the parser and prior to rendering where we re-allocate 'related 
stuff' in contiguous memory. This happens a few place today. With 
meshes, for example, due an internal, post memory allocation during 
parsing; it's a some lessor reason why meshes are fast. The 'related 
stuff' determination would probably include information passed from the 
parser - but how to do this is only a VERY vague idea in my head.
---

Anyhow... I agree with working out how to actively push forward toward 
what v4.0 / v5.0 should be and I believe ideas must be tried to work out 
any final path/result. Hearing my Dad chide me with: "The job doesn't 
get done by looking at it." :-)

Bill P.

[William F Pokorny] Suggest v4.0 upgrade the material_map feature. (... [448 days 2 hours and 15 minutes ago]

Thu, 16 Jan 2025 18:18:44 GMT

The yuqk fork's initial step was renaming this feature! It's now called 
image_indexed_textures{}.

The release notes for the updates are currently:

---

Re-worked the image_indexed_textures{} feature so it more reliably works 
with image formats supporting channel depths > 8 bits or channel values 
 >1.0.

- Texture list entry 0 is always the default background / unmapped 
region texture. Further, rather than wrap when palette registers/indexes 
exceed the number of textures in the list, yuqk maps these also to the 0 
texture entry.

- Adding support for color channel depths > 8 bits by specifying texture 
list of longer than 256 entries. (The 0.0..1.0 red channel multiplier 
becomes 65535.0 rather than always 255.0)

- High dynamic range images, which often have .red or .grey values > 1.0 
in typical use, can exploit this support by using the .red or .grey 
values directly as index values into the texture list.

- Removed a dynamic_cast in render time image value access code, which 
significantly improved performance.

- Additional parse time checks for valid map types, etc.

- Added warp{} parsing support missing always since warp{}s added.

- Rather than casting map image float values to integers, yuqk now 
rounds using std::lround() which makes interpolations more useable / stable.

- Negative .red / .grey channel values, which have never been handled 
explicitly, are now treated as equivalent positive index values after 
rounding.

- Fixed bugs in imageutil.cpp's InterpolateBicubic() and Interp() where 
the code by numerical noise was sometimes flipped into an index 
calculated mode.

---

Attached are two files. A first draft of yuqk's updated documentation 
and an image generated using the example scene which can be found in 
that documentation.

The image shows no interpolation in the upper left. Bi-linear in the 
upper right. Bi-cubic in the lower left. Normalized distance in the 
lower right while added somewhat extreme warp{<'turbulence'>}.

Of course, typical image_indexed_textures{} use would have a MUCH larger 
texture indexing image - and probably not use interpolation at all.

Bill P.

[Bald Eagle] Re: SDL2 [448 days 3 hours and 44 minutes ago]

Thu, 16 Jan 2025 16:50:00 GMT

Ingo:  Thanks for the reminder about Nim.
There's some pretty good ideas in there.
I'm hoping we can begin to figure something out in this coming year.


https://pbrt.org/

https://pbr-book.org/3ed-2018/contents

https://pbr-book.org/3ed-2018/Scene_Description_Interface
I found this quite interesting, especially the part discussing immediate mode vs
retained mode style.

William Pokorny: you might find some of the stuff in "Utilities" useful.


Do we think that there's a way to export POV-Ray's "Abstract Syntax Tree" or
whatever we use after the scene has been parsed and lexed?

Comparing and contrasting a new parser with one that's being developed would be
a useful debugging tool, and a way to measure progress and completion.

[ingo] Re: SDL2 [449 days 13 hours and 59 minutes ago]

Wed, 15 Jan 2025 06:35:00 GMT

"Bald Eagle" <cre### [at] netscapenet> wrote:
>
> This thread will quickly become a collection of disparate ideas that will need
> to be sorted and prioritized.
>

As an example, a SQL parser that produces an Abstract Syntax Tree, written in
Nim, a readable language.

The parsers code:
https://github.com/nim-lang/Nim/blob/version-2-2/lib/pure/parsesql.nim

The parsers doc:
https://nim-lang.org/docs/parsesql.html

Nim documentation:
https://nim-lang.org/documentation.html

ingo

[Bald Eagle] Re: SDL2 [449 days 23 hours and 49 minutes ago]

Tue, 14 Jan 2025 20:45:00 GMT

Look what/who I found:

https://www.martinjules.com/projects/single-project?id=5

[Bald Eagle] Re: SDL2 [451 days 1 hour and 4 minutes ago]

Mon, 13 Jan 2025 19:30:00 GMT

At this juncture, we really need a functional flowchart showing exactly HOW
POV-Ray goes from the SDL in .pov file to the final rendered image.

The only people that I know of who might have such knowledge (and who we're seen
post here "recently") are (in alphabetical order)

Chris Cason
Thorsten Frohlich
Jerome Grimbert
William Pokorny
Yvo Smellenburgh

If they could help lay things out such that we can get a head start on
understanding what really needs to happen to potentially rewrite everything from
scratch, that would be a big help.
Also, if they are in contact with other past members of the POV-Ray development
team, perhaps they can solicit some commentary from people that we haven't seen
in a while.

As far as I can tell (off the top of my head / rushed):
We have the parsing phase:
We have the parser that nibbles away at the SDL character by character,
identifying keywords and such.
All of that has to get filtered through error-handling routines.
Then the lexer/tokenizer converts all of that to (numerical?) tokens.
(guessing / speculating)
for every token, some sort of hierarchy is constructed
a bounding box is calculated

Then we have the render phase:
A ray gets shot from the camera to the coordinates corresponding to the current
screen pixel
The ray gets tested against "all" the bounding boxes (presumably there is some
kind of tree optimization)
If a bounding box is hit, then the ray gets tested against "all" objects in a
CSG (let's just call everything a CSG for now) and a solver gets invoked to
determine the ray-object intersection.
Once the intersection point is determined, the normal, texture, finish, etc get
handled.  This is likely the most complicated part, since we can have media,
transparent objects, ior, reflections, etc.
Stuff gets done with antialiasing
Pixel gets assigned an rgb color.

Please fill in the blanks and expand upon the generalizations, and correct the
errors.

- BW

[Bald Eagle] Re: SDL2 [451 days 2 hours and 14 minutes ago]

Mon, 13 Jan 2025 18:20:00 GMT

"jr" <cre### [at] gmailcom> wrote:
> one feature we're all (I think) keen to see would be
> a means to find out a variable's type.

I think this would best be illustrated by a .pov file trying to #read from a
data file of some sort.

This thread will quickly become a collection of disparate ideas that will need
to be sorted and prioritized.

I'd suggest creating a document (or better, a spreadsheet - for reasons I can
expand on) to append and annotate, thus keeping everything in one place.

Author, feature type (object, attribute [texture, pigment pattern], flow
control, introspective keyword, syntactical sugar, etc.), priority (core,
wanted, maybe-nice-to-have)

The more granular we make it, the easier it will be to deal with everything, and
make appropriate recommendations and changes.

Examples from existing languages would help easily illustrate syntax and usage
without having to write everything out from the outset.

Approaching this from a "unix-style" way of thinking: everything has a single
purpose, and the result is achieved by assembling the functional parts into a
cohesive whole.  This way, any time something has to be fixed/updated, the input
and the output remain unchanged, and it's only how things are handled internally
that changes.  Old versions ought to be deprecated and fully retained with
commentary, so as not to lose ideas and historical explanations about WHY things
were done.  Every keyword/feature ought to have a version number, and the last
working version ought to be retained in full (perhaps as keyword_lw so that the
newer version of the full software can still be used without rollbacks).

- BW

[jr] SDL2 [451 days 4 hours and 4 minutes ago]

Mon, 13 Jan 2025 16:30:00 GMT

hi,

the SDL2 design needs to have introspection facilities comparable to Tcl, or
better, ideally, I think.  one feature we're all (I think) keen to see would be
a means to find out a variable's type.

so if I wanted to write a macro or procedure which takes one argument that could
be, say for a colour, a 3-vector, 4-vector, or a 5-vector.

ideally we'd have keywords, of course, but even a simple boolean function which
takes two arguments, a reference type and the variable to check, would do.

something like:

if (isType(<0,0,0,0,0>, arg))
  // full colour.
elseif (isType(<0,0,0,0>, arg))
  // rgbf or rgbt
....

with keywords would be neater, of course:

if (isType(v5type, arg))
  // full colour.
elseif (isType(v4type, arg))
  // rgbf or rgbt
....

(I'm not a language designer, as you can tell :-))


regards, jr.

[William F Pokorny] Re: Suggest v4.0 upgrade the polygon object. (yu... [481 days 19 hours and 25 minutes ago]

Sat, 14 Dec 2024 01:09:10 GMT

On 12/13/24 10:08, Bald Eagle wrote:
> So that's an inbuilt function that outlines the bounding box of the isosurface?

It's the bounding box of the polygon object. They are similar in the end.

...
#declare PgonCW = polygon { // Normal set to -z
     10,
     <-1.0, -1.0>, <-1.0, +1.0>, <+1.0, +1.0>, <+1.0, -1.0>,
     <-1.0, -1.0>,
     <-0.6, -0.6>, <-0.6, +0.6>, <+0.6, +0.6>, <+0.6, -0.6>,
     <-0.6, -0.6>,
     bounded_by { box { <-1.5,-1.5,-0.5>, <+1.5,+1.5,+0.5> } }
}
...
#declare Offset = 0.04;
#declare Fn00 = function {
     pattern {
         potential {
             PgonCW
             ip_type 6
             ip_offset Offset
             ip_mode 0
         }
         raw_wave
     }
}
#declare Iso00 = isosurface {
     function { Fn00(x,y,z) }
     contained_by {
         box {
             min_extent(PgonCW)-10*Offset,
             max_extent(PgonCW)+10*Offset
         }
     }
     threshold 0
     accuracy 0.0005
     max_gradient 1.1
     pigment { Gold }
}
...

> Is there one for the bounding sphere {} as well?

The bounding in play here is the base bounding box used for the method 
1 & 2 overall object bounding. (Internally the last level of bounding is 
sometimes a sphere...)

Aside: One of the reasons to implement the bounding box potential 
patterns was to create an easier way to view what is happening with the 
global bounding. I have ideas for better performance - especially with 
method 2 which is under-exploited for the kinds of shapes and base 
bounding we typically have (why I believe it mostly doesn't help much). 
Anyhow...

You can get a sort of bounding sphere based upon the bound box 
coordinates - which always exist whether other last level bounding is a 
sphere (or skipped as with spheres).

...
#declare OffsetVec = (max_extent(PgonCW)-min_extent(PgonCW))/2.0;
#declare Offset    = vlength(OffsetVec);
#declare Fn99 = function {
     pattern {
         potential {
             PgonCW
             ip_type 2
             ip_offset  Offset
             ip_mode 0
         }
         raw_wave
     }
}
#declare Iso99 = isosurface {
     function { Fn99(x,y,z) }
     contained_by {
         box {
             min_extent(PgonCW)-2*Offset,
             max_extent(PgonCW)+2*Offset
         }
     }
     threshold 0
     accuracy 0.0005
     max_gradient 1.1
     pigment { White }
}
...

 > Do you think it would be too much trouble to add the middle lines
 > crossing through the center?

Could be done by change the 'dense' bbox potential form or as another 
ip_type I guess. Maybe as another light form with just those connections 
that folks can merge in if they wish... I'll think about it. There are 
trade offs.

 > I'm also envisioning another function that returns one of the points
 > on the ip_type 3 grid. Start by envisioning picking integer values for
 > a "uvw" vector <-1, 0, 1> of the bounding box and returning that?
 > <x,y,z> point.
 > I think it would be interesting to return points for any uvw value
 > passed into the function to get the corresponding x,y,z value in 3D
 > space.

Yeah, there are a lot of possibilities here and I'll add that one to the 
list banging around in my head.

Another idea on my list is using the polygon or polygon like interface 
for specifying coordinates which people can then transform and afterward 
query for a spatially updated point list.

I have some of these sorts of features in my TCL wrapper scripting - and 
being able to manipulate point lists in this way is useful.

Some years back I took a step toward that support with yuqk's new 
'pattern_modifiers' keyword for capturing and using complex spatial 
manipulations:

        #declare PigMods00 = pigment {
         color Black
         rotate 45*x
         scale <1.3,2.3,0.1>
         rotate -15*y
         scale 9
         warp { turbulence <0.1,0.1,0.1>
                octaves 5 omega 0.07 lambda 7.75 }
         scale 1/9
         rotate x*60 rotate z*35
         translate <0.1,0.1,-0.1>
         scale 1.4
     }
     #declare FnPigMods00 = function {
         pattern_modifiers { PigMods00 }
     }
     #declare Fn00 = function (x,y,z) {
         f_sphere(FnPigMods00(x,y,z).x,
                     FnPigMods00(x,y,z).y,
                     FnPigMods00(x,y,z).z,0.3)
     }

but some polygon-list like capability would be easier conceptually and 
as a tool easier to use I think. Ref:

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

This might be something I try as a kind of potential pattern extension 
near term, but ultimately some kind of dedicated support for point list 
manipulations in SDL would be better.

Bill P.

[William F Pokorny] Re: Suggest v4.0 upgrade the polygon object. (yu... [481 days 20 hours and 16 minutes ago]

Sat, 14 Dec 2024 00:17:38 GMT

On 12/13/24 10:48, Bald Eagle wrote:
> Out of curiosity about the crossing number / normal direction, and to give you
> another debugging test:
> 
> Have you tried making a pentagonal arrangement, with the connectivity
> every-other point, to produce a star?

I'd not done it with this new polygon / polygon-potential code. See the 
attached image - crossing star form on the right.

FWIW. The right form with f_path() previously:

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

Bill P.

[Bald Eagle] Re: Suggest v4.0 upgrade the polygon object. (yu... [482 days 4 hours and 44 minutes ago]

Fri, 13 Dec 2024 15:50:00 GMT

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

> The yellow-brown shape is the 'ip_type 6' potential value field of the
> polygon itself.

> The yellow lines the 'ip_type 5' connected point to point value field
> scaled slightly larger in z so the smaller ip_offset protrudes enough to
> just show up.

Out of curiosity about the crossing number / normal direction, and to give you
another debugging test:

Have you tried making a pentagonal arrangement, with the connectivity
every-other point, to produce a star?

[Bald Eagle] Re: Suggest v4.0 upgrade the polygon object. (yu... [482 days 5 hours and 24 minutes ago]

Fri, 13 Dec 2024 15:10:00 GMT

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

> The white frame is what the 'ip_type 3' bounding frame looks like. (I
> had a bug in this code I didn't see just looking at it as a pigment on a
> plane. Now fixed.)

So that's an inbuilt function that outlines the bounding box of the isosurface?
Is there one for the bounding sphere {} as well?

I'm wondering what the syntax, and arguments for that function are.
Do you think it would be too much trouble to add the middle lines crossing
through the center?

I'm also envisioning another function that returns one of the points on the
ip_type 3 grid.
Start by envisioning picking integer values for a "uvw" vector <-1, 0, 1> of the
bounding box and returning that <x,y,z> point.
I think it would be interesting to return points for any uvw value passed into
the function to get the corresponding x,y,z value in 3D space.

- BW

[William F Pokorny] Re: Suggest v4.0 upgrade the polygon object. (yu... [483 days 7 hours and 41 minutes ago]

Thu, 12 Dec 2024 12:52:39 GMT

On 12/11/24 09:49, Bald Eagle wrote:
> That's definitely pretty cool - more explanation on what that's about, and show
> the other two?

Attached an image of four isosurfaces occupying the same bounded space. 
Using one polygon object, but with four different potential pattern 
settings wrapped in four functions for the isosurfaces.

I used a 'bounded_by' to create an overly large bounding box and, on 
rendering, the flag -ur so it wasn't ignored.

The white frame is what the 'ip_type 3' bounding frame looks like. (I 
had a bug in this code I didn't see just looking at it as a pigment on a 
plane. Now fixed.)

The yellow-brown shape is the 'ip_type 6' potential value field of the 
polygon itself.

The blue-grey rods the 'ip_type 4' spheres for polygon points scaled big 
in z so as to clip on the isosurfaces bounding box.

The yellow lines the 'ip_type 5' connected point to point value field 
scaled slightly larger in z so the smaller ip_offset protrudes enough to 
just show up.

Bill P.

[William F Pokorny] Re: Suggest v4.0 upgrade the polygon object. (yu... [483 days 19 hours and 48 minutes ago]

Thu, 12 Dec 2024 00:45:51 GMT

On 12/11/24 09:49, Bald Eagle wrote:
> William F Pokorny <ano### [at] anonymousorg> wrote:
> 
> I'm not sure what this "offset" value is, but I'm wondering if there could be
> some sort of z-axis control that allows one to make things analogous to the
> prism's conic sweep.

Once we have a potential{} pattern in hand, we have access to all the 
usual value and spatial modifiers - plus functions based on the 
potential pattern (you can scale in z). How well it all works in 
practice, I'm not sure. The door to this functionality has just opened 
for me too.

> And for that matter, I'm wondering if the prism can be worked into this whole
> thing.

The thought occurred to me too :-). I don't know, maybe some potential 
support eventually there too. It would be hard to handle the prism as 
I'm handling the polygon's potential pattern.

In yuqk, shapes with a well defined inside (already 3D) can use the 
soft_object{} and hard_object{} patterns to turn things into some sort 
of value field pattern.

> 
>> The upper right two images show the 'ip_type 0' potential pattern
>> support which is a sort of infinite in z inside / outside test. The
>> inside values being (1.0*('ip_offset value')). By wrapping these
>> potential{} patterns in function{}s, this 'ip_type 0' is essentially a
>> drawn drawn polygon-tiles and calk method. A numerically noise proof,
>> and infinitely flexible alternative to the 'pavement' and 'tiling' value
>> patterns, for example.
> 
> Not sure what I'm seeing there - is there a rotational offset?

Yes. The upper right image adds a 'rotate z*45' to one of the two 50% 
grey images exactly overlapping for the white areas in the image just to 
the left.

> Could the rotational offset be defined as rotation per unit, to get a spiraling
> effect?

Yes. Any sort of normal spatial modifier is available.

> Maybe scratch whatever the "offset" currently is and incorporate a matrix
> transform for greater flexibility?

The offset (as positive values) is usually subtracted from the distance 
formulas being used internally (roughly specifying a radius or 
thickness), but it's sometimes used as a simple value multiplier too - 
as in the case of the 'ip_type 0'.

> 
> That's definitely pretty cool - more explanation on what that's about, and show
> the other two?

Currently there are two bounding box frameworks available (ip_type 3 is 
the one shown) and a center of bounding box distance. In other words, 
there are potential patterns for the polygon based upon the shapes 
bounding box rather than the shape itself. I'm unsure how useful this 
capability is...

> 
> I see that the center point of the outer polygon is included in that diagram -
> what if instead of drawing the even division of the AABB to give that "+", the
> center point was "connected" to the vertices with rays, with the potential
> varying in between the rays (to give an "X")
> (or a star, like the macro I used here:
> https://news.povray.org/web.54414d9ccbb3d8155e7df57c0%40news.povray.org)
> 

...

> One thing which could be cool, would be to re-order the connection points so
> that they now skip every other point.  With odd-number polygons, one would get a
> star.
> 
> Is there a way to easily achieve what is essentially a convex-hull effect -
> where none of the inner sub-polygon points "count"?
> Using the potential feature, one could then (potentially <--- Ha!) easily make
> isosurfaces...
> 

As to the rest of your suggestions, what I have in mind is to implement 
a new keyword called 'laxparse on|off' or 'lax_parsing on|off' for the 
polygon object which would free the polygon's parsing so we can specify 
sets of four connection values:

<2D vector of first pt> <2D vector second pt> <offset> <taper on 't'>

The code here has similarities to the previously implemented f_path() 
inbuilt function in yuqk. In f_path() one specifies a collection of 
points in space; followed by a limited number of 'connection 
specifications' between those points.

I don't think I've posted examples, but f_path() can change the base 
radius (offset to distance), the direction of every connection it makes 
- and taper the offset value up or down as each connection is made. 
This includes tapers which stop or start short; only pointing toward the 
closing or starting point. These f_path(), per connection, hooks are 
sitting in the polygon object's potential code - currently unused.

---

It might be a push in this direction leads eventually to a new 3D point 
set shape which would be a collection of 3D spheres by default, behind 
which would be potential{} pattern support allowing arbitrary point to 
point 'connections' in 3D rather than 2D.

The performance with the distance based methods degrade as the number of 
total measures needed for the overall value field go up. Without max 
value clamping on each component measure the value field's gradient 
values get pretty choppy away from any resultant surface too. In short,
there is much I don't know about the practical use / limits here.

Bill P.

Aside: One of the things I noticed while playing with a polygon made up 
of a bunch of small triangle loops is that we can get voronoi like 
results due the distances to other than just points in space. Maybe this 
an obvious result I guess... :-)

[Bald Eagle] Re: Suggest v4.0 upgrade the polygon object. (yu... [484 days 5 hours and 44 minutes ago]

Wed, 11 Dec 2024 14:50:00 GMT

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

Polygon as a df3 compression method.
Nice idea.

I'm not sure what this "offset" value is, but I'm wondering if there could be
some sort of z-axis control that allows one to make things analogous to the
prism's conic sweep.
And for that matter, I'm wondering if the prism can be worked into this whole
thing.

https://news.povray.org/povray.general/thread/%3Cweb.5d75c2d16af53e9cecc0fada0%40news.povray.org%3E/?mtop=431108

illustration:

https://news.povray.org/povray.binaries.images/thread/%3Cweb.5e97c744fd34edcfb0b41570%40news.povray.org%3E/?ttop=441730
&toff=400

> The upper right two images show the 'ip_type 0' potential pattern
> support which is a sort of infinite in z inside / outside test. The
> inside values being (1.0*('ip_offset value')). By wrapping these
> potential{} patterns in function{}s, this 'ip_type 0' is essentially a
> drawn drawn polygon-tiles and calk method. A numerically noise proof,
> and infinitely flexible alternative to the 'pavement' and 'tiling' value
> patterns, for example.

Not sure what I'm seeing there - is there a rotational offset?
Could the rotational offset be defined as rotation per unit, to get a spiraling
effect?
Maybe scratch whatever the "offset" currently is and incorporate a matrix
transform for greater flexibility?

> The bottom row of images show some of the kinds of potential patterns
> returned. The left most bottom being one of three possible
> bounding-box-based potential patterns.

That's definitely pretty cool - more explanation on what that's about, and show
the other two?

I see that the center point of the outer polygon is included in that diagram -
what if instead of drawing the even division of the AABB to give that "+", the
center point was "connected" to the vertices with rays, with the potential
varying in between the rays (to give an "X")
(or a star, like the macro I used here:
https://news.povray.org/web.54414d9ccbb3d8155e7df57c0%40news.povray.org)

> The remaining three images in the bottom row return polygon point
> values, connections between polygon points values and, on the very
> right, a stand-in 3D potential somewhat similar to the inbuilt
> f_rounded_box() function's value field - but defined by the polygon
> object's 2D shape.

One thing which could be cool, would be to re-order the connection points so
that they now skip every other point.  With odd-number polygons, one would get a
star.

Is there a way to easily achieve what is essentially a convex-hull effect -
where none of the inner sub-polygon points "count"?
Using the potential feature, one could then (potentially <--- Ha!) easily make
isosurfaces...

- BW

[William F Pokorny] Suggest v4.0 upgrade the polygon object. (yuqk R... [484 days 14 hours and 57 minutes ago]

Wed, 11 Dec 2024 05:37:12 GMT

In part due a bug report, and in part due an offline discussion with jr 
regarding an effort more than 15 years ago to implement a df3 file 
encoding format based upon 2d polygons in each z plane as a compression 
technique - I've been working on the polygon object's code.

The result is updated code which fixes a number of bugs and, of more 
interest to me, implements potential{} value pattern support(*) for the 
polygon object.

(*) The potential{} pattern is new to v3.8 and the initial 
implementation supports the blob{} and isosurface{} objects which 
naturally have a value fields defining the resulting shape.

The potential{} pattern support for the polygon object is based upon an 
expanded concept for what potential pattern support for an object means 
in general. It can be about more than reproducing the original shape as 
an isosurface or pattern.

Attached is an image with some examples and my initial pass at some 
documentation for yuqk's polygon object.

The upper left two images are the same as one gets with official POV-Ray 
releases. The green specifies the points in clockwise order. The red in 
counter-clockwise order.

The upper right two images show the 'ip_type 0' potential pattern 
support which is a sort of infinite in z inside / outside test. The 
inside values being (1.0*('ip_offset value')). By wrapping these 
potential{} patterns in function{}s, this 'ip_type 0' is essentially a 
drawn drawn polygon-tiles and calk method. A numerically noise proof, 
and infinitely flexible alternative to the 'pavement' and 'tiling' value 
patterns, for example.

The bottom row of images show some of the kinds of potential patterns 
returned. The left most bottom being one of three possible 
bounding-box-based potential patterns.

The remaining three images in the bottom row return polygon point 
values, connections between polygon points values and, on the very 
right, a stand-in 3D potential somewhat similar to the inbuilt 
f_rounded_box() function's value field - but defined by the polygon 
object's 2D shape.

Bill P.

[William F Pokorny] Re: Suggest v4.0 drop global noise_generator. (y... [495 days 8 hours and 20 minutes ago]

Sat, 30 Nov 2024 12:14:03 GMT

On 11/30/24 06:20, William F Pokorny wrote:
> Still refining it, but an updated version of the ip_noise_generator 
> documentation is attached.

I read it again after posting. One of the points I'm still not making 
well in the "background noise" section is that with f_hash() you can 
roll your own uniform random noise code in SDL.

The following code was used to generate the attached image 
(file_gamma=1.0). No AA used on the left image. Heavy method 3 AA used 
in the middle. No AA, but changing the Step value from 0.0 to 0.02 on 
the right.

#include "functions.inc"
#declare Seed00 = 7834.5540283051168443;
#declare Step = 0.00; // 0.02 for right image
#declare Fn00 = function {
     f_hash(
         (
         f_hash(x+pi, Seed00  ,Step,0)+
         f_hash(y+tau,Seed00*2,Step,0)+
         f_hash(z+e,  Seed00*4,Step,0)
         ),
     Seed00,Step,0)
}
#declare Pigm00 = pigment {
     function { Fn00(x,y,z) }
}

Bill P.

[William F Pokorny] Re: Suggest v4.0 drop global noise_generator. (y... [495 days 9 hours and 13 minutes ago]

Sat, 30 Nov 2024 11:20:48 GMT

On 11/29/24 21:08, William F Pokorny wrote:
> Due the noise_generator changes in yuqk, I've been working on 
> documentation which I think will help. See the attached text file.

Still refining it, but an updated version of the ip_noise_generator 
documentation is attached.

Bill P.

[William F Pokorny] Re: Suggest v4.0 drop global noise_generator. (y... [495 days 18 hours and 26 minutes ago]

Sat, 30 Nov 2024 02:08:09 GMT

On 11/29/24 09:18, Bald Eagle wrote:
> I had something bouncing around in the back of my head this morning, and since
> this thread concerns the PRNG, I'll drop this here.
> 
> If you look at my issue here:
> https://news.povray.org/web.650c19af5bb87ec31f9dae3025979125%40news.povray.org
> 
> this exposed what I believe to be a long-standing non-uniformity in the returned
> values from POV-Ray's built-in PRNG.
> 
> Have we taken a deep look at the values that the PRNG returns?
> 
> I was examining this from a color_map point of view way back, and I think it
> would be good to have something uniform/linear unless otherwise specified.
> 
> - BW
> 

Due the noise_generator changes in yuqk, I've been working on 
documentation which I think will help. See the attached text file.

I believe the noise you were trying to use is a smoothed noise which in 
addition to not being locally random at all, roughly follows a normal / 
Gaussian centered distribution over all values returned.

The yuqk fork has implemented a few different methods for uniform random 
noise in a range beyond what we can do with seed() and random() at parse 
time.

Bill P.

[Bald Eagle] Re: Suggest v4.0 drop global noise_generator. (y... [496 days 6 hours and 14 minutes ago]

Fri, 29 Nov 2024 14:20:00 GMT

I had something bouncing around in the back of my head this morning, and since
this thread concerns the PRNG, I'll drop this here.

If you look at my issue here:
https://news.povray.org/web.650c19af5bb87ec31f9dae3025979125%40news.povray.org

this exposed what I believe to be a long-standing non-uniformity in the returned
values from POV-Ray's built-in PRNG.

Have we taken a deep look at the values that the PRNG returns?

I was examining this from a color_map point of view way back, and I think it
would be good to have something uniform/linear unless otherwise specified.

- BW

[William F Pokorny] Suggest v4.0 better handle value modifiers in no... [498 days 8 hours and 3 minutes ago]

Wed, 27 Nov 2024 12:31:34 GMT

In posting some slope_map{} images over in the pbi forum:

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

I had the thought I've not mentioned an older change in the yuqk fork 
which makes general wave modifiers, like sine_wave, illegal in the 
normal{} block context.

normal {
   wood
   sine_wave  // The yuqk parser flags this as illegal!
}

The reasons are the results are unstable in current official releases of 
POV-Ray. Some examples:

---

normal {
   bumps          // normal perturbation is used over bumps value pattern
   triangle_wave  // So, this does nothing at all. No parse errors
}

---

normal {
   facets       // There is only a normal perturbation
   frequency 2  // This does nothing at all. No parse errors
}

-- 

normal {
   wood
   sine_wave  // sine_wave replaces wood's triangle_wave default
}

normal {
   pigment_pattern {
     wood
     color_map {  // This the default map for all value patterns in yuqk
       [0 rgb 0]  // Official POV-Ray need
       [1 rgb 1]
     }
   }
   // sine_wave below is chained after the wood's default triangle_wave
   sine_wave
}

---

The yuqk fork in making the normal context illegal for the general value 
pattern modifiers, forces the creation of pigment_pattern{} or 
function{pattern {}} wrap contexts where the behavior is stable.

Aside: A pattern{} usable within normal{}, pigment{}, etc blocks with 
direct access to the pattern's value in additional to the 
pigment_pattern{} would be good to have too. The next release of the 
yuqk fork changes pavement's 'pattern' keyword to 'ip_pattern' removing 
one obstacle to a more general pattern{} capability. Maybe I'm dreaming 
and pattern{} functionality cannot be extended for other reasons - I've 
not gotten to actually trying to do it...

Bill P.

[William F Pokorny] Suggest v4.0 fix wrinkles small value bias issue... [508 days 23 hours and 46 minutes ago]

Sat, 16 Nov 2024 20:47:54 GMT

When x,y or z nears 0.0, the scalar value wrinkles pattern works less 
well (shows artefacts). The effect differs somewhat between the three 
noise generators

To better make the issue visible I made two renders where I compiled in 
a slightly different internal lambda factor. Such a change should result 
in evenly distributed differences in a rendered wrinkles result.

All renders shown using the default noise generator (2).

The upper row of the attached image shows the issue. Near the origin 
there is little to no effective change in coordinate values and so 
little or no change in the result from Noise() as we walk through the 
(1/f) steps.

In the middle row I simply add 'translate +2222' to get the internal 
coordinate away from small x,y or z values - and all good.

In the bottom row is the change made in yuqk. A constant asymmetric 
translate is done internally to the three different values with a 
magnitude of 1e7 (this the +- numerical magnitude limit for POV-Ray). 
Yes, with the right, counter, spatial transforms a user could bring the 
'shifted origin' back into play, but it is very unlikely to happen in 
practice.

Bill P.

Aside: The normal{} block's wrinkle perturbation is still disabled in 
yuqk. The long standing perturbation moves relative to any surface on 
changes to the bump_size. In trying for alternatives, I've come up with 
other perturbations like 'concrete', but nothing acceptably wrinkles 
like. Using the value pattern above is still the best replacement.

[Bald Eagle] Re: Suggest v4.0 keep enhanced marble pattern. (... [509 days 6 hours and 44 minutes ago]

Sat, 16 Nov 2024 13:50:00 GMT

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

> SSLT - maybe I'll give it a go. My todo list always grows longer when I
> interact with you... :-)

:D   My to do list gets longer when I finally get some time to myself and I can
think about all the things that I have to or want to do.

I think that implementing a more collaborative approach to scenes might help
people like us (too busy + too many ideas) make progress and complete more
scenes / experiments.  The old coding circles and code pong type stuff.

"Here's my basic / incomplete scene, here's what I want to do, here's what I
have, and this is what still needs coding / developing / fixing."

A scene can be made very modular using include files, #switch/case blocks,
macros, etc.
Unimplemented parts of the scene can just have placeholders that can be edited
as the scene develops.
It's easy enough to paste links to POV-Rayfeatures, images on the web, code that
needs to get translated to SDL, etc. into the scene as comments.

Then anyone at any time can pick it up and run with it, and then post how far
they've gotten.

Because we all know that sometime the difference between complete poop and a
great looking working scene can be editing a single line of code, changing a
single value, or just implementing one feature that makes it WORK.

> SSLT is one of those features still on yuqk's 'not sure what to do with
> it' list. There are issues. Not the least of which is the feature was
> never really polished off in the code. On other than simple geometries
> I've found it a little funky to use - this could be me not understanding
> it well. It's slow on my little i3, so it's hard for me to experiment.

Yes, as I recall, it was complicated to merely implement in a scene as well.
TdG managed to get it to work fairly well in the granite texture - maybe you can
just steal a block of code from there and see what you can get to work.

Or post your crackle-wood code, with specific ideas to convert it to geometry,
and someone can work that out and apply the SSLT if they have the time and
nothing specific of their own to work on.

- BW

[William F Pokorny] Suggest v4.0 enable enhanced onion pattern. (yuq... [509 days 17 hours and 50 minutes ago]

Sat, 16 Nov 2024 02:43:47 GMT

Adding 'ip_form', 'ip_offset' and 'ip_raw_return' as options for the for 
the scalar value 'onion' pattern. When no options are used the behavior 
is unchanged.

The heart of the onion pattern is a distance from origin / center 
function wrapped in an fmod(value,1) call. The fmod() call itself 
creates a slight inconsistency due the general value modifier code using 
a version too. One which has historically and, though revised in yuqk, 
still skirts to 1+'numerical epsilon' in the fmod() call so '1' doesn't 
disappear from the 0 to 1 value range returned.

Enabling 'ip_raw_return on' suppresses the internal fmod() call making 
behavior more consistent with other patterns near the 1.0 multiples, 
snapping back to 0.0 values - 99.99% of the time it will look the same.

The three internal pattern (ip_) functions together allow the internal 
distance function to be used more generally and flexibly should folks 
want to do it.

See attached images. The upper left being the traditional onion 
translated +1 in z applied to a plane.

Bill P.

[William F Pokorny] Re: Suggest v4.0 keep enhanced marble pattern. (... [509 days 17 hours and 56 minutes ago]

Sat, 16 Nov 2024 02:38:09 GMT

On 11/15/24 10:40, Bald Eagle wrote:
> I'll bet this would also look great if rendered with SSLT.
> You'd probably have to use actual displacement mapping - maybe with a
> heightfield or isosurface to get the variations in geometry and thickness.

SSLT - maybe I'll give it a go. My todo list always grows longer when I 
interact with you... :-)

SSLT is one of those features still on yuqk's 'not sure what to do with 
it' list. There are issues. Not the least of which is the feature was 
never really polished off in the code. On other than simple geometries 
I've found it a little funky to use - this could be me not understanding 
it well. It's slow on my little i3, so it's hard for me to experiment.

The yuqk fork's solver fixes / improvements help its behavior quite a 
bit. I was able to pull out some hacks specifically for the feature in 
the blob code, for example.

I don't know... Down my list a ways. It's relatively complicated code. 
Uses too a boost feature I've not seen elsewhere. Anyhow...

Bill P.

[Bald Eagle] Re: Suggest v4.0 keep enhanced marble pattern. (... [510 days 4 hours and 49 minutes ago]

Fri, 15 Nov 2024 15:45:00 GMT

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

> A few weeks ago I played with the idea of using crackle as base for a
> wood texture. It was just a quick test, but see the attached image.
> Aimed for pine, but ended up with something more like tulip poplar I
> think. :-) The code used is simple and I believe it would work with the
> crackle in official releases of POV-Ray too.

Now that _is_ interesting!
When I have the opportunity and energy, I ought to try incorporating that into
Marschner's wood texture and see if that improves things.

I'll bet this would also look great if rendered with SSLT.
You'd probably have to use actual displacement mapping - maybe with a
heightfield or isosurface to get the variations in geometry and thickness.

> I believe POV-Ray has long been self-hindered with respect to developing
> good libraries of textures. Too many features on which textures /
> materials are based behave in unstable ways. Much of my effort with the
> yuqk fork has been to tune up the old core of code; To make existing
> features more stable and more flexible (You've helped - 'quilted' and
> 'radial', for example). I'm still on that tune up bit...

Well, we have a lot of basic patterns that serve as the basis of actual textures
- given the proper inclusion and setting of a wide variety of (incompletely
understood) switches and knobs.

I think that the approach that Thomas took - generating a proper, fully-formed
texture with a macro is a very promising approach.

Certainly a lot of often-encountered inefficiencies and errors could be avoided
if we had some macros to handle sanity checking and the proper implementation of
feature settings for all those fun things like radiosity, floating point math,
etc.

- BW

[William F Pokorny] Re: Suggest v4.0 keep enhanced marble pattern. (... [510 days 22 hours and 47 minutes ago]

Thu, 14 Nov 2024 21:47:03 GMT

On 11/14/24 09:33, Bald Eagle wrote:
> FYI:
> I noticed in the comments for the crackle source:

The comments in the code ahead of the crackle code itself come from the 
original authors. I found them interesting - and like you, I wondered if 
some were still true.

A few weeks ago I played with the idea of using crackle as base for a 
wood texture. It was just a quick test, but see the attached image. 
Aimed for pine, but ended up with something more like tulip poplar I 
think. :-) The code used is simple and I believe it would work with the 
crackle in official releases of POV-Ray too.

     plane { -z 0
         pigment {
             crackle
             ip_solid
             color_map {
                 [0.0 AppleBlossom ]
                 [0.2 AppleGreen  ]
                 [0.4 AppleGreen1 ]
                 [0.6 AppleGreen2 ]
                 [0.8 AppleGreen3 ]
                 [0.9 AppleGreen4 ]
                 [0.90 rgb 0 ]
                 [1.00 rgb 0 ]
             }
             scale <1,1/12666.6667,1>
             rotate z*33.333
         }
         finish { emission 1 }
     }

> Just #include "v40textures.inc" or something . . .

I agree with your aim.

I believe POV-Ray has long been self-hindered with respect to developing 
good libraries of textures. Too many features on which textures / 
materials are based behave in unstable ways. Much of my effort with the 
yuqk fork has been to tune up the old core of code; To make existing 
features more stable and more flexible (You've helped - 'quilted' and 
'radial', for example). I'm still on that tune up bit...

Bill P.

[Bald Eagle] Re: Suggest v4.0 keep enhanced marble pattern. (... [511 days 5 hours and 59 minutes ago]

Thu, 14 Nov 2024 14:35:00 GMT

William F Pokorny <ano### [at] anonymousorg> wrote:
> I debated for a long while on whether to keep the marble pattern in yuqk
> given the base pattern is just 'gradient x' with a 'triangle_wave' value
> modifier.

FYI:
I noticed in the comments for the crackle source:
"// Highly turbulent (with moderate displacement) makes a good marble, solving
// the problem of apparent parallel layers in Perlin's method. (The perlin
// method being the noise generator used with POV-Ray's 'turbulence'
// implementations)"

I don't know if anyone's tried this out yet and compared it to our current
"marble".

tl;dr

It would be great if people could pick a simple pattern/texture and really flesh
it out like TdG with the granite pattern, and I made some headway on with
Marschner's wood texture.

Yes, the danger is that those would be the default and become "overused", but at
the same time, people wouldn't have to be left to ascend the learning curve and
code 397 lines of fundamental computer graphics to get something that looks
better than the usual newbie/lazy 5 lines of "marble".
Just #include "v40textures.inc" or something . . .

- BW

[William F Pokorny] Suggest v4.0 keep enhanced marble pattern. (yuqk... [511 days 6 hours and 53 minutes ago]

Thu, 14 Nov 2024 13:40:52 GMT

I debated for a long while on whether to keep the marble pattern in yuqk 
given the base pattern is just 'gradient x' with a 'triangle_wave' value 
modifier.

For the record I suppose. I decided, given the new to yuqk internal 
turbulence (_it) keyword support, it was worthwhile to keep around. Many 
of us use marble too in old scenes as quick texturing.

In the attached image the basic pattern in the upper left.

In the upper right adding 'it_frequency 1/3'

In the lower left adding 'it_frequency 1/3' and 'it_scale 3'

In the lower right adding 'it_frequency 1/3' and 'it_scale 1/3'

---

Note! I missed adding the it_scale support to 'marble', 'spiral1' and 
'spiral2' when the general scaling capability was added to the internal 
Turbulence() code. The 'it_scale' above is a parse error with marble 
until the next yuqk release (R17).

Reminder. The patterns 'agate', 'marble','spiral1', 'spiral2' and 'wood' 
are touched by the (noise centering drift on omega values) issue fixed 
now a long while ago in the yuqk fork.

Bill P.

[William F Pokorny] Suggest v4.0 updates to leopard pattern. (yuqk R... [511 days 21 hours and 26 minutes ago]

Wed, 13 Nov 2024 23:08:16 GMT

In a manner similar to recent changes to the brick pattern, the leopard 
pattern was re-written in yuqk to support an 'ip_form' keyword for more 
control over how the pattern is generated.

Where one or two vector components are zero, the return values are more 
reliably in the 0 to 1 range (The pattern still squares internally so 
the value change is not linear).

The pattern's behavior is identical if the ip_form vector is left at the 
default of <1,1,1>.

In the attached image using the leopard pattern on a squished sphere 
(Go, go-ishi like shape).

Upper left uses the traditional pattern - which takes on different looks 
depending upon where in the pattern the surface exists.

Upper right uses 'ip_form <1,1,0>'.

Lower left uses 'ip_form <1,4,0>'.

Lower right uses 'ip_form <pi,0,tau>'.

Bill P.

[William F Pokorny] Suggest v4.0 use rgbft floats for color image cr... [513 days 12 hours and 43 minutes ago]

Tue, 12 Nov 2024 07:51:09 GMT

In early 2023 I posted on creating internal greyscale image_maps from a 
function. See:

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

Well... It's also possible to create color image_maps this way. However, 
the long standing set up in official releases of POV-Ray was to store 
the results in a 16 bit, positive value only, internal image format. In 
the next release of the yuqk fork (R17) the internal format for color 
images is now rgbft, 32 bit floats.

As a way to look at how the available image_map interpolations work at 
the pixel level in the attached image, I used the following code for the 
pigment:

#declare P00 = pigment {
     image_map {
         function 20 20 {
         pigment {
             user_defined {
                 function { f_popnrm_rnoise(x,y,z,e  *1e5,1) },
                 function { f_popnrm_rnoise(x,y,z,pi *1e5,1) },
                 function { f_popnrm_rnoise(x,y,z,tau*1e5,1) },
                 function { 0 },
                 function { 0 }
             }
         }
         once
       //interpolate 0  // No interpolation.    Upper left
       //interpolate 2  // Bi-Linear.           Upper right
       //interpolate 3  // Bi-Cubic.            Lower left
         interpolate 4  // Normalized distance. Lower right
     }
     translate <-0.5,-0.5,0>
     scale <e,e,1>
}

Note. We are storing negative channel values in the image_map. This more 
or less where the stored image goes black due clipping to 0.0 channel 
values on output (to most formats).

If instead of f_popnrm_rnoise() for the color channels, we use functions 
based on an incoming image, we can do image processing / 
post-processing. For example, a quick blur can be had with just:

...
         function IMAGE_WIDTH/2 IMAGE_HEIGHT/2 ...
...
         interpolate 3
...

Bill P.

[William F Pokorny] Re: Suggest v4.0 drop global noise_generator. (y... [516 days 9 hours and 41 minutes ago]

Sat, 9 Nov 2024 10:52:39 GMT

On 11/8/24 19:45, Cousin Ricky wrote:
>> Created a new 'ip_noise_generator' keyword for the patterns /
>> perturbations: agate, bozo, bumps, dents, granite, marble, noise_cubed,
>> spiral1, spiral2 and wrinkles. Made changes so the two remaining uses of
>> 'noise_generator' now set values local to 'fog{}' and 'irid{}'. The
>> patterns and features mentioned here are the only ones ever affected by
>> 'noise_generator' settings, global and not

> Sounds reasonable.  I presume there will be a default 'ip_noise_generator'
> value, and a warning for pre-4.0 scenes that use the global_settings()?

The 'ip_noise_generator' internal pattern settings are defaulted in yuqk 
- the effective noise generator defaulting(2) is unchanged from v3.8 
beta 2. The pre-yuqk (4.0 playpen) scenes see an error on invalid use of 
'noise_generator' in global_settings{}.

I believe a v4.0 release of POV-Ray should be something new. The yuqk 
fork - as my playpen for v4.0 changes / ideas - is breaking away from 
official POV-Ray v3.8 over time.

Aside: The maintenance of v3.8 and/or v3.7 versions can be continued 
indefinitely - if there is someone to do what would be tedious work over 
time, keeping those versions compiling as environmental stuff changes.

We can maintain the bridge to our old scenes with an officially 
maintained pre-v4.0 version - without crippling v4.0 development with 
the need to stay backward compatible with the old scenes.

Bill P.

[Cousin Ricky] Re: Suggest v4.0 drop global noise_generator. (y... [516 days 19 hours and 44 minutes ago]

Sat, 9 Nov 2024 00:50:00 GMT

William F Pokorny <ano### [at] anonymousorg> wrote:
> The yuqk fork does this and more in the next release.
>
> The global_settings{} noise_generator option was removed. It was never
> truly global! The old set up added overhead for all patterns. It left a
> situation where sharing SDL was exposed to differences in behavior, any
> time the user sharing did not lock all the noise generator use. It
> limited flexibility with options like fog{} and irid{}.
>
> Created a new 'ip_noise_generator' keyword for the patterns /
> perturbations: agate, bozo, bumps, dents, granite, marble, noise_cubed,
> spiral1, spiral2 and wrinkles. Made changes so the two remaining uses of
> 'noise_generator' now set values local to 'fog{}' and 'irid{}'. The
> patterns and features mentioned here are the only ones ever affected by
> 'noise_generator' settings, global and not

Sounds reasonable.  I presume there will be a default 'ip_noise_generator'
value, and a warning for pre-4.0 scenes that use the global_settings()?

[William F Pokorny] Suggest v4.0 drop global noise_generator. (yuqk ... [517 days 6 hours and 1 minute ago]

Fri, 8 Nov 2024 14:33:26 GMT

The yuqk fork does this and more in the next release.

The global_settings{} noise_generator option was removed. It was never 
truly global! The old set up added overhead for all patterns. It left a 
situation where sharing SDL was exposed to differences in behavior, any 
time the user sharing did not lock all the noise generator use. It 
limited flexibility with options like fog{} and irid{}.

Created a new 'ip_noise_generator' keyword for the patterns / 
perturbations: agate, bozo, bumps, dents, granite, marble, noise_cubed, 
spiral1, spiral2 and wrinkles. Made changes so the two remaining uses of 
'noise_generator' now set values local to 'fog{}' and 'irid{}'. The 
patterns and features mentioned here are the only ones ever affected by 
'noise_generator' settings, global and not

The attached image is a bit contrived, but does show the updated 
capability with fog{} and irid{}.

In the top row changing the irid{} noise generators with 
'noise_generator' keyword. Left to right, 1, 2 and 3.

In the bottom row playing with fog{}'s new 'noise_generator' setting as 
follows left to right. Maybe a Holiday fog on the right...

// Left
//fog { Fog01_wTurb color <0.9,0.9,0.9>}

// Middle
//fog { Fog01_wTurb color <0.9,0.0,0.0> noise_generator 2}
//fog { Fog01_wTurb color <0.0,0.9,0.0> noise_generator 2}
//fog { Fog01_wTurb color <0.0,0.0,0.9> noise_generator 2}

// Right
fog { Fog01_wTurb color <0.9,0.0,0.0> noise_generator 3}
fog { Fog01_wTurb color <0.0,0.9,0.0> noise_generator 2}
fog { Fog01_wTurb color <0.0,0.0,0.9> noise_generator 3}

Bill P.

[William F Pokorny] Re: Suggest v4.0 inbuilt f_popnrm_rnoise(). (yuq... [523 days and 19 minutes ago]

Sat, 2 Nov 2024 20:14:59 GMT

On 11/1/24 15:11, William F Pokorny wrote:
> No real shape - just enough +-noise that the isosurface root finder 
> finds plenty of roots.

Playing now and again with this idea. I wondered how the roots / 
surfaces bits from the 'random noise filling' would affect normals and 
finish. They still work in a noisy way. Interesting effects in any case.

Just a quilted normal used in the attached images. On my i3 the top 
image took about 20 seconds elapsed the bottom roughly 30 with mid to 
light AA and simple radiosity.

Bill P.

[William F Pokorny] Re: Suggest v4.0 inbuilt f_popnrm_rnoise(). (yuq... [524 days 1 hour and 23 minutes ago]

Fri, 1 Nov 2024 19:11:12 GMT

On 11/1/24 08:40, William F Pokorny wrote:
> Mind running - what if we stick this noise only inside more usual shape 
> functions or inbuilt shapes as part of a function. I bet they'd all show 
> up...

Attached an image where I filled text object characters with noise as a 
function for an isosurface. Here not that fast because the inside test 
for a single text string like "Halloween" is slow.

#declare Fn01 = function {
     pattern {
         bool_object {  // In POV-Ray proper this called 'object'
             text {     // yuqk has also list_object etc.
                 ttf "timrom.ttf" "Halloween"
                 0.15, 0.001
                 translate <-2.0,0,0>
             }
         }
     }
}
#declare Fn02 = function (x,y,z) {
     (Fn01(x*3,y*3,z*3) > 0.0)*f_popnrm_rnoise(x,y,z,now,1)
}

No real shape - just enough +-noise that the isosurface root finder 
finds plenty of roots.

Bill P.

[William F Pokorny] Suggest v4.0 inbuilt f_popnrm_rnoise(). (yuqk R1... [524 days 7 hours and 53 minutes ago]

Fri, 1 Nov 2024 12:40:58 GMT

About a year ago I was playing some with an idea for a facets normal 
perturbation.

Ref:

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

As part of that work I mentioned using the population count opcode in 
most modern processors as part of a creating a normal-ish / 
sloppy-Gaussian distribution of not more than 64 values.

I had the thought at the time, we could probably extend the technique to 
random noise generation too.

Release (R16) of yuqk is adding a new inbuilt function called 
f_popnrm_rnoise(). Attached is an image of the +-1 noise created (no AA) 
and a histogram of the value distribution.

pigment {
     function { f_popnrm_rnoise(x,y,z,now,1) }
     function_interval
     color_map {
         [-1.0 rgb 0]
         [+1.0 rgb 1]
     }
}

The steps of the technique are certainly visible, but for a really fast, 
normal-ish, random, noise distribution - I think it will often be useful.

Bill P.

Hmmm, I wonder what happens if I use this directly as an isosurface 
function... To a first order, renders a noisy shape constrained by the 
container. Relatively quick, but HUGE max gradients need be ignored. :-) 
Mind running - what if we stick this noise only inside more usual shape 
functions or inbuilt shapes as part of a function. I bet they'd all show 
up... Anyhow. More play to be had I guess.

[Bald Eagle] Re: 3D warp repeat for primitives [600 days 18 hours and 49 minutes ago]

Sat, 17 Aug 2024 01:45:00 GMT

And to follow up a little further on that,

See:
http://news.povray.org/povray.binaries.images/thread/%3Cweb.5d3c5fe27be432e04eec112d0%40news.povray.org%3E/?ttop=443897
&toff=600

All of those rocks are a single isosurface.

I can pattern them uniquely, as I have, but having a ray intersection that
triggers - not the usual texture evaluation - but a blindingly faster stored
value from a "lookup table" derived from a single evaluation of the basis unit
cell - I think would make a scene with a complex texture render MUCH faster.

Mod () is just a "portal" to the cell defined by the magnitude of the divisor.
A grid of TV screens all showing the same image.  Cahnge the image, change ALL
the cells.
You don't have a lot of images where you have to change all of them
individually.
https://en.wikipedia.org/wiki/Modulo

Just think about making your faked pattern with real objects.
Let's say its a Lego.
You place all the Legos next to each other - but you already know what the next
spot is going to look like even before it gets filled in, because they're all
identical to the first Lego.  The Nth Lego is just an identical copy of the
first one.
And the unit cell is defined by the dimensions of the Lego - that's your unit.

But you can still make them all "look different" - even though the underlying
pigment is the same - by lining them up so they go through a tunnel and out
again, and only lighting them from one side.

[Bald Eagle] Re: 3D warp repeat for primitives [600 days 19 hours and 14 minutes ago]

Sat, 17 Aug 2024 01:20:00 GMT

> SO...From your isosurface/spheres render-- as your analogue-- I have a much
> clearer idea of what you're after: a (quasi-)infinite built-in 'pattern' of 3-D
> objects via a warp/repeat or some such, using any(?) kind of pre-made object as
> the 'unit', not just a sphere.

YES.

> Then the underlying pattern mechanism can place
> the objects within a pre-defined(?) set of planes, appearing to go to infinity
> in at least 2 if not all 3 axes (but constrained by the planes.) And
> accomplished very quickly, because the basic pattern is built-in behind the
> scenes, rather than having to code the entire shebang in SDL. Correct so far?

Well - the objects are coded in SDL.
The repeating unit cell is defined by the "vector" or however the actual
implementation would be defined.   Maybe just an automatic bounding box of the
union.
(The set of planes is just sort of a way to bound the isosurface analogue - we
likely don't need it for the actual source implementation)
Then the way the pattern is repeated is handled by the warp specified by the
user.


> It's an intriguing idea...but I still wonder if *nearly* the same thing could be
> accomplished visually-- albeit in a much slower way-- by nested #for loops, to
> place the (*many!*) objects in such a grid-like arrangement, 'appearing' to go
> to infinity even though the loops have finite start and end locations.

Well yes - we can fake such things - but what if we're talking about an
isosurface or a parametric.  Or _anything_ that renders slowly.
The magic of mod () is that when you solve the equation for <x, y, z> once, you
have solved it for every mod (<x, y, z>, N) in all of 3D space.
Because everything is just a copy of that basis unit cell.
Obviously lighting and shadow and everything else needs to be calculated because
the absolute coordinates are different and there are differences in lighting and
proximity to other scene elements - but the geometry and texture is already
established at that point for every analogous point in every other unit cell.

> As has been mentioned, even POV-ray's typical built-in patterns-- when applied
> to a plane, for example-- lose their definition the farther the pattern is from
> the camera. So having the 3-D objects go all the way to 'infinity' (i.e.
> quasi-infinity) may not be necessary anyway; instead, only as far as what looks
> like infinity, before they lose their definition too. (I hope that makes sense.)

Yes, yes, we can fake many things - but that's not the point.

> And if the camera moves during an animation, it seems to me that the #for-loop
> construction could easily be adjusted to keep the many objects looking like they
> still go out to quasi-infinity (by changing the finite start and end locations
> in the loops.)

But that has to be babysat by the (new) user.
How would you like to have to explicitly define the extent of any pigment {}
statement that you used in a scene rather than just being able to rely on the
fact that that procedural pattern is inherent in the very 3D-space of the scene?

> But I agree that it would be nice to have such an 'infinite 3-D-object pattern'
> built-in, if only for the vast parse/render-speed increase.

It would be faster and require far less memory.

> BTW: If your code for your red-spheres-isosurface analogue scene is still
> intact, would you mind posting it here? I would like to see how and where you
> used your 'mod' code to get the repeating spheres in the isosurface. I haven't
> used such a trick before.

Of course.
Notice that that entire thing is a single isosurface.

You have Mike Williams' site that I converted to PDF - just search for "mod" and
it ought to be the first search result.

Also read his web page on holes to see an(other) excellent example of how
efficient and fast "baking" a feature into the equations is.


Notice that I have ONE shape - a sphere with a radius of 0.5, so that the
diameter is the width of a unit cell. Mod () takes care of the rest no matter
how large you set Ext to be, or where (in that narrow slice of space) you
position the contained_by box.
------------------------------------------------------------------------

#version 3.8;
global_settings {assumed_gamma 1.0 }

camera {
 location <0, 4, -40>
 right x*image_width/image_height
 up y
 look_at <0, 0, 0>
}

light_source {<0, 5, -50> rgb 1}

sky_sphere {pigment {rgb 1}}

#declare Ext = 100;
#declare Radius = 0.5;
#declare Sphere = function (X, Y, Z) {sqrt(X*X+Y*Y+Z*Z)-Radius}
isosurface {
   function {Sphere (mod(abs(x),1)-0.5, y, mod(abs(z),1)-0.5)}
   max_gradient 1

   accuracy     0.001
   contained_by {box {-<Ext, 0.6, Ext>, <Ext, 0.6, Ext>}}
     texture {pigment {rgb x} finish {specular 0.4}}
}

[Kenneth] Re: 3D warp repeat for primitives [600 days 23 hours and 19 minutes ago]

Fri, 16 Aug 2024 21:15:00 GMT

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

> When we have meshes, with multiple instantiations, we merely apply a
> transformation matrix to the reference mesh in order to do the calculations to
> find the new position of the copy.
>
> If we simply apply the same methods to ACTUAL TEXTURED OBJECTS, then we
> ought to be able to accomplish exactly the same thing.   When I texture an
> object, and THEN translate it, the texture "follows" it.  So i ought to be
> able to define a unit cell with a vector, and then simply use mod () to
> repeat that unit EVERYWHERE.
>
> The attached is an isosurface of a 100 x 100 grid using mod () which rendered
> in 7 seconds.  We KNOW primitives render much faster than isosurfaces, and
> so would be a feasible way to accomplish the same thing only using all of
> the native optimizing of CSG objects.

(Sorry for the long delay in responding. I finally got a little bit of free
time-- but then my internet connection went down completely for 3 days; no clue
as to why. There's a bad technical glitch somewhere...) Anyway...

SO...From your isosurface/spheres render-- as your analogue-- I have a much
clearer idea of what you're after: a (quasi-)infinite built-in 'pattern' of 3-D
objects via a warp/repeat or some such, using any(?) kind of pre-made object as
the 'unit', not just a sphere. Then the underlying pattern mechanism can place
the objects within a pre-defined(?) set of planes, appearing to go to infinity
in at least 2 if not all 3 axes (but constrained by the planes.) And
accomplished very quickly, because the basic pattern is built-in behind the
scenes, rather than having to code the entire shebang in SDL. Correct so far?

It's an intriguing idea...but I still wonder if *nearly* the same thing could be
accomplished visually-- albeit in a much slower way-- by nested #for loops, to
place the (*many!*) objects in such a grid-like arrangement, 'appearing' to go
to infinity even though the loops have finite start and end locations.

As has been mentioned, even POV-ray's typical built-in patterns-- when applied
to a plane, for example-- lose their definition the farther the pattern is from
the camera. So having the 3-D objects go all the way to 'infinity' (i.e.
quasi-infinity) may not be necessary anyway; instead, only as far as what looks
like infinity, before they lose their definition too. (I hope that makes sense.)

And if the camera moves during an animation, it seems to me that the #for-loop
construction could easily be adjusted to keep the many objects looking like they
still go out to quasi-infinity (by changing the finite start and end locations
in the loops.)

But I agree that it would be nice to have such an 'infinite 3-D-object pattern'
built-in, if only for the vast parse/render-speed increase.

BTW: If your code for your red-spheres-isosurface analogue scene is still
intact, would you mind posting it here? I would like to see how and where you
used your 'mod' code to get the repeating spheres in the isosurface. I haven't
used such a trick before.

[Thomas de Groot] Re: 3D warp repeat for primitives [606 days 13 hours and 20 minutes ago]

Sun, 11 Aug 2024 07:13:39 GMT

Op 10-8-2024 om 18:10 schreef Cousin Ricky:
> On 2024-08-10 03:56 (-4), Thomas de Groot wrote:
>>
>> meshmaker.inc can be found in the official POV-Ray/include folder.....
> 
> If you are using POV-Ray 3.7, please note that there is a bug in
> meshmaker.inc 3.7.  It is fixed in POV-Ray 3.8, and should work without
> modification if you copy it to your 3.7 include folder.
> 
Ah! Good to remind us of this, and thanks!

I use 3.8 most of the time, but I shall do as you say.

-- 
Thomas

[Cousin Ricky] Re: 3D warp repeat for primitives [607 days 4 hours and 24 minutes ago]

Sat, 10 Aug 2024 16:10:13 GMT

On 2024-08-10 03:56 (-4), Thomas de Groot wrote:
> 
> meshmaker.inc can be found in the official POV-Ray/include folder.....

If you are using POV-Ray 3.7, please note that there is a bug in
meshmaker.inc 3.7.  It is fixed in POV-Ray 3.8, and should work without
modification if you copy it to your 3.7 include folder.

[jr] Re: 3D warp repeat for primitives [607 days 11 hours and 34 minutes ago]

Sat, 10 Aug 2024 09:00:00 GMT

hi,

Thomas de Groot <tho### [at] degrootorg> wrote:
> ...
> My memory is not what it has been :(

know the feeling..

> meshmaker.inc can be found in the official POV-Ray/include folder.....

perhaps that is what I was thinking of, unsure now :-).

@Kenneth

fwiw, I had a look in "the collection" too, and got 2 and-a-half :-) "hits":

/meshrelief
The meshrelief include file comprises a set of macros that create meshes of
simple shapes, and displace the surfaces according to a predefined pigment.
These macros are intended for creating realistic, but relatively low-detail,
building blocks that can be copied many times to build structures, and render
many times faster than the equivalent isosurfaces.

/meshlathe
Lathes are often useful to easily create objects like wineglasses, pots, etc.
However, often they can be rather slow to render. This include file creates a
triangle mesh from a spline by rotating it around the y axis, similarly to how
the lathe object works. Several options and parameters to define the amount of
triangles and debugging features are supported, as demonstrated in the example
pov file and the image (rendered from it).

/scroll  (Scroll_array2mesh2.inc)
Include file for the Scroll_Mesh2FromArray macro takes an array of Positions and
generates a mesh2 object.

if you're interested, I can post the zip(s).

regards, jr.

[Thomas de Groot] Re: 3D warp repeat for primitives [607 days 12 hours and 38 minutes ago]

Sat, 10 Aug 2024 07:56:07 GMT

Op 10-8-2024 om 09:32 schreef Thomas de Groot:
> Op 9-8-2024 om 19:33 schreef jr:
>> ingo wrote/published a "meshmaker" macro[*], I guess you could explore 
>> that code
>> for ideas, there's also a "nagging feeling" of having forgotten 
>> another mesh2
>> generating macro published in the NGs.
>>
>> [*] which I haven't to hand, sorry.
>>
>>
> I add it here.
> 
> I have used it, though I don't remember when exactly, I should have a 
> pov-scene somewhere.... (looking for it)
> 
My memory is not what it has been :(

meshmaker.inc can be found in the official POV-Ray/include folder.....

-- 
Thomas

[Thomas de Groot] Re: 3D warp repeat for primitives [607 days 13 hours and 2 minutes ago]

Sat, 10 Aug 2024 07:32:29 GMT

Op 9-8-2024 om 19:33 schreef jr:
> ingo wrote/published a "meshmaker" macro[*], I guess you could explore that code
> for ideas, there's also a "nagging feeling" of having forgotten another mesh2
> generating macro published in the NGs.
> 
> [*] which I haven't to hand, sorry.
> 
> 
I add it here.

I have used it, though I don't remember when exactly, I should have a 
pov-scene somewhere.... (looking for it)

-- 
Thomas

[Bald Eagle] Re: 3D warp repeat for primitives [608 days 2 hours and 4 minutes ago]

Fri, 9 Aug 2024 18:30:00 GMT

"Kenneth" <kdw### [at] gmailcom> wrote:

> As in, taking any pre-made object and turning it into a triangle mesh surface--
> even objects with holes, voids, undercuts, etc. So far, I have solved only 'step
> A'-- finding regularly-spaced points on all the surfaces, without picking
> redundant points. Even that's not quite perfect, though.

Using something like a progressive trace () to generate a crossing number (used
for insidedness tests for polygons, but storing all of the crossing points would
allow this.

https://news.povray.org/povray.pov4.discussion.general/message/%3Cweb.662158a818d5960295196c9d25979125%40news.povray.or
g%3E/#%3Cweb.662158a818d5960295196c9d25979125%40news.povray.org%3E

> The *bigger* problem is
> how to logically connect those points to make triangles... which is the 'holy
> grail' of the entire scheme, of course!

Well, that's why it's easy to convert parametric shapes into meshes, since you
can cycle through the values and calculate where the next point is.

Looking at primitive CSG's or isosurfaces, you're sort of working backwards.
You have a value of sorts, but you don't have access to the underlying mechanism
of how it was generated. (This is also what bothers me about POV-Ray's
parametric {} object - why the hell is it so slow? )

Anyway, none of that really has to do with the repeat warp mechanism for
primitives. . .

- BW

[jr] Re: 3D warp repeat for primitives [608 days 2 hours and 59 minutes ago]

Fri, 9 Aug 2024 17:35:00 GMT

hi,

"Kenneth" <kdw### [at] gmailcom> wrote:
> ...
> As in, taking any pre-made object and turning it into a triangle mesh surface--
> even objects with holes, voids, undercuts, etc. So far, I have solved only 'step
> A'-- finding regularly-spaced points on all the surfaces, without picking
> redundant points. Even that's not quite perfect, though. The *bigger* problem is
> how to logically connect those points to make triangles... which is the 'holy
> grail' of the entire scheme, of course!

ingo wrote/published a "meshmaker" macro[*], I guess you could explore that code
for ideas, there's also a "nagging feeling" of having forgotten another mesh2
generating macro published in the NGs.

[*] which I haven't to hand, sorry.

regards, jr.

[Kenneth] Re: 3D warp repeat for primitives [608 days 3 hours and 9 minutes ago]

Fri, 9 Aug 2024 17:25:00 GMT

"Kenneth" <kdw### [at] gmailcom> wrote:
>
> There is also a 'pivoting ball' algorithm that looks more promising,
> although I don't yet know how I would implement it in SDL.
>

Here's a PDF file of the idea, by the original authors...

https://mesh.brown.edu/taubin/pdfs/bernardini-etal-tvcg99.pdf

[Kenneth] Re: 3D warp repeat for primitives [608 days 3 hours and 19 minutes ago]

Fri, 9 Aug 2024 17:15:00 GMT

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

> > I've also been working for months on various schemes to tesselate a typical
> > pre-made POV-ray object (to eventually turn it directly into an .stl file for
> > 3-D printing). I've solved *some* of the problems, but the overall solution
> > still eludes me :-\  I haven't given up though!
>
> "tesselate" --- More details please!  ;)
>

As in, taking any pre-made object and turning it into a triangle mesh surface--
even objects with holes, voids, undercuts, etc. So far, I have solved only 'step
A'-- finding regularly-spaced points on all the surfaces, without picking
redundant points. Even that's not quite perfect, though. The *bigger* problem is
how to logically connect those points to make triangles... which is the 'holy
grail' of the entire scheme, of course!

As alternatives:
I've looked at the old 'marching cubes' algorithm, but that does not seem to be
appropriate, as it deals with isosurfaces and look-up tables. I don't know
though.

There is also a 'pivoting ball' algorithm that looks more promising, although I
don't yet know how I would implement it in SDL.

Anyway, I didn't mean to hi-jack your post...

[Bald Eagle] Re: 3D warp repeat for primitives [609 days 20 hours and 9 minutes ago]

Thu, 8 Aug 2024 00:25:00 GMT

"Leroy" <whe### [at] gmailcom> wrote:

> There no infinitely repeating objects! There is a limit. Even with functions
> there a point where pov variables can't reach. I was playing with the random
> seed the other day to see just how big of number in would take. After 10 digits
> the seed acted like only the first 10 where used.

Like I said - there is only the limit of the ability of the computer to store
and represent the values.
But within those limits, we can generate "infinite numbers" of objects.

>  If I understand you right, you're trying to fake it with a pattern that holds
> all the different textures of a union of objects, that can use a warp repeat
> type function to fix things up.
>  The trouble with pigments or textures is that they need an object to be on. And
> any object used only shows what hits it. If you want to see a union of objects
> as a 3d pattern you need something 3d that shows only what is part of the
> pattern and let light pass through otherwise.

I'm not trying to fake anything.
When we have meshes, with multiple instantiations, we merely apply a
transformation matrix to the reference mesh in order to do the calculations to
find the new position of the copy.

If we simply apply the same methods to ACTUAL TEXTURED OBJECTS, then we ought to
be able to accomplish exactly the same thing.   When I texture an object, and
THEN translate it, the texture "follows" it.  So i ought to be able to define a
unit cell with a vector, and then simply use mod () to repeat that unit
EVERYWHERE.

The attached is an isosurface of a 100 x 100 grid using mod () which rendered in
7 seconds.  We KNOW primitives render much faster than isosurfaces, and so would
be a feasible way to accomplish the same thing only using all of the native
optimizing of CSG objects.

[Leroy] Re: 3D warp repeat for primitives [609 days 20 hours and 49 minutes ago]

Wed, 7 Aug 2024 23:45:00 GMT

"Bald Eagle" <cre### [at] netscapenet> wrote:
>
> At present, I can define a set of functions to be evaluated as a pigment {}
> pattern, and can use the repeat warp to infinitely tile a plane (or, I suppose,
> all of 3D space)
>
> However what I cannot do (*) is define a set of objects like spheres, and have
> them infinitely repeated using the repeat warp.
>
>* Now, what I can envision is somehow using the object {} pattern to laboriously
> achieve this with some well thought out nesting of the inside and outside
> textures (I do not have the ability to test this at the present moment) -
> however that seems to be very labor intensive, takes a bit of skill and/or macro
> writing, and may not work as I imagine it could.
>

There no infinitely repeating objects! There is a limit. Even with functions
there a point where pov variables can't reach. I was playing with the random
seed the other day to see just how big of number in would take. After 10 digits
the seed acted like only the first 10 where used.

 If I understand you right, you're trying to fake it with a pattern that holds
all the different textures of a union of objects, that can use a warp repeat
type function to fix things up.
 The trouble with pigments or textures is that they need an object to be on. And
any object used only shows what hits it. If you want to see a union of objects
as a 3d pattern you need something 3d that shows only what is part of the
pattern and let light pass through otherwise.
 My first thought was df3 files with media . It might work for pigments only but
trying to use the full texture function might cause problems. And df3 files have
to be large to keep from being  grainy and they are limited.
 Any way I look at it, even if we got something to work it would only be
effective for a relative short distance before it blurs out like most textures
do.

Have Fun

[Bald Eagle] Re: 3D warp repeat for primitives [610 days and 34 minutes ago]

Wed, 7 Aug 2024 20:00:00 GMT

"Kenneth" <kdw### [at] gmailcom> wrote:
> I'm a bit confused as to what the final result should be, or what it should look
> like when applied(?) to your two infinite planes.

Any of our current pigment patterns are procedurally generated, meaning that
they return some value given only the <x, y, z> coordinates as input.
What that essentially means is that there is actually no "pattern" that globally
 exists as a monolithic pre-made thing, but simply a method for determining what
 is at any given point in space when actually evaluated by the raytracer.

> (I'm actually not sure what
> those planes are for.)

The planes would be the limits of the 3D space evaluated for applying the warp
repeat - kinda like an infinite bounding box of a certain thickness.
A "thick plane".

> For endlessly repeating a textured 3D object (like a sphere) *as* 3D objects, a
> simple or nested #for-loop construct would be the easy solution, with each
> sphere offset of course; no 'repeat warp' necessary.

No sir.  I cannot do #for (i, 0, inf)
And I'd have to know _where_ to place all of those 3D objects ahead of time.

What I'm talking about is truly infinite.
Just like our current procedural patterns.

> But I sense that you're
> seeking something different or more complex...possibly involving an 'object
> pattern' use?

Yes, like I mentioned before, it would be "as though" one used the object
pattern, but this would be implemented rather differently to make it simpler.

> More details please!

So, picture I have the unit cube.  I can place 8 spheres in the unit cube "in
the corners" each tangent to 3 sides and 3 other spheres.
I our usual scenes, I could give these spheres a rich pallete of colors,
patterns, normals, finishes, etc.
What I'm simply envisioning is having that unit cell get substituted into ANY
unit cell encompassed by the repeat warp parameters.
So if I repeated it in the x and z directions, I would get a "plane" of that
unit cell containing those 8 spheres anywhere I looked - wherever the camera was
placed, and however far away from the origin I chose.
I could animate the camera position and keep going and going and going, and
there would truly be an infinite number of spheres. (Naturally constrained to
the abilities of the computer to store and represent the <x, y, z> coordinates)

It's that same effect as making an isosurface using <mod (x, 1), y, mod(z,1)>,
but it would be handled much more efficiently vis source, _and it would carry
all of the material properties with it_.
So it would be thousands of times faster and probably tens of thousands of times
less tedious to implement.

> I've also been working for months on various schemes to tesselate a typical
> pre-made POV-ray object (to eventually turn it directly into an .stl file for
> 3-D printing). I've solved *some* of the problems, but the overall solution
> still eludes me :-\  I haven't given up though!

"tesselate" --- More details please!  ;)

- BW

[Kenneth] Re: 3D warp repeat for primitives [610 days 2 hours and 49 minutes ago]

Wed, 7 Aug 2024 17:45:00 GMT

I'm a bit confused as to what the final result should be, or what it should look
like when applied(?) to your two infinite planes. (I'm actually not sure what
those planes are for.)

For endlessly repeating a textured 3D object (like a sphere) *as* 3D objects, a
simple or nested #for-loop construct would be the easy solution, with each
sphere offset of course; no 'repeat warp' necessary. But I sense that you're
seeking something different or more complex...possibly involving an 'object
pattern' use?

More details please!

----------
I haven't posted to the newsgroups in a long while-- real life and work have
taken up my time-- but I'm still reading the posts here. My so-called
'high-speed' internet connection has been problematic too; sometimes it works
fine, but most of the time it's as slow as molasses, and I can't even load a web
page. No idea why.

I've also been working for months on various schemes to tesselate a typical
pre-made POV-ray object (to eventually turn it directly into an .stl file for
3-D printing). I've solved *some* of the problems, but the overall solution
still eludes me :-\  I haven't given up though!

[Bald Eagle] 3D warp repeat for primitives [612 days 2 hours and 39 minutes ago]

Mon, 5 Aug 2024 17:55:00 GMT

So, I was pondering the extension of some patterns, and it occurred to me that
having a 3D primitive-based version of:

https://wiki.povray.org/content/Reference:Warp#Repeat_Warp

would be an excellent feature to be made available - especially for new users or
the non-mathematically inclined.

At present, I can define a set of functions to be evaluated as a pigment {}
pattern, and can use the repeat warp to infinitely tile a plane (or, I suppose,
all of 3D space)

However what I cannot do (*) is define a set of objects like spheres, and have
them infinitely repeated using the repeat warp.

* Now, what I can envision is somehow using the object {} pattern to laboriously
achieve this with some well thought out nesting of the inside and outside
textures (I do not have the ability to test this at the present moment) -
however that seems to be very labor intensive, takes a bit of skill and/or macro
writing, and may not work as I imagine it could.

The idea there being that the objects could be assigned the inside texture,
while the outside would be a transparent rgbt 1.   Then a "thick box" - the
intersection of 2 planes could be assigned that object {} texture with a repeat
warp applied.

I think it would be vastly easier on the user, and probably much faster if
implemented internally, so that one could simply define a typical CSG object,
textured in the usual manner, and then use the min & max_extents to define the
repeat vectors (perhaps as the default).

Thoughts, criticisms, comments on the feasibility, and SDL / source
implementations welcome.  ;)

- BE

[ingo] Re: Suggest v4.0 read only identifiers. (yuqk R1... [639 days 4 hours and 34 minutes ago]

Tue, 9 Jul 2024 16:00:00 GMT

There is http://chiselapp.com/ that hosts fossils (kind of like github) and you
can control who has access to the data. I used it in the past, worked fine then
and then not and then again. Seems to look ok now.

ingo

"Bald Eagle" <cre### [at] netscapenet> wrote:
> "Bald Eagle" <cre### [at] netscapenet> wrote:
>
> > > <https://www.fossil-scm.org/home/doc/trunk/www/index.wiki>
>
> Curious if anyone has the ability and inclination to run this in server mode

[Bald Eagle] Re: Suggest v4.0 read only identifiers. (yuqk R1... [640 days 8 hours and 19 minutes ago]

Mon, 8 Jul 2024 12:15:00 GMT

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

> > <https://www.fossil-scm.org/home/doc/trunk/www/index.wiki>

Curious if anyone has the ability and inclination to run this in server mode, or
alternatively if someone knows of a peer-to-peer (P2P) style collaborative
document editing FOSS software that would serve our purpose.

- BW

[William F Pokorny] Re: Suggest v4.0 read only identifiers. (yuqk R1... [646 days 5 hours and 2 minutes ago]

Tue, 2 Jul 2024 15:32:25 GMT

On 6/29/24 14:36, William F Pokorny wrote:
>>> Given I'm going to delay to implement a build configuration option for
>>> this feature, do you think some other prefix would be better? ('_r',
>>> 'ro_', 'r_', ?)
>>
>> "democracy" eh ?! </grin>.Â  given those options, 'ro_' would be my 
>> choice, as
>> it's "mnemonic".
>>
> 
> Yeah, and ro_ fits with my keyword prefix direction too.

Release 15 of the yuqk fork has moved to the ro_ prefix to indicate the 
identifier is read-only. The build configure script option to disable 
the feature was added and is: --disable-read-only-identifiers

Bill P.

[ingo] Re: Suggest v4.0 read only identifiers. (yuqk R1... [648 days 14 hours and 29 minutes ago]

Sun, 30 Jun 2024 06:05:00 GMT

"ingo" <nomail@nomail> wrote:

>
> Just as an example how it works in an other language. In the Nim programming
> language

I should have added one more option as it does what one can do with macro's.
Note there is now no output type specified and thus no return value. 'a' is
modified "in place".

proc dothing(a: var int, b: int) =
  a = a + b

var  a = 1
let  b = 2

dothing(a, b) # or a.dothing(b)

echo a  #printed result is sum of and b

ingo

[Bald Eagle] Re: Suggest v4.0 read only identifiers. (yuqk R1... [648 days 22 hours and 59 minutes ago]

Sat, 29 Jun 2024 21:35:00 GMT

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

> > I'm game.  I can download that and we can see about getting something started.
>
> <https://www.fossil-scm.org/home/doc/trunk/www/index.wiki>

I'm already "up and running" - just need to figure out how you log in to the
system to start doing stuff.

- BW

[jr] Re: Suggest v4.0 read only identifiers. (yuqk R1... [648 days 23 hours and 14 minutes ago]

Sat, 29 Jun 2024 21:20:00 GMT

"Bald Eagle" <cre### [at] netscapenet> wrote:
> "jr" <cre### [at] gmailcom> wrote:
>
> > a wiki s/ware would be perfect.  personally, I think 'fossil' should "be on the
> > table".
>
> I'm game.  I can download that and we can see about getting something started.

<https://www.fossil-scm.org/home/doc/trunk/www/index.wiki>

> > (the machine which took the place of the common access will be the "bug bear" imo.
>
> We are truly 2 people separated by a common language.

</grin>.  "struggling against the same s/ware configuration", more like.
apparently, the GBP currency sign (too) makes the web l/f "unhappy"; I wrote,
"showing off", that crow's "replacement" has 1.5T (truly mind-boggling "space",
on two M.2 SSDs), for under 100 of our currency units; cheaper still now.

regards, jr.

[Bald Eagle] Re: Suggest v4.0 read only identifiers. (yuqk R1... [648 days 23 hours and 59 minutes ago]

Sat, 29 Jun 2024 20:35:00 GMT

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

> a wiki s/ware would be perfect.  personally, I think 'fossil' should "be on the
> table".

I'm game.  I can download that and we can see about getting something started.

> (the machine which took the place of the common access will be the "bug bear" imo.

We are truly 2 people separated by a common language.

- BW

[jr] Re: Suggest v4.0 read only identifiers. (yuqk R1... [649 days and 54 minutes ago]

Sat, 29 Jun 2024 19:40:00 GMT

hi,

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

a lot of points/issues "touched on", food for thought.  will, in the coming
days, try and set out the response "gut feeling" tells me, structured, for your
inbox.

@Bald Eagle.
> Users could then have a personal "wiki page".

a wiki s/ware would be perfect.  personally, I think 'fossil' should "be on the
table".

> ... it should be fairly small to store local copies ...

no need to worry, in this day and age.  (the machine which took the place of the
'crow' earlier this year has two M.2 "drives" -- 1.5T total, not even £100)

common access will be the "bug bear" imo.

regards, jr.

[Bald Eagle] Re: Suggest v4.0 read only identifiers. (yuqk R1... [649 days 1 hour and 39 minutes ago]

Sat, 29 Jun 2024 18:55:00 GMT

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

> agree, a in-one-place collection of things needing doing, plus "feature
> requests", is very much needed.

Well, this has been brought up by myself and other before,

I think the easiest thing to do would simply be use a collaboration tool or
project management tool and get _something_ started.

https://opensource.com/business/15/7/five-open-source-alternatives-google-docs

Then we could start with a general outline of what we _have_ complete with
hyperlinks to the wiki or whatever works best to illustrate the concept.

Then maybe separate documents that "mirror" the source code, where we could
strip out all of the extraneous non-code stuff, for enhanced readability (with
links to original).  Then people with coding experience could read and comment
on the code, and perhaps even insert hyperlinks between where one piece of code
utilizes a variable, and the (faraway) place in the code where that variable
gets updated last.

Obviously to-do list and desired features.
Coders could begin scribbling scratch code and other people could be inspired
and take it a step further.

The advantage here is that if the outline structure is maintained well, it'll be
a lot easier to find than sifting through 30 years of haphazard forum posts.

Users could then have a personal "wiki page".

FAQ type material could be organized to provide "one code example for every
keyword", micro-tutorials on coding methods / algorithms / tricks, working
examples of tricky syntax, etc.

Macros could be assembled so that people could look things up in an index and
find what they were looking for.
Desired features could be exemplified with macros, and then converted to source
code by people who have the c++ experience but don't understand the goal /
algorithm needed.

And since it should pretty much be all text, with hyperlinks to graphics,
articles, pdf documents, websites, etc, it should be fairly small to store local
copies - which means every collaborator has a copy / backup.

- BW

[William F Pokorny] Re: Suggest v4.0 read only identifiers. (yuqk R1... [649 days 1 hour and 58 minutes ago]

Sat, 29 Jun 2024 18:36:26 GMT

On 6/29/24 01:00, jr wrote:
> hi,
> 
> just a couple of thoughts.
> 
> William F Pokorny <ano### [at] anonymousorg> wrote:
>> ...
>> One day, not long ago, it hit me that maybe identifier prefixes would be
>> a way we could implement reasonably broad, useful constant-ness - ...
>>
>> Given I'm going to delay to implement a build configuration option for
>> this feature, do you think some other prefix would be better? ('_r',
>> 'ro_', 'r_', ?)
> 
> "democracy" eh ?! </grin>.  given those options, 'ro_' would be my choice, as
> it's "mnemonic".
> 

Yeah, and ro_ fits with my keyword prefix direction too.

> 
>> Aside 1: I have still bugs and issues with the current global / local
>> dictionary behavior in v3.8+ to sort... Our implementation doesn't match
>> our documentation and we probably need a #top (or #upid (upvar n))
>> directive alongside #directive and #local.
> 
> having read ingo's Nim language examples, I really like the "everything is
> immutable unless" approach.  safe.  perhaps all macro args (as you wrote
> somewhere) ought to be "ro" by default, and an explicit 'upvar N' required for
> every exception ?  (that (upvar N) :-) would be _seriously_ nice to have)
> 

I've been thinking about those examples too & my response to Ingo's 
question. I failed / bailed on my initial attempts to make a macro 
parameters constant always - but success would have meant a SDL change 
much more likely to break current code than an 'ro_' prefix. I hadn't 
thought much at all about a keyword to change defaulted read-only to 
something mutable via a new keyword.

It might be we could check that the mutability of the parameter in the 
macro matches the caller's ID mutability, but there are limits to how 
much checking like that we can do given SDL isn't compiled and linked. 
We'd be paying the price of the overhead on every call to the macro.

 From what I've seen people mostly use the macro 'pass by reference and 
change' and '#declare ID' as mechanisms to return multiple values or to
define what they want global as with the yuqk munction concept compiling 
users functions only once. (We now have the tuple return and assignment 
mechanisms in v3.8.)

Another thing which might be possible nearer term, would be to make 
mixed use of #declare and #local with the same variable name inside 
macros illegal in yuqk (or in just the debug compile).

See the attached file for a few examples of how mixing one identifier 
name with both #local and #declare can result in instability. The macro 
parameter - change by reference - issue aside.

We should mention too, for those stumbling across this thread later, 
that a good solution for all the macro-ish exposures to inadvertent 
identifier change is to use functions when dealing with just math and a 
return a value.

Bill P.

[jr] Re: Suggest v4.0 read only identifiers. (yuqk R1... [649 days 15 hours and 29 minutes ago]

Sat, 29 Jun 2024 05:05:00 GMT

hi,

just a couple of thoughts.

William F Pokorny <ano### [at] anonymousorg> wrote:
> ...
> One day, not long ago, it hit me that maybe identifier prefixes would be
> a way we could implement reasonably broad, useful constant-ness - ...
>
> Given I'm going to delay to implement a build configuration option for
> this feature, do you think some other prefix would be better? ('_r',
> 'ro_', 'r_', ?)

"democracy" eh ?! </grin>.  given those options, 'ro_' would be my choice, as
it's "mnemonic".

> Aside 1: I have still bugs and issues with the current global / local
> dictionary behavior in v3.8+ to sort... Our implementation doesn't match
> our documentation and we probably need a #top (or #upid (upvar n))
> directive alongside #directive and #local.

having read ingo's Nim language examples, I really like the "everything is
immutable unless" approach.  safe.  perhaps all macro args (as you wrote
somewhere) ought to be "ro" by default, and an explicit 'upvar N' required for
every exception ?  (that (upvar N) :-) would be _seriously_ nice to have)

regards, jr.

[jr] Re: Suggest v4.0 read only identifiers. (yuqk R1... [649 days 15 hours and 34 minutes ago]

Sat, 29 Jun 2024 05:00:00 GMT

hi,

"Bald Eagle" <cre### [at] netscapenet> wrote:
> "jr" <cre### [at] gmailcom> wrote:
> > > > [Cousin Ricky]
> > > > I'm thinking a keyword modifier would be more flexible than a directive,
> > > > for example:
> > > >
> > > >   #declare const GlobalVal = 12345;
> > > >   #local const LocalVal = 54321;
> >
> > "modifier", yes.  +1.
>
> > > Why not just have another separate type of declaration?
> >
> > the keyword modifier, more often than not I think, would be in close proximity
> > to the variable where/when it's used.  an advantage.
>
> In the absence of a concrete example, I'm wondering how the modifier would be
> "more flexible", and what "close proximity to the variable where/when it's
> used." means.

the "close proximity" thing is shown in CR's suggestion, note the 'const'
immediately in front of the variable in question.

"flexible", for instance, a (say) '#constant' directive alone and the macro
definition would still offer no "visual clues" wrt the arguments also could not
be used in expressions either.

(and remember, I'm no "language designer" either :-))


> > if a variable's value can/will change "at runtime", #constant would simply be
> > misleading.
> Sort of.  I think the underlying idea is that it's not forever immutable, but
> protected from unintentional and silent reassignment of it's value.
> What about #protected?
> It could be like function {}, where once declared, the parser throws an
> (intelligible) error unless it's #undef'd before redeclaring.

see reply to WFP.


> The trick is balancing ease-of-coding with good coding practices, and new-user
> friendly syntax so that we don't further steepen the learning curve.
>
> > maybe "4.x" could have a revamped "SDL 2.0", with more "introspection" tools, so
> > we can write better, "type safe" code.
>
> Well YES.  Those sorts of things have long been wanted. ...
> What really needs to be done is to draw a "map" of what we have coupled with
> what we'd like to see.  That would function as a brainstorming vehicle, and a
> to-do list.

agree, a in-one-place collection of things needing doing, plus "feature
requests", is very much needed.


regards, jr.

[tTh] Re: Suggest v4.0 read only identifiers. (yuqk R1... [650 days 4 hours and 43 minutes ago]

Fri, 28 Jun 2024 15:51:01 GMT

On 6/28/24 00:47, Cousin Ricky wrote:

>> Release R15 of the yuqk fork has an implementation supporting constant
>> identifiers / macro parameters. They are indicated by using a leading
>> '_' character in the name.

    Mmmm, this can break some of my code /o\

> I also agree with Ingo: a keyword or directive would be better, such as:
> 
>    #const MagicNumber = 12345;

    [like]

-- 
+---------------------------------------------------------------------+
|          https://tube.interhacker.space/a/tth/video-channels        |
+---------------------------------------------------------------------+

[William F Pokorny] Re: Suggest v4.0 read only identifiers. (yuqk R1... [650 days 6 hours and 53 minutes ago]

Fri, 28 Jun 2024 13:40:40 GMT

On 6/28/24 01:13, ingo wrote:
> William F Pokorny <ano### [at] anonymousorg> wrote:
> 
> 
> #macro Add(_immuInt, otherInt)
> ......
> #end
> 
> #declare Res = Add(99,1)
> 
> #declare _immu = 99;
> 
> #declare Res = Add(_immu, 1)
> 
> In the second use of the macro, would it be required that the 'referenced' value
> is also declared immutable?
> 
> ingo
> 

If I'm understanding you, no with respect to the macro, identifier pass 
by reference issue.

As long as you have _immuInt as the first macro Add() parameter name, 
the call can be Add(_immu,1) or Add(Res,1) and neither _immu or Res can 
be changed by any #local or #declare use of _immuInt inside the macro.

That said, the Res identifier is not protected from someone writing:

     #declare Res = 42;

inside the macro while  	

     #declare _immu = 42;

will be illegal inside the Add() macro. So, it's not necessary the _ 
prefix immutability be indicated in both the macro parameter and more 
global calling space - but it is a good idea, if you want protection 
from someone making more global changes from within the macro.

Related. The hole in the prefix based constant-ness is that it is NOT 
propagated into macros called. For example,

#macro Add(V1,V2)
     #local V1 = V1+V2;
     V1
#end

    #declare _immu = 42;
    #declare Val99 = Add(_immu,1);

will still result in the _immu getting clobbered. The best practice 
would be to always use macro parameter names with the _ prefix - unless 
you are truly aiming to change identifiers by reference inside the 
macro.

Bill P.

[Bald Eagle] Re: Suggest v4.0 read only identifiers. (yuqk R1... [650 days 7 hours and 4 minutes ago]

Fri, 28 Jun 2024 13:30:00 GMT

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

> > > I'm thinking a keyword modifier would be more flexible than a directive,
> > > for example:
> > >
> > >   #declare const GlobalVal = 12345;
> > >   #local const LocalVal = 54321;
>
> "modifier", yes.  +1.

>
> > Hmmm.   Yes, but maybe no?
> > Why not just have another separate type of declaration?
>
> the keyword modifier, more often than not I think, would be in close proximity
> to the variable where/when it's used.  an advantage.

In the absence of a concrete example, I'm wondering how the modifier would be
"more flexible", and what "close proximity to the variable where/when it's
used." means.

> > ...
> > So maybe #constant can ONLY be changed by specifically using another #constant
> > directive.
>
> if a variable's value can/will change "at runtime", #constant would simply be
> misleading.

Sort of.  I think the underlying idea is that it's not forever immutable, but
protected from unintentional and silent reassignment of it's value.

What about #protected?
It could be like function {}, where once declared, the parser throws an
(intelligible) error unless it's #undef'd before redeclaring.

The trick is balancing ease-of-coding with good coding practices, and new-user
friendly syntax so that we don't further steepen the learning curve.

> maybe "4.x" could have a revamped "SDL 2.0", with more "introspection" tools, so
> we can write better, "type safe" code.

Well YES.  Those sorts of things have long been wanted.
Camera location keyword/identifiers that would function like image_height, etc.
Identifier typing, especially for use in #read.
Differentiating things like vectors of different sizes, floats, etc.
View frustum coordinates or an internally defined 3D view frustum (maybe an
internal function that takes a length for the direction vector) that one can do
inside () tests with.

What really needs to be done is to draw a "map" of what we have coupled with
what we'd like to see.  That would function as a brainstorming vehicle, and a
to-do list.

Macros that people have written over the decades could be used as inspiration,
and I'm sure there are code libraries and things on GitHub, etc that have actual
c++ code or whatever language 4.x will be written in.

- BW

[William F Pokorny] Re: Suggest v4.0 read only identifiers. (yuqk R1... [650 days 7 hours and 22 minutes ago]

Fri, 28 Jun 2024 13:12:10 GMT

On 6/27/24 18:47, Cousin Ricky wrote:
> On 2024-06-27 11:44 (-4), William F Pokorny wrote:
>> Release R15 of the yuqk fork has an implementation supporting constant
>> identifiers / macro parameters. They are indicated by using a leading
>> '_' character in the name.
> 
> I also agree with Ingo: a keyword or directive would be better, such as:
> 
>    #const MagicNumber = 12345;
> 
> I'm thinking a keyword modifier would be more flexible than a directive,
> for example:
> 
>    #declare const GlobalVal = 12345;
>    #local const LocalVal = 54321;
> 

Thanks, everyone, for the feedback & thinking toward v4.0.

The yuqk fork is intended to be a playpen for features like this. 
Nothing about any given change or feature is set in stone. It might be 
the current implementation for read only variables gets dumped in part 
or in total after using it for while. I think it a decent approach, but 
I've not used it nearly enough myself to know. It is, likely, the only 
sort of global-ish thing doable with respect to identifier constant-ness 
given the state of our current Scene Description Language (SDL).

With our SDL and parser, we don't have a cleanly scoped and typed 
'variable' declaration system which allows more naturally for the 
propagation and maintenance of constant information. (Any v4.0 SDL 
re-work should probably treat scene identifiers complete apart from the 
language variables)

My initial runs at some constant identifier support started with the 
idea of all macro parameters being considered constant. However, I ran 
across cases where users had macros which used the pass by reference and 
change behavior.

I then started to look at a new 'const' keyword only with macro 
parameters while thinking about how I might extend its usage before 
concluding. There are a great many complications due how our language 
and parser work which drive the need for language refinement or ugly, 
complicated code infrastructure. I dropped the whole idea for years.

With yuqk, I've been forced to create prefixed language SDL keywords to 
fix bugs and enable features. Over time, I started to see it's more or 
less the same kind of weak scoping of functionality in our SDL. Where I 
adopted prefixed keywords the source code too became more understandable 
and manageable. I now plan, over time, to broadly adopt SDL keyword 
prefixes. With this next R15 yuqk release I'll have three in keyword 
prefixes in play with ii_ (input image), ip_ (internal 
pattern/perturbation) and it_ (internal turbulence).

One day, not long ago, it hit me that maybe identifier prefixes would be 
a way we could implement reasonably broad, useful constant-ness - though 
not completely robust, constant-ness. When I started to really look at 
implementing the idea, it turned out it was an amount of code work I 
could manage.

While working in yuqk, the features implemented are often not exactly 
what I'd wish for in v4.0! They are what I can manage and/or am forced 
to do in the context of the yuqk/POV-Ray implementation as it is.

---
(BW) > Is that a scene-wide global thing?

Currently, it's always on and acts depending on context and what's 
defined in each context. There isn't yet a way to configure with the 
feature off as there is with no lower case identifier checking - which 
is on by default in yuqk.

I think you're right, I need to go work on that configuration option 
before releasing R15. We should be able to create executable(s) with the 
checking off.

As for users switching the checking on and off on the fly... I think, 
such control runs counter to the aim of the constant-ness feature itself.

---
(ingo, jr, et al)

I realize there is a fair bit of _xyz parameter and identifier usage. 
It's in a lot of my own stuff too. Much of that will break - sometimes 
while pointing out existing exposures too. I haven't played enough to 
have a feel for the level of pain.

Given I'm going to delay to implement a build configuration option for 
this feature, do you think some other prefix would be better? ('_r', 
'ro_', 'r_', ?)

---
(jr)

Remember yuqk reduced the functionality of the 'optional' keyword to 
just macro parameters due bugs and that when I really looked at broader 
use, I found a new world space for confusing, extremely difficult to 
debug, SDL bugs.

---

The larger view is the yuqk fork is breaking compatibility with official 
POV-Ray releases.

I don't do it lightly because I want to be able to run scenes aimed at 
official releases too, but breakage is unavoidable given I want to 
address certain bugs, features and deficiencies.

Bill P.

Aside 1: I have still bugs and issues with the current global / local 
dictionary behavior in v3.8+ to sort... Our implementation doesn't match 
our documentation and we probably need a #top (or #upid (upvar n)) 
directive alongside #directive and #local.

[ingo] Re: Suggest v4.0 read only identifiers. (yuqk R1... [650 days 11 hours and 9 minutes ago]

Fri, 28 Jun 2024 09:25:00 GMT

"Bald Eagle" <cre### [at] netscapenet> wrote:
> I dunno - I'm not really a computer language person, but the pro's and cons of
> each approach ought to be hashed out with an eye towards Pov-Ray 4.0
>

Just as an example how it works in an other language. In the Nim programming
language the following will not work as all proc parameters are immutable int
types. With Nim procs immutable arguments is the default, unless one uses "var":

proc dothing(a: int, b: int): int =
  a = a + b
  return a

let
  a = 1
  b = 2

let res = dothing(a, b)

This one will work as c is declared and assigned a value, c is immutable (let)

proc dothing(a: int, b: int): int =
  let c = a + b
  return c

let
  a = 1
  b = 2

let res = dothing(a, b)

This will work as a is now of type var int, a mutable variable:

proc dothing(a: var int, b: int): int =
  a = a + b
  return a

var  a = 1
let  b = 2

a = dothing(a, b)

In the last example 'a' is 'var' in the proc and 'a' has to be "declared" as
'var', else the Nim compiler nags.

Changing a variable "declared" using 'let' into a 'var', or the other way
around, is not possible.

N.B. the last two examples can coexist next to each other in one file/program.
Depending on whether 'a' is a 'var' or not, the compiler chooses the proper
proc.

ingo

[jr] Re: Suggest v4.0 read only identifiers. (yuqk R1... [650 days 11 hours and 49 minutes ago]

Fri, 28 Jun 2024 08:45:00 GMT

hi,

"Bald Eagle" <cre### [at] netscapenet> wrote:
> Cousin Ricky <ric### [at] yahoocom> wrote:
> > On 2024-06-27 11:44 (-4), William F Pokorny wrote:
> > > Release R15 of the yuqk fork has an implementation supporting constant
> > > identifiers / macro parameters. They are indicated by using a leading
> > > '_' character in the name.
> >
> > I also agree with Ingo: a keyword or directive would be better, such as:
> >
> >   #const MagicNumber = 12345;
> >
> > I'm thinking a keyword modifier would be more flexible than a directive,
> > for example:
> >
> >   #declare const GlobalVal = 12345;
> >   #local const LocalVal = 54321;

"modifier", yes.  +1.


> Hmmm.   Yes, but maybe no?
> Why not just have another separate type of declaration?

the keyword modifier, more often than not I think, would be in close proximity
to the variable where/when it's used.  an advantage.


> ...
> So maybe #constant can ONLY be changed by specifically using another #constant
> directive.

if a variable's value can/will change "at runtime", #constant would simply be
misleading.


> I dunno - I'm not really a computer language person, but the pro's and cons of
> each approach ought to be hashed out with an eye towards Pov-Ray 4.0

maybe "4.x" could have a revamped "SDL 2.0", with more "introspection" tools, so
we can write better, "type safe" code.


regards, jr.

[ingo] Re: Suggest v4.0 read only identifiers. (yuqk R1... [650 days 15 hours and 19 minutes ago]

Fri, 28 Jun 2024 05:15:00 GMT

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


#macro Add(_immuInt, otherInt)
......
#end

#declare Res = Add(99,1)

#declare _immu = 99;

#declare Res = Add(_immu, 1)

In the second use of the macro, would it be required that the 'referenced' value
is also declared immutable?

ingo

[Bald Eagle] Re: Suggest v4.0 read only identifiers. (yuqk R1... [650 days 21 hours and 9 minutes ago]

Thu, 27 Jun 2024 23:25:00 GMT

Cousin Ricky <ric### [at] yahoocom> wrote:
> On 2024-06-27 11:44 (-4), William F Pokorny wrote:
> > Release R15 of the yuqk fork has an implementation supporting constant
> > identifiers / macro parameters. They are indicated by using a leading
> > '_' character in the name.
>
> I also agree with Ingo: a keyword or directive would be better, such as:
>
>   #const MagicNumber = 12345;
>
> I'm thinking a keyword modifier would be more flexible than a directive,
> for example:
>
>   #declare const GlobalVal = 12345;
>   #local const LocalVal = 54321;

Hmmm.   Yes, but maybe no?
Why not just have another separate type of declaration?

#declare
#local
#constant

We've also discussed
#persistent

as well as PRAGMA

So maybe #constant can ONLY be changed by specifically using another #constant
directive.

I dunno - I'm not really a computer language person, but the pro's and cons of
each approach ought to be hashed out with an eye towards Pov-Ray 4.0

- BW

[Cousin Ricky] Re: Suggest v4.0 read only identifiers. (yuqk R1... [650 days 21 hours and 46 minutes ago]

Thu, 27 Jun 2024 22:47:55 GMT

On 2024-06-27 11:44 (-4), William F Pokorny wrote:
> Release R15 of the yuqk fork has an implementation supporting constant
> identifiers / macro parameters. They are indicated by using a leading
> '_' character in the name.

I also agree with Ingo: a keyword or directive would be better, such as:

  #const MagicNumber = 12345;

I'm thinking a keyword modifier would be more flexible than a directive,
for example:

  #declare const GlobalVal = 12345;
  #local const LocalVal = 54321;

[jr] Re: Suggest v4.0 read only identifiers. (yuqk R1... [651 days 3 hours and 4 minutes ago]

Thu, 27 Jun 2024 17:30:00 GMT

hi,

William F Pokorny <ano### [at] anonymousorg> wrote:
> Release R15 of the yuqk fork has an implementation supporting constant
> identifiers / macro parameters. They are indicated by using a leading
> '_' character in the name.

agree with ingo, a keyword would be "cleaner".  we already can write:

  #macro foo(optional a)  ...  #end

suggest a 'const' or such ?  ie

  #macro foo(a, const b, optional c)  ...  #end


regards, jr.

[ingo] Re: Suggest v4.0 read only identifiers. (yuqk R1... [651 days 3 hours and 44 minutes ago]

Thu, 27 Jun 2024 16:50:00 GMT

William F Pokorny <ano### [at] anonymousorg> wrote:
> Release R15 of the yuqk fork has an implementation supporting constant
> identifiers / macro parameters. They are indicated by using a leading
> '_' character in the name.
>
> Aside: I have hopes this mechanism a step toward enabling the safe
> passing of function pointers into yuqk's inbuilt functions.
>
> Attached a first pass at a little documentation for the feature.

There are quite a lot of include files out there that use a starting underscore
to prevent name space collisions. Many of these variables are also variable and
not 'static/constant'. Would that break scene's and includes?


(Would, for example a '#let' keyword for immutables be an option, or is that an
awful lot more work.)

ingo

[Bald Eagle] Re: Suggest v4.0 read only identifiers. (yuqk R1... [651 days 4 hours and 29 minutes ago]

Thu, 27 Jun 2024 16:05:00 GMT

William F Pokorny <ano### [at] anonymousorg> wrote:
> Release R15 of the yuqk fork has an implementation supporting constant
> identifiers / macro parameters. They are indicated by using a leading
> '_' character in the name.
>
> Aside: I have hopes this mechanism a step toward enabling the safe
> passing of function pointers into yuqk's inbuilt functions.
>
> Attached a first pass at a little documentation for the feature.
>
> Bill P.

Very nice - I hope that works out the way you/we/everyone would like.

"Parse Error:
Attempt to #undef a constant identifier.
The identifier is:
    '_V99'
Due the leading '_' the existing identifier can only be read.
Fatal error in parser: Cannot parse input."

Is that a scene-wide global thing?
Due to some need to actually undefine or redefine a variable, maybe the leading
underscore could be a safeguard, rather than a complete lockout.

Maybe have some mechanism by which you can do the equivalent of su in a shell to
override the protections set in place to prevent casual/inadvertent overwriting.

Only saying this because it might make some things pretty awkward to code from
scratch / covert from legacy scenes into yuqk.

I dunno - maybe doing scene development you might want to have the safeguard in
place for the main scene, but during experimentation you want to turn off the
protection, but not scene-wide, only in the little test block of code that
you're fiddling with.

Just a thought.

[William F Pokorny] Suggest v4.0 read only identifiers. (yuqk R15 v0... [651 days 4 hours and 50 minutes ago]

Thu, 27 Jun 2024 15:44:27 GMT

Release R15 of the yuqk fork has an implementation supporting constant 
identifiers / macro parameters. They are indicated by using a leading 
'_' character in the name.

Aside: I have hopes this mechanism a step toward enabling the safe 
passing of function pointers into yuqk's inbuilt functions.

Attached a first pass at a little documentation for the feature.

Bill P.

[jr] Re: Suggest v4.0 updates to 'crackle'. (yuqk R15... [663 days 4 hours and 44 minutes ago]

Sat, 15 Jun 2024 15:50:00 GMT

hi,

William F Pokorny <ano### [at] anonymousorg> wrote:
> ...
> Otherwise, just a bunch of achievable crackle scalar value results given
> the new and altered options in the yuqk fork.

wow.  hard to credit it's all the same pattern/function.  v nice.


regards, jr.

[William F Pokorny] Suggest v4.0 updates to 'crackle'. (yuqk R15 v0.... [663 days 6 hours ago]

Sat, 15 Jun 2024 14:34:21 GMT

Attached scene and image files demonstrating suggested new features 
using the default crackle scalar value mode.

The upper right and middle right in the image use a new metric 132 - a 
cube root of square distance.

---

Otherwise, just a bunch of achievable crackle scalar value results given 
the new and altered options in the yuqk fork.

Bill P.

[William F Pokorny] Suggest v4.0 updates to 'crackle ip_solid'. (yuq... [663 days 7 hours and 42 minutes ago]

Sat, 15 Jun 2024 12:52:19 GMT

Attached scene and image files demonstrating suggested new features(*) 
using crackle's solid mode.

The offset / 'ip_offset' in yuqk is fixed / changed so it is applied 
just prior to the return of the pattern's value. This means unlike 
official POV-Ray it works with the solid mode.

The yuqk fork has added 'ip_strength' and 'ip_raw_return' features.

---

The top row of the image shows the three noise generator options (1,2,3).


The middle row shows the three noise generator options (1,2,3), but now 
using 'ip_strength <0,0,0> so that the cube centers running from -4,-4,0 
to 4,4,0 (**) are used as seeds for Noise(). It shows especially the 
weakness of the original perlin noise implementation(***) - middle, right.


The bottom row uses the default noise generator 2 always and:

   Left: ip_strength <0.5,0,0>

   Middle: ip_strength <0,2,0>  // can cheat >1 with solid mode

   Right: ip_repeat <2,2,0> ip_strength <0,0,0.7>


Bill P.


(*) - Additional features likely still to come, but work is stalled due 
cache issue.

(**) - There are optimizations which make this statement a bit of a lie.

(***) - We are landing on the grid boundaries - the Noise() value range 
only 0.459921 - 0.524583. An improved perlin noise implementation 
exists, but it is not available in POV-Ray.

[William F Pokorny] Re: Alt v4.0 facets pattern interface. (yuqk R15... [664 days 21 hours and 3 minutes ago]

Thu, 13 Jun 2024 23:31:05 GMT

On 6/4/24 18:34, William F Pokorny wrote:
>  Â //--- The version with yuqk's keyword changes
>  Â Â  facets type 0 ip_size 0.1
>  Â Â Â Â  ip_metricÂ 
0+(frame_number-1)*1.0 bump_size 0.8

A quick note. I moved up a planned 'type' to 'ip_type' change to release 
(R15) of the yuqk fork.

This affects yuqk's current 'facets' perturbation syntax.

Bill P.

[William F Pokorny] Re: Suggest new v4.0 'spatial' normal{} perturba... [664 days 21 hours and 5 minutes ago]

Thu, 13 Jun 2024 23:29:06 GMT

On 6/1/24 11:11, William F Pokorny wrote:
> Currently, the only options are three 'type' values in 0,1 and 2.

A quick note. I moved up a planned 'type' to 'ip_type' change to release 
(R15) of the yuqk fork.

This affects yuqk's new 'spatial' perturbation syntax.

Bill P.

[William F Pokorny] Re: Suggest new v4.0 'lean' normal{} perturbatio... [664 days 21 hours and 6 minutes ago]

Thu, 13 Jun 2024 23:27:55 GMT

On 5/31/24 14:00, William F Pokorny wrote:
> It uses a 'type' keyword...

A quick note. I moved up a planned 'type' to 'ip_type' change to release 
(R15) of the yuqk fork.

This affects yuqk's new 'lean' perturbation syntax.

Bill P.

[William F Pokorny] Re: Software rewrite (article) [667 days 4 hours and 52 minutes ago]

Tue, 11 Jun 2024 15:42:16 GMT

On 6/11/24 09:11, Bald Eagle wrote:
> 
> I was reading this the other day, and thought it might be something interesting
> re: 4.0
> 
> https://medium.com/@herbcaudill/lessons-from-6-software-rewrite-stories-635e4c8f7c22
> 

Thanks. :-) I cannot read it at the moment due some real life demands 
today, but I'll put it on my to-read list.

Bill P.

[Bald Eagle] Software rewrite (article) [667 days 7 hours and 19 minutes ago]

Tue, 11 Jun 2024 13:15:00 GMT

I was reading this the other day, and thought it might be something interesting
re: 4.0

https://medium.com/@herbcaudill/lessons-from-6-software-rewrite-stories-635e4c8f7c22

[William F Pokorny] Re: Alt v4.0 facets pattern interface. (yuqk R15... [673 days 5 hours and 31 minutes ago]

Wed, 5 Jun 2024 15:02:49 GMT

On 6/5/24 09:04, jr wrote:
> 5) The internal code used a crackle implementation but it is an older

First, the above bit should have read:

5) The internal code uses a crackle implementation, but it is an older...

And correct, I was referring to the 'metric' keyword not being mentioned 
as a 'facets' pattern / perturbation option when it is supported:

https://wiki.povray.org/content/Reference:Facets_Pattern

At the moment I'm unsure if I'll change any of the existing 'facets' 
core code(a). However, I did want to set up to take a run at adding 
additional types along the lines of the facets pattern I posted about 
last fall to the existing 'facets' perturbation wrapper. See:

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

Bill P.

(a) - I can somewhat see how the type 0 / flat form of 'facets' could be 
converted to our current 'crackle' implementation (facets is still 
missing the 'form' capability which could be cool). I'm a lot less clear 
on how I might adapt (or replace) the type 2 / curved surface approach. 
In any case, the up front plan is to get one or more of my facet ideas 
running as types 3,4,... so I can play. :-)

[jr] Re: Alt v4.0 facets pattern interface. (yuqk R15... [673 days 7 hours and 24 minutes ago]

Wed, 5 Jun 2024 13:10:00 GMT

hi,

William F Pokorny <ano### [at] anonymousorg> wrote:
> ...
> 3) In news to me, there exist already a fully functioning 'metric'
> keyword for both forms. I'm not aware of this being documented anywhere?
> ...
> 5) The internal code used a crackle implementation but it is an older
> and (by comment at least) slower version than the current crackle
> pattern code implementation.

guessing not what you meant, but in the wiki reference page 'metric' links to:
<https://wiki.povray.org/content/Reference:Crackle_Pattern>


regards, jr.

[William F Pokorny] Alt v4.0 facets pattern interface. (yuqk R15 v0.... [673 days 21 hours and 59 minutes ago]

Tue, 4 Jun 2024 22:34:53 GMT

I've dug into the normal{} block facets perturbation code a little. I'll 
note a few things and then show the initial set of related keyword 
changes I hope makes facets simpler to use in yuqk.

These notes which apply to official releases and the yuqk fork:

1) Spatial modifiers (ie scale 0.5) as used within the normal{} block 
affect only the flat form.

2) The 'coords' keyword is effectively 'bump_size', thought it only 
affects the flat form.

3) In news to me, there exist already a fully functioning 'metric' 
keyword for both forms. I'm not aware of this being documented anywhere?

4) It was noted somewhere on these news groups that facets replaces the 
normal rather than perturbs it, but this is only true for the 
spherically / curved surface oriented version of facets.

5) The internal code used a crackle implementation but it is an older 
and (by comment at least) slower version than the current crackle 
pattern code implementation.

6) The spherical form is best applied around the origin then transformed 
for use.

7) Both patterns are sensitive to extreme scaling around the default of 
0.1. The spherical form more so than the flat one.

-----------

The attached image reflects the result of the top set of normal{} block 
facets specifications for recent official releases of POV-Ray as well as 
the bottom set of four specifications reflecting the keyword changes 
being adopted for release R15 of yuqk. The core facet implementation has 
not yet been changed.

The aim was to quickly try out the already implemented 'metric' keyword 
code and the keyword changes.

  //--- For official releases
  //facets coords 0.8 size 0.1 metric  0+(frame_number-1)*1.0
  //facets coords 0.8 size 0.1 metric -2+(frame_number-1)*0.5
  //facets coords 0.0 size 0.1 metric  0+(frame_number-1)*1.0
  //facets coords 0.0 size 0.1 metric -2+(frame_number-1)*0.5

  //--- The version with yuqk's keyword changes
    facets type 0 ip_size 0.1
      ip_metric  0+(frame_number-1)*1.0 bump_size 0.8
  //facets type 0 ip_size 0.1
  //  ip_metric -2+(frame_number-1)*0.5 bump_size 0.8
  //facets type 1 ip_size 0.1
  //  ip_metric  0+(frame_number-1)*1.0
  //facets type 1 ip_size 0.1
  //  ip_metric -2+(frame_number-1)*0.5

Bill P.

[William F Pokorny] Re: Suggest new v4.0 'spatial' normal{} perturba... [677 days 5 hours and 11 minutes ago]

Sat, 1 Jun 2024 15:22:58 GMT

On 6/1/24 11:11, William F Pokorny wrote:
> It's an attempt to open the door for users to create normal patterns 
> based on spatial information in a way sort of like what happens when 
> scalar value patterns / functions are used in a normal{} block.

Another 'spatial' normal{} image using the following code:

#declare Nrml_0 = normal {
   //spatial type 0 bump_size +0.3  // Left
     spatial type 1 bump_size +1.5  // Right
     warp { repeat x offset 1/3 flip y}
     warp { repeat y offset 2/3 flip z}
     warp { repeat z offset 0/3 flip x}
     rotate <+22,+44,-43>
     warp { repeat x offset 0/3 flip y}
     warp { repeat y offset 1/3 flip z}
     warp { repeat z offset 2/3 flip x}
     rotate <-33,+22,-11>
     scale 1/17
}

Bill P.

[William F Pokorny] Suggest new v4.0 'spatial' normal{} perturbation... [677 days 5 hours and 23 minutes ago]

Sat, 1 Jun 2024 15:11:26 GMT

Reference:

https://news.povray.org/povray.unofficial.patches/message/%3C60a268da%241%40news.povray.org%3E/

The general idea with the 'spatial' normal{} perturbation pattern is to
use only spatial modifiers (warp, rotate, etc) to create various normal
perturbations. In other words, there isn't any inbuilt perturbation code
per se, but rather a few post treatments for the difference between the
true surface intersection point vs its spatially modified location.

It's an attempt to open the door for users to create normal patterns
based on spatial information in a way sort of like what happens when
scalar value patterns / functions are used in a normal{} block.

Currently, the only options are three 'type' values in 0,1 and 2.

Zero is the simplest treatment and basically the spatial difference
weighted by the bump_size.

One is more complicated and it allows bump_sizes much larger than 1.0
without inverting - so long as the values are not negative.

Two is like (1), but with additional code to prevent larger negative
bump_size values from inverting the normals (turning lit surface
contributions black).

Please see the attached files. With respect to the image: Obj_1 is shown
in the upper left, Obj_2 in the upper right, Obj_3 in the lower left and
Obj_4 in the lower right.

Lastly I'll add, 'spatial' is the most experimental of the new normal{}
perturbation patterns added of late. I've played with a larger
collection of 'spatial' difference treatments, but only these initial
three types 'feel' stable enough at this point.

Bill P.

[William F Pokorny] Suggest new v4.0 'lean' normal{} perturbation. (... [678 days 2 hours and 34 minutes ago]

Fri, 31 May 2024 18:00:02 GMT

The perturbation leans / bends incoming normals (or already perturbed 
normals) toward the 3D vector specified by 'ip_direction'.

It uses a 'type' keyword with values of 0 or 1.  When 0, 'lean' acts 
like most normal perturbation patterns in perturbing the raw surface 
normal. When the type is 1 however, the code starts with the previous 
perturbed normal and makes it lean toward ip_direction.

Part of the thinking is this leaning capability might be useful in a 
sort of 'radiosity importance' kind of way. Something where each shape's 
normals could be bent toward the most important lighting for it. 
Radiosity would need to have 'normals on', of course. How well the it 
might work in practice, I do not know. There's a small pile of 
trade-offs in play.

It might be on some thought, that it would make sense to add the type 1 
chaining of normal perturbations to other normal{} block specific 
patterns, but that's something for another day. It wouldn't work for 
some patterns, but maybe there is some value with others.

In the attached image the columns are using lean ip_direction vectors 
of: <0,0,0>, <0,+1,0> and <0,-1,0>.

The top row shows just the type 0 lean pattern results.

The middle row again using type 0, averages 'lean' and 'quilted' raw 
perturbed normals in a traditional way.

The bottom row now using type 1, chains the quilted and lean patterns 
one after the other using the average infrastructure with slightly 
different weighting. It amounts to raw normal -> perturb -> perturb -> 
perturb...

Bill P.


// SDL code excerpt. Requires yuqk release 15 or later.

#declare WestSide = srgb <1,0.56863,0.05882>;
#declare Pig99 = pigment { WestSide }
#declare Fin99 = finish { brilliance 2 phong 0.5 phong_size 50 }

#declare  DirY = -1;

#declare NrmLean = normal {
     lean type 0 ip_direction <0,DirY,0> bump_size 0.5
}
#declare NrmAve0 = normal {
     average
     normal_map {
          [1 quilted bump_size 0.5 scale 1/8]
          [1 lean type 0 ip_direction <0,DirY,0> bump_size 0.5]
     }
}
#declare NrmAve1 = normal {
     average
     normal_map {
          [0 quilted bump_size 0.5 scale 1/8]
          [1 lean type 1 ip_direction <0,DirY,0> bump_size 0.5]
     }
}

#declare Txt99 = texture {
     pigment { Pig99 }
   //normal { NrmLean }  // Top row     Col DirYs = 0 +1 -1
   //normal { NrmAve0 }  // Middle row  Col DirYs = 0 +1 -1
     normal { NrmAve1 }  // Borrom row  Col DirYs = 0 +1 -1
     finish { Fin99 }
}
#declare Obj99 = object { Iso99 texture { Txt99 } }

[William F Pokorny] Suggest new v4.0 'niln' normal{} perturbation. (... [679 days 1 hour and 14 minutes ago]

Thu, 30 May 2024 19:20:04 GMT

An implementation of a nil / zero normal{} pattern (niln)

Ref:

https://news.povray.org/povray.binaries.images/message/%3C657b1e7e%241%40news.povray.org%3E

...
default {
     pigment { rgb <0,0.7,0.5>}
     finish { diffuse 0.3 }
     normal { quilted bump_size 0.5 scale 1/6 }
}
#declare TxtrDflt = texture {
     pigment { Pigm99 }
     normal { concrete bump_size -0.2 scale 50 }
     finish { brilliance 3 }
}
...
//--- scene ---
...
#if (frame_number = 1) // R0C0
     object { ObjIso }  // Starts with TxtrDflt assigned
#end
#if (frame_number = 2) // R0C1
     object { ObjIso texture { pigment { rgb <0.5,0.5,0> } } }
#end
#if (frame_number = 3) // R0C2
     object { ObjIso texture { finish  { brilliance 7 } } }
#end
#if (frame_number = 4) // R1C0
     object { ObjIso texture { normal  {} } }
#end
#if (frame_number = 5) // R1C1
     object { ObjIso texture { normal  { niln } } }
#end
#if (frame_number = 6) // R1C2
     object { ObjIso texture {
             TxtrDflt
             pigment { rgb <0.5,0.5,0> } }
         }
#end
#if (frame_number = 7) // R2C0
     object { ObjIso texture {
             TxtrDflt
             finish  { brilliance 7 } }
         }
#end
#if (frame_number = 8) // R2C1
     object { ObjIso texture { TxtrDflt normal  {} } }
#end
#if (frame_number = 9) // R2C2
     object { ObjIso texture { TxtrDflt normal  { niln } } }
#end

Bill P.

[William F Pokorny] Re: Suggest new v4.0 'concrete' normal{} perturb... [680 days 10 hours and 13 minutes ago]

Wed, 29 May 2024 10:21:26 GMT

On 5/29/24 05:58, William F Pokorny wrote:
> normal { concrete bump_size +1.9 scale 1/2 }

The 'concrete' normal perturbation can also be scaled up to a somewhat 
large value to get something like a camouflage (partially rounded 
facets?) result.

   normal { concrete bump_size -0.2 scale 50 }

In the attached image I changed the 'brick' pattern's 'ip_spacing' to:

   ip_spacing <1.0*0.7,0.0,0.0>

to demonstrates that the updated 'brick' pattern can be now used to 
create other than strictly brick like patterns.

Bill P.

[William F Pokorny] Suggest new v4.0 'concrete' normal{} perturbatio... [680 days 10 hours and 36 minutes ago]

Wed, 29 May 2024 09:58:11 GMT

See the attached scene and image files. The upper left result is a 
repeat of an earlier thread about an easier to use 'brick' pattern, but 
now with:

     finish { diffuse 0.8 brilliance 7 }

The upper right makes use of yuqk's 'it_scale' with:

     warp { it_amount 0.3 it_scale 0.022 }

The lower left adds:

     normal { concrete }

The lower right replaces that normal with:

     normal { concrete bump_size +1.9 scale 1/2 }

---

The end result is no match for Chris R's isosurface brick walls, but for 
something quick, perhaps not too bad.

Bill P.

[William F Pokorny] Re: Suggest v4.0 updates to 'brick'. (yuqk R15 v... [680 days 12 hours and 34 minutes ago]

Wed, 29 May 2024 08:00:23 GMT

On 5/28/24 13:23, Bald Eagle wrote:
> I'd like a look at the source for that little snippet, to see how you made the
> improvements.  ðŸ™‚
> 
> Did you borrow your solution from somewhere, or is this home-rolled?

In this case, once I finally looked in detail at the core 'brick' code, 
I found it was mostly, already set up in a way to support the changes I 
made...

In the yuqk code base, and the file pattern.cpp (where there was already 
change relative to v3.8), the older code:

double BrickPattern::Evaluate(const Vector3d& EPoint,
   const Intersection* /*pIsection*/,
   const Ray* /*pRay*/, TraceThreadData* /*pThread*/) const
{
// pIsection, pRay, pThread not presently used.
// Commented to avoid -Wunused-parameter

     int ibrickx, ibricky, ibrickz;
     double brickheight, brickwidth, brickdepth;
     double brickmortar, mortarheight, mortarwidth, mortardepth;
     double brickx, bricky, brickz;
     double x, y, z, fudgit;

     fudgit = gkDBL_epsilon + mortar;

     x =  EPoint[X]+fudgit;
     y =  EPoint[Y]+fudgit;
     z =  EPoint[Z]+fudgit;

     brickwidth  = brickSize[X];
     brickheight = brickSize[Y];
     brickdepth  = brickSize[Z];
     brickmortar = mortar;

     mortarwidth  = brickmortar / brickwidth;
     mortarheight = brickmortar / brickheight;
     mortardepth  = brickmortar / brickdepth;
...

was changed to:

double BrickPattern::Evaluate(const Vector3d& EPoint,
   const Intersection* /*pIsection*/,
   const Ray* /*pRay*/, TraceThreadData* /*pThread*/) const
{
// pIsection, pRay, pThread not presently used.
// Commented to avoid -Wunused-parameter

     int ibrickx, ibricky, ibrickz;
     double brickheight, brickwidth, brickdepth;
     double mortarheight, mortarwidth, mortardepth;
     double brickx, bricky, brickz;
     double x, y, z;

     x = EPoint[X]+gkMinIsectDepthReturned;
     y = EPoint[Y]+gkMinIsectDepthReturned;
     z = EPoint[Z]+gkMinIsectDepthReturned;

     brickwidth  = brickSize[X] + brickSpacing[X];
     brickheight = brickSize[Y] + brickSpacing[Y];
     brickdepth  = brickSize[Z] + brickSpacing[Z];

     mortarwidth  = brickSpacing[X] / brickwidth;
     mortarheight = brickSpacing[Y] / brickheight;
     mortardepth  = brickSpacing[Z] / brickdepth;
...

The whole of the change covers roughly a half a dozen source code files 
and as many, or more, files related to documentation, examples and 
testing. All of that not being very interesting and amounting to the 
cost of almost any change in how stuff works! :-)

Bill P.

[Bald Eagle] Re: Suggest v4.0 updates to 'brick'. (yuqk R15 v... [681 days 3 hours and 9 minutes ago]

Tue, 28 May 2024 17:25:00 GMT

Damn.
Nice job!

I'd like a look at the source for that little snippet, to see how you made the
improvements.  :)

Did you borrow your solution from somewhere, or is this home-rolled?

I like both examples - they really show how the changes make it BETTER.

- BW

[tTh] Re: Suggest v4.0 updates to 'brick'. (yuqk R15 v... [681 days 10 hours and 54 minutes ago]

Tue, 28 May 2024 09:40:08 GMT

On 5/28/24 10:51, William F Pokorny wrote:

> In short, make the brick discrete value pattern easier to use.
    Also in short, I like that :)

-- 
+---------------------------------------------------------------------+
|          https://tube.interhacker.space/a/tth/video-channels        |
+---------------------------------------------------------------------+

[William F Pokorny] Suggest v4.0 updates to 'brick'. (yuqk R15 v0.6.... [681 days 11 hours and 42 minutes ago]

Tue, 28 May 2024 08:51:40 GMT

In short, make the brick discrete value pattern easier to use.

Move the 'brick_size' and 'mortar' keywords to the generic 'ip_size' and 
'ip_spacing' keywords respectively. The ip_size is now the actual 3D 
brick size and not the brick+mortar size. The ip_spacing is now a 3D 
vector indicating the brick to brick space (mortar thickness) in each of 
the three directions.

The ip_spacing vector components can be zero - in which case the brick 
effectively becomes infinite in that direction. This capability makes it 
easier to apply and map the 'brick' pattern.

In other words, being able to zero the mortar between bricks in one 
direction helps avoid the common issue of surfaces drifting into the 
mortar regions of the pattern. See attached image with the traditional 
'brick' pattern in the left column and the updated yuqk implementation 
in the right column.

Lastly, an internal pattern offset using the mortar value was removed as 
its aim now addressed by being able to zero spacing directions. This 
change should make the pattern somewhat more intuitive to use as well.

Bill P.

[William F Pokorny] Re: Suggest v4.0 inbuilt f_catenary(). (yuqk R15... [686 days 4 hours and 37 minutes ago]

Thu, 23 May 2024 15:57:04 GMT

On 5/22/24 06:32, Bald Eagle wrote:
> Better would be to allow spline {} to take any function as a
> spline definition (whether it would make sense to from a spline perspective or
> not).

That's an interesting idea. Where the functions support 't' or at least 
a rough equivalent I suppose.

Once in a while I look at Ingo's gradient.inc with the idea of 
supporting something like that whole collection as one inbuilt function 
with 'modes' or 'selections' to run each.

Bill P.

[William F Pokorny] Re: Suggest v4.0 inbuilt f_catenary(). (yuqk R15... [686 days 4 hours and 51 minutes ago]

Thu, 23 May 2024 15:43:14 GMT

On 5/22/24 12:45, jr wrote:
> Chris B's 'rope' set of macros though, where 'catenary'
> is among the given keywords.

Yes, perhaps this is what I was remembering... With my old head one can 
never be sure. :-)

Bill P.

[jr] Re: Suggest v4.0 inbuilt f_catenary(). (yuqk R15... [687 days 3 hours and 44 minutes ago]

Wed, 22 May 2024 16:50:00 GMT

hi,

"Cousin Ricky" <rickysttATyahooDOTcom> wrote:
> William F Pokorny <ano### [at] anonymousorg> wrote:
> > Another approach was used by PM 2RING for his catenary.inc ...
> It was never in the Object Collection.  ...

the collection does have Chris B's 'rope' set of macros though, where 'catenary'
is among the given keywords.  no idea if useful / applicable, but attached here.

regards, jr.

[Cousin Ricky] Re: Suggest v4.0 inbuilt f_catenary(). (yuqk R15... [687 days 4 hours and 4 minutes ago]

Wed, 22 May 2024 16:30:00 GMT

William F Pokorny <ano### [at] anonymousorg> wrote:
>
> Another approach was used by PM 2RING for his catenary.inc set up
> specifically for chains with definable links. This include might have
> been in the object collection..? My copy of it came by way of a post
> from Thomas a few years ago.

It was never in the Object Collection.  My copy came from this post:

https://news.povray.org/web.43182c9b30c60c8bbc2b06b10%40news.povray.org

[Bald Eagle] Re: Suggest v4.0 inbuilt f_catenary(). (yuqk R15... [687 days 9 hours and 59 minutes ago]

Wed, 22 May 2024 10:35:00 GMT

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

> IIRC, it's y' (slope) in the upper right. The bottom row being
> arc length, t and angle.

Ah, they are graphs.   Got it.

>  With the
> first two, I'd lean toward adding them as additional splines(a). It
> might be hgpovray38 has these - it supports many additional splines.

But then I'm trapped by the restriction of only using those with in a spline
keyword block.  Better would be to allow spline {} to take any function as a
spline definition (whether it would make sense to from a spline perspective or
not).

> The f_voronoi() inbuilt is on my list (with additional metrics). The
> hgpovray38 fork has already some of the voronoi with specified vertices
> functionality already too.

It's still a challenge (for me) to return a result of "I am in cell 'N', closest
to seed 'n' " rather than just returning the seed-ignorant value of the distance
to the nearest seed.
That seems to lie firmly in the realm of
under-the-hood-algorithm-masquerading-as-a-function.

As always much interesting stuff to think about, and fun stuff to play with.
RL is being a real bugger lately, so not much povving has been done.

- BW

[William F Pokorny] Re: Suggest v4.0 inbuilt f_catenary(). (yuqk R15... [687 days 11 hours and 36 minutes ago]

Wed, 22 May 2024 08:58:22 GMT

On 5/21/24 11:46, Bald Eagle wrote:
> I don't understand what the pointy curves are - shouldn't they all have rounded
> minima?
> 
Only the upper row, left and center are based on catenary curves.

With the rest I was using results from the other modes to create the 
shapes. IIRC, it's y' (slope) in the upper right. The bottom row being 
arc length, t and angle.

The bottom center - if inverted - is close to the main roof line of the 
Sears & Roebuck barn on the tiny farm where I lived for most of my 
youth. :-)

> ...
> 
> Also for your consideration, it would be useful to have f_bezier or f_bernstein
> for modeling quadratic or cubic curves, and perhaps f_voronoi which would take a
> list of seed values as an argument.

:-)

A somewhat more flexible form of the quilted pattern's 2D 'quilt_cubic' 
is available as an inbuilt in yuqk as f_quilt_cubic(), FWIW. With the 
first two, I'd lean toward adding them as additional splines(a). It 
might be hgpovray38 has these - it supports many additional splines.

The f_voronoi() inbuilt is on my list (with additional metrics). The 
hgpovray38 fork has already some of the voronoi with specified vertices 
functionality already too.

Bill P.

(a) - Or maybe that and plus an inbuilt f_bezier() with two or more 
internal control points..? Suppose where I've implemented inbuilt 
patterns as true inbuilt functions too, I've almost always done this in 
a way that the function is much more flexible with respect to options 
and return values.

[William F Pokorny] Re: Suggest v4.0 inbuilt f_catenary(). (yuqk R15... [687 days 11 hours and 57 minutes ago]

Wed, 22 May 2024 08:36:43 GMT

On 5/21/24 11:12, Cousin Ricky wrote:
> This sounds very useful!

:-) I hope it proves so. It's something to play with in any case.

The approach / form isn't the only possible. I borrowed mostly from 
Wikipedia and my old copy of "The VNR Concise Encyclopedia of 
Mathematics (2nd edition)."

Another approach was used by PM 2RING for his catenary.inc set up 
specifically for chains with definable links. This include might have 
been in the object collection..? My copy of it came by way of a post 
from Thomas a few years ago.

Bill P.

[Bald Eagle] Re: Suggest v4.0 inbuilt f_catenary(). (yuqk R15... [688 days 4 hours and 44 minutes ago]

Tue, 21 May 2024 15:50:00 GMT

William F Pokorny <ano### [at] anonymousorg> wrote:
> In adopting a suggestion from Bill Walker, an implementation of an
> inbuilt f_catenary() function, documentation and an example scene file
> will be included in release R15 of yuqk.
>
> Bill P.

Thanks Bill!   :)

I don't understand what the pointy curves are - shouldn't they all have rounded
minima?

I'm happy that some of these basic curve shapes that are often used in modeling
are being implemented into the source of your fork.

Also for your consideration, it would be useful to have f_bezier or f_bernstein
for modeling quadratic or cubic curves, and perhaps f_voronoi which would take a
list of seed values as an argument.

[Cousin Ricky] Re: Suggest v4.0 inbuilt f_catenary(). (yuqk R15... [688 days 5 hours and 19 minutes ago]

Tue, 21 May 2024 15:15:00 GMT

William F Pokorny <ano### [at] anonymousorg> wrote:
> In adopting a suggestion from Bill Walker, an implementation of an
> inbuilt f_catenary() function, documentation and an example scene file
> will be included in release R15 of yuqk.
>
> Bill P.

This sounds very useful!

[William F Pokorny] Suggest v4.0 inbuilt f_catenary(). (yuqk R15 v0.... [688 days 13 hours and 45 minutes ago]

Tue, 21 May 2024 06:48:50 GMT

In adopting a suggestion from Bill Walker, an implementation of an 
inbuilt f_catenary() function, documentation and an example scene file 
will be included in release R15 of yuqk.

Bill P.

[ingo] Re: POV-Ray is "PIEware" [720 days 8 hours and 39 minutes ago]

Fri, 19 Apr 2024 11:55:00 GMT

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

> A box has 8 corners.  You now have _7_ left.

 ... incomplete thought disclaimer ;) I was doing a quick 2d  visualization.
>
> You're not going to find (all the) holes with that method. Trace suffers from an
> object's (potential) self-occlusion.

Yes that's related to your other question, "what's the box size". Too big and
you miss holes too small and you and you waste cpu ticks.

It would be helpful if we had Roentgen images. Can we create them? Maybe. Fill
the object with an absorbing medium. X-Ray from three sides, but how to analyze
the result? Again, it would be nice if the ray density sampling data could be
written to a file (per object).

But, I think your method, trace, move by epsilon, trace, should work. You'd get
all the object/ empty space transitions. Depending on the goal, instead of
tracing from the camera, you could scan from one surface of the bounding box to
the opposite. Store all intersections in arrays of arrays. For test render each
point as a small sphere.

ingo

[Bald Eagle] Re: POV-Ray is "PIEware" [720 days 9 hours and 49 minutes ago]

Fri, 19 Apr 2024 10:45:00 GMT

"ingo" <nomail@nomail> wrote:

> Would it detect the hole of the doughnut?

"No," because we're only detecting surfaces, but
Yes, because we're doing winding numbers, so you'd be going from the the odd
number of crossings to an even number when you hit the hole.

Picture spearing the doughnut with a bamboo skewer, all the way through.

> Marching cubes should find all cavities in an object.
>
> That brings me to another line of thought. A mesh engine. With the nearly same
> SDL generate mesh' of al POV-Ray objects. Difference would be an added meshify
> keyword with an int for the base resolution of the mesh. A mesh resolution
> multiplier could be set in global_settings so you can make the mesh resolution
> fitting the image resolution.

> Get min-, max_extent of object.
> 1. trace() a corner, lets assume it's a hit.
> 2. At the hit point create a virtual box with the point as center.

Of what size?

> 3. Use the inside() function to test the four corners of the box.

A box has 8 corners.  You now have _7_ left.

> [*]
> Assume one point is inside the object
> 4. Trace from the other corners to the one inside the object to find points on
> thesurface.

You're not going to find (all the) holes with that method. Trace suffers from an
object's (potential) self-occlusion.

> 5.Move the box and repeat. Scan the whole bounding box using cubes.

Marching cubes has a lot to offer, and is definitely something that should be
implemented in parallel to the sort of pseudo-ray-marching method that I
suggested.

Using our primitives vs SDF's necessitates different methods, or at least a
conversion.  I've even looked into generating an SDF from an arbitrary mesh, and
apparently that too is possible with certain software.

[ingo] Re: POV-Ray is "PIEware" [720 days 12 hours and 44 minutes ago]

Fri, 19 Apr 2024 07:50:00 GMT

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

>
> What I'm thinking is that you:
> 1. shoot a ray with trace () from the camera to the World Coordinates that are
> back calculated from the screen pixel position.
> 2. in the event that you get a Hit, you increment the position farther along the
> ray by Epsilon, and initiate a subsequent trace () call.
> 3. repeat until you get <0, 0, 0> for the normal vector.
>

Unfinished thought:

Get min-, max_extent of object.
1. trace() a corner, lets assume it's a hit.
2. At the hit point create a virtual box with the point as center.
3. Use the inside() function to test the four corners of the box.
[*]
Assume one point is inside the object
4. Trace from the other corners to the one inside the object to find points on
thesurface.
5.Move the box and repeat. Scan the whole bounding box using cubes.

[*] Ok it's simplistic and it may require some subdivision of the box before
using trace() or create 4 boxes with the inside point as common corner straight
away.
It may be more efficient to first scan one face of the bounding box with trace()
and start with the cubes from there.

ingo

[ingo] Re: POV-Ray is "PIEware" [720 days 14 hours and 19 minutes ago]

Fri, 19 Apr 2024 06:15:00 GMT

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

> What I'm thinking is that you:
> 1. shoot a ray with trace () from the camera to the World Coordinates that are
> back calculated from the screen pixel position.
> 2. in the event that you get a Hit, you increment the position farther along the
> ray by Epsilon, and initiate a subsequent trace () call.
> 3. repeat until you get <0, 0, 0> for the normal vector.

Would it detect the hole of the doughnut?

Marching cubes should find all cavities in an object.

That brings me to another line of thought. A mesh engine. With the nearly same
SDL generate mesh' of al POV-Ray objects. Difference would be an added meshify
keyword with an int for the base resolution of the mesh. A mesh resolution
multiplier could be set in global_settings so you can make the mesh resolution
fitting the image resolution.

It would make the SDL the heart of the system, from there one can ray trace
solids, or mesh. One could push the mesh to openGL, or use a scan line renderer.

ingo

[Bald Eagle] Re: POV-Ray is "PIEware" [721 days 2 hours and 59 minutes ago]

Thu, 18 Apr 2024 17:35:00 GMT

"ingo" <nomail@nomail> wrote:

> Go, go, go ;) Maybe also get al the bounding boxes (min- max_extent) of the
> object so one does not have to test every ray against every object. But, before
> you know you are writing a ray-tracer within a ray-tracer, within a ray-tracer
> ....

:D  I've already started writing the raytracer within a raytracer to figure out
the inverse transform sampling that clipka wanted for lighting.

> POV-Ray has so many usable internal data that are not available to the user.
> I've manipulated the radiosity proces by rendering an image with the radiosity
> data from an other image. What if we knew the data file format and can
> manipulate it? Or photon data? Normals, intersection points, mirror things, all
> stuff that's available in OpenGL for shaders.

That's a good point.  We have the source, and Bill Pokorny, Jerome Grimbert, and
others have experience in following the internal workings.  We need to find some
more programmers to help the rest of us get up to speed on how it all works and
how to make edits to the code without breaking too much / everything.

> > Also, I've wanted a custom version of trace () that would return ALL of the

> That is difficult as shapes can have all kind of holes and protrusions.

Correct.  Which is why I think your approach might not work, as it seems to be
(unless I'm missing something) just a variation on my many failed past attempts.

What I'm thinking is that you:
1. shoot a ray with trace () from the camera to the World Coordinates that are
back calculated from the screen pixel position.
2. in the event that you get a Hit, you increment the position farther along the
ray by Epsilon, and initiate a subsequent trace () call.
3. repeat until you get <0, 0, 0> for the normal vector.

That seems like a guaranteed method for getting ALL of the surfaces, down to
pixel-level granularity.

And of course, you could go finer if you wanted / needed to.

The bounding box array is a good idea for partitioning / limiting the number of
trace ()- tests for any given ray.

- BE

[ingo] Re: POV-Ray is "PIEware" [721 days 14 hours and 29 minutes ago]

Thu, 18 Apr 2024 06:05:00 GMT

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

> So consider this:
>
> We take my idea of having an object registry, so we can store all of the objects
> in an array, and loop through them.
> Next, we loop through all the y and x of the camera view frustum, and use trace
> ()  to cycle through every object in the registry for every pixel.
> Using that <x, y, z> data, we have a map of the image with a sort of z-buffer.
> Now we write image data perhaps using a format like:
> <x, y, object1_z, . . . , objectN_z>
>
> What do you think?

Go, go, go ;) Maybe also get al the bounding boxes (min- max_extent) of the
object so one does not have to test every ray against every object. But, before
you know you are writing a ray-tracer within a ray-tracer, within a ray-tracer
....

POV-Ray has so many usable internal data that are not available to the user.
I've manipulated the radiosity proces by rendering an image with the radiosity
data from an other image. What if we knew the data file format and can
manipulate it? Or photon data? Normals, intersection points, mirror things, all
stuff that's available in OpenGL for shaders.

> Also, I've wanted a custom version of trace () that would return ALL of the
> intersections with an object, not just the first one, so we could do something
> like custom inside/outside tests using crossing numbers.
> Any idea on how to approach that via SDL that doesn't involve testing dozens of
> thin slices of the object perpendicular to the camera ray?

That is difficult as shapes can have all kind of holes and protrusions. What I
tried in the past is create a "slit camera" that works like a flat bed scanner,
but with the object rotating above the sensor.
https://en.wikipedia.org/wiki/Slit-scan_photography You could rotate such a
camera around the object and inside the object. Or make a point source camera
and scan in a sphere shape, but there will always be "self shadowing". Some of
these must be doable with the advanced camera features.

An other way could be to "shrink wrap" a mesh around an object and use the
vertices, but how in SDL?

ingo

[Bald Eagle] Re: POV-Ray is "PIEware" [721 days 23 hours and 14 minutes ago]

Wed, 17 Apr 2024 21:20:00 GMT

"ingo" <nomail@nomail> wrote:

> During rendering POV-Ray has to know with what
> object a ray intersects. Can these data somehow be saved? Primary intersection,
> secondary intersection?

Damned good idea(s) and something I've thought about and suggested in the past,
however not to the extent of saving the data to a file!

So consider this:

We take my idea of having an object registry, so we can store all of the objects
in an array, and loop through them.
Next, we loop through all the y and x of the camera view frustum, and use trace
()  to cycle through every object in the registry for every pixel.
Using that <x, y, z> data, we have a map of the image with a sort of z-buffer.
Now we write image data perhaps using a format like:
<x, y, object1_z, . . . , objectN_z>

What do you think?

Also, I've wanted a custom version of trace () that would return ALL of the
intersections with an object, not just the first one, so we could do something
like custom inside/outside tests using crossing numbers.
Any idea on how to approach that via SDL that doesn't involve testing dozens of
thin slices of the object perpendicular to the camera ray?

- BE

[ingo] POV-Ray is "PIEware" [722 days 7 hours and 54 minutes ago]

Wed, 17 Apr 2024 12:40:00 GMT

Just some musings, little head or tail,

For some time now I of and on work as a volunteer in a local museum. The big job
to be dome is digitizing the collection, mostly by means of photography. The
whole process has to be reviewed every now and then.

In the workflow we convert RAW images to DNG files. Every operation on the image
is stored as a kind of 'script' in the file and no pixel is changed. From the
script(s) a new image(s) can be rendered. Parametric Image Editing [1]. In a way
POV-Ray is a Parametric Image Editor/Creator, an image is rendered on a set of
rules.

I.i.r.c. POV-Ray' internal resolution(?) and or colour depth is different than
what is written to file. So the ray-tracing part is one set of parameters. The
conversion to the actual image is an other set of, mostly fixed, parameters.

Imagine that we can use something else for the second part. Lets say
ImageMagick. POV-Ray's "internal image" then would be comparable with a raw file
from a camera.

Now we can use ImageMagick to do the conversion to screen ready image. But with
the power of it a lot more can be done. All the processing it can do can be
applied to the RAW part for rendering. You could write a parametric processing
script in your POV-Ray file that is applied after rendering, or you can store it
in the 'RAW image'. You can write multiple processing scripts for different
outputs. You can use the post processing for manipulation of many aspects of the
image.

Can it be pushed even further? During rendering POV-Ray has to know with what
object a ray intersects. Can these data somehow be saved? Primary intersection,
secondary intersection? "RedSphere" is a list of pixels. BlueSphere an other
one. Now we can select pixels by object (-intersection) instead of by colour as
in the Gimp. These pixels can be fed into the post-processor, so we can apply
effects to the red sphere and not to the red box. Can such data be stored in a
DNG file? Or can we finally use SQLite ;) (SQLite as a project container format
could be nice)  Or, even store the whole POV-Ray scene in a DNG as metadata.

An other thought, could it be possible to attach such scripts directly to an
object and modify the object/texture with them while rendering?

[1] https://dpbestflow.org/image-editing/parametric-image-editing

[William F Pokorny] Re: On new directive to stop after parsing. A ne... [723 days 17 hours and 44 minutes ago]

Tue, 16 Apr 2024 02:50:01 GMT

On 4/15/24 13:26, Leroy wrote:
> Great Trick!

Hi Leroy,

I'm glad I stumbled across it. Now that I've got this easier way to test 
ini files and command line flags, I'm finding quite a bit of stuff in 
need of fixing!

Bill P.

[Leroy] Re: On new directive to stop after parsing. A ne... [724 days 3 hours and 4 minutes ago]

Mon, 15 Apr 2024 17:30:00 GMT

William F Pokorny <ano### [at] anonymousorg> wrote:
>
>   povray scene.pov -d -p +wt0
>
> Setting the thread count to zero causes POV-Ray to bail before rendering
> with a clean, 0 return code - so long as nothing is otherwise wrong with
> the scene set up.
>
> It means I've got a better way to run parsing test cases and, should
> anyone want to do it, you can use SDL as a sort of scripting language to
> do other stuff.
>
> The trick works too in v3.8 beta 2 and likely all recent, official
> versions.
>
> Bill P.

-d -p +wt0 works on my win3.7 version just put it in the command box and run
Great Trick!

[William F Pokorny] Re: On new directive to stop after parsing. A ne... [739 days 7 hours and 36 minutes ago]

Sun, 31 Mar 2024 12:57:39 GMT

On 3/31/24 07:32, jr wrote:
> was / am thinking documentation.  it would have been handy to read (at the end
> of 'alltext.out') whether there were warnings and or (non-library) errors.
> 

Short on time this morning. First, remember alltext.out (all_file) is 
just echoing the five other actual console streams to a single file.

The set up was >5 output streams, down to five today. In those five 
there is a warning stream and a fatal / error stream. Those latter two 
do capture all the warnings and errors to files if you set up your run 
that way. Those two files will be empty if all is well and otherwise 
have all the warnings and errors captured by POV-Ray.

We don't count warnings today which is an interesting idea.

> 
>> ...
>> The yuqk fork has a getenv() function ...
> interesting.  what use case do you have in mind ?  (un)set in-scene "flags" ?
> 

Nothing too specific. One thought was to enable POV-Ray to query the 
process environment from which it was called. USER, USERNAME, LANG, 
HOME, ...

I think you are suggesting SDL capability to set and unset environment 
variables too?  If so, I thought about. It is, though, a capability 
which could cause quite a bit of trouble.

> 
>> I don't know how to handle self generated return codes with only one
>> call to the 'povray' executable.
> not sure I understand, the "(a)" above would do though, aiui.

I can look at doing (a). What I do not know at the moment is where 
stdout / stderr are go as compared to where +o- image output goes. I 
suspect, the optional image output is using stdout so I could use stderr 
for the 0, 1 or 2 return codes. If so, zero return code result messages 
would end up on stderr which is a little off.

Anyhow, got to run.

Bill P.

[jr] Re: On new directive to stop after parsing. A ne... [739 days 8 hours and 59 minutes ago]

Sun, 31 Mar 2024 11:35:00 GMT

hi,

William F Pokorny <ano### [at] anonymousorg> wrote:
> On 3/29/24 13:08, jr wrote:
> > can you use BE's "to file" idea ?  ie write the exit / status code as last line
> > when 'all_file=true', perhaps.
>
> I think not reliably from within POV-Ray itself(a).
>
> Some events, like segmentation faults, are being generated by libraries
> in use by POV-Ray and they are, more or less, crashing the program in a
> way the operating system ends up handling.
>
> (a) - The 0, 1, 2 return codes are ones handled by POV-Ray itself and
> these could be written to stderr / cerr prior to exit, but not to one of
> the output streams as defined and handled by POV-Ray.

was / am thinking documentation.  it would have been handy to read (at the end
of 'alltext.out') whether there were warnings and or (non-library) errors.


> ...
> The yuqk fork has a getenv() function ...

interesting.  what use case do you have in mind ?  (un)set in-scene "flags" ?


> I don't know how to handle self generated return codes with only one
> call to the 'povray' executable.

not sure I understand, the "(a)" above would do though, aiui.


regards, jr.

[William F Pokorny] Re: On new directive to stop after parsing. A ne... [740 days 22 hours and 30 minutes ago]

Fri, 29 Mar 2024 22:03:52 GMT

On 3/29/24 13:08, jr wrote:
> can you use BE's "to file" idea ?  ie write the exit / status code as last line
> when 'all_file=true', perhaps.

I think not reliably from within POV-Ray itself(a).

Some events, like segmentation faults, are being generated by libraries 
in use by POV-Ray and they are, more or less, crashing the program in a 
way the operating system ends up handling.

(a) - The 0, 1, 2 return codes are ones handled by POV-Ray itself and 
these could be written to stderr / cerr prior to exit, but not to one of 
the output streams as defined and handled by POV-Ray.

In Unix environments we can today do this:

yuqk boom.pov;echo "yuqk return code is: $?";

or

povray boom.pov;echo "povray return code is: $?";

or

povray boom.pov;export POVRAY_RC=$?;

'yuqk' is really a wrapper script around the yuqk fork's 'povray' 
executable where the last line is 'exit $?' to pass the return code back 
to the calling process. That wrapper could be modified to output to 
always write out a status line with the return code to the terminal - or 
to a file.

The yuqk fork has a getenv() function so you could run another SDL .pov 
file which does something with a YUQK_RC environment variable.

unset YUQK_RC;yuqk boom.pov;export YUQK_RC=$?;yuqk getenv.pov -d -p;

Where getenv.pov contains:

#debug concat("The return code is: ",getenv("YUQK_RC"),"\n")

and then the second yuqk will print: "The return code is: 1".

Rather than a #debug statement, that could be a #write I guess doing 
more stuff based on the value.

I don't know how to handle self generated return codes with only one 
call to the 'povray' executable.

Bill P.

[jr] Re: On new directive to stop after parsing. A ne... [741 days 3 hours and 24 minutes ago]

Fri, 29 Mar 2024 17:10:00 GMT

hi,

William F Pokorny <ano### [at] anonymousorg> wrote:
> ...
> This also works in my yuqk fork, though I doubt whether it will work for
> official POV-Ray releases. Pretending the following is all on one line:
>
> yuqk boom.pov fatal_error_command="echo \"Scene: <%s>
> fatal_error_command. RC: <$?>\""
>
> It uses the fatal_error_command facility of POV-Ray itself. The output
> looks like:
>
> ==== [Parsing...] ==================================================
> File 'boom.pov' line 2:
> Parse Error:
> Parse halted by #error directive: Boom
> Fatal error in parser: Cannot parse input.
> Scene: <boom> fatal_error_command. RC: <0>
> Render failed
>
> However! The return code (RC) reported by the 'fatal command' is not for
> the current running POV-Ray executable, but for the command previously
> run from the terminal, which is currently running the POV-Ray executable.

can you use BE's "to file" idea ?  ie write the exit / status code as last line
when 'all_file=true', perhaps.


regards, jr.

[William F Pokorny] Re: On new directive to stop after parsing. A ne... [742 days 5 hours and 58 minutes ago]

Thu, 28 Mar 2024 14:35:42 GMT

On 3/27/24 19:28, Kenneth wrote:
> Just out of curiosity: Where do these codes show up? Are they 'accessible' to a
> typical (i.e. naive!) computer user in Windows?

Most any place a compute working environment / locale has called a 
executable program, it's the normal to return, 'return codes'. In my 
Ubuntu Linux environment, the calling, work locale is my terminal where 
I type 'povray ...' to call the POV-Ray executable program.

I can look at the return code by looking at a special environment 
variable '?' which holds the return code of the command / program called 
/ run. The '$' prefix extracts the current integer value.

Supposing the file boom.pov contains a single line: #error "Boom",

	yuqk boom.pov
	echo $?

returns something like:

...
=== [Parsing...] ==================================================
File 'boom.pov' line 2:
Parse Error:
Parse halted by #error directive: Boom
Fatal error in parser: Cannot parse input.
Render failed

pokorny:tmp$ echo $?
1

I don't know the equivalent to 'echo $?' in a window's command terminal, 
but I'm sure there is one.

In testing, I'm using the new +wt0 trick and the return code value to 
create bash testing scripts like:

#!/bin/bash
#----------------------------------------------
# Herein running series of POV-Ray (yuqk) commands with good flag usage
# looking for any of them to fail.
#----------------------------------------------

export YUQK_PARSE_ONLY="yuqkA -d -p +wt0"

#---
if $YUQK_PARSE_ONLY version_only.pov >/dev/null 2>&1; then
     echo "Pass case: version_only.pov"
else
     RC=$?
     echo "Pass case: version_only.pov   FAIL  rc=$RC"
     exit $RC
fi

... 179 more tests of good flag usage follow

Bill P.

---
I was curious so played some more... It gets convoluted, please feel 
free to ignore the rest.

This also works in my yuqk fork, though I doubt whether it will work for 
official POV-Ray releases. Pretending the following is all on one line:

yuqk boom.pov fatal_error_command="echo \"Scene: <%s> 
fatal_error_command. RC: <$?>\""

It uses the fatal_error_command facility of POV-Ray itself. The output 
looks like:

==== [Parsing...] ==================================================
File 'boom.pov' line 2:
Parse Error:
Parse halted by #error directive: Boom
Fatal error in parser: Cannot parse input.
Scene: <boom> fatal_error_command. RC: <0>
Render failed

However! The return code (RC) reported by the 'fatal command' is not for 
the current running POV-Ray executable, but for the command previously 
run from the terminal, which is currently running the POV-Ray executable.

The following pile of a command shows how return code values exist in 
two locale environments here. The initial terminal and a second one the 
fatal error command sets up. Again imagine it all on one line:

ls;yuqk boom.pov fatal_error_command="yuqk boom.pov;RC=$?;echo \"boom 2 
RC=$RC\";echo \"Scene: <%s> fatal_error_command. RC: <$RC> and <$?> for 
initial 'ls'\"";

The output is:

...
File 'boom.pov' line 2:
Parse Error:
Parse halted by #error directive: Boom
Fatal error in parser: Cannot parse input.
Render failed

boom 2 RC=1
Scene: <boom> fatal_error_command. RC: <1> and <0> for initial 'ls'
Render failed

Yepper. The fatal error command is running yuqk with boom.pov a second 
time just to capture the eventual return code - which the first running 
version of yuqk has not yet set itself... :-)

[Bald Eagle] Re: On new directive to stop after parsing. A ne... [742 days 9 hours and 39 minutes ago]

Thu, 28 Mar 2024 10:55:00 GMT

"Kenneth" <kdw### [at] gmailcom> wrote:
> Thanks guys. I learned something new!
>
> Just out of curiosity: Where do these codes show up? Are they 'accessible' to a
> typical (i.e. naive!) computer user in Windows?

I would guess that they're completely internal to source.
And once the code exits - the program is terminated.  So it's gone.

But that makes me think about the possibility of writing those values to a file,
or to some sort of shell environment variable.

Then you could parse a scene, exit without rendering, and do some post-parse
processing with a shell command....

[Kenneth] Re: On new directive to stop after parsing. A ne... [742 days 21 hours and 4 minutes ago]

Wed, 27 Mar 2024 23:30:00 GMT

Thanks guys. I learned something new!

Just out of curiosity: Where do these codes show up? Are they 'accessible' to a
typical (i.e. naive!) computer user in Windows?

[Alain Martel] Re: On new directive to stop after parsing. A ne... [743 days 2 hours and 58 minutes ago]

Wed, 27 Mar 2024 17:36:29 GMT

Le 2024-03-26 Ã  13:39, Kenneth a Ã©critÂ :
> William F Pokorny <ano### [at] anonymousorg> wrote:
>> I often stop POV-Ray after parsing by adding an #error directive:
>>
>> #error "Stopping after parse"
>>
>> at the very bottom of some scene description language (SDL) code.
>>
>> It works but, with the disadvantage of setting a non-zero return code;
>> something which makes testing the parser harder.
>>
> 
> What is a 'non-zero return code', and what testing problems(s) does it cause
> when using #error? I confess to complete ignorance of it :-/
> 
> 
> 

A zero return code is an universal way that a procedure use to indicate 
that it finished successfully. Any non-zero value indicate that there 
was some error occurring.

[William F Pokorny] Re: On new directive to stop after parsing. A ne... [743 days 8 hours and 43 minutes ago]

Wed, 27 Mar 2024 11:51:10 GMT

On 3/26/24 13:39, Kenneth wrote:
> What is a 'non-zero return code', and what testing problems(s) does it cause
> when using #error? I confess to complete ignorance of it :-/
Hi.

Programs - like POV-Ray - running within typical compute environments, 
return a final integer value called a return code indicating how 
'things' went.

With POV-Ray it's mostly:

0 - All is well.
1 - Some lessor user-ish exit or abort.
2 - Some more serious problem.

But, you can see other non-zero codes too. This more true in yuqk - 
especially the debug compile.

An #error directive will cause POV-Ray to always return (1). Any testing 
looking for "0 - All is well" (or !0), will always see a problem (or 
not) if looking at just the return code(*) where '#error' the technique 
stopping POV-Ray at the parsing stage.

With yuqk, close the X11 preview window with 'q' while the render is in 
progress and you see a return code of (2).

With yuqk, close the X11 preview window, once the render is finished and 
paused, using the 'x' symbol to close and you see a return code of 
(139). Yes, that's a minor bug.

(*) - You can still check how things ran, but without the return code 
giving you the easy answer up front, it means looking at various outputs 
in some detail and checking whether what you expect to be there is, or 
isn't.

Bill P.

[Kenneth] Re: On new directive to stop after parsing. A ne... [744 days 2 hours and 54 minutes ago]

Tue, 26 Mar 2024 17:40:00 GMT

William F Pokorny <ano### [at] anonymousorg> wrote:
> I often stop POV-Ray after parsing by adding an #error directive:
>
> #error "Stopping after parse"
>
> at the very bottom of some scene description language (SDL) code.
>
> It works but, with the disadvantage of setting a non-zero return code;
> something which makes testing the parser harder.
>

What is a 'non-zero return code', and what testing problems(s) does it cause
when using #error? I confess to complete ignorance of it :-/

[William F Pokorny] v4..0 and yuqk should stop rendering extra pixels. [747 days 10 hours and 56 minutes ago]

Sat, 23 Mar 2024 09:38:27 GMT

What is happening today:

yuqk play.pov -w1500 -h980 +p +am1 +a500.0 +r3 +wt1 +bs1500

........... Image ..... Render ... Added
........... Pixels .... Pixels ... Pixels
........... _______     _______    ______
Method 1 .. 1470000 --> 1472480 .. +0.17% . bs1500
(+am1) .... 1470000 --> 1562560 .. +6.30% . bs32
........... 1470000 --> 1838740 ..+25.08% . b8

Method 2 .. 1470000 --> 1472481 .. +0.17% . bs1500
(+am2) .... 1470000 --> 1564017 .. +6.40% . bs32
........... 1470000 --> 1861864 ..+26.66% . bs8

Method 3 .. 1470000 --> 1470000 .. +0.00% . bs1500
(+am3) .... 1470000 --> 1470000 .. +0.00% . bs32
........... 1470000 --> 1470000 .. +0.00% . bs8

It's a partial - if not complete - answer to questions I've been 
carrying in my head for a long time. Likely, it's led me to a few 
certain incorrect / too-harsh impressions too. For example:

1) Why don't the method 1 and 2 pixels and rays make sense?

2) Why does there seem to be an asymmetric AA bias that I've noticed 
this mostly with method 1 - and blamed it's up and left only threshold 
test.

3) Why does (a completely working) method 3 sometimes run faster than it 
really should compared to method's 1 and 2.

...

---
For those who wish to play at home, you cannot exactly duplicate (or 
even see) all of the result I get with my yuqk fork. You should be able
to do the following while paying attention to the 'Rays:  <count> ' 
rendering output.

Use the following scene:

//---
version 3.8;
global_settings { max_trace_level 1 assumed_gamma 1.0 }
background { rgb 1 }
//---

Then commands like  (I think +a1.0 is illegal in v3.7 -> 0.99) :

p380b2 v38.pov -w1500 -h980 +am1 -a1.0 +r3 +wt1 +bs1500
p380b2 v38.pov -w1500 -h980 +am1 +a1.0 +r3 +wt1 +bs1500
p380b2 v38.pov -w1500 -h980 +am1 +a1.0 +r3 +wt1 +bs8

The silver lining here is that I think we have a decent available 
performance improvement available to us - if, we can figure out how to 
avoid the extra pixels on the thread render block edges (method two has 
an additional corner pixel too). My guess is this comes from an attempt
to re-use already rendered pixels before taking an adaptive step. If 
true, I think this the wrong approach with method 2, for a start, where 
we should just shoot the four corner rays as soon as someone turns on AA 
(Yep, another old question has been: why isn't method 2 better at 
picking up detail than it is..).

Aside: Mixed in, is work clipka did after v3.7 to center the pixel 
positions. IIRC, when AA kicked in they were offset in v3.7 (earlier?) 
by half the pixel size.

Going to be a bit before I dig more here. Real life is keeping me busy 
and this bit a detour from a bunch of other in progress plays with yuqk 
I need to finish. I've got far too many old play/work items going...

Bill P.

[jr] Re: On new directive to stop after parsing. A ne... [754 days 14 hours and 59 minutes ago]

Sat, 16 Mar 2024 05:35:00 GMT

hi,

William F Pokorny <ano### [at] anonymousorg> wrote:
> I often stop POV-Ray after parsing by adding an #error directive:
> ...

v nice, and thank you.  I now have a "cleaner" 'povparse' alias.


regards, jr.

[ingo] Re: On new directive to stop after parsing. A ne... [755 days 13 hours and 29 minutes ago]

Fri, 15 Mar 2024 07:05:00 GMT

William F Pokorny <ano### [at] anonymousorg> wrote:
>[...]
>    povray scene.pov -d -p +wt0
>
>[...], 0 return code - [...]

Ah nice, I always used -d +w0 +h0 -F, but then you get a render failed.

ingo

[William F Pokorny] On new directive to stop after parsing. A near t... [755 days 21 hours and 12 minutes ago]

Thu, 14 Mar 2024 23:22:18 GMT

I often stop POV-Ray after parsing by adding an #error directive:

#error "Stopping after parse"

at the very bottom of some scene description language (SDL) code.

It works but, with the disadvantage of setting a non-zero return code; 
something which makes testing the parser harder.

I've a few times talked about adding a new (SDL) directive like '#exit 
<rc value>', perhaps.

Well, while continuing to work through the ini options and command line 
flags, I stumbled across the following trick. We can effectively run 
just the command line, ini file and scene file parsing with the command:

   povray scene.pov -d -p +wt0

Setting the thread count to zero causes POV-Ray to bail before rendering 
with a clean, 0 return code - so long as nothing is otherwise wrong with 
the scene set up.

It means I've got a better way to run parsing test cases and, should 
anyone want to do it, you can use SDL as a sort of scripting language to 
do other stuff.

The trick works too in v3.8 beta 2 and likely all recent, official 
versions.

Bill P.

[William F Pokorny] The yuqk fork blend_mode 5 and media. [762 days 23 hours and 24 minutes ago]

Thu, 7 Mar 2024 21:09:55 GMT

The blend_modes 4 and 5 were added to the yuqk fork with a set of 
possible applications in mind. Blend mode 5, with blend_gamma settings 
larger than one, uses only the middle of the interpolation segments in a 
map. This capability can be used to define specific colors in media 
aligning in some aspect with functions or patterns.

Given the recent mention of using media to represent probabilities(a), I 
worked up an initial set of media examples related to media in general 
and 'blend_mode 5' which will ship in R13 of the yuqk fork.

Attaching an image of four results and scene files for the upper left 
and lower right sub-images.

Oh! Despite what the header says in blend_mode_5_06.pov, the attached 
version was changed to use the emission media for performance over any 
of the scattering media options.

Versions of the techniques used here can probably be implemented in 
official POV-Ray releases, but I believe much less easily, if so.

Bill P.

(a) Don't forget .df3 density files for this sort of application. Using 
multiple colors for probabilities a little problematic too given the 
differing intensities of the colors themselves - without normalization(s).

https://wiki.povray.org/content/User:Wfpokorny/DensityFile

[William F Pokorny] Re: Suggest v4.0 ripples, waves re-work. (povr R... [767 days 11 hours and 34 minutes ago]

Sun, 3 Mar 2024 08:59:36 GMT

On 3/1/24 09:39, William F Pokorny wrote:
> I found a bug in the defaulting of the ip_scale & ip_fade_distance where 
> only one of the two 'extended options' is specified.

Bugs are fixed in all four sets of code and will be available in the 
next yuqk release (R12).

I played for a while creating isosurfaces using the waves scalar value 
pattern. One of the images I liked is attached.

Bill P.

[William F Pokorny] Re: Suggest v4.0 ripples, waves re-work. (povr R... [769 days 5 hours and 54 minutes ago]

Fri, 1 Mar 2024 14:39:48 GMT

On 3/18/23 09:58, William F Pokorny wrote:
> ripples & waves extended

While working on documentation for the yuqk re-written, four, ripples 
and waves pattern implementations, I found a bug in the defaulting of 
the ip_scale & ip_fade_distance where only one of the two 'extended 
options' is specified.

Likely an 'original sin' so to speak. It might also be something I 
introduced when I re-centered these patterns to be more apparent - to 
work better - on near origin shapes.

In any case, should anyone be playing with these patterns in already 
released versions of the yuqk fork, there be bugs...

Bill P.

[William F Pokorny] Re: On the #version scene language directive. [792 days 6 hours and 56 minutes ago]

Wed, 7 Feb 2024 13:38:07 GMT

On 1/29/24 07:00, William F Pokorny wrote:
> Unfortunately, it looks like the ini / flag defaulting isn't completely 
> there today code wise (the default isn't set correctly(a)). However, I 
> think the ini / flag solution should be the path going forward for v4.0. 
> I intend to adopt the approach for future releases of the yuqk fork.

See related discussion about assumed_gamma and version settings at:

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

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

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

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

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

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

Bill P.

[William F Pokorny] On the #version scene language directive. [801 days 8 hours and 34 minutes ago]

Mon, 29 Jan 2024 12:00:26 GMT

While running down this bug:

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

I ended up reviewing a lot of the version setting code.

For a long time code development was on a path to require #version as 
the very first line of a scene. If you coded:

#declare One = 1.0;
#version 3.7;

you'd get warnings or errors saying something like:

"Parse Error: As of POV-Ray v3.7, the '#version' directive must be the 
first non-comment statement in the scene file. ..."

After the v3.8 release parser code was backed up to an earlier form of 
the parser, this checking coded ended up excluded in, v3.8 beta 2, via 
some hard coding in the source (#if 0 .... #endif). Comments were added 
about the check was a problem because of the +hi include header feature 
for as one issue. Yuqk still issues an error, within the context of the 
newer parser.

In the overall code, it looks like to me, the original intent was the 
default-version / optional-version override when running of 'povray' was 
to be accomplished with 'version=' ini / +mv flag options - which makes 
a lot of sense.

The #version directive in the scene description language being needed 
only when, locally specific, scene language handling was needed. A 
little of this original intent can be seen by running the code above 
with a (v3.8 beta 2) executable and looking at the 'input:' line just 
below the 'Parser Options' header in the output.

povray above.pov version=3.7
<Input file: hmm2.pov (compatible to version 3.70)>

povray above.pov +mv3.8
<Input file: hmm2.pov (compatible to version 3.80)>

povray above.pov
<Input file: hmm2.pov>


Always handling the initial rendering version via ini / flag settings 
solves the 'must be first' problem and the '+hi include file first on 
the fly' problem.

Unfortunately, it looks like the ini / flag defaulting isn't completely 
there today code wise (the default isn't set correctly(a)). However, I 
think the ini / flag solution should be the path going forward for v4.0. 
I intend to adopt the approach for future releases of the yuqk fork.

Putting the #version first still good form. Further, for those already 
doing it, the ini / flag approach will result in no changes at all in 
behavior(b).

Bill P.

(a) - I think things ended up this way for backward compatibility. No 
#version and defaulting going all the way back to 3.6.2.

(b) - Excepting where users making use of +hi.

[William F Pokorny] Re: Better understanding of GitHub issue 377 [803 days 23 hours and 1 minute ago]

Fri, 26 Jan 2024 21:32:55 GMT

On 1/26/24 07:20, Thorsten wrote:
> On 25.01.2024 16:49, William F Pokorny wrote:
>> Aside: As of writing this I'm unsure what happens with render 
>> continuations.Â  If the position in the random number streams are 
>> maintained in the state file, continuations should work without issue. 
>> Otherwise continued renders may well show differences when compared to 
>> renders not stopped and re-started.
> 
> Using a random sampling and then always expecting the same result is a 
> user error, not a bug. The random effects may also depend on the thread 
> settings, block size settings, hardware used, etc. because they are 
> random. As such, clearly not a bug.
> 
> Thorsten
> 
> 

:-) True as written. I agree well enough that I closed the github issue 
once I understood why the partially rendered regions where sometimes 
showing differences.

We should though, avoid setting a universal impression AA jitter should 
be avoided where users want repeatable render to render results. This 
especially true in the very latest yuqk release where the v3.8 method 3 
+ss mechanism has been extended to all three AA methods. Being able to 
use a good jitter and get repeatable results is effectively a new, 
desirable feature.

---
The AA / jitter reality across v3.6 -> v4.0 & my yuqk fork is 
complicated over time - as I think might reasonably be user expectations.

Speaking only of anti-aliasing / jitter affected results...

With the latest yuqk release - so long as +ss is set, the render 
pattern, step size and block size is held constant and we are doing full 
frame renders - results are repeatable no matter the number of threads 
used and no matter whether jitter is used or not (jitter of course 
always on or off).

A similar statement can be made for official releases and (non-buggy) 
method 3 (v3.8+) results using jitter or not. Methods 1 & 2 jitter 
onward in official v3.7 onward are mostly repeatable too (jitter is 
using a static table and jitter defaults on), but here the statement is 
weaker as is the quality of the AA when jitter is on.

Users expecting that a partially rendered region of a frame should match 
the same region when the frame is fully render isn't that much of a 
stretch, if they are seeing frame to frame repeatability. The same true 
for renders stopped and restarted via state files - though again, I 
don't myself know what is or is not happening with continued renders 
with respect to jitter / method 3(a).

Bill P.

(a) - If the continuations start after the last full block rendered in 
the context of the an identically ordered (and block numbered) render 
pattern, probably things work fine.

[Thorsten] Re: Better understanding of GitHub issue 377 [804 days 8 hours and 14 minutes ago]

Fri, 26 Jan 2024 12:20:33 GMT

On 25.01.2024 16:49, William F Pokorny wrote:
> Aside: As of writing this I'm unsure what happens with render 
> continuations.Â  If the position in the random number streams are 
> maintained in the state file, continuations should work without issue. 
> Otherwise continued renders may well show differences when compared to 
> renders not stopped and re-started.

Using a random sampling and then always expecting the same result is a 
user error, not a bug. The random effects may also depend on the thread 
settings, block size settings, hardware used, etc. because they are 
random. As such, clearly not a bug.

Thorsten

[William F Pokorny] Better understanding of GitHub issue 377 [805 days 4 hours and 44 minutes ago]

Thu, 25 Jan 2024 15:49:36 GMT

Better understanding of GitHub issue 377 regarding partial render
differences as compared to full renders.

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

https://news.povray.org/povray.binaries.images/thread/%3Cweb.5d07acb1d24138982bedecc40%40news.povray.org%3E/

(Unable to update the thread above due corruption from server crash some
ago)

The differences highlighted in the forum post and issue above come down
to jitter values both as external settings to antialiasing(AA) and
internal random sampling (a kind of jitter too) part of method 3's AA
algorithm.

All three methods are exposed to differences on partial renders when AA
jitter is on. Method three is always exposed because internally it uses
a random number stream to generate the samples even when the
Stochastic_Seed=n / +SSn is used.

Excepting AA method 3, turning off jitter solves the full to partial
render difference issues.

---
With jitter on and always with method three the following helps reduce
the full render pixel to partial render pixel differences:

a) A smaller threshold value (and method 3 also confidence value).

b) Colors matter because the threshold difference is based on a
calculated grey equivalent.

c) The new to yuqk minimum sample depth via Antialias_Min_Depth=n ini /
+RMn settings help when >0.

d) The yuqk fork no longer use a fixed table in methods 1 and 2 when
jitter is on. This method tends to be less sensitive to partial vs full
renders, but this statement depends quite a lot on the block sizes and
ordering used on the partial rendering versus the full rendering.

e) Method 3 will always be exposed to differences on partial renders
versus full renders.

f) Method 2 (with jitter) the least exposed because of how is so
drastically shrinks the non zero jitter value on depth/+r. Yes, it's
also true the deeper the depth/+r settings with both methods 1 & 2 the
less likely partial render to full render differences will show up.

g) Related to (f) the partial to full render differences are more likely
to show up where yuqk's big jitter value is larger than 1.0.

Aside: As of writing this I'm unsure what happens with render
continuations. If the position in the random number streams are
maintained in the state file, continuations should work without issue.
Otherwise continued renders may well show differences when compared to
renders not stopped and re-started.

Bill P.

[William F Pokorny] Suggest moving AA methods 1 & 2 jitter to stocha... [814 days 10 hours and 5 minutes ago]

Tue, 16 Jan 2024 10:29:22 GMT

With the yuqk fork, moved the jitter option of AnitAlias(AA) methods 1 & 
2 to the same stochastic random number generator used already with 
method 3 (boost::mt19937 2d double). Updates should be in R11 v0.6.5.0.

With this update, comes the ability to use Stochastic_Seed=n / +SSn with 
yuqk's methods 1 & 2 jitter for render to render stability.

The yuqk fork has for some years run method 1&2 jitter again with random 
2D vectors. This matching earlier POV-Ray behavior and the jitter 
default is again off. See previous posts about the fixed set of jitter 
samples currently in use with v3.7/v3.8 having shortcomings. Basically, 
+-j with v3.7 / v3.8 is different, but only 'maybe' better or worse with 
or without jitter for any given scene.

Lastly, enabled big jitter with method 3 too. Unlike methods 1 & 2 it is 
not scaled smaller on the AA depth (+r). So, for sampling bleeding 
slightly into adjacent pixels, use say, +j1.1. In other words, with 
method 3 it's a scaling factor applied to the random sampling that is 
'always' done over the entire square pixel with method 3.

Bill P.

[William F Pokorny] Re: More on jitter. The yuqk fork and ideas for ... [818 days 18 hours and 1 minute ago]

Fri, 12 Jan 2024 02:33:00 GMT

On 1/11/24 17:22, William F Pokorny wrote:
> I'll ponder & perhaps play with your idea in code.

Well, I'm surprised. Your idea works well for somewhat complicated 
reasons(a) over just setting the threshold to 0.0 in method 1 - where we 
need to force more samples(b). Thanks for the prompt!

(a) - My guess is we might be a little more exposed to left top 
directional artifacts on using min depth.

(b) - In scenes where we were almost always sub-sampling already the use 
of +rm is slightly slower because we sometimes force sampling where the 
threshold alone wouldn't have / didn't need to.

Attached more or less equivalent images (less random jitter) both using 
method 1. Th difference image shown on the right. The left column image 
is using:

yuqkB hmmAA.pov +w400 +h400 +d +p +am1 +a0.035 +rm4 +r6 +j1.33

and the samples / pixel come in at: 19.05

The middle column image is using:

yuqkB hmmAA.pov +w400 +h400 +d +p +am1 +a0.0 +r6 +j1.33

and the samples / pixel come in at: 33.80

I'm a little tired to finish off the commit and documentation tonight. I 
plan to tackle it tomorrow - extending the AA min depth option to method 
1 as well.

Bill P.

[William F Pokorny] Re: More on jitter. The yuqk fork and ideas for ... [818 days 22 hours and 12 minutes ago]

Thu, 11 Jan 2024 22:22:00 GMT

On 1/11/24 15:48, Cousin Ricky wrote:
> Method 1 is adaptive in a minimal way:  If a pixel is not determined to require
> anti-aliasing, it is not sub-sampled at all.  That is, unless this was changed
> in POV-Ray 3.7, and the reference manual had not been updated to reflect the
> change.  I did notice that 3.7 does a better job of method 1 anti-aliasing than
> 3.6 did, but it still doesn't appear to sub-sample every pixel.
> 
> Perhaps +AM1 +RMn can specify the sub-sampling depth for any pixel that is not
> selected for anti-aliasing under the old algorithm.

Hmm... Yeah. I guess up front I was thinking if folks wanted to force 
the sub-sampling with method 1 they could specify a threshold of 0. I'll 
ponder & perhaps play with your idea in code.

I confess to seldom using method 1 due the left / top directional bias.

Bill P.

[William F Pokorny] Re: More on jitter. The yuqk fork and ideas for ... [818 days 22 hours and 31 minutes ago]

Thu, 11 Jan 2024 22:03:19 GMT

On 1/11/24 11:08, Bald Eagle wrote:
> Nice results ðŸ™‚
> 
> This reminded me of something I stumbled upon, and maybe it will help you come
> up with some more sophisticated methods.

Thanks - and thanks for the links. :-)

Bill P.

[Cousin Ricky] Re: More on jitter. The yuqk fork and ideas for ... [818 days 23 hours and 44 minutes ago]

Thu, 11 Jan 2024 20:50:00 GMT

William F Pokorny <ano### [at] anonymousorg> wrote:
>
> Added Antialias_Min_Depth=n ini / +RMn flag option for antialias methods
> 2 and 3(a). It can be thought of as a way to implement initial
> non-adaptive AA sampling - better at resolving detail - prior to
> adaptive AA. Will be available in R11 v0.6.5.0.

This sounds like a great feature for official POV!

> Aside: Method 1 is not adaptive so there is no point in specifying a
> minimum Antialias depth. The depth value is the number of steps in x and y.

Method 1 is adaptive in a minimal way:  If a pixel is not determined to require
anti-aliasing, it is not sub-sampled at all.  That is, unless this was changed
in POV-Ray 3.7, and the reference manual had not been updated to reflect the
change.  I did notice that 3.7 does a better job of method 1 anti-aliasing than
3.6 did, but it still doesn't appear to sub-sample every pixel.

Perhaps +AM1 +RMn can specify the sub-sampling depth for any pixel that is not
selected for anti-aliasing under the old algorithm.

[Bald Eagle] Re: More on jitter. The yuqk fork and ideas for ... [819 days 4 hours and 24 minutes ago]

Thu, 11 Jan 2024 16:10:00 GMT

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

Nice results :)

This reminded me of something I stumbled upon, and maybe it will help you come
up with some more sophisticated methods.

https://bgolus.medium.com/the-best-darn-grid-shader-yet-727f9278b9d8

http://iquilezles.org/articles/filtering/
https://iquilezles.org/articles/filterableprocedurals/
https://iquilezles.org/articles/checkerfiltering/


- BW

[William F Pokorny] Re: More on jitter. The yuqk fork and ideas for ... [819 days 11 hours and 57 minutes ago]

Thu, 11 Jan 2024 08:36:50 GMT

On 11/1/23 06:07, William F Pokorny wrote:
> I've added to my yuqk fork to do list some ability to specify a minimum 
> recursive AA depth in addition to the maximum one. Thinking the options 
> and flag would be Antialias_Min_Depth=n and +RMn, respectively.

Added Antialias_Min_Depth=n ini / +RMn flag option for antialias methods 
2 and 3(a). It can be thought of as a way to implement initial 
non-adaptive AA sampling - better at resolving detail - prior to 
adaptive AA. Will be available in R11 v0.6.5.0.

The attached image shows method 2 in the left column and method 3 in the 
right column. The top row is what we get today without the ability to 
initially force a minimum number of samples. The bottom row uses a 
Antialias_Min_Depth of two and the results are substantially better for 
both methods 2 and 3.

Method 2
--------
yuqk hmmAA.pov +w400 +h400 +am2 +a0.035      +r6 +j3.33
yuqk hmmAA.pov +w400 +h400 +am2 +a0.035 +rm2 +r6 +j3.33

Method 3
--------
yuqk hmmAA.pov +w400 +h400 +am3 +a0.035 +ac0.9      +r6 +ss12345
yuqk hmmAA.pov +w400 +h400 +am3 +a0.035 +ac0.9 +rm2 +r6 +ss12345

Credit Ton for the test scene from an issue report some years ago.

Aside: Method 1 is not adaptive so there is no point in specifying a 
minimum Antialias depth. The depth value is the number of steps in x and y.

(a) - Reminder the yuqk fork has method 3 fixes which are not in any 
official POV-Ray release. Fixes which in part prevent the implementation 
from sometimes running in a non-adaptive manner; Where results look 
good, but at the expense of the maximum number of samples specified by 
+r being taken.

[Bald Eagle] Semicolon required for successful array definiti... [869 days 18 hours and 19 minutes ago]

Wed, 22 Nov 2023 02:15:00 GMT

So, I'm coding some macros to experiment with some recent discussion topics (as
a break from the many many functions, etc in the wood texture project)

and I needed an array of triangle vertices.

So I have a 2D array, number of triangles and 3 vertices each.
Then I have the name of the array as a standalone line at the end of the macro
to "export" the array to the global environment when the assignment is made.

POV-Ray doesn't like that, and thinks the array name hasn't been declared yet.
When I end the array declaration with a semicolon, suddenly it's alright.

Seems something is wonky there in the parser (3.8).

 - BW

[Bald Eagle] Re: On surface normal calculation and perturbation [876 days 19 hours and 44 minutes ago]

Wed, 15 Nov 2023 00:50:00 GMT

So, one of the things that I noticed, looking at this with fresh eyes, is that
I'm probably not doing the whole

ki * f (p + h*ki)

part correctly.

I'm not sure how to take a simple function like f(x) = sin (x) and plug a vector
into that.

do I just use the x components of the ki vectors?

I'm getting errors for trying to normalize a zero-length vector that way...

[Bald Eagle] Re: On triangle and smooth_triangle shapes. [877 days 1 hour and 59 minutes ago]

Tue, 14 Nov 2023 18:35:00 GMT

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

> I need to better understand the gradient calculation method(a)

> (a) There is a similar method used to calculate isosurface normals.

No ...  if you're talking about the

* FUNCTION
*
*   IsoSurface_Normal

in isosurface.cpp, in source/core/shapes,

that looks like just regular old forward-difference to calculate a function
gradient.

> > https://news.povray.org/5c45e632%241%40news.povray.org
>
> I don't remember reading that particular post - thanks.

Certainly.  I stumbled across it while trying to find one of my other posts.

- BW

[William F Pokorny] Re: On triangle and smooth_triangle shapes. [877 days 8 hours and 49 minutes ago]

Tue, 14 Nov 2023 11:45:14 GMT

On 11/13/23 07:12, Bald Eagle wrote:
> While you're in there digging around in the normal code,  perhaps you can make
> some notes about exactly HOW that all works.  Normals seem to me like they'd
> need a 2D modification (theta, r) rather than just a single scalar value.
> That whole weird tetrahedron thing....

Digging again into that code is something on my list, but it's not at 
the top at the moment.

I need to better understand the gradient calculation method(a) - or 
replace it - to understand, for example, what is happening with that 
experimental facets pattern when I set the accuracy setting really large 
compared to the value region dimensions. I don't get at all why results 
become smoother. I have some wild guesses(b), but they are wild. I have 
longer standing questions / issues with it too with the sampling pattern.

(a) There is a similar method used to calculate isosurface normals.

(b) My up front one is that the accuracy value is getting used, 
intentionally or not, to inverse scale the effect of the perturbation - 
before it can be scaled with the bump_size value. In other words, there
'might be' a missing normalization of the resultant gradient value. 

> 
> https://news.povray.org/5c45e632%241%40news.povray.org

I don't remember reading that particular post - thanks.

I had the thought while reading it, we often are too brief when 
discussing how scalar values can get to the normal{} mechanism. I have 
the follow parser test case which might help as sort of a guide:

// Patterns, pigments with normals

#declare Pig = pigment { bumps }
#declare Nrm = normal { bumps }

#declare Fn0 = function { pattern { bumps } }
#declare Nr0 = normal { function { Fn0(x,y,z) } }
#declare Fn1 = function { pigment { bumps } }
#declare Nr1 = normal { function { Fn1(x,y,z).red } }
#declare Nr1 = normal { function { Fn1(x,y,z).grey } }
#declare Nr2 = normal { pigment_pattern { bumps } }
#declare Nr3 = normal { pigment_pattern { Pig } }

// The following fail today with parsing errors though perhaps
// they should not?
//  #declare Nr4 = normal {
//      pigment_pattern { pigment { bumps } }
//  }
//  #declare Nn5 = normal {
//      pigment_pattern { pigment { Pig } }
//  }
//  #declare Nn6 = normal { pattern { bumps } }

#error "Parse test. Stopping early"

As a guide for POV-Ray proper would need an example overriding the 
default pattern color_maps. The yuqk for doesn't have default color_maps 
except for the block patterns).

> 
> I also had a link to an external site/article, but can't find it atm.

If it's the one you gave me, I have it somewhere in your folder.

> 
> A useful pattern would be something that would allow a function to return the
> normal as a vector (and doesn't require the prior existence of an object surface
> to work).

The special pattern(s) I have in mind to implement will certainly be 
returning vectors. Specifically three 21 bit floats in the double scalar 
value return space - something which will work with today's pattern 
mechanism.

> 
> Also reminds me of the problem I still have to solve/work-around here:
>
https://news.povray.org/povray.unofficial.patches/thread/%3C60a268da%241%40news.povray.org%3E/

I should get back to some of these ideas once in a while :-).

Bill P.

[Bald Eagle] On surface normal calculation and perturbation [877 days 18 hours and 4 minutes ago]

Tue, 14 Nov 2023 02:30:00 GMT

So, William Pokorny's recent experiments / bug eradication in the yuqk fork
reminded me of a discussion we had about 2 years ago concerning POV-Ray's
internal handling of surface normals, and how they get perturbed by the various
normal patterns.

clipka briefly touched on this:
https://news.povray.org/povray.general/message/%3C5c45e632%241%40news.povray.org%3E/#%3C5c45e632%241%40news.povray.org%
3E

"When plugging in a pattern into a normal, the normal is computed by
first sampling the pattern at four points in 3D space, from that
computing the gradient of the pattern in 3D space, and from that
computing how to perturb the normal. The four samples are always taken
at fixed offsets relative to the intersection points, distributed in a
tetrahedral arrangement."

But I'm still mystified how applying a scalar value to a normal (vector) changes
the direction of the normal. This is apparently the basis of how surface
normals are simulated in the raytracer, but neither myself nor WFP exactly
understand how it all works. All the vectors sum to <0, 0, 0>, and we can't
seem to determine where the anisotropy gets introduced.

In trying to figure this out, I stumbled upon:

https://iquilezles.org/articles/normalsSDF/

Which attempts to explain it a bit too briefly, but the result seems to be that
after terms cancel, one gets directional gradients of the function, the vector
sum of which is the normal vector to the surface.

I was unable to find any other mention of this method, so I have an email out
trying to find the origin of this technique, and hopefully the
technical/mathematical details of how it works.

Maybe TOK has the key to this. :)

I hastily scribbled out a scene that uses the method to compute the normal of a
simple sine-wave function, and plots the normal vectors on the surface. It
seems like it mostly works, but some of the normals are wrong.
(it almost seems like if the sides of the valleys were switched, and the signs
of the normals were reversed, then the wrong normals would be corrected)
I'll have to superimpose a trace () result onto this for comparison.

Rendering a visualization of the tetrahedral vectors and coloring them by vertex
coordinates suggested that 3 of the vectors are pseudo-cardinal vectors, and the
remaining vector is the inverse of their vector sum. (Center cube)

Shifting the reference point/origin to <-1, -1, -1> shows what I mean. (Right
cube)

I don't presently know what that all means, but hopefully it spurs some ideas.

Some interesting additional reading on normal related topics:

https://blog.selfshadow.com/publications/blending-in-detail/

https://j3l7h.de/talks/2008-02-18_Care_and_Feeding_of_Normal_Vectors.pdf

[William F Pokorny] Re: On triangle and smooth_triangle shapes. [878 days 5 hours and 40 minutes ago]

Mon, 13 Nov 2023 14:54:08 GMT

On 11/13/23 08:45, William F Pokorny wrote:
> The complication is the mesh / mesh2 parsing is different and I'm not 
> yet sure if things all work the same way there. I'll have to dig some more.

It appears the mesh / mesh2 code was already working as yuqk's 
smooth_triangle was just updated to work - except there are no 
degenerate warnings for the normal cases considered degenerate by 
smooth_triangle.

Think I'll leave it as is for now. If there are many triangles people 
are going to use mesh / mesh2 anyhow.

Bill P.

[William F Pokorny] Re: On triangle and smooth_triangle shapes. [878 days 6 hours and 49 minutes ago]

Mon, 13 Nov 2023 13:45:24 GMT

On 11/12/23 22:36, William F Pokorny wrote:
> I've already modified the yuqk aoi pattern to work with the full range 
> -1 to +1 possible perturbed normals. I should try that now actually on 
> the black ones... Ah, it didn't offer clue why things go black in the 
> degenerate case - things are still black.
> 
> I'll need to do some debugging I guess.

Alright. What is happening is the code marks degenerate triangles with 
an internal flag setting that they are degenerate.

This flag setting gets tested during most operations including the 
ray->triangle intersection code, where it immediately returns with no 
intersections. (The bounding box intersections still happen, if those 
are active with the active bounding)

Doing this where the specified normals are the only reason it is being 
considered degenerate would be wrong for mesh inside testing - and I 
think too conservative generally. Those mesh inside tests care not a 
whit about normals, but dropping intersections will certainly create 
problems.

The complication is the mesh / mesh2 parsing is different and I'm not 
yet sure if things all work the same way there. I'll have to dig some more.

With respect to the smooth_triangle, what I've done in the yuqk fork is 
modify the code so that, where the specified normals are the reason a 
triangle is considered degenerate, we still get the warning messages 
from the parser, but the triangle degenerate flag is no longer set.

Updated image of the new behavior is attached.

Bill P.

[Bald Eagle] Re: On triangle and smooth_triangle shapes. [878 days 8 hours and 19 minutes ago]

Mon, 13 Nov 2023 12:15:00 GMT

William F Pokorny <ano### [at] anonymousorg> wrote:
> On 11/12/23 22:09, Bald Eagle wrote:
> > I'm guessing that you'll likely have to implement some debugging capability to
> > output or make visible the normal vectors.
>
> As always. Thanks for the references! Yes, related.

You're welcome.   And thanks for confirming.

> Yes, your debugging capability for normals. It's been on my todo list
> for a while. I plan to implement it as a special pattern so I can return
> the perturbed normals in addition to the raw normals.
>
> I've already modified the yuqk aoi pattern to work with the full range
> -1 to +1 possible perturbed normals. I should try that now actually on
> the black ones... Ah, it didn't offer clue why things go black in the
> degenerate case - things are still black.
>
> I'll need to do some debugging I guess.

While you're in there digging around in the normal code,  perhaps you can make
some notes about exactly HOW that all works.  Normals seem to me like they'd
need a 2D modification (theta, r) rather than just a single scalar value.
That whole weird tetrahedron thing....

https://news.povray.org/5c45e632%241%40news.povray.org

I also had a link to an external site/article, but can't find it atm.

A useful pattern would be something that would allow a function to return the
normal as a vector (and doesn't require the prior existence of an object surface
to work).

Also reminds me of the problem I still have to solve/work-around here:
https://news.povray.org/povray.unofficial.patches/thread/%3C60a268da%241%40news.povray.org%3E/

Speaking of functions, I just threw up my hands and gave up on converting a
"simple" shader, because trying to convert that into SDL with functions blows up
into over 1000 lines of bloated code.  As you know, there's a long list of
things that make the function parser unusable in such circumstances, so I won't
get into it .... here.   ;)

- BW

[William F Pokorny] Re: On triangle and smooth_triangle shapes. [878 days 16 hours and 58 minutes ago]

Mon, 13 Nov 2023 03:36:22 GMT

On 11/12/23 22:09, Bald Eagle wrote:
> I'm guessing that you'll likely have to implement some debugging capability to
> output or make visible the normal vectors.

As always. Thanks for the references! Yes, related.

Yes, your debugging capability for normals. It's been on my todo list 
for a while. I plan to implement it as a special pattern so I can return 
the perturbed normals in addition to the raw normals.

I've already modified the yuqk aoi pattern to work with the full range 
-1 to +1 possible perturbed normals. I should try that now actually on 
the black ones... Ah, it didn't offer clue why things go black in the 
degenerate case - things are still black.

I'll need to do some debugging I guess.

Bill P.

[Bald Eagle] Re: On triangle and smooth_triangle shapes. [878 days 17 hours and 24 minutes ago]

Mon, 13 Nov 2023 03:10:00 GMT

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

> The bottom two rows are an open question for me. These rows are
> duplicates of the middle two rows except I invert one (or it can be two)
> of the normals. This does cause a degenerate triangle warning, but I
> suddenly get a black result - why the latter? My naive thought is if bad
> normals are the reason for the degenerate condition, the normals should
> all be ignored and the ccw or cw order used instead. I think we should
> get the interior or exterior texture no matter how mangled the normals.

It looks like you might be running into what I discovered here: ?

http://news.povray.org/povray.advanced-users/thread/%3Cweb.5f763c8daf8e23f91f9dae300%40news.povray.org%3E/

I'm guessing that you'll likely have to implement some debugging capability to
output or make visible the normal vectors.

If the normal vector is <0, 0, 0> does that result in a degenerate triangle?
If the normal is zero, very small, or perpendicular to the triangle surface,
wouldn't that result in a black/non-visible triangle?

You might try rendering arrows for the vertex and face normals, and show
warnings/symbols for <0, 0, 0> or <(<threshhold), (<threshhold), (<threshhold)>
normal vectors, and see what that gives you.

Rendering problematic triangles individually, and mapping the surface normals by
interpolating the vertex normals across the face might reveal something wonky
that's hard to do in any other way.

See the excellent link that TOK posted:
https://codeplea.com/triangular-interpolation

- BW

[William F Pokorny] Overly, token hungry, parser. [878 days 17 hours and 28 minutes ago]

Mon, 13 Nov 2023 03:06:35 GMT

Because I've been playing a lot with overly, token hungry, parser issues 
of late, I inserted a couple of texture ID declares smack in the middle 
of the triangle definition in a scene posted to this newsgroup just 
prior. BOOM, CRASH, BANG!!! There too semicolons are absolutely 
necessary for the parser to not get confused, but the parser issues nary 
a word on the actual problem.

Once it is overeating tokens and confused, we can get all sorts of odd 
error / warning messages depending on what SDL follows those 
definitions. Anything from not a peep to whatever. It depends on what 
tokens end up getting eaten and what remains once the parser rights itself.

The overeating condition has too the bad side effect of, occasionally, 
eating warnings and errors the parser code actually did try to issue.

The problem is there all the way back to v3.7 at least - and it looks to 
be a lot more of a general problem than I thought. Guess I've mostly 
missed this 'elephant in the room' issue.

My habit is to pre-declare almost everything as IDs (sometimes as 
macros) in a stand alone / non-mingled way. Thereafter I reference IDs 
while building larger things, which often are assigned to IDs too.

Suppose people who inline most everything as raw SDL code will mostly be 
OK too - will avoid the overeating.

On typos / mistakes, though, we are all exposed confusing results or 
feedback from the parser when it gets overly token hungry. :-(

Having just implemented better vector related checking for lack of 
semicolons, I think a general solution is unlikely in any v3.8 offering 
- but I'll let the thought bounce around a while.

We should be sure we don't carry this issue to v4.0 in any case!

Bill P.

[Mike Miller] Re: On triangle and smooth_triangle shapes. [878 days 17 hours and 34 minutes ago]

Mon, 13 Nov 2023 03:00:00 GMT

William F Pokorny <ano### [at] anonymousorg> wrote:
> In the binary images forum there has recently been discussion related to
> triangles and meshes as sprite surfaces representing plants.
>
>
https://news.povray.org/povray.binaries.images/thread/%3Cweb.654efeced2ab8e2ef22cdb33dabc9342%40news.povray.org%3E/
>
> I've had on my yuqk to do list a partly finished triangle /
> smooth_triangle sample scene / test case. Scene file and image attached.
> The scene file in this case runs back to v3.7 so long as the version
> gets set on the command line with +mv3.7 or +mv3.8.
>
> In the image there are six columns. Left two are v3.7. Middle two
> v3.8b2. Right two yuqk.
>
> The top two rows are just triangle{}s and the ccw or cw order relative
> to the incoming ray (the camera ray here) in which the corners are
> specified sets the surface normal direction. The ccw order points back
> toward the 'z' ortho camera.
>
> For the triangles there is always both an texture and an
> interior_texture specified with an emission 1.0 finish.
>
> The middle two rows are smooth-triangle{}s. In the left column of each
> column pair the specified normals all point back at the camera. In the
> right column of each column pair the specified normals all point away
> from the camera. If normals are specified, it looks like the corner
> order specification does not matter.
>
> The bottom two rows are an open question for me. These rows are
> duplicates of the middle two rows except I invert one (or it can be two)
> of the normals. This does cause a degenerate triangle warning, but I
> suddenly get a black result - why the latter? My naive thought is if bad
> normals are the reason for the degenerate condition, the normals should
> all be ignored and the ccw or cw order used instead. I think we should
> get the interior or exterior texture no matter how mangled the normals.
>
> Bill P.
>
> ---
> Aside (1) not directly triangle related, but shown in the scene file:
>
> The sample scene has some stuff in it related to open questions about
> finish{} texture updates - applying to pigment{}, normal{} updates too.
>
> One of the cool things about the original Scene Description Language
> (SDL) approach was that more often we could update aspects of already
> defined things.
>
> With an object's texture, if in some later placement / use, we want to
> tweak the finish we just write:
>
> object { Widget12 finish { ... } translate ToMoon }
>
> However, when the interior_texture{} capability was introduced, this
> sort of blind update capability of an aspect of the object's original
> interior_texture was not implemented.
>
> The only way to make a 'partial' interior_texture{} update to a
> particular instance of something with an interior_texture{} is to
> re-specify the entire interior_texture. This method is, of course, ugly.
> Especially true if the object's texture is not accessible as a defined
> ID. There we basically have to unravel the inline interior_texture{} to
> be to replicate the whole of it, so we can update just the finish{}
> aspect.

Thanks' so much for all the info. I'll study the scene file for a closer look.
Mike

[William F Pokorny] On triangle and smooth_triangle shapes. [878 days 17 hours and 50 minutes ago]

Mon, 13 Nov 2023 02:43:57 GMT

In the binary images forum there has recently been discussion related to
triangles and meshes as sprite surfaces representing plants.

https://news.povray.org/povray.binaries.images/thread/%3Cweb.654efeced2ab8e2ef22cdb33dabc9342%40news.povray.org%3E/

I've had on my yuqk to do list a partly finished triangle /
smooth_triangle sample scene / test case. Scene file and image attached.
The scene file in this case runs back to v3.7 so long as the version
gets set on the command line with +mv3.7 or +mv3.8.

In the image there are six columns. Left two are v3.7. Middle two
v3.8b2. Right two yuqk.

The top two rows are just triangle{}s and the ccw or cw order relative
to the incoming ray (the camera ray here) in which the corners are
specified sets the surface normal direction. The ccw order points back
toward the 'z' ortho camera.

For the triangles there is always both an texture and an
interior_texture specified with an emission 1.0 finish.

The middle two rows are smooth-triangle{}s. In the left column of each
column pair the specified normals all point back at the camera. In the
right column of each column pair the specified normals all point away
from the camera. If normals are specified, it looks like the corner
order specification does not matter.

The bottom two rows are an open question for me. These rows are
duplicates of the middle two rows except I invert one (or it can be two)
of the normals. This does cause a degenerate triangle warning, but I
suddenly get a black result - why the latter? My naive thought is if bad
normals are the reason for the degenerate condition, the normals should
all be ignored and the ccw or cw order used instead. I think we should
get the interior or exterior texture no matter how mangled the normals.

Bill P.

---
Aside (1) not directly triangle related, but shown in the scene file:

The sample scene has some stuff in it related to open questions about
finish{} texture updates - applying to pigment{}, normal{} updates too.

One of the cool things about the original Scene Description Language
(SDL) approach was that more often we could update aspects of already
defined things.

With an object's texture, if in some later placement / use, we want to
tweak the finish we just write:

object { Widget12 finish { ... } translate ToMoon }

However, when the interior_texture{} capability was introduced, this
sort of blind update capability of an aspect of the object's original
interior_texture was not implemented.

The only way to make a 'partial' interior_texture{} update to a
particular instance of something with an interior_texture{} is to
re-specify the entire interior_texture. This method is, of course, ugly.
Especially true if the object's texture is not accessible as a defined
ID. There we basically have to unravel the inline interior_texture{} to
be to replicate the whole of it, so we can update just the finish{}
aspect.

[William F Pokorny] Re: More on jitter. The yuqk fork and ideas for ... [890 days 10 hours and 15 minutes ago]

Wed, 1 Nov 2023 10:19:10 GMT

On 11/1/23 06:07, William F Pokorny wrote:
> The 'lines' in the attached image have been fattened with a big jitter 
> rather than by increasing the radius of the cylinders. I believe this 
> will lead to better looking thumbnails for images of this type - FWIW.

:-) Well, my thinking there was certainly not as right as I'd hoped with 
respect to the POV-Ray web site's thumbnail mechanism!

Bill P.

[William F Pokorny] More on jitter. The yuqk fork and ideas for v4.0. [890 days 10 hours and 26 minutes ago]

Wed, 1 Nov 2023 10:07:46 GMT

The yuqk fork returned to truly random jitter where the default of 
jitter is off rather than the official V3.7 onward POV-Ray code where 
antialiasing (AA) methods 1 and 2 jitter is always on - and any 
randomness is predictive, but not purely gridded.

Further, it allows the jitter-ing to bounce outside the pixel - or bleed 
into adjacent pixels - where the jitter amounts are >1.0. This ability 
has thus far been called 'big jitter'.

I've now had some years playing with the 'improved jitter' in the yuqk 
fork and while the yuqk fork is certainly more flexible, the results are 
not always better depending upon the measure of goodness.

Using the Pursuit Curve code from Kurtz le pirate which was recently 
posted on the POV-Ray forums, I've made an attempt to better formalize 
some rough AA rules for using random/big jitter. See those rules below.

I've added to my yuqk fork to do list some ability to specify a minimum 
recursive AA depth in addition to the maximum one. Thinking the options 
and flag would be Antialias_Min_Depth=n and +RMn, respectively.

The 'lines' in the attached image have been fattened with a big jitter 
rather than by increasing the radius of the cylinders. I believe this 
will lead to better looking thumbnails for images of this type - FWIW.

Bill P.

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

October 31, 2023

1)
--

Shooting more rays and scaling smaller almost always leads to better 
looking images. This can be accomplished by rendering much larger images 
and scaling them down, or one can force more rays to be shot with AA, by 
setting the threshold to 0.0.

2)
--

Though random / big jitter only applies to AA methods 1 and 2, All three 
AA methods in v3.8 and beyond lack a means to force a minimum 'depth' or 
number of rays be shot - prior to invoking adaptive AA. This is a 
serious shortcoming where resolving detail is the measure of goodness. 
In modes 1 & 2 you can set the AA threshold to 0.0, but then the 
recursion depth is all that limits the number of rays shot.


3)
--

If trying to 'see' fine detail, where using, say, '+a0.01 +am2 +r3' it 
is the case that dropping back one recursive depth with zero threshold, 
'+a0.0 +am2 +r2', is often a win in both performance and result. This AA 
depth fall back with a zero threshold, typically, works sooner in 
resolving detail (at less depth), with random / big jitter.

4)
--

Using yuqk's random / big jitter will frequently see fine detail at 
lower AA recursion depths - if the AA threshold is 0.0 (if a minimum 
number of rays beyond the initial 'sample corners' is shot). However, at 
low recursive depths the overall result is noisier due some of those 
rays also more often missing the detail. In other words, at lower 
recursive depths (minimum number of rays shot) the intensity of the fine 
detail will more universally fluctuate.

5)
--

Where the number of rays is higher the random / big jitter leads to 
better images faster than just rendering large with AA modes not having 
random / big jitter. As the number of rays shot grows still more, having 
a random / big jitter capability matters less and less. Aside: There is 
a slight dimming of detail as the number of rays grows for mostly the 
same reason the fluctuation in intensity shows up in (4).

6)
--

There are recommended maximum big jitter amounts for methods 1 and 2 
depending on recursion depth. Using a big jitter value (jitter > 1.0), 
but smaller than this recommended maximum, somewhat often, leads to a 
better result with respect to resolving detail and the smoothness of the 
resultant detail.

7)
--

There are a non-trivial number of reasons AA might quit earlier than 
we'd like due used features having their own adaptive mechanisms.

8)
--

Big jitter allows for additional effects beyond more traditional AA.

9)
--

Depending on the particular scene, alignment of pixels with detail - and 
desired results - the rules above will apply more, or less well. YMMV.

[William F Pokorny] Re: A yuqk fork seedfi example. [892 days and 48 minutes ago]

Mon, 30 Oct 2023 19:45:45 GMT

On 10/30/23 15:02, William F Pokorny wrote:
> 

And this image demonstrates the just added 'blend_mode 5' to go with 
'blend_mode 4'. The new to yuqk fork modes 4 and 5 don't operated on the 
color channel values, but rather the two internal weight values of the 
interpolation between the end points of each blend range. In other words 
the gamma adjustment is getting applied to the weighting factors. Mode 4 
accentuates the end parts of the blend while 5 the middle part.

(a)

> #declare ColorMap = color_map {
>  Â Â Â  [ -1 CarmineRed ]
>  Â Â Â  [Â  0 Black ]
>  Â Â Â  [Â  1 ChalkGreen ]
> }
> 

For the attached image, the map above was changed to:

#declare ColorMap = color_map {
     blend_mode 5  blend_gamma 0.667
     [ -1 CarmineRed ]
     [  0 Black ]
     [  1 ChalkGreen ]
}

Bill P.

[William F Pokorny] A yuqk fork seedfi example. [892 days 1 hour and 32 minutes ago]

Mon, 30 Oct 2023 19:02:35 GMT

With the yuqk fork release posted today I started to include some simple 
example scenes for particular features. Attached an image from the 
seedfi_00.pov example.

It's an image that just showed up as I played and I thought it cool. The 
relevant bit of code is below.

...
#declare CarmineRed = srgb <1,0,0.21961>;
#declare Black = srgb <0,0,0>;
#declare ChalkGreen = srgb <0.11765,0.68627,0.07843>;
#declare ColorMap = color_map {
     [ -1 CarmineRed ]
     [  0 Black ]
     [  1 ChalkGreen ]
}

// The focus is just below. It shows the use of the seedfi
// pattern and that it needs to use function_interval due the
// -1..1 values it generates. There is too a chaining of two
// _wave general value pattern modifiers which can create effects
// not otherwise easily achieved.
#declare Fn = function {
     pattern {
         seedfi function_interval sine_wave
         warp {
             turbulence <0,0,1.667>
             octaves 5
             omega 0.67
             lambda 5.3
             it_scale 1/7
         }
     }
}
#declare Pigment00 = pigment {
     function { Fn(x,y,z) }
     function_interval
     frequency 33 triangle_wave
     color_map { ColorMap }
     translate <0,0,-0.5> scale 1/3
}
...

Bill P.

[And] Re: Playing with ideas for additional facets met... [905 days 12 hours and 24 minutes ago]

Tue, 17 Oct 2023 08:10:00 GMT

.... Oh, it sounds like a POV-Ray internal C++ function...

[William F Pokorny] Re: Playing with ideas for additional facets met... [907 days 5 hours and 20 minutes ago]

Sun, 15 Oct 2023 15:14:18 GMT

On 10/15/23 01:55, And wrote:
> What is the concept about f_hash()?

Sorry, I forget I'm playing way off in the weeds!

A newsgroup thread on f_hash() can be found here:

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

It's basically a much more general 'cells' like capability for creating 
regions with discrete, constant values.

------

A problem I have, is that once I get an idea sort of working, I always 
doubt whether it's worthwhile enough to endure the pain of complete 
implementations! :-) What I'm posting on here isn't in a final feature 
form.

The basic idea I'm playing with here, coded as SDL in the povr fork, is 
below. If I do adopt it as full scalar value pattern and/or a normal 
perturbation method, all of it would be hard coded internally in C++ to 
speed it up.

// This f_hash() bit creates a bunch of partitioned value regions
#declare Step = e*0.011;  // e*0.015
#declare Fn00 = function {
     f_hash(
         f_hash(
             f_hash(x,now,Step,0)+
             f_hash(y,now+1,Step,0)+
             f_hash(z,now+2,Step,0),
             now+3,Step,0) +
         f_hash(
             f_hash(f_gradient(x,y,z,1,1,0),now+4,Step*1.414,0)+
             f_hash(f_gradient(x,y,z,1,0,1),now+5,Step*1.414,0)+
             f_hash(f_gradient(x,y,z,0,1,1),now+6,Step*1.414,0),
             now+7,Step,0) +
         f_hash(
             f_hash(f_gradient(x,y,z,+1,+1,+1),now+8,Step*tau,0)+
             f_hash(f_gradient(x,y,z,-1,+1,+1),now+9,Step*pi,0)+
             f_hash(f_gradient(x,y,z,+1,-1,1),now-1,Step*tau,0)+
             f_hash(f_gradient(x,y,z,+1,+1,-1),now-2,Step*pi,0)
             ,now-3,Step,0),
     now-4,0,1)
}

#declare TmpVal = pow(2,52);

// The bit below is doing a dot product of two sets(vectors) of
// 64 bits, where each bit represents -1 or 1. Why? It's a way to
// create values in a -64 to 63 integer range which conform to an
// approximate normal distribution. For something with crystal
// like facets, I don't want many final values for the normal
// perturbation vectors.

// Aside: The approach for this very fast dot product has seen
// renewed use in neural network programming. I suppose this due
// many recent, mainstream, processors adding a built in popcnt
// opcode. (I know very little about neural networks)

#declare Fn01 = function {
     f_64x_ui1_popcnt(
         f_64x_ui1_xor(
             f_64x_ui1_fltto(Fn00(x,y,z)*TmpVal),
             f_64x_ui1_ror(
                 f_64x_ui1_fltto(Fn00(z,-y,x)*TmpVal),32,0),
             1
         )
     )
}
#declare Fn02 = function {
     2.0*Fn01(x,y,z) - 64.0
}

sphere { 0, 0.7
     pigment { rgb 1 }
     normal {
         function { Fn02(x,y,z)/63.0 }
         bump_size 1 accuracy 0.0777
     }
     finish {
         brilliance 7.0 reflection { 0.01, 0.3 fresnel}
     }
     interior { ior 2.5 }
}
#declare RangoonGreen = srgb <0.1098,0.11765,0.07451>;
plane { y, -1.1
     pigment { RangoonGreen }
     normal {
         function { Fn02(x/2,y/2,z/2)/63.0 }
         bump_size 1/3 accuracy 0.1777
     }
     finish {
         brilliance 3.5 reflection { 0.01, 0.1 fresnel}
     }
     interior { ior 1.5 }
}
//---

Attaching a couple more test images images.

Bill P.

[And] Re: Playing with ideas for additional facets met... [907 days 14 hours and 34 minutes ago]

Sun, 15 Oct 2023 06:00:02 GMT

William F Pokorny <ano### [at] anonymousorg> wrote:
> In one of the recent threads, Sam mentioned the facets pattern and how
> it replaces normals rather than perturbs them in one of its two modes.
>
> It got me thinking how we might get facets like patterns without the
> need for picking different facet modes depending on the shape's form and
> surface orientation(s).
>
> Attached is an attempt which is perhaps not bad?
>
> It is currently set up by creating regions of constant values a little
> like cells or solid crackle, but at the moment based upon povr's
> f_hash() and a number of other newer inbuilt functions though which of
> those latter might make it into any final code is still somewhat
> undetermined.
>

What is the concept about f_hash()?

[William F Pokorny] Playing with ideas for additional facets methods. [907 days 22 hours and 8 minutes ago]

Sat, 14 Oct 2023 22:26:04 GMT

In one of the recent threads, Sam mentioned the facets pattern and how 
it replaces normals rather than perturbs them in one of its two modes.

It got me thinking how we might get facets like patterns without the 
need for picking different facet modes depending on the shape's form and 
surface orientation(s).

Attached is an attempt which is perhaps not bad?

It is currently set up by creating regions of constant values a little 
like cells or solid crackle, but at the moment based upon povr's 
f_hash() and a number of other newer inbuilt functions though which of 
those latter might make it into any final code is still somewhat 
undetermined.

After the value regions are set up, the 'accuracy' feature of the 
normal{} block for normal perturbations based upon scalar value patterns 
is used, but with mostly larger than typical settings due the dimensions 
of the value regions. Basically, the pattern works by taking samples 
from different value regions around the base the raw normal vector on 
the surface(*).

(*) The samples would usually come from a scalar value field and not 
discrete values.

Yes, this test code is still normal perturbation and not normal 
replacement, but I think the direction shows promise(a). Image attached 
with a constant, f_hash value regions set up - only changing the 
accuracy settings.

(a) - Thinking the end result will probably be both a scalar value 
pattern and a normal{} block modification method. Maybe calling it 
facets2 or something?

- I've still not played much with the existing facets pattern...

- The larger the accuracy setting the smoother the result, which I 
confess, I don't really understand at the moment. But, there is stuff I 
think not completely right in the way sampling gets done today - and 
there is that magic stuff sitting there in the code too. I need to dig 
into it someday.

Bill P.

Aside: Yep, it might be just using crackle as the value pattern works 
too and twiddling with accuracy works too - I've not tried it. I'm 
trying for something less expensive the crackle(z), but who knows where 
it would all come out cost wise.


(z) - The existing normal{} facets pattern itself uses the crackle 
pattern internally.

[William F Pokorny] New f_path() inbuilt function in upcoming povr f... [918 days 9 hours and 28 minutes ago]

Wed, 4 Oct 2023 11:06:33 GMT

Attached an image showing a few isosurfaces based on a new f_path() 
inbuilt function.

Though called f_path, the function allows two to thirteen(a) vertice 
definitions; Plus a general ability to describe how those vertices 
should be connected - or not.

(Bill W. The code uses distance to 3D line segments internally)

Bill P.

(a) - I might later allow more vertices. The performance turned out 
better than I guessed it would be.

[And] Re: Wood pattern and v4.0. [931 days 9 hours and 34 minutes ago]

Thu, 21 Sep 2023 11:00:00 GMT

"Bald Eagle" <cre### [at] netscapenet> wrote:
> https://www.cs.cornell.edu/~srm/publications/SG05-wood-lr.pdf
>
> https://www.cs.cornell.edu/~srm/publications/SG05-wood.html
>
> has a link to a tar/gz archive with code.   :)
>
>

https://www.youtube.com/watch?v=FG57kqn7GC8

https://arxiv.org/pdf/1511.04224.pdf

I think this is doable, just need to figure out how to implement it, and perhaps
get a bit of help with the Jacobian and outer product (tensor product)
functions.

- BW

Thank you.

[And] Re: Wood pattern and v4.0. [931 days 9 hours and 49 minutes ago]

Thu, 21 Sep 2023 10:45:00 GMT

William F Pokorny <ano### [at] anonymousorg> wrote:
> On 9/19/23 04:52, And wrote:
> > Are you have facebook? I have searched(a little) people on this newsgroup. I
> > have found you. I think that I ought to add people on facebook, otherwise I
> > cannot imagine any character about people here.
>
> There is probably an old facebook account out there that I created years
> ago. However, I have long not used it. It got far too noisy for this old
> man. :-)
>
> Bill P.

OK.

[Bald Eagle] Re: Wood pattern and v4.0. [932 days 19 hours and 49 minutes ago]

Wed, 20 Sep 2023 00:45:00 GMT

https://www.cs.cornell.edu/~srm/publications/SG05-wood-lr.pdf

https://www.cs.cornell.edu/~srm/publications/SG05-wood.html

has a link to a tar/gz archive with code.   :)



/*
 * woodreflectance.sl -- wood (anisotropic)
 *
 * DESCRIPTION:
 *   Simple wood shader, driven by four textures:
 *    RGB diffuse color
 *    RGB fiber (anisotropic highlight) color
 *    x,y,z of unit vector giving local fiber orientation in local
 *      coordinates
 *    beta, a "roughness" parameter to control width of highlight.
 *   If any of these files is not specified, we fall back on a
 *    uniform parameter. So far, every map has had uniform beta.
 *
 * PARAMETERS:
 *
 *   diffuse_texture: name of file containing 3-channel texture
 *     modulating color across the patch.
 *
 *   fiber_texture: name of file containing 3-channel texture
 *     modulating fiberColor across the patch. This map is divided by
 *     20 because it generally contains values greater than 1, which
 *     would be clamped in an integer pixel format.
 *
 *   axis_texture: name of file containing 3-channel texture
 *     modulating fiberAxis across the patch. Values are mapped
 *     [0:max] -> [-1:1] for each component, since most image file
 *     formats are unsigned.
 *
 *   beta_texture: name of file containing 1-channel texture
 *     modulating beta across the patch.
 *
 *   eta: Index of refraction of surface finish. Used to modulate
 *     highlight and subsurface with varying angle. eta=0 used to
 *     signal absence of overcoat.
 *
 *   color, fiberColor: fallback diffuse and directional colors if
 *     texture is missing
 *
 *   fiberAxis: fallback fiber direction if texture is missing
 *
 *   beta: width of subsurface highlight if texture is missing
 *
 *   roughness: width of surface (white) highlight
 *
 *   Ka, Kd, Ks: normal Renderman coefficients. Ka and Kd modulate the
 *     diffuse component (parameter "color"), and Ks is a fudge factor
 *     on the surface (white) highlight.
 *
 * ANTIALIASING: provided by texture lookup
 *
 * REFERENCE: Stephen R. Marschner, Stephen H. Westin,
 *              Adam Arbree, and Jonathan T. Moon,
 *            "Measuring and Modeling the Appearance of
 *               Finished Wood", SIGGRAPH 2005
 *
 * AUTHOR: written by Stephen H. Westin,
 *                    Cornell University Program of
 *                    Computer Graphics
 *         last modified by $Author: westin $
 *
 * VERSION: $Revision: 1.2 $
 *
 * HISTORY:
 * $Log: woodreflectance.sl,v $
 * Revision 1.2  2005/05/10 20:02:15  westin
 * Modified to use 4 TIFF texture maps rather than a single
 *  10-channel map.
 *
 * Revision 1.1  2005/05/09 21:10:18  westin
 * Working version of shader; used for animation on Proceedings DVD-ROM.
 *
 */

surface
woodreflectance ( float Ka = 1.0,
                        Kd = 1.0,
                        Ks = 1.0;
                  float eta = 1.5;
                  vector fiberAxis = ( 1, 0, 0 );
                  float beta = .1745; /* 10 degrees -> radians */
                  color fiberColor = color ( 1, .6, .4 );
                  string diffuse_texture = "",
                         fiber_texture = "",
                         axis_texture = "",
                         beta_texture = "";
                  float minU = 0, maxU = 1,
                  minV = 0, maxV = 1,
                  roughness = 0.2; )
{

  uniform float sqrt2pi = 2.5066283;

  vector local_z;        /* Surface normal in "world" space */
  vector local_x, local_y; /* Unit vector in "u" and "v" directions */

  normal Nf = faceforward (normalize(N), I); /* Forward-facing normal */
  vector V = normalize(I);                 /* Normalized eye vector */

  color diffuseColor, highlight;
  vector axis;
  float tx_beta;

  vector ssInDir, ssOutDir; /* Light and eye vector, possibly refracted */
  float thInPrime, thOutPrime;
  float halfAngle, diffAngle;
  float fiberFactor, geometryFactor;

  float Kr, Kt;                          /* for output of fresnel() */
  float ssAtten; /* Attenuation from going through the smooth interface twice */

  /* Get local coordinate system in terms of native
     parameters (u,v). We should really use (s,t). */
  local_z = Nf;
  /* Get unit vector in "u" parameter direction */
  local_x = normalize ( dPdu );
  /* Get final local basis vector y perpendicular to x and z. */
  local_y = local_z^local_x;

  /* If there is a clear overcoat, calculate refraction direction and
     attenuation. */
  if ( eta != 1.0 ) {
    vector Rdir;                     /* Dummy */
    fresnel ( V, Nf, 1.0/eta, Kr, Kt, Rdir, ssOutDir );
    ssOutDir = -ssOutDir;
    // Use (1-Kr) rather than Kt, because we are dealing with power,
    // not radiance.
    ssAtten = 1 - Kr;
  } else {
    ssOutDir = -V;
    ssAtten = 1.0;
  }
  normalize(ssOutDir);

  color axisTemp;
  float ourS = minU + u * (maxU - minU),
    ourT = minV + v * (maxV - minV);

  // Get parameters locally from texture maps, if available

  if ( diffuse_texture != "" )
    diffuseColor = color texture ( diffuse_texture, ourS, ourT );
  else
    diffuseColor = Cs;

  if ( fiber_texture != "" )
    highlight = color texture ( fiber_texture, ourS, ourT ) * 20;
  else
    highlight = fiberColor;

  if ( axis_texture != "" ) {
    axisTemp = color texture ( axis_texture, ourS, ourT )
                                   *2 - 1.0;
    /* Transform to local coordinate system */
    axis = comp ( axisTemp, 0 ) * local_x
         - comp ( axisTemp, 1 ) * local_y
         + comp ( axisTemp, 2 ) * local_z;
  }
  else
    axis = comp ( fiberAxis, 0 ) * local_x
         + comp ( fiberAxis, 1 ) * local_y
         + comp ( fiberAxis, 2 ) * local_z;
  normalize(axis);

  if ( beta_texture != "" )
    tx_beta = float texture ( beta_texture, ourS, ourT );
  else
    tx_beta = beta;

  thOutPrime = asin ( ssOutDir.axis );

  /* Calculate anisotropic highlight for each light */
  Ci = 0;
  illuminance ( P, Nf, PI/2 /* Hemisphere */ ) {
    float dummy, ssAttenOut;
    vector Ln = normalize ( L );

    /* Refract at smooth surface */
    if ( eta != 1.0 ) {
      vector Rdir;                           /* dummy */
      fresnel ( -Ln, local_z, 1.0/eta, Kr, Kt, Rdir, ssInDir );
      // Use (1-Kr) rather than Kt, because we are dealing with power,
      // not radiance.
      ssAttenOut = 1 - Kr;
    } else {
      ssInDir = -Ln;
      ssAttenOut = 1.0;
    }

    float ssFactor = max ( 0, -ssInDir.local_z ) * ssAtten*ssAttenOut;
    thInPrime  = asin ( -ssInDir.axis );
    halfAngle = thOutPrime + thInPrime;
    diffAngle = thOutPrime - thInPrime;
    // Compute value of Gaussian at this angle
    fiberFactor = tx_beta * exp ( -pow(halfAngle/tx_beta,2)/2 )
                                      / sqrt2pi;
    float cosIncline = cos(diffAngle / 2);
    geometryFactor = 1 / pow ( cosIncline, 2 );
    fiberFactor *= geometryFactor;
    // Add in diffuse term, attenuated by surface term.
    Ci += Cl * Kd * diffuseColor * ssFactor;
    // Add in fiber highlight, also attenuated.
    Ci += Cl * fiberFactor * highlight * ssFactor;
    /* Second Fresnel call is for strength of surface highlight */
    vector H = normalize ( -V + Ln );
    fresnel ( V, H, 1.0/eta, Kr, Kt );
    // Blinn/Phong highlight with Fresnel attenuation
    Ci += Cl * Ks * Kr
      * pow ( max ( 0, H.local_z ), 1/roughness );
  }

  Ci += Ka * diffuseColor * ambient();
}

[Bald Eagle] Re: Wood pattern and v4.0. [932 days 22 hours and 39 minutes ago]

Tue, 19 Sep 2023 21:55:00 GMT

https://www.youtube.com/watch?v=FG57kqn7GC8

https://arxiv.org/pdf/1511.04224.pdf

I think this is doable, just need to figure out how to implement it, and perhaps
get a bit of help with the Jacobian and outer product (tensor product)
functions.

- BW

[William F Pokorny] Re: Wood pattern and v4.0. [932 days 23 hours and 35 minutes ago]

Tue, 19 Sep 2023 20:59:07 GMT

On 9/19/23 04:52, And wrote:
> Are you have facebook? I have searched(a little) people on this newsgroup. I
> have found you. I think that I ought to add people on facebook, otherwise I
> cannot imagine any character about people here.

There is probably an old facebook account out there that I created years 
ago. However, I have long not used it. It got far too noisy for this old 
man. :-)

Bill P.

[And] Re: Wood pattern and v4.0. [933 days 11 hours and 39 minutes ago]

Tue, 19 Sep 2023 08:55:00 GMT

William F Pokorny <ano### [at] anonymousorg> wrote:
>
> I played a little with the IsoWood macros a 'long' time ago and have a
> copy somewhere, but I don't recall what pattern / functions were used
> for the wood patterning - thanks for the info on the look of it in
> comparison.
>
> I've been following your 'wood work' programming effort. I confess to
> more or less thrashing around, pushing here and there, on what can be
> done and only sometimes with 'wood' grain specifically in mind.
>

Ha... I explored the concept (deform, growth rates, knots, etc) separately. I
would like integrate them. But I don't have enough ability on developing a
program. I just learn it by DIY.

Thank you. I feel encouraged.

> Yes, the approach in the bottom row is to start with an internal
> turbulence scaled small to make the rings just a little bit noisy as
> they go around - and then on top of that to layer one or more additional
> warp turbulences at larger scales to get a more complete wood pattern look.
>
> This turbulence layering approach is difficult with the old style 'wood'
> because it has those fixed, positional harmonics. It's too easy to push
> the 'favorable' portion of the pattern off of the surface being textured.
>

I cannot understand it very well.

> I'm starting to look now at pushing into the warp{} mechanisms with
> thoughts toward a re-work of the underlying functionality of that code.
> In the povr fork, I have quite a few fixes and additions hacked into
> that code over what is in official POV-Ray releases, but it's all
> 'hacked in'. I'd like to refined what's there into something better.
>
> Anyhow... I'll attach another image using the povr updated 'wood' as the
> base pattern - not really aimed to be anything in particular. It's a
> test image for other features as much as the changed 'wood', but I think
> it looks interesting.
>
> Using it_* turbulence and warp{it_* ...} turbulence with emitting,
> media{density{density_map{...}...}}.
>
> Oh, the containing shape is an isosurface based upon povr's inbuilt
> f_toupie() function. Here with options forming a shape somewhat like a
> spinning top. It's thicker in the middle, thinning as it moves out from
> the center before thickening into an outer torus at the edges.
>
> Bill P.


I noticed that povr is running on Linux. I don't have much ability on
C/C++,(additional I'm learning another thing) so I'm not trying it. I will try
it in the future or waiting the integration with official POV-Ray version.

-----------------------------------
Are you have facebook? I have searched(a little) people on this newsgroup. I
have found you. I think that I ought to add people on facebook, otherwise I
cannot imagine any character about people here.

[William F Pokorny] Re: Wood pattern and v4.0. [936 days 19 hours ago]

Sat, 16 Sep 2023 01:34:32 GMT

On 9/15/23 07:10, And wrote:
> I haven't used povr yet.
> 
> I found that your image (top row) are similar to the deform of the IsoWood
> include files of Christoph Hormann.
> 
> The bottom row is interesting, too.

I played a little with the IsoWood macros a 'long' time ago and have a 
copy somewhere, but I don't recall what pattern / functions were used 
for the wood patterning - thanks for the info on the look of it in 
comparison.

I've been following your 'wood work' programming effort. I confess to 
more or less thrashing around, pushing here and there, on what can be 
done and only sometimes with 'wood' grain specifically in mind.

Yes, the approach in the bottom row is to start with an internal 
turbulence scaled small to make the rings just a little bit noisy as 
they go around - and then on top of that to layer one or more additional 
warp turbulences at larger scales to get a more complete wood pattern look.

This turbulence layering approach is difficult with the old style 'wood' 
because it has those fixed, positional harmonics. It's too easy to push 
the 'favorable' portion of the pattern off of the surface being textured.

I'm starting to look now at pushing into the warp{} mechanisms with 
thoughts toward a re-work of the underlying functionality of that code. 
In the povr fork, I have quite a few fixes and additions hacked into 
that code over what is in official POV-Ray releases, but it's all 
'hacked in'. I'd like to refined what's there into something better.

Anyhow... I'll attach another image using the povr updated 'wood' as the 
base pattern - not really aimed to be anything in particular. It's a 
test image for other features as much as the changed 'wood', but I think 
it looks interesting.

Using it_* turbulence and warp{it_* ...} turbulence with emitting, 
media{density{density_map{...}...}}.

Oh, the containing shape is an isosurface based upon povr's inbuilt 
f_toupie() function. Here with options forming a shape somewhat like a 
spinning top. It's thicker in the middle, thinning as it moves out from 
the center before thickening into an outer torus at the edges.

Bill P.

[And] Re: Wood pattern and v4.0. [937 days 9 hours and 19 minutes ago]

Fri, 15 Sep 2023 11:15:00 GMT

I haven't used povr yet.

I found that your image (top row) are similar to the deform of the IsoWood
include files of Christoph Hormann.

The bottom row is interesting, too.

[William F Pokorny] Wood pattern and v4.0. [939 days 2 hours and 57 minutes ago]

Wed, 13 Sep 2023 17:36:40 GMT

I'd re-written the povr fork's wood, scalar value pattern (not povr's 
f_wood() inbuilt) a couple years back. I found myself twiddling with it 
again recently. I wanted to document some of how I understand it to be 
working in official releases (since v1.0) and how it is now working in 
the povr fork.

An image is attached. In the top row on the left and right showing how 
'special turbulence' (naked 'turbulence' and associated keywords) today 
produces a wood pattern with harmonics. This is due a melding of the 
incoming x and y coordinates with the turbulence.

My best guess is odd turbulence treatment was done to get differing size 
growth rings - so long as users carefully position the pattern with 
respect to the surface(s) being textured. Namely, orthogonal / ortho45 
arrangements with respect to x & y axes. The behavior is very touchy 
with respect to the turbulence settings.

Lastly, the middle top row shows that if the user codes 'warp { 
turbulence ...}' over 'turbulence ...' they get no internal / special 
turbulence treatment at all, but rather only warp turbulence. This one 
of the reasons the povr fork has new it_ prefixed (internal turbulence) 
keywords where features make use of internal turbulence.

     //...  Official POV-Ray code
     plane { -z 0
         pigment {
             wood
             turbulence 0.05
             color_map {
                 [0 rgb 0]
                 [1 rgb 1]
             }
         }
         scale 1/8
         finish { emission 1 }
     }

---

Originally, I'd re-code to match the behavior above, but the povr fork 
now has f_wood() and I wanted to change the basic wood pattern to 
something easier to understand and use well.

The povr update is shown on the bottom row. The special melding of x and 
y with the DTurbulence() result is gone in favor of using the output of 
DTurbulence() directly. Further, as a general enhancement, there is now 
an it_scale option for warp { turbulence .. } and also scalar value 
patterns like wood.

     //... Example for povr fork using it_* turbulence and
     // warp{ turbulence ... it_scale ... }
     plane { -z 0
         pigment {
             wood
             it_amount 0.05  // New
             it_scale 1/4    // New
//          scale 1/3  // Old turbulence scaling method
             translate <pi,pi/2,pi/3>
             warp {
		turbulence 0.1 octaves 3
		omega 0.67 lambda 1.7 it_scale 3.0 // New
             }
             translate <pi,pi/2,pi/3>*-1
//          scale 3   // Old turbulence scaling method
             scale 1/24
             color_map {
                 [0 rgb 0]
                 [1 rgb 1]
             }
         }
         finish { emission 1 }
     }

Bill P.

[Greg Kennedy] Re: Aspect Ratio Handling [980 days and 9 minutes ago]

Thu, 3 Aug 2023 20:25:00 GMT

Alain Martel <kua### [at] videotronca> wrote:
> Le 2023-07-24 à 00:47, Greg Kennedy a écrit :
> > The default POV-Ray camera setting for "right" is a 4:3 ratio, designed to match
> > the default 4:3 output (for 4:3 screens) leading to a 1:1 pixel aspect ratio.
> >
> > A common stumbling block for new users is attempting to render a 16:9 image,
> > which leads to non-square pixels and the output appearing horizontally
> > stretched.  This means a search in the manual until you discover the magic words
> > "right x*ImageWidth/ImageHeight" to produce the desired aspect ratio.
> >
> > The rationale for 4:3 default in the manual FAQ section is pretty thin these
> > days, as people are not rendering Windows XP startup screens any more, and it
> > seems FAR more likely that users will want a 1:1 PAR by default (which they can
> > change if needed for special cases).
> >
> > I suggest for 4.0, that the default for camera Right be automatically set to the
> > same ratio as the requested image output ratio, which means 16:9 resolutions
> > will work "out of the box", and that users wanting an anamorphic ratio should
> > instead tweak Right themselves (overriding the default).
> >
> As of version 3.8, the default right vector is now :
> x*image_width/image_height
>
> That mean that there is no more stretching/squishing.
> So, your request is already fulfilled.

Oh that's great!  I didn't realize it was already changed (still using 3.7) and
assumed that my next chance to get a feature request in would be 4.0.  Thanks
for the clarification :)

[Alain Martel] Re: Aspect Ratio Handling [990 days 3 hours and 26 minutes ago]

Mon, 24 Jul 2023 17:07:41 GMT

Le 2023-07-24 Ã  12:49, Cousin Ricky a Ã©critÂ :
> "Greg Kennedy" <ken### [at] gmailcom> wrote:
>>
>> I suggest for 4.0, that the default for camera Right be automatically set to the
>> same ratio as the requested image output ratio, which means 16:9 resolutions
>> will work "out of the box", and that users wanting an anamorphic ratio should
>> instead tweak Right themselves (overriding the default).
> 
> This is already done in POV-Ray 3.8, so long as the scene file starts with
> 
>    #version 3.8;
> 
> 
Or
	#version version;

The above will automatically set the used version to the actual version 
of the program.

[Alain Martel] Re: Aspect Ratio Handling [990 days 3 hours and 28 minutes ago]

Mon, 24 Jul 2023 17:05:38 GMT

Le 2023-07-24 Ã  00:47, Greg Kennedy a Ã©critÂ :
> The default POV-Ray camera setting for "right" is a 4:3 ratio, designed to match
> the default 4:3 output (for 4:3 screens) leading to a 1:1 pixel aspect ratio.
> 
> A common stumbling block for new users is attempting to render a 16:9 image,
> which leads to non-square pixels and the output appearing horizontally
> stretched.  This means a search in the manual until you discover the magic words
> "right x*ImageWidth/ImageHeight" to produce the desired aspect ratio.
> 
> The rationale for 4:3 default in the manual FAQ section is pretty thin these
> days, as people are not rendering Windows XP startup screens any more, and it
> seems FAR more likely that users will want a 1:1 PAR by default (which they can
> change if needed for special cases).
> 
> I suggest for 4.0, that the default for camera Right be automatically set to the
> same ratio as the requested image output ratio, which means 16:9 resolutions
> will work "out of the box", and that users wanting an anamorphic ratio should
> instead tweak Right themselves (overriding the default).
> 
As of version 3.8, the default right vector is now :
x*image_width/image_height

That mean that there is no more stretching/squishing.
So, your request is already fulfilled.

[Cousin Ricky] Re: Aspect Ratio Handling [990 days 3 hours and 39 minutes ago]

Mon, 24 Jul 2023 16:55:00 GMT

"Greg Kennedy" <ken### [at] gmailcom> wrote:
>
> I suggest for 4.0, that the default for camera Right be automatically set to the
> same ratio as the requested image output ratio, which means 16:9 resolutions
> will work "out of the box", and that users wanting an anamorphic ratio should
> instead tweak Right themselves (overriding the default).

This is already done in POV-Ray 3.8, so long as the scene file starts with

  #version 3.8;

[Thomas de Groot] Re: Aspect Ratio Handling [990 days 6 hours and 9 minutes ago]

Mon, 24 Jul 2023 14:25:18 GMT

Op 24-7-2023 om 13:23 schreef Bald Eagle:
> "Greg Kennedy" <ken### [at] gmailcom> wrote:
>> The default POV-Ray camera setting for "right" is a 4:3 ratio, designed to match
>> the default 4:3 output (for 4:3 screens) leading to a 1:1 pixel aspect ratio.
>>
>> A common stumbling block for new users is attempting to render a 16:9 image,
>> which leads to non-square pixels and the output appearing horizontally
>> stretched.  This means a search in the manual until you discover the magic words
>> "right x*ImageWidth/ImageHeight" to produce the desired aspect ratio.
>>
>> The rationale for 4:3 default in the manual FAQ section is pretty thin these
>> days, as people are not rendering Windows XP startup screens any more, and it
>> seems FAR more likely that users will want a 1:1 PAR by default (which they can
>> change if needed for special cases).
>>
>> I suggest for 4.0, that the default for camera Right be automatically set to the
>> same ratio as the requested image output ratio, which means 16:9 resolutions
>> will work "out of the box", and that users wanting an anamorphic ratio should
>> instead tweak Right themselves (overriding the default).
> 
> I, and others completely understand these little things that drive new users
> crazy - since we were all once new users, and sometimes get caught making newbie
> mistakes even now.
> 
> The Insert menu is there to solve many of these problems, along with example
> scenes, and scenes posted my users to the forum.   There kind of is a FAQ that
> covers stuff like this - maybe it should be made more prominent, and maybe a
> VERY simple new user guide should be written walking someone through the various
> necessary and sufficient steps to writing a basic scene.
> 
> The paradox of all of this is that the more you hand them, the less they learn,
> and the more disconnected they get from the HOWs and WHYs of everything - which
> just winds up kicking the stumbling block further down the road.
> 
> The Shadertoy community has some amazing content, and they write ALL of the code
> for ALL of the elements of their scenes from scratch.   Camera, lighting, the
> functions for all of the shapes and colors - everything.
> 
> So, I would say that there ought to be a two-prong approach, one addressing the
> quick and easy copy-paste to speed the creation of a working scene, but with the
> proviso and caveat that the user should work through a more technical version of
> the scene to gain an understanding of WHAT they are doing with the various
> commands, arguments, and values, and WHY.
> 
> Mindlessly plopping text into a .pov file without understanding any of it is a
> sure recipe for greater eventual frustration, when they want to start really
> making nice looking scenes, and still don't for the life of them know HOW.
> 
> 
> That's the just way of things, I guess..
> 
> - BW
> 

A page that can help (new) users is:

https://wiki.povray.org/content/Reference:Keywords

The advantage is that it is the latest up-to-date version, including 
changes related to version 3.8.

For the present topic, the default for right is:

right <image_width/image_height,0,0>

-- 
Thomas

[Bald Eagle] Re: Aspect Ratio Handling [990 days 9 hours and 9 minutes ago]

Mon, 24 Jul 2023 11:25:00 GMT

"Greg Kennedy" <ken### [at] gmailcom> wrote:
> The default POV-Ray camera setting for "right" is a 4:3 ratio, designed to match
> the default 4:3 output (for 4:3 screens) leading to a 1:1 pixel aspect ratio.
>
> A common stumbling block for new users is attempting to render a 16:9 image,
> which leads to non-square pixels and the output appearing horizontally
> stretched.  This means a search in the manual until you discover the magic words
> "right x*ImageWidth/ImageHeight" to produce the desired aspect ratio.
>
> The rationale for 4:3 default in the manual FAQ section is pretty thin these
> days, as people are not rendering Windows XP startup screens any more, and it
> seems FAR more likely that users will want a 1:1 PAR by default (which they can
> change if needed for special cases).
>
> I suggest for 4.0, that the default for camera Right be automatically set to the
> same ratio as the requested image output ratio, which means 16:9 resolutions
> will work "out of the box", and that users wanting an anamorphic ratio should
> instead tweak Right themselves (overriding the default).

I, and others completely understand these little things that drive new users
crazy - since we were all once new users, and sometimes get caught making newbie
mistakes even now.

The Insert menu is there to solve many of these problems, along with example
scenes, and scenes posted my users to the forum.   There kind of is a FAQ that
covers stuff like this - maybe it should be made more prominent, and maybe a
VERY simple new user guide should be written walking someone through the various
necessary and sufficient steps to writing a basic scene.

The paradox of all of this is that the more you hand them, the less they learn,
and the more disconnected they get from the HOWs and WHYs of everything - which
just winds up kicking the stumbling block further down the road.

The Shadertoy community has some amazing content, and they write ALL of the code
for ALL of the elements of their scenes from scratch.   Camera, lighting, the
functions for all of the shapes and colors - everything.

So, I would say that there ought to be a two-prong approach, one addressing the
quick and easy copy-paste to speed the creation of a working scene, but with the
proviso and caveat that the user should work through a more technical version of
the scene to gain an understanding of WHAT they are doing with the various
commands, arguments, and values, and WHY.

Mindlessly plopping text into a .pov file without understanding any of it is a
sure recipe for greater eventual frustration, when they want to start really
making nice looking scenes, and still don't for the life of them know HOW.

That's the just way of things, I guess..

- BW

[jr] Re: Aspect Ratio Handling [990 days 12 hours and 24 minutes ago]

Mon, 24 Jul 2023 08:10:00 GMT

hi,

"Greg Kennedy" <ken### [at] gmailcom> wrote:
> The default POV-Ray camera setting for "right" is a 4:3 ratio, designed to match
> the default 4:3 output (for 4:3 screens) leading to a 1:1 pixel aspect ratio.
>
> A common stumbling block for new users is attempting to render a 16:9 image,
> which leads to non-square pixels and the output appearing horizontally
> stretched.  This means a search in the manual until you discover the magic words
> "right x*ImageWidth/ImageHeight" to produce the desired aspect ratio.
>
> The rationale for 4:3 default in the manual FAQ section is pretty thin these
> days, as people are not rendering Windows XP startup screens any more, and it
> seems FAR more likely that users will want a 1:1 PAR by default (which they can
> change if needed for special cases).
>
> I suggest for 4.0, that the default for camera Right be automatically set to the
> same ratio as the requested image output ratio, which means 16:9 resolutions
> will work "out of the box", and that users wanting an anamorphic ratio should
> instead tweak Right themselves (overriding the default).

you already can, and are "encouraged to do", adjust the global 'povray.ini' file
after installation; simply add the desired 'Width's and 'Height's ?

also, fwiw and afaik, I've not had any "non-square pixels and the output
appearing horizontally stretched" problems.  (rendering 16:9 and 16:10 regularly
on a machine with a 5:4 monitor)


regards, jr.

[Greg Kennedy] Aspect Ratio Handling [990 days 15 hours and 44 minutes ago]

Mon, 24 Jul 2023 04:50:00 GMT

The default POV-Ray camera setting for "right" is a 4:3 ratio, designed to match
the default 4:3 output (for 4:3 screens) leading to a 1:1 pixel aspect ratio.

A common stumbling block for new users is attempting to render a 16:9 image,
which leads to non-square pixels and the output appearing horizontally
stretched.  This means a search in the manual until you discover the magic words
"right x*ImageWidth/ImageHeight" to produce the desired aspect ratio.

The rationale for 4:3 default in the manual FAQ section is pretty thin these
days, as people are not rendering Windows XP startup screens any more, and it
seems FAR more likely that users will want a 1:1 PAR by default (which they can
change if needed for special cases).

I suggest for 4.0, that the default for camera Right be automatically set to the
same ratio as the requested image output ratio, which means 16:9 resolutions
will work "out of the box", and that users wanting an anamorphic ratio should
instead tweak Right themselves (overriding the default).

[William F Pokorny] Re: Suggest v4.0 inbuilt complex functions. (pov... [1076 days 12 hours and 14 minutes ago]

Sat, 29 Apr 2023 08:20:13 GMT

On 4/29/23 02:28, kurtz le pirate wrote:
>> hi,
>>
>> kurtz le pirate<kur### [at] gmailcom>  wrote:
>>> ...
>>> last thing : where can I find "cfunctions.inc" ?
>> installs as part of 'povr' branch (published in p.b.programming)
>>
>>
>> regards, jr.
>>
> Find. Thank jr
> 
> But as I suspected, the functions are just calls to internal functions.
> so I will continue my work
> 

Glad you found your path forward (jr, thanks for providing the pointer 
to the include file).

Thanks for posting your complex function include!

I'd looked at Tor Olav's and Ingo's include file efforts in this 
direction as I coded up the C++11 complex function wrappers, but I 
didn't have yours in hand. I've stored a copy as a reference in my work 
directory so I have it should I come back for more play.

Bill P.

--- Thinking aloud

One of the povr ideas / v4.0 suggestions I'm carrying around in my head 
is to drop the inbuilt fractal stuff - the julia shape and perhaps the 
julia, mandel and magnet patterns - as inbuilt code.

The julia shape is interesting, but aside from the pulled taffy shape 
most everyone seems to try, I don't see a common use for a julia shape 
in a ray tracer. I've taken shots at rendering some of the other 
julia-shape (sub-shapes) but I've not had luck finding anything I think 
useful to the mainstream. Plus, I've found the julia shape to be quite 
slow and glitchy.

The fractal patterns are more useful I think, but wish we'd not ended up 
with so many explicit versions (internally) for differing powers. I've 
not done any performance comparisons to the generic forms though...

I also don't know what I'm really doing in this area of POV-Ray - or 
with fractals in fact! Been holding off pulling it all from povr. This 
partly due finding recursive algorithm's - with which I'd had some luck 
back in the 2000s - to be pretty unstable today when I went to try some 
things recently...

I have in my head that I'd read somewhere there are fractal forms which 
are continuous? If so, these 'kinds' might make for more useful shapes / 
isosurfaces / patterns. But, yep! I'm just yapping. I don't know what 
I'm doing with respect to fractals...

Bill P.

[kurtz le pirate] Re: Suggest v4.0 inbuilt complex functions. (pov... [1076 days 14 hours and 5 minutes ago]

Sat, 29 Apr 2023 06:28:40 GMT

On 28/04/2023 16:10, jr wrote:
> hi,
> 
> kurtz le pirate <kur### [at] gmailcom> wrote:
>> ...
>> last thing : where can I find "cfunctions.inc" ?
> 
> installs as part of 'povr' branch (published in p.b.programming)
> 
> 
> regards, jr.
> 

Find. Thank jr

But as I suspected, the functions are just calls to internal functions.
so I will continue my work






-- 
Kurtz le pirate
Compagnie de la Banquise

[jr] Re: Suggest v4.0 inbuilt complex functions. (pov... [1077 days 6 hours and 19 minutes ago]

Fri, 28 Apr 2023 14:15:00 GMT

hi,

kurtz le pirate <kur### [at] gmailcom> wrote:
> ...
> last thing : where can I find "cfunctions.inc" ?

installs as part of 'povr' branch (published in p.b.programming)


regards, jr.

[kurtz le pirate] Re: Suggest v4.0 inbuilt complex functions. (pov... [1077 days 12 hours and 24 minutes ago]

Fri, 28 Apr 2023 08:10:08 GMT

On 10/03/2023 00:39, William F Pokorny wrote:
> In the past few years Ingo, Tor Olav and others have played around with 
> include files supporting complex numbers for sound and images. Attached 
> is an image using a few of 30 plus inbuilt complex functions added to 
> the povr fork. Mostly just wrapping the complex functions coming with 
> C++11, but sometimes using function names more in line with the existing 
> complex includes and POV-Ray's function naming.
> 
> In povr, to work with the existing function vm, packing two 32 bit 
> floats into a double space as the complex value and all complex function 
> code runs at single float accuracy.
> 
> 

Sorry to re-open this old discussion. I didn't know this pov4 group exist :(

Anyway, i too have worked a lot in the world of complex numbers. I
started to write a macro library that implements complex functions using
povray "function".

And so: is "cfunctions.inc" just an encapsulation of C functions ?
Does v4 include a new data type like c = <re,im> with the possibility to
access c.re and c.im ?

I'm attaching my "complex_functions.inc" just in case ... I continue to
develop it or I wait for v4 ?

last thing : where can I find "cfunctions.inc" ?

-- 
Kurtz le pirate
Compagnie de la Banquise

[William F Pokorny] Re: On povr's accidental text{cmap} capability. [1104 days 2 hours and 28 minutes ago]

Sat, 1 Apr 2023 18:05:50 GMT

On 4/1/23 10:43, Bald Eagle wrote:
> Have you tried sorting out that diacritical mark issue we were having a while
> back?

I did see the thread, but no.

---
Where the ring is incomplete at the top of the A in some fonts, I 
strongly suspect overlapping polygon point lists - which are technically 
legal - but the cleanest fonts eliminate such overlaps.

Those fonts represent the same covered areas with non-overlapping 
polygons point lists - which you can always do.

POV-Ray cannot handle the overlaps a renders the even overlapped areas 
as empty space. There isn't any fixing this beyond adopting some polygon 
processing package(a) to create non-overlapping representations on the 
fly...

---
Some of the rest I suspect is a font not implementing a character as a 
single glyph, but as an assembly of glyphs - to save space. A guess is 
that POV-Ray tried and failed to position all the parts of some assembly 
correctly in some of those funky cases. (Parts / point loops ending up 
outside the per prism bounding within the overall union of objects - in 
addition to - or as part of being placed incorrectly)

In the end POV-Ray is not a word processor or type setting application - 
and should never be in my opinion. There are significant packages for 
such work like freetype and IBM's open source ICT 
(https://icu.unicode.org/) underneath much of the font handling we "see" 
in applications. POV-Ray will likely use such libraries to make font 
handling better at some point, but I'd bet big there will always be 
things that don't quite work.

Aside: I've thought about what POV-Ray might look like with single 
character, ready made polygon representations in include libraries with 
no inbuilt text object at all. Rather SDL code to position characters in 
a string. Suppose that too is no small amount of work... It's attractive 
as an end goal in that it would get the POV-Ray core code out of the 
font handling game.

Bill P.

(a) - For a long time I've kept an eye on 'clipper'. See: 
http://www.angusj.com/clipper2/Docs/Overview.htm

[Bald Eagle] Re: On povr's accidental text{cmap} capability. [1104 days 5 hours and 49 minutes ago]

Sat, 1 Apr 2023 14:45:00 GMT

William F Pokorny <ano### [at] anonymousorg> wrote:
> I admit to not paying attention to 'cmap' when it was being worked on in
> early 2019. I wrongly thought it was freetype fork specific and I tuned
> it out while busy with other code play.

I was going to point you to that thread, but I had figured you knew about it.
(oops)

> ---
> Aside: For a short time saw a very strange parsing error more text{}
> related than cmap{}. I started with some example cmap{} code off the
> newsgroup and it initially failed. It seemed somehow related to a
> semicolon following the string declare used within the text{} object!
> The SDL declare looked like:
>
> #declare MyText = "..."; // Semicolon not needed.
>
> However, as I played the parsing error went away and, try as I might,
> I've been unable to reproduce that parsing fail. Maybe something like
> dos line terminations vs unix/linux ones - or some utf8 character
> elsewhere in the scene mangling things. I don't know. Still, for the
> record, I did see what looked to me to be a bogus parsing fail while
> working on a scene with cmap{}.

Have you tried sorting out that diacritical mark issue we were having a while
back?   That seemed really strange.  Had to solve it by using a totally
different font file.

Also, I have been getting some weird parse errors, for reasons that don't make
sense.

Perhaps they are due to my structuring of the code, but I feel that they are
just too weird - and - from a user perspective - unexpected behaviour.

Over the years, I also notice instances of transient and unreproducible
behaviour in scenes that DO parse and render successfully.
There are definitely ghosts lurking in the machine's code.  I suppose that I was
always uneasy about trying to point them out as possibly being real, since I'm
not a professional programmer, and POV-Ray has always had it's unique issues.  I
guess I just felt like it would get trivialized and dismissed, and I would have
a hard time supplying a scene that demonstrated the error or strange behaviour.
(just look at your recent dictionary / core dump experiments)

I will try to note and document such things more diligently in the future.

At present, I have 2 issues in the same scene/inc pair, that I sent to jr for
inspection.  I have also spent the last week chasing my tail around in circles
trying to sort out the vertices and edges of these triangles.  In my development
scene, it appears that I have everything working the way I want to and expect.
When I switch over to rendering all of the patterns, two that are not radially
symmetric are rotated - even though my preliminary debugging suggests that it
doesn't make any logical sense.

Given that you are presently in the thick of unraveling all of the keywords that
have different scopes and meaning, and we know that we have 2 different parsers
and different solvers, and ....   I would encourage others to post their
experiences in debugging their own scenes, as this would not only help spot
potential real issues, but also serve to show where SDL and/or its documentation
perhaps isn't clear enough, and revising things in those areas would be time
well spent.

- BW

[William F Pokorny] On povr's accidental text{cmap} capability. [1104 days 12 hours and 26 minutes ago]

Sat, 1 Apr 2023 08:08:15 GMT

Elsewhere while working on the keyword_status() idea - which became 
initially two keywords in word_is() and word_get() - I discovered the 
povr fork picked up Christoph's text object cmap keyword and associated 
code changes due simply to when I created the povr fork.

I admit to not paying attention to 'cmap' when it was being worked on in 
early 2019. I wrongly thought it was freetype fork specific and I tuned 
it out while busy with other code play.

Well, I have it. I took a look over the past couple days. The 'cmap' 
functionality is going to stay in povr. It's impossible to pass on what 
it already offers - even if bugs later turn up.

See attached image. Using v3.8 beta 2 rendering some utf8 text in a 
text{} object at top. On the bottom rendering the same utf8 text with 
povr - identical results with or without the cmap{} block.

I worked first with a cmap{} block and it took the ttfdump utility for 
me to guess probably something like 'cmap { 0,3 charset 0 }' was what I 
needed while using the .../dejavu/DejaVuSans.ttf font file coming with 
Ubuntu 22.04.

I then wondered what would happen if I removed the cmap{} block 
altogether. I was surprised to find it worked just as well. This comes 
to the first character map table in the font being used as the default 
and it being 0,3. Plus the 'cmap{}' related changes when the font is 
read correctly read the right cmap information in the font file.

So! On unix / linux what use is the cmap{} block you ask. Well it might 
or might not be of much use. I don't have enough experience to know.

Do the font files on linux usually have already usable defaults as 
encoded? I'd make a small bet those fonts shipping with linux 
distributions do. Font files coming from, say, a windows environment - 
maybe not. Perhaps the cmap{} functionality will be needed to pick the 
correct internal cmap with those. I'm guessing.

---

Related. The DejaVuSans.ttf font I picked also encodes two indows 
specific character maps too. The following cmap examples also work to 
some degree or other:

cmap { 3,1 charset 0 } // Works as well as linux (Apple) {0,3 charset 0}
cmap { 3,1 charset 1252 } // Works, but less well in general (a).

Anyhow. Going to keep the functionality in povr and play with it. We'll 
see what other issues pop up.

---
Aside: For a short time saw a very strange parsing error more text{} 
related than cmap{}. I started with some example cmap{} code off the 
newsgroup and it initially failed. It seemed somehow related to a 
semicolon following the string declare used within the text{} object! 
The SDL declare looked like:

#declare MyText = "..."; // Semicolon not needed.

However, as I played the parsing error went away and, try as I might, 
I've been unable to reproduce that parsing fail. Maybe something like 
dos line terminations vs unix/linux ones - or some utf8 character 
elsewhere in the scene mangling things. I don't know. Still, for the 
record, I did see what looked to me to be a bogus parsing fail while 
working on a scene with cmap{}.

Bill P.

(a) - With charset 1252 and similar it might be for the restricted set 
of windows characters you are better off for 'reasons.' When it or other 
charsets used, it seems to be dropping utf8 characters outside the first 
256 or something like that. On linux I suspect the charset won't be 
useful unless trying to match some specific windows character set behavior.

[William F Pokorny] Re: Thoughts on 'keyword_status()' functionality... [1106 days and 20 minutes ago]

Thu, 30 Mar 2023 20:13:38 GMT

On 3/27/23 17:32, Bald Eagle wrote:
> Speaking of sorting, I'm thinking that it would be a handy thing for devs,
> example scenes, documentation, and the kind of oddball experiments that people
> like me conduct - to have all the keywords numbered, just like the internal
> functions.

Given the code base, we currently need to avoid fixed number to keyword 
associations. While the number to inbuilt function name associations are 
more stable than the number to keyword ones, as a soft rule, none of the 
associations are fixed until the code's compile and link is complete.

We can create indirect 'type' to number associations at parse time in 
the form of a dictionary for a particular executable. We do this in povr 
within the shipped setidtypes.inc file.

---

You and jr have both suggested, being able to work with a keyword 
'index' of some kind as a way to, say, maintain documentation in a 
database. A good idea. Today the database keys need to be strings(a).

The next release of povr (R7 v0.6.1) implements two new SDL functions in 
word_is() and word_get(). These access and make use of 18 internal 
arrays of token information relative to the active version of 
POV-Ray(povr). The 18 arrays break down into three categories.

Previous tokens (back to through v3.6) which are out (o prefix); Tokens 
included in the current code (i prefix); Lastly, tokens which are new (n 
prefix) compared to the prior major release (v3.8 beta 2). See the, 
initial, attached text documentation for more detail.

The aim, for me as much as anyone, is to create methods for the 
POV-Ray(povr) executable to provide initial hooks / 'string indexes' for 
creating and maintaining documentation; Methods for doing parse time 
checks for active keywords, directives, functions, etc.

Aside: In doing this work, I turned up that, at povr's v3.8 branch 
point, there was a new keyword called cmap related to ttf text objects. 
On the parser back up for the v3.8 release, 'cmap' got dropped. I need 
to sort out what to do with 'cmap' for povr as it's something new that I 
didn't know was in my povr fork! (It's probably still in the v4.0 code 
base too, but I did not check)

Bill P.

(a) - Even string / token indexing comes with complications.

Directives, for example, still, mostly, come in two forms as with 
'version' and '#version'. Some like #default are not really SDL 
directives and should be coded as default{}.

A new to v3.8 feature like global and local dictionaries, made use of 
the the token 'global' which had been used with photons in earlier 
POV-Ray versions - depending upon compile time options. Knowing there is 
a 'global' token is a good start, but, then there is the detail. We all 
know, quite a few keywords have multiple uses / applications.

Back to v3.6 at least there were functions coded up in various shipped 
include files that, by name, look like lower case inbuilt keywords or 
functions. I've either replaced these with true inbuilt forms - so 
behavior is not dependent on included files - or I've deleted the lower 
case function code and created versions with upper case characters so it 
is clear the functionality is NOT inbuilt, but is being declared 
somewhere. For example, a function 'even()' was long defined in 
math.inc. With povr it is now F_even() and defined in munctions.inc 
calling M_even() if need be. M_even() being a shipped, 'munction', a 
macro defining & compiling a global function, once, on need.

It's simple except where it's complicated. :-)

[Bald Eagle] Re: Thoughts on 'keyword_status()' functionality... [1108 days 22 hours and 59 minutes ago]

Mon, 27 Mar 2023 21:35:00 GMT

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

> I'm now leaning toward the function name 'word_is()' because it leaves
> open the possibility for similarly named extensions.
>
> I should perhaps have left the return value detail for later -
> especially given I'm still sorting it out.

I can imagine it will take a bit of sorting.
Speaking of sorting, I'm thinking that it would be a handy thing for devs,
example scenes, documentation, and the kind of oddball experiments that people
like me conduct - to have all the keywords numbered, just like the internal
functions.

That would allow easily iterating through them all to check them by number, and
not be as subject to human error of, "I forgot that one."  I can envision that
depending on the kind of code one is writing, it would be a lot easier and more
compact to simply switch the argument of a master keyword directive that takes
an argument, like keyword (1).  If you had keyword_name (), then you could just
run a loop and do
word_is(keyword_name(keyword(index))).

;)

[William F Pokorny] Re: Thoughts on 'keyword_status()' functionality... [1109 days and 10 minutes ago]

Mon, 27 Mar 2023 20:23:46 GMT

On 3/27/23 07:13, jr wrote:
> like BE I'm a little bewildered by the .. variety ðŸ˜„  I think
that this whole
> issue needs to be tied in with the (proposed) 'versions.inc' and id type
> checking/testing; all aspects of the same goal, imo.

At code bottom there is a lot of detail, but I hope day to day users can 
ignore most of it. :-)

My aim is for this new functionality to be in usable alongside / along 
with the version.inc and setidtypes.inc proposals.

Bill P.

[William F Pokorny] Re: Thoughts on 'keyword_status()' functionality... [1109 days and 18 minutes ago]

Mon, 27 Mar 2023 20:16:29 GMT

On 3/26/23 15:22, Bald Eagle wrote:
> I would probably use it (often) if I could run a simple
> #if (keyword_status() > Threshold) check.

I'm now leaning toward the function name 'word_is()' because it leaves 
open the possibility for similarly named extensions.

I should perhaps have left the return value detail for later - 
especially given I'm still sorting it out.

---
Most day to day usage would be simple:

#declare MyStr = "lockandkey"

#if (word_is(MyStr)=0)
    #debug concat("No usage conflicts for '",MyStr,"'.\n")
#end

//--- or

#if (word_is(MyStr)!=0)
    #debug concat("Usage conflicts exist for '",MyStr,"'.\n")
#end

//--- or

#if (word_is(MyStr)>0)
    #debug concat("'",MyStr,"' is a part of this POV-Ray version.\n")
#end

Bill P.

[jr] Re: Thoughts on 'keyword_status()' functionality... [1109 days 9 hours and 19 minutes ago]

Mon, 27 Mar 2023 11:15:00 GMT

William F Pokorny <ano### [at] anonymousorg> wrote:
> ...
> Plus I've been thinking about the bigger picture of actual keywords,
> possible keywords, stand in internal keywords used for other purposes
> and functions. We have too the ini keywords and flags.
>
> As an initial proposal thinking about a new 'keyword_status()' function
> passed strings like "tau". It would return the following values for the
> status of various strings in answer to what meanings are relative to the
> version of code being run.
> ...
> Thoughts?

like BE I'm a little bewildered by the .. variety :-)  I think that this whole
issue needs to be tied in with the (proposed) 'versions.inc' and id type
checking/testing; all aspects of the same goal, imo.


regards, jr.

[Bald Eagle] Re: Thoughts on 'keyword_status()' functionality... [1110 days 1 hour and 9 minutes ago]

Sun, 26 Mar 2023 19:25:00 GMT

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

> -5 ==> ini keyword (cmd line flag ?) setting removed.
> -4 ==> lower case, shipped function looking like something inbuilt.
> -3 ==> deleted inbuilt function formerly defined in functions.inc.
> -2 ==> pseudo / hidden keyword removed.
> -1 ==> formerly visible and usable keyword removed.
>   0 ==> not now and never a keyword. Good to go.
> +1 ==> active SDL keyword.
> +2 ==> pseudo / hidden keywords active or potentially active on config.
> +3 ==> inbuilt function declared in functions.inc or cfunctions.inc.
> +4 ==> (povr never fakes inbuilt, lower case keywords with functions)
> +5 ==> current ini keyword (cmd line flag?) setting.
>
> (+-5 checking would be case insensitive)
>
> Actual keyword support in SDL is more complex because the meaning of
> keywords changes over time as functionality is added, removed or
> changed. Not thinking to try and document any of that drift in usage
> detail over time with keyword_status().
>
> The central aim is giving users a greater ability to check whether using
> any particular 'word' / 'keyword' in a scene has the potential to cause
> trouble or confusion.
>
> Thoughts?

I don't quite know what a few of those mean, but let me add some ideas here.

> The central aim is giving users a greater ability to check whether using any
particular 'word' / 'keyword' in a scene
 has the potential to cause trouble or confusion.

Yes.   And to that end, I would suggest a sort of stratifying - much like one
might do with memory, line-numbered code, or any other hierarchical structure.
So I don't really get why  -5 is where it is.

I would probably use it (often) if I could run a simple
#if (keyword_status() > Threshold) check.

So one thing to think about would be to space the values out a bit, so that you
can fill in other things that come up as time goes on.


-BW

[William F Pokorny] Thoughts on 'keyword_status()' functionality for... [1110 days 14 hours and 36 minutes ago]

Sun, 26 Mar 2023 05:58:10 GMT

In working recently with the povr fork to restore v3.7, v3.6 and prior, 
ID only checking behavior with the #ifdef(), #ifndef() and defined() 
keywords, the subject of keyword status checking in SDL came up again.

I've looked at the reserved word warning code in v3.8 and on.

Plus I've been thinking about the bigger picture of actual keywords, 
possible keywords, stand in internal keywords used for other purposes 
and functions. We have too the ini keywords and flags.

As an initial proposal thinking about a new 'keyword_status()' function 
passed strings like "tau". It would return the following values for the 
status of various strings in answer to what meanings are relative to the 
version of code being run.

-5 ==> ini keyword (cmd line flag ?) setting removed.
-4 ==> lower case, shipped function looking like something inbuilt.
-3 ==> deleted inbuilt function formerly defined in functions.inc.
-2 ==> pseudo / hidden keyword removed.
-1 ==> formerly visible and usable keyword removed.
  0 ==> not now and never a keyword. Good to go.
+1 ==> active SDL keyword.
+2 ==> pseudo / hidden keywords active or potentially active on config.
+3 ==> inbuilt function declared in functions.inc or cfunctions.inc.
+4 ==> (povr never fakes inbuilt, lower case keywords with functions)
+5 ==> current ini keyword (cmd line flag?) setting.

(+-5 checking would be case insensitive)

Actual keyword support in SDL is more complex because the meaning of 
keywords changes over time as functionality is added, removed or 
changed. Not thinking to try and document any of that drift in usage 
detail over time with keyword_status().

The central aim is giving users a greater ability to check whether using 
any particular 'word' / 'keyword' in a scene has the potential to cause 
trouble or confusion.

Thoughts?

Bill P.

[Alain Martel] Re: Suggest v4.0 ripples, waves re-work. (povr R... [1118 days and 38 minutes ago]

Sat, 18 Mar 2023 19:56:04 GMT

Le 2023-03-18 Ã  09:58, William F Pokorny a Ã©critÂ :
> There are a number of issues with the current ripples and waves 
> patterns. For the record, there is a set of two for normal{} 
> perturbation and another scalar value set of two for use with functions 
> and maps.
> 
> I've not yet pulled the number_of_waves code, but otherwise testing is 
> looking pretty good. The updated ripples code is roughly 18% slower and 
> the waves pattern about 20% slower for 10 sources.
> 
> The basic form of both support the keywords:
> 
> ripples & waves basic (ip_ means internal to pattern)
> ----------------------
> ip_seed <float> // Seed for point source locations.
> ip_count <number of sources> // Number of sources. 2-128 currently.
> ip_frequency <float>
> ip_phase <float>
> 
> 
> waves only basic (waves has always generated source weights/freq too)
> ---------------------
> lo <float> hi <float> // re-range inv weight 0-1.1 values to...
> 
> 
> ripples & waves extended (Use of keywords triggers the extended mode)
> --------------------
> ip_scale <3d vector>
> ip_fade_distance <float post ip_scale> // interior exp fade
> 
> 
> Example used for right side of attached image.
> -------------------
> #declare Fn00 = function { pattern {
>  Â Â Â  waves
>  Â Â Â  raw_wave // No attempt a heuristic in povr.
Adj on use.
>  Â Â Â  ip_frequency 2
>  Â Â Â  ip_count 14
>  Â Â Â  ip_seed e
>  Â Â Â  lo 0.3 hi 1.0Â  // Left side of
image didn't use this
>  Â Â Â  ip_scale <11,0.1,11>
>  Â Â Â  ip_fade_distance e
>  Â Â Â  scale <1/11,1,1/11>
> }}
> 
> I spent some time re-rendering a waves based isosurface using a scene 
> with a seed based upon now. Results are interesting. Some very good and 
> some kinda ugly due where the point sources ended up. If looking around 
> for a good seed, remember to print it out or otherwise
> save it for re-use! :-)
> 
> Plus, if thinking about, say, the surface of water, it helps quite a bit 
> to use ip_scale to compress / scale locations toward the plane of the 
> water.
> 
> Bill P.

Pretty interesting improvement upon the current ripples and waves patterns.

[William F Pokorny] Suggest v4.0 ripples, waves re-work. (povr R7 v0... [1118 days 6 hours and 36 minutes ago]

Sat, 18 Mar 2023 13:58:19 GMT

There are a number of issues with the current ripples and waves 
patterns. For the record, there is a set of two for normal{} 
perturbation and another scalar value set of two for use with functions 
and maps.

I've not yet pulled the number_of_waves code, but otherwise testing is 
looking pretty good. The updated ripples code is roughly 18% slower and 
the waves pattern about 20% slower for 10 sources.

The basic form of both support the keywords:

ripples & waves basic (ip_ means internal to pattern)
----------------------
ip_seed <float> // Seed for point source locations.
ip_count <number of sources> // Number of sources. 2-128 currently.
ip_frequency <float>
ip_phase <float>


waves only basic (waves has always generated source weights/freq too)
---------------------
lo <float> hi <float> // re-range inv weight 0-1.1 values to...


ripples & waves extended (Use of keywords triggers the extended mode)
--------------------
ip_scale <3d vector>
ip_fade_distance <float post ip_scale> // interior exp fade


Example used for right side of attached image.
-------------------
#declare Fn00 = function { pattern {
     waves
     raw_wave // No attempt a heuristic in povr. Adj on use.
     ip_frequency 2
     ip_count 14
     ip_seed e
     lo 0.3 hi 1.0  // Left side of image didn't use this
     ip_scale <11,0.1,11>
     ip_fade_distance e
     scale <1/11,1,1/11>
}}

I spent some time re-rendering a waves based isosurface using a scene 
with a seed based upon now. Results are interesting. Some very good and 
some kinda ugly due where the point sources ended up. If looking around 
for a good seed, remember to print it out or otherwise
save it for re-use! :-)

Plus, if thinking about, say, the surface of water, it helps quite a bit 
to use ip_scale to compress / scale locations toward the plane of the 
water.

Bill P.

[Kenneth] Re: Suggest v4.0 inbuilt complex functions. (pov... [1121 days 4 hours and 24 minutes ago]

Wed, 15 Mar 2023 16:10:00 GMT

William F Pokorny <ano### [at] anonymousorg> wrote:
>
> :-) How about a POV-Ray, user ink blot test image?
>

That is really interesting and fabulous! I can imagine all sorts of
different-looking and visually unexpected results from using this technique.

One possible use would be for texturing the walls in a room-- like wall paper.
Or for creating designs for floor rugs and carpets.

[Thomas de Groot] Re: Suggest v4.0 inbuilt complex functions. (pov... [1125 days 8 hours and 18 minutes ago]

Sat, 11 Mar 2023 12:15:41 GMT

Op 11-3-2023 om 10:17 schreef William F Pokorny:
> On 3/10/23 07:11, Thomas de Groot wrote:
>> Ooh! This one is nice! Going to download it: could be useful for 
>> something ðŸ˜‰
> 
> :-) How about a POV-Ray, user ink blot test image?
> 
> "That Looks like an ink blot test," is what I thought on getting the 
> result - and I'm never letting you all know I see in there! ;-)
> 
LOL! I wont either! ;-)

> Here again a complex function 'warp' acting on a small portion of a 
> photograph; where I also used those undocumented / hidden, image_map, 
> repeat and offset options.
> 
> 
Fascinating stuff indeed.

-- 
Thomas

[William F Pokorny] Re: Suggest v4.0 inbuilt complex functions. (pov... [1125 days 11 hours and 17 minutes ago]

Sat, 11 Mar 2023 09:17:19 GMT

On 3/10/23 07:11, Thomas de Groot wrote:
> Ooh! This one is nice! Going to download it: could be useful for 
> something ðŸ˜‰

:-) How about a POV-Ray, user ink blot test image?

"That Looks like an ink blot test," is what I thought on getting the 
result - and I'm never letting you all know I see in there! ;-)

Here again a complex function 'warp' acting on a small portion of a 
photograph; where I also used those undocumented / hidden, image_map, 
repeat and offset options.

Bill P.

[Thomas de Groot] Re: Suggest v4.0 inbuilt complex functions. (pov... [1126 days 8 hours and 23 minutes ago]

Fri, 10 Mar 2023 12:11:35 GMT

Op 10-3-2023 om 11:08 schreef William F Pokorny:
> On 3/9/23 20:51, Kenneth wrote:
>> I like the image itself, it's a very artistic-looking render. Like a 
>> painting.
>>
> 
> Thanks. :-)
> 
> I'll attach another I liked while playing. Same set up with complex 
> functions, but much lower power exponents. Plus adding in some spiral 
> action in the middle.
> 
> Another bit I stumbled across working with cf_pow() 'warping' is the 
> effective change in scaling from the origin outward makes it pretty easy 
> to set up images which change from a near constant color away from the 
> origin to something where the f_hash()-ing is clear.
> 
> In other words, when the changes in region due the f_hash(), and/or 
> higher cf_pow exponents, are happening at >>1 per pixel we end up with 
> kind of an aggregate color. As we move to the origin things spread out 
> and and we get a fade-in effect. FWIW, I guess, but neat. Hints at a 
> possible general technique with on top of f_hash() for fading in or out 
> of near constant colors.
> 
> Bill P.
> 

Ooh! This one is nice! Going to download it: could be useful for 
something ;-)

-- 
Thomas

[William F Pokorny] Re: Suggest v4.0 inbuilt complex functions. (pov... [1126 days 10 hours and 26 minutes ago]

Fri, 10 Mar 2023 10:08:23 GMT

On 3/9/23 20:51, Kenneth wrote:
> I like the image itself, it's a very artistic-looking render. Like a painting.
> 

Thanks. :-)

I'll attach another I liked while playing. Same set up with complex 
functions, but much lower power exponents. Plus adding in some spiral 
action in the middle.

Another bit I stumbled across working with cf_pow() 'warping' is the 
effective change in scaling from the origin outward makes it pretty easy 
to set up images which change from a near constant color away from the 
origin to something where the f_hash()-ing is clear.

In other words, when the changes in region due the f_hash(), and/or 
higher cf_pow exponents, are happening at >>1 per pixel we end up with 
kind of an aggregate color. As we move to the origin things spread out 
and and we get a fade-in effect. FWIW, I guess, but neat. Hints at a 
possible general technique with on top of f_hash() for fading in or out 
of near constant colors.

Bill P.

[Kenneth] Re: Suggest v4.0 inbuilt complex functions. (pov... [1126 days 18 hours and 39 minutes ago]

Fri, 10 Mar 2023 01:55:00 GMT

I like the image itself, it's a very artistic-looking render. Like a painting.

[William F Pokorny] Suggest v4.0 inbuilt complex functions. (povr R7... [1126 days 20 hours and 55 minutes ago]

Thu, 9 Mar 2023 23:39:31 GMT

In the past few years Ingo, Tor Olav and others have played around with 
include files supporting complex numbers for sound and images. Attached 
is an image using a few of 30 plus inbuilt complex functions added to 
the povr fork. Mostly just wrapping the complex functions coming with 
C++11, but sometimes using function names more in line with the existing 
complex includes and POV-Ray's function naming.

In povr, to work with the existing function vm, packing two 32 bit 
floats into a double space as the complex value and all complex function 
code runs at single float accuracy.

The render takes advantage of povr's big jitter and v3.8's ability to 
write png files at a reduced bit depth; I used +fn4 to get the file size 
down to something reasonable. Given the detail the image doesn't 
compress well.

Bill P.

//---
...
#include "functions.inc"
#include "cfunctions.inc"
#declare Fn00 = function { f_hash(y,Seed00,0.0005,0) }
#declare Pigm00 = pigment {
     function {
         Fn00(
             cf_real(cf_pow(cf_cmplx(abs(x),y),cf_cmplx(4.4,0))),
             cf_imag(cf_pow(cf_cmplx(abs(x),y),cf_cmplx(4.4,0))),
             z)
     }
     color_map {
     ...
     }
...
//---

cf_abs, cf_acos, cf_acosh, cf_add, cf_asin, cf_asinh, cf_atan,
cf_atanh, cf_cmplx, cf_conj, cf_cos, cf_cosh, cf_div, cf_exp,
cf_imag, cf_inv, cf_ln, cf_log, cf_mul, cf_neg, cf_norm, cf_phase,
cf_polar, cf_pow, cf_proj, cf_real, cf_sin, cf_sinh, cf_sqr,
cf_sqrt, cf_sub, cf_tan, cf_tanh

[William F Pokorny] Re: Testing povr / potential v4.0 functions and ... [1134 days 20 hours and 40 minutes ago]

Wed, 1 Mar 2023 23:53:45 GMT

On 3/1/23 01:38, William F Pokorny wrote:
> ...

Attaching a quick derivative doodle based on the posted code.

Plus, two notes regarding the code.

First, jr let me know what I posted for code won't run with the latest 
povr tarball posted on the newsgroups. The version.inc stuff being too 
new for starters. I am working toward an updated tarball, but it's 
taking some time.

Second, I made a small, non-fatal, editing mistake shortening some lines 
so they didn't wrap when posted. I should have kept 'pigment { Red }' 
and not 'color Red' - similarly for Green and Blue pigments. My tcl 
wrapper writes 'pigment { color Red }' trying to be clear though the 
'color' token isn't strictly needed as the parser understands what Red is.

Bill P.

[William F Pokorny] Testing povr / potential v4.0 functions and inbu... [1135 days 13 hours and 55 minutes ago]

Wed, 1 Mar 2023 06:38:56 GMT

I'm attaching a test image of two inter-twined isosurfaces and the full 
scene file for reference. One isosurface has 16 wires rotating about z 
one way; the second has another 16 wires rotating the opposite way.

The newer povr functions are naturally able to calculate values suited 
for isosurfaces by default, but where possible they also have a mode 
which returns map values. The map values making it much easier to use 
*_maps on the isosurfaces in a way which always tracks the isosurface 
shape perturbations.

You can code up parallel map value calculations manually, but having 
done it myself for many years - it's a real pain to keep straight.

In this test case I primarily wanted to try passing the map values up 
from somewhere relatively low in the function call chain. The new 
functions were coded with the intent this would work, but I'd not 
actually tried a scene doing it. Looks OK to me.

Oh! FYI. On my old i3 the two isosurfaces render in about 35 seconds 
with one light no AA and no radiosity. With AA and radiosity active and 
set to be of relatively high quality, the render takes about 45 minutes.

Bill P.

[William F Pokorny] Using f_planar() v4.0 proposal with 3 cos Fn. [1144 days 6 hours and 39 minutes ago]

Mon, 20 Feb 2023 13:55:16 GMT

Another advert for a new v4.0 inbuilt function.

The f_planar() function in povr can be used to mimic the inbuilt planar 
pattern with:

function { -max(0.0,f_planar(y,1,1)) }

However, as an inbuilt function, f_planar() can more generically create 
shells about a function's roots. The f_planar() function 'fattens' the 
surface-root creating a new shell function from the original function-shape:

// Below works only with povr fork.
...
#include "functions.inc"
// Function f_planar defined in functions.inc
#declare Fn03 = function (x,y,z) { (cos(x) + cos(y) + cos(z))*(1/3) }
#declare Fn05 = function (x,y,z) {
     f_planar(Fn03(x*10,y*10,z*10),0.050,1)
}
#declare Iso99 = isosurface {
     function { Fn05(x,y,z) }
     contained_by { box { <-0.95,-0.175,-0.95>,<0.95,0.175,0.95> } }
...

Bill P.

[William F Pokorny] Re: Playing with suggested v4.0 f_boxb and three... [1144 days 6 hours and 43 minutes ago]

Mon, 20 Feb 2023 13:50:49 GMT

On 2/19/23 14:38, Bald Eagle wrote:
> That looks cool.

Thanks.

> 
> Now all you need to do is interlace that function with some white ovoids with
> micronormals, and you sell those by the case for $50+ each.

:-)

---

 > Aside: The gradient of "cos(x) + cos(y) + cos(z)" is relatively high
 > as isosurface functions go.

Aside to my aside... We can lower the gradient in the above case. By 
noticing the function values swing between -3 and 3 in a symmetrical 
way, we can code:

#declare Fn03 = function (x,y,z) {
     (cos(x) + cos(y) + cos(z))*(1/3)
}

Which re-maps the values to -1 to 1. Why not *1/9 you ask for an even 
lower gradient? Well, you can, but it gets to be a gradient game with 
isosurfaces after some point. It tends' to help to get everything into a 
more common value space - and I aim for -1 to 1 as a rule - as in that 
space functions tend to play better together.

Bill P.

[Bald Eagle] Re: Playing with suggested v4.0 f_boxb and three... [1145 days and 54 minutes ago]

Sun, 19 Feb 2023 19:40:00 GMT

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

> f_boxb() is a function which takes another function as an input and
> encloses it in a box which in part or in total is expected to be smaller
> than the isosurface contained_by shape.
>
> The contained_by shape can itself be used to clip away sides of the now
> boxed original function to expose an inner structure. I did this on the
> top and front in the attached image.

That looks cool.

Now all you need to do is interlace that function with some white ovoids with
micronormals, and you sell those by the case for $50+ each.

[William F Pokorny] Playing with suggested v4.0 f_boxb and three cos... [1145 days 15 hours and 56 minutes ago]

Sun, 19 Feb 2023 04:38:13 GMT

In newusers there was recently a post about creating an isosurface with 
the function "cos(x) + cos(y) + cos(z)". I decided to grab that function 
and play with the new to povr fork's f_boxb(). A function intended for 
use in specifically with isosurfaces.

f_boxb() is a function which takes another function as an input and 
encloses it in a box which in part or in total is expected to be smaller 
than the isosurface contained_by shape.

The contained_by shape can itself be used to clip away sides of the now 
boxed original function to expose an inner structure. I did this on the 
top and front in the attached image.

Bill P.

Aside: The gradient of "cos(x) + cos(y) + cos(z)" is relatively high as 
isosurface functions go.

// Code ONLY works with the povr fork
...
#include "functions.inc"
// Function f_boxb defined in functions.inc
#declare Fn03 = function (x,y,z) { (cos(x) + cos(y) + cos(z))*-1 }
#declare Fn04 = function (x,y,z) {
     f_boxb(x,y,z,0.6,0.667,1,-0.02,0,0,Fn03(x*20,y*20,z*20),0.010)
}
#declare Iso99 = isosurface {
     function { Fn04(x,y,z) }
     contained_by { box { <-1,-1,-0.95>,<1,1/3,1> } }
     threshold 0
     accuracy 0.00017
     max_gradient 33.3
}
#declare SorrellBrown = srgb <0.80784,0.72549,0.56078>;
#declare Pigment02 = pigment { color SorrellBrown }
#declare Normal02 = normal { granite  0.31 scale 0.177 }
#declare Finish02 = finish { phong 0.33 }
#declare Texture02 = texture {
     pigment { Pigment02 }
     finish { Finish02 }
     normal { Normal02 }
}
#declare Obj02 = object { Iso99 texture { Texture02 } }
...

[yesbird] Re: Height_fields and using wave modifiers. [1150 days 1 hour and 34 minutes ago]

Tue, 14 Feb 2023 19:00:00 GMT

> Attached is an image of 8 height_fields based upon a based on the
> granite pattern. Seven use only wave modifiers to change up the terrain.
> One uses a warp of directional turbulence.

This is a royal gift ! Can't stop playing with them:

------------------------------------------------------
#include "colormaps.inc" // From here: https://github.com/syanenko/colormaps

#version 3.8;
global_settings { assumed_gamma 1 }


camera
{ location <1,1,1> * 2
  look_at <0,0,0>
  angle 50
}


light_source { <10,10,10>, rgb <1,1,1> }


// The core code for reference.
#declare FnBase    = function { pattern {
         granite scale 0.7
         warp {
 turbulence <0.25,0.05,0> octaves 4 omega 0.6 lambda 2.3
 }
 }
     }
#declare FnCubic   = function { pattern {
         // Povr's cubic_wave changed from POV-Ray's
         granite cubic_wave phase 0.3 frequency 1.77 scale 0.7 }
     }
#declare FnSine    = function { pattern {
         granite sine_wave scale 0.7 }
     }
#declare FnScallop = function { pattern {
         granite scallop_wave scale 0.7 }
     }
#declare FnTri     = function { pattern {
         granite triangle_wave scale 0.7 }
     }
#declare FnTriInv  = function { pattern {
         // Povr added an inverse wave modifier
         granite triangle_wave scale 0.7 }
     }
#declare FnPoly2_0 = function { pattern {
         granite poly_wave 2.0 scale 0.7 }
     }
#declare FnPoly0_2 = function { pattern {
         granite poly_wave 0.2 scale 0.7 }
     }
//---------
#declare Orange = srgb <1,0.50196,0>;
#declare HF_Base = height_field {
     function 800, 800 { FnBase(x,y,z) }
     smooth  // With smooth runs faster.
     scale <1,0.1,1>
     pigment { gradient y
               color_map  {jet}
               scale 0.15 }
}
#declare Acorn = srgb <0.41569,0.36471,0.10588>;
#declare HF_Cubic = height_field {
     function 800, 800 { FnCubic(x,y,z) }
     smooth  // With smooth runs faster.
     scale <1,0.1,1>
     pigment { gradient y
               color_map  {spring}
               scale 0.15 }
}
#declare Akaroa = srgb <0.83137,0.76863,0.65882>;
#declare HF_Sine = height_field {
     function 800, 800 { FnSine(x,y,z) }
     smooth  // With smooth runs faster.
     scale <1,0.1,1>
     pigment { gradient y
               color_map  {hot}
               scale 0.15 }
}
#declare Alpine = srgb <0.68627,0.56078,0.17255>;
#declare HF_Scallop = height_field {
     function 800, 800 { FnScallop(x,y,z) }
     smooth  // With smooth runs faster.
     scale <1,0.15,1>
     pigment { gradient y
               color_map  {winter}
               scale 0.04 }
}
#declare Amazonite = srgb <0,0.76863,0.6902>;
#declare HF_Tri = height_field {
     function 800, 800 { FnTri(x,y,z) }
     smooth  // With smooth runs faster.
     scale <1,0.1,1>
     pigment { gradient y
               color_map  {hsv}
               scale 0.15 }
}
#declare AndroidGreen = srgb <0.64314,0.77647,0.22353>;
#declare HF_TriInv = height_field {
     function 800, 800 { FnTriInv(x,y,z) }
     smooth  // With smooth runs faster.
     scale <1,0.15,1>
     pigment { gradient y
               color_map  {autumn}
               scale 0.05 }
}
#declare Apricot0 = srgb <0.92157,0.57647,0.45098>;
#declare HF_Poly2_0 = height_field {
     function 800, 800 { FnPoly2_0(x,y,z) }
     smooth  // With smooth runs faster.
     scale <1,0.1,1>
     pigment { gradient y
               color_map  {parula}
               scale 0.15 }
}
#declare AppleBlossom = srgb <0.68627,0.30196,0.26275>;
#declare HF_Poly0_2 = height_field {
     function 800, 800 { FnPoly0_2(x,y,z) }
     smooth  // With smooth runs faster.
     scale <1,0.4,1>
     pigment { gradient y
               color_map  {summer}
               scale 0.1 }
}
//---------
#declare Union00 = union {

     object { HF_Base }
     object { HF_Cubic   translate <-1.0,0,0>}
     object { HF_Sine    translate <-0.5,0,1> }
     object { HF_Scallop translate <-2.0,0,-0.5> }
     object { HF_Tri     translate <-1.0,0,-1> }
     object { HF_TriInv  translate <0,0,-1> }
     object { HF_Poly2_0 translate <-0.5,0,-2>}
     object { HF_Poly0_2 translate <1,0,-0.5> }

}
object {Union00}
------------------------------------------------------
YB

[yesbird] Re: Height_fields and using wave modifiers. [1150 days 1 hour and 39 minutes ago]

Tue, 14 Feb 2023 18:55:00 GMT

> Attached is an image of 8 height_fields based upon a based on the
> granite pattern.

This is a royal gift ! Can't stop playing with them:
------------------------------------------------------
#include "colormaps.inc" // From here: https://github.com/syanenko/colormaps

#version 3.8;
global_settings { assumed_gamma 1 }


camera
{ location <1,1,1> * 2
  look_at <0,0,0>
  angle 50
}


light_source { <10,10,10>, rgb <1,1,1> }


// The core code for reference.
#declare FnBase    = function { pattern {
         granite scale 0.7
         warp {
 turbulence <0.25,0.05,0> octaves 4 omega 0.6 lambda 2.3
 }
 }
     }
#declare FnCubic   = function { pattern {
         // Povr's cubic_wave changed from POV-Ray's
         granite cubic_wave phase 0.3 frequency 1.77 scale 0.7 }
     }
#declare FnSine    = function { pattern {
         granite sine_wave scale 0.7 }
     }
#declare FnScallop = function { pattern {
         granite scallop_wave scale 0.7 }
     }
#declare FnTri     = function { pattern {
         granite triangle_wave scale 0.7 }
     }
#declare FnTriInv  = function { pattern {
         // Povr added an inverse wave modifier
         granite triangle_wave scale 0.7 }
     }
#declare FnPoly2_0 = function { pattern {
         granite poly_wave 2.0 scale 0.7 }
     }
#declare FnPoly0_2 = function { pattern {
         granite poly_wave 0.2 scale 0.7 }
     }
//---------
#declare Orange = srgb <1,0.50196,0>;
#declare HF_Base = height_field {
     function 800, 800 { FnBase(x,y,z) }
     smooth  // With smooth runs faster.
     scale <1,0.1,1>
     pigment { gradient y
               color_map  {jet}
               scale 0.15 }
}
#declare Acorn = srgb <0.41569,0.36471,0.10588>;
#declare HF_Cubic = height_field {
     function 800, 800 { FnCubic(x,y,z) }
     smooth  // With smooth runs faster.
     scale <1,0.1,1>
     pigment { gradient y
               color_map  {spring}
               scale 0.15 }
}
#declare Akaroa = srgb <0.83137,0.76863,0.65882>;
#declare HF_Sine = height_field {
     function 800, 800 { FnSine(x,y,z) }
     smooth  // With smooth runs faster.
     scale <1,0.1,1>
     pigment { gradient y
               color_map  {hot}
               scale 0.15 }
}
#declare Alpine = srgb <0.68627,0.56078,0.17255>;
#declare HF_Scallop = height_field {
     function 800, 800 { FnScallop(x,y,z) }
     smooth  // With smooth runs faster.
     scale <1,0.15,1>
     pigment { gradient y
               color_map  {winter}
               scale 0.04 }
}
#declare Amazonite = srgb <0,0.76863,0.6902>;
#declare HF_Tri = height_field {
     function 800, 800 { FnTri(x,y,z) }
     smooth  // With smooth runs faster.
     scale <1,0.1,1>
     pigment { gradient y
               color_map  {hsv}
               scale 0.15 }
}
#declare AndroidGreen = srgb <0.64314,0.77647,0.22353>;
#declare HF_TriInv = height_field {
     function 800, 800 { FnTriInv(x,y,z) }
     smooth  // With smooth runs faster.
     scale <1,0.15,1>
     pigment { gradient y
               color_map  {autumn}
               scale 0.05 }
}
#declare Apricot0 = srgb <0.92157,0.57647,0.45098>;
#declare HF_Poly2_0 = height_field {
     function 800, 800 { FnPoly2_0(x,y,z) }
     smooth  // With smooth runs faster.
     scale <1,0.1,1>
     pigment { gradient y
               color_map  {parula}
               scale 0.15 }
}
#declare AppleBlossom = srgb <0.68627,0.30196,0.26275>;
#declare HF_Poly0_2 = height_field {
     function 800, 800 { FnPoly0_2(x,y,z) }
     smooth  // With smooth runs faster.
     scale <1,0.4,1>
     pigment { gradient y
               color_map  {summer}
               scale 0.1 }
}
//---------
#declare Union00 = union {

     object { HF_Base }
     object { HF_Cubic   translate <-1.0,0,0>}
     object { HF_Sine    translate <-0.5,0,1> }
     object { HF_Scallop translate <-2.0,0,-0.5> }
     object { HF_Tri     translate <-1.0,0,-1> }
     object { HF_TriInv  translate <0,0,-1> }
     object { HF_Poly2_0 translate <-0.5,0,-2>}
     object { HF_Poly0_2 translate <1,0,-0.5> }

}
object {Union00}
------------------------------------------------------
YB

[William F Pokorny] Re: Height_fields and using wave modifiers. [1150 days 2 hours and 2 minutes ago]

Tue, 14 Feb 2023 18:31:56 GMT

On 2/14/23 13:23, yesbird wrote:
> Nice ! Got it and put to my collection, but
> 
>> granite triangle_wave inverse scale 0.7 }
> 
> gives parsing error (on 3.7 and 3.8) - "inverse" is the reason.
> --
> YB
> 
:-) Yes, inverse as a wave modifier is a povr fork extension and a 
proposed idea for v4.0 (though yep that v4.0 bit of pipe dream at the 
moment).

Delete it to run on regular releases.

Note povr's cubic_wave is also different, but it should run as coded - 
it'll look a little different.

Bill P.

[yesbird] Re: Height_fields and using wave modifiers. [1150 days 2 hours and 9 minutes ago]

Tue, 14 Feb 2023 18:25:00 GMT

Nice ! Got it and put to my collection, but

> granite triangle_wave inverse scale 0.7 }

gives parsing error (on 3.7 and 3.8) - "inverse" is the reason.
--
YB

[William F Pokorny] Height_fields and using wave modifiers. [1150 days 2 hours and 43 minutes ago]

Tue, 14 Feb 2023 17:50:39 GMT

In povray.general there's been a recent discussion on using functions to 
define height fields on the fly. I had the thought height_fields a good 
way to see how wave modifiers and warps can be used to change up 
patterns and 'terrain' too.

Attached is an image of 8 height_fields based upon a based on the 
granite pattern. Seven use only wave modifiers to change up the terrain. 
One uses a warp of directional turbulence.

Posting in this pov4 forum due using a couple of povr specific wave 
modifier updates. The ideas apply to official POV-Ray releases too.

Bill P.



// The core code for reference.
#declare FnBase    = function { pattern {
        	granite scale 0.7
         warp {
	turbulence <0.25,0.05,0> octaves 4 omega 0.6 lambda 2.3
	}
	}
     }
#declare FnCubic   = function { pattern {
         // Povr's cubic_wave changed from POV-Ray's
         granite cubic_wave phase 0.3 frequency 1.77 scale 0.7 }
     }
#declare FnSine    = function { pattern {
         granite sine_wave scale 0.7 }
     }
#declare FnScallop = function { pattern {
         granite scallop_wave scale 0.7 }
     }
#declare FnTri     = function { pattern {
         granite triangle_wave scale 0.7 }
     }
#declare FnTriInv  = function { pattern {
         // Povr added an inverse wave modifier
         granite triangle_wave inverse scale 0.7 }
     }
#declare FnPoly2_0 = function { pattern {
         granite poly_wave 2.0 scale 0.7 }
     }
#declare FnPoly0_2 = function { pattern {
         granite poly_wave 0.2 scale 0.7 }
     }
//---------
#declare Orange = srgb <1,0.50196,0>;
#declare HF_Base = height_field {
     function 800, 800 { FnBase(x,y,z) }
     smooth  // With smooth runs faster.
     scale <1,0.05,1>
     pigment { color Orange }
}
#declare Acorn = srgb <0.41569,0.36471,0.10588>;
#declare HF_Cubic = height_field {
     function 800, 800 { FnCubic(x,y,z) }
     smooth  // With smooth runs faster.
     scale <1,0.05,1>
     pigment { color Acorn }
}
#declare Akaroa = srgb <0.83137,0.76863,0.65882>;
#declare HF_Sine = height_field {
     function 800, 800 { FnSine(x,y,z) }
     smooth  // With smooth runs faster.
     scale <1,0.05,1>
     pigment { color Akaroa }
}
#declare Alpine = srgb <0.68627,0.56078,0.17255>;
#declare HF_Scallop = height_field {
     function 800, 800 { FnScallop(x,y,z) }
     smooth  // With smooth runs faster.
     scale <1,0.05,1>
     pigment { color Alpine }
}
#declare Amazonite = srgb <0,0.76863,0.6902>;
#declare HF_Tri = height_field {
     function 800, 800 { FnTri(x,y,z) }
     smooth  // With smooth runs faster.
     scale <1,0.05,1>
     pigment { color Amazonite }
}
#declare AndroidGreen = srgb <0.64314,0.77647,0.22353>;
#declare HF_TriInv = height_field {
     function 800, 800 { FnTriInv(x,y,z) }
     smooth  // With smooth runs faster.
     scale <1,0.05,1>
     pigment { color AndroidGreen }
}
#declare Apricot0 = srgb <0.92157,0.57647,0.45098>;
#declare HF_Poly2_0 = height_field {
     function 800, 800 { FnPoly2_0(x,y,z) }
     smooth  // With smooth runs faster.
     scale <1,0.05,1>
     pigment { color Apricot0 }
}
#declare AppleBlossom = srgb <0.68627,0.30196,0.26275>;
#declare HF_Poly0_2 = height_field {
     function 800, 800 { FnPoly0_2(x,y,z) }
     smooth  // With smooth runs faster.
     scale <1,0.05,1>
     pigment { color AppleBlossom }
}
//---------
#declare Union00 = union {
     object { HF_Base }
     object { HF_Cubic   translate <-1.0,0,0>}
     object { HF_Sine    translate <-0.5,0,1> }
     object { HF_Scallop translate <-2.0,0,-0.5> }
     object { HF_Tri     translate <-1.0,0,-1> }
     object { HF_TriInv  translate <0,0,-1> }
     object { HF_Poly2_0 translate <-0.5,0,-2>}
     object { HF_Poly0_2 translate <1,0,-0.5> }
}

[Bald Eagle] Re: NVIDIA vulkan and POV-Ray [1251 days 3 hours and 9 minutes ago]

Sat, 5 Nov 2022 17:25:00 GMT

Alain Martel <kua### [at] videotronca> wrote:
> Le 2022-11-04 à 15:40, rodv92 a écrit :
> > I keep on watching the speed at which real time GPU ray tracing / light
> > transport technology advances.
> > It seems quite amazing.

> GPU render assume that everything will use the same code : The code for
> a mesh of polygons. That assumption comes from the obligation to use the
> same code for all cores.
> POV Ray use many primitives. All of the primitives need to use their own
> code. So, a GPU version of POV Ray could only deal with one primitive
> type at a time. Render all the spheres, then, render all the boxes, then
> the torus, then the cones and cylinders, then...

Well that, or code a fork that converts all the primitives into polygon meshes
before rendering.  Or just add in mesh alternatives for all of the primitives in
case someone wants to use them...  It probably can't be that hard to copy most
of the primitives into macro-driven mesh alternatives, especially since most of
them could just be rendered as parametric surfaces that are made with triangle{}
or mesh{} or mesh2{} objects, not the parametric{}.   Then you could just use
the same macro code and pass in the relevant equations for x, y, and z as
arguments.

[Alain Martel] Re: NVIDIA vulkan and POV-Ray [1251 days 5 hours and 13 minutes ago]

Sat, 5 Nov 2022 15:21:32 GMT

Le 2022-11-04 Ã  15:40, rodv92 a Ã©critÂ :
> I keep on watching the speed at which real time GPU ray tracing / light
> transport technology advances.
> It seems quite amazing.
> 
> 
> 
> So, let's say hypothetically at what version POV-ray would have to fork so that
> its SDL is entirely covered by NVIDIA Vulkan Ray Tracing API as of today ?
> 
> I am currently reading that tutorial
> https://nvpro-samples.github.io/vk_raytracing_tutorial_KHR/
> 
> the tutorial specifies : plain colors, textures, diffuse and specular
> reflections, lighting. no transparency for now.
> Seems we are in povray 1.0 territory.
> 
> I will browse the reference to see if there are now more documented features
> since the tutorial webpage date is May 2020)
> 
> The goal being to make both rendering pipelines meet where the least of code is
> required for the glue.
> 
> I think i will try a hello world by converting biscuit.pov into Vulkan TLAS/BLAS
> and trying a render.
> 
> 
> To be honest, I think it is a matter of a couple of years that fast GPU assisted
> ray traced
> render is achieved at the levels of POV Ray 3.6, since in December 2020 Nvidia
> was already implementing caustics (using POV-Ray as a reference on the matter by
> the way)
> 
>
https://developer.nvidia.com/blog/generating-ray-traced-caustic-effects-in-unreal-engine-4-part-1/
> 
> let's be clear rendering time is the top factor in the game now. Always has
> been.
> 
> As a reference and a dean in the game of RAY tracing, I think that porting
> POV-Ray SDL to the recent hardware advancement is fair game, could be done as a
> tribute, that NVIDIA could even handle in part, but that's more of a political
> issue, and it's just an humble advice, since the workload could be quite big.
> 
> 
> 
> It is probable the that NVIDIA engineers browse POV-Ray codebase.
> Maybe there is a possibility to make the Vulkan ray tracing capabilities grow in
> tandem with  those of povray. so that porting would be easier.
> 
> If there is one thing that would be an absolute hit, it is a povray 4.0 renderer
> that renders in an instant, even if some SDL directives have to be ignored for
> that at the moment.
> 
> What do you think ?
> 
> 
> 
> 
GPU render assume that everything will use the same code : The code for 
a mesh of polygons. That assumption comes from the obligation to use the 
same code for all cores.
POV Ray use many primitives. All of the primitives need to use their own 
code. So, a GPU version of POV Ray could only deal with one primitive 
type at a time. Render all the spheres, then, render all the boxes, then 
the torus, then the cones and cylinders, then...

[rodv92] NVIDIA vulkan and POV-Ray [1252 days and 49 minutes ago]

Fri, 4 Nov 2022 19:45:00 GMT

I keep on watching the speed at which real time GPU ray tracing / light
transport technology advances.
It seems quite amazing.

So, let's say hypothetically at what version POV-ray would have to fork so that
its SDL is entirely covered by NVIDIA Vulkan Ray Tracing API as of today ?

I am currently reading that tutorial
https://nvpro-samples.github.io/vk_raytracing_tutorial_KHR/

the tutorial specifies : plain colors, textures, diffuse and specular
reflections, lighting. no transparency for now.
Seems we are in povray 1.0 territory.

I will browse the reference to see if there are now more documented features
since the tutorial webpage date is May 2020)

The goal being to make both rendering pipelines meet where the least of code is
required for the glue.

I think i will try a hello world by converting biscuit.pov into Vulkan TLAS/BLAS
and trying a render.

To be honest, I think it is a matter of a couple of years that fast GPU assisted
ray traced
render is achieved at the levels of POV Ray 3.6, since in December 2020 Nvidia
was already implementing caustics (using POV-Ray as a reference on the matter by
the way)

https://developer.nvidia.com/blog/generating-ray-traced-caustic-effects-in-unreal-engine-4-part-1/

let's be clear rendering time is the top factor in the game now. Always has
been.

As a reference and a dean in the game of RAY tracing, I think that porting
POV-Ray SDL to the recent hardware advancement is fair game, could be done as a
tribute, that NVIDIA could even handle in part, but that's more of a political
issue, and it's just an humble advice, since the workload could be quite big.

It is probable the that NVIDIA engineers browse POV-Ray codebase.
Maybe there is a possibility to make the Vulkan ray tracing capabilities grow in
tandem with those of povray. so that porting would be easier.

If there is one thing that would be an absolute hit, it is a povray 4.0 renderer
that renders in an instant, even if some SDL directives have to be ignored for
that at the moment.

What do you think ?

[Chris R] Dynamically loadable internal functions [1493 days 2 hours and 29 minutes ago]

Tue, 8 Mar 2022 18:05:00 GMT

I have noticed discussions about employing dynamic library loading for a number
of topics, including loading other modeling language formats.

Has there been any thought to allowing the addition of new internal functions
coded in C via dynamic libraries?  It seems like there are a lot of branches on
the POV-Ray code to add new ones, but rather than rebuilding the whole thing for
every new function, would it make sense to just load them at runtime?

-- Chris R

[William F Pokorny] Notes on povr performance analysis related to po... [1512 days 16 hours and 59 minutes ago]

Thu, 17 Feb 2022 03:34:57 GMT

Attaching my notes looking at the performance impacts for a set of povr 
changes since last October at the expected compile and link options for 
best general povr performance.

Quickly:

The work to eliminate useless zeroing of vector components - always 
faster. (-0.1% to -4.7%)

Moving the bounding from floats to doubles (calc today always? doing 
type conversions float->double->float) is usually faster for scenes 
already heavily leaning on bounding for good performance (-0.3% to 
-16.9%). However, some scenes are slower (+1.8% to +2.9%). Accuracy of 
course better. Likely actual CPU hardware will also affect results.

The fix to avoid floating point exceptions into intersect_BBox so we can 
continue to use -ffast-math is - almost always - somewhat expensive 
(+0.4% +3.4%). Cost always much smaller than the typical -ffast-math gains.

The file has some information looking at certain shapes with the 
intersect_BBox code bypassed and not. Recommend a re-evaluation of what 
shapes bypass the mechanism hard coded set up.

Aside: The earlier look at parser symtable performance improvements not 
looked at for this analysis because I've not decided to adopt the 
changes for povr. The speed up method is kinda clunky.

Bill P.

[William F Pokorny] Suggested v4.0 changes to reflection where pertu... [1526 days 6 hours and 50 minutes ago]

Thu, 3 Feb 2022 13:44:34 GMT

New keyword as in: reflection { ... inv_pnormal_cure 4 }

Regarding the reflected ray adjustments with any normal{} block 
resulting in inverted reflected rays as compared to the raw surface 
normals. These should be extended and brought out as a set of options. 
It is confusing when such actions are done in silence. The associated 
code can currently be found in Trace::ComputeReflection().

The povr branch is using a new keyword called inv_pnormal_cure which 
takes a float argument. The integer portion chooses one of seven 'cures' 
currently.  The fractional digits following the decimal point are used 
only with cure 5 as the probability of the reflected ray being generated 
in a direction opposed to the incoming perturbed normal direction.

If you have no normal{} block in the texture, only Fix0 runs and in 
result it does nothing. In other words, there will be no modifications 
to reflected rays by ComputeReflection unless a normal{} block is used. 
Where normal{} and there are already near tangent ray surface 
interactions (a sphere at the edges) the fixes start fixing on any 
non-zero bump size.

------- povr's current cures

Fix0 - This is itself a fix of sorts and it predates the 1998 v3.1 Fix1. 
All generated reflected rays are calculated as if no perturbed normals 
invert with respect to the raw surface normal. We can still see through 
the shape at large bump sizes and this what Fix1 and Fix3 were created 
to address. However, these surface piercing rays are always inside the 
negative half plane of the raw normal.

Fix1 - Since 1998 (added to v3.1). In total it is Fix0 above followed, 
potentially, by Fix2 or Fix3. The break out between whether to apply 
Fix2 or Fix3 is made by testing the Fix0 generated ray against the 
perturbed normal direction.

Fix2 - New to povr. Runs Fix0 and then on seeing the reflected ray still 
in an inverted relation to the raw surface normal it applies another 
calculation which moves the generated reflected ray another step toward 
the raw normal direction. The comments call this a double reflection, 
and it might be for specific surface structure assumptions, but in 
general, it's more of a heuristic fix.

Fix3 - New to povr. Runs Fix0 and then on seeing the reflected ray still 
in an inverted relation to the raw surface, it dumps the current 
reflected ray for a new one calculated with the raw surface normal. 
These reflected rays, to the degree they appear in the total ray color 
result, will appear as if no normal{} block was used. In other words, on 
increasing bump sizes it can be this fix partly ignores the expected 
normal{} effect.

Fix4 - New to povr. This result likely the one intuitively expected with 
larger normal bump sizes. This fix, partly, modifies the Fix0 changes 
such that where the perturbed normal is inverted with respect to the raw 
surface normal the generated reflected ray respects the perturbed normal 
direction. We start to see through the surface as might happen with a 
mesh of wires or a cloth weave. The results here sometimes look quite 
like Fix0 alone at a macro level, but the rays going into the shape here 
are those with perturbed normals inverted with respect to the raw. The 
reflection effect is at a macro level somewhat darker. How much Fix0 
differs from this Fix4, depends on the scene set up.

Fix5 - New to povr. Applies Fix0 and then inverts a portion of the 
reflected rays through the surface using a [0..1) probability specified 
in the fractional part of the passed float value. Think of more porous 
surfaces (being faked by solid ones) where rays can reflect past the 
surface intersection.

Fix11 - This Fix1, but where the internal Fix2 and Fix3 are applied in 
reverse of the long standing test. The result I think less physically 
accurate, but it does tend to better delineate the edges / near tangent 
regions. It's here for effects.


Background
----------

While working on a micro normal pattern for the povr branch, larger bump 
sizes were found to unexpected return non-blurred reflections mixed in 
with extremely blurred ones. Detailed above, found that reflection 
adjustments have been in play a long time.

One sphere with reflection within sky_sphere. Fix1 = Fix0->(Fix2 | Fix3)

Fix0 - Never treat the perturbed normal as inverted with respect to raw.

Fix2 - The double correction / reflection.

Fix3 - Glass marble look due dropping back to raw normal use.

Looking at what povr leaves available as Fix1 using the micro pattern 
and differing bump sizes we see while Fix2 and Fix3 come into play at 
even small bump sizes, but the effect is small until the bump sizes get 
up around 0.5.  What happens will of course vary greatly with the 
normal{} pattern and surface particulars.

Reflected rays
---
---------------------    Orig   Fix0   Fix2   Fix3
normal { micro 0.00 }  655360 655360      0      0 100%  0%  0%
normal { micro 0.01 }  655360 655317     10     33 100%  0%  0%
normal { micro 0.10 }  655360 651450    976   2934  99%  0%  0%
normal { micro 0.25 }  655360 631096   6162  18102  96%  1%  3%
normal { micro 0.50 }  655360 557621  24868  72871  85%  4% 11%
normal { micro 0.75 }  655360 444730  57817 152813  68%  9% 23%
normal { micro 1.00 }  655360 327379 106134 221847  50% 16% 34%
normal { micro 1.25 }  655360 275507 138012 241841  42% 21% 37%
normal { micro 1.50 }  655360 252949 153439 248972  39% 23% 38%
normal { micro 1.75 }  655360 241388 163163 250809  37% 25% 38%
normal { micro 2.00 }  655360 234691 170364 250305  36% 26% 38%
normal { micro 3.00 }  655360 224005 187031 244324  34% 29% 37%
normal { micro 4.00 }  655360 221058 195115 239187  34% 30% 36%
normal { micro 5.00 }  655360 219605 200161 235594  34% 31% 36%
normal { micro 9.00 }  655360 218117 208661 228582  33% 32% 35%

Attached is an image with povr's cure set 0-5,11 top to bottom.  The 
bump size columns run 0, 0.05, 0.5 and 2.0 left to right. The entire 
grid is repeated on the right with heavy AA showing more of the expected 
normal micro pattern result.

Using two spheres, not hollow, with an orange-red emitting sphere just 
inside each. The more yellow is the exterior texture and the blur the 
interior_texture. The top row is the pre 1998 fix result and the red 
shows what I take to have been "fixed." Namely, without that fix, and 
with large bump sizes, you do see through the surface to the inner 
sphere despite 'effectively' correcting the perturbed normals with 
respect to the raw normals. Fix4 / Cure 4, looks similar with this set 
up, but it uses the flipped to raw normal perturbed normals straight up 
to create the reflected rays.

Bill P.

[William F Pokorny] Re: Suggested v4.0 patch for openexr read where ... [1536 days 8 hours and 40 minutes ago]

Mon, 24 Jan 2022 11:54:10 GMT

On 1/23/22 18:57, William F Pokorny wrote:
...
> Found where incoming exr files are at floats and the file has channel 
> values larger than about 2^16 we end up with +inf color channel values 
> internally.
...

I forgot to mention, should you run into one of these exr files with 
values too large for POV-Ray's current exr reader, you can use 
converters to get to an hdr file.

I was able to use: 'iconvert sunflowers_4k.exr sunflowers_4k.hdr'

The openimageio-tools based tooling is able to handle the >2^16 channel 
values and appears to correctly convert to 'workable' hdr files(a)(b).

Bill P.

(a) - An attempt to use incovert from full float encoding to half float 
ran and looks OK external to POV-Ray in that the values are reduced to 
what fits in a half float. However, on attempting to use the half float 
form HDRI, I still had the speckling problem - though the signature of 
the speckles was somewhat different. Not sure what's happening there.

(b) - The hdr format supports less precision and dynamic range than exr 
files, so, it's a non-ideal work around.

[William F Pokorny] Suggested v4.0 patch for openexr read where larg... [1536 days 20 hours and 36 minutes ago]

Sun, 23 Jan 2022 23:57:41 GMT

(Just posting my povr branch commit message here so the exr image issue 
is recorded somewhere)

Found where incoming exr files are at floats and the file has channel 
values larger than about 2^16 we end up with +inf color channel values 
internally.

This causes unavoidable speckling whenever one of these files is used 
with a sky_sphere and a ray hits a location with a +inf internal channel 
value - even if as part of a larger set of AA rays. In other words AA 
cannot fix this kind of speckling bug.

The kind of speckling changes depending upon the -ffast-math options 
being used or not. Note! The bad internal values are not correct in any 
case, nor universally clamped. Further, other problems than sky_sphere 
use might present themselves.

The hack of a fix the povr branch is adopting is two fold.

First, the addition of pre-scan code in the openexr.cpp file controlled 
by EXR_PRESCAN_PATCH. Here the +inf channel values are replaced by the 
largest valid channel values otherwise seen for each channel. This 
better than what -fno-fast-math trips some of the color space template 
code to do. But, yes it's a hack.

On adoption of the newer 3.0 OpenEXR, the right full float read support 
should be implemented so these larger values in exr HDRIs don't cause 
trouble. Aside better both read and write for full floats - in addition 
to half floats.

Second, The addition of some limit checking controlled by 
POV_PIGMENT_DEBUG was added to Compute_Pigment in pigment.cpp which 
looks for +-inf in debug builds.  This checking would catch the exr 
large value issue herein, but the thinking is we could get such values 
by other means such as bad user defined pigments or too large user 
defined color channel values.

Bill P.

[William F Pokorny] Suggested fix. Divide by zero bug. Intersect_BBo... [1544 days 2 hours ago]

Sun, 16 Jan 2022 18:33:40 GMT

The bug herein is very unstable and it's one I've been chasing for 
years. Recent povr only bounding code changes caused the parse trace() 
to fail more consistently using Warren's recent Halloween stain test 
scene. And even so I found slight changes in code ordering would cause 
the bug to disappear.

The bug only shows up where one or more ray direction components is 
zero. Further, I think it comes to divide by zero exceptions being 
handled in a standard - reliable way - only where NOT bypassing certain 
exception handling with --ffast-math options.  I've no plans to run down 
particulars after taking a few shots in the dark as to the exact cause.

--- The simple fix.

Don't use -ffast-math / -O3. We currently 'ship' linux/unix builds using 
--ffast-math though most linux package developers use a conservative -O2 
generic build. People installing provided packages are likely OK. If 
compiling your own versions, avoid fast-math optimizations.

--- Alternate fix.

The more complex suggested code fix better preserving -O3/-ffast-math is 
shown below and it's what I've moved to with my povr branch.

--- Background

A change from v3.6 to v3.7 and onward was the introduction of some 
in-lined / template code culminating in a object->Intersect_BBox call. 
This code also at the root of a couple of other v3.7+ issues fixed in 
the povr branch.  Only one issue/pull req remains open (#357) IIRC. The 
inability to completely turn off bounding with -mb is another issue 
where I closed the pull req after it sitting a long time.

The aim of this code is to speed up operations like projected_through, 
the shadow cache, the parser's trace()(*) and subsurface feature 
calculations.  Despite the issues - where the one herein another - it 
largely accomplishes its performance aims per the targets.

I'm unsure the overhead cost / gains in more the more mainstream 
intersection determination.

This new-ish ray-bbox test code requires the calculation of a variant 
enum and invdir 3d vector. The code for this calculation exists in four 
places that I see. Two in trace.cpp and two in object.cpp. It's 
currently identical, four times repeated code.

----------- Current code

     BBoxVector3d origin;
     BBoxVector3d invdir;
     BBoxDirection variant;

     Vector3d tmp(1.0 / ray.GetDirection()[X],
         1.0 / ray.GetDirection()[Y], 1.0 / ray.GetDirection()[Z]);
     origin = BBoxVector3d(ray.Origin);
     invdir = BBoxVector3d(tmp);
     variant = (BBoxDirection)
         ((int(invdir[X] < 0.0) << 2) | (int(invdir[Y] < 0.0) << 1) |
         int(invdir[Z] < 0.0));

----------- Alternate code not triggering divide by zero exceptions.

     Vector3d rayDir = ray.GetDirection();

     // Get inverse direction, explicitly handling zero components.
     // Avoiding divide by zero exception to enable -ffast-math/-O3
     // use without occasional flaky issues where sometimes
     // (invdir[*] < 0.0) working and not, depending on compiler
     // options / code structure / cpu / flow. (v3.7/v3.8/v4.0)

     double tmpX = (std::abs(rayDir.x())<gkDBL_epsilon) ?
         std::copysign(1.0,rayDir.x())*HUGE_VAL : 1.0/rayDir.x();
     double tmpY = (std::abs(rayDir.y())<gkDBL_epsilon) ?
         std::copysign(1.0,rayDir.y())*HUGE_VAL : 1.0/rayDir.y();
     double tmpZ = (std::abs(rayDir.z())<gkDBL_epsilon) ?
         std::copysign(1.0,rayDir.z())*HUGE_VAL : 1.0/rayDir.z();

//  Vector3d tmp(tmpX,tmpY,tmpZ);
//  BBoxVector3d invdir = BBoxVector3d(tmp);
     // OK if BBox at doubles, otherwise compile error & use above
     BBoxVector3d invdir = Vector3d(tmpX,tmpY,tmpZ);
//  BBoxVector3d origin = BBoxVector3d(ray.Origin);
     BBoxVector3d origin = ray.Origin;  // OK while BBox at doubles
     BBoxDirection variant = (BBoxDirection)
         ((int(invdir[X] < 0.0) << 2) | (int(invdir[Y] < 0.0) << 1)
         | int(invdir[Z] < 0.0));

Bill P.

[Mr] Re: Possible v4.0 finish changes (povr). amplify... [1578 days 11 hours and 44 minutes ago]

Mon, 13 Dec 2021 08:50:00 GMT

William F Pokorny <ano### [at] anonymousorg> wrote:
> Using this time an environmental HDRI from:
>
> https://polyhaven.com/a/photo_studio_loft_hall
>
> in a scene to demonstrate other povr changes made - or still in progress
> - for the past 4-5 months. The pertinent code for the attached image is:
>
[...]
> The scene file uses a couple of other new-ish features in getenv("HDRI")
> and the micro normal bevy pattern 9. The latter still to be changed to a
> named normal only pattern called, I guess, 'micro' - or something? Its
> aim is to implement the inbuilt micro normal stuff folks have been
> hacking in some fashion for many years. An aim was coding it in a way
> which leads AA to help achieve a blurred result. It's just noise where
> the magnitude of the overall micro 'blur' is controlled by the bump_size.
>
> Bill P.

..... Drooling ! Thanks for keeping up all your work.

[William F Pokorny] Suggested v4.0 radiosity fix. (sky_sphere / back... [1579 days 6 hours and 5 minutes ago]

Sun, 12 Dec 2021 14:29:05 GMT

While chasing the odd uninitialized vector while working to eliminate 
the dual initialization most 2d and 3d vectors get today in v3.8, found 
a long standing issue with radiosity using sky_spheres / backgrounds.

In radiosity.cpp change:

...
if (recSettings.maxReuseFactor >= HUGE_VAL)
     maximum_distance = HUGE_VAL;
...
smallest_dist = BOUND_HUGE;
...
if (depth > HUGE_VAL)
     depth = HUGE_VAL;
...


to:

...
if (recSettings.maxReuseFactor >= BOUND_HUGE)
     maximum_distance = BOUND_HUGE;
...
smallest_dist = HUGE_VAL;
...
if (depth > BOUND_HUGE)
     depth = BOUND_HUGE;
...


Background.

Originally HUGE_VAL was a POV-Ray defined value of 1e17. As early as the 
mid to late 1990s HUGE_VAL was often a c/c++ include defined macro 
value. Today in c++11, it is a macro defined to double +inf.

Originally the POV-Ray defined BOUND_HUGE was 1e30, it is today 2e10.

The maximum intersection depth to actual shapes is limited to 
MAX_DISTANCE set at 1.0e7.

POV-Ray long returned a BOUND_HUGE value for the intersection depth when 
no intersection was found with TraceRay() as well as all the 
FindIntersection() variations. Today in v3.7,v3.8,v4.0 it returns 
HUGE_VAL for the function TraceRay() alone.

TraceRay does this using optional max distance conditionals and logic 
I'm 'guessing' might have been added to support the obscure mesh camera 
feature (v3.7) allowing a max range spec for the camera rays.

If you are setting up an environment for radiosity with shapes - a 
surrounding hollow sphere say - there is no exposure to the bug being 
fixed here.

If, however, you are using the background color or a sky_sphere the 
TraceRay() code returns inf and often enough all the radiosity samples 
in the half sphere end up with an infinite result and the nearest vector 
doesn't get set to anything. Several other values driven large by the 
inf results get clamped more or less as they do for shape intersections 
at large distances.

Where the nearest vector doesn't get set, it happens we've been 
mitigating the bug via the fact the vector.h template allocation always 
initializes to a zero vector (this the very, almost always duplicate, 
initialization I'm trying to eliminate in povr). Today, where the 
nearest vector is 'left' a 0,0,0 the vector dot product comes out at 
zero and we use 100% of the 'harmonic mean' of samples in the code 
instead of one more vigorously weighted in the direction of one of the 
samples in the half dome of samples.

The bug is real, however, how much one might see it in any given scene - 
especially with better radiosity settings - I'm not sure. My guess is it 
would most often present as slightly darker and bland/washed out results 
when the bug is in play - with better radiosity settings.

For more background on the v3.8/v4.0 performance issues I am, in part, 
trying to address by eliminating the nearly always double vector 
initialization see:

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

--- image
The top row of the attached image shows there is no change due the fix 
where the environment is set up with a sphere.

The second row shows there are corrections due the fix when using a 
sky_sphere.

The bottom two rows show there are always differences between a 
radiosity environment set up by shapes and any set up with 
background/sky_spheres.

Asides:

- Environmental set up with shapes is slower than any with 
backgrounds/sky_spheres because intersections on the containing shape 
exist and must be handled as real shape intersections.

- Noted too while digging around, there are differences between the 
accuracy of loaded radiosity samples and immediately calculated ones 
which 'might' - occasionally - present as visible differences.

Bill P.

[Dick Balaska] Re: filter transmit only with 256 color depth [1611 days 20 hours and 33 minutes ago]

Wed, 10 Nov 2021 00:01:04 GMT

On 10/19/2021 8:13 PM, Adam C wrote:

> 
> I should be using PNG and not GIF. OK. However under Output File Type is says;
> "The default output depth for all formats is 8 bits/color".

OT
I use GIF for input files to POV-Ray so as not to confuse them with the 
PNG which are output files.  Then I can safely `rm *.png`

dik

[William F Pokorny] Possible v4.0 finish changes (povr). amplify, in... [1627 days 6 hours and 49 minutes ago]

Mon, 25 Oct 2021 13:45:28 GMT

Using this time an environmental HDRI from:

https://polyhaven.com/a/photo_studio_loft_hall

in a scene to demonstrate other povr changes made - or still in progress 
- for the past 4-5 months. The pertinent code for the attached image is:

//-------------
//...
  #macro ImageMap00(_HF)
   #if (_HF=0)
     image_map { getenv("HDRI")
   #else
       getenv("HDRI")
   #end
   #if (_HF=0)
      map_type 1
      interpolate 2
     }
   #end
#end
#declare PigSkySph = pigment { ImageMap00(0) }
#declare SkySphere00 = sky_sphere {
     pigment { PigSkySph }
     amplify rgb <1,1,1>
}

#declare Fin00 = finish {
     amplify 0
     reflection { 0.7 0.9 fresnel amplify 1 metallic 1 }
     intensity_max 1
}

#declare Sph00 = sphere {
     0, 0.7
     texture {
         pigment { rgb <0.81,0.74,0.11> }
         finish { Fin00 }
         normal { bevy 0.03125 type 9 } // inbuilt micro normal
     }
     interior { ior 1.5 }
}

//--- scene ---
     sky_sphere { SkySphere00 }
     camera { Camera00 }
     object { Sph00 }
     object { Sph00
         finish {Fin00 intensity_max  0}
         translate <-0.9,+0.9,-0.7>
     }
     object { Sph00
         finish {Fin00 intensity_max -1}
         translate <+0.9,-0.9,+0.7>
     }

The finish items which are new (or changed) are amplify, intensity_max 
and that reflection no longer supports the old, non-block / non-brace 
bound form.

The amplify concept partially exists today, but under different keyword 
names - sky_spheres like background always emit so 'emission' is a color 
vector multiplier. With interior fade the old 'refraction' keyword was 
the multiplier. In povr many of these have been changed to 'amplify' and 
'amplify' has been added to more - but not yet all - functional blocks.

The intensity_max keyword is mostly new(1) and again has been added to 
many - but not all - blocks / trace operations. Primarily, what 
intensity_max does is shown in the attached image. With the upper left 
sphere intensity_max is 0 and so off. With the middle sphere it's 1.0 
and color vectors are not clamped, but rather constrained to a [0..1] 
range. In the lower right it's -1, where - when if finds color channel 
values generated outside the 0-1 range - it attempts to mangle the 
colors returned in way to indicate render regions where the color vector 
will get clipped on conversion to most output image formats(2).

The thinking is amplify and intensity_max would be used together to 
better isolate and control the components of any given ray color result.

(1) - Radiosity max_sample exists and I've not (yet?) renamed it.

(2) - Tricky! It's perhaps not possible to do in ways always easily 
visible. I've tried many approaches and I'm using a couple of those 
currently depending on what information the local code has in hand.

The scene file uses a couple of other new-ish features in getenv("HDRI") 
and the micro normal bevy pattern 9. The latter still to be changed to a 
named normal only pattern called, I guess, 'micro' - or something? Its 
aim is to implement the inbuilt micro normal stuff folks have been 
hacking in some fashion for many years. An aim was coding it in a way 
which leads AA to help achieve a blurred result. It's just noise where 
the magnitude of the overall micro 'blur' is controlled by the bump_size.

Bill P.

[William F Pokorny] Possible v4.0 real time rendering extensions (po... [1628 days 21 hours and 36 minutes ago]

Sat, 23 Oct 2021 22:57:50 GMT

Ref:

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

Web Message: <61563f4b$1@news.povray.org>

Firstly, FWIW, I now think the real time rendering (RTR) memory bubble
is primarily due the POV-Ray Messaging System (POVMS) backing up.
Though, other things certainly affect the total memory consumed.

---
I've added a couple real time rendering extensions to my povr playpen
branch.

Co-opted the Cyclic_Animation=true|false (+-kc) capability for real time
rendering(1). The control already existed for non-RTR animations. The
real time rendering now stops at the end of the camera list unless +kc
is used. Perhaps too help for how large the memory bubble gets.

A Real_Time_Capture=true|false (+-rtc) capability. Which currently
writes pfm, 32 bit float rgb files for each frame to the current
directory. These can, for example, be converted to full float exr files
with the openimageio-tools' iconvert utility.

The +rtc mode also bypasses the usual internal messaging framework used
for the preview display. To render one scene to a pfm file one would
turn off the Clockless_Animation(1), -kla, as in: '... +rtr +rtc -kla
-kc ...'

(1) The Clockless_Animation animation feature, as currently implemented,
is in fact a: "Cylic rendering of a list of cameras during RTR." So,
today we have a ByCameras_Animation for RTR - though other clockless
animation approaches are possible.

For an example animation see:

http://news.povray.org/povray.binaries.animations/thread/%3C6174929b%241%40news.povray.org%3E/
or
Web Message: <6174929b$1@news.povray.org>

Bill P.

[Kenneth] Re: filter transmit only with 256 color depth [1632 days 10 hours and 24 minutes ago]

Wed, 20 Oct 2021 10:10:00 GMT

"Kenneth" <kdw### [at] gmailcom> wrote:

>
> I'm a little confused about your question. If you want a 256-color PNG--
> kind of 'like a GIF' with a very limited color palette-- then no, it would
> be 2, not 256. (I.e., 2 to the 8th power is 256.)
>

Sorry, *I* am confused about my answer. My brain is kind of fried tonight; my
apologies.

[Kenneth] Re: filter transmit only with 256 color depth [1632 days 13 hours and 49 minutes ago]

Wed, 20 Oct 2021 06:45:00 GMT

I happen to be working with 'transmit' and 'transmit all' at the moment, so I'll
try to help.

[I am running POV-ray v3.8.0 beta 1, but most of the following applies to v3.7
as well; I tested it.)

> So my question is, how can I specify a 256-bit PNG as the output file type?
> It looks like the option +Fxn,  +FP256   Am I on the right track here?

I'm a little confused about your question. If you want a 256-color PNG-- kind of
'like a GIF' with a very limited color palette-- then no, it would be 2, not
256. (I.e., 2 to the 8th power is 256.) But if you want the standard 256-bits
*per color*, then it should be 8, as JR mentioned.

> I'm simulating a color film transparency laid upon a surface or another
> transparency. Image maps with ambient <1.0 1.0 1.0>, viewed from overhead.
>
> So I have been struggling with poor results from "filter all 1.0" and
> "transmit all 1.0" after my pigment image_map of jpg or png with or without
> alpha channel.

Unfortunately, 'transmit all' has had problems in the past, particularly with
alpha-channel image_maps; that was during the early v3.7 days. But the problems
were fixed by one of the developers in 2016, in one of the 3.71-alpha versions.
For a discussion of that, see...

https://news.povray.org/povray.binaries.images/thread/%3Cweb.5690126895214779ad6fa18f0%40news.povray.org%3E/

But there is an interesting workaround for you variable-transparency problem, IF
I understand what you are trying to do. It does not use 'transmit all', but
instead uses a pigment_map with 'transmit --some value--' (assuming you are
using your original images, not GIFs, and that you have pre-#declared one of
your images):

Example:
#declare IMG_1 = // this will ultimately be the faded-out image
pigment{image_map{jpeg "my_image_1.jpg" interpolate 2}}

#declare MY_TEX_1 =
texture{
pigment{
      average
      pigment_map{
           [1 IMG_1]
           [.5 transmit 1]
                 }
       }
finish {...whatever...}
}

This makes the image_map 25% transparent (or maybe 33%?) because of the average
of the two pigment_map 'weights' of 1 and .5. It also works with alpha-channel
images. Surprisingly, 'transmit' can be successfully used here, even though your
image_map probably has the standard 16-million colors. And just as surprisingly,
'transmit all' does NOT work here.

You can vary the two weights to get some other translucency, of course.

Then for your simpler non-faded underlying image, #declare that one as a similar
texture, MY_TEX_2 (but no pigment_map or average for this one, of course.)

Then combine both textures on your box object, or whatever you are using for the
surface:

box{0, <1,1,0> // a zero-thickness box actually works
texture{MY_TEX_2} // the 'base' image and texture, opague
texture{MY_TEX_1} // the semi-transparent image texture
}

(you may have to rotate these by 90-deg, if you're aiming your camera downward).

I hope this helps; if it's unclear, just ask.

------
Strangely, I am getting inconsistent results with 'transmit all' even in v3.8.0
beta 1. It *should* work with any type of image_map-- JPEG, PNG, TIFF etc-- like
the documentation states in

3.6.2.6.3 The Filter and Transmit Bitmap Modifiers:
"You can give the entire image a filter or transmit value using filter all
Amount or transmit all Amount. For example:
image_map {
  gif "stnglass.gif"
  filter all 0.9
  }
"

However, *sometimes* it works, sometimes it does not, and I have no idea why.
I've used it successfully many times in somewhat older versions of POV-ray, so
my current results are rather strange.

[jr] Re: filter transmit only with 256 color depth [1632 days 15 hours and 24 minutes ago]

Wed, 20 Oct 2021 05:10:00 GMT

hi,

"Adam C" <ada### [at] anonymousorg> wrote:
> Looking at;  2.1.2.4 File Output Options here;
> http://www.povray.org/documentation/view/3.6.1/219/
>
> I should be using PNG and not GIF. OK. However under Output File Type is says;
> "The default output depth for all formats is 8 bits/color".
>
> So my questions is, how can I specify a 256-bit PNG as the output file type? It
> looks like the option +Fxn,  +FP256   Am I on the right track here? Will give
> that a try now.

8bit per colour channel png:  +fn8

transparency:  +ua

<https://wiki.povray.org/content/Reference:File_Output_Options>


regards, jr.

[Adam C] Re: filter transmit only with 256 color depth [1632 days 20 hours and 19 minutes ago]

Wed, 20 Oct 2021 00:15:00 GMT

Looking at;  2.1.2.4 File Output Options here;
http://www.povray.org/documentation/view/3.6.1/219/

I should be using PNG and not GIF. OK. However under Output File Type is says;
"The default output depth for all formats is 8 bits/color".

So my questions is, how can I specify a 256-bit PNG as the output file type? It
looks like the option +Fxn,  +FP256   Am I on the right track here? Will give
that a try now.

Thank you.

[Adam C] filter transmit only with 256 color depth [1632 days 20 hours and 39 minutes ago]

Tue, 19 Oct 2021 23:55:00 GMT

I'm simulating a color film transparency laid upon a surface or another
transparency. Image maps with ambient <1.0 1.0 1.0>, viewed from overhead.

So I have been struggling with poor results from "filter all 1.0" and "transmit
all 1.0" after my pigment image_map of jpg or png with or without alpha channel.

Today I find, " .. can only apply filter or transmit to 8 bit 256 color palleted
images ..", as per this link on the wiki;

https://wiki.povray.org/contentDocumentation:Tutorial_Section_4.1#When_I_use_filter_or_transmit_with_my_.tga_image_map_
nothing_happens.


Looking through the Documentation, I find its also referred to here;
http://www.povray.org/documentation/3.7.0/r3_4.html#r3_4_6_3_2


Thank you, folks. I'll switch to GIF as the intermediary for my transparency,
after scratching my head for several days. There were some interesting results
on the way, but generally too dark black or too opaque white preventing the
scene underneath from being visible.

[Kenneth] Re: Another v4.0 rtr/kla concern. Memory bubble ... [1644 days 23 hours and 49 minutes ago]

Thu, 7 Oct 2021 20:45:00 GMT

William F Pokorny <ano### [at] anonymousorg> wrote:
> On 10/7/21 4:09 AM, Kenneth wrote:

> > Assume that I have turned both of these off:
> > preview display OFF
> > output file OFF
> >
> > In POV-ray's GUI, I have to choose *some* particular render resolution
> > (which gets chosen from my 'quickres.ini' file) to run a scene-- even
> > though there is now NO image output and NO preview. But I discovered
> > that the res I pick *does* affect the fps speed of the looping animation.
> > Running my 'bare' test scene with
> > 8 cores/16 threads, this is what happens:
> > At 160X120 res:   90fps (!)
> > At 1280X960 res:  9.5fps
> >

Oops; I was getting tired and brain-drained last night. Those stats are for my
'typical' scene. The 'bare' cameras-only scene produced these:
At 160X120 res: 900fps (!!!)
At 1280X960 res: 9.9fps
>
> The only sure thing I see is slowing down the frame rate helps with the
> memory bubble.

I was beginning to see that result as well, but could not definitely say yea or
nay.

> Aside: I believe the entire reason the real time / continuous render
> options were created was to show off multiple core / hyper threaded
> CPUs. IIRC Thorsten and Chris did it in a hurry and it's more or less
> been in that demo state since.

And it's still a great feature that I love to use.

[William F Pokorny] Re: Another v4.0 rtr/kla concern. Memory bubble ... [1645 days 9 hours and 46 minutes ago]

Thu, 7 Oct 2021 10:47:57 GMT

On 10/7/21 4:09 AM, Kenneth wrote:
> "Kenneth" <kdw### [at] gmailcom> wrote:
> 
>>
>> I ran a series of thread tests, with the preview display OFF, and got some
>> interesting and mysterious results.
>>
> 
> Well, I'm getting some screwy results now. Just when I thought that my previous
> tests were 'definitive' (more or less), some *new* and mysterious behavior
> arises.
> 
> I just ran one of my 'typical' older (v3.8) scenes that I had already set up for
> kla/rtr, with an almost identical #while-loop camera like my 'bare' test, and
> with image_maps, objects, lights, etc. And I used all 8 cores/16 threads of my
> machine, AND turned the preview display ON...
> 
> ....And that scene runs with NO increase in memory, loop after loop! I don't get
> it. I feel like I'm comparing bananas to footballs, with no logical basis for my
> tests. :-<  If anything, *that* scene should trigger the increase in memory, not
> my 'bare' scene.
> 
> Here's *another* screwy thing (which may be Windows-specific?):
> Assume that I have turned both of these off:
> preview display OFF
> output file OFF
> 
> In POV-ray's GUI, I have to choose *some* particular render resolution (which
> gets chosen from my 'quickres.ini' file) to run a scene-- even though there is
> now NO image output and NO preview. But I discovered that the res I pick *does*
> affect the fps speed of the looping animation. Running my 'bare' test scene with
> 8 cores/16 threads, this is what happens:
> At 160X120 res:   90fps (!)
> At 1280X960 res:  9.5fps
> 
> I didn't realize this earlier. And I have not yet determined if this ghostly
> change-of-res (AND fps rate) affects how the memory use increases...or does not
> increase.
> 
> Madness!
> 
Hmm, Alright. Thank you for the data. I'm seeing odd results too. There 
are reasons - and likely a mix on them. We just don't know at the moment 
what the reasons are!

The only sure thing I see is slowing down the frame rate helps with the 
memory bubble. I've got and itch / vague recollection of having run 
across code comments about some memory handling trade off with rtr/kla.

Aside: I believe the entire reason the real time / continuous render 
options were created was to show off multiple core / hyper threaded 
CPUs. IIRC Thorsten and Chris did it in a hurry and it's more or less 
been in that demo state since.

FYI - I'm busy with real life until early to mid next week.

Bill P.

[Kenneth] Re: Another v4.0 rtr/kla concern. Memory bubble ... [1645 days 12 hours and 24 minutes ago]

Thu, 7 Oct 2021 08:10:00 GMT

"Kenneth" <kdw### [at] gmailcom> wrote:

>
> I ran a series of thread tests, with the preview display OFF, and got some
> interesting and mysterious results.
>

Well, I'm getting some screwy results now. Just when I thought that my previous
tests were 'definitive' (more or less), some *new* and mysterious behavior
arises.

I just ran one of my 'typical' older (v3.8) scenes that I had already set up for
kla/rtr, with an almost identical #while-loop camera like my 'bare' test, and
with image_maps, objects, lights, etc. And I used all 8 cores/16 threads of my
machine, AND turned the preview display ON...

....And that scene runs with NO increase in memory, loop after loop! I don't get
it. I feel like I'm comparing bananas to footballs, with no logical basis for my
tests. :-<  If anything, *that* scene should trigger the increase in memory, not
my 'bare' scene.

Here's *another* screwy thing (which may be Windows-specific?):
Assume that I have turned both of these off:
preview display OFF
output file OFF

In POV-ray's GUI, I have to choose *some* particular render resolution (which
gets chosen from my 'quickres.ini' file) to run a scene-- even though there is
now NO image output and NO preview. But I discovered that the res I pick *does*
affect the fps speed of the looping animation. Running my 'bare' test scene with
8 cores/16 threads, this is what happens:
At 160X120 res:   90fps (!)
At 1280X960 res:  9.5fps

I didn't realize this earlier. And I have not yet determined if this ghostly
change-of-res (AND fps rate) affects how the memory use increases...or does not
increase.

Madness!

[Kenneth] Re: Another v4.0 rtr/kla concern. Memory bubble ... [1645 days 18 hours and 4 minutes ago]

Thu, 7 Oct 2021 02:30:00 GMT

William F Pokorny <ano### [at] anonymousorg> wrote:
> On 10/5/21 5:42 PM, Kenneth wrote:
> >
> > My own 'working hypothesis' at the moment is that ALL of a scene's code and
> > elements are being duplicated for each 'new' loop, not just any
> > image_maps... and that each loop's 'new' memory use adds to the previous
> > total.
>
> If you get a chance, I'd be interested in a single thread run on your
> machine/windows. I'm actually getting better reported FPS that way than
> using 2 cores / 4 threads - which on the surface doesn't make much sense.
>

I ran a series of thread tests, with the preview display OFF, and got some
interesting and mysterious results.

Running my bare 'cameras only' test scene, and letting the kla/rtr animation run
and loop continuously for exactly one minute:

1A) With:
preview display OFF
1 thread-- Work_Threads=1 in my .ini file
Result: NO increase in used memory(!), although the value dances around a bit as
expected (just a result of the memory being cleared after each loop, I suppose).
About 35MB average
20.5 fps, consistent

1B)
Same as A), 1 thread, but with the preview display ON (800X600 render):
The memory use *increases* to 2050 MB by the 1 minute mark.
16.6 fps, consistent more or less

The 1A) combination of 1 thread and NO display preview is the only one of my
tests where the memory did not increase. Here, the preview display seems to be
the root cause of the increasing memory.

However...
2) Using 2 threads, with preview display still OFF:
Memory use increases to 2040 MB anyway
30.3fps-- but *very slowly* starts climbing, by hundredths of a second

....and every additional thread that's used causes a FASTER memory increase. With
4 threads, it climbed to 11,723 MB! That's as far as I dared to go. So in these
>1-thread test cases, it looks like multi-threading itself is the culprit,
somehow.

(BTW, file output being on or off does not affect any of these results, as far
as I can tell.)

So maybe kla/rtr was never meant to be run in a multi-threaded environment?

-----
BTW: I need to modify my previous comments about the trouble with the 'stop'
button, at least in Windows. It actually *does* work-- but certainly not
immediately *when using more than 1 thread*. In such cases, the looping
animation continues to run for awhile, but only while POV-ray slowly RELEASES
its resulting big memory load. Once the memory value falls to POV-ray's 'idle'
value, the looping animation finally stops. None of this happens when using only
*1* thread, though; the 'stop' button works instantly.

[William F Pokorny] Re: Another v4.0 rtr/kla concern. Memory bubble ... [1646 days 8 hours and 17 minutes ago]

Wed, 6 Oct 2021 12:17:29 GMT

On 10/5/21 5:42 PM, Kenneth wrote:
> [in Windows]
> Confirmed in v3.8.0 beta 1 (v3.7.0 can't use this feature, otherwise I would
> have tested it there too.)
> 
> While trying to track down where the memory increase might be coming from, I
> instead wrote a*bare*  test scene-- with nothing but the changing cameras! Yet
> the memory-use still increases.
> 
> Try running just this scene in your povr branch to see what happens:
>   -----
> #version 3.8;
> global_settings{assumed_gamma 1.0}
> 
> // MULTIPLE CAMERAS:
> #declare CK = 0;
> 
> #while(CK <= 1.0)
> camera {
>    perspective
>    location  <0, 25, 40>
>    look_at   <0,0,0>
>    right     x*image_width/image_height
>    angle 67 // 67
>    rotate 360*CK*y
> }
> #declare CK = CK + .05;
> #end
>   -----
> 
> [But WARNING: On my i7 8-core machine, this runs SO fast that the 'stop' button
> doesn't reliably work; I had to shut down POV-ray instead. OR, what also works
> for me: Hit 'pause'-- which does pause the looping animation temporarily-- then
> hit 'stop'. The looping still proceeds x-number of times before coming to a
> final halt-- but the memory use starts to slowly*decrease*  while that happens.
> That's interesting by itself.]
> 
> My own 'working hypothesis' at the moment is that ALL of a scene's code and
> elements are being duplicated for each 'new' loop, not just any image_maps...
> and that each loop's 'new' memory use adds to the previous total.

Thanks! I didn't think to try larger render windows with just cameras. 
My non HDRI stuff was what I already had - small isosurface changing / 
morphing things and there memory is always small, but the frame rate and 
render sizes are smallish too.

If you get a chance, I'd be interested in a single thread run on your 
machine/windows. I'm actually getting better reported FPS that way than 
using 2 cores / 4 threads - which on the surface doesn't make much sense.

Playing around just now I had the thought to try -D to turn off the 
preview display and it does change the rate at which the memory bubble 
grows.

Aside 1: You've probably noticed too that pause/un-pause screws up the 
fps reporting.

Aside 2: Given what we see here, I'm wondering how much the freeing and 
re-allocation of memory is costing us 'during' normal single frame 
renders. c++17 / c++20 I understand will have more in the way of inbuilt 
memory pre-allocation / re-allocation (for memory locality of reference) 
and control - not that I currently have a clue how to make use of any of 
those features at the moment... :-)

Aside 3: I run rtr/kla renders with -cc and -fn too, to be sure I'm not 
creating the continuation and image files - or portions thereof. Which 
likely also changes behavior, but not explored much.

Bill P.

[Kenneth] Re: Another v4.0 rtr/kla concern. Memory bubble ... [1646 days 22 hours and 49 minutes ago]

Tue, 5 Oct 2021 21:45:00 GMT

William F Pokorny <ano### [at] anonymousorg> wrote:
> With some of the recent posts on environmental HDRI image use, I played
> today in the povr branch with .hdr and .exr 4k x 2k images. First,
> viewing them via rtr/kla...
>
> The frame rates are surprisingly good even on my little i3 rotating HDRI
> images full circle. In fact for small windows it's quick - for a while...
>
> It looks like large amounts of memory are allocated to back the large
> HDRI images and that memory (or a substantial part of it) is freed at
> the end of each 'frame.'
>

[in Windows]
Confirmed in v3.8.0 beta 1 (v3.7.0 can't use this feature, otherwise I would
have tested it there too.)

While trying to track down where the memory increase might be coming from, I
instead wrote a *bare* test scene-- with nothing but the changing cameras! Yet
the memory-use still increases.

Try running just this scene in your povr branch to see what happens:
 -----
#version 3.8;
global_settings{assumed_gamma 1.0}

// MULTIPLE CAMERAS:
#declare CK = 0;

#while(CK <= 1.0)
camera {
  perspective
  location  <0, 25, 40>
  look_at   <0,0,0>
  right     x*image_width/image_height
  angle 67 // 67
  rotate 360*CK*y
}
#declare CK = CK + .05;
#end
 -----

[But WARNING: On my i7 8-core machine, this runs SO fast that the 'stop' button
doesn't reliably work; I had to shut down POV-ray instead. OR, what also works
for me: Hit 'pause'-- which does pause the looping animation temporarily-- then
hit 'stop'. The looping still proceeds x-number of times before coming to a
final halt-- but the memory use starts to slowly *decrease* while that happens.
That's interesting by itself.]

My own 'working hypothesis' at the moment is that ALL of a scene's code and
elements are being duplicated for each 'new' loop, not just any image_maps...
and that each loop's 'new' memory use adds to the previous total.

[William F Pokorny] Re: Missing close brace causing segfault in >v3.... [1648 days 22 hours and 52 minutes ago]

Sun, 3 Oct 2021 21:41:40 GMT

On 10/3/21 12:23 PM, William F Pokorny wrote:
> This issue affects my povr branch because in branched off of the updated 
> parser. Expect this issue in release which include the parser updates 
> (ie not the v3.8 release or earlier).

Well... Another post proving my mind is glitching. :-(

in branched -> it branched
in release -> in releases
.ini -> .inc

If I start to talk endlessly about turnips, please let me know.

Bill P.

[William F Pokorny] Missing close brace causing segfault in >v3.8 pa... [1649 days 4 hours and 11 minutes ago]

Sun, 3 Oct 2021 16:23:25 GMT

This issue affects my povr branch because in branched off of the updated 
parser. Expect this issue in release which include the parser updates 
(ie not the v3.8 release or earlier).

See: https://github.com/POV-Ray/povray/issues/439

Two examples where the parser should catch the still being defined 
function state and suggest a missing brace as the cause:

// povray +mv3.8 +iScalarFunction_missedBrace.ini
// Missing close brace causing seg fault with v4.0(master) parser updates?
#declare Fn = function {pattern {bozo
}   // <--- Missing close brace }
#declare Vn = Fn(1,2,3);
#debug concat("\nVn = ",str(Vn,1,3),"\n\n")

#error "Parse Test. Stop early"
//---

or

// povray +mv3.8 +iVectorFunction_missedBrace.ini
// Missing close brace causing seg fault with v4.0(master) parser updates?

#declare Fn = function {pigment {bozo
         color_map {[0,rgbft 0][1,rgbft 1]  // <-- missing }
     }}
#declare Vn = Fn(1,2,3);
#debug concat("\nVn = ",vstr(5,Vn,",",1,3),"\n\n")

#error "Parse Test. Stop early"
//---

Bill P.

[William F Pokorny] Re: Ideas. Updated f_wood(). povr branch. [1649 days 8 hours and 35 minutes ago]

Sun, 3 Oct 2021 11:59:01 GMT

On 9/27/21 9:47 AM, William F Pokorny wrote:
> sumPrev, sum pair

Another test image attached for f_wood() and as yet to be mentioned, 
povr branch, finish block changes. Again using the sumPrev, sum pair 
return - though differently - along with pattern turbulence (via 
raw_wave) and f_eblob() for the blobbing.

Bill P.

[William F Pokorny] Re: Not a v3.8 issue, but a patch is needed for ... [1651 days 10 hours and 24 minutes ago]

Fri, 1 Oct 2021 10:10:16 GMT

On 10/1/21 12:54 AM, Kenneth wrote:
> Are you referring to the jitter when using v3.8xx's newer antialiasing method 3
> and Stochastic_Seed? Or in a more general AA sense?

Thanks for the question, I wasn't clear.

Only AA methods 1 & 2 with jitter(b) are affected. The new v3.8 method 
3(a) AA is immune to the AA jitter amount issue for certain, but I also 
admit I didn't try that AA method with rtr/kla.

This jitter shrinking issue matters more to the povr branch due both 
having truly random jitter and in supporting big jitter (>1 values) both 
to compensate for another kind of jitter shrink on increasing recursion 
depth and for effects. See "Correcting comments on Anti-alias (AA) modes 
and jitter" post to povray.general from October of last year for more 
detail.

Bill P.

(a) - I perhaps missed a fix for the method 3 sqrt of slightly negative 
color channel values issue, but to my recollection, that's not fixed in 
v3.8 beta 2.

(b) - Even without jitter AA methods 1&2 take additional samples - why I 
too had missed that jitter was shrinking to nothing as rtr/kla ran. 
Well, and that until I started to play with HDRIs environment maps where 
I could run rtr/kla at larger render sizes and good fps rates my 
continuous animation window sizes were smallish.

[Kenneth] Re: Not a v3.8 issue, but a patch is needed for ... [1651 days 15 hours and 39 minutes ago]

Fri, 1 Oct 2021 04:55:00 GMT

Are you referring to the jitter when using v3.8xx's newer antialiasing method 3
and Stochastic_Seed? Or in a more general AA sense?

I've never noticed the effect you mentioned when running kla/rtr animation in
Windows versions-- but then again, I rarely use any type of AA for such
'real-time rendering' tests (unless I'm doing a specific test that really needs
AA).

So, from your description, it sounds like the jitter is being constantly reduced
(from a given value) *as* the animation runs(?) I'll have to take a closer look.
Thanks for the heads-up.

[William F Pokorny] Another v4.0 rtr/kla concern. Memory bubble with... [1651 days 21 hours and 43 minutes ago]

Thu, 30 Sep 2021 22:50:51 GMT

With some of the recent posts on environmental HDRI image use, I played 
today in the povr branch with .hdr and .exr 4k x 2k images. First, 
viewing them via rtr/kla and then playing a little with potential HDRI 
edits(2).

The frame rates are surprisingly good even on my little i3 rotating HDRI 
images full circle. In fact for small windows it's quick - for a while...

It looks like large amounts of memory are allocated to back the large 
HDRI images and that memory (or a substantial part of it) is freed at 
the end of each 'frame.'

The free's cannot keep up after a certain fps rate(1) and the memory 
attached to the povray process quickly jumps to many gigabytes. If 
lucky, you reach an equilibrium before you start to page (or crash).

For now, the frame rates can be slowed with strong AA settings. For the 
4k x 2k HDRIs with which I was playing, I had to use AA costly enough to 
drop to around 2 fps to keep the memory continuously under 500MB.

Note: There are github pull requests and issues related to not freeing 
image memory during animations which might be of use - should one of us 
find a 'todo' to pop the memory bubble issue.

Aside: When the frame rate gets high, closing the preview window itself 
works much better than 'q' (quit) or 'p' (pause). Or, on linux/unix, you 
can have a kill command ready to go on the povray process id should the 
memory consumption start to get out of hand...

Bill P.

(1) - I suspect the slow free might be due the use of c++11 vectors - 
but that's a guess. For rtr/kla it would, of course, be better not to 
allocate and free the memory, but rather re-use it.

(2) - The idea being to modify HDRIs with an rtr/kla 360 preview. After 
which, a render using same scene, but a single spherical camera, would 
be used to generate an updated HDRI image.

[William F Pokorny] Not a v3.8 issue, but a patch is needed for jitt... [1652 days 2 hours and 42 minutes ago]

Thu, 30 Sep 2021 17:52:25 GMT

Somewhere want to document for v4.0.

It looks as if it's long been the case the jitter value forever shrinks 
as the continuous (-kla) real time rendering (rtr) option runs. The 
user's jitter value needs to be captured aside and restored after each 
'frame' in the continuous render.

I checked and frames rendered by the more usual animation mechanisms are 
OK with respect to the jitter value.

Bill P.

[William F Pokorny] Re: Ideas. Updated f_wood(). povr branch. [1655 days 6 hours and 46 minutes ago]

Mon, 27 Sep 2021 13:47:54 GMT

On 9/26/21 10:21 AM, William F Pokorny wrote:
> On 9/12/21 3:42 PM, William F Pokorny wrote:
>> ... I took another run at an f_wood() ...
> 
...
> I've added two additional return modes, including the sumPrev, sum pair 
> one mentioned briefly elsewhere. 
> 

Attached another test image making use of f_wood()'s new sumPrev, sum 
pair value return mode; coupled with Tor Olav Kristensen's linear sweep 
trick coded up as the inbuilt f_labseep() function.

Bill P.

[William F Pokorny] Re: Ideas. Updated f_wood(). povr branch. [1656 days 6 hours and 12 minutes ago]

Sun, 26 Sep 2021 14:21:52 GMT

On 9/12/21 3:42 PM, William F Pokorny wrote:
>... I took another run at an f_wood() ...

Attached is an image where I'm starting to play more with the idea of 
the updated f_wood creating patterns/structures not related to tree rings.

I've added two additional return modes, including the sumPrev, sum pair 
one mentioned briefly elsewhere. However, this isosurface is just five 
'z' cylinders and f_wood() applied in four 'z' columns between the 
cylinders so it's not using the two new return modes.

Bill P.

[William F Pokorny] Re: Ideas. Updated f_wood(). povr branch. [1661 days 4 hours and 50 minutes ago]

Tue, 21 Sep 2021 15:44:11 GMT

On 9/20/21 9:40 AM, jr wrote:
> hi,
> 
> William F Pokorny <ano### [at] anonymousorg> wrote:
>> FYI - I've not published a povr version with f_wood().
> 
> when will you publish an updated version?  (will '-into' feature?  :-))
> 

Suppose the answer to that second question, depends some on the answer 
to the first. My best guess is '-into' won't be in the next one, if 
another tarball gets publish relatively soon.

I've been hung up for a while on pushing certain, relatively broad, 
changes I've been playing with over the past few months into the media 
block. How, when - and whether I should go after other media changes 
ahead of next publishing a tar ball.

Bill P.

[jr] Re: Ideas. Updated f_wood(). povr branch. [1662 days 6 hours and 49 minutes ago]

Mon, 20 Sep 2021 13:45:00 GMT

hi,

William F Pokorny <ano### [at] anonymousorg> wrote:
> FYI - I've not published a povr version with f_wood().

when will you publish an updated version?  (will '-into' feature?  :-))


regards, jr.

[William F Pokorny] Re: Ideas. Updated f_wood(). povr branch. [1663 days 10 hours and 4 minutes ago]

Sun, 19 Sep 2021 10:29:58 GMT

On 9/19/21 4:22 AM, jr wrote:
> thinking aloud about the simulation, and not having used 'f_wood()' yet, as user
> I think I'd like one simple (wrapper) function/macro where, ideally, I'd only
> provide an "age" (ie #rings) and some average "annual" growth value to obtain a
> pattern, and maybe a rand seed.  (I guess all eight parameters will be needed
> when "tuning" some aspect(s) of the render)

FYI - I've not published a povr version with f_wood().

Yes, a simpler interface would likely be the more common use case in 
practice. With many of new inbuilt functions, I'm trying out and tuning 
ideas. I want knobs and switches and expect further change

In fact With f_wood been thinking about additional return value pairs... 
Internally, we are always tracking a previous positional sum for ring 
count and the the next sum - so we can do a linear interpolation at the 
value between the two value 'positions.'

My thinking is we can probably create some interesting isosurface 
ladder/net/web like structures by using the leg positions of the ladder 
as seeds and, local to the value, four corner positions. Maybe connect 
up TOK's point to point linear sweeps on the fly.

> 
> unrelated, but I've only found out about two_exciting_  Tcl extensions; thinking
> that when 'povr'/POV-Ray compiles, the "library" of backend stuff which is
> linked late in the process, I'm fairly certain, could be (mis-)used;-)  with
> either of these:
> <https://wiki.tcl-lang.org/page/Ffidl>
> <https://cffi.magicsplat.com/>

Thanks for the pointers. The first rings no bells, but I see from my 
notes I've stumbled across the second site at some point.

I played some - looks like now, way back in 2019 :-| - with:

https://github.com/flightaware/cpptcl

which is based on a much earlier tcl function wrapper package that's 
15-20 years older IIRC. There is too, of course, swig.

With tcl wrappers of C++, I always seem to get as far as a few examples, 
but never much more before I drop the effort for other - less painful - 
play. Someday...

On the practical side, I find I often drop back to to extracting enough 
of the POV-Ray header structure to compile tiny c++ programs when first 
trying bits of code. The compile / link loop is then really quick even 
if I happen to be playing also with the headers. I've got an older two 
core i3. Even with 'make -j4', changed header compiles take a while.

Bill P.

[jr] Re: Ideas. Updated f_wood(). povr branch. [1663 days 12 hours and 9 minutes ago]

Sun, 19 Sep 2021 08:25:00 GMT

hi,

William F Pokorny <ano### [at] anonymousorg> wrote:
> Roughly a year ago I re-worked the wood pattern and implemented an
> inbuilt function called f_wood() ...
> The documentation text from functions.inc: ...
> Though aimed at creating wood patterns, the function can be used with
> any gradient of values.
>
> Eight parameters required:

thinking aloud about the simulation, and not having used 'f_wood()' yet, as user
I think I'd like one simple (wrapper) function/macro where, ideally, I'd only
provide an "age" (ie #rings) and some average "annual" growth value to obtain a
pattern, and maybe a rand seed.  (I guess all eight parameters will be needed
when "tuning" some aspect(s) of the render)

unrelated, but I've only found out about two _exciting_ Tcl extensions; thinking
that when 'povr'/POV-Ray compiles, the "library" of backend stuff which is
linked late in the process, I'm fairly certain, could be (mis-)used ;-) with
either of these:
<https://wiki.tcl-lang.org/page/Ffidl>
<https://cffi.magicsplat.com/>

regards, jr.

[William F Pokorny] Initial attempt at timing POV-Ray keywords / fun... [1666 days 6 hours and 38 minutes ago]

Thu, 16 Sep 2021 13:56:12 GMT

Elsewhere, during the discussion related to the 'now' keyword, I floated 
the idea of using the parser with povr's f_clock() as a way to measure 
the relative cost of various keywords, patterns, shapes and functions.

Using Tor Olav Kristensen's array statistics include as updated for v3.8 
and jr's Tabulated() include (thank you both!), I've got an initial pass 
of some timing test code going.

In the attached image the rows above the null row are measuring the cost 
of calling things from the parser itself. Of note, the f_null() function 
is close to the simplest inbuilt function possible. All it does is 
multiply a single passed float by 0.0, returning zero. In that row I'm 
trying to gauge the relative cost of the call from the parser to any 
inbuilt function - the overhead for the function call itself.

Below the null row measuring the cost of some functions as if they are 
being called from within the vm. Closer to the isosurface / parametric 
relative cost.

Aside: Because timing was done with a version of the povr branch with 
the extra debugging and assertions turned on, the cost of the var() 
parser function is inflated. I added a chunk of extra assertion and user 
  debug-aid code there - and it's active.

Bill P.

[William F Pokorny] Re: Ideas. Updated f_wood(). povr branch. [1668 days 6 hours and 53 minutes ago]

Tue, 14 Sep 2021 13:40:58 GMT

On 9/13/21 7:21 PM, Bald Eagle wrote:
> This is very cool.   I experimented a bit with the marble pattern to try to get
> a more irregular spacing of the veins and a variation in the width.  I'll have
> to get back to that once things IRL settle down a bit.
> 
Thanks. Though called f_wood() it can be used with any gradient and so a 
marble if you want.

As you probably know, the marble pattern is just a gradient in x where 
the x position is jostled about by values from calls to Turbulence()(1)

(1) - Which has the distribution drift issue, if not using povr or other 
branches where this is fixed.

> Is it possible to implement this as a function in plain-vanilla SDL, or does it
> require some "special sauce"?

:-) It needs to be inbuilt is the practical answer.

Could you do it in SDL for perhaps patterns only or ,perhaps, as a way 
to pre-bake image maps for later use? Likely yes - but I've not done it.

The whole approach is more expensive than today's wood - especially 
where the random values for the offsets fit a normal distribution. I 
wanted to be able to use it on the fly and with isosurfaces - and for 
that use - inbuilt is the only practical approach I think.

Bill P.

[William F Pokorny] Re: Ideas. Updated f_wood(). povr branch. [1668 days 6 hours and 57 minutes ago]

Tue, 14 Sep 2021 13:37:00 GMT

On 9/13/21 11:47 AM, Alain Martel wrote:
> Very interesting. Mostly useful for wooden objects that are viewed from 
> a relatively short distance.

Thanks. Mostly, Yes. :-)

> Is there any way to have undisturbed rings in the centre with the 
> disturbance increasing as you get farther ?

First, to be clear, the turbulence in the previously posted image was 
accomplished with two 'external' to f_wood() turbulence warps. One for 
fuzz in the rings and another for the log level. The f_wood() function 
doesn't have any inbuilt turbulence - unlike the traditional wood pattern.

In povr certainly a fade is possible, as the Turbulence(1) and vector 
turbulence (DTurbulence) functionality of POV-Ray is brought out as 
inbuilt functions.

If not using that sort of functionality... I think one could probably do 
something like an inward black hole warp(2), apply turbulence, then an 
outward black hole warp. Similar to scaling patterns up (or down) prior 
to applying turbulence and then reversing it.

While, the fade used is the opposite you asked about, attached is a test 
isosurface image based upon f_wood() where I'm using the ring count 
value to fade the rings to nothing in height while moving out from the 
center.

FWIW, the, povr only, core SDL for the isosurface is:

//---
//...
#declare Fn00 = function (x,y,z) {
      f_wood(0,f_hypot(x,z),Core,Width,Rings,Seed,Mean,Sigma)
}
#declare Fn01 = function (v) {
      f_distribution(7,// A triangle distribution. Wikipedia version.
          f_dec2x_f32(v,0),
          A,B,C,ReturnMode,nullArg
      )* ((f_dec2x_f32(v,1)*-0.0035)+0.059) // The fade to nothing.
}
#declare Iso99 = isosurface {
      function { abs(y)-Fn01(Fn00(x,y,z)) }
...
}
//---

Bill P.

(1) - The povr branch has fixed the forever standing Turbulence() 
octaves distribution mean drift issue.

(2) - The povr branch has a black hole type 1 without the clamping 
and/or reaching outside the black hole radius issues of POV-Ray's 
black_hole. The povr type 1 forms would likely be needed for other than 
linear fading / strength 1.

[Bald Eagle] Re: Ideas. Updated f_wood(). povr branch. [1668 days 21 hours and 9 minutes ago]

Mon, 13 Sep 2021 23:25:00 GMT

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

> One of the distribution types recently added to f_distribtion() was a
> normal/gaussian. With this in hand, I took another run at an f_wood()
> supporting more realistic growth rings. I left all turbulence and
> displacement to outside actors.

This is very cool.   I experimented a bit with the marble pattern to try to get
a more irregular spacing of the veins and a variation in the width.  I'll have
to get back to that once things IRL settle down a bit.

Is it possible to implement this as a function in plain-vanilla SDL, or does it
require some "special sauce"?

Regardless, this is looking great as the basis for some excellent wood patterns.
 Looking forward to seeing this implemented with some black hole warps for the
knots, and a good color map and finish.   :)

[Alain Martel] Re: Ideas. Updated f_wood(). povr branch. [1669 days 4 hours and 46 minutes ago]

Mon, 13 Sep 2021 15:48:00 GMT

Le 2021-09-12 Ã  15:42, William F Pokorny a Ã©critÂ :
> Roughly a year ago I re-worked the wood pattern and implemented an 
> inbuilt function called f_wood() which could mimic it using the same 
> basic approach long used for wood. I wasn't very satisfied with the 
> result. My thinking was what we really needed was functionality which 
> could create growth rings in a more realistic way.
> 
> One of the distribution types recently added to f_distribtion() was a 
> normal/gaussian. With this in hand, I took another run at an f_wood() 
> supporting more realistic growth rings. I left all turbulence and 
> displacement to outside actors.
> 
> Attached is an image where in the top row the variation is accomplished 
> with a random number stream adjusting a nominal ring width for each 
> ring. In the second row the random values conform to a normal 
> distribution - less often are extreme values seen. The columns represent 
> the three return types.
> 
> Of note, the color_map for middle and right columns use the blend_mode 3 
> feature of v3.8 to get the ring 'steps' to better show.
> 
> Bill P.
> 
> 
> The documentation text from functions.inc:
> 
> Returns 0-1 ramp value within a ring and ring number. Optionally, the 
> float portion of the ring number can represent the what fraction of the 
> total rings in the tree a particular ring represents.
> 
> Values are returned as two 32 bit values encoded in the double space 
> where the individual values are accessed via the f_dec2x_f32() function. 
> The first 32 bit float is the 0-1 pattern value within the particular 
> ring.Â  The second value is a 32 bit float representing this ring's count 
> from the core by the integer portion of the float and optionally a 
> [0..1) value representing thisRingCnt/treeRingsCount via the decimal 
> portion.
> 
> The aim with f_wood is not to mimic the wood pattern, but rather provide 
> a function returning growth rings which vary in width, a definable wood 
> core and the ring number and fractional position in the wood log. The 
> hope is upon this base, more natural algorithmic-ally generated 'wood 
> patterns' can be created.
> 
> TODO. There are only 6-7 digits of accuracy in that second float! For 
> typical ring counts OK, but maybe the user should be able to select the 
> second return type?
> 
> Example:
> 
> #declare CoreÂ  = 0.02;
> #declare Width = Core/2.0;
> #declare Rings = int(((1.0-Core)/Width)+10);
> #declare SeedÂ  = 9871.123456;
> #declare MeanÂ  = 0.0;Â  // Used only if type is 1
> #declare Sigma = 1/3;Â  // ditto
> 
> #declare Pigm00 = pigment {
>  Â Â Â  function {
> 
Â Â Â Â Â Â Â 
f_dec2x_f32(
> 
Â Â Â Â Â Â Â Â Â Â Â 
f_wood(1,f_hypot(x,y),Core,Width,Rings,Seed,Mean,Sigma),
> 
Â Â Â Â Â Â Â 
0)
>  Â Â Â  }
>  Â Â Â  color_map {...}
> }
> 
> Though aimed at creating wood patterns, the function can be used with 
> any gradient of values.
> 
> Eight parameters required:
> 
> 1. Type. If 0, a random value stream is used to vary each ring width. If 
> 1, the random value stream conforms to a more nature like normal 
> distribution. Option 1 is slower.
> 
> 2. Input value. Usually a distance from a center, but any gradient works.
> 
> 3. The core / starting radius. If positioning wood shapes in the pattern 
> away from the core, this can be used to improve performance by skipping 
> the ring calculations prior to those needed.
> 
> 4. The nominal width of each ring in the 'tree log.'
> 
> 5. The count of the rings in the tree. Used to calculated a stepped 
> gradient of each ring from the core to the bark.
> 
> 6. Seed for random number stream(s). It should be a float other than 0.
> 
> 7. Mean value of the normal distribution. Used only if the type is 1.
> 
> 8. Sigma value for the normal distribution. Used only if the type is 1.

Very interesting. Mostly useful for wooden objects that are viewed from 
a relatively short distance.

Is there any way to have undisturbed rings in the centre with the 
disturbance increasing as you get farther ?

[William F Pokorny] Ideas. Updated f_wood(). povr branch. [1670 days and 52 minutes ago]

Sun, 12 Sep 2021 19:42:26 GMT

Roughly a year ago I re-worked the wood pattern and implemented an 
inbuilt function called f_wood() which could mimic it using the same 
basic approach long used for wood. I wasn't very satisfied with the 
result. My thinking was what we really needed was functionality which 
could create growth rings in a more realistic way.

One of the distribution types recently added to f_distribtion() was a 
normal/gaussian. With this in hand, I took another run at an f_wood() 
supporting more realistic growth rings. I left all turbulence and 
displacement to outside actors.

Attached is an image where in the top row the variation is accomplished 
with a random number stream adjusting a nominal ring width for each 
ring. In the second row the random values conform to a normal 
distribution - less often are extreme values seen. The columns represent 
the three return types.

Of note, the color_map for middle and right columns use the blend_mode 3 
feature of v3.8 to get the ring 'steps' to better show.

Bill P.


The documentation text from functions.inc:

Returns 0-1 ramp value within a ring and ring number. Optionally, the 
float portion of the ring number can represent the what fraction of the 
total rings in the tree a particular ring represents.

Values are returned as two 32 bit values encoded in the double space 
where the individual values are accessed via the f_dec2x_f32() function. 
The first 32 bit float is the 0-1 pattern value within the particular 
ring.  The second value is a 32 bit float representing this ring's count 
from the core by the integer portion of the float and optionally a 
[0..1) value representing thisRingCnt/treeRingsCount via the decimal 
portion.

The aim with f_wood is not to mimic the wood pattern, but rather provide 
a function returning growth rings which vary in width, a definable wood 
core and the ring number and fractional position in the wood log. The 
hope is upon this base, more natural algorithmic-ally generated 'wood 
patterns' can be created.

TODO. There are only 6-7 digits of accuracy in that second float! For 
typical ring counts OK, but maybe the user should be able to select the 
second return type?

Example:

#declare Core  = 0.02;
#declare Width = Core/2.0;
#declare Rings = int(((1.0-Core)/Width)+10);
#declare Seed  = 9871.123456;
#declare Mean  = 0.0;  // Used only if type is 1
#declare Sigma = 1/3;  // ditto

#declare Pigm00 = pigment {
     function {
         f_dec2x_f32(
             f_wood(1,f_hypot(x,y),Core,Width,Rings,Seed,Mean,Sigma),
         0)
     }
     color_map {...}
}

Though aimed at creating wood patterns, the function can be used with 
any gradient of values.

Eight parameters required:

1. Type. If 0, a random value stream is used to vary each ring width. If 
1, the random value stream conforms to a more nature like normal 
distribution. Option 1 is slower.

2. Input value. Usually a distance from a center, but any gradient works.

3. The core / starting radius. If positioning wood shapes in the pattern 
away from the core, this can be used to improve performance by skipping 
the ring calculations prior to those needed.

4. The nominal width of each ring in the 'tree log.'

5. The count of the rings in the tree. Used to calculated a stepped 
gradient of each ring from the core to the bark.

6. Seed for random number stream(s). It should be a float other than 0.

7. Mean value of the normal distribution. Used only if the type is 1.

8. Sigma value for the normal distribution. Used only if the type is 1.