povray.bugreports message digest

[Bald Eagle] Re: The macro scope / identifier / semicolon bug [12 hours and 18 minutes ago]

Tue, 7 Apr 2026 19:05:00 GMT

Also:

The original paper:
https://www.ams.org/notices/200304/fea-escher.pdf

https://www2.oberlin.edu/faculty/kwoods/talks/escher.pdf

http://roy.red/posts/droste/

[Bald Eagle] Re: The macro scope / identifier / semicolon bug [19 hours and 3 minutes ago]

Tue, 7 Apr 2026 12:20:00 GMT

"Tor Olav Kristensen" <tor### [at] TOBEREMOVEDgmailcom> wrote:
> Yes, Bill - We've been here for a while now...

Yep - you for far longer than I.  ;)

> And you are right; I've been very busy the last years.
> Not much time to do POV-Ray work =(

That's life.  Work is work, and hobbies are hobbies.
We need clones. :D

> But you, IIRC, have always been - and still are - quite active in here.
> Very good!

Almost every day.  It keeps my mind active, and I just have all of the ideas
that I have to somehow meaningfully get out of my head.  That's why I appreciate
POV-Ray so much - it allows me to simultaneously document and create, and
explore things that a GUI modeler just can't do.

> - I couldn't resist exploring the "Droste Effect" in Escher's
> "Print Gallery" picture with POV-Ray. I've made some progress in
> achieving this in POV-Ray. I'll post some of my results here.

I've been meaning to explore it myself, since it touches on much of what I've
played with in terms of functions in the complex plane, geometric inversion,
procedural patterns, Doyle spirals, etc.

> "M.C. Escher: More Mathematics Than Meets the Eye" - By Sara Robinson
> https://im-possible.info/english/articles/escher_printgallery/index.html
>
> "A logarithmic image transformation" - by Jos Leys
> https://www.josleys.com/article_show.php?id=82
>
> As far as I can see, the page above has much the same contents as
> the document below. But Firefox and Edge do not try to render the
> jsMath formulas within it. The PDF file from the page below has the
> formulas rendered, but it's behind a pay wall.

Yes.  I found Jos' page as well, and the formulas wouldn't render for me either.
 I tried downloading jsMath and unzipping it (holy motherlode of files! :O ) but
I'm assuming I'm missing some key step in getting a browser to locate,
recognize, and use it.

I'd love to have some kind of math formula formatting suite of macros . . . cue
Project Number 4,597.

I have new internet arriving on Thursday, so I can continue with various
projects that are stalled due to connectivity.

Happy Easter - hope to "see" you again sometime soon.

- BE

[Tor Olav Kristensen] Re: The macro scope / identifier / semicolon bug [1 day 7 hours and 38 minutes ago]

Mon, 6 Apr 2026 23:45:00 GMT

Yes, Bill - We've been here for a while now...

And you are right; I've been very busy the last years.
Not much time to do POV-Ray work =(
But you, IIRC, have always been - and still are - quite active in here.
Very good!

This Easter I've had some spare time. So, when you, in another post,
mentioned this recent 3Blue1Brown video for us (thank you btw.):

"How (and why) to take a logarithm of an image"
https://www.youtube.com/watch?v=ldxFjLJ3rVY&t=2462s

- I couldn't resist exploring the "Droste Effect" in Escher's
"Print Gallery" picture with POV-Ray. I've made some progress in
achieving this in POV-Ray. I'll post some of my results here.

Here are some other useful texts I've found regarding this topic:

"M.C. Escher: More Mathematics Than Meets the Eye" - By Sara Robinson
https://im-possible.info/english/articles/escher_printgallery/index.html

"A logarithmic image transformation" - by Jos Leys
https://www.josleys.com/article_show.php?id=82

As far as I can see, the page above has much the same contents as
the document below. But Firefox and Edge do not try to render the
jsMath formulas within it. The PDF file from the page below has the
formulas rendered, but it's behind a pay wall.

"The Droste effect image transformation" - by Jos Leys
https://www.sciencedirect.com/science/article/abs/pii/S0097849306002433

--
Tor Olav
http://subcube.com
https://github.com/t-o-k

"Bald Eagle" <cre### [at] netscapenet> wrote:
> Hi Tor!
>
> I've been bus reviewing all sorts of code, and that of course led me across all
> the different places that we've crossed paths.
> So I was literally just thinking about you for the past few days.
>
> I'm sure you're super busy as always, but hope that you get enough down-time to
> enjoy things.
>
> Thanks for that 26-year-old post. (!)
>
> What other dark secrets lay dormant in the POV-Ray parser, waiting to one day be
> awakened . . . ?
>
> - BE

[Bald Eagle] NAN math [12 days 8 hours and 8 minutes ago]

Thu, 26 Mar 2026 23:15:00 GMT

I've been working on making my vector arity macro robust, and I came across this
surprising fact while stress testing.

NAN is treated differently in the parser than in the function VM.

NAN equals - EVERYTHING in the parser.

NAN equals nothing, not even itself in the function VM.

So my IfNan () macro fails, but my IfNan () function works as expected.

I'll need to dig into this and see where in the source it goes wrong.

I also recall seeing a thread where people were playing with N/0, and I think
the parser biases that - probably because it allows certain code to keep going.

https://news.povray.org/44294a5a%241%40news.povray.org

- BE

[Bald Eagle] Re: The macro scope / identifier / semicolon bug [13 days 12 hours and 53 minutes ago]

Wed, 25 Mar 2026 18:30:00 GMT

https://news.povray.org/6613cd42%241%40news.povray.org

"There are issues in all the recent parser variations with respect to
sometimes necessary, but missing semicolons. The yuqk fork has addressed
a few of them in its version of the parser, but certainly not all.

The worst cause flaky behavior during parsing without any notice
something has gone wrong."

[Bald Eagle] Re: 3.8 macro parsing errors [14 days 16 hours and 38 minutes ago]

Tue, 24 Mar 2026 14:45:00 GMT

"Bald Eagle" <cre### [at] netscapenet> wrote:
> Works pretty nice!  :)
>
> Any way to force str to prepend the + sign to +inf?
>
> val ("+inf")  =                 inf
> val ("-inf")  =                -inf
> val ("+nan")  =                 nan
> val ("-nan")  =                -nan
> val (1.0123")  = 1.01229999999999998
> val (1.01 23") = 1.01000000000000001
> val ("inf")   =                 inf
> =============================================
> Val1 = -1.00000000
> Val2 = 1.00000000
> Val1 < Val2
>
> Val1 = -1.00000000
> Val2 = 0.00000000
> Val1 < Val2
>
> Val1 = -1.00000000
> Val2 = -1.00000000
> Val1 = Val2
>
> Val1 = 0.00000000
> Val2 = 0.00000000
> Val1 = Val2
>
> Val1 = 1.00000000
> Val2 = 1.00000000
> Val1 = Val2
>
> Val1 = -inf
> Val2 = inf
> Val1 < Val2
>
> Val1 = inf
> Val2 = inf
> Val1 = Val2
>
> Val1 = -inf
> Val2 = inf
> Val1 < Val2               <--- Oooh, nice.
>
> Val1 = inf
> Val2 = inf
> Val1 = Val2
>
> Val1 = nan
> Val2 = inf               <--- possibly good, possibly bad.
> Val1 = Val2

If anyone's up for writing some SDL, (I'm stuck here for the next 5h)
I need reliable ways to detect +/- inf and +/- nan.
In the #if MyVal = val("inf") sort of way.
^^^
That doesn't need to be the exact implementation, I just need the equivalent
that yields the correct Boolean result.

Square it, multiply it by zero, by -1, test equality to itself, subtract it from
itself, add it to itself, abs(), .... whatever works to
_differentiate inf and nan from the real numbers_.

Thanks!

- BE

[Bald Eagle] Re: The macro scope / identifier / semicolon bug [15 days 8 hours and 23 minutes ago]

Mon, 23 Mar 2026 23:00:00 GMT

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

> > I noticed that the parser allowed and didn't complain about:
> > #local in2 = #local Result = {EcResult [2], EcResult [4]};
> > So who know what other wacky constructs it will let slip through.
>
> not that one[*], beta.2 says:
>
> Parse Error: Expected 'RValue to declare', { found instead
>
> same with parentheses (tried supplying a "tuple" instead).
>
> [*] replaced the 'EcResult's with '123.456' and '789.012'.

On 3.7 or 3.8?
Because remember, clipka was playing around with a LOT of parser stuff during
that time, adding and then rolling back. IIRC, that's when I started noticing it
more.

Also, thanks for running the test(s).

- BE

[jr] Re: The macro scope / identifier / semicolon bug [15 days 8 hours and 53 minutes ago]

Mon, 23 Mar 2026 22:30:00 GMT

hi,

"Bald Eagle" <cre### [at] netscapenet> wrote:
> Now, jr has mentioned various thing about my semicolon usage.
> I noticed upon review that I can successfully assign an array without a
> semicolon, and then it's only the subsequent array that triggers the error when
> it doesn't have a semicolon.

_can_ because the parser is "forgiving", but relying on .. a quirk ?

"Note: There should be a semi-colon after the expression in all float,vector and
color identifier declarations."
<wiki.povray.org/content/Reference:Declare_and_Local_Directives#Declaring_identifiers>


> ...
> I noticed that the parser allowed and didn't complain about:
> #local in2 = #local Result = {EcResult [2], EcResult [4]};
> So who know what other wacky constructs it will let slip through.

not that one[*], beta.2 says:

Parse Error: Expected 'RValue to declare', { found instead

same with parentheses (tried supplying a "tuple" instead).

[*] replaced the 'EcResult's with '123.456' and '789.012'.


regards, jr.

[Bald Eagle] Re: The macro scope / identifier / semicolon bug [15 days 9 hours and 18 minutes ago]

Mon, 23 Mar 2026 22:05:00 GMT

Now, jr has mentioned various thing about my semicolon usage.
I noticed upon review that I can successfully assign an array without a
semicolon, and then it's only the subsequent array that triggers the error when
it doesn't have a semicolon.

So I'm thinking that it might be partially about the semicolon, but also that
the parser allows "tandem assignments" through without raising any kind of
warning or error.

See:

https://news.povray.org/web.68fc36a5251da1bc1f9dae3025979125%40news.povray.org

I noticed that the parser allowed and didn't complain about:

#local in2 = #local Result = {EcResult [2], EcResult [4]};

So who know what other wacky constructs it will let slip through.

- BE

[Bald Eagle] Re: The macro scope / identifier / semicolon bug [15 days 9 hours and 33 minutes ago]

Mon, 23 Mar 2026 21:50:00 GMT

Which is the same macro construct as the following:

// ------------------ Scalar failure ---------------------------
#macro BugScalar(A,B,X)
    #if (X < A)
        0
    #else
        ((X - A) / (B - A))
    #end
#end

#local S_FAIL = BugScalar(0.1,0.2,T);   // âscalar failure

// ------------------ Vector failure ---------------------------
#macro BugVector(X)
    #if (X < 0.5)
        <1,0,0>
    #else
        <0,1,0>
    #end
#end

#local V_FAIL = BugVector(T);           // âvector failure

However this works:
#macro Test (N)
 0
#end
#local Val = Test (1);

and (provisionally)

#macro Test (N)
    #if (N < 1)
        #local Result = 0;
    #else
        #local Result = 1;
    #end
    Result
#end

#local Val = Test (1);

Also, as Mr. Callwood advised in an older thread,
wrapping the internals of the macro in parentheses allows successful evaluation:

#macro BugScalar(A,B,X)
(
    #if (X < A)
        0
    #else
        ((X - A) / (B - A))
    #end
)
#end

[Bald Eagle] Re: The macro scope / identifier / semicolon bug [15 days 9 hours and 53 minutes ago]

Mon, 23 Mar 2026 21:30:00 GMT

"Tor Olav Kristensen" <tor### [at] TOBEREMOVEDgmailcom> wrote:
> Hi Bill
>
> Some posts in this old thread, ... may
> also be relevant:


This one too:

https://news.povray.org/povray.general/thread/%3Cweb.63cc2badcc2a7a8c1742c61c57ffd389%40news.povray.org%3E/?ttop=446984
&toff=200

[Bald Eagle] Re: The macro scope / identifier / semicolon bug [16 days 10 hours and 18 minutes ago]

Sun, 22 Mar 2026 21:05:00 GMT

Hi Tor!

I've been bus reviewing all sorts of code, and that of course led me across all
the different places that we've crossed paths.
So I was literally just thinking about you for the past few days.

I'm sure you're super busy as always, but hope that you get enough down-time to
enjoy things.

Thanks for that 26-year-old post. (!)

What other dark secrets lay dormant in the POV-Ray parser, waiting to one day be
awakened . . . ?

- BE

[Tor Olav Kristensen] Re: The macro scope / identifier / semicolon bug [16 days 12 hours and 43 minutes ago]

Sun, 22 Mar 2026 18:40:00 GMT

Hi Bill

Some posts in this old thread, started March 28th 2000 by Sigmund Kyrre Aas, may
also be relevant:

Newsgroup: povray.advanced-users
Subject: Re: Macros acting strange

https://news.povray.org/povray.advanced-users/thread/%3C38E10B3A.7C6D3308%40stud.ntnu.no%3E/?mtop=61708&moff=4

--
Tor Olav
http://subcube.com
https://github.com/t-o-k

[Bald Eagle] Re: The macro scope / identifier / semicolon bug [19 days 11 hours and 33 minutes ago]

Thu, 19 Mar 2026 19:50:00 GMT

"Leroy" <whe### [at] gmailcom> wrote:

> This 'bug' doesn't bother me. Perhaps I' already insane ;) When learning POV
> someone said that the macros are not true C or C++ macros. So I just learn to
> accept what works and what doesn't. If you 'fix' doesn't cause more problems, I
> see no harm.
>
> Have Fun!

Well the issue is that sometimes it shows up and sometimes it doesn't.
And that has caused issues where previously working scenes suddenly didn't work
anymore.
And the intermittent appearance makes debugging a nightmare.

Providing a "minimal scene that reproduces the error" is either impossible, or
the bug doesn't show up when run on someone else's system.

Also, writing:

#macro (Argument)
....
a bunch of povray code
....
#local Result = (my final calculation)

Result

#end

just gives a clean, easily followed logic, since you know that the macro emits
"Result" when exiting.

It used to work just fine, or at least very very often, and then something got
changed and it's a 50/50 shot whether or not the parser wants to let it work or
not - which is not something that I want to be fussing with when trying to write
1000 lines of complicated SDL.

So a solid, reliable fix would be well worth it if the source code edit is
fairly simple.

- BE

[Leroy] Re: The macro scope / identifier / semicolon bug [19 days 11 hours and 53 minutes ago]

Thu, 19 Mar 2026 19:30:00 GMT

"Bald Eagle" <cre### [at] netscapenet> wrote:
> I've run into the issue where assigning the final value(s) of a macro to an
> indentifier such as "Result" and then having the final line of the macro be:
> Result triggers the ole' "attempt to assign uninitialized identifier to Lvalue"
> error.
> I'm hoping that this might help WFP fix this in the yuqk fork, identify where
> things went off the rails between earlier versions and 3.7/3.8, and propose a
> robust fix for this long-standing and really annoying bug that can nearly drive
> one insane.
>
This 'bug' doesn't bother me. Perhaps I' already insane ;) When learning POV
someone said that the macros are not true C or C++ macros. So I just learn to
accept what works and what doesn't. If you 'fix' doesn't cause more problems, I
see no harm.

Have Fun!

[jr] Re: The macro scope / identifier / semicolon bug [19 days 13 hours and 48 minutes ago]

Thu, 19 Mar 2026 17:35:00 GMT

hi,

"Bald Eagle" <cre### [at] netscapenet> wrote:
> I've run into the issue where assigning the final value(s) of a macro to an
> indentifier such as "Result" and then having the final line of the macro be:
> Result triggers the ole' "attempt to assign uninitialized identifier to Lvalue"
> error.
> ...
> The idiom:
>
> ```pov
> #macro Foo()
>     #local Result = 1 + 2;
>     Result
> #end
>
> #local X = Foo();
> ```
>
> After macro expansion, the parser sees:
>
> ```pov
> #local X = 1 + 2
> ```

really ?  would it not "see":
  #local X = 3

anyway, that is as far as I could read the .. generated content.


regards, jr.

[Bald Eagle] The macro scope / identifier / semicolon bug [19 days 15 hours and 13 minutes ago]

Thu, 19 Mar 2026 16:10:00 GMT

I've run into the issue where assigning the final value(s) of a macro to an
indentifier such as "Result" and then having the final line of the macro be:
Result triggers the ole' "attempt to assign uninitialized identifier to Lvalue"
error.
I'm hoping that this might help WFP fix this in the yuqk fork, identify where
things went off the rails between earlier versions and 3.7/3.8, and propose a
robust fix for this long-standing and really annoying bug that can nearly drive
one insane.

"povray has a bug in the way macros work.  A typical way of using a macro is to
use #local to assign a value to an identifier such as "Result", and then have
the identifier be a standalone line at the end of the macro to "export" Result.
 However this often raises an error that Result is undefined.  adding a
semicolon after Result sometimes fixes this behaviour, but then the assignment
using the macro call needs to have its semicolon removed, otherwise the parsers
complains that there is an extra semicolon.  Emitting the raw value from the
macro without assigning it to Result seems to work fine.  Can you look at the
povray code base and see what causes this bug?
https://github.com/POV-Ray/povray"

Short answer: this isn’t a “random macro bug” so much as a **quirk (and
design
limitation) of POV‑Ray’s macro substitution combined with its parser’s
statement/semicolon handling**. When you look at the codebase, the behavior
you’re seeing falls out quite directly from how macro expansion is implemented,
especially in the parser and symbol-table logic.

---

## 1. What macros actually are in POV‑Ray (per the code)

From the documentation and the code, a **POV‑Ray macro is pure textual
substitution at parse time**, not a function with a return value.

When a macro is invoked:

1. A new local symbol table is pushed.
2. The macro body tokens are **spliced verbatim** into the token stream.
3. The parser continues as if the macro body had literally been typed there.
4. At `#end`, all local identifiers are destroyed and parsing resumes.

This behavior is explicitly described in the docs and is reflected in the parser
implementation (`parser.cpp`, `parser_macros`, `SymbolStack`).

---

## 2. Why the “`Result` at the end of a macro” is fragile

The idiom:

```pov
#macro Foo()
    #local Result = 1 + 2;
    Result
#end

#local X = Foo();
```

*looks* reasonable, but here’s what actually happens.

After macro expansion, the parser sees:

```pov
#local X = 1 + 2
```

or sometimes (depending on tokens):

```pov
#local X = Result
```

### Why that breaks

* `Result` is **local to the macro’s symbol table**
* As soon as `#end` is processed, `Result` is destroyed
* The parser may still be in the middle of parsing the surrounding statement
(`#local X = ...`)

So when the parser tries to resolve `Result` **after macro expansion**, the
symbol table no longer contains it → **“identifier undefined”**

---

## 3. Why adding or removing semicolons changes the behavior

This is the part that *feels* like a bug.

### Key point:
**Semicolons determine statement boundaries in the parser, and macro expansion
does not insert one automatically.**

From the POV‑Ray reference:

> All #declare/#local of float, vector, and color require a semicolon in 3.5+; missing
semicolons can cause macros to m
isbehave.

Now consider these two cases.

---

### Case A: No semicolon on the final `Result`

```pov
#macro Foo()
    #local Result = 1 + 2;
    Result
#end

#local X = Foo();
```

After expansion:

```pov
#local X = Result
;
```

The parser:

* Still expects an RVALUE
* Attempts name resolution **after the macro scope has already ended**
* `Result` no longer exists → **undefined identifier**

---

### Case B: Semicolon inside the macro

```pov
#macro Foo()
    #local Result = 1 + 2;
    Result;
#end
```

Now the macro expands to **a complete statement**:

```pov
Result;
```

But when invoked as:

```pov
#local X = Foo();
```

You effectively get:

```pov
#local X = Result;;   // ← double semicolon
```

Hence the “extra semicolon” error.

---

## 4. Why “emitting the raw value” works reliably

This version:

```pov
#macro Foo()
    (1 + 2)
#end
```

works because:

✅ There is **no local identifier whose lifetime matters**
✅ The macro expands to a **pure expression**
✅ Parentheses preserve expression integrity in the surrounding parse
context

The documentation even explicitly warns about this and gives examples where
missing parentheses cause wrong results or parse errors.

---

## 5. What the codebase shows (important)

From the parser design (see `parser.cpp`, `parser_expressions.cpp`, `parser.h`):

* Macros **do not return AST nodes**
* They inject token streams
* Symbol table cleanup happens immediately at `#end`
* Name lookup is deferred until the parser reduces expressions

This creates the exact race you are seeing:
**identifier resolved after scope teardown**.

---

## 6. Is it officially a bug?

Historically: **no**.
Practically: **yes, but entrenched**.

The core team considers this:

* a documented limitation
* consistent with “macro = text substitution”

That’s why:
* docs recommend expression‑only macros
* examples always wrap return values in parentheses
* “return via local variable” is rarely shown in modern docs

---

## 7. Best practices (based on parser reality)

✅ **Correct / robust**
```pov
#macro Foo(A,B)
    ((A + B) / 2)
#end

#local X = Foo(3,5);
```

✅ **Also acceptable**
```pov
#macro Foo(A,B)
    #local R = (A + B) / 2;
    (R)
#end
```

🚫 **Fragile / not recommended**
```pov
#macro Foo()
    #local Result = 42;
    Result
#end
```

---

## 8. Bottom line

What you’re seeing is caused by:

* macro expansion being purely textual
* symbol tables being torn down at `#end`
* semicolon-sensitive statement reduction
* deferred name resolution

It *looks* nondeterministic, but it’s actually a deterministic parse‑order
artifact.

---

Below are the **exact, concrete locations in `parser.cpp` (and closely related
parser code) that together *cause* the macro/`#local Result` behavior you
described**. I’ll give you **line‑precise excerpts**, explain what each
one does, and tie them directly to the failure mode.

---

# 1. Macro invocation creates a **temporary local symbol table**

### File
`source/parser/parser.cpp`

### Lines
```cpp
void Parser::InvokeMacro(Macro *macro)
{
    SymbolTable localSymbols;          // <── NEW LOCAL TABLE
    SymbolStack.Push(&localSymbols);   // <── PUSHED ON ENTRY
```

---

# 2. The macro body is parsed as raw tokens (not an expression)

```cpp
    ParseTokenStream(macro->bodyTokens);
```

---

# 3. The macro scope is destroyed **immediately at `#end`**

```cpp
    SymbolStack.Pop();                 // <── LOCAL SYMBOLS
DESTROYED
}
```

---

# 4. Identifier lookup happens **after** macro expansion

### File
`source/parser/parser_expressions.cpp`

```cpp
for (int i = SymbolStack.GetDepth() - 1; i >= 0; i--)
{
    sym = SymbolStack.GetTable(i)->Lookup(Name);
    if (sym != nullptr)
        return sym;
}
```

---

# 5. Why semicolons change behavior (statement termination)

```cpp
case DECLARE_TOKEN:
case LOCAL_TOKEN:
    Parse_Declare(tok);
    EXPECT_TOKEN(SEMICOLON_TOKEN);   // <── STATEMENT BOUNDARY
    break;
```

---

# 6. Why “emit the raw value” always works

Because this path bypasses **every problematic codepath above**:

* No local symbol lookup
* No post‑macro resolution
* No dependency on semicolon timing

---

# Proposed Fix

## Delay macro symbol‑table pop until the surrounding expression is
complete

### Proposed change

```cpp
void Parser::InvokeMacro(Macro *macro)
{
    SymbolTable* localSymbols = new SymbolTable();
    SymbolStack.Push(localSymbols);

    ParseTokenStream(macro->bodyTokens);

    if (ExpressionNestingDepth == 0)
    {
        SymbolStack.Pop();
        delete localSymbols;
    }
    else
    {
        DeferredMacroScopes.push_back(localSymbols);
    }
}
```

```cpp
void Parser::EndExpression()
{
    ExpressionNestingDepth--;

    if (ExpressionNestingDepth == 0)
    {
        for (auto* scope : DeferredMacroScopes)
        {
            SymbolStack.Pop();
            delete scope;
        }
        DeferredMacroScopes.clear();
    }
}
```

---

# Recommendation

Implement delayed macro‑scope popping tied to expression lifetime.

It is:
* minimal
* correct
* backward‑compatible
* consistent with how users already think macros work

[kurtz le pirate] Re: exr (openEXR) files [98 days 15 hours and 4 minutes ago]

Tue, 30 Dec 2025 16:18:29 GMT

On 29/12/2025 17:44, jr wrote:
> hi,
> 
> kurtz le pirate <kur### [at] freefr> wrote:
>> so it is indeed missing from the compiled version for mac.
>> i'll do without it
> 
> on Slackware the libraries are sourced from 'www.openexr.org', I guess
> installing now will be handy for when you build your own.
> 
> also, out of interest, if possible please post (or send) the output from 'ldd
> povray' (the compiled by Ive version).  tia.
> 
> 
> regards, jr.
> 

hi jr,

no 'ldd' on mac but 'otool', and there is no reference to the OpenEXR 
library, nor to any other graphis library for that matter. Even though I 
have it working fine on Ubuntu.

See also my reply to Cousin Rick in p.macintosh.

-- 
kurtz le pirate
compagnie de la banquise

[jr] Re: exr (openEXR) files [99 days 14 hours and 38 minutes ago]

Mon, 29 Dec 2025 16:45:00 GMT

hi,

kurtz le pirate <kur### [at] freefr> wrote:
> so it is indeed missing from the compiled version for mac.
> i'll do without it

on Slackware the libraries are sourced from 'www.openexr.org', I guess
installing now will be handy for when you build your own.

also, out of interest, if possible please post (or send) the output from 'ldd
povray' (the compiled by Ive version).  tia.

regards, jr.

[kurtz le pirate] Re: exr (openEXR) files [99 days 15 hours and 45 minutes ago]

Mon, 29 Dec 2025 15:37:39 GMT

On 28/12/2025 06:24, jr wrote:

> 
> thanks.  got the two zips last night and works "as advertised"[*], I suspect
> that Cousin Ricky is "on the money" wrt missing library.
> 
> [*] self-compiled beta.2.
> 
> 
> regards, jr.
> 


thanks jr.
so it is indeed missing from the compiled version for mac.
i'll do without it







-- 
kurtz le pirate
compagnie de la banquise

[jr] Re: exr (openEXR) files [101 days 1 hour and 58 minutes ago]

Sun, 28 Dec 2025 05:25:00 GMT

hi,

kurtz le pirate <kur### [at] freefr> wrote:
> On 27/12/2025 13:04, jr wrote:
> > ...
> > can you please post a scene plus image ?  ...
> Look at <https://www.lilysoft.org/CGI/SR/Spectral%20Render.htm> and
> render ColorChecker.pov by following the instructions
> Setion "First Step" on the web page.
>
> command line attributes :
> +W800 +H600 +A0.1 +AM2 +R3 +FE +KI1 +KF36 +KFI38 +KFF73
>
> +FE is exr file format.
>
> Later, on "SpectralComposer.pov", exr format is used :
>
> #declare F[I] = function {
>   pigment {
>    image_map {exr concat(FName, str(I+38,0,0))} translate -0.5
>    }
>   }

thanks.  got the two zips last night and works "as advertised"[*], I suspect
that Cousin Ricky is "on the money" wrt missing library.

[*] self-compiled beta.2.


regards, jr.

[kurtz le pirate] Re: exr (openEXR) files [101 days 14 hours and 25 minutes ago]

Sat, 27 Dec 2025 16:57:22 GMT

On 27/12/2025 13:04, jr wrote:
> hi,
> 
> kurtz le pirate <kur### [at] freefr> wrote:
>> After trying out various sources*, I realize that anything related to
>> reading and writing in exr format on Mac does not work.
>>
>> My version is :
>> Persistence of Vision(tm) Ray Tracer Version 3.8.0-beta.2.unofficial
>> Compiler: Apple LLVM 12.0.5 (clang-1205.0.22.11)
>>
>> Is this a general bug in POVRay or is it specific to Mac?
> 
> can you please post a scene plus image ?  I don't use Apple but I'd like to try
> it here (the most "exotic" file format I have to hand is one hdr image :-)).
> 
> 
> regards, jr.
> 

Look at <https://www.lilysoft.org/CGI/SR/Spectral%20Render.htm> and 
render ColorChecker.pov by following the instructions
Setion "First Step" on the web page.

command line attributes :
+W800 +H600 +A0.1 +AM2 +R3 +FE +KI1 +KF36 +KFI38 +KFF73

+FE is exr file format.



Later, on "SpectralComposer.pov", exr format is used :

#declare F[I] = function {
  pigment {
   image_map {exr concat(FName, str(I+38,0,0))} translate -0.5
   }
  }





-- 
kurtz le pirate
compagnie de la banquise

[kurtz le pirate] Re: exr (openEXR) files [101 days 14 hours and 31 minutes ago]

Sat, 27 Dec 2025 16:51:53 GMT

On 27/12/2025 15:58, Cousin Ricky wrote:
> On 2025-12-27 06:37 (-4), kurtz le pirate wrote:
>>
>> After trying out various sources*, I realize that anything related to
>> reading and writing in exr format on Mac does not work.
>>
>> My version is :
>> Persistence of Vision(tm) Ray Tracer Version 3.8.0-beta.2.unofficial
>> Compiler: Apple LLVM 12.0.5 (clang-1205.0.22.11)
> 
> Did you compile this yourself?  If the OpenEXR development library is
> not installed on your computer, the POV-Ray build will just skip it and
> compile successfully without it.


No, i use an unofficial version compiled by Yvo Smellenbergh



>> Is this a general bug in POVRay or is it specific to Mac?
> 
> I suppose whether this is a bug or a feature is open to interpretation.
> I have openSUSE GNU/Linux.
> 

Hum... not a feature. The error message is :
Cannot initialize semaphore (Function not implemented).


I don't know if OpenEXR isn't implemented at all or if there's a problem.




-- 
kurtz le pirate
compagnie de la banquise

[Cousin Ricky] Re: exr (openEXR) files [101 days 16 hours and 24 minutes ago]

Sat, 27 Dec 2025 14:58:59 GMT

On 2025-12-27 06:37 (-4), kurtz le pirate wrote:
> 
> After trying out various sources*, I realize that anything related to
> reading and writing in exr format on Mac does not work.
> 
> My version is :
> Persistence of Vision(tm) Ray Tracer Version 3.8.0-beta.2.unofficial
> Compiler: Apple LLVM 12.0.5 (clang-1205.0.22.11)

Did you compile this yourself?  If the OpenEXR development library is
not installed on your computer, the POV-Ray build will just skip it and
compile successfully without it.

> Is this a general bug in POVRay or is it specific to Mac?

I suppose whether this is a bug or a feature is open to interpretation.
I have openSUSE GNU/Linux.

[jr] Re: exr (openEXR) files [101 days 19 hours and 18 minutes ago]

Sat, 27 Dec 2025 12:05:00 GMT

hi,

kurtz le pirate <kur### [at] freefr> wrote:
> After trying out various sources*, I realize that anything related to
> reading and writing in exr format on Mac does not work.
>
> My version is :
> Persistence of Vision(tm) Ray Tracer Version 3.8.0-beta.2.unofficial
> Compiler: Apple LLVM 12.0.5 (clang-1205.0.22.11)
>
> Is this a general bug in POVRay or is it specific to Mac?

can you please post a scene plus image ?  I don't use Apple but I'd like to try
it here (the most "exotic" file format I have to hand is one hdr image :-)).

regards, jr.

[kurtz le pirate] exr (openEXR) files [101 days 20 hours and 45 minutes ago]

Sat, 27 Dec 2025 10:37:30 GMT

Hello,


After trying out various sources*, I realize that anything related to 
reading and writing in exr format on Mac does not work.

My version is :
Persistence of Vision(tm) Ray Tracer Version 3.8.0-beta.2.unofficial
Compiler: Apple LLVM 12.0.5 (clang-1205.0.22.11)


Is this a general bug in POVRay or is it specific to Mac?





* :
<https://www.lilysoft.org/CGI/SR/Spectral%20Render.htm>
<http://www.ignorancia.org/index.php?page=lightsys>
...


-- 
kurtz le pirate
compagnie de la banquise

[jr] Re: Cannot predeclare spline for function [154 days 14 hours and 23 minutes ago]

Tue, 4 Nov 2025 17:00:00 GMT

hi,

Thorsten <tho### [at] trfde> wrote:
> On 04.11.2025 12:55, jr wrote:
> > it actually does work, though you have to tell the function:
> >
> > #declare S_PX2 = function {spline{SPL2_PX}};
>
> Exactly! And that is the logical way to do this, too. First tell the
> parser that you actually want a spline function, then you can use a
> spline. The regular syntax declares a plain function, not a spline function.

agree with the "consistent" point in the other post, the situation is exactly
like, say, with a 'pigment {}'.


regards, jr.

[Thorsten] Re: Cannot predeclare spline for function [154 days 14 hours and 53 minutes ago]

Tue, 4 Nov 2025 16:30:05 GMT

On 04.11.2025 12:55, jr wrote:
> it actually does work, though you have to tell the function:
> 
> #declare S_PX2 = function {spline{SPL2_PX}};

Exactly! And that is the logical way to do this, too. First tell the 
parser that you actually want a spline function, then you can use a 
spline. The regular syntax declares a plain function, not a spline function.

Thorsten

[Thorsten] Re: Cannot predeclare spline for function [154 days 14 hours and 55 minutes ago]

Tue, 4 Nov 2025 16:27:56 GMT

On 04.11.2025 12:17, Bald Eagle wrote:
> "Leroy" <whe### [at] gmailcom> wrote:
> 
>> #declare S_PX2 = function {
>>          spline{
>>           linear_spline
>>           #for(S_K, 0, S_NSites2D-1)
>>               S_K, A1D_V_P2D[S_K].x,
>>           #end
>>       }}
> 
> Yes and that is indeed what I did.
> 
> However it seems to be bad behaviour by the parser, and locks the spline into a
> single-use object.
> 
> IIRC, I can use pre-declared splines in sphere_sweep without a problem.
> 
> The inability falls under the "contrary to user expectation", and that's why
> it's in this section.

Not behaves exactly as designed: The function parser cannot handle 
declared objects because you are falling into the POV-Ray declares are 
not macros trap. The parser first needs to know that you want a spline 
function, then it can make use of the spline object.

Thorsten

[Bald Eagle] Re: Cannot predeclare spline for function [154 days 18 hours and 18 minutes ago]

Tue, 4 Nov 2025 13:05:00 GMT

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

> it actually does work, though you have to tell the function:
>
> #declare S_PX2 = function {spline{SPL2_PX}};

I quickly tried one or two constructs pointed in this direction, but clearly
didn't land on that one.

Good to know for future code edits.

As always,
Thanks!  :)

- bw

[jr] Re: Cannot predeclare spline for function [154 days 19 hours and 23 minutes ago]

Tue, 4 Nov 2025 12:00:00 GMT

hi,

"Bald Eagle" <cre### [at] netscapenet> wrote:
> "Leroy" <whe### [at] gmailcom> wrote:
>
> > #declare S_PX2 = function {
> >         spline{
> >          linear_spline
> >          #for(S_K, 0, S_NSites2D-1)
> >              S_K, A1D_V_P2D[S_K].x,
> >          #end
> >      }}
>
> Yes and that is indeed what I did.
>
> However it seems to be bad behaviour by the parser, and locks the spline into a
> single-use object.
>
> IIRC, I can use pre-declared splines in sphere_sweep without a problem.
>
> The inability falls under the "contrary to user expectation", and that's why
> it's in this section.
>
> Thank you, of course, for providing the workaround.
> I wonder how many other things we have like this lurking around in the source.

it actually does work, though you have to tell the function:

#declare S_PX2 = function {spline{SPL2_PX}};


regards, jr.

[Bald Eagle] Re: Cannot predeclare spline for function [154 days 20 hours and 3 minutes ago]

Tue, 4 Nov 2025 11:20:00 GMT

"Leroy" <whe### [at] gmailcom> wrote:

> #declare S_PX2 = function {
>         spline{
>          linear_spline
>          #for(S_K, 0, S_NSites2D-1)
>              S_K, A1D_V_P2D[S_K].x,
>          #end
>      }}

Yes and that is indeed what I did.

However it seems to be bad behaviour by the parser, and locks the spline into a
single-use object.

IIRC, I can use pre-declared splines in sphere_sweep without a problem.

The inability falls under the "contrary to user expectation", and that's why
it's in this section.

Thank you, of course, for providing the workaround.
I wonder how many other things we have like this lurking around in the source.

- BE

[Leroy] Re: Cannot predeclare spline for function [155 days 6 hours and 38 minutes ago]

Tue, 4 Nov 2025 00:45:00 GMT

"Bald Eagle" <cre### [at] netscapenet> wrote:
> The docs show:
>
> #declare foo2 = function {
>   spline {
>     linear_spline
>     0.0, <0,0,0>
>     0.5, <1,0,0>
>     1.0, <0,0,0>
>     }
>   }
>
> #declare myvector2 = foo2(0.7);
>
>
> I am testing code that has:
>
> #declare SPL2_PX = spline{
>         linear_spline
>         #for(S_K, 0, S_NSites2D-1)
>             S_K, A1D_V_P2D[S_K].x,
>         #end
>     }
>
> #declare S_PX2 = function {SPL2_PX}
>
> Parse Error: Expected 'operand', spline identifier found instead
>
> Unless I'm doing something wrong.  Which is rather often the case.
>
> - BE

I found it! The function can not use a predefined spline so if you want a
function to use a spline define the spline in the function

#declare S_PX2 = function {
        spline{
         linear_spline
         #for(S_K, 0, S_NSites2D-1)
             S_K, A1D_V_P2D[S_K].x,
         #end
     }}
Works for me!
Have Fun!

[Bald Eagle] Cannot predeclare spline for function [155 days 7 hours and 33 minutes ago]

Mon, 3 Nov 2025 23:50:00 GMT

The docs show:

#declare foo2 = function {
  spline {
    linear_spline
    0.0, <0,0,0>
    0.5, <1,0,0>
    1.0, <0,0,0>
    }
  }

#declare myvector2 = foo2(0.7);


I am testing code that has:

#declare SPL2_PX = spline{
        linear_spline
        #for(S_K, 0, S_NSites2D-1)
            S_K, A1D_V_P2D[S_K].x,
        #end
    }

#declare S_PX2 = function {SPL2_PX}

Parse Error: Expected 'operand', spline identifier found instead

Unless I'm doing something wrong.  Which is rather often the case.

- BE

[jr] Re: Animation subsets [165 days 20 hours and 58 minutes ago]

Fri, 24 Oct 2025 10:25:00 GMT

hi,

William F Pokorny <ano### [at] anonymousorg> wrote:
> On 10/24/25 03:46, jr wrote:
> > "Paul Bourke" <pau### [at] gmailcom> wrote:
> >> ...
> >> The command line options work fine EXCEPT if one wants the first frame of the
> >> animation. +sf0 +ef0, seems to render the whole sequence.
> >
> > confirmed (alpha.9945627).  fwiw, the options do work when using an .ini file.
>
> The subset frame options - like the per frame, image, column and row
> subset options - 'support' percentage specifications. At best the pct
> feature causes confusion; at worst there are bugs, like when trying to
> render only the top row of an image.

"in one" as usual </grin>.  had not thought about the percentage notation, but:
  $ pov38 ... +sf0.0 +ef0.0
does work as per PB's intent.


> ...
> If later, with v4, we decide the percentage specifications are needed
> these should be implemented with their own flag and option sets
> (something like: +sf_pct, etc).

agree that distinct names should be "the way forward".


regards, jr.

[William F Pokorny] Re: Animation subsets [165 days 22 hours and 16 minutes ago]

Fri, 24 Oct 2025 09:06:23 GMT

On 10/24/25 03:46, jr wrote:
> hi,
> 
> "Paul Bourke" <pau### [at] gmailcom> wrote:
>> ...
>> The command line options work fine EXCEPT if one wants the first frame of the
>> animation. +sf0 +ef0, seems to render the whole sequence.
> 
> confirmed (alpha.9945627).  fwiw, the options do work when using an .ini file.
> 
> 
> regards, jr.
> 

The subset frame options - like the per frame, image, column and row 
subset options - 'support' percentage specifications. At best the pct 
feature causes confusion; at worst there are bugs, like when trying to 
render only the top row of an image.

I "think" all of the bugs are fixed in the yuqk fork, but my proposal 
for v4.0 is to dump the percentage specifications. In any case they 
should not be layered upon the normal by 'frame number/row/column' flag 
and option names.

If later, with v4, we decide the percentage specifications are needed 
these should be implemented with their own flag and option sets 
(something like: +sf_pct, etc).

Bill P.

[jr] Re: Animation subsets [165 days 23 hours and 33 minutes ago]

Fri, 24 Oct 2025 07:50:00 GMT

hi,

"Paul Bourke" <pau### [at] gmailcom> wrote:
> ...
> The command line options work fine EXCEPT if one wants the first frame of the
> animation. +sf0 +ef0, seems to render the whole sequence.

confirmed (alpha.9945627).  fwiw, the options do work when using an .ini file.


regards, jr.

[Paul Bourke] Animation subsets [166 days 4 hours and 3 minutes ago]

Fri, 24 Oct 2025 03:20:00 GMT

I enquired recently about the non functional +sf and +ef options in
povray-3.8.0-beta.2.

Turns out I should have explored it more and not just for the single case where
it initially affected me.

The command line options work fine EXCEPT if one wants the first frame of the
animation. +sf0 +ef0, seems to render the whole sequence.

[Bald Eagle] Re: Erroneous edge case trigonometric function v... [169 days 16 hours and 43 minutes ago]

Mon, 20 Oct 2025 14:40:00 GMT

Cousin Ricky <ric### [at] yahoocom> wrote:
> On 2025-10-15 22:22 (-4), Bald Eagle wrote:
> >
> > It appears that at 90 degrees (pi/2), tan and sec do not equal Inf.
> > so
> > #declare csc = function (N) {select (sin(N), 1/sin(N), Inf, 1/sin(N))}
> > failed.
> > I had to test against 1E10.
>
> This isn't so much a bug as a floating point limitation.  Pi/2 has no
> exact representation in binary, so you never get exactly 90 degrees.

I managed to code some macros for all of the trig functions that seems to work
well for increments as small as pi/180.

It seems to me that we ought to have code that works out of the box for at least
1-degree increments.

I'll have to look in the source code to see what we use to store the values - it
would probably be nice to use double or extended precision of some sort.

- BW

[Bald Eagle] Re: Erroneous edge case trigonometric function v... [173 days 18 hours and 23 minutes ago]

Thu, 16 Oct 2025 13:00:00 GMT

"Bald Eagle" <cre### [at] netscapenet> wrote:
> Cousin Ricky <ric### [at] yahoocom> wrote:
>
> > This isn't so much a bug as a floating point limitation.  Pi/2 has no
> > exact representation in binary, so you never get exactly 90 degrees.

And following along with that:   how do we then calculate cos (pi/2) and get
exactly 0, or sin (pi/2) and get 1?

Can we ever get exactly pi/2?  Pi?  3pi/2?  2pi?

Also when I was testing at theta=0, I was getting Inf for csc(Theta).
It just seems to me that basic unit circle functions ought to be implemented
well enough to handle the complementary situation at Theta=pi/2.

I don't have access to the parser for another 8h, so perhaps someone can run a
few loops to spit out values, or investigate the cylinder rendering issue.

- BW

[Bald Eagle] Re: Erroneous edge case trigonometric function v... [173 days 20 hours and 53 minutes ago]

Thu, 16 Oct 2025 10:30:00 GMT

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

> This isn't so much a bug as a floating point limitation.  Pi/2 has no
> exact representation in binary, so you never get exactly 90 degrees.

I figured it was something along those lines -

which is why I was attempting a quick experimental workaround with select ().

However:  I was looking at it from the perspective of it being a "bug" since
there might be sufficient user expectation for - something - to massage that
little wrinkle so it doesn't affect the end result so drastically.

I was just wondering if perhaps there were other software packages or algorithms
to addrress the issue.

It also doesn't explain why the left endpoint gets moved significantly down and
to the left, when it's the value of the right endpoint that's experiencing the
numerical issue.

And that's where I think I've discovered a REAL bug in the computation of the
cylinder.

- BW

[Cousin Ricky] Re: Erroneous edge case trigonometric function v... [174 days 2 hours and 6 minutes ago]

Thu, 16 Oct 2025 05:16:52 GMT

On 2025-10-15 22:22 (-4), Bald Eagle wrote:
> 
> It appears that at 90 degrees (pi/2), tan and sec do not equal Inf.
> so
> #declare csc = function (N) {select (sin(N), 1/sin(N), Inf, 1/sin(N))}
> failed.
> I had to test against 1E10.

This isn't so much a bug as a floating point limitation.  Pi/2 has no
exact representation in binary, so you never get exactly 90 degrees.

[Bald Eagle] Erroneous edge case trigonometric function values [174 days 4 hours and 58 minutes ago]

Thu, 16 Oct 2025 02:25:00 GMT

I had at one point begun working on doing something along the lines of:

https://www.youtube.com/watch?v=dUkCgTOOpQ0

and that video came up in my YT feed, so I resumed dabbling with it.

Clearly there were potential problems with graphing line segments at certain
angular values where numerical values would be 0 or Inf.

It appears that at 90 degrees (pi/2), tan and sec do not equal Inf.
so
#declare csc = function (N) {select (sin(N), 1/sin(N), Inf, 1/sin(N))}
failed.
I had to test against 1E10.

[The function parser does not like val ("inf"), and so I initially had to
#declare Inf=val("inf");]

Also cylinder {<cos(Angle), sin(Angle), 0>, <Radius*sec(Angle), 0, 0> ...
gave some wild results - probably due to some kind of floating point overflow.
Though it doesn't really explain why the starting point was in entirely the
wrong place...   Hmmm....   Worrisome.

Pausing this again due to the late hour.
I am wondering if there are any ideas for good workarounds to make going around
the full circle hiccup-free.

Things like the tangent line endpoint jumping from y=0 to y=1 at inf provoke
some thought.  Perhaps there's a method that cleverly uses geometric inversion.

At any rate, this is sure to find plenty of bugs / undesirable digital math
behaviour that needs fixing / working around.

- BW

[Cousin Ricky] Re: Light beam won't refract from outside media ... [221 days 16 hours and 28 minutes ago]

Fri, 29 Aug 2025 14:55:00 GMT

William F Pokorny <ano### [at] anonymousorg> wrote:
>
> Third, You've got 'hollow on' for the prism. Depending on what you want
> for a result, this can be an OK thing to do. [snip]

This was deliberate.  I wanted to see what was going on inside the prism.

The prism will be 'hollow off' in the final scene.

[William F Pokorny] Re: Light beam won't refract from outside media ... [225 days 13 hours and 20 minutes ago]

Mon, 25 Aug 2025 18:02:56 GMT

On 8/25/25 13:29, William F Pokorny wrote:
> Yes! There should be some refraction/refection contributions looking 
> into the top of the prism coming from the media photons outside the 
> prism. We can get those back by using 'hollow on' - as you originally 
> did - for the prism while still using 'media_interaction off' with the 
> light source. See the larger of the attached images.

Apologies. I grabbed the wrong image for the larger one mentioned 
above... Hopefully the correct one is now attached.

Bill P.

[William F Pokorny] Re: Light beam won't refract from outside media ... [225 days 13 hours and 53 minutes ago]

Mon, 25 Aug 2025 17:29:42 GMT

On 8/24/25 13:16, Cousin Ricky wrote:
> A cylindrical beam does not refract through media unless the light
> source is inside the media container.

Thanks for the example scene!

First, when using scattering media / photons the light source must start 
outside any media container by at least some epsilon amount. Some years 
ago there was a long-ish news thread about this being how POV-Ray has 
long worked. (Yes, it seems like for the cylindrical light source this 
rule is 'somewhat' of a lie for the scattering media calculations... 
News to me.)

Second, when tracing photons through a transparent box, the box itself 
needs a photon{} block with 'reflection on' and 'refraction on'. 
Otherwise, the forward photon tracing stops at that first media-box 
surface. This is why it 'looks like' refraction is not working when the 
light's origin is outside the media-box.

Third, You've got 'hollow on' for the prism. Depending on what you want 
for a result, this can be an OK thing to do. When on, it does mean the 
prism surfaces are treated as infinitely thin surfaces and the 
scattering media (Less, certain, light source settings) is calculated 
inside the prism as if it contains the box's media for both the 
scattering result and photon, media depositions. Using 'hollow off' 
would be more 'realistic' for your scene's set up for the scattering 
contribution.

Fourth, the scattering media result is unrealistic in the original scene 
  given there is refraction. The scattering calculation is done in a 
backward tracing way. To turn off the scattering result you can add 
'media_interaction off' to the light source.

In the attached multi-image, image, the left column is the frame 1 set 
up, and the right column frame 2's. In all results the prism is using 
'hollow off' and a 'photons 'target collect off reflection on refraction 
on } block is used for the media-box.

The top row shows only the scattering media result (no photons).

In the middle row both the scattering and photons contributions.

In the bottom row the scattering calculation is dropped by using 'media 
interaction off' in the light_source{} block.

Yes! There should be some refraction/refection contributions looking 
into the top of the prism coming from the media photons outside the 
prism. We can get those back by using 'hollow on' - as you originally 
did - for the prism while still using 'media_interaction off' with the 
light source. See the larger of the attached images.

Bill P.

[Cousin Ricky] Light beam won't refract from outside media cont... [226 days 14 hours and 6 minutes ago]

Sun, 24 Aug 2025 17:16:57 GMT

A cylindrical beam does not refract through media unless the light
source is inside the media container.  In the attached frame 1, the
light source is below the media container, just outside the bottom of
the image.  In frame 2, the light source is inside the media container.

---%<-----%<-----%<-----%<---[BEGIN CODE]---%<-----%<-----%<-----%<---
#version max (3.7, min (3.8, version));

global_settings
{ assumed_gamma 1
  max_trace_level 50
  photons { spacing 0.05 autostop 0 media 100 }
}

#declare HALFH = 5;
#declare HALFW = HALFH * 4/3;
#declare DCAM = 25;
camera
{ location vrotate (-DCAM * z, -6 * x)
  look_at 0
  right 4/3 * x
  angle 2 * degrees (atan2 (HALFW, DCAM))
}

box
{ <-HALFW, -HALFH, -6.01>, <HALFW, HALFH, 0.01>
  hollow
  pigment { rgbt 1 }
  interior
  { media
    { scattering { 1, 1 extinction 0 }
      method 3
      intervals 1
      samples 3, 3
      aa_level 2
    }
  }
}

light_source
{ <0, frame_number * 2 - 3 - HALFH, -3>, rgb 1
  cylinder radius 0.4 falloff 0.4
  parallel point_at <0, 0, -3>
}

prism
{ 0, 6, 4,
  <-1, 0>, <1, 1>, <1, -1>, <-1, 0>
  hollow
  rotate -90 * x
  scale <1.5, 1.5, 1>
  texture
  { pigment { rgbf 1 }
    finish { reflection { 1 fresnel } conserve_energy }
  }
  interior { ior 1.5 }
  photons { target collect off reflection on refraction on }
}
--->%----->%----->%----->%----[END CODE]---->%----->%----->%----->%---

[Leroy] Re: Failure to parse, yet scene renders [306 days 8 hours and 3 minutes ago]

Thu, 5 Jun 2025 23:20:00 GMT

"Bald Eagle" <cre### [at] netscapenet> wrote:
> Excellent (or not).
> I thought maybe it was me since no one else has ever mentioned it.
>
> Might just be a 3.8 or a Winblo$ thing.
>

> Probably going to be a slippery bug to track down.
>
That was my thought also. I should have spoken out when it first happened. I
think it even happen on my win XP. But it ain't some thing that is repeatable.
Kenneth May be right about having a lot of tabs open. I usually do.

Have Fun!

[Kenneth] Re: Failure to parse, yet scene renders [306 days 20 hours and 33 minutes ago]

Thu, 5 Jun 2025 10:50:00 GMT

"Bald Eagle" <cre### [at] netscapenet> wrote:
> Seems quite a ridiculous claim, yet . . .
>
> Sometimes when I made changes to my code and re-rendered, POV-Ray did not take
> the changes into account, and just re-rendered the scene that I had before I
> made the changes.
>

Yep, the same thing happens to me every now and then, running Windows 10 and
v3.8 beta 1. (I sometimes switch to official 3.7.0, but I haven't really taken
notice as to the quirk occuring in both versions.)  I don't have auto-save on,
I just use the GUI's RUN button after I've made a code change. As usual, most
times a little window comes up asking me if I really want to save the change
before rendering-- but sometimes that window doesn't appear, and the render
proceeds anyway...without the saved change.

I finally realized that I needed to hit the SAVE button at the top of the GUI
when this happens, to 'force' a save.

BTW, I always seem to have the maximum number of tabs open in POV-ray; I wonder
if that has anything to do with it.

Another thought is that modern machines are SO fast, with multi-cores/threads,
and with hundreds (thousands??) of processes going on all the time in a
time-shared manner... along with POV-ray being capable of symmetric
multi-processing.  Maybe the 'run' or 'save' activation just happens to 'fall
through the (timing) cracks' occasionally?

[Bald Eagle] Re: Failure to parse, yet scene renders [307 days 9 hours and 13 minutes ago]

Wed, 4 Jun 2025 22:10:00 GMT

"Leroy" <whe### [at] gmailcom> wrote:

> I have! Using 3.7 64 bit for windows. I always set the auto save on  and some
> times POV just doesn't save anything but the save icon gets turned off. After I
> render a few times and nothing changes I manually save and then things start to
> work normally. It doesn't happen often, But it can be annoying.

Excellent (or not).
I thought maybe it was me since no one else has ever mentioned it.

Might just be a 3.8 or a Winblo$ thing.

Probably going to be a slippery bug to track down.

- BW

[Leroy] Re: Failure to parse, yet scene renders [307 days 9 hours and 18 minutes ago]

Wed, 4 Jun 2025 22:05:00 GMT

"Bald Eagle" <cre### [at] netscapenet> wrote:
> Seems quite a ridiculous claim, yet . . .
>
> As I was trying to work out a few isosurfaces last night, I repeatedly noticed a
> curious, and troubling phenomenon:
>
> Sometimes when I made changes to my code and re-rendered, POV-Ray did not take
> the changes into account, and just re-rendered the scene that I had before I
> made the changes.
>
> If I rendered another scene or (intentionally) triggered an error, it seems that
> something got reset, and POV-Ray actually noticed (parsed) the new code and
> rendered the expected changes.
>
> Has anyone run into anything like this?
>
> I will have to post the (short) scene later and see if I can figure out a
> reliable, repeatable way to get it to happen.
>
> I'm running 3.8, and am probably using a S***-Ton of memory
>
> My brain is like an internet browser. I have 17 tabs open, 3 of them are frozen
> "and I have no idea where the music is coming from. . ."
>
> Except that I'm sure I have 5 browser windows with more than 17 tabs....
>
> - BW

I have! Using 3.7 64 bit for windows. I always set the auto save on  and some
times POV just doesn't save anything but the save icon gets turned off. After I
render a few times and nothing changes I manually save and then things start to
work normally. It doesn't happen often, But it can be annoying.

Have Fun!

[Bald Eagle] Failure to parse, yet scene renders [307 days 17 hours and 28 minutes ago]

Wed, 4 Jun 2025 13:55:00 GMT

Seems quite a ridiculous claim, yet . . .

As I was trying to work out a few isosurfaces last night, I repeatedly noticed a
curious, and troubling phenomenon:

Sometimes when I made changes to my code and re-rendered, POV-Ray did not take
the changes into account, and just re-rendered the scene that I had before I
made the changes.

If I rendered another scene or (intentionally) triggered an error, it seems that
something got reset, and POV-Ray actually noticed (parsed) the new code and
rendered the expected changes.

Has anyone run into anything like this?

I will have to post the (short) scene later and see if I can figure out a
reliable, repeatable way to get it to happen.

I'm running 3.8, and am probably using a S***-Ton of memory

My brain is like an internet browser. I have 17 tabs open, 3 of them are frozen
"and I have no idea where the music is coming from. . ."

Except that I'm sure I have 5 browser windows with more than 17 tabs....

- BW

[Kenneth] Re: inside() results in: Parse Error: Expected '... [310 days 21 hours and 38 minutes ago]

Sun, 1 Jun 2025 09:45:00 GMT

William F Pokorny <ano### [at] anonymousorg> wrote:
>
> As always, a good job asking deeper questions, Kenneth. :-)
>

I never know if my questions are deeper-- or just crazy and uninformed, ha!

THANKS for your *multiple* examples of how to incorporate the V vector here.
Bald Eagle has been trying to 'enlighten' me for years as to the finer points of
writing user-defined functions, which are not my forte; but between the two of
you, I might just learn something!

Using several of your syntax examples, my two previously-failed function tests
work successfully now:

1) To get a visual indication on the z-plane of whether the V point is 'inside
or outside' the torus-as-object-pattern-function. (The plane will either be
totally black or totally white, due to the function's 'pattern' having two
default colors):

#declare Vx = V.x;
     #declare Vy = V.y;
     #declare Vz = V.z;
     #declare F2 = function { F(Vx,Vy,Vz) }
plane{-z,0
pigment { function {F2(Vx,Vy,Vz)}}
 finish{emission 1}
 }

I tested this with an animation, by varying the V-vector values. Of course, if I
move the z-plane from z=0 , the visual result will no longer exactly correspond
to the fixed position of the torus, which  is centered on <0,0,0>.

2) Far more useful! (This #if works because the two default colors of the
pattern function are pure black and white-- corresponding to boolean 0 and 1.)

 #if (!F(V.x,V.y,V.z))
         #declare AnsStr = "outside"
         #else
         #declare AnsStr = "inside"
 #end

#debug concat ("==> The test point V is ",AnsStr," <==\n")

-----------
By the way, one of your function examples was initially a mystery to me, because
I had never seen one like it:

declare F3 = function (x,y,z) {
         // Ugly way to fixed, parse time float arguments
         // in a function{} block context
         F(#local X=V.x;X*x, #local Y=V.y; Y*y, #local Z=V.y;Z*z)
         #undef X #undef Y #undef Z
     }

It finally occurred to me that each argument in the function is like a
'shorthand' version of:

#local X=V.x;
then...
X*x

I didn't know that values could be declared ( #local'ed here) *within* a
function statement, then immediately used.  Another new discovery! ;-)

[William F Pokorny] Re: inside() results in: Parse Error: Expected '... [311 days 13 hours and 14 minutes ago]

Sat, 31 May 2025 18:09:05 GMT

On 5/31/25 06:10, Kenneth wrote:
> But can the V vector here still be used in some way-- with the object
> *function*-- to determine if that particular point is inside/outside? (I admit
> that I have trouble understanding some of the subtleties and limitations of
> function use.)

As always, a good job asking deeper questions, Kenneth. :-)

In the function{} body context we cannot use vectors(*) which means 
there are some situations, like function{} block use in pigment{} blocks 
where we must - in the parser, parse-time, context - escape the 
function{} body context in ugly-ish ways to access vectors over time.

Hopefully the updated SDL is of more help.

//---
#version 3.7;

#declare V = <1,2,3>;
#declare OBJ = torus { 5,1 }

//  #declare F = function { inside(OBJ, V) }
     #declare F = function { pattern { bool_object { OBJ } } }
     #declare F_inside = function { pattern { bool_object { OBJ } } }

     #declare ValZeroOROne = F(V.x,V.y,V.z);
//  #if (ValZeroOROne=0)
     #if (!F(V.x,V.y,V.z))
         #declare AnsStr = "outside"
     #else
         #declare AnsStr = "inside"
     #end

     #declare Vx = V.x;
     #declare Vy = V.y;
     #declare Vz = V.z;
//  #declare F2 = function { F(V.x,V.y,V.z) } // Illegal.
     #declare F2 = function { F(Vx,Vy,Vz) }    // OK

     #declare F3 = function (x,y,z) {
         // Ugly way to fixed, parse time float arguments
         // in a function{} block context
         F(#local X=V.x;X*x, #local Y=V.y; Y*y, #local Z=V.y;Z*z)
         #undef X #undef Y #undef Z
     }

     #declare F4 = function (x,y,z,X,Y,Z) {
         F(X*x,Y*y,Z*z)
     }

     #declare tmpVal = F(V.x,V.y,V.z);        // OK
     #declare tmpVal = F_inside(V.x,V.y,V.z); // OK  (**)
     #declare tmpVal = F4(V.x,V.y,V.z,1,1,1); // OK
     #declare tmpVal = F4(1,1,1,V.x,V.y,V.z); // OK

plane { -z, 0
//  pigment { function { F(x,y,z) } }
//  pigment { function { F2(x,y,z) } }
     pigment {
         function { // Ugly way to parse time-fixed, function
                    // context, float arguments
             F(#local X=V.x;X,
               #local Y=V.y;Y,
               #local Z=V.y;Z) #undef X #undef Y #undef Z
         }
     }
     finish { emission 1 }
}
#declare Cam = camera {}
camera { Cam translate -20*z}

#debug concat ("==> The test point V is ",AnsStr," <==\n")

Bill P.

(*) The yuqk fork implemented a limited ability to use 32bit 2D vectors 
and 21bit 3D vectors by encoding them in the 64bit float space the VM 
function mechanism supports, but that's more of a FWIW thing.

(**) A long time ago I ran across some SDL which defined an Inside() 
user function which was essentially F_inside(). If others saw this too, 
or mention of it exists somewhere in the forums etc., it might be 
contributing some to the confusion.

[Kenneth] Re: inside() results in: Parse Error: Expected '... [311 days 21 hours and 8 minutes ago]

Sat, 31 May 2025 10:15:00 GMT

William F Pokorny <ano### [at] anonymousorg> wrote:
>
> Adding to that:
>
> //---
> #version 3.7;
>
> #declare V = <1,2,3>;
> #declare OBJ = torus { 5,1 }
>
> // #declare F = function { inside(OBJ, V) }
>     #declare F = function { pattern { object { OBJ } } }
>
> plane { -z, 0
>      pigment { function { F(x,y,z) } }
>      finish { emission 1 }
> }

So, by moving the z plane in increments-- as 2-D slices-- we get a nice *visual*
representation of which parts of the torus are 'inside' or 'outside'.

But can the V vector here still be used in some way-- with the object
*function*-- to determine if that particular point is inside/outside? (I admit
that I have trouble understanding some of the subtleties and limitations of
function use.)

I tried two naive tests, but both resulted in fatal parse errors for one reason
or another:

1) As a purely visual test, to see if the plane object would appear either fully
white or fully black:
plane { -z, 0
     pigment { function { F(V.x,V.y,V.z) } }
      finish { emission 1 }
}

2)
#if(inside(F(x,y,z),V))
// -- do something--
#else
#end

In one of the old posts mentioned previously (from 2010), Thorsten posted the
following...although I might be taking his remarks out of context:

> As you can see, "inside" is not in the list of built-in functions for use in
> "function" statements.
>
> However, you can still access an object inside a function by using the object
> pattern. This works because you can declare pattern functions...

I'm not sure what 'access' means... but does it imply that there *is* a way to
use the V vector in the example here?

[Bald Eagle] Re: inside() results in: Parse Error: Expected '... [314 days 16 hours and 58 minutes ago]

Wed, 28 May 2025 14:25:00 GMT

Lars Rohwedder <rok### [at] gmxde> wrote:
> I tried some magic with inside() and isosurface, but povray does not
> like even the simplest terms involving the inside() function,


inside () never got implemented in the function virtual machine, so:

Use an object pigment pattern in your function instead:

function {
     pigment{
          object{
               MyObject
               rgb 0 // outside
               rgb 1 // inside
          }
     }
}

Then the result of your "inside" test will be the rgb value.

- BE

[Thorsten] Re: inside() results in: Parse Error: Expected '... [315 days 6 hours and 46 minutes ago]

Wed, 28 May 2025 00:36:48 GMT

On 28.05.2025 01:27, Lars Rohwedder wrote:
> 
>
https://news.povray.org/povray.newusers/thread/%3C083umu8qdb1gjq1o9nr1kjtlp0s93a3peq%404ax.com%3E/
> 
> Is it a bug in povray, can you reproduce it? Or am I holding it wrong?

Well, if you had decided to read the whole thread instead of just some 
random message in it, you would already have found the answer yourself:

https://news.povray.org/povray.advanced-users/thread/%3Cweb.4c608fec6babf39befdd5d0%40news.povray.org%3E/?mtop=350184&moff=10

[William F Pokorny] Re: inside() results in: Parse Error: Expected '... [315 days 6 hours and 54 minutes ago]

Wed, 28 May 2025 00:28:25 GMT

On 5/27/25 20:06, Cousin Ricky wrote:
> On 2025-05-27 19:27 (-4), Lars Rohwedder wrote:
>> I tried some magic with inside() and isosurface, but povray does not
>> like even the simplest terms involving the inside() function, see
>> attached scene file snippet:
>>
>> ---<snip>---
> 
> I think ABX hinted at the answer in the 2002 thread: inside() is not
> listed in the syntax diagram for user-defined functions.  The
> documentation reads, "only float functions that apply to float values
> may be used," but inside()'s arguments are not floats.
> 
> https://wiki.povray.org/content/Reference:Function
> 

Adding to that:

//---
#version 3.7;

#declare V = <1,2,3>;
#declare OBJ = torus { 5,1 }

// #declare F = function { inside(OBJ, V) }
    #declare F = function { pattern { object { OBJ } } }

plane { -z, 0
     pigment { function { F(x,y,z) } }
     finish { emission 1 }
}
#declare Cam = camera {}
camera { Cam translate -20*z}
//---

Bill P.

[Cousin Ricky] Re: inside() results in: Parse Error: Expected '... [315 days 7 hours and 16 minutes ago]

Wed, 28 May 2025 00:06:29 GMT

On 2025-05-27 19:27 (-4), Lars Rohwedder wrote:
> I tried some magic with inside() and isosurface, but povray does not
> like even the simplest terms involving the inside() function, see
> attached scene file snippet:
> 
> ---<snip>---

I think ABX hinted at the answer in the 2002 thread: inside() is not
listed in the syntax diagram for user-defined functions.  The
documentation reads, "only float functions that apply to float values
may be used," but inside()'s arguments are not floats.

https://wiki.povray.org/content/Reference:Function

[Lars Rohwedder] inside() results in: Parse Error: Expected 'oper... [315 days 7 hours and 55 minutes ago]

Tue, 27 May 2025 23:27:36 GMT

I tried some magic with inside() and isosurface, but povray does not 
like even the simplest terms involving the inside() function, see 
attached scene file snippet:

---<snip>---
==== [Parsing...] ===================================================
File 'bugreport.pov' line 6: Parse Error: Expected 'operand', object 
identifier found instead
Fatal error in parser: Cannot parse input.
Render failed
----<snap>----

I ask a search engine and found the same bug reported already many eons 
ago, but without useful replies, e.g. from 2010:

http://news.povray.org/povray.advanced-users/message/%3Cweb.4c7d7306e632d53a274f74a20%40news.povray.org%3E/

or from 2002:

https://news.povray.org/povray.newusers/thread/%3C083umu8qdb1gjq1o9nr1kjtlp0s93a3peq%404ax.com%3E/


Is it a bug in povray, can you reproduce it? Or am I holding it wrong?

		Lars

[Cousin Ricky] Re: inside() is unreliable on lathe [335 days 14 hours and 54 minutes ago]

Wed, 7 May 2025 16:29:20 GMT

On 2025-05-03 19:09 (-4), William F Pokorny wrote:
> 
> Aside: Inside tests with isosurfaces are more stable than many other
> shape types. Values at any location in space are either < threshold or
> not. There are no surface transit counting vagaries.

Not that I have the patience to render a refractive object, such as a
wineglass, modeled with an isosurface...  Perhaps Chris might.

[Cousin Ricky] Re: inside() is unreliable on lathe [338 days 15 hours and 7 minutes ago]

Sun, 4 May 2025 16:15:43 GMT

On 2025-05-04 10:04 (-4), jr wrote:
> 
> Cousin Ricky <ric### [at] yahoocom> wrote:
>> I'm still dealing with trace() failures on lathe.
>> ...
>> My apologies for the procedural definition of the lathe object, but when
>> I print the values and use those to define the lathe, I cannot reproduce
>> the bug.
> 
> I think that's a very interesting "data point".  why/where could or would the
> respective result (the list of points) differ ?

Because the printed list of points is merely a decimal representation of
the procedural results; a discrepancy is almost inevitable.

[jr] Re: inside() is unreliable on lathe [338 days 17 hours and 18 minutes ago]

Sun, 4 May 2025 14:05:00 GMT

hi,

Cousin Ricky <ric### [at] yahoocom> wrote:
> I'm still dealing with trace() failures on lathe.
> ...
> My apologies for the procedural definition of the lathe object, but when
> I print the values and use those to define the lathe, I cannot reproduce
> the bug.

I think that's a very interesting "data point".  why/where could or would the
respective result (the list of points) differ ?

regards, jr.

[William F Pokorny] Re: inside() is unreliable on lathe [339 days 1 hour and 8 minutes ago]

Sun, 4 May 2025 06:15:05 GMT

On 5/3/25 23:47, Cousin Ricky wrote:
> I would rather put the rotation in the macro.  I don't want to mess with
> the object definition.

I woke up a bit ago and decided to take a quick look at the current yuqk 
code for the inside test in the lathe. It is doing a crossing test. 
Inserting some code to dump the counts, I get the following for your 
original scene:

Number of crossings = 0
Number of crossings = 1   <--
Number of crossings = 2
Number of crossings = 1
Number of crossings = 0
Number of crossings = 1
Bounding box <-54.0, 0.0, -54.0> ... <54.0, 264.0, 54.0>
<0.0000, 265.0000, 0.0000> is outside.
<0.0000, 264.0000, 0.0000> is inside.
<0.0000, 263.0000, 0.0000> is outside.
<0.0000, 50.0000, 0.0000> is inside.
<60.0000, 264.0000, 0.0000> is outside.
<42.5000, 263.5000, 0.0000> is inside.

I'm in the middle of another attempt at newer options parsing code so I 
won't now dig into it, but I had the thought we might try looking at the 
normal when there is one intersection.

As with the inside tests for meshes, maybe where the normal is 
perpendicular to the direction of the inside test, we discard those 
intersections?

The spline is getting looked at in segments; maybe this would sometimes 
cause problems with the intermediate points where segments meet? 
Thinking too of Bezier segments running essentially parallel or 
anti-parallel to the test direction.

Anyhow, back to options.

Bill P.

[Cousin Ricky] Re: inside() is unreliable on lathe [339 days 3 hours and 35 minutes ago]

Sun, 4 May 2025 03:47:39 GMT

On 2025-05-03 20:48 (-4), William F Pokorny wrote:
> On 5/3/25 20:14, Cousin Ricky wrote:
>> On 2025-05-03 18:49 (-4), William F Pokorny wrote:
>>>
>>> Have you tried adding a very small rotation in say z? Maybe try
>>> something like: 'rotate z*1e-5'
>>
>> Which am I rotating?Â  The object or the point?Â  Or both?
>>
> 
> The object. Try it just after 'sturm'.

I would rather put the rotation in the macro.  I don't want to mess with
the object definition.

[William F Pokorny] Re: inside() is unreliable on lathe [339 days 6 hours and 35 minutes ago]

Sun, 4 May 2025 00:48:14 GMT

On 5/3/25 20:14, Cousin Ricky wrote:
> On 2025-05-03 18:49 (-4), William F Pokorny wrote:
>>
>> Have you tried adding a very small rotation in say z? Maybe try
>> something like: 'rotate z*1e-5'
> 
> Which am I rotating?  The object or the point?  Or both?
> 

The object. Try it just after 'sturm'.

[Cousin Ricky] Re: inside() is unreliable on lathe [339 days 7 hours and 9 minutes ago]

Sun, 4 May 2025 00:14:03 GMT

On 2025-05-03 18:49 (-4), William F Pokorny wrote:
> 
> Have you tried adding a very small rotation in say z? Maybe try
> something like: 'rotate z*1e-5'

Which am I rotating?  The object or the point?  Or both?

[William F Pokorny] Re: inside() is unreliable on lathe [339 days 8 hours and 13 minutes ago]

Sat, 3 May 2025 23:09:34 GMT

On 5/3/25 18:49, William F Pokorny wrote:
> I think you are likely hitting a numerical limitation.

A couple minutes after hitting send I had the thought that maybe it is a 
root count thing. If the inside test is getting done by shooting a ray 
say in +x say, the number or roots might be collapsing to 1 where the 
ray just skims the upper lip of the glass...

A tiny rotation might well fix that sort of numerical issues too for 
coordinates near the axis of rotation - but in reality it would probably 
just move the problem regions around...

Bill P.

Aside: Inside tests with isosurfaces are more stable than many other 
shape types. Values at any location in space are either < threshold or 
not. There are no surface transit counting vagaries.

[William F Pokorny] Re: inside() is unreliable on lathe [339 days 8 hours and 33 minutes ago]

Sat, 3 May 2025 22:49:59 GMT

On 5/3/25 17:14, Cousin Ricky wrote:
> The second test is inside neither the wall nor the stem of the glass;
> the inside() function has given the wrong result!
> 
> My apologies for the procedural definition of the lathe object, but when
> I print the values and use those to define the lathe, I cannot reproduce
> the bug.

I think you are likely hitting a numerical limitation. The lathe and sor 
objects are problematic where the equations to be solved end up with 
x,y,z aspects which are axis aligned. More specifically, where the 
equations to be solved see little or no change in x, y or z over the 
evaluated range. In such cases, the equation's curve never crosses 
through zero in a reliable way and it becomes difficult (or impossible) 
to find roots. Or sometimes, one finds too many roots due numerical noise.

Have you tried adding a very small rotation in say z? Maybe try 
something like: 'rotate z*1e-5'

Another test which could be interesting would be to use your lathe in an 
object pattern where you leave your lathe as is, but sweep a y plane 
through a range just about the problem coordinate. Using this, with an 
orthograpic camera(*) looking directly up or down at the y plane, we can 
probably get an idea how large the 'numerical void' is about your 
problem coordinate. Could be a disc, maybe a tiny dot. I don't remember 
how the inside test for the lathe is getting done.

Bill P.

(*) The orthographic camera itself exposes many of these kinds of... 
no-dimensional delta/change, numerical issues.

[Cousin Ricky] inside() is unreliable on lathe [339 days 10 hours and 8 minutes ago]

Sat, 3 May 2025 21:14:41 GMT

I'm still dealing with trace() failures on lathe.  I've tried various
workarounds, but the most promising entails an inside() tests.

The attached scene file does inside() tests on a wine glass defined as a
BÃ©zier lathe, with the following results:

Bounding box <-54.0, 0.0, -54.0> ... <54.0, 264.0, 54.0>
<0.0000, 265.0000, 0.0000> is outside.
<0.0000, 264.0000, 0.0000> is inside.
<0.0000, 263.0000, 0.0000> is outside.
<0.0000, 50.0000, 0.0000> is inside.
<60.0000, 264.0000, 0.0000> is outside.
<42.5000, 263.5000, 0.0000> is inside.

These tests are at, respectively:
  1. Along the central axis, above the height of the glass.
  2. Along the central axis, at exactly the height of the glass.
  3. Along the central axis, just below the height of the glass.
  4. Along the central axis, within the stem of the glass.
  5. At exactly the height of the glass, outside its bounding box.
  6. Within the rim of the glass.

The second test is inside neither the wall nor the stem of the glass;
the inside() function has given the wrong result!

My apologies for the procedural definition of the lathe object, but when
I print the values and use those to define the lathe, I cannot reproduce
the bug.

(I'm looking at having to tell my trace macro in advance whether or not
I'm starting the trace from within the object.  I don't like having to
tell a macro how to do its job.)

[Thorsten] Re: Animations. malloc(): unsorted double linked... [364 days 18 hours and 53 minutes ago]

Tue, 8 Apr 2025 12:30:09 GMT

On 07.04.2025 14:15, William F Pokorny wrote:
> (*) - I found that the messaging code doesn't use the pov_mem versions, 
> but rather raw C malloc(), realloc() and free().

Yes, it needs memory allocation outside the main code because it must be 
able to handle low and out of memory conditions.

On Linux it may also be that the C++ library calls malloc for handling 
new. There used to be overrides for new/delete somewhere that could use 
the POV-Ray internal memory allocation functions, but they may since 
have been removed. If so, you can always use Memcheck from Valgrind.

Thorsten

[William F Pokorny] Re: Animations. malloc(): unsorted double linked... [365 days 11 hours and 58 minutes ago]

Mon, 7 Apr 2025 19:25:12 GMT

On 4/7/25 08:15, William F Pokorny wrote:
> I'll try to get a MEM_GUARD build going today and run more of those.

Update.

A build with MEM_GUARD and MEM_TAG defined just finished a second long 
set of animation frames. No warnings or errors. I tried a handful of 
still frame scenes and they too ran clean.

I'll run a few more animation sequences overnight and then, unless 
something goes boom, I'll likely pause the chase. It's not failing often 
enough at present for me to give it a high priority.

Bill P.

[William F Pokorny] Re: Animations. malloc(): unsorted double linked... [365 days 19 hours and 7 minutes ago]

Mon, 7 Apr 2025 12:15:44 GMT

On 4/6/25 08:44, Thorsten wrote:
> If it is indeed a bug, you should be able to reproduce it if you enable 
> memory debugging by defining the various macros in pov_mem.cpp (in 
> particular MEM_GUARD) when compiling POV-Ray.
> 
> The other, and more likely, option - if this only occurs during long 
> renders - may very well be memory corruption due to overheating 
> problems. Nowadays this also tends to be a problem for memory due to 
> overall heat being generated.

Thank you for the information. I'd not considered overheating as a 
potential cause.

I spent some time earlier this morning looking at the C style memory 
handling I could find in the source code - as well as what in particular 
was using code from pov_mem.cpp.

Other than functions, which were common to both animations which 
crashed, I wasn't using much beyond the povms code(*). There are still 
too some allocations and frees to set up for possible blobs around the 
rendering of each frame, for example.

My dummy long animation renders have all finished clean. I'll try to get 
a MEM_GUARD build going today and run more of those.

Bill P.

(*) - I found that the messaging code doesn't use the pov_mem versions, 
but rather raw C malloc(), realloc() and free().

[Thorsten] Re: Animations. malloc(): unsorted double linked... [366 days 18 hours and 38 minutes ago]

Sun, 6 Apr 2025 12:44:23 GMT

Hi,

If it is indeed a bug, you should be able to reproduce it if you enable 
memory debugging by defining the various macros in pov_mem.cpp (in 
particular MEM_GUARD) when compiling POV-Ray.

The other, and more likely, option - if this only occurs during long 
renders - may very well be memory corruption due to overheating 
problems. Nowadays this also tends to be a problem for memory due to 
overall heat being generated.

Thorsten

On 06.04.2025 09:09, William F Pokorny wrote:
> Posting as a hook so others who might see this failure can find it and 
> provide information.
> 
> If you have seen this issues or have just hit it, please post here - 
> along with environment, running conditions, frequency, etc.
> 
> ---
> 
> In the last six months or so I've been using the animation facilities in 
> POV-Ray (yuqk) more than ever. Sometimes to create actual animations, 
> but more often as a way to explore feature options. Or, as with the 
> text{} object recently, to run down some crash already, infrequently, 
> seen in non-animation (single frame/image) renders.
> 
> Today, for the second time in the last month, I had a long running 
> animation core dump with a "malloc(): unsorted double linked list 
> corrupted" error(*). Both times the animation frames, rendering was 
> working in the background while I was doing other interactive work. Both 
> times the animation completed without issue once resumed.
> 
> I'm kicking off some intentionally long running (many frame) dummy 
> animations trying to trip this error while running my debug compile. I'm 
> hoping to capture an annotated core dump file. Maybe I'll get lucky, but 
> I doubt it. I guess something like valgrind an option - if I find myself 
> really motivated.
> 
> ---
> 
> Linux. x86-64. My yuqk, v3.8 based fork releases R19 and working state, 
> R20 code. Both times the scenes were small - with memory requirements 
> <100MB.
> 
> lsb_release -a :
>  Â Â Â  No LSB modules are available.
>  Â Â Â  Distributor ID: Ubuntu
>  Â Â Â 
Description:Â Â Â  Ubuntu 24.04.2 LTS
>  Â Â Â 
Release:Â Â Â Â Â Â Â 
24.04
>  Â Â Â 
Codename:Â Â Â Â Â Â 
noble
> g++ --version : g++ (Ubuntu 13.3.0-6ubuntu2~24.04) 13.3.0
> ldd --version : ldd (Ubuntu GLIBC 2.39-0ubuntu8.4) 2.39
> uname -rÂ Â Â Â Â  :
6.8.0-57-generic
> 
> Bill P.
> 
> (*) - The error message comes from glibc prior to things crashing.

[William F Pokorny] Animations. malloc(): unsorted double linked lis... [367 days and 13 minutes ago]

Sun, 6 Apr 2025 07:09:38 GMT

Posting as a hook so others who might see this failure can find it and 
provide information.

If you have seen this issues or have just hit it, please post here - 
along with environment, running conditions, frequency, etc.

---

In the last six months or so I've been using the animation facilities in 
POV-Ray (yuqk) more than ever. Sometimes to create actual animations, 
but more often as a way to explore feature options. Or, as with the 
text{} object recently, to run down some crash already, infrequently, 
seen in non-animation (single frame/image) renders.

Today, for the second time in the last month, I had a long running 
animation core dump with a "malloc(): unsorted double linked list 
corrupted" error(*). Both times the animation frames, rendering was 
working in the background while I was doing other interactive work. Both 
times the animation completed without issue once resumed.

I'm kicking off some intentionally long running (many frame) dummy 
animations trying to trip this error while running my debug compile. I'm 
hoping to capture an annotated core dump file. Maybe I'll get lucky, but 
I doubt it. I guess something like valgrind an option - if I find myself 
really motivated.

---

Linux. x86-64. My yuqk, v3.8 based fork releases R19 and working state, 
R20 code. Both times the scenes were small - with memory requirements 
<100MB.

lsb_release -a :
     No LSB modules are available.
     Distributor ID: Ubuntu
     Description:    Ubuntu 24.04.2 LTS
     Release:        24.04
     Codename:       noble
g++ --version : g++ (Ubuntu 13.3.0-6ubuntu2~24.04) 13.3.0
ldd --version : ldd (Ubuntu GLIBC 2.39-0ubuntu8.4) 2.39
uname -r      : 6.8.0-57-generic

Bill P.

(*) - The error message comes from glibc prior to things crashing.

[Bald Eagle] Possible error(s) in color_map handling [369 days 17 hours and 28 minutes ago]

Thu, 3 Apr 2025 13:55:00 GMT

Sorry for no code - it was late, and I got sidetracked by finishing up code.

So, I was playing with some of the interesting texturing found in:

https://www.sciencedirect.com/science/article/pii/S0898122114005252#f000030

and it looked to me like the slope pattern would be the way to go for some of
the figures.

I made a torus, defined a pigment with slope {x}, and then made a simple color
map with 3 entries.  0.0 color1, 0.5 color2, 1.0 rgbt 1 (clear)

Oddly enough, the right side of the torus had the same pigmentation as the left,
on both inner and outer surfaces.

This seemed to be an "unexpected result".

I started to debug this by making a "capsule" - a cylinder along the x-axis
capped by 2 spheres.  But that looked fine, with the expected coloration, and no
 -x color at the +x side.  So maybe it's specific to the torus (and perhaps
other shapes?)

I was also making some tori with the layered striped patterns, and rather than a
fade wrapping around the 1.00 - 0.00 transition, I got a hard boundary.  Which
seemed weird.

So, I initially started with color at 0.0, repeating that color at 0.5, and then
rgbt 1 at 1.0

Then I started to implement the fading effect, and figured that just moving the
color entry from 0.0 to 0.1 would allow the rgbt 1 entry at 1.00 to "wrap around
to 1.00.   This did not happen.  I had to add an additional rgbt 1 at 0.0 in
order to achieve the desired effect.

This was an unexpected result - is it a bug?

- BW

[kurtz le pirate] Re: unexpected evaluation of #if(...)? [395 days 14 hours and 36 minutes ago]

Sat, 8 Mar 2025 16:47:04 GMT

On 08/03/2025 12:34, ingo wrote:
> kurtz le pirate <kur### [at] freefr> wrote:
> 
>> So, splitting conditions seems to be the only solution with POV.
> 
> But not always straight forward,
> 
> #if (Z > 0 & VoxelGrid[X][Y][Z-1] > 0)
>    .....
> #else
>    .....
> #end
> 
> after splitting #else may not be reached, where it is in the original (VoxelGrid
> = 0).
> 
> #if (Z > 0)
>    #if (VoxelGrid[X][Y][Z-1] > 0)
>      ....
>    #end
> #else
>    ....
> #end
> 
> it needs some thought and the code is way more complex than this. (#switch #case
> can be an alternative after turning the conditions into "states")

Of corse.


It also depends on what you want to do in the "else" case.
You can also do something like this :

   #if ( VoxelGrid[X][Y][(Z>0?Z-1:OTHER)] > 0 )

More tricky



-- 
kurtz le pirate
compagnie de la banquise

[William F Pokorny] Bug introduced in the text{} code during v3.8 co... [395 days 14 hours and 54 minutes ago]

Sat, 8 Mar 2025 16:29:18 GMT

For the record.

I finally found and fixed a bug introduced in the text{} object code 
during v3.8 code development. It was occasionally(*) causing segment 
faults / invalid memory accesses.

The code was part of the code backed out late for the v3.8 beta releases 
- so our two v3.8 beta releases are OK. Official v3.8 releases prior to 
those two are likely exposed to the bug.

The bug still exists in POV-Ray's master 4.0 branch code.

The v3.8 yuqk fork will be fixed in the upcoming R19 release.

In truetype.cpp and the function ProcessCharMap(), change the line:

     for(j = 0; j <= ffile->info->cmapSelector.size(); ++j)
to
     for(j = 0; j <  ffile->info->cmapSelector.size(); ++j)

Bill P.

(*) - Only crashing for me on the order of 1/1000 text{} object 
creations with a few fonts; while much less - or apparently not at all 
with other fonts.

[ingo] Re: unexpected evaluation of #if(...)? [395 days 17 hours and 28 minutes ago]

Sat, 8 Mar 2025 13:55:00 GMT

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

> Maybe fall back onto using some small helper macros [...] Or, potentially what
> you could do is multiply the pseudo-Boolean values [...]

We share a line of thought,

ingo

[Bald Eagle] Re: unexpected evaluation of #if(...)? [395 days 18 hours and 3 minutes ago]

Sat, 8 Mar 2025 13:20:00 GMT

"ingo" <nomail@nomail> wrote:

> But not always straight forward,

> it needs some thought and the code is way more complex than this. (#switch #case
> can be an alternative after turning the conditions into "states")

Maybe fall back onto using some small helper macros just to keep the statements
short and the logic straight.

Or, potentially what you could do is multiply the pseudo-Boolean values instead
of using the "&" operator.

0*0 = 0
0*1=1
1*0=0

- BW

[ingo] Re: unexpected evaluation of #if(...)? [395 days 19 hours and 48 minutes ago]

Sat, 8 Mar 2025 11:35:00 GMT

kurtz le pirate <kur### [at] freefr> wrote:

> So, splitting conditions seems to be the only solution with POV.

But not always straight forward,

#if (Z > 0 & VoxelGrid[X][Y][Z-1] > 0)
  .....
#else
  .....
#end

after splitting #else may not be reached, where it is in the original (VoxelGrid
= 0).

#if (Z > 0)
  #if (VoxelGrid[X][Y][Z-1] > 0)
    ....
  #end
#else
  ....
#end

it needs some thought and the code is way more complex than this. (#switch #case
can be an alternative after turning the conditions into "states")


ingo

[kurtz le pirate] Re: unexpected evaluation of #if(...)? [395 days 21 hours and 45 minutes ago]

Sat, 8 Mar 2025 09:37:23 GMT

On 08/03/2025 07:28, ingo wrote:
> "Tor Olav Kristensen" <tor### [at] TOBEREMOVEDgmailcom> wrote:
>>
>> https://en.wikipedia.org/wiki/Short-circuit_evaluation
> 
> Ah, that clarifies.

Above all, it shows that it's VERY language-dependent.




> It will needs some rethinking, nested #if it will be,

So, splitting conditions seems to be the only solution with POV.




-- 
kurtz le pirate
compagnie de la banquise

[ingo] Re: unexpected evaluation of #if(...)? [396 days and 53 minutes ago]

Sat, 8 Mar 2025 06:30:00 GMT

"Tor Olav Kristensen" <tor### [at] TOBEREMOVEDgmailcom> wrote:
>
> https://en.wikipedia.org/wiki/Short-circuit_evaluation

Ah, that clarifies.

It will needs some rethinking, nested #if it will be,

thanks,

ingo

[Tor Olav Kristensen] Re: unexpected evaluation of #if(...)? [396 days 6 hours and 33 minutes ago]

Sat, 8 Mar 2025 00:50:00 GMT

"ingo" <nomail@nomail> wrote:
> The following line results in an negative subscript error when Z = 0:
>
> #if (Z > 0 & VoxelGrid[X][Y][Z-1] > 0)
>
> I expected the evaluation to terminate, with false, at Z > 0.
>
> Won't say it is a bug, it is just unexpected.

Hi Ingo

There's some relevant information here:

https://en.wikipedia.org/wiki/Short-circuit_evaluation

In order to program in a more robust and portable way, one should avoid such
constructs that may differ between languages.

I suggest that you split this up into nested #if statements.

--
Tor Olav
http://subcube.com
https://github.com/t-o-k

[Leroy] Re: unexpected evaluation of #if(...)? [396 days 8 hours and 13 minutes ago]

Fri, 7 Mar 2025 23:10:00 GMT

"ingo" <nomail@nomail> wrote:
> The following line results in an negative subscript error when Z = 0:
>
> #if (Z > 0 & VoxelGrid[X][Y][Z-1] > 0)
>
> I expected the evaluation to terminate, with false, at Z > 0.
>
> Won't say it is a bug, it is just unexpected.
>
> ingo

I ran into this before. The way I got around it is...

#if(Z>0) #if(array[X][Y][Z-1]>0) do_something.. #end #end

I think it is the negative element of the array is accessed during evaluation
that causes the error.
#ifndef with an array with a negative element or a positive element out of range
will cause an error too. Even throuh clearly element [-1] doesn't exist.

Have Fun!

[ingo] unexpected evaluation of #if(...)? [396 days 15 hours and 28 minutes ago]

Fri, 7 Mar 2025 15:55:00 GMT

The following line results in an negative subscript error when Z = 0:

#if (Z > 0 & VoxelGrid[X][Y][Z-1] > 0)

I expected the evaluation to terminate, with false, at Z > 0.

Won't say it is a bug, it is just unexpected.

ingo

[And] Re: mesh camera ouput uv-mapping has a seam when... [414 days 22 hours and 3 minutes ago]

Mon, 17 Feb 2025 09:20:00 GMT

MichaelJF <fri### [at] t-onlinede> wrote:
> Am 16.02.2025 um 10:14 schrieb And:
> > MichaelJF <fri### [at] t-onlinede> wrote:
> >>
> >> Jaime Vives Piqueres has written a work-around several years ago.
> >> Fortunately, he has restored this part of his website:
> >>
> >> http://ignorancia.org/index.php?page=mesh-camera
> >>
> >> Best regards
> >> Michael
> >
> > Well, he(or she @@) has already pointed out the problem.
> >
> I admit, his (Jaime is a Spanish variant of the name James) repair_seams
> approach of smearing the textures is lossy and cannot always be used.
> But it helps with his statuettes. I myself have only used it for such
> purposes. But, if Blender helps, why not use it?
>
> Best regards
> Michael

Thank you.
Well, I have used Blender, I just ask the same situation here.
(I don't actually use 3D for any official purpose.)

[MichaelJF] Re: mesh camera ouput uv-mapping has a seam when... [415 days 11 hours and 28 minutes ago]

Sun, 16 Feb 2025 19:54:34 GMT

Am 16.02.2025 um 10:14 schrieb And:
> MichaelJF <fri### [at] t-onlinede> wrote:
>> Am 14.02.2025 um 11:32 schrieb And:
>>> "And" <49341109@ntnu.edu.tw> wrote:
>>>> Maybe I have post this issue several years ago.
>>>> When I use mesh_camera to output a uv-map texture(for other 3D software), I
>>>> found that the rendered area is not enough, it should extend the render area.
>>>> Has these problem been solved?
>>>>
>>>> attachment is POV-Ray's output.
>>>
>>> When it applied to model:
>>
>> Jaime Vives Piqueres has written a work-around several years ago.
>> Fortunately, he has restored this part of his website:
>>
>> http://ignorancia.org/index.php?page=mesh-camera
>>
>> Best regards
>> Michael
> 
> Well, he(or she @@) has already pointed out the problem.
> 
I admit, his (Jaime is a Spanish variant of the name James) repair_seams 
approach of smearing the textures is lossy and cannot always be used. 
But it helps with his statuettes. I myself have only used it for such 
purposes. But, if Blender helps, why not use it?

Best regards
Michael

[Bald Eagle] Re: camera problem [415 days 14 hours and 43 minutes ago]

Sun, 16 Feb 2025 16:40:00 GMT

"jr" <cre### [at] gmailcom> wrote:
> hi,
>
> while preparing some stuff, I ran into a strange problem; same for alpha, betas,
> and yuqk.
>
> while the programs correctly report 100 objects rendered on every run, not all
> are visible, the camera angle appears to make a difference ?  demo attached,
> tia.
>
>
> regards, jr.

You're just running into the ole' "It's too small to see" issue.
If I even increase your sphere radius to 0.011, I see all the spheres.

The camera angle thing might make the "invisible" spheres straddle enough pixels
so that it gets rendered.

Maybe also try very aggressive aa settings, and see it makes them show up.

Otherwise, you're going to have to ensure that the sphere radius is always large
enough no matter the render "resolution" or the camera position.

I have code for that if needed.

- BW

[jr] camera problem [415 days 15 hours and 43 minutes ago]

Sun, 16 Feb 2025 15:40:00 GMT

hi,

while preparing some stuff, I ran into a strange problem; same for alpha, betas,
and yuqk.

while the programs correctly report 100 objects rendered on every run, not all
are visible, the camera angle appears to make a difference ?  demo attached,
tia.


regards, jr.

[And] Re: mesh camera ouput uv-mapping has a seam when... [415 days 22 hours and 8 minutes ago]

Sun, 16 Feb 2025 09:15:00 GMT

MichaelJF <fri### [at] t-onlinede> wrote:
> Am 14.02.2025 um 11:32 schrieb And:
> > "And" <49341109@ntnu.edu.tw> wrote:
> >> Maybe I have post this issue several years ago.
> >> When I use mesh_camera to output a uv-map texture(for other 3D software), I
> >> found that the rendered area is not enough, it should extend the render area.
> >> Has these problem been solved?
> >>
> >> attachment is POV-Ray's output.
> >
> > When it applied to model:
>
> Jaime Vives Piqueres has written a work-around several years ago.
> Fortunately, he has restored this part of his website:
>
> http://ignorancia.org/index.php?page=mesh-camera
>
> Best regards
> Michael

Well, he(or she @@) has already pointed out the problem.

[And] Re: mesh camera ouput uv-mapping has a seam when... [415 days 22 hours and 8 minutes ago]

Sun, 16 Feb 2025 09:15:00 GMT

"Bald Eagle" <cre### [at] netscapenet> wrote:
> "And" <49341109@ntnu.edu.tw> wrote:
> > Maybe I have post this issue several years ago.
> > When I use mesh_camera to output a uv-map texture(for other 3D software), I
> > found that the rendered area is not enough, it should extend the render area.
> > Has these problem been solved?
> >
> > attachment is POV-Ray's output.
>
> We're going to need WAY more information to figure that one out.
>
> What model are you using?
> What is the POV-Ray scene and mesh camera setup you're using to generate your uv
> map?
> What uv vectors are being used to wrap the generated image for uv-mapping?
>
> 1. That's a pretty complex work flow, where SO many things can go wrong, if only
> because of floting point precision, etc.
>
> 2. I'm sure people here would love to learn how to use this method for their own
> work - thus ensuring that all of the tools needed to make this work get the
> attention and fixing that they need!
>
> - BW

Every model it has this issue.

mesh_camera {
    ...

    distribution_type 3
    ...
}


Because its color only covers the area of the model.


I show you a uv-mapping texture generated by Blender 3D:
Its color covers not only the area of the model, it generate a margin area, too.
It can control margin size (for this example I set 16 px), type("extend" or
using "adjacent faces")

[MichaelJF] Re: mesh camera ouput uv-mapping has a seam when... [417 days 16 hours and 16 minutes ago]

Fri, 14 Feb 2025 15:06:25 GMT

Am 14.02.2025 um 11:32 schrieb And:
> "And" <49341109@ntnu.edu.tw> wrote:
>> Maybe I have post this issue several years ago.
>> When I use mesh_camera to output a uv-map texture(for other 3D software), I
>> found that the rendered area is not enough, it should extend the render area.
>> Has these problem been solved?
>>
>> attachment is POV-Ray's output.
> 
> When it applied to model:

Jaime Vives Piqueres has written a work-around several years ago. 
Fortunately, he has restored this part of his website:

http://ignorancia.org/index.php?page=mesh-camera

Best regards
Michael

[Bald Eagle] Re: mesh camera ouput uv-mapping has a seam when... [417 days 17 hours and 18 minutes ago]

Fri, 14 Feb 2025 14:05:00 GMT

"And" <49341109@ntnu.edu.tw> wrote:
> Maybe I have post this issue several years ago.
> When I use mesh_camera to output a uv-map texture(for other 3D software), I
> found that the rendered area is not enough, it should extend the render area.
> Has these problem been solved?
>
> attachment is POV-Ray's output.

We're going to need WAY more information to figure that one out.

What model are you using?
What is the POV-Ray scene and mesh camera setup you're using to generate your uv
map?
What uv vectors are being used to wrap the generated image for uv-mapping?

1. That's a pretty complex work flow, where SO many things can go wrong, if only
because of floting point precision, etc.

2. I'm sure people here would love to learn how to use this method for their own
work - thus ensuring that all of the tools needed to make this work get the
attention and fixing that they need!

- BW

[And] Re: mesh camera ouput uv-mapping has a seam when... [417 days 20 hours and 48 minutes ago]

Fri, 14 Feb 2025 10:35:00 GMT

"And" <49341109@ntnu.edu.tw> wrote:
> Maybe I have post this issue several years ago.
> When I use mesh_camera to output a uv-map texture(for other 3D software), I
> found that the rendered area is not enough, it should extend the render area.
> Has these problem been solved?
>
> attachment is POV-Ray's output.

When it applied to model:

[And] mesh camera ouput uv-mapping has a seam when I u... [417 days 22 hours and 3 minutes ago]

Fri, 14 Feb 2025 09:20:00 GMT

Maybe I have post this issue several years ago.
When I use mesh_camera to output a uv-map texture(for other 3D software), I
found that the rendered area is not enough, it should extend the render area.
Has these problem been solved?

attachment is POV-Ray's output.

[Tor Olav Kristensen] Re: Bad values crash POV-Ray [534 days 10 hours and 53 minutes ago]

Sun, 20 Oct 2024 20:30:00 GMT

"Tor Olav Kristensen" <tor### [at] TOBEREMOVEDgmailcom> wrote:
> "Bald Eagle" <cre### [at] netscapenet> wrote:
> > So here's how I got it to NOT crash, but my mapping results suck.
> >
> > Remove all of the protective select () and mod () functions, and it will crash.
> >
>
> Here's what you can do to make it work:
>...

Sorry, I made a little mistake in the code below:

>...
> #declare s2d =
>     function(X, Y) {
>         select(
>             X*X + Y*Y,
>             select(
>                 1 - X*X*Y*Y,
>                 sqrt(
>                     (X*X + Y*Y - 2*X*X*Y*Y)/
>                      ((X*X + Y*Y)*(1 - X*X*Y*Y))
>                 )*X,
>                 sqrt(0.5)*X,
>                 sqrt(
>                     (X*X + Y*Y - 2*X*X*Y*Y)/
>                      ((X*X + Y*Y)*(1 - X*X*Y*Y))
>                 )*X
>             )*X,

Remove the last *X above


>             0,
>             select(
>                 1 - X*X*Y*Y,
>                 sqrt(
>                     (X*X + Y*Y - 2*X*X*Y*Y)/
>                      ((X*X + Y*Y)*(1 - X*X*Y*Y))
>                 )*X,
>                 sqrt(0.5)*X,
>                 sqrt(
>                     (X*X + Y*Y - 2*X*X*Y*Y)/
>                      ((X*X + Y*Y)*(1 - X*X*Y*Y))
>                 )*X
>             )
>         )
>     }
> ;
>...

--
Tor Olav
http://subcube.com
https://github.com/t-o-k

[Tor Olav Kristensen] Re: Bad values crash POV-Ray [534 days 11 hours and 33 minutes ago]

Sun, 20 Oct 2024 19:50:00 GMT

"Bald Eagle" <cre### [at] netscapenet> wrote:
> So here's how I got it to NOT crash, but my mapping results suck.
>
> Remove all of the protective select () and mod () functions, and it will crash.
>

Here's what you can do to make it work:

(Note that I might change my mind later about what values should
be used when the first expressions in the select statements
evaluates to zero. I may do some more testing in Python to be sure.)


> #version 3.8;

Replace with:

#version 3.7;  // I have not tested with v3.8


> #declare Zoom = 300;

Replace with:

#declare Zoom = 100;  // To see all the results


> #declare Image = pigment {image_map {"HyperbolicSoccerBall.jpg"} translate-0.5}

Replace with:

#declare Image =
    pigment {
        image_map { "HyperbolicSoccerBall.jpg" }
        scale <2, 2, 1>
        translate -<1, 1, 0>
    }
/*
To move the image from the region from x = 0 and y = 0 to
x = +1 and y = +1 into the region from x = -1 and y = -1 to
x = +1 and y = +1, as these are the intervals that the functions
below are made for.
*/


> #declare d2s = function (M, N, U, V) {
>  select (M,
>   select (2*(U*U + V*V - 2),
>    sgn (M) * sqrt (abs (-U*U -V*V + sqrt ((U*U + V*V)+(U*U + V*V + 4*U*U*V*V
> *(U*U+V*V-2)) )  / (2*(U*U + V*V - 2))) ) / M,
>    M,
>    sgn (M) * sqrt (abs (-U*U -V*V + sqrt ((U*U + V*V)+(U*U + V*V + 4*U*U*V*V
> *(U*U+V*V-2)) )  / (2*(U*U + V*V - 2))) ) / M
>   ),
>   M,
>   select (2*(U*U + V*V - 2),
>    sgn (M) * sqrt (abs (-U*U -V*V + sqrt ((U*U + V*V)+(U*U + V*V + 4*U*U*V*V
> *(U*U+V*V-2)) )  / (2*(U*U + V*V - 2))) ) / M,
>    M,
>    sgn (M) * sqrt (abs (-U*U -V*V + sqrt ((U*U + V*V)+(U*U + V*V + 4*U*U*V*V
> *(U*U+V*V-2)) )  / (2*(U*U + V*V - 2))) ) / M
>   )
>  )
> }

Replace with:

#declare d2s =
    function(U, V) {
        select(
            V,
            select(
                U*U + V*V - 2,
                sgn(U*V)*
                sqrt(
                    (
                        -U*U -V*V +
                        sqrt(
                            (U*U + V*V)*
                            (U*U + V*V + 4*U*U*V*V*(U*U + V*V - 2))
                        )
                    )/(2*(U*U + V*V - 2))
                )/V,
                U,
                sgn(U*V)*
                sqrt(
                    (
                        -U*U -V*V +
                        sqrt(
                            (U*U + V*V)*
                            (U*U + V*V + 4*U*U*V*V*(U*U + V*V - 2))
                        )
                    )/(2*(U*U + V*V - 2))
                )/V
            ),
            U,
            select(
                U*U + V*V - 2,
                sgn(U*V)*
                sqrt(
                    (
                        -U*U -V*V +
                        sqrt(
                            (U*U + V*V)*
                            (U*U + V*V + 4*U*U*V*V*(U*U + V*V - 2))
                        )
                    )/(2*(U*U + V*V - 2))
                )/V,
                U,
                sgn(U*V)*
                sqrt(
                    (
                        -U*U -V*V +
                        sqrt(
                            (U*U + V*V)*
                            (U*U + V*V + 4*U*U*V*V*(U*U + V*V - 2))
                        )
                    )/(2*(U*U + V*V - 2))
                )/V
            )
        )
    }
;
/*
Note that the plus symbols between the parentheses in the inner square roots
in your expressions are wrong; they should be multiplication symbols.
Also abs() should not be needed.
*/


> #declare s2d = function (M, N, X, Y) {
>  select (mod (M+FF, 1),
>   sqrt ((X*X + Y*Y - 2*X*X*Y*Y)/((X*X + Y*Y)*(1 - X*X*Y*Y))),
>   M,
>   sqrt ((X*X + Y*Y - 2*X*X*Y*Y)/((X*X + Y*Y)*(1 - X*X*Y*Y)))
>  )
> }

Replace with:

#declare s2d =
    function(X, Y) {
        select(
            X*X + Y*Y,
            select(
                1 - X*X*Y*Y,
                sqrt(
                    (X*X + Y*Y - 2*X*X*Y*Y)/
                     ((X*X + Y*Y)*(1 - X*X*Y*Y))
                )*X,
                sqrt(0.5)*X,
                sqrt(
                    (X*X + Y*Y - 2*X*X*Y*Y)/
                     ((X*X + Y*Y)*(1 - X*X*Y*Y))
                )*X
            )*X,
            0,
            select(
                1 - X*X*Y*Y,
                sqrt(
                    (X*X + Y*Y - 2*X*X*Y*Y)/
                     ((X*X + Y*Y)*(1 - X*X*Y*Y))
                )*X,
                sqrt(0.5)*X,
                sqrt(
                    (X*X + Y*Y - 2*X*X*Y*Y)/
                     ((X*X + Y*Y)*(1 - X*X*Y*Y))
                )*X
            )
        )
    }
;


> box {0, 1 translate -0.5 pigment {Image} translate -x}

Replace with:

box {
    -<1, 1, 0>, +<1, 1, 1>
    pigment { Image }
    translate +1.0*y
}


> //box {0, 1 translate -0.5 pigment {function {f_Image (s2d (x, y, x, y), s2d (y,
> x, x, y), z).red}} translate x}

Replace with:

box {
    -<1, 1, 0>,
    +<1, 1, 1>
    pigment {
        function {
            f_Image(
                s2d(x, y),
                s2d(y, x),
                0
            ).gray
        }
    }
    translate -2.5*x -1.0*y
}


> union {
>  #for (Y, 0, 1, Step)
>   #for (X, 0, 1, Step)
>    #declare C = f_Image (X, Y, 0).red;
>    #declare X2 = d2s (X, Y, X, Y)*Step;
>    #declare Y2 = d2s (Y, X, X, Y)*Step;
>    box {<X2, Y2, 0>, <X2+Step, Y2+Step, 1> pigment {rgb C}}
>   #end
>  #end
> }

Replace with:

union {
    #for (Y, -1, +1, Step)
        #for (X, -1, +1, Step)
            #declare C = f_Image(X, Y, 0).gray;
            #declare X2 = d2s(X, Y);
            #declare Y2 = d2s(Y, X);
            box {
                <X2, Y2, 0>, <X2 + Step, Y2 + Step, 1>
                pigment { color rgb C*<1, 1, 1> }
            }
        #end // for
    #end // for
    translate +2.5*x -1.0*y
}

--
Tor Olav
http://subcube.com
https://github.com/t-o-k

[jr] Re: Bad values crash POV-Ray [536 days 15 hours and 58 minutes ago]

Fri, 18 Oct 2024 15:25:00 GMT

"Bald Eagle" <cre### [at] netscapenet> wrote:
> ... 0, N/0, and 0/0?

<https://www.quantamagazine.org/how-the-human-brain-contends-with-the-strangeness-of-zero-20241018/>

</grin>


regards, jr.

[Bald Eagle] Re: Bad values crash POV-Ray [538 days 10 hours and 18 minutes ago]

Wed, 16 Oct 2024 21:05:00 GMT

So here's how I got it to NOT crash, but my mapping results suck.

Remove all of the protective select () and mod () functions, and it will crash.


#version 3.8;
global_settings {assumed_gamma 1.0 }

#include "math.inc"

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

light_source {<10, 10, -20> rgb 1}

sky_sphere {pigment {rgb 1}}

#declare Image = pigment {image_map {"HyperbolicSoccerBall.jpg"} translate-0.5}
#declare f_Image = function {pigment {Image}}

#declare d2s = function (M, N, U, V) {
 select (M,
  select (2*(U*U + V*V - 2),
   sgn (M) * sqrt (abs (-U*U -V*V + sqrt ((U*U + V*V)+(U*U + V*V + 4*U*U*V*V
*(U*U+V*V-2)) )  / (2*(U*U + V*V - 2))) ) / M,
   M,
   sgn (M) * sqrt (abs (-U*U -V*V + sqrt ((U*U + V*V)+(U*U + V*V + 4*U*U*V*V
*(U*U+V*V-2)) )  / (2*(U*U + V*V - 2))) ) / M
  ),
  M,
  select (2*(U*U + V*V - 2),
   sgn (M) * sqrt (abs (-U*U -V*V + sqrt ((U*U + V*V)+(U*U + V*V + 4*U*U*V*V
*(U*U+V*V-2)) )  / (2*(U*U + V*V - 2))) ) / M,
   M,
   sgn (M) * sqrt (abs (-U*U -V*V + sqrt ((U*U + V*V)+(U*U + V*V + 4*U*U*V*V
*(U*U+V*V-2)) )  / (2*(U*U + V*V - 2))) ) / M
  )
 )
}

#local FF = 0.0000001;

#declare s2d = function (M, N, X, Y) {
 select (mod (M+FF, 1),
  sqrt ((X*X + Y*Y - 2*X*X*Y*Y)/((X*X + Y*Y)*(1 - X*X*Y*Y))),
  M,
  sqrt ((X*X + Y*Y - 2*X*X*Y*Y)/((X*X + Y*Y)*(1 - X*X*Y*Y)))
 )
}

box {0, 1 translate -0.5 pigment {Image} translate -x}

//box {0, 1 translate -0.5 pigment {function {f_Image (d2s (x, y, x, y), d2s (y,
x, x, y), z).red}} }
//box {0, 1 translate -0.5 pigment {function {f_Image (s2d (x, y, x, y), s2d (y,
x, x, y), z).red}} translate x}

#declare Step = 0.01;
union {
 #for (Y, 0, 1, Step)
  #for (X, 0, 1, Step)
   #declare C = f_Image (X, Y, 0).red;
   #declare X2 = d2s (X, Y, X, Y)*Step;
   #declare Y2 = d2s (Y, X, X, Y)*Step;
   box {<X2, Y2, 0>, <X2+Step, Y2+Step, 1> pigment {rgb C}}
  #end
 #end
}

#local FF = 0.0000001;
#for (N, 0, 1, 0.1)
 #debug concat ("mod (", str(N, 0, 1),  ", 1) = ", str(mod (N+FF, 1), 0, 3),
"\n")
#end

[kurtz le pirate] Re: Bad values crash POV-Ray [539 days 16 hours and 13 minutes ago]

Tue, 15 Oct 2024 15:10:01 GMT

On 15/10/2024 16:10, Bald Eagle wrote:

> In the meantime:
> Can you try a simple "scene" where you try to take the sqrt of 0, N/0, and 0/0?

Sure :

#debug "Begin -------------\n"

#declare a = sqrt(0);
#debug concat("sqrt(0) = ",str(a,0,-1),"\n")

#declare b = sqrt(1/0);
#debug concat("sqrt(1/0) = ",str(b,0,-1),"\n")

#declare c = sqrt(0/0);
#debug concat("sqrt(0/0) = ",str(c,0,-1),"\n")

#debug "End-----------------\n"

#error "nothing to draw"



Output :
Begin -------------
sqrt(0) = 0.000000
sqrt(1/0) = inf
sqrt(0/0) = inf
End-----------------

Parse Warning: Divide by zero.
Parse Warning: Divide by zero.






-- 
Kurtz le pirate
Compagnie de la banquise

[Bald Eagle] Re: Bad values crash POV-Ray [539 days 17 hours and 8 minutes ago]

Tue, 15 Oct 2024 14:15:00 GMT

kurtz le pirate <kur### [at] gmailcom> wrote:

> I quickly did these two scenes.
> I used the silly method that gives the images as attachments.
> I don't know why you have crashes.
>
> Here is some of my code :
 ....
> Values between -1 and 1 go through zero, but I don't have any crashes.
> I don't know if this will help you..

Hey - you got it to work, which is more than I got.
When I next get a chance (it may be a while), I can compare your code to mine.

In the meantime:
Can you try a simple "scene" where you try to take the sqrt of 0, N/0, and 0/0?

Thanks

- BW

[kurtz le pirate] Re: Bad values crash POV-Ray [539 days 17 hours and 25 minutes ago]

Tue, 15 Oct 2024 13:57:49 GMT

On 14/10/2024 18:16, Bald Eagle wrote:
> I was experimenting with the mapping equations in:
> 
> https://archive.bridgesmathart.org/2018/bridges2018-59.pdf

Really interesting article...


> and crashed POV-Ray (3.8) about 6 times.
> 
> I'm guessing it has to do with trying to take square roots of something divided
> by 0, or 0/0.
> I haven't had a chance to scribble out a minimal .pov script to see what
> triggers it.
> 
> 
> 
> I also was not able to get the mapping to work correctly - I'm guessing that I'm
> going to have to apply the _inverse_ of the mapping - but I'm out of practice,
> and can't see an easy way to go about that.
> 
> Any suggestions?


I quickly did these two scenes.
I used the silly method that gives the images as attachments.
I don't know why you have crashes.

Here is some of my code :
-- begin code ---
#declare Sq = function(x) { x*x }

#declare fnDisc2Square = function(u,v) {
 
sgn(u*v)*sqrt(((-Sq(u)-Sq(v)+sqrt((Sq(u)+Sq(v))*(Sq(u)+Sq(v)+4*Sq(u)*Sq(v)*(Sq(u)+Sq(v)-2)))))/(2*(Sq(u)+Sq(v)-2)))
  }

#declare fnSquare2Disc = function(x,y) {
  sqrt((Sq(x)+Sq(y)-(2*Sq(x)*Sq(y)))/((Sq(x)+Sq(y))*(1-Sq(x)*Sq(y))))
  }

#macro Disc2Square(U,V)
  <fnDisc2Square(U,V)/V, fnDisc2Square(U,V)/U, -0.10>
#end

#macro Square2Disc(X,Y)
  <fnSquare2Disc(X,Y)*X, fnSquare2Disc(X,Y)*Y, -0.10>
#end
--- end code ---


Values between -1 and 1 go through zero, but I don't have any crashes.
I don't know if this will help you..


-- 
Kurtz le pirate
Compagnie de la banquise

[Bald Eagle] Bad values crash POV-Ray [540 days 15 hours and 3 minutes ago]

Mon, 14 Oct 2024 16:20:00 GMT

I was experimenting with the mapping equations in:

https://archive.bridgesmathart.org/2018/bridges2018-59.pdf

and crashed POV-Ray (3.8) about 6 times.

I'm guessing it has to do with trying to take square roots of something divided
by 0, or 0/0.
I haven't had a chance to scribble out a minimal .pov script to see what
triggers it.



I also was not able to get the mapping to work correctly - I'm guessing that I'm
going to have to apply the _inverse_ of the mapping - but I'm out of practice,
and can't see an easy way to go about that.

Any suggestions?

- BW

[Cousin Ricky] Re: Examples directory and file names mismatches [612 days 16 hours and 3 minutes ago]

Sat, 3 Aug 2024 15:20:00 GMT

"Tadonic the Flautulant" <1p1### [at] relayfirefoxcom> wrote:
>
> 1. "reflection.ini" in the subdirectory "reflection" attempts to use
> "reflect.pov" as the Input_File_Name, when, in fact, the file name is
> "reflection.pov".

This one is fixed in POV-Ray 3.8, which is currently in beta testing.  There is
no anticipated release date, though.

[Tadonic the Flautulant] Examples directory and file names mismatches [612 days 16 hours and 58 minutes ago]

Sat, 3 Aug 2024 14:25:00 GMT

This may be the wrong place to address a relatively minor and perhaps, obsolete,
issue:

I'm using "POV-Ray 3.7.0.10.unofficial" from the Debian packages that come with
Pop! OS 22.04  (povray 1:3.7.0.10-1 and povray-examples 1:3.7.0.10-1).

I wrote a quick Bash script to generate MP4 animations from the examples in the
animation subdirectories and hit two snags:

1. "reflection.ini" in the subdirectory "reflection" attempts to use
"reflect.pov" as the Input_File_Name, when, in fact, the file name is
"reflection.pov".

2. The directory "quilted" has "plotqlt.pov" and "plotqlt.ini". All of the other
directory names match the root of the filenames within them. In other words, for
consistency I would expect the directory name to be "plotqlt" OR the file names
to be "quilted.pov" and "quilted.ini".

Easy enough to fix, but I thought someone might want to be aware of the
problems.

[kurtz le pirate] Re: makemesh problem [645 days 13 hours and 46 minutes ago]

Mon, 1 Jul 2024 17:37:15 GMT

On 01/07/2024 16:49, ingo wrote:
> kurtz le pirate <kur### [at] gmailcom> wrote:
> 
> 
> Bonjour Kurtz
> 
> What version, are you using? The one on my site seems to run fine and searching
> for ' NumVertices,"\n ' yields no result. The same for the files in the POV-Ray
> distributions. Could you test with the include file from :
> 
> https://ingoogni.nl/download/MMM.zip
> 

Bonjour Ingo,

The version i use :

// Persistence of Vision Ray Tracer Include File
// File: makemesh.inc
// Vers: 3.5
// Desc: Macros and functions used in builing mesh2 objects.
// Date: 2002/04/27
// Auth: Ingo Janssen

The test with makemesh in "MMM.zip"

// Persistence of Vision Ray Tracer Include File
// File: makemesh.inc
// Vers: 3.5
// Desc: Macros and functions used in builing mesh2 objects.
// Date: 2002/04/27
// Auth: Ingo Janssen

// Rev 2002/10/23 : Added the CheckFileName macro.
//                  Added the option to write Wavefront *.obj files.
//                  Added the option to write *.pcm files, for Chris
Colefax' Compressed Mesh Macros.
//                  Added the option to write *.arr files, this writes
only the arrays to a file.
// Rev 2004/26/5 :  Changed the order the vertices are written in to
counter clockwise

And your site say : "Last update: 2019-01-04" for makemesh.

... I use the original version of April 27, **2002**
I'm "really" not up to date !

Thanks for your answer, all is ok.

-- 
Kurtz le pirate
Compagnie de la Banquise

[ingo] Re: makemesh problem [645 days 16 hours and 33 minutes ago]

Mon, 1 Jul 2024 14:50:00 GMT

kurtz le pirate <kur### [at] gmailcom> wrote:

Bonjour Kurtz

What version, are you using? The one on my site seems to run fine and searching
for ' NumVertices,"\n ' yields no result. The same for the files in the POV-Ray
distributions. Could you test with the include file from :

https://ingoogni.nl/download/MMM.zip

ingo

>
> "makemesh.inc" by Ingo Janssen in 2002 is a superb and very useful macro.

[ingo] Re: makemesh problem [645 days 18 hours and 23 minutes ago]

Mon, 1 Jul 2024 13:00:00 GMT

kurtz le pirate <kur### [at] gmailcom> wrote:


Thanks, I'll have a look and report back when fixed with proper link etc.

ingo

>
> The official distribution of this macro should be corrected, but I don't
> know where it is.
> Ingo Janssen doesn't seem to have a site anymore.
>

[Bald Eagle] Re: makemesh problem [645 days 20 hours and 18 minutes ago]

Mon, 1 Jul 2024 11:05:00 GMT

kurtz le pirate <kur### [at] gmailcom> wrote:

> Just change :
>  "    ", NumVertices,"\n    "
> By :
>  "    ", str(NumVertices,0,0),"\n    "
>
> And it works like a charm!


Nice catch, and excellent debugging!


> The official distribution of this macro should be corrected, but I don't
> know where it is.
> Ingo Janssen doesn't seem to have a site anymore.

https://ingoogni.nl/

- BW

[kurtz le pirate] makemesh problem [645 days 21 hours and 10 minutes ago]

Mon, 1 Jul 2024 10:12:42 GMT

Hi,


"makemesh.inc" by Ingo Janssen in 2002 is a superb and very useful macro.


But I found a small issue. For "small" resolutions, it's okay.
At higher resolutions, however, the bug appears.


Let's say the resolution is 1000.
So we have Iter_U = 1000 and Iter_V = 1000

When using the generated file created by "makemesh.inc"
i get this error :

"10_sphere_mesh.txt"
line 200404
Parse Error: No matching }, < found instead




By studying what the file (122Mo) contains i can see :

#declare Surface = mesh2 {
  vertex_vectors {
    1.002e+06
	...
  normal_vectors {
    1.002e+06
	...
  uv_vectors {
    1.002e+06
	...
  face_indices {
    2e+06
	...

As you can see, the number of elements in each section is in scientific
notation.

But, 1.002e+06 is interpreted as 1 002 000 while the real number is 1
002 001.

Of course the POVRay finds vector's elements before the end of section.


The lines in question look like this :
#write(
	FILE_HANDLE,
	"  vertex_vectors {\n",
	"    ", NumVertices,"\n    "
	)

Just change :
	"    ", NumVertices,"\n    "
By :
	"    ", str(NumVertices,0,0),"\n    "

And it works like a charm!


The official distribution of this macro should be corrected, but I don't
know where it is.
Ingo Janssen doesn't seem to have a site anymore.



Hope that help ;)

-- 
Kurtz le pirate
Compagnie de la Banquise

[Bald Eagle] Re: 3.8 macro parsing errors [649 days 15 hours and 8 minutes ago]

Thu, 27 Jun 2024 16:15:00 GMT

William F Pokorny <ano### [at] anonymousorg> wrote:
> On 6/26/24 19:29, Bald Eagle wrote:
> > Any way to force str to prepend the + sign to +inf?
>
> Not presently. :-)
>
> I'm sure it's possible to modify the internal str() code to do it, but...
>
> Bill P.

Macro it is.

(I guess we don't have anything like numeric formatting (#.###.###) . . . yet.)


- BW

[William F Pokorny] Re: 3.8 macro parsing errors [649 days 15 hours and 44 minutes ago]

Thu, 27 Jun 2024 15:38:39 GMT

On 6/26/24 19:29, Bald Eagle wrote:
> Any way to force str to prepend the + sign to +inf?

Not presently. :-)

I'm sure it's possible to modify the internal str() code to do it, but...

Bill P.

[Bald Eagle] Re: 3.8 macro parsing errors [650 days 7 hours and 53 minutes ago]

Wed, 26 Jun 2024 23:30:00 GMT

Works pretty nice!  :)

Any way to force str to prepend the + sign to +inf?

val ("+inf")  =                 inf
val ("-inf")  =                -inf
val ("+nan")  =                 nan
val ("-nan")  =                -nan
val (1.0123")  = 1.01229999999999998
val (1.01 23") = 1.01000000000000001
val ("inf")   =                 inf
=============================================
Val1 = -1.00000000
Val2 = 1.00000000
Val1 < Val2

Val1 = -1.00000000
Val2 = 0.00000000
Val1 < Val2

Val1 = -1.00000000
Val2 = -1.00000000
Val1 = Val2

Val1 = 0.00000000
Val2 = 0.00000000
Val1 = Val2

Val1 = 1.00000000
Val2 = 1.00000000
Val1 = Val2

Val1 = -inf
Val2 = inf
Val1 < Val2

Val1 = inf
Val2 = inf
Val1 = Val2

Val1 = -inf
Val2 = inf
Val1 < Val2

Val1 = inf
Val2 = inf
Val1 = Val2

Val1 = nan
Val2 = inf
Val1 = Val2

[Bald Eagle] Re: 3.8 macro parsing errors [650 days 16 hours and 28 minutes ago]

Wed, 26 Jun 2024 14:55:00 GMT

I got sidetracked onto something else so I didn't try any of this out (yet).

What I did do is snare myself into the whole pass-by-reference trap when trying
to run a macro in a loop.

https://news.povray.org/povray.advanced-users/message/%3C63dd9c26%241%40news.povray.org%3E/#%3C63dd9c26%241%40news.povr
ay.org%3E

This is very sneaky, and even though I'm aware of this problem, it still didn't
register when I was trying to debug my code, and it only dawned on me this
morning that this is what was happening.
I went through all of my code and was trying to find why my loop counter wasn't
incrementing, and I was stuck in an infinite loop.  My debug statement
overloaded the text stream, and I had to manually terminate the POV-Ray process
and restart nearly a dozen times before I fixed the problem.

Perhaps consider issuing a warning that an identifier is being passed by
reference, or some other mechanism to help fix, or better - avoid this problem
in the first place.

(Does anyone have any protective "wrapper" code to somehow alert that an
identifier is being passed into a macro that can be modified by the macro rather
than dummy/placeholder identifier?)

I also unconsciously engage in the bad habit of running loops from 0 to 1,
creating fractional loop counter values.  "Fractional loop counter value"
warning would be useful just to stay out of the weeds in some of the hairier
code.

- BW

[William F Pokorny] Re: 3.8 macro parsing errors [651 days 11 hours and 35 minutes ago]

Tue, 25 Jun 2024 19:48:21 GMT

On 6/25/24 14:57, William F Pokorny wrote:
> Off to again update the new rulesOfThumbForMath.txt file - or the code, 
> if I can figure out how to let only infinite double returns from val() 
> past by the debug compile checking for infinite values.

The yuqk documentation was updated.

There isn't any practical way to turn off all the checking for 
infinities in the debug compile of yuqk to allow for the setting of 
+-inf via val().

So, in the non-debug compile of yuqk and all recent official POV-Ray 
releases you can set +-inf values via val() and do things like 
comparisons. However, the +-inf values are likely to cause undetected & 
unreported problems should they make it into downstream math - or into 
any down stream functions. Use with caution.

Bill P.

[William F Pokorny] Re: 3.8 macro parsing errors [651 days 12 hours and 26 minutes ago]

Tue, 25 Jun 2024 18:57:13 GMT

On 6/25/24 11:53, jr wrote:
> our" as in not just 'yuqk' ?  (because the wiki docs only mention 'float', and
> knowing it'll be a double is useful (I think))

I'm reasonably sure. :-)

It's true that the yuqk fork moved from the std::atof() function to 
std::strtod() to enable better debugging on bad, but still sort of 
getting converted strings. I wanted the debug compile of yuqk to return 
detail on problems and not just continue onward with unintended values. 
I believe both std::atof() and std::strtod() return doubles(*).

I'm not 100% sure what std::atof() might do on being passed "1.0f" say,
but it should be getting assign to a return double.

Suppose we have these two SDL lines where the first one is what we 
intended and the second one is what we typed.

#debug concat("val(1.0123\") = ",str(val("1.0123"),19,17),"\n")
#debug concat("val(1.01 23\") = ",str(val("1.01 23"),19,17),"\n")

in v3.8 beta 2 or the non-debug compile of yuqk we get the following 
output:

val(1.0123") = 1.01229999999999998  // (Example of str's noisy digits)
   (f_boom() %g returns 1.0123 with default rounding)
val(1.01 23") = 1.01000000000000001 // Oops

Where the debug compile of yuqk returns:

val(1.0123") = 1.01229999999999998
File 'HUGE_VAL.pov' line 46:
Parse Error:
Error during val call At: < 23> converting <1.01 23>
Value set to <1.01>

---

And wonder of wonders, I used the same test scene file I was using for 
the +-inf stuff and my debug compile dies on:

#debug concat("val(\"inf\") = ",str(val("+inf"),19,17),"\n")

but not in val but due an additional check I inserted in our expression 
parsing... Ideally at that check I would remember be smart enough to 
trust that std::strtod()'s own parsing handles the infinities correctly. 
I'd bet there is no easy way to do that with 100% certainly and still 
prevent other +-inf things which are very likely problems.

I'll look, but currently, I'd say now you cannot use infinities at all 
in the debug version of yuqk. Thanks jr & BW for the questions.

Off to again update the new rulesOfThumbForMath.txt file - or the code, 
if I can figure out how to let only infinite double returns from val() 
past by the debug compile checking for infinite values.

Bill P.

[William F Pokorny] Re: 3.8 macro parsing errors [651 days 13 hours and 3 minutes ago]

Tue, 25 Jun 2024 18:19:24 GMT

On 6/25/24 09:45, Bald Eagle wrote:
> Can we use those for actual practical comparisons?

Unless there is some sort of bug(*) or check(**) it should be you can do 
comparisons with inf (the sign should only be strictly needed for -inf).

Bill P.

(*) - There might be compiler flags which break the capability - see 
recent povray.unix posts. Testing what you expect to work involving 
+-inf in SDL is prudent. I'd not trust feeding these infinite values to 
functions SDL or VM ones for example.

(**) - The debug compile of the yuqk fork will often, but not always 
complain and stop/throw on seeing infinite values.

[jr] Re: 3.8 macro parsing errors [651 days 15 hours and 28 minutes ago]

Tue, 25 Jun 2024 15:55:00 GMT

hi,

William F Pokorny <ano### [at] anonymousorg> wrote:
> ...
> I also forgot, as I often do because of its name, about our val() SDL
> function which converts string floating point representations of values
> to internal double representations.

"our" as in not just 'yuqk' ?  (because the wiki docs only mention 'float', and
knowing it'll be a double is useful (I think))

regards, jr.

[Bald Eagle] Re: 3.8 macro parsing errors [651 days 17 hours and 33 minutes ago]

Tue, 25 Jun 2024 13:50:00 GMT

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

> I also forgot, as I often do because of its name, about our val() SDL
> function which converts string floating point representations of values
> to internal double representations. The following works, which could be
> useful for +-inf maths.
>
> #debug concat("val(\"+inf\") = ",str(val("+inf"),19,17),"\n")
> #debug concat("val(\"-inf\") = ",str(val("-inf"),19,17),"\n")
> #debug concat("val(\"+nan\") = ",str(val("+nan"),19,17),"\n")
> #debug concat("val(\"-nan\") = ",str(val("-nan"),19,17),"\n")

Whoa.  This is interesting.
I don't currently have access to a machine to run the test with, but:
Can we use those for actual practical comparisons?

#if (N = "val(\"+inf\") )
.. . .
?

#if (N = "val(\"+nan\") )
.. . .
?

And are the signs required?

- BW

[William F Pokorny] Re: 3.8 macro parsing errors [651 days 22 hours and 1 minute ago]

Tue, 25 Jun 2024 09:21:28 GMT

On 6/24/24 20:30, William F Pokorny wrote:
> #declare Val = 1.012345678901234567890/(+0.0); // +inf Why + ?

Should have read:

#declare Val = 1.012345678901234567890/(-0.0); // +inf Why + ?

---

FWIW. This morning I glanced at the str() implementation while my coffee 
maker worked. You can on overflowing an internal buffer, trigger 
exponential (%g) formatting, but that method is of course not of 
practical use...

---

I also forgot, as I often do because of its name, about our val() SDL 
function which converts string floating point representations of values 
to internal double representations. The following works, which could be 
useful for +-inf maths.

#debug concat("val(\"+inf\") = ",str(val("+inf"),19,17),"\n")
#debug concat("val(\"-inf\") = ",str(val("-inf"),19,17),"\n")
#debug concat("val(\"+nan\") = ",str(val("+nan"),19,17),"\n")
#debug concat("val(\"-nan\") = ",str(val("-nan"),19,17),"\n")

---

Aside. I've have avoided putting much work into the SDL string functions 
in yuqk because I want to do that work alongside a move to all utf8 
string handling (with conversions to ucs4 internally for things like 
strlen(), maybe message passing too, I don't know - all at that dream 
planning stage).

Bill P.

[William F Pokorny] Re: 3.8 macro parsing errors [652 days 6 hours and 53 minutes ago]

Tue, 25 Jun 2024 00:30:00 GMT

On 6/24/24 09:29, Bald Eagle wrote:
> "Bald Eagle" <cre### [at] netscapenet> wrote:
> 
>>      double min = +-2.22507e-308
>>      double max = +-1.79769e+308
> 
> So, I just got done playing around with that 500+ lines of the hypergeometric
> function, and some of the values were too large to display in the #debug stream.
> 
> I had no idea I could - make - numbers that large in SDL.
> It looked like each line didn't carriage-return and overwrote the previous one.
> 

Unsure what you are seeing there. The windows output & official POV-Ray 
release for unix like systems are both long different than my yuqk fork 
in formatting and using '\r' (internally 'lf/cr' for one, I think. 
Though, it's been a long time since I've was making changes in that code)

The yuqk fork is unix/linux only and I moved everything to '\n' line 
terminations and formatting was made more compatible with typical 
unix/linux terminal output.

> Also, having objects with coordinates that large seemed to slow down the render
> phase even though the objects (small spheres) weren't even in the view frustum.
> I also sorta recall that some of my other spheres weren't even rendered, but
> that's a mid-debugging anecdotal eye-witness recollection - so assign to that
> whatever reliability that you will.
> 

See that previously attached file and the lines:

In official releases of POV-Ray a good rule of thumb is to keep 
coordinates, shape dimensions, spatial transforms and values in the 1e-2 
to 1e+5 range.

The yuqk fork supports a more centered 1e-6 to 1e+6 range.

I've since added more about bounding limits of +-2e10 and the max 
current intersection limit distance of +-1e7 which will be in the yuqk 
(R15) released version of that file.

> 
> So I'm wondering 3 things:
> 
> 1. how to make the #debug stream behave properly
>       (I often get things written to the stream that seem - out of order.)
>       no overwriting of existing lines when str() overflows the screen width

Fair answers in yuqk are to always use a trailing '\n' new line 
characters (and sometimes leading a leading '\n' ones help too to force 
'more immediate' outputs to particular streams. Set the inbuilt output 
streams to write each to files. Things are routed through POV-Ray's 
messaging system, which is itself buffered beyond any file buffering 
which, well just kinda get jumbled sometimes especially where POV-Ray's 
usual five output streams are getting merged in some way in the output 
users see.

One thing I do when I really care about debugging output is open an 
output file of my own and use "#write" with the newline '\n' character 
formatting to force more immediate output.

That file should be closed properly when you are done, but if you've 
added the newline '\n' characters the unix/linux OS is quite good at 
getting what's buffered written and closing the open file handles itself 
even when things crash.

> 2. how to use str () to display numbers to display with 10eN exponential format

There is no way to do this with str() or vstr() - it's on my list to 
look at numerical output issues with these too. Don't trust those string 
functions too far, if you do go beyond float ranges and accuracy.

One of the reasons I created the inbuilt function f_boom() was to get 
more accurate output including the jumps to exponential notation. Went 
to create a few examples - and blast it, if I didn't immediately see I'd 
used 16 digits instead of 17 in that function! The fix will be in R15 of 
yuqk.

> 3. how to express things like INF in SDL and write code to utilize that value.
> 

There is not today a way to directly use such literals in SDL, though I 
have given some thought to implementing a few like these in yuqk.

There may be some differences in results below depending on how your 
running version of was compiled. On linux using the default -ffast-math, 
-O3 optimized compile it should be you mostly follow as below.

Getting output with:  #debug concat("Val = ",str(Val,19,17),"\n")

#declare Val = -0.0;  // -0.0
#declare Val = +0.0;  //  0.0
#declare Val = 1.012345678901234567890/(+0.0); // +inf
#declare Val = 1.012345678901234567890/(+0.0); // +inf Why + ?
#declare Val =-1.012345678901234567890/0.0; // +inf Why + ?
#declare Val = -1.01e300/1e-300; // -inf

And using that last #declare you can use code like:

#if (Val < -1.01e300) // When Val -inf this trips...
     #debug "(Val < -1.01e300)\n\n"
#else
     #debug "\n"
#end

---

If in the SDL we have:

#declare Val = 1.012345678901234567890/1e-25;

The usual str() output will be:

10123456789012344763056128.00000000000000000

while yuqk's f_boom (with the 17 sig digit fix) spits out:

1.0123456789012345e+25  (and then it throws an exception)

Auto jumping to exponential notation should be done with str(), vstr() 
when we exceed double's representational  accuracy or the digits 
available due the user's formatting specification. Today we can create 
output with both noisy digits and garbage digits.

> Also, some of my macro results came back as NAN.  Doe yuqk have a function to
> assign NAN to a user-declared variable ?
> 

In my non-debug version of yuqk and my compile of v3.8 beta 2, you can 
get +-nan by calling one of the inbuilt functions (C++ std library 
functions) which generates them, but mostly they can only be be printed!

For example, numerical comparisons with them are not reliable (tangled 
in compiler options/support) and this is all that can be done in SDL today.

#declare Val = pow(-1,2.1);  // -nan

FWIW. The debug version of yuqk dies on the line above with:

Parse Error:
Domain error with pow() call.
Base value is negative and exponent not an integer.

Bill P.

[Bald Eagle] Re: 3.8 macro parsing errors [652 days 17 hours and 53 minutes ago]

Mon, 24 Jun 2024 13:30:00 GMT

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

>     double min = +-2.22507e-308
>     double max = +-1.79769e+308

So, I just got done playing around with that 500+ lines of the hypergeometric
function, and some of the values were too large to display in the #debug stream.

I had no idea I could - make - numbers that large in SDL.
It looked like each line didn't carriage-return and overwrote the previous one.

Also, having objects with coordinates that large seemed to slow down the render
phase even though the objects (small spheres) weren't even in the view frustum.
I also sorta recall that some of my other spheres weren't even rendered, but
that's a mid-debugging anecdotal eye-witness recollection - so assign to that
whatever reliability that you will.

So I'm wondering 3 things:

1. how to make the #debug stream behave properly
     (I often get things written to the stream that seem - out of order.)
     no overwriting of existing lines when str() overflows the screen width
2. how to use str () to display numbers to display with 10eN exponential format
3. how to express things like INF in SDL and write code to utilize that value.

Also, some of my macro results came back as NAN.  Doe yuqk have a function to
assign NAN to a user-declared variable ?

- BW

[Bald Eagle] Re: 3.8 macro parsing errors [654 days 7 hours and 18 minutes ago]

Sun, 23 Jun 2024 00:05:00 GMT

William F Pokorny <ano### [at] anonymousorg> wrote:
> On 6/22/24 01:58, William F Pokorny wrote:
> > With respect to SDL variables, your asking a simple sounding,
> > complicated question. 🙂
> >
> > Let me think about what a good answer would be.
>
> OK. I've written up a first draft of documentation I plan to include in
> the next yuqk release (R15). See the attached txt file.
>
> Bill P.

Thank you for this.  :)



"So long as the maths are entirely within the SDL/VM/Messaging framework in the
yuqk fork, you can use the double's range of values:

    double min = +-2.22507e-308
    double max = +-1.79769e+308
"

:O   Holy crap.

"In official POV-Ray releases - or where you want to play things safer to home
in yuqk - using the single float ranges are more stable / reliable.

    float min = +-1.17549e-38
    float max = +-3.40282e+38
"

WAY more range than I thought there was!

So values of 10^-16 shouldn't be too big of a deal.

- BW

[William F Pokorny] Re: 3.8 macro parsing errors [654 days 16 hours and 27 minutes ago]

Sat, 22 Jun 2024 14:55:45 GMT

On 6/22/24 01:58, William F Pokorny wrote:
> With respect to SDL variables, your asking a simple sounding, 
> complicated question. ðŸ™‚
> 
> Let me think about what a good answer would be.

OK. I've written up a first draft of documentation I plan to include in 
the next yuqk release (R15). See the attached txt file.

Bill P.

[William F Pokorny] Re: 3.8 macro parsing errors [655 days 1 hour and 25 minutes ago]

Sat, 22 Jun 2024 05:58:08 GMT

On 6/21/24 22:16, Bald Eagle wrote:
> Got it to mostly work.
> What is the smallest number that I can realistically use for a variable value?
> Largest?
> 
> (Maybe yuqk can have yuqk_smallest and yuqk_largest as internal values to
> compare against?)

With respect to SDL variables, your asking a simple sounding, 
complicated question. :-)

Let me think about what a good answer would be.

I too have thought about bringing out some of the internal values used 
in yuqk - through a new function or new keywords. There are a couple 
good numeric rules of thumb used internally in the yuqk fork. The 
official releases of POV-Ray are ... more chaotic, numerically.

Bill P.

[Bald Eagle] Re: 3.8 macro parsing errors [655 days 5 hours and 3 minutes ago]

Sat, 22 Jun 2024 02:20:00 GMT

I was really just going mind-blind.

I went over that code another 7 or 8 times and still missed it.
I even skipped over the (obvious in hindsight) spot where the indenting skipped
a beat.

"I started by boiling the code you
posted for Gamma() down to what needs #end matching."

So I did that, and I caught it.
#if (X < 12.0) was not properly ended.

Got it to mostly work.
What is the smallest number that I can realistically use for a variable value?
Largest?

(Maybe yuqk can have yuqk_smallest and yuqk_largest as internal values to
compare against?)

I know Alain posted this somewhere, but trying to find it....

I'm gonna get some sleep and then see if writing a Beta function works with what
I've got for Gamma.


Thanks.  Sanity mostly restored.
Also poured for 2 days, so a lot cooler.

- BW

[Bald Eagle] Re: 3.8 macro parsing errors [655 days 11 hours and 33 minutes ago]

Fri, 21 Jun 2024 19:50:00 GMT

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

> To my eyes and a quick check the parser was correct to complain. Without
> that 'extra' #end you have a missing #end statement in the code you
> posted. That 'extra' one fixed that, but Result ended up in the wrong
> spot - about which the compiler is also right to complain.

Ugh.  I really must have been reading straight through something.
I'll go over it again ASAP and try to see what I was missing.

> Parse Error:
> #declare of float, vector, and color identifiers require semi-colon ';'
> at end. As do equivalent #local identifier definitions and the #version
> setting. This error is sometimes issued where an #end statement
> incorrectly follows a floating, defined identifier. The problem may
> involve lines of prior code.
>
> Is that error message more helpful?

Better.  I'll have to read that again when I'm encountering it during my
testing/editing.

> I see Kelumden answered your C++ question (Thank you). Apologies. I
> spaced that you'd asked it.

Totally fine.   I constantly have things drop off the stack when I'm trying to
compose a long list of ideas and/or responses.

> 2) When really stumped on #end matching,
 . . .
> When lucky, mistakes will immediately be highlighted in red.

I will try some version of that - thanks!

 - BW

[William F Pokorny] Re: 3.8 macro parsing errors [655 days 12 hours and 1 minute ago]

Fri, 21 Jun 2024 19:21:46 GMT

On 6/21/24 05:40, Bald Eagle wrote:
>> 1)
>>    Result
>>
>>           #end // end macro Gamma
>> #end
>>
>> Those lines should be:
>>
>>           #end
>>   Result
>> #end // end macro Gamma
> That's because I left that extra #end in there to just try to get it to run
> without complaining about the initial "missing" #end statement.

To my eyes and a quick check the parser was correct to complain. Without 
that 'extra' #end you have a missing #end statement in the code you 
posted. That 'extra' one fixed that, but Result ended up in the wrong 
spot - about which the compiler is also right to complain.

I agree though, the error message is confusing. In my yuqk fork, I can 
add another line of explanation making the entire error message:

Parse Error:
#declare of float, vector, and color identifiers require semi-colon ';' 
at end. As do equivalent #local identifier definitions and the #version 
setting. This error is sometimes issued where an #end statement 
incorrectly follows a floating, defined identifier. The problem may 
involve lines of prior code.

Is that error message more helpful?

I see Kelumden answered your C++ question (Thank you). Apologies. I 
spaced that you'd asked it.

---

I'll offer up two tricks I use. One when translating from c/C++ to SDL 
or playing with potential changes to the POV-Ray(yuqk) code base. The 
other when trying to match all of SDL's opening directive blocks with 
their #end(s).

1) For smallish questions about c/C++ code, compile and run a small 
example. The whole of the recently announced f_catenary() function was 
written this way prior to inserting it into the yuqk source code. 
Install a C++ compiler if you've not.

For the question you asked, I'd create a file my.cpp containing:

//---
#include <iostream>
#include <string>

int main()
{
     double Result = 1.0;
     int    Y      = 1;

     Result *= Y++;
     std::cout << std::endl << Result << std::endl;

     Result *= Y++;
     std::cout << std::endl << Result << std::endl << std::endl;
}
//---

Compile with:

	g++ my.cpp

or equivalent. Without setting more options, the executable on unix like 
systems will be 'a.out'. In a terminal window type:

	a.out

And you'll see:

1

2

Trying ++Y is an interesting experiment too.

2) When really stumped on #end matching, employ an editor which matches 
braces, parens, brackets or the like. It doesn't need to be the editor 
you use day to day. I'm using 'vim via gvim' on my Ubuntu machine.

Edit a temporary file called my.pov. I started by boiling the code you 
posted for Gamma() down to what needs #end matching. I then added open 
'{' and close '}' characters in a more or less outside -> inward order.

#macro Gamma (X) {
     #if (X <= 0.0) {
     #end }

     #if (X < 0.001) {
     #end }

     #if (X < 12.0) {
         #if (arg_was_less_than_one) {
         } #else {
         #end }

         #for (i, 0, 7) {
         #end }

         #if (arg_was_less_than_one) {
         } #else {
             #for (i, 0, n) {
             #end }
         #end }

         #if (X > 171.624) {
         #end }
     #end }
#end }

When lucky, mistakes will immediately be highlighted in red. When not - 
say, for example, #end(s) are in some way matching incorrectly - I place 
the cursor at each opening '{' or closing '}' brace in turn. Its 
matching brace will be highlighted(*) in a like color to the one at my 
cursor - and I check that matching is correct for each matching pair in 
turn.

Yes, I'm managing to stay cool, but one sure feels the heat & humidity 
on stepping outside! :-)

Bill P.

(*) - In larger bits of code there are ways to find and move to the 
currently matching brace.

[jr] Re: 3.8 macro parsing errors [655 days 14 hours and 18 minutes ago]

Fri, 21 Jun 2024 17:05:00 GMT

hi,

"Bald Eagle" <cre### [at] netscapenet> wrote:
> ...
> then 3.1
> which is when it started parsing differently / more thoroughly.

noted.  (for when it's my turn again "cursing the parser" :-))

> Hope you're doing well and staying cool,

the "heat dome" your side is making the news here too, hope you too (and WFP,
others? in the region) keep cool + hydrated.  cheers.

regards, jr.

[Bald Eagle] Re: 3.8 macro parsing errors [655 days 15 hours and 28 minutes ago]

Fri, 21 Jun 2024 15:55:00 GMT

"Kelumden" <nomail@nomail> wrote:

> In your interpretation, Y will never be incremented ...

Yes, I knew there was reason that I wasn't fully confident with what I wrote.

Thanks for the clarification - I was trying to crank out a language translation
at the end of a hot day, and getting frustrated by parser woes.

Thanks!

Hopefully I can get the rest of it sorted out to do some testing and then start
daisy-chaining everything together soon.

[Kelumden] Re: 3.8 macro parsing errors [655 days 15 hours and 48 minutes ago]

Fri, 21 Jun 2024 15:35:00 GMT

> Also struggling a bit with
> result *= y++;
> I interpreted that as:
> #local Result = Result * (Y+1);
> (line 102)

The whole statement, when decomposed, can be interpreted in C/C++ as

      old_y = y ;
      y = y + 1 ;
      result = result * old_y ;

'y++' is interpreted as get the value of y, increment y by one then return the
value of y prior to incrementing it.

      #local Old_Y = Y ;
      #local Y = Y + 1 ;
      #local Result = Result * Old_Y ;

In your interpretation, Y will never be incremented ...

[Bald Eagle] Re: 3.8 macro parsing errors [655 days 21 hours and 38 minutes ago]

Fri, 21 Jun 2024 09:45:00 GMT

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

> and _then_ there's the first line:
> > #version 3.1;

I started with 3.8

edited

got pissed, and figured it was the lurking #local bug in macros,

set it to 3.7

then 3.5

then 3.1

which is when it started parsing differently / more thoroughly.

So that's how _that_ happened.

Hope you're doing well and staying cool,

BW

[Bald Eagle] Re: 3.8 macro parsing errors [655 days 21 hours and 38 minutes ago]

Fri, 21 Jun 2024 09:45:00 GMT

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

> The yuqk fork complains about the line with the comment "// end macro
> Gamma" and there being a missing semicolon somewhere prior, but in this
> case the error is somewhat miss-leading.
>
> The parser is unhappy because that line isn't the end of the macro, but
> of an #if directive. The '#end' line following is the end of the macro.
>
> 1)
>   Result
>
>          #end // end macro Gamma
> #end
>
> Those lines should be:
>
>          #end
>  Result
> #end // end macro Gamma

That's because I left that extra #end in there to just try to get it to run
without complaining about the initial "missing" #end statement.

The initial configuration was just:

  Result

#end // end macro Gamma

Then I just commented it out when I started version changing.

> 2) Also in macro Gamma it looks possible by logic to go all the way
> through that macro and not ever set Result. So my strong recommendation
> would be to immediately set a default local 'Result' value at the top of
> Gamma(), but I don't know what it should be.

Yes, I had that sort of idea in the back of my head after I converted to SDL,
but without being able to run it and test it, that hardly matters.  I'd get an
obvious Lvalue Rvalue error of some sort anyway.

> 3) Also in macro Gamma you have:
>
>       #if (X <= 0.0)
>          #warning concat ("Invalid input argument ", str (X, 0, 4),
>   ". Argument must be positive. \n")
>          #break
>      #end
>
> But, seems like that needs to be an #error as your not handling Result
> on the #break. You could not do that check at all then below cheat
> around some potential divisions by zero by adding fudge factors but I
> have no immediate idea what this means for the validity of any result.

It was an #error, but I needed to force further parsing.
:)

>
> 4) The following line needs a semicolon:
>
> #local Test = Gamma (0.5)

I removed that after I set v to 3.1 because the parser complained about it being
there

>
> 5) In TestGamma() you have the line:
>
> #local computed = Gamma (test[T][0])

Same as above.

Thanks for looking - I prob won't be able to start tearing my hair out again
until late tonight or tomorrow.

- BW

[jr] Re: 3.8 macro parsing errors [656 days 3 hours and 3 minutes ago]

Fri, 21 Jun 2024 04:20:00 GMT

hi,


William F Pokorny <ano### [at] anonymousorg> wrote:
> On 6/20/24 19:49, Bald Eagle wrote:
> > Can anyone confirm?
> > debug?
>
> I see a few things.

and _then_ there's the first line:
> #version 3.1;

</grin>


regards, jr.

[William F Pokorny] Re: 3.8 macro parsing errors [656 days 4 hours and 8 minutes ago]

Fri, 21 Jun 2024 03:14:32 GMT

On 6/20/24 19:49, Bald Eagle wrote:
> Can anyone confirm?
> debug?

I see a few things.

The yuqk fork complains about the line with the comment "// end macro 
Gamma" and there being a missing semicolon somewhere prior, but in this 
case the error is somewhat miss-leading.

The parser is unhappy because that line isn't the end of the macro, but 
of an #if directive. The '#end' line following is the end of the macro.

1)
		Result

         #end // end macro Gamma
#end

Those lines should be:

         #end
	Result
#end // end macro Gamma

2) Also in macro Gamma it looks possible by logic to go all the way 
through that macro and not ever set Result. So my strong recommendation 
would be to immediately set a default local 'Result' value at the top of 
Gamma(), but I don't know what it should be.

3) Also in macro Gamma you have:

      #if (X <= 0.0)
         #warning concat ("Invalid input argument ", str (X, 0, 4),
		". Argument must be positive. \n")
         #break
     #end

But, seems like that needs to be an #error as your not handling Result 
on the #break. You could not do that check at all then below cheat 
around some potential divisions by zero by adding fudge factors but I 
have no immediate idea what this means for the validity of any result.

     #if (X < 0.001)
         #local Result = 1.0/((X*(1.0 + _gamma*X))+1e-6);
     #end

and

     #local Result = Result / ((Y-1.0) + 1e-6);

4) The following line needs a semicolon:

#local Test = Gamma (0.5)

5) In TestGamma() you have the line:

#local computed = Gamma (test[T][0])

which needs a semicolon.

I hope of some help.

Bill P.

[Bald Eagle] 3.8 macro parsing errors [656 days 7 hours and 33 minutes ago]

Thu, 20 Jun 2024 23:50:00 GMT

I'm trying to port some c++ over to SDL so that I can use the Gamma function to
implement the version of the Beta function based on that.

original code:
https://www.johndcook.com/Gamma.cpp

Using v 3.8, I get "end of file found, but #end expected" even though I went
through the code 7+ times and every opening statement was matched with a
corresponding #end.

So I added a token #end, and got an error that it didn't recognize TestGamma,
which is a macro name.

So I set the scene to v 3.5 and got a bunch of weird ; errors
and now it's not recognizing #local declared variables.

This parser has some major problems if I can't write some simple macros.

Can anyone confirm?
debug?
provide a sane and function workaround?

- BW

PS


Also struggling a bit with
result *= y++;
I interpreted that as:
#local Result = Result * (Y+1);
(line 102)

[William F Pokorny] Re: transmit does not work with image maps [705 days 22 hours and 21 minutes ago]

Thu, 2 May 2024 09:02:08 GMT

On 4/21/24 12:35, Kenneth wrote:
> When using 'transmit all' with typical jpeg and png images, there is an
> unfortunate mix of flaws in both official v3.7.0 and in the v3.8 betas--
> different kinds of problems in each, especially with alpha-channel images

Thanks for the reminder on the overall read image transparency status. 
Your understanding closely matches mine.

I'll add there remain in v3.8+ long term issues with gif files coming in 
with a transparent index. Where someone specifies 'filter all' or 
'transmit all' - or a specific index reference matching the one assigned 
to 'full' transparency. In such cases the transparent index becomes 
"milky" - toward whatever RGB values are sitting in the gif-transparent 
index.

There are too problems with sparse gif index usage getting remapped by 
POV-Ray to more compressed indexes during the gif read. The latter issue 
making it iffy to make color channel changes by index entry over the 
adjustments by specifically indexed colors.

Aside: I've had thoughts of a .df3 variation making use of the animated 
gif format internally - for compressed df3s.

Anyhow... :-)

Bill P.

[Kenneth] Re: transmit does not work with image maps [714 days 7 hours and 33 minutes ago]

Tue, 23 Apr 2024 23:50:00 GMT

"Kenneth" <kdw### [at] gmailcom> wrote:
>
> According to POV-ray's  documentation, transmit all ...some value... *should*
> work correctly even on non-GIF images. I have successfully used it many
> times in the distant past. But currently, this  is the situation:
>
> In 'official' v3.7.0, it does work correctly with typical 24-bit .jpeg's and
> png's -- but has an odd problem with 32-bit alpha-channel images that already
> have a mask...
>
> But in the v3.8 beta releases, something changed--  transmit all  is
> completely *ignored*, when used with typical 24-bit images. However, it DOES
> work correctly if those images are re-saved as 32-bit .png...

I was looking at one of my old test-scene files, and realized that there is yet
another simple workaround for the 'transmit all' problem in the 3.8 betas...
which ALSO solves the odd problem in 3.7.0 with alpha-channel images: using an
averaged pigment_map with a plain 'transmit' value instead. The relative weights
of the average determine the translucency:

pigment{
    average
    pigment_map{
         [0.6 image_map{png "my image.png" once interpolate 2]
         // .jpeg, .png, .tiff; can an have an alpha-channel mask too.

         [0.4 transmit 1.0]
               }
       }

Of course, this would require re-editing old scene files to replace the original
'transmit all', which could be cumbersome. (BTW, tiff images may or may not need
the new 'premultiplied on/off' keyword for this,  if they have an actual
alpha-channel mask. In my tests, I had to turn it off to get better visual
results. I guess it depends on the app that creates such images.)

The simple construct above makes me wonder if 3.8's problem with 'transmit all'
(re: typical 24-bit images) may be the result of a minor source code difference
between it and plain 'transmit'...possibly a change that was introduced by
mistake.

[Kenneth] Re: transmit does not work with image maps [715 days 13 hours and 28 minutes ago]

Mon, 22 Apr 2024 17:55:00 GMT

Thomas de Groot <tho### [at] degrootorg> wrote:
> Op 21/04/2024 om 18:35 schreef Kenneth:
> > When using 'transmit all' with typical jpeg and png images, there is an
> > unfortunate mix of flaws in both official v3.7.0 and in the v3.8 betas--
> > different kinds of problems in each, especially with alpha-channel images.
> > See this related post from December 2022 (with some function solutions further
> > down in the post)...
> >
> > [snip]
>
> Thanks Kenneth! Somehow, I never use those cases where the bug shows, it
> appears. Good to know if I come across the problem.
>

Over the years, I have come to realize that at least part of the transmit all /
color-reversal problem in v3.7 with alpha-channel images depends on how external
apps actually construct their own alpha channels, and the steps required. My old
version of Photoshop vs. the current paint.net app (as examples) go about it in
completely different ways, at least as far as the user is concerned. And
POV-ray's transmit all results show somewhat different flaws from each, in v3.7.
Dave Blandston's image examples in his 2022 thread show the same kind of results
I used to get with Photoshop.

I have not fully tested POV-ray's own alpha-channel image output, when brought
back into POV-ray and applied to an object, then using transmit all with it. In
the 3.8 betas, my few tests look nicely correct; in 3.7, the
translucent/transparent parts of the alpha channel (gray-to-black) start showing
up as a kind of ghostly translucent white-- although this might be hard to see
when used with other layered textures.

[Kenneth] Re: transmit does not work with image maps [715 days 15 hours and 8 minutes ago]

Mon, 22 Apr 2024 16:15:00 GMT

"Kenneth" <kdw### [at] gmailcom> wrote:
>
> But in the v3.8 beta releases, something changed--  transmit all  is
> completely *ignored*, when used with typical 24-bit images. However, it DOES
> work correctly if those images are re-saved as 32-bit .png. I currently use
> the free paint.net app to do this-- it creates a 'dummy' [white] alpha
> channel, which is apparently needed now...

[Bald Eagle wrote:]
> I wanted to re-install that, but apparently they don't support a Win 7
> version anymore and I can't find an install package for it.  :(

I just discovered another way to get this 24-bit-to-32-bit image conversion, no
external app required. It can be done *within* POV-ray, by *re-rendering* the
image there as a 1:1 reproduction .png file and using OutPut_Alpha=on in
your .ini file (or +ua on the command line).  This produces a 32-bit image with
a dummy white alpha channel, just like paint.net.  Then  'transmit all'  can
work correctly with it. I have included a small image-copying scene file to do
this, for your enjoyment ;-)

Surprisingly, this new image also works correctly in v3.7.0  re:  transmit all
-- which has a problem with typical 32-bit alpha-channel images. I think this is
because the dummy alpha-channel *is* pure white (meaning fully 'opaque', no
transparency.) Whereas, the translucent/transparent areas in usual
alpha-channels are gray-to-black, with black representing full transparency.
It's *those* areas that cause the odd 'transmit all' color-reversal problem in
v3.7 (IF there are image colors in those areas.)

(BTW, the following bit of info in the POV-ray documentation at '3.6.2.6.4 Using
the Alpha Channel' can be ignored for this 1:1 re-render):
"Note: In version 3.7 alpha handling for image file output has changed.
Effectively, the background now requires a filter or transmit value in order for
alpha transparency to work properly."
-------------

#version 3.8; // 3.7 also works for this
global_settings{assumed_gamma 1.0}

//#declare IMAGE_DIMEN = <1152,921>; // pixel size of the original image to be
// copied. For perfect 1:1 final image size, enter these values onto
// the command line-- like +w1152 +h921 -- which overrides any .ini file
// resolutions.

// Or, you could use the max_extent(...) keyword to automatically get the
// dimensions of the image...
#declare IMG = pigment{image_map{jpeg "my image.jpg" gamma 2.2}} // must be
// #declared first. Do not use 'interpolate' for 1:1 reproduction. 'Once' is
// not necessary either. Gamma setting is optional.

#declare IMAGE_DIMEN = max_extent(IMG);

camera {
  orthographic // perspective or orthographic, same result
  location  <.5*(IMAGE_DIMEN.x/IMAGE_DIMEN.y), .5, -1> // u and v also work
  look_at   <.5*(IMAGE_DIMEN.x/IMAGE_DIMEN.y), .5,  0>
  right     x*image_width/image_height
  //angle 67 // Leave this out for 1:1 render! The default angle is not 67.
}

// the original image, on a box to copy it
box{0,<1,1,0> // zero-thickness is OK
texture{
    pigment{IMG}
    finish{ambient 1 emission 0 diffuse 0}
       }
    scale <IMAGE_DIMEN.x,IMAGE_DIMEN.y,1>/IMAGE_DIMEN.y
}

[Thomas de Groot] Re: transmit does not work with image maps [716 days 1 hour and 10 minutes ago]

Mon, 22 Apr 2024 06:12:23 GMT

Op 21/04/2024 om 18:35 schreef Kenneth:
> When using 'transmit all' with typical jpeg and png images, there is an
> unfortunate mix of flaws in both official v3.7.0 and in the v3.8 betas--
> different kinds of problems in each, especially with alpha-channel images.
> See this related post from December 2022 (with some function solutions further
> down in the post)...
> 
> [snip]

Thanks Kenneth! Somehow, I never use those cases where the bug shows, it 
appears. Good to know if I come across the problem.

-- 
Thomas

[Bald Eagle] Re: transmit does not work with image maps [716 days 7 hours and 38 minutes ago]

Sun, 21 Apr 2024 23:45:00 GMT

"Kenneth" <kdw### [at] gmailcom> wrote:

> According to POV-ray's  documentation, transmit all ...some value... *should*
> work correctly even on non-GIF images. I have successfully used it many times in
> the distant past.

Yeah, see, I thought so.  Good to know it's "just" buggy behaviour.

> I currently use the
> free paint.net app to do this-- it creates a 'dummy' alpha channel, which is

I wanted to re-install that, but apparently they don't support a Win 7 version
anymore and I can't find an install package for it.  :(

Thanks for the info!

[Kenneth] Re: transmit does not work with image maps [716 days 14 hours and 43 minutes ago]

Sun, 21 Apr 2024 16:40:00 GMT

When using 'transmit all' with typical jpeg and png images, there is an
unfortunate mix of flaws in both official v3.7.0 and in the v3.8 betas--
different kinds of problems in each, especially with alpha-channel images.
See this related post from December 2022 (with some function solutions further
down in the post)...

https://news.povray.org/povray.binaries.images/thread/%3Cweb.63ac0323f59cfc766631b53a9334df62%40news.povray.org%3E/?mto
p=438912

and this one from 2016...
https://news.povray.org/povray.binaries.images/thread/%3C569528cc%241%40news.povray.org%3E/

According to POV-ray's documentation, transmit all ...some value... *should*
work correctly even on non-GIF images. I have successfully used it many times in
the distant past. But currently, this is the situation:

In 'official' v3.7.0, it does work correctly with typical 24-bit .jpeg's and
png's -- but has an odd problem with 32-bit alpha-channel images that already
have a mask, where the 'invisible' parts of the alpha mask start showing up as
the image's complementary colors instead. (Developer Christoph Lipka fixed that
particular flaw back in 2016, in one of the ongoing v3.71 development releases
that 'piggy-backed' on v3.7.)

But in the v3.8 beta releases, something changed-- transmit all is completely
*ignored*, when used with typical 24-bit images. However, it DOES
work correctly if those images are re-saved as 32-bit .png. I currently use the
free paint.net app to do this-- it creates a 'dummy' alpha channel, which is
apparently needed now. Images with an *actual* alpha channel also behave
properly. (If the #version in the scene is changed to 3.7 instead of 3.8, the
behavior is the same as using v3.7.0 itself: transmit all works as advertised
on typical 24-bit images...but with the prior 32-bit alpha-channel problem.)

[Thomas de Groot] Re: transmit does not work with image maps [717 days and 16 minutes ago]

Sun, 21 Apr 2024 07:07:00 GMT

Op 19-4-2024 om 13:27 schreef William F Pokorny:
> On 4/19/24 02:36, Thomas de Groot wrote:
>> I never used that wiki example though. I wonder if that is not 
>> specifically for GIF image formats only...?
> 
> You've got it Thomas. When you specify an integer rather than 'all' you 
> are asking the 'filter' and 'transmit' keywords to modify an indexed 
> image's filter / transmit value for a particular index 'n'. This is not 
> possible with non-indexed images (probably not too, where indexes are 
> out of range).
> 
> Several image formats support internal formats using indexes / tables of 
> color/grey values. I'm unsure of the complete, working / supported list 
> for POV-Ray? The gif format is always indexed and it's certainly one 
> which works.
> 
> Bill P.

Thank you Bill. I suspected something like this but it has been such a 
long time since I last manipulated gif-format images that the info had 
become ghost-like in my mind...

-- 
Thomas

[William F Pokorny] Re: transmit does not work with image maps [718 days 19 hours and 55 minutes ago]

Fri, 19 Apr 2024 11:27:54 GMT

On 4/19/24 02:36, Thomas de Groot wrote:
> I never used that wiki example though. I wonder if that is not 
> specifically for GIF image formats only...?

You've got it Thomas. When you specify an integer rather than 'all' you 
are asking the 'filter' and 'transmit' keywords to modify an indexed 
image's filter / transmit value for a particular index 'n'. This is not 
possible with non-indexed images (probably not too, where indexes are 
out of range).

Several image formats support internal formats using indexes / tables of 
color/grey values. I'm unsure of the complete, working / supported list 
for POV-Ray? The gif format is always indexed and it's certainly one 
which works.

Bill P.

[Thomas de Groot] Re: transmit does not work with image maps [719 days and 46 minutes ago]

Fri, 19 Apr 2024 06:36:57 GMT

Op 19/04/2024 om 04:11 schreef Bald Eagle:
> 
>
https://wiki.povray.org/content/Reference:Image_Map#The_Filter_and_Transmit_Bitmap_Modifiers
> 
> I'm trying filter all and transmit all, and there is no observable filter or
> transmit.
> 
> When I try filter 0, 0.99, I get
> 
> Parse Error: Keyword 'transmit' cannot be used with non color-mapped image.
> 
> So either I'm doing something very wrong, or this part of the code is _broken_,
> or things have changed, and the documentation does not reflect this.
> 
> Can anyone verify / solve / workaround?
> 
> - BE
> 
> 

Should work I guess. I use them all the time, with Poser figures in 
particular. Example:

#declare p_map13=pigment {image_map{jpeg "JamesHair1.jpg" gamma srgb 
interpolate 2 transmit all 0 filter all 0} }

I never used that wiki example though. I wonder if that is not 
specifically for GIF image formats only...?

-- 
Thomas

[Bald Eagle] transmit does not work with image maps [719 days 5 hours and 8 minutes ago]

Fri, 19 Apr 2024 02:15:00 GMT

https://wiki.povray.org/content/Reference:Image_Map#The_Filter_and_Transmit_Bitmap_Modifiers

I'm trying filter all and transmit all, and there is no observable filter or
transmit.

When I try filter 0, 0.99, I get

Parse Error: Keyword 'transmit' cannot be used with non color-mapped image.

So either I'm doing something very wrong, or this part of the code is _broken_,
or things have changed, and the documentation does not reflect this.

Can anyone verify / solve / workaround?

- BE

[Mr] Re: Failed to start render: Failed to parse INI ... [750 days 22 hours and 48 minutes ago]

Mon, 18 Mar 2024 08:35:00 GMT

"jr" <cre### [at] gmailcom> wrote:
> "Rob" <nomail@nomail> wrote:
> > "jartim" <tim### [at] yahoocom> wrote:
> > ...
>
> 5038 days.  a record ? :-)
>
>
> regards, jr.

Still, Thanks for constructive feedback it's also good because it keeps
workarounds actualized.

[jr] Re: Failed to start render: Failed to parse INI ... [751 days 15 hours and 48 minutes ago]

Sun, 17 Mar 2024 15:35:00 GMT

"Rob" <nomail@nomail> wrote:
> "jartim" <tim### [at] yahoocom> wrote:
> ...

5038 days.  a record ? :-)


regards, jr.

[Rob] Re: Failed to start render: Failed to parse INI ... [751 days 21 hours and 18 minutes ago]

Sun, 17 Mar 2024 10:05:00 GMT

"jartim" <tim### [at] yahoocom> wrote:
> Thorsten Froehlich <tho### [at] trfde> wrote:
> > On 26.05.10 15:35, clipka wrote:
> > > Sounds familiar - I guess it is a variation of known bug FS#107
> > > (<http://bugs.povray.org/task/107>); a fix for that exists and will be
> > > included in the next beta release.
> > >
> > > Until then you'll probably have to work around by copying the files to a
> > > local directory and rendering from there.
> >
> > Actually, mapping the network share to a drive letter is sufficient.
> >
> > Interesting enough, there are lots of programs out there that cannot deal
> > with network share paths in Windows ... so at least we are not alone with
> > this (already fixed) bug.
> >
> >  Thorsten
>
> Thanks for the help, but I still have the problem.
> I tried changing the povray.ini location by mapping it to a drive and setting
> the POVINI environment variable to point to it - set POVINI =
> H:\POV-Ray\v3.7\ini\povray.ini
>
> This still makes no difference, in fact no matter what I set POVINI to point to
> I still get the same error! I have tried pointing to local folders on drive C
> and remote folders on drive H.

If you have changed directories like I have, you have to change the registry
too, go to the registry editor and go to
'Computer\HKEY_CURRENT_USER\Software\POV-Ray\v3.7\Windows'
There will be 'DocPath' and 'Home', change those to the path of the directory
you have installed it in

[Cousin Ricky] Re: one source, two images [796 days 7 hours and 36 minutes ago]

Thu, 1 Feb 2024 23:46:51 GMT

On 2024-02-01 18:57 (-4), William F Pokorny wrote:
> 
> And yep! That I cannot remember my own work is a little disturbing.

Based on my own experience, and hearing from other coders, you are
perfectly normal.

IIRC, this observation is noted in the book _The Elements of Programming
Style_ from back in the 1970s.  They say to write your code for someone
else, because in the future, you *will* be someone else.

[William F Pokorny] Re: one source, two images [796 days 8 hours and 26 minutes ago]

Thu, 1 Feb 2024 22:57:19 GMT

On 2/1/24 07:28, William F Pokorny wrote:
>> My vague recollection is that some time during v3.71->v3.8 development 
>> a typo was introduced somewhere in the class set up for the spiral 1 & 
>> 2 patterns. We ended up with two spiral1(s) or two spiral2(s) instead 
>> of one of each - or something similar to that. Likely in pattern.h or 
>> pattern.cpp or both.
> 
> In looking at a question elsewhere I realized there is more going on 
> with these spiral 1 & 2 changes that I realized when I picked up an 
> unexpected difference in spiral1 spin direction in yuqk. I'll need to 
> dig for a while.

OK. I did not remember correctly - not that much of a surprise these days.

The typo in the v3.8 code is in the parser not in the class definitions 
for the spirals. Further, the typo is in a section which pertains to the 
use of the spiral1 pattern in a function.

In the file parser_materials.cpp there are two blocks of code looking like:

...
         CASE (SPIRAL1_TOKEN)
             New->Type = GENERIC_PATTERN;
             New->pattern = ParseSpiralPattern<Spiral1Pattern>();
         END_CASE
...

...
         CASE (SPIRAL1_TOKEN)
             New->Type = GENERIC_PATTERN;
             New->pattern = ParseSpiralPattern<Spiral2Pattern>();
         END_CASE
...

That second one is in a section which handles function{ pattern {} } 
wrap differences (though the spiral has none) and it should of course read:

...
         CASE (SPIRAL1_TOKEN)
             New->Type = GENERIC_PATTERN;
             New->pattern = ParseSpiralPattern<Spiral1Pattern>();
         END_CASE
...

On the rotational difference between v3.8 and yuqk
--------------------------------------------------

It is intentional!

I forgot that the spiral patterns were two of those touched by the fix 
to POV-Ray's internal Turbulence() function - for the distribution drift 
on the omega values.

While I was doing the work to adjust to that turbulence change and to 
move to the internal turbulence keywords (it_* (a)), I noticed the 
official POV-Ray rotation for the spiral pattern was right handed about 
z as the distance from the origin increased rather than the more normal 
- and likely expected - left handed rotation(b).

(a) - The spiral's turbulence in official POV-Ray has long been 
colliding with the pattern modifier's 'frequency' keyword usage.

(b) - With yuqk, I have, in a few other places too, moved to change 
right handed implementations of stuff to left handed ones.

Remembering all this, I recall there is somewhere a detailed post on 
everything going on that was fixed / changed in yuqk with the spiral 
patterns.

And yep! That I cannot remember my own work is a little disturbing.

Bill P.

[William F Pokorny] Re: one source, two images [796 days 18 hours and 55 minutes ago]

Thu, 1 Feb 2024 12:28:14 GMT

On 11/19/23 02:15, William F Pokorny wrote:
> My vague recollection is that some time during v3.71->v3.8 development a 
> typo was introduced somewhere in the class set up for the spiral 1 & 2 
> patterns. We ended up with two spiral1(s) or two spiral2(s) instead of 
> one of each - or something similar to that. Likely in pattern.h or 
> pattern.cpp or both.

In looking at a question elsewhere I realized there is more going on 
with these spiral 1 & 2 changes that I realized when I picked up an 
unexpected difference in spiral1 spin direction in yuqk. I'll need to 
dig for a while.

Not got much coffee in me yet, but I thought my remembered change/fix 
would be obvious. Of course, in a quick look just now I don't see it at 
all!

The v3.7.0.10 result on the left, my current yuqk working code on the 
right of the attached image.

Bill P.

[Le Forgeron] Re: animation display window does not reset to b... [822 days 21 hours and 30 minutes ago]

Sat, 6 Jan 2024 09:52:37 GMT

Le 02/01/2024 Ã  19:58, Jonathan Bush a Ã©critÂ :
> Apparently, if every frame of an animation is identical, POVray will not black
> out frames beyond the first frame. I'm not sure if this qualifies as a bug or
> not.
> 
> My apologies, nothing to see here, move along.
> 
> 
Actually, displayed image on X11 system (such as linux) during rendered 
is not reset between frames.

I made a modification on the hgpovray fork to dimer the previous image 
when computing start, so that the graphical progress of the rendering of 
the new frame is still visible (excepted if all is black on black). But 
that is my personal taste.

[jr] Re: animation display window does not reset to b... [824 days 19 hours and 48 minutes ago]

Thu, 4 Jan 2024 11:35:00 GMT

hi,

"Jonathan Bush" <djb### [at] gmxcom> wrote:
> ...
> And speaking of diagnostic info, I am unable to disable the verbose option for
> POVray. I put -V on the command line, and my povray.ini file includes the line
> Verbose=Off
> But it won't shut up. ...

I use '-gr -gs' to reduce output.  and 'nice -n 19 povray ...' generally.

also, re "compiled by Beckmann", as you're evidently ok with command lines, why
not (configure and) build your own ?
<https://github.com/POV-Ray/povray/tags/>

regards, jr.

[Jonathan Bush] Re: animation display window does not reset to b... [826 days 12 hours and 23 minutes ago]

Tue, 2 Jan 2024 19:00:00 GMT

Apparently, if every frame of an animation is identical, POVray will not black
out frames beyond the first frame. I'm not sure if this qualifies as a bug or
not.

My apologies, nothing to see here, move along.

[jr] Re: animation display window does not reset to b... [827 days 1 hour and 23 minutes ago]

Tue, 2 Jan 2024 06:00:00 GMT

hi,

"Jonathan Bush" <djb### [at] gmxcom> wrote:
> ...
> I will continue to make simpler and simpler code until it works correctly, then
> I will post the simplest code I could make which demonstrates the problem.

had a first quick look, a couple of comments only.

looks like you can use some of POV-Ray's "built-in" stuff to advantage.  the
'frame_number' for instance.  the idea of (re)writing a shell script which gets
executed by an .ini is new to me, and looks interesting; thinking that the
'Parse_String()' macro is what you're looking for instead.

<https://wiki.povray.org/content/Reference:Numeric_Expressions#Built-in_Variables>
<https://wiki.povray.org/content/Reference:Strings.inc>

fwiw, if (ap.pov) "The first second is static", then that code does not
"belong".  recommend splitting the generation of the initial frames from the
game/move animation.

regards, jr.

[Jonathan Bush] Re: animation display window does not reset to b... [827 days 5 hours and 33 minutes ago]

Tue, 2 Jan 2024 01:50:00 GMT

Regarding Windows, of course the copy command is a different syntax. I don't
imagine a bash shellout command would work either. The files ap_skip.inc and
povray.ini would need to be modified to produce a command string which Windows
would be able to run. Sorry, I cannot offer much help with that.

I ran a subset of the frames, skipping the initial static interval. The same
problem occurred; the display of the first frame was initially black, but
subsequent frames did not reset to black. I rewrote the code to produce a
9-second video where the first static second is avoided, but this did not fix
the problem either.

I will continue to make simpler and simpler code until it works correctly, then
I will post the simplest code I could make which demonstrates the problem.

I am grateful for your patience.

[Jonathan Bush] Re: animation display window does not reset to b... [827 days 7 hours and 33 minutes ago]

Mon, 1 Jan 2024 23:50:00 GMT

Thank you for responding so quickly.

In my follow-up post, I stated that you need to make a subdirectory /images with
its own subdirectories /static and /animated. See the povray.ini file for the
output file path. Sorry I don't know much about Windows; I guess you need
backslashes. I hope you don't have to edit the files to change forward slashes
to back slashes.

I hope that, once those subdirectories are installed within the directory that
contains all these files, the code will run for you. It was not my intention for
you to help me with debugging my own code. I do appreciate your efforts!
Meanwhile I would be glad to try to explain my code.

Regarding the line from ap_animate.inc

#declare NewClock123 = (clock-0.1)*1.25; // turns .1 to .9 into 0 to 1

Yes, this happens during the animated interval, when clock ranges from 0.1 to
0.8. There are 4 animated objects which follow 4 paths. The variable NewClock123
is a value that ranges from 0 to 1 during this interval, which makes it easier
for me to calculate where the first 3 of these 4 objects should be on their
paths.


render 1 seems to be about the missing subdirectories.

render 2: The file ap.pov contains line 89 assumed_gamma 1.

"In ap_skip.inc black frame" Please where is black frame? What line number?

I should provide some background. ap.pov is supposed to generate the frames for
a 10-second video at 60 fps. The first 60 frames are all identical. After the
first frame is generated, a post-frame command executes the file fix.sh which
contains a cp command to copy this frame into static0 in the /static directory.
So by the time ap_skip.inc is creating the cp command to copy from static back
into animated, you should already have that static file sitting there. This is
for frames 2 through 60.

ap_skip.inc creates the cp command and then passes it back to ap.pov inside the
variable CpCommand. Check out ap.pov line 187 for the else clause where this
string gets used. The string is placed inside fix.sh and then ap.pov stops,
which results in a black frame for this iteration. The post frame command inside
of povray.ini then copies the static image over top of the black frame that
ap.pov just generated.

If the post frame command is not working for you, you may need to modify a file
povray.conf somwhere in your system to allow shellout commands.

render 60 of 600 looks the same.

All the warning messages you show screen shots of are placed in the code by me
as diagnostics. I am unable to get #debug messages to display.

PLEASE ask if you are unable to get my code running after you create the
subdirectories, or if you have any questions.

[Kenneth] Re: animation display window does not reset to b... [827 days 8 hours and 43 minutes ago]

Mon, 1 Jan 2024 22:40:00 GMT

[running Windows 10, with POV-ray v3.7]

I downloaded your zip file. This is quite a complex scene, with many pieces that
interact, making it difficult to track down what is going on.

I attempted to run your ap.pov file with a 600-frame animation. I could not get
the scene to render at all without fatal errors-- probably because I would
need(?) to create folders and sub-folders called 'images', 'animated', 'static',
etc. and with the correct file paths to find them, which is not my own set-up.
(See your ap_skip.inc file.)

The best I could do was to run various animation frames and report the
parse-error results. I have attached that below, as screenshots; maybe it will
prove helpful. (I could not even get POV-ray's 'All_File=on' feature to work
with this scene, to output the parse-error message contents as text.)

I *suspect* that something might be wrong with how the 'clock' value is used in
the scene-- but I haven't been able to check that so far. I wonder about this
line in your ap_animate.inc file:
     #declare NewClock123 = (clock-0.1)*1.25; // turns .1 to .9 into 0 to 1

According to the notes in your posted comments, that line is supposed to kick-in
at frame 61 of the animation(?).. which is where your problems begins, as you
mentioned. But I honestly don't yet understand how all of the
various files work together for the final result.

[Jonathan Bush] Re: animation display window does not reset to b... [827 days 12 hours and 43 minutes ago]

Mon, 1 Jan 2024 18:40:00 GMT

In order to run the ap.pov script, you should have a subdirectory /images which
includes the subdirectories /static and /animated. I use the command

povray -V ap.pov

In an attempt to prevent verbose mode, for all the good it does.

[Jonathan Bush] animation display window does not reset to black [827 days 13 hours and 38 minutes ago]

Mon, 1 Jan 2024 17:45:00 GMT

The first animated frame begins as a black window and generates as usual, but
the 2nd and subsequent animated frames do not. I just see the completed first
frame remaining on the screen while I hear the computer working hard. All the
generated images are identical to the first frame. This does not happen with
other animated scripts, so my script is buggy, but what bug in my script would
result in this behavior?

System:
  Host: XPS Kernel: 5.15.0-91-generic x86_64 bits: 64 Desktop: Xfce 4.18.1
    Distro: Linux Mint 21.2 Victoria

This is an informal build 3.7.0.10 by Andreas Beckmann, so perhaps I should ask
him?

I don't know if it is related, but there are supposed to be four animated
objects in an otherwise static scene. The animated objects do not appear in the
first animated frame, although diagnostic info I see in the console tells me two
of them begin positioned within the frame.

And speaking of diagnostic info, I am unable to disable the verbose option for
POVray. I put -V on the command line, and my povray.ini file includes the line

Verbose=Off

But it won't shut up. Futhermore, #debug messages are not displayed even though
I have Debug_Console=On in that same povray.ini file. I have to use the #warning
directive instead, and the warnings are embedded within the verbose output. Here
is a sample from the console display:

==== [Parsing...] ==========================================================
File 'ap_skip.inc' line 101: Parse Warning: In ap_skip.inc ANIMATING
File 'ap.pov' line 55: Parse Warning: ***** ANIM Time=  1.0351
File 'ap_animate.inc' line 65: Parse Warning: NewClock123=  0.0044 Path123Alpha=
  0.0138
File 'ap_animate.inc' line 67: Parse Warning: piece 1 y*-63.2734 <  5.6667,
 0.0092, -5.3333>
File 'ap_animate.inc' line 68: Parse Warning: NewClock4=  0.0050 Path4Alpha=
 1.5787
File 'ap_animate.inc' line 70: Parse Warning: piece 2 y*26.3322 <  5.3334,
 0.0092, -6.3333>
File 'ap_animate.inc' line 72: Parse Warning: piece 3 <  2.3335,  0.0092,
 -6.0000>
File 'ap_animate.inc' line 74: Parse Warning: piece 4 <  7.9843,  1.3333,
 -5.6667>
----------------------------------------------------------------------------

I apologize for the rambling tone of this bug report, but I'm just trying to
provide all the info I can.

Here is the .inc file which is responsible for generating the animated objects.

//****************************************************************************
// ap_animate.inc
//
//  A lot of these comments require the other files to understand
//  what is going on. I provide a link below to Google Drive.
//
//  Here we place the 4 animated objects. 3 are BlackLink and one is BlackPeg.
//
//  IntervalIndex is either 0, 1, or 2.
//    0 refers to the first 60 frames, which are static.
//      They generate just fine. The two object commands below execute
//      correctly.
//    1 refers to frames 61 to 540 which is where the problem lies.
//      The four object commands in this block do not execute.
//      Just prior to the object commands are some
//      #warning messages, and they display onscreen during execution.
//      Someone reading this code by itself might conclude that the objects
//      are placed outside of the frame. I present this file because it might
//      pertain to the weird POVray behavior of not blacking out the display
//      at the start of frames 62 to 540.
//
//      To summarize, the buggy behavior I see begins with frame 62
//      which is the first animated frame.
//
//    2 refers the the final second, frames 541 to 600, which is also
//      A static interval.

#if (IntervalIndex = 0)     // Static interval, two pieces on the board
     // calling macros from another file, but this only happens once.
     // These commands execute correctly.
  object { BlackLink rotate y*ATH translate  Link12Pos(20, 3)}
  object { BlackLink rotate y*(-AT2) translate Link34Pos(21, 4)}
#else   // Yes, I know I could use elseif, and I will when the bugs are fixed.
  #if (IntervalIndex = 1)               // animated interval
    #declare NewClock123 = (clock-0.1)*1.25;     // turns .1 to .9 into 0 to 1
    #declare Path123Alpha = radians(180*NewClock123);
    // angle of elliptical path, 0 to pi radians
    // Path 4 is the peg, which Alpha ranges PI/2 to Pi radians,
    // arriving at hole 1 second before the links
    #declare NewClock4 = ((clock<0.8)?(clock-0.1)*(10/7):1);
    #declare Path4Alpha   = radians(90+90*NewClock4);
    #declare Center1x = separation*8.25;  // center of ellipse. path 1 is the
                                          // link3 that moves to link2.
    #declare Center1z = separation*(-8.25);
    #declare Center2x = separation*8.5;   // Path 2 is the link1 that moves to
                                          // link2.
    #declare Center2z = separation*(-9.5);
    #declare Center3x = separation*6;     // 3 is the link3 that arrives from
                                          // offscreen left
    #declare Center3z = separation*(-9);
    #declare Center4x = separation*12;    // 4 is the peg arriving from
                                          // offscreen right
    #declare Center4z = separation*(-8.5);
    #declare BoardVector1x = 0.25*separation;
    #declare BoardVector1z = 0.25*separation;   // vectors for the ellipse axes
                                                // in the xz plane
    #declare BoardVector2x = -0.5*separation;
    #declare BoardVector2z = 0;
    #declare BoardVector3x = -2.5*separation;
    #declare BoardVector3z = 0;
    #declare BoardVector4x = 3*separation;
    #declare BoardVector4z = 0;
    #declare Height123 = separation;
    #declare Height4 = 2*separation;
    #declare RotStart1 =-AT2;
    #declare RotEnd1 = -ATH;
    #declare RotStart2 = ATH;
    #declare RotEnd2 = -ATH;



    #macro PathPos(Alpha, Centerx, Centerz, Height, BoardVectorx, BoardVectorz)
      <Centerx+BoardVectorx*cos(Alpha), Height*sin(Alpha),
       Centerz+BoardVectorz*cos(Alpha)>
    #end

     // animated paths 1 and 2 rotate during animation but nothing else.
    #macro PathRot(NewClock, RotStart, RotEnd)
      y*(RotStart+NewClock*(RotEnd-RotStart))
    #end

     // all these definitions are for the sake of the #warning messages.

    #declare RotVec1 = RotStart1+NewClock123*(RotEnd1-RotStart1);
    #declare PosVec1x = Center1x+BoardVector1x*cos(Path123Alpha);
    #declare PosVec1y = Height123*sin(Path123Alpha);
    #declare PosVec1z = Center1z+BoardVector1z*cos(Path123Alpha);
    #declare RotVec2 = RotStart2+NewClock123*(RotEnd2-RotStart2);
    #declare PosVec2x = Center2x+BoardVector2x*cos(Path123Alpha);
    #declare PosVec2y = Height123*sin(Path123Alpha);
    #declare PosVec2z = Center2z+BoardVector2z*cos(Path123Alpha);
    #declare PosVec3x = Center3x+BoardVector3x*cos(Path123Alpha);
    #declare PosVec3y = Height123*sin(Path123Alpha);
    #declare PosVec3z = Center3z+BoardVector3z*cos(Path123Alpha);
    #declare PosVec4x = Center4x+BoardVector4x*cos(Path4Alpha);
    #declare PosVec4y = Height4*sin(Path4Alpha);
    #declare PosVec4z = Center4z+BoardVector4z*cos(Path4Alpha);

    #warning concat("NewClock123=",str(NewClock123,8,4),
                    " Path123Alpha=",str(Path123Alpha,8,4),"\n")
    #warning concat("piece 1 y*",str(RotVec1,7,4),
                    " <",str(PosVec1x,8,4),",",str(PosVec1y,8,4),",",
                    str(PosVec1z,8,4),">\n")
    #warning concat("NewClock4=",str(NewClock4,8,4),
                    " Path4Alpha=",str(Path4Alpha,8,4),"\n")
    #warning concat("piece 2 y*",str(RotVec2,7,4),
                    " <",str(PosVec2x,8,4),",",str(PosVec2y,8,4),",",
                    str(PosVec2z,8,4),">\n")
    #warning concat("piece 3 <",str(PosVec3x,8,4),",",str(PosVec3y,8,4),",",
                    str(PosVec3z,8,4),">\n")
    #warning concat("piece 4 <",str(PosVec4x,8,4),",",str(PosVec4y,8,4),",",
                    str(PosVec4z,8,4),">\n")

    // These object commands do not execute correctly,
    // but the above warning directives are displayed on the console.
    object { BlackLink rotate PathRot(NewClock123, RotStart1, RotEnd1)
             translate  PathPos(Path123Alpha, Center1x, Center1z, Height123,
                        BoardVector1x, BoardVector1z)
    }
    object { BlackLink rotate PathRot(NewClock123, RotStart2, RotEnd2)
             translate  PathPos(Path123Alpha, Center2x, Center2z, Height123,
                        BoardVector2x, BoardVector2z)
    }
    object { BlackLink rotate -AT2*y
             translate  PathPos(Path123Alpha, Center3x, Center3z, Height123,
                        BoardVector3x, BoardVector3z)
    }
    object { BlackPeg translate  PathPos(Path4Alpha, Center4x, Center4z,
                                 Height4, BoardVector4x, BoardVector4z)
    }
  #else                        // last interval is static
    object { BlackLink rotate -ATH*y translate Link12Pos(20, 4) }
    // calling macros from another file, but this only happens once.

    object { BlackLink rotate -ATH*y translate Link12Pos(21, 3) }
    object { BlackLink rotate -AT2*y translate Link34Pos(21, 3) }
    object { BlackPeg translate PegPos(22, 4) }
  #end
#end

// *********************************************************************

You should be able to access the other files at
https://drive.google.com/file/d/1CUqz-eivsopQLrQc4bHrbSw_E5fWUgB4/view?usp=sharing
and I also attach the zip file here.

Thanks for your attention!

[Cousin Ricky] Re: Unexpected select () results in both 3 and 4... [829 days 12 hours and 14 minutes ago]

Sat, 30 Dec 2023 19:08:22 GMT

On 2023-12/29 23:06 (-4), Bald Eagle wrote:
> "Tor Olav Kristensen" <tor### [at] TOBEREMOVEDgmailcom> wrote:
> 
>> But, but, but - you are using a "fractional loop iterator" also here.
> 
> UGGGGGGGGGGGGGGGGGGGGgggggggggggggggggggghhhhhhhhhhhhhhhhhhhhhh.
> 
> And I was just explaining floating point woes to the stepson the other day.
> 
> I think I need a plaque on my monitor that reads:
> 
> "THOU SHALT NOT USE FRACTIONS"
> 
> :(
> 
> I'll just multiply everything by 1/Step and hopefully that will get everything
> to work out.  What a PITA.

I see these FP glitches often enough that I will always endure that
PITA.  See for example macro ILight__Integrate() in:

https://github.com/CousinRicky/POV-IntegrateLight/blob/main/integratelight.inc

I view it as just a part of the game, like tuning a guitar, or
collimating a reflector telescope, or using my turn signal.

[Bald Eagle] Re: Unexpected select () results in both 3 and 4... [830 days 4 hours and 13 minutes ago]

Sat, 30 Dec 2023 03:10:00 GMT

"Tor Olav Kristensen" <tor### [at] TOBEREMOVEDgmailcom> wrote:

> But, but, but - you are using a "fractional loop iterator" also here.

UGGGGGGGGGGGGGGGGGGGGgggggggggggggggggggghhhhhhhhhhhhhhhhhhhhhh.

And I was just explaining floating point woes to the stepson the other day.

I think I need a plaque on my monitor that reads:

"THOU SHALT NOT USE FRACTIONS"

:(

I'll just multiply everything by 1/Step and hopefully that will get everything
to work out.  What a PITA.

Thanks, Tor.


- BW

[Tor Olav Kristensen] Re: Unexpected select () results in both 3 and 4... [830 days 5 hours and 13 minutes ago]

Sat, 30 Dec 2023 02:10:00 GMT

"Tor Olav Kristensen" <tor### [at] TOBEREMOVEDgmailcom> wrote:
> "Bald Eagle" <cre### [at] netscapenet> wrote:
> > So, I did some more testing, wrote a simple, standalone sample scene, and found
> > yet another curious set of circumstances.
> >
> > And it looks like probably what's happening is another case of floating point
> > math error, similar to what I experienced way back when trying to use fractional
> > loop iterators.
> >...
>
> But, but, but - you are using a "fractional loop iterator" also here.
> You are incrementing by a number; 0.05 = 5/100, that's not possible to write
> as a binary number with a finite length.
>
> 0.05 =
> 0*10^0+0*10^-1+5*10^-2 =
> 0*2^0+0*2^-1+0*2^-2+0*2^-3+0*2^-4+1*2^-5+1*2^-6*+0*2^-7+0*2^-8+1*2^-9+1*2^-10+...
>
> Try to use this step length instead:
>
> #declare Step = 0.0498046875; // = 1/2^-5 + 2^-6 + 2^-9 + 2^-10


Sorry. I meant to write this:

//  = 2^-5 + 2^-6 + 2^-9 + 2^-10


--
Tor Olav
http://subcube.com
https://github.com/t-o-k

[Tor Olav Kristensen] Re: Unexpected select () results in both 3 and 4... [830 days 5 hours and 48 minutes ago]

Sat, 30 Dec 2023 01:35:00 GMT

"Bald Eagle" <cre### [at] netscapenet> wrote:
> So, I did some more testing, wrote a simple, standalone sample scene, and found
> yet another curious set of circumstances.
>
> And it looks like probably what's happening is another case of floating point
> math error, similar to what I experienced way back when trying to use fractional
> loop iterators.
>...

But, but, but - you are using a "fractional loop iterator" also here.
You are incrementing by a number; 0.05 = 5/100, that's not possible to write
as a binary number with a finite length.

0.05 =
0*10^0+0*10^-1+5*10^-2 =
0*2^0+0*2^-1+0*2^-2+0*2^-3+0*2^-4+1*2^-5+1*2^-6*+0*2^-7+0*2^-8+1*2^-9+1*2^-10+...

Try to use this step length instead:

#declare Step = 0.0498046875; // = 1/2^-5 + 2^-6 + 2^-9 + 2^-10

--
Tor Olav
http://subcube.com
https://github.com/t-o-k

[William F Pokorny] Re: tuple-style assignment fails after including... [833 days 9 hours and 25 minutes ago]

Tue, 26 Dec 2023 21:57:52 GMT

On 12/26/23 15:43, Bald Eagle wrote:
> But then I commented out transforms.inc and everything worked fine, so then I
> copied the vtransform macro and pasted into the scene and ...
> 
> now the tuple-style assignment feature seems to be permanently broken.
ðŸ™
> 
> So there seems to be some persistent thing somewhere that gets triggered
> haphazardly - which are always the most fun bugs to track down and fix.

This is probably a case of the tuple related error messages not being 
that clear when the tuple / list / batch assignment types get mixed. I 
mentioned this somewhere else - maybe only a direct email to you, though?

I'm guessing you have written something like this:

#version 3.8;
#include "transforms.inc"
#declare Xfrm = transform {translate -z}
#declare (Vx,Vy) = vtransform(x, Xfrm);
...

If so, that last tuple assignment from the result of the vtransform 
macro (which returns a vector) needs to be something like:

#declare <Vx,Vy> = vtransform(x, Xfrm);

or

#declare <Vx,Vy,Vz> = vtransform(x, Xfrm); // all vector components

---
Aside:

Where still shipped in the core includes, the yuqk fork renamed all 
lower case macro names (and include compiled functions) with leading 
upper case characters to make clear what is a true inbuilt functionality 
and what is not. Official releases of POV-Ray have too many include 
coded things which 'look' like keywords that are not. So, yuqk's 
vtransform() is called VTransform(). This renaming also a step toward 
adding additional, true, inbuilt functions.

Further, the recommended vector transform macro in yuqk is called 
VectorTransform() which comes from Tor Olav Kristensen's vectors.inc 
which ships as a yuqk core include file.

Bill P.

[Bald Eagle] Re: tuple-style assignment fails after including... [833 days 10 hours and 38 minutes ago]

Tue, 26 Dec 2023 20:45:00 GMT

But then I commented out transforms.inc and everything worked fine, so then I
copied the vtransform macro and pasted into the scene and ...

now the tuple-style assignment feature seems to be permanently broken. :(

So there seems to be some persistent thing somewhere that gets triggered
haphazardly - which are always the most fun bugs to track down and fix.


- BW

[Bald Eagle] tuple-style assignment fails after including tra... [833 days 11 hours and 3 minutes ago]

Tue, 26 Dec 2023 20:20:00 GMT

Doodling a bit before work, and I need to find the position of a point after
rotating around an axis.

So I need to include transforms.inc to have use of vtransform, but then that
suddenly triggered a parse error of a macro I was using that exports its values
via a (N1, N2) tuple-style assignment.

I tried redeclaring the version after the inc file invocation, but (since this
happens upon exiting the inc file already) that didn't fix anything.

So this looks like a bug in source.

Perhaps someone can confirm and investigate.

(Also, many of these silly macros ought to be inbuilt functions in future
versions)

- BW

[William F Pokorny] Re: Is the following cutaway_textures bug common... [837 days 13 hours and 43 minutes ago]

Fri, 22 Dec 2023 17:39:22 GMT

On 12/22/23 08:29, Cousin Ricky wrote:
> I'm also using GNU/Linux, but for what it's worth, case 0110 halts in
> POV-Ray 3.5 and 3.6 with the message "Rendering Error: No textures in
> multi-texture CSG object."

Thanks! :-) I wondered what might be happening in earlier versions but 
was too lazy to run it.

I was considering adding a render time error to yuqk too as something 
better than what is happening. However, I believe I've worked out a 
relatively simple fix.

In the file csg.cpp and the function CSG::Determine_Textures, change the 
line:

     if (Type & CSG_DIFFERENCE_OBJECT)

to

     if ((Type & CSG_DIFFERENCE_OBJECT) &&
         (children[0]->Texture != nullptr))

This aligns the results with those of intersection{} where the first 
object in the difference has no texture - and we are using cutaway_textures.

I've also worked up some yuqk documentation which goes as far as my 
current understanding of cutaway_textures goes. I'll stick the top part 
of that documentation below.

Bill P.

---
cutaway_textures

A modifier used with intersection and difference to tweak texturing

The keyword can only be used with a difference{} or intersection{} block.

The cutaway_textures is specified with no arguments.

The cutaway_textures keyword is useful ONLY where more than one, but not 
all of the objects in an intersection{} or difference{} blocks have no 
texture and there is no texture specified in the parent intersection{} 
or difference{}.

The keyword can always be used in any difference{} or intersection{} 
block, but as a rule, never do this where the keyword is not useful as 
it triggers extra work during ray tracing / rendering.

---
Useful things to remember when trying to understand cutaway_textures 
results.
---

0) If none of the input objects have textures, the parser will assign 
the current default texture to everything and cutaway_textures will have 
no effect.  This action of the parser can occur during a chain of csg / 
object {} block wraps prior to the difference{} / intersection{} blocks. 
In other words, it helps to keep the inputs - especially the 'cutting 
shape' - simple when attempting to use cutaway_textures.

1) If all input objects have textures, cutaway_textures will have no effect.

2) If the difference{} or intersection{} blocks themselves have a 
texture specified, cutaway_textures will have no effect.

3) Where the inputs are simple single objects (sphere, cone, etc) and 
one or more of the inputs (as seen by the current ray) is not textured, 
but one of the inputs is, use of cutaway_textures will result in the 
copying of of the other input's texture. This can vary, if the input 
object's texture vary.

4) Where the inputs are multiple, simple objects as with a csg input the 
resulting texture from the 'cut' will be an average of all the textured 
components - as seen by the current ray and determined by inside object 
tests.  (Yes, cutaway_textures can get expensive)

5) During parsing and internal to POV-Ray the cutaway_textures keyword 
prevents the copying of the default texture, leaving the texture pointer 
set to nullptr.  It further sets a cutaway_textures flag on those shapes 
with no texture as well on the parent intersection{} or difference{}. At 
render time and for each ray interacting with components having the 
cutaway_textures flag and no texture, extra work gets done to determine 
a resulting texture.

6) The direct inputs being a union{} or merge{} makes no difference. 
Less sure about uses of merge{} in csg chains coming into the 
difference{} / intersection{} blocks.

7) What happens with nested difference{} and intersection{} blocks using 
cutaway_textures in other difference{} and intersection{} blocks also 
using cutaway_textures was not explored - and unsure what happens.

[Cousin Ricky] Re: Is the following cutaway_textures bug common... [837 days 17 hours and 53 minutes ago]

Fri, 22 Dec 2023 13:29:53 GMT

On 2023-12-18 11:16 (-4), William F Pokorny wrote:
> While continuing to think about yuqk / v4.0 texturing clean up /
> changes, I took a detailed look at cutaway_textures.
> 
> I'm pretty sure the 0110 difference case below should end up as 'Red
> Red'. The nullptr result for the pigment I see as a bug itself in any
> case - the pigment should end up set to something valid.
> 
> The behavior is identical v3.7-stable, v3.8 beta 2 and yuqk on linux.
> 
> Do windows users see the same bug?

I'm also using GNU/Linux, but for what it's worth, case 0110 halts in
POV-Ray 3.5 and 3.6 with the message "Rendering Error: No textures in
multi-texture CSG object."

[Bald Eagle] Re: Is the following cutaway_textures bug common... [839 days 19 hours and 13 minutes ago]

Wed, 20 Dec 2023 12:10:00 GMT

So, my waking brain was just meandering over this topic, and I was wondering:

We have the object pigment pattern feature, and we have cutaway_textures.

How difficult would it be to implement a sort of hybrid feature?

Consider I have a base object, and I want to "intersect" it with another object,
but not do a CSG - rather leave the "imprint" of the other object on its
surface.

I suppose this is the object pattern, but with a different, simpler syntax,
perhaps leveraging whatever existing algorithmic processes exist under the hood
for cutaway_textures.

If I were to start intersecting the base object with a loop of random spheres
with random pigments, then the final result would either be the average of all
the overlapping spheres' pigments on the surface of the base object, or the
last-intersected sphere's pigment would take precedence, sort of like a
z-buffer/painter's algorithm.

Just an idea to throw out there.

- BW

[Bald Eagle] Re: Is the following cutaway_textures bug common... [840 days 11 hours and 58 minutes ago]

Tue, 19 Dec 2023 19:25:00 GMT

"Kenneth" <kdw### [at] gmailcom> wrote:
> "Bald Eagle" <cre### [at] netscapenet> wrote:
> >
> > Yes, maybe if you reread that, you'll see where you don't understand their
> > point.
>
> I did. All the way through. Ugh. (Embarrassing, ha.) But in the 'present age', I
> now fully understand their point and where I was wrong. My basic assumption back
> then was...naive and rather uninformed :-\

I feel the same way when I read my posts going back to 2013.  <oof>
> Luckily, the UN-textured
> slicing object does not impose its own color on those surfaces...but will if
> given a 'specified' texture of its own.
>
> (I find it interesting-- and useful!-- that the un-textured object behaves this
> way, even though it does have a default texture applied 'behind-the-scenes'. Why
> it does not impose that on the cut surfaces is a mystery to me. But it's a happy
> circumstance!)

Well, if I had to speculate, it would be that there is a difference between a
primitive and an object.  We can define things as primitives, but the default
texture may not actually get assigned to them until we invoke them as visible
objects to be rendered in a scene, perhaps using object {}.

And honestly, I'd call the fact that a textured object can't be used as the
"cutter" without imparting its assigned texture to the intersection surface,
even when cutaway_textures is invoked, either a bug, or at least unexpected or
undesired behaviour.
So if I want to model a complex CSG object that I want to see in the scene, but
also use as a differencing cutter, I have to model it TWICE?
I would think that cutaway_textures should simply ignore all of the assigned
texturing of the cutter, since that's its conceptual function - to use the
textures of the cut object for the remaining surface, not those of the cutter.

> > One way to address the color selection would be to allow the optional
> > inclusion of a hierarchical index in the cutaway_textures call.   No index
> > averages the colors as is currently the default behaviour.  Supplying an
> > index allows the user to choose some texture in whatever texture
> > hierarchy that POV-Ray constructs, up to the max. So, if there are only 2,
> > and you supply 20, then it's texture #2.
>
> Ah yes-- and that would have been the solution to my old argument too!
> Well-explained, laddie.
>
> > I do very much like your suggestion of the partial contribution of the cutting
object's texture to the surface.  ..
. That would be useful indeed.
>
> That can be done even now. :-) It's part of my code test.

I copied and rendered the code, since The Naughty Walker didn't attach the scene
as a .pov file.  :P

> > And truly, I think it would be as simple as adding the cutting object's
> > texture into the averaged result.
>
> Exactly.

Wait, wha...?   We agree?
To quote Phil Collins, "There must be some misunderstanding...."  ;)

- BW

[William F Pokorny] Re: Is the following cutaway_textures bug common... [840 days 16 hours and 14 minutes ago]

Tue, 19 Dec 2023 15:08:54 GMT

On 12/19/23 03:32, Kenneth wrote:
> It's interesting that you should mention this topic.*Many*  years ago (2009), I
> had a 'discussion' in the newsgroups with long-time user Warp

Thanks for the pointer. I read through it. I'll say my up front concern 
isn't really the averaging(a,b,c) when it comes into play, but rather 
that with relatively simple test cases for the cutaway_textures I found 
bugs and instability in behavior depending on the kind of inputs given 
to the intersection{} and difference{} blocks. Maybe the 'bug' mentioned 
in that 2009 thread compared to v3.6 didn't get fixed - or didn't get 
fixed completely?

(a) - Relative to the specific averaged texture discussion in that 
thread, the yuqk fork introduced a list_object{} pattern for pretty much 
the situation discussed. It allows the user to specify a list of objects 
for a patterned / *_map texture in a last one wins order. In other 
words, the user selects which texture wins in overlapping regions.

(b) - The averaging method provides a way to generate a texture when 
there are object overlaps, but the result is clunky I think; as in not 
being actually useful except to provide 'some' texture result indicating 
overlapping regions. In what I've seen so far you get bits that are 
averaged and bits not, depending on overlaps. If all we are after is 
some special effect - like image transitions in an animation or 
something - the set up could be useful.

(c) - I still haven't unrolled completely how the averaging gets done in 
our code. What concerns me some is the inside tests. These are sometimes 
very expensive. Even fast ones will be costly if there are huge numbers 
of shapes in the input CSG objects to the intersection / difference 
(really a modified intersection).

Anyhow, see the image and yuqk scene file(d) for the list_object{} 
pattern approach as a cutaway_textures alternative - one also with 
limitations.

(d) - I played very briefly with cutaway_textures in this file too and 
it seemed like the behavior was different yet again (ignored sometimes 
where not previous...?), but I didn't dig into it.

Bill P.

[Kenneth] Re: Is the following cutaway_textures bug common... [840 days 16 hours and 43 minutes ago]

Tue, 19 Dec 2023 14:40:00 GMT

"Kenneth" <kdw### [at] gmailcom> wrote:
> "Bald Eagle" <cre### [at] netscapenet> wrote:
> >
> > I do very much like your suggestion of the partial contribution of the
> > cutting
> > object's texture to the surface.  Like adding a bit of f or t in the cutting
> > object's texture to act as a filter to view the final surface through to
> > the final cutaway_texture result, or applying a faint amount of dye in the
> > cutter to tint the surface.   That would be useful indeed.
>
> That can be done even now. :-) It's part of my code test.
>
{snip]
> // When a partially-transparent texture is applied:
> //          1) with cutaway_textures missing, it's hard to tell what happens--
> //             perhaps the look is partially 'hollow' and partially non-
//               hollow,
> //             with the texture's color partially applied to the half-visible
> //             slicing walls. But no 'averaging' of the original objects'
> //             colors occurs.

Hmm, it does not work like I thought, for the reason given. The interiors of the
many objects ARE partially visible, as is the partially-transparent slicing
surface. A mix of the two.

[Kenneth] Re: Is the following cutaway_textures bug common... [840 days 16 hours and 58 minutes ago]

Tue, 19 Dec 2023 14:25:00 GMT

"Bald Eagle" <cre### [at] netscapenet> wrote:
>
> Yes, maybe if you reread that, you'll see where you don't understand their
> point.

I did. All the way through. Ugh. (Embarrassing, ha.) But in the 'present age', I
now fully understand their point and where I was wrong. My basic assumption back
then was...naive and rather uninformed :-\

William's comments about cutaway_textures induced me to go back to an *old* test
file I made at the time, and update it... while discovering some additional
interesting things. I've included that scene below, with updated comments. The
various code pieces are worth playing around with, to see what happens.

Some salient points:
Cutaway_textures can only be used in a 'difference' or 'intersection', and both
behave the same way regarding it.

Given a complex CSG object with lots of overlapping parts and overlapping
individual textures/colors: When cutaway_textures is used as the final step, the
colors end up being 'averaged' at the surface(s) when the overall object is
sliced into with a difference or intersection. (This assumes that the slicing
object has NO specifically-applied texture of its own, which is an important
point.) The averaging makes sense, because at present there is no way for
POV-ray to know *which* of the overlapped/nested objects should contribute its
own 'pure' color at that surface; the big slicing surface may intersect any
number of differently-colored and overlapping objects. Luckily, the UN-textured
slicing object does not impose its own color on those surfaces...but will if
given a 'specified' texture of its own.

(I find it interesting-- and useful!-- that the un-textured object behaves this
way, even though it does have a default texture applied 'behind-the-scenes'. Why
it does not impose that on the cut surfaces is a mystery to me. But it's a happy
circumstance!)
>
> One way to address the color selection would be to allow the optional
> inclusion of a hierarchical index in the cutaway_textures call.   No index
> averages the colors as is currently the default behaviour.  Supplying an
> index allows the user to choose some texture in whatever texture
> hierarchy that POV-Ray constructs, up to the max. So, if there are only 2,
> and you supply 20, then it's texture #2.

Ah yes-- and that would have been the solution to my old argument too!
Well-explained, laddie.

> I do very much like your suggestion of the partial contribution of the cutting
> object's texture to the surface.  Like adding a bit of f or t in the cutting
> object's texture to act as a filter to view the final surface through to
> the final cutaway_texture result, or applying a faint amount of dye in the
> cutter to tint the surface.   That would be useful indeed.

That can be done even now. :-) It's part of my code test.
>
> And truly, I think it would be as simple as adding the cutting object's
> texture into the averaged result.

Exactly.

--------------
#version 3.8;
global_settings{assumed_gamma 1.0 max_trace_level 40}
#default{finish{ambient .05 emission 0 diffuse .85}}

camera {
  perspective
  location  <1, 2, -5>
  look_at   <0, -.3,  0>
  right x*image_width/image_height
  angle 40
}

// It is difficult to arrange the lighting here, to show the various
// results well.

light_source {
  0*x
  color rgb .6
  translate <-10, 15, -30>
}

light_source {
  0*x
  color rgb <1,1,1>*.33
  translate <20, -10, -40>
}

light_source {
  0*x
  color rgb <1,1,1>*.63
  translate <40, 20, 0>
}

background{rgb .1}

#declare S1 = seed(3); // for the objects' colors -- try 12 and 25 too
#declare S2 = seed(10); //for object creation and placement-- try 5, 6,
// and 10 too
#declare counter = 1;

difference{ // difference. For the cutaway box at end. But try intersection
// instead.
 union{ // try merge instead
 #while(counter <= 10)
 box{0,1 translate -.5
  texture{
   pigment{color srgb <rand(S1),rand(S1),rand(S1)>}
         }
  // an experiment...
  interior_texture{ pigment{bozo scale .15}}

  translate 1.3*<rand(S2) - .5,rand(S2) - .5,rand(S2) - .5>
    }

 cylinder{-1.8*x,1.8*x,.08
  texture{
   pigment{color srgb <rand(S1), rand(S1), rand(S1)>}
    }

  // an experiment...
  interior_texture{ pigment{gradient x frequency 20}}

  translate 1.5*<0,1.3*(rand(S2) - .5),rand(S2) - .5 -.1>
    }
 #declare counter = counter + 1;
 #end
  rotate 30*y
 } // end of merge

// === The cutting object ===... with NO applied texture, OR with various
// others. Assuming that a DIFFERENCE is used above:
// When NO initial texture is applied here:
//          1) with cutaway_textures missing, this
//             box applies its default WHITE color to the cut surfaces
//             (it used to be black when I originally wrote this code in 2009
//             in an older version of POV-ray.)
//          2) With cutaway_textures APPLIED, all of the original object
//             textures get blended or averaged together.
// When a totally *transparent* texture is applied below:
//          1) with cutaway textures missing, you can see INSIDE the many
//             cutaway objects as HOLLOW with thin walls, with all of the
//             objects' original colors NON-averaged. The COLOR of the
//             transparent texture is not used either.
//             HOWEVER, if the original objects have an inside_texture,
//             *that* texture shows up on the inside surfaces.
//             Good for cutaway diagrams!
//          2) With cutaway_textures applied, it has no visual effect; same
//             as if not applied.
// When a partially-transparent texture is applied:
//          1) with cutaway_textures missing, it's hard to tell what happens--
//             perhaps the look is partially 'hollow' and partially non-hollow,
//             with the texture's color partially applied to the half-visible
//             slicing walls. But no 'averaging' of the original objects'
//             colors occurs.
//          2) with cutaway textures applied, no difference; same as if not
//             applied.

// The differenced box:
box {0,2
 // optional, for experimentation...
 //texture{pigment {color srgbt <0,1,0,1>}} // fully transparent
 // OR, another optional experiment...
 //texture{pigment{srgb 1}}
 // AND/OR, another optional experiment...
 //texture{pigment{srgbt <1,.1,1,.6>}} // partially transparent

 /*
 // and/or a third experiment...it does not seem to show up...
 interior_texture{ // NEEDS a specified regular texture first--
                          // otherwise fatal parse error: "interior_texture
                          // requires an exterior texture"
  pigment{
   gradient y frequency frame_number
    color_map{
     [.5 srgb <0,0,1>]
     [.5 srgb <1,1,0>]
        }
    }
  finish{ambient .4 emission 0 diffuse .6}

       }
 */
  rotate 45*y
  translate <-1.4,-.4,-1.2>
  }  // end of box

 cutaway_textures
 //rotate 180*y
}

[Bald Eagle] Re: Is the following cutaway_textures bug common... [840 days 19 hours and 33 minutes ago]

Tue, 19 Dec 2023 11:50:00 GMT

"Kenneth" <kdw### [at] gmailcom> wrote:
 https://news.povray.org/povray.newusers/thread/%3Cweb.4a13ff1fd9818dbeab6e42900%40news.povray.org%3E/?mtop=310905
>
> Maybe there is a germ of an idea somewhere in that discussion that will be of
> use.

Yes, maybe if you reread that, you'll see where you don't understand their
point.

I don't exactly understand clipka's example but...

One way to address the color selection would be to allow the optional inclusion
of a hierarchical index in the cutaway_textures call.   No index averages the
colors as is currently the default behaviour.  Supplying an index allows the
user to choose some texture in whatever texture hierarchy that POV-Ray
constructs, up to the max.   So, if there are only 2, and you supply 20, then
it's texture #2.

Thinking about clipka's point about other software packages, I suppose it would
be useful to have a macro called Union () that differences away one object from
another before creating a union {} of them, thereby conveniently eliminating the
problem in the first place.

I do very much like your suggestion of the partial contribution of the cutting
object's texture to the surface.  Like adding a bit of f or t in the cutting
object's texture to act as a filter to view the final surface through to modify
the final cutaway_texture result, or applying a faint amount of dye in the
cutter to tint the surface.   That would be useful indeed.

And truly, I think it would be as simple as adding the cutting object's texture
into the averaged result.  Since enabling that would require a flag of some
sort, and a source-rewrite / new keyword or optional auxiliary keyword (like
sturm), then you would just supply a weighting for the cutting object's
contribution to the average.

(And this is written knowingly full well what "just" entails  ;) )

- BW

[Kenneth] Re: Is the following cutaway_textures bug common... [840 days 22 hours and 48 minutes ago]

Tue, 19 Dec 2023 08:35:00 GMT

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

> There is this bit too in the documentation which I don't currently see
> any code for:
>
> "If the parent object is a CSG of objects with different textures, then
> the textures on overlapping parts will be averaged together."
>
> but maybe somehow 'averaging' happens... The test case in this thread
> isn't set up to trigger it. Guess, I'll need to create more complex
> cases. My guess at the moment is we'll get, not 'averaging', but
> multiple individual textures (including any texture lists) from the
> parent's component parts.
>

It's interesting that you should mention this topic. *Many* years ago (2009), I
had a 'discussion' in the newsgroups with long-time user Warp-- actually an
argument :-( -- as to what we *should* see when using cutaway_textures re:
'averaging'. Even Clipka chimed in, in a more reasonable way. I don't recall my
exact thinking or frame of mind at the time, but I'm sure that I made some
logical errors in my side of the argument. (Warp and I had a sort of
antagonistic approach to one another at the time, but he is a very smart guy,
with a sharp mind. I haven't seen him in the newsgroups for years, sadly.)
Anyway, here it is...warts and all...

https://news.povray.org/povray.newusers/thread/%3Cweb.4a13ff1fd9818dbeab6e42900%40news.povray.org%3E/?mtop=310905

Maybe there is a germ of an idea somewhere in that discussion that will be of
use.

FWIW, I am currently using the cutaway_textures feature in my long-overdue
object-slicing-to-3D-printing scheme (via the 3D SLICER CT-scan app)... and I
*still* had to experiment with it to find the best approach.

[William F Pokorny] Re: Is the following cutaway_textures bug common... [841 days 9 hours and 27 minutes ago]

Mon, 18 Dec 2023 21:55:26 GMT

On 12/18/23 14:53, William F Pokorny wrote:
> I'll dig a more into the code - really not much of it in truth. There is 
> a dynamic_cast used in one of the conditional test which is why I wanted 
> to be sure windows binaries behaved the same way.
> 
> ---
> There is this bit too in the documentation which I don't currently see 
> any code for:
> 
> "If the parent object is a CSG of objects with different textures, then 
> the textures on overlapping parts will be averaged together."
> 
> but maybe somehow 'averaging' happens... The test case in this thread 
> isn't set up to trigger it. Guess, I'll need to create more complex 
> cases. My guess at the moment is we'll get, not 'averaging', but 
> multiple individual textures (including any texture lists) from the 
> parent's component parts.

Using more or less the same set up, but with union{}s in the 
intersection and difference.

With cutaway_textures where the intersection{} and difference{} blocks 
themselves don't have textures, the results are different than when the 
input is not the CSG union. :-(

And in the difference case I now do see some sort of 'maybe averaging' 
happening though I'm unsure of what textures/texture-components; nor do 
I have a clue how it's happening internal to POV-Ray at the moment.

The testing combinations explode in number from here :-(


I wonder if I can make intersections and differences using 
cutaway_textures without a dedicated block texture illegal in yuqk and 
just walk away carrying my bag of blissful ignorance...

Bill P.


Intersection                    | Difference
------------                    | ------------
                                 |
        CSG       CSG            |        CSG       CSG
BCRG   Surface   Surface        | BCRG   Surface   Surface
-----|---------|----------|---| | -----|---------|----------|---|
0000   DfltPig   DfltPig    =   | 0000   DfltPig   DfltPig    = ==
0001   Green     DfltPig    =   | 0001   Green     DfltPig    = ==
0010   DfltPig   Red        =   | 0010   DfltPig   Red        = ==
0011   Green     Red        =   | 0011   Green     Red        = ==
0100   DfltPig   DfltPig    =   | 0100   DfltPig   DfltPig    = ==
0101   Green     DfltPig    .   | 0101   Green     Gre+Ave    . ??
0110   DfltPig   Red        =   | 0110   DfltPig   Red        = ??
0111   Green     Red        =   | 0111   Green     Red        = ==
1000   Blue      Blue       =   | 1000   Blue      Blue       = ==
1001   Green     Blue       =   | 1001   Green     Blue       = ==
1010   Blue      Red        =   | 1010   Blue      Red        = ==
1011   Green     Red        =   | 1011   Green     Red        = ==
1100   Blue      Blue       =   | 1100   Blue      Blue       = ==
1101   Green     Blue       =   | 1101   Green     Blue       = ==
1110   Blue      Red        =   | 1110   Blue      Red        = ==
1111   Green     Red        =   | 1111   Green     Red        = ==

(*) - The Red, Green and Blue in the table above are really similar 
unique colors for each element of the union{}s.

[Bald Eagle] Re: Is the following cutaway_textures bug common... [841 days 10 hours and 3 minutes ago]

Mon, 18 Dec 2023 21:20:00 GMT

Thanks for looking into this part of the code.  I've always run into problems
when trying to use it, and never ferreted out what the source of the problem
was.

Running some experiments to test your yuqk fork would give some good reference
SDL to look at.

https://news.povray.org/povray.bugreports/thread/%3Cweb.5e3385d55a7390894eec112d0%40news.povray.org%3E/

I'm switching to a new position at work, and need to leave in 15 min for
training.
Hopefully that all goes smoothly.

- BW

[William F Pokorny] Re: Is the following cutaway_textures bug common... [841 days 11 hours and 30 minutes ago]

Mon, 18 Dec 2023 19:53:06 GMT

On 12/18/23 13:51, Kenneth wrote:
> I also get the same result in v3.7.0.
> 
Thank you Kenneth! :-) Results are the same.

I'll dig a more into the code - really not much of it in truth. There is 
a dynamic_cast used in one of the conditional test which is why I wanted 
to be sure windows binaries behaved the same way.

---
There is this bit too in the documentation which I don't currently see 
any code for:

"If the parent object is a CSG of objects with different textures, then 
the textures on overlapping parts will be averaged together."

but maybe somehow 'averaging' happens... The test case in this thread 
isn't set up to trigger it. Guess, I'll need to create more complex 
cases. My guess at the moment is we'll get, not 'averaging', but 
multiple individual textures (including any texture lists) from the 
parent's component parts.

Bill P.

[Kenneth] Re: Is the following cutaway_textures bug common... [841 days 12 hours and 28 minutes ago]

Mon, 18 Dec 2023 18:55:00 GMT

I also get the same result in v3.7.0.

[Kenneth] Re: Is the following cutaway_textures bug common... [841 days 12 hours and 43 minutes ago]

Mon, 18 Dec 2023 18:40:00 GMT

> and to see the bug this bit should be:
>
>     #declare G =    0;
>     #declare R =   1;
>     #declare C =  1;
>     #declare B = 0;

In Windows 10, running v3.8 beta 1--

Using your 0110 suggestion, the RED shows up on the cutaway surfaces.

[William F Pokorny] Re: Is the following cutaway_textures bug common... [841 days 15 hours and 42 minutes ago]

Mon, 18 Dec 2023 15:40:27 GMT

On 12/18/23 10:16, William F Pokorny wrote:
> Do windows users see the same bug?

Sorry, the top part of the scene was missing.

     #version 3.8;
     global_settings {
         assumed_gamma 1 }
     #declare Grey50 = srgb <0.5,0.5,0.5>;
     background { Grey50 }
     #declare Camera00 = camera {
         perspective
         location <3,3,-3.001>
         sky y
         angle 35
         right x*(image_width/image_height)
         look_at <0,0,0>
     }
     #declare Red = srgb <1,0,0>;
     #declare Green = srgb <0,1,0>;
     #declare Blue = srgb <0,0,1>;
     #declare White = srgb <1,1,1>;
     #declare Light00 = light_source { <50,150,-250>, White }
     default { pigment { rgb <1,1,0> } }
     camera { Camera00 }
     light_source { Light00 }

and to see the bug this bit should be:

     #declare G =    0;
     #declare R =   1;
     #declare C =  1;
     #declare B = 0;


Bill P.

[William F Pokorny] Is the following cutaway_textures bug commonly u... [841 days 16 hours and 6 minutes ago]

Mon, 18 Dec 2023 15:16:39 GMT

While continuing to think about yuqk / v4.0 texturing clean up / 
changes, I took a detailed look at cutaway_textures.

I'm pretty sure the 0110 difference case below should end up as 'Red 
Red'. The nullptr result for the pigment I see as a bug itself in any 
case - the pigment should end up set to something valid.

The behavior is identical v3.7-stable, v3.8 beta 2 and yuqk on linux.

Do windows users see the same bug?

Bill P.

//...
default { pigment { rgb <1,1,0> } }
#declare Sph00 = sphere { 0, 0.5 }
#declare Cyl00 = cylinder { -1*y, 1*y, 0.50 }

#declare G =    0;
#declare R =   0;
#declare C =  0;
#declare B = 0;

#declare I00 = intersection {
     object { Sph00
         #if (G) pigment { Green } #end
     }
     object { Cyl00 translate +0.25*z
         #if (R) pigment { Red }   #end
     }
     #if (C) cutaway_textures #end
     #if (B) pigment { Blue } #end
}

#declare D00 = difference {
     object { Sph00
         #if (G) pigment { Green } #end
     }
     object { Cyl00 translate -0.5*z
         #if (R) pigment { Red }   #end
     }
     #if (C) cutaway_textures #end
     #if (B) pigment { Blue } #end
}

object { I00 translate -0.6*x }
object { D00 translate +0.6*x }
//...

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

Default texture's pigment (DfltPig).

Intersection                    | Difference
------------                    | ------------
                                 |
        Sphere    Cylinder       |        Sphere    Cylinder
BCRG   Surface   Surface        | BCRG   Surface   Surface
-----|---------|----------|---| | -----|---------|----------|---|
0000   DfltPig   DfltPig    =   | 0000   DfltPig   DfltPig    =
0001   Green     DfltPig    =   | 0001   Green     DfltPig    =
0010   DfltPig   Red        =   | 0010   DfltPig   Red        =
0011   Green     Red        =   | 0011   Green     Red        =
0100   DfltPig   DfltPig    =   | 0100   DfltPig   DfltPig    =
0101   Green     Green      =   | 0101   Green     Green      =
0110   Red       Red        .   | 0110   Nullptr   Red        ?
0111   Green     Red        =   | 0111   Green     Red        =
1000   Blue      Blue       =   | 1000   Blue      Blue       =
1001   Green     Blue       =   | 1001   Green     Blue       =
1010   Blue      Red        =   | 1010   Blue      Red        =
1011   Green     Red        =   | 1011   Green     Red        =
1100   Blue      Blue       =   | 1100   Blue      Blue       =
1101   Green     Blue       =   | 1101   Green     Blue       =
1110   Blue      Red        =   | 1110   Blue      Red        =
1111   Green     Red        =   | 1111   Green     Red        =

[Kenneth] Re: Open file on failed render [842 days 23 hours and 13 minutes ago]

Sun, 17 Dec 2023 08:10:00 GMT

I forgot to ask: Can you reproduce the problem and the steps that caused it? (if
you haven't already trashed the bad ttf file)

[Kenneth] Re: Open file on failed render [842 days 23 hours and 43 minutes ago]

Sun, 17 Dec 2023 07:40:00 GMT

I sometimes see that behavior in other image-processing apps I have; I don't
think it's exclusive to POV-ray. I can't give specifics because it happens only
rarely, when I have two apps open that share a resource like an image-- or at
one point did-- and when both apps are still open and I try to delete something.
I don't remember exactly what I do each time to fix the situation; probably
shutting down one of the apps(?). Sorry that I can't be more helpful.

Are you sure that you need to close out all your active POV-ray scenes to solve
it? I have *multitudes* of scenes always loaded when I start the program-- 3.8
beta 1 on Windows-- and I've never had to resort to that drastic solution.

[Bald Eagle] Open file on failed render [845 days 6 hours and 3 minutes ago]

Fri, 15 Dec 2023 01:20:00 GMT

I have a corrupted ttf file that I tried to use in a scene, and after the render
failed, went to delete it.

"The action can't be completed because the file is open in POV-Ray for Windows
v3.8-beta"

Perhaps make a note that all files need to be closed before exiting the
parser.Maybe I'll keep the file to the side, to run an experiment to see if I
can open a fresh scene and close the open file by name from there - without
having to close POV-Ray and then open it again.

- BW

[Kenneth] Re: one source, two images [868 days 12 hours and 13 minutes ago]

Tue, 21 Nov 2023 19:10:00 GMT

Cousin Ricky <ric### [at] yahoocom> wrote:
>
> This is a montage of renders of the scene with the POV-Ray versions that
> I have, plus 3 versions of UberPOV along the bottom row.  From these, it
> appears that the bug was introduced prior to the release candidate phase
> of 3.7.1, but after whichever version of 3.7.1 that the latest UberPOV
> was based on.

I like the black one best (hee hee). That one must be from POV-ray
version -001...

William, I hope you feel better soon! Having the flu is no fun.

[Cousin Ricky] Re: one source, two images [870 days 6 hours and 23 minutes ago]

Mon, 20 Nov 2023 00:59:24 GMT

On 2023-11-19 03:15 (-4), William F Pokorny wrote:
> 
> My vague recollection is that some time during v3.71->v3.8 development a
> typo was introduced somewhere in the class set up for the spiral 1 & 2
> patterns. We ended up with two spiral1(s) or two spiral2(s) instead of
> one of each - or something similar to that. Likely in pattern.h or
> pattern.cpp or both.

This is a montage of renders of the scene with the POV-Ray versions that
I have, plus 3 versions of UberPOV along the bottom row.  From these, it
appears that the bug was introduced prior to the release candidate phase
of 3.7.1, but after whichever version of 3.7.1 that the latest UberPOV
was based on.

[jr] Re: one source, two images [870 days 19 hours and 38 minutes ago]

Sun, 19 Nov 2023 11:45:00 GMT

hi,

William F Pokorny <ano### [at] anonymousorg> wrote:
> ...
> I'm fighting a northern hemisphere cold/flu/bug at the moment so I don't
> feel like doing any more rooting around.

perhaps I ought to have tried to render a "get well soon" card :-), best wishes.


regards, jr.

[William F Pokorny] Re: one source, two images [871 days and 7 minutes ago]

Sun, 19 Nov 2023 07:15:46 GMT

On 11/18/23 11:50, jr wrote:
> hi,
> 
> when rendering WFP's "op art" scene[*] from 2014, I get different images,
> depending whether I use a "stock" POV-Ray (3.8, both alpha and beta.2), or WFP's
> own (6e4ed6c2), see attached.
> 
> [*] <https://news.povray.org/53b35d39%40news.povray.org>
> 
> regards, jr.

Hi.

v3.7 renders the bottom version too.

My vague recollection is that some time during v3.71->v3.8 development a 
typo was introduced somewhere in the class set up for the spiral 1 & 2 
patterns. We ended up with two spiral1(s) or two spiral2(s) instead of 
one of each - or something similar to that. Likely in pattern.h or 
pattern.cpp or both.

I thought I'd mentioned it somewhere out here in the news groups, but 
looks like I did not add the fix to any of my commit messages - so maybe 
not.  I was just something I saw while working on other issues.

I'm fighting a northern hemisphere cold/flu/bug at the moment so I don't 
feel like doing any more rooting around.

Bill P.

[jr] Re: one source, two images [871 days and 23 minutes ago]

Sun, 19 Nov 2023 07:00:00 GMT

"jr" <cre### [at] gmailcom> wrote:
> when rendering WFP's "op art" scene[*] from 2014, I get different images,
> depending whether I use a "stock" POV-Ray (3.8, both alpha and beta.2), or WFP's
> own (6e4ed6c2), see attached.

version 3.7.0.8 works as intended, from 3.7.1-rc.1 the results/images differ.

[jr] one source, two images [871 days 14 hours and 28 minutes ago]

Sat, 18 Nov 2023 16:55:00 GMT

hi,

when rendering WFP's "op art" scene[*] from 2014, I get different images,
depending whether I use a "stock" POV-Ray (3.8, both alpha and beta.2), or WFP's
own (6e4ed6c2), see attached.

[*] <https://news.povray.org/53b35d39%40news.povray.org>

regards, jr.

[Bald Eagle] Unexpected select () results in both 3 and 4 arg... [881 days 7 hours and 43 minutes ago]

Wed, 8 Nov 2023 23:40:00 GMT

So, I did some more testing, wrote a simple, standalone sample scene, and found
yet another curious set of circumstances.

And it looks like probably what's happening is another case of floating point
math error, similar to what I experienced way back when trying to use fractional
loop iterators.

Sometimes the 4-value version works (as expected), and sometimes it doesn't.

Always a headache, with the simplest things.

- BW



#version 3.8;
global_settings {assumed_gamma 1}
default {finish {diffuse 1}}


#declare E = 0.001;

#declare Zoom = 700;
camera {
 orthographic
 location <0.5, 0.5, -50>
 right x*image_width/Zoom
 up y*image_height/Zoom
 look_at <0.5, 0.5, 0>
 rotate y*0
}

sky_sphere {pigment {rgb 0}}

light_source {<1, 1, -10> rgb 1}

#declare LW = 0.01;
#declare f_XLines = function {pigment {gradient y scale 0.1}}
#declare XLines = function {select (f_XLines (x, y, z).red-LW, 1, 0)}
#declare f_YLines = function {pigment {gradient x scale 0.1}}
#declare YLines = function {select (f_YLines (x, y, z).red-LW, 1, 0)}
#declare Grid = function {XLines (x, y, z) + YLines (x, y, z)}

box {0, 1+E pigment {function {Grid (x, y, z)}} }



#declare Select3 = function (N) {
 select (N*10-2, 0.1,
  select (N*10-5, 0.4,
   select (N*10-7, 0.6,
    0.9
   )
  )
 )
}

// In this version, when N-Val = 0 --- when N=Val,
// then the repeated value, argument B, should get returned.
#declare Select4 = function (N) {
 select (N-0.2, 0.1, 0.1,
  select (N-0.5, 0.4, 0.4,
   select (N-0.7, 0.6, 0.6,
    0.9
   )
  )
 )
}

#declare Line = 0.0015;

#declare Step = 0.05;
union {
  #for (X, 0, 1, Step)

   #local Y = Select3 (X);

   #debug concat( "X = ", str(X, 0, 3),  " Y = ", str(Y, 0, 3), "\n")

   #local Current = <X, Y, 0>;
   sphere {Current Line}
   #if (X > 0)
    cylinder {Last, Current, Line}
   #end
   #local Last = Current;
  #end

 pigment {rgb x}
}

#debug "\n===========================================\n"

union {
  #for (X, 0, 1, Step)

   #local Y = Select4 (X);

   #debug concat( "X = ", str(X, 0, 3),  " Y = ", str(Y, 0, 3), "\n")

   #local Current = <X, Y, 0>;
   sphere {Current Line}
   #if (X > 0)
    cylinder {Last, Current, Line}
   #end
   #local Last = Current;
  #end

 pigment {rgb z}
}

[ingo] Re: Can't #undef a dict item that contains an ar... [1018 days 3 hours and 48 minutes ago]

Sun, 25 Jun 2023 03:35:00 GMT

This works around it:

#declare D["Arr"]=""
#undef D["Arr"]

ingo

[ingo] Re: Can't #undef a dict item that contains an ar... [1018 days 14 hours and 23 minutes ago]

Sat, 24 Jun 2023 17:00:00 GMT

"jr" <cre### [at] gmailcom> wrote:
> I think that may be to do with not being allowed to address "a slice" of an
> array, eg.
>   #undef D["Arr"][0]
>   #undef D["Arr"][1]
> and
>   #undef D["Dict"]["1"]
>
> work "as advertised".
>

Thanks, yes, I had figured that out, but am not happy with it.

#undef D["Arr"][0]
#undef D["Arr"][1]
#ifdef(D["Arr"])
  #debug "D_Arr\n"
#end

This prints "D_arr", so D["Arr"] isn't gone, it's just empty. Don't know how
harmful it is, if at all?

Thanks,
ingo

[jr] Re: Can't #undef a dict item that contains an ar... [1018 days 17 hours and 33 minutes ago]

Sat, 24 Jun 2023 13:50:00 GMT

hi,

"ingo" <nomail@nomail> wrote:
> ---%<------%<------%<---
> #version 3.8;
>
> #declare D = dictionary{
>   ["test"]:"test",
>   ["Arr"]: array{1,2},
>   ["Dict"]: dictionary{["1"]:1}  //parse error: Tried to free undefined symbol
> } ;
>
> #undef D["test"]
>
> #undef D["Arr"] //parse error: Tried to free undefined symbol
>
> #undef D["Dict"] //parse error: Tried to free undefined symbol
>
> ---%<------%<------%<---
>
> Win11, Persistence of Vision(tm) Ray Tracer Version
> 3.8.0-beta.2+gh7.msvc14.win64

I think that may be to do with not being allowed to address "a slice" of an
array, eg.
  #undef D["Arr"][0]
  #undef D["Arr"][1]
and
  #undef D["Dict"]["1"]

work "as advertised".


regards, jr.

[ingo] Can't #undef a dict item that contains an array ... [1018 days 18 hours and 13 minutes ago]

Sat, 24 Jun 2023 13:10:00 GMT

---%<------%<------%<---
#version 3.8;

#declare D = dictionary{
  ["test"]:"test",
  ["Arr"]: array{1,2},
  ["Dict"]: dictionary{["1"]:1}  //parse error: Tried to free undefined symbol
} ;

#undef D["test"]

#undef D["Arr"] //parse error: Tried to free undefined symbol

#undef D["Dict"] //parse error: Tried to free undefined symbol

---%<------%<------%<---

Win11, Persistence of Vision(tm) Ray Tracer Version
3.8.0-beta.2+gh7.msvc14.win64

ingo

[Cousin Ricky] Re: Macro parameters with the same name [1049 days 9 hours and 46 minutes ago]

Wed, 24 May 2023 21:37:16 GMT

On 2023-05-23 07:08 (-4), Bald Eagle wrote:
> OK - I see it now.
> 
> I was thinking in terms of the macro CALL, not the macro "constructor".
> 
> So yeah, what you're saying now makes a lot more sense.

Yes, of course the *caller* should be able to reuse the name as often as
desired, no warnings necessary.

[William F Pokorny] Re: Macro parameters with the same name [1050 days 18 hours and 45 minutes ago]

Tue, 23 May 2023 12:37:27 GMT

On 5/23/23 00:50, Cousin Ricky wrote:
> As it turns out, POV-Ray appears to choose the latter instance.
> Arbitrarily.  It could have been the other way around.  It could have
> been random.  Maybe it*is*  random, and I just haven't done enough test
> cases.

In a look at three other languages...

C/C++ (gcc/g++ 11.3.0)considers the duplicate parameter names/ids to be 
an error. As does python3 (3.10.6).

The scripting languages tcl (8.6) allows the duplication and it appears 
the first setting of the repeated name/id always wins.

In POV-Ray SDL I think the last setting of the parameter will always win 
because POV-Ray maintains symbol tables (key -> value hash tables) so 
the last time the symbol is set in the current scope is what the value 
is thereafter.

If allowing duplicate parameters, I think POV-Ray's last value wins 
method more intuitive as inside macros / functions we can always update 
the local variable(a). These within code body/block overrides are always 
the last setting wins so it sort of makes sense the last time a 
duplicated parameter name is set should win out too.

I lean toward the duplication of parameter names being an error. I think 
duplicates are far more likely to cause confusion than help.

Bill P.

(a) excepting where languages support constant parameters/variables and 
the feature used.

[William F Pokorny] Re: pov 3.7 array and for strangeness [1050 days 20 hours ago]

Tue, 23 May 2023 11:22:29 GMT

On 5/14/23 17:16, Leroy wrote:
> So I tried this.
> 
>     #local Tc=Image_Width * Image_Height;
>     #for(a,0,Tc)//--- notice the change------
>      #write (Mfile,uint8 Image[a])// The image array still contain Integers<256
>     #end
> POV didn't crash !?  And the image worked!!

I don't know why you see what you do.

In some quick tests on linux the parser always stops with an error once 
the array subscript goes out of range on the very last 'for loop' step. 
And I don't have problems with the larger array.

A wild guess is maybe the file handle (Mfile) isn't always getting 
closed in the SDL and the file buffering or render completion handling 
for open file handles not explicitly closed is in some way different on 
windows? It's a wild guess that I don't think the likely.

Bill P.

[Bald Eagle] Re: Macro parameters with the same name [1050 days 20 hours and 13 minutes ago]

Tue, 23 May 2023 11:10:00 GMT

OK - I see it now.

I was thinking in terms of the macro CALL, not the macro "constructor".

So yeah, what you're saying now makes a lot more sense.

I can still see where someone may have some reason to want to do it that way,
especially if the second argument is an optional one, but I don't write computer
languages or parsers...

I will say that it's like a second camera in a scene, so there's still the
potential to issue a "duplicate argument found in macro declaration - ignoring
previous instance"   kind of warning.

But your point is indeed a valid one, and something for macro writers to be
acutely aware of.  (A similar but harder-to-spot error would be having a second
variable declaration later in the scene to overwrite the previous value.  Kind
of the reverse of failing to update a counter in a while loop.)

- BW

[Bald Eagle] Re: Macro parameters with the same name [1050 days 20 hours and 13 minutes ago]

Tue, 23 May 2023 11:10:00 GMT

OK - I see it now.

I was thinking in terms of the macro CALL, not the macro "constructor".

So yeah, what you're saying now makes a lot more sense.

I can still se where someone may have some reason to want to do it that way,
especially if the second argument is an optional one, but I don't write computer
languages or parsers...

I will say that it's like a second camera in a scene, so there's still the
potential to issue a "duplicate argument found in macro declaration - ignoring
previous instance"   kind of warning.

But your point is indeed a valid one, and something for macro writers to be
acutely aware of.  (A similar but harder-to-spot error would be having a second
variable declaration later in the scene to overwrite the previous value.  Kind
of the reverse of failing to update a counter in a while loop.)

- BW

[Cousin Ricky] Re: Macro parameters with the same name [1051 days 2 hours and 33 minutes ago]

Tue, 23 May 2023 04:50:12 GMT

On 2023-05-22 15:39 (-4), Bald Eagle wrote:
> 
>> Do you see the problem?  I didn't--but neither did the POV-Ray parser.
>> When I combined the macros, I accidentally used the name 'Roughness' for
>> two different arguments.  I spent a week wondering why the final macro
>> didn't give the results I expected.  I think the parser should flag this
>> as a fatal error.
> 
> Well - I would respectfully disagree.
> I would say the the parser ought to issue a warning - "Multiple usage of
> argument name in macro call" - since I can easily envision instances where
> people might want to use named variables in multiple places, rather than rigidly
> partitioning everything into unique special-purpose values such as you are
> doing.
> 
> It's always hard to judge what someone may want to construct, and leaving the
> option open for employing that kind of flexibility to use anything one might
> desire as a macro argument should always be something available to the SDL
> programmer.
> 
> I do agree that we could use some more assistive programming aids and debugging
> tools, but I think a warning would suffice.   Much like we can scale by x*2,
> which is <2, 0, 0> and the parser "knows" (the Dev Team rightly assumes /
> presumes) that the user means to scale in the x direction by two, leaving the y
> and z dimensions untouched - <2, 1, 1>.  We can make degenerate triangles, and
> sometimes even divide by zero, yet the scene successfully parses.
> 
> A fatal error here is WAY too strict / limiting.

No, I stand by my position.

You've seen me complain bitterly about POV-Ray's scope leakage--how a
local identifier can conflict with a macro name, requiring everyone who
shares a macro to avoid any name that the users might think up.  You've
seen users burned because they created an identifier whose name
*happened* to be the same as a formal parameter of a function they
didn't write.  Those are conflicts that should never happen in a
block-structured language, and require elements of a scene to know the
inner workings of other elements that they shouldn't need to know, and
indeed have no business knowing.  Those are situations in which allowing
multiple identifiers with the same name would be the best policy.

Instead, what we have in this case are identifiers with the same name
*in the same context.*  How is the macro to know which instance the
POVer intended where?  What exactly would a fatal error be limiting?

This is not flexibility; it is ambiguity.

As it turns out, POV-Ray appears to choose the latter instance.
Arbitrarily.  It could have been the other way around.  It could have
been random.  Maybe it *is* random, and I just haven't done enough test
cases.

I maintain that this is not analogous to a degenerate triangle; it is
analogous to a degenerate cylinder.  This is not a warning situation; it
is a scenario where, by rights, the parser doesn't really know what to
do.  The construction is useless, ambiguous, and nonsensical.

[Bald Eagle] Re: Macro parameters with the same name [1051 days 11 hours and 43 minutes ago]

Mon, 22 May 2023 19:40:00 GMT

> Do you see the problem?  I didn't--but neither did the POV-Ray parser.
> When I combined the macros, I accidentally used the name 'Roughness' for
> two different arguments.  I spent a week wondering why the final macro
> didn't give the results I expected.  I think the parser should flag this
> as a fatal error.

Well - I would respectfully disagree.
I would say the the parser ought to issue a warning - "Multiple usage of
argument name in macro call" - since I can easily envision instances where
people might want to use named variables in multiple places, rather than rigidly
partitioning everything into unique special-purpose values such as you are
doing.

It's always hard to judge what someone may want to construct, and leaving the
option open for employing that kind of flexibility to use anything one might
desire as a macro argument should always be something available to the SDL
programmer.

I do agree that we could use some more assistive programming aids and debugging
tools, but I think a warning would suffice.   Much like we can scale by x*2,
which is <2, 0, 0> and the parser "knows" (the Dev Team rightly assumes /
presumes) that the user means to scale in the x direction by two, leaving the y
and z dimensions untouched - <2, 1, 1>.  We can make degenerate triangles, and
sometimes even divide by zero, yet the scene successfully parses.

A fatal error here is WAY too strict / limiting.

I am glad though, that you found the error - sometimes those things can be SO
hard to spot.

Although it does eat up lines, I will sometimes put all of the arguments on
separate lines just to makes things like that visually stick out.


One thing I have suggested in the past is a way to access from SDL the number of
arguments passed to the macro.  First, this would be useful in cases where
optional arguments are used, and conditional processing is needed.

But in your case, I can imagine a little sanity-check sub-macro being called in
the first line of every macro that could compare all of the values of the
arguments looking for equalities/duplicates.   Better still would be access to
the macro argument names, or the whole list of argument names as a small array.

You could of course, simply pass everything to the macro as an array, and then
use dimension_size to cycle through all of the elements of the array to do
sanity checks...  (I initially wrote "samity checks"...  which kinda seemed like
a fitting error   :D )


- BE

[Bald Eagle] Re: Macro parameters with the same name [1051 days 11 hours and 43 minutes ago]

Mon, 22 May 2023 19:40:00 GMT

> Do you see the problem?  I didn't--but neither did the POV-Ray parser.
> When I combined the macros, I accidentally used the name 'Roughness' for
> two different arguments.  I spent a week wondering why the final macro
> didn't give the results I expected.  I think the parser should flag this
> as a fatal error.

Well - I would respectfully disagree.
I would say the the parser ought to issue a warning - "Multiple usage of
argument name in macro call" - since I can easily envision instances where
people might want to use named variables in multiple places, rather than rigidly
partitioning everything into unique special-purpose values such as you are
doing.

It's always hard to judge what someone may want to construct, and leaving the
option open for employing that kind of flexibility to use anything one might
desire as a macro argument should always be something available to the SDL
programmer.

I do agree that we could use some more assistive programming aids and debugging
tools, but I think a warning would suffice.   Much like we can scale by x*2,
which is <2, 0, 0> and the parser "knows" (the Dev Team rightly assumes /
presumes) that the user means to scale in the x direction by two, leaving the y
and z dimensions untouched - <2, 1, 1>.  We can make degenerate triangles, and
sometimes even divide by zero, yet the scene successfully parses.

A fatal error here is WAY too strict / limiting.

I am glad though, that you found the error - sometimes those things can be SO
hard to spot.

Although it does eat up lines, I will sometimes put all of the arguments on
separate lines just to makes things like that visually stick out.


One thing I have suggested in the past is a way to access from SDL the number of
arguments passed to the macro.  First, this would be useful in cases where
optional arguments are used, and conditional processing is needed.

But in your case, I can imagine a little sanity-check sub-macro being called in
the first line of every macro that could compare all of the values of the
arguments looking for equalities/duplicates.   Better still would be access to
the macro argument names, or the whole list of argument names as a small array.

You could of course, simply pass everything to the macro as an array, and then
use dimension_size to cycle through all of the elements of the array to do
sanity checks...  (I initially wrote "samity checks"...  which kinda seemed like
a fitting error   :D )


- BE

[Cousin Ricky] Macro parameters with the same name [1051 days 13 hours and 20 minutes ago]

Mon, 22 May 2023 18:02:55 GMT

I'm not sure how to categorize this, as it does not manifest with
properly constructed SDL; but it lets improper code render to completion
while leaving you scratching your head over why the image doesn't look
right.

Say you're developing a wood macro, and you start with:

  #macro MyWood
  ( Taper, Rings_map, c_Light, c_Dark,
    Grain_size, Roughness, Gnarl, Gnarl_size, v_Random
  )

It looks good, but you want to add varnish.  Your arguments are the
glossiness, the specular highlight roughness, and the varnish's index of
refraction:

  #macro MyVarnish (Glossiness, Roughness, IoR)

Finally, you think it would be convenient to combine the two macros into
one:

  #macro MyVarnishedWood
  ( Taper, Rings_map, c_Light, c_Dark,
    Grain_size, Roughness, Gnarl, Gnarl_size, v_Random,
    Glossiness, Roughness, IoR
  )

Do you see the problem?  I didn't--but neither did the POV-Ray parser.
When I combined the macros, I accidentally used the name 'Roughness' for
two different arguments.  I spent a week wondering why the final macro
didn't give the results I expected.  I think the parser should flag this
as a fatal error.

[Leroy] pov 3.7 array and for strangeness [1059 days 10 hours and 3 minutes ago]

Sun, 14 May 2023 21:20:00 GMT

A while ago I made some POV code to turn a 2meg color tga (made by POV) into a
256 color palette pcx. This was for the old Quake2 game.

I used this in a mac to save the file:

   #local Tc=Image_Width * Image_Height;
   #for(a,0,Tc-1)
    #write (Mfile,uint8 Image[a])// The image array contain Integers<256
   #end
I had no problems, as the Image_Width & Image_Height where rather small 400*400.

Lately I tried to use the same code to save a much larger image array
(2048*1024)
The Image just didn't work. After going through the code a dozen times looking
for bugs. I decided to try and make the POV crash on purpose.
So I tried this.

   #local Tc=Image_Width * Image_Height;
   #for(a,0,Tc)//--- notice the change------
    #write (Mfile,uint8 Image[a])// The image array still contain Integers<256
   #end
POV didn't crash !?  And the image worked!!

To see what the output was I saved the Image array into POV file as an Named
array and ran that file to see if the array would work.
 neither of the codes above made a good array with out a lot of tweeking.

Not satisfied I tried this:

   #local Tc=Image_Width * Image_Height;
   #local a=0;
   #while(a<Tc)
    #write (Mfile,uint8 Image[a])
    #local a=a+1;
   #end
Everything worked as expected!!

So what ya think?

I've got:: POV version 3.7.0.RC7.mevc10.sse.win32 running on an winXP.

Have fun!!

[William F Pokorny] Re: POV-Ray 3.7 crashes on photons or radiosity [1081 days 3 hours and 16 minutes ago]

Sun, 23 Apr 2023 04:07:12 GMT

On 4/22/23 15:51, jr wrote:
> hi,
> 
> Cousin Ricky <ric### [at] yahoocom> wrote:
>> I get a segmentation fault with this scene:
>> ...
>> I used self-compiled POV-Ray 3.7.0.10 for Unix.  This code renders fine
>> with 3.8-beta 2, ...
> 
> yep, v3.7.0.8 on Debian 11/bullseye too segfaults.  though fine with beta.2,
> WFP's povr informs: "Check_Photon_Light_Group called and internal code is
> incomplete.Internal Error."
> 
> regards, jr.
> 

The issue here is: max_trace_level 255

 From our documentation:

Note: Raising max_trace_level will use more memory and time and it could 
cause the program to crash with a stack overflow error, although ADC 
will alleviate this to a large extent.

Aside 1: On the documentation the ADC bailout helps less with 
assumed_gamma 1, photons (and radiosity?). There is too a comment about 
a warning being issued if the max is hit, which I think not true. The 
Max Level: n/max usage is reported as information.

--- More
v3.7 still has the old unix/linux stack size allocation issues. Windows 
v3.7 does too, but it kicks in much later than g++ due how the window's 
build/compile works. One of our initial patches for the stack overflow 
issue doubled the default stack sizes if compiling on unix/linux...

That initial unix/linux 'patch/hack' was later deleted. Christoph put in 
a chunk of work to remove most (practically, perhaps all) stack size 
allocation issues in the v3.8 code & onward. I've not run into a stack 
overflow issue since his thread-stack handling changes were completed.

There are too compiler options which change stack overflow behavior and 
likely-hood. So, with the v3.7 code base, it's not too surprising we 
might be seeing differences in behavior depending upon the build. The 
linux package distribution folks compile with a more conservative set of 
flags than does the default POV-Ray release configure script.

Aside 2: IIRC there is a max_trace_level setting inside the photon block 
inside global_settings. I didn't play with it. Probably, it defaults to 
the scene's global setting unless overridden, but not sure. In my 
testing, if either radiosity or photons turned on, the segfault happened 
with max_trace_level at 255.

Aside 3: Shouldn't the light_source in the scene have a photon block too?

Aside 4: (Thanks jr!) The Internal error out of povr was me putting in a 
message to force myself to look at that hacked code a little more on the 
next photon scene I ran. I forgot it was sitting there in the code...

My thinking is we should not just return 'true' from that hacked 
function, but rather should run the loop which tests whether at least 
one light group source has photon block before returning true. But, the 
reality is there are other things not complete in the code with respect 
to photons and light groups. See: 
https://github.com/POV-Ray/povray/issues/126

Aside 4.5: The commented code in Check_Photon_Light_Group touches on 
that compile time configurable 'global' photon keyword mentioned during 
the work toward the povr word_is / word_get additions. The photon 
specific keyword 'global' was co-opted for use in v3.8 onward for the 
global dictionary. If the option is re-enabled, we'll likely need to 
change the photon keyword 'global' to something else.

Anyhow...

Bill P.

[Kenneth] Re: POV-Ray 3.7 crashes on photons or radiosity [1081 days 8 hours and 8 minutes ago]

Sat, 22 Apr 2023 23:15:00 GMT

(running official v3.7.0 msvc10.win64 at default Quality 9, Windows 10, Lenovo
desktop machine with Core I7, 8 cores/16 threads)

No segfault or other problems for me; the code runs fine. I tried it at various
render resolutions, with/without AA, and different Quality settings.
Render_Block_Size at default (32?). Bounding_Threshold=1.

[jr] Re: POV-Ray 3.7 crashes on photons or radiosity [1081 days 10 hours and 58 minutes ago]

Sat, 22 Apr 2023 20:25:00 GMT

"jr" <cre### [at] gmailcom> wrote:
> ...
> yep, v3.7.0.8 on Debian 11/bullseye too segfaults.  though fine with beta.2,
> WFP's povr informs: "Check_Photon_Light_Group called and internal code is
> incomplete.Internal Error."

the Debian version is pre-compiled, 'apt' installed.  interestingly, on a
Slackware machine, self-compiled 3.7.0.8 and 3.7.1-rc.1 run ok, until I add a
'+q'uality switch higher than '8'.  :-)

regards, jr.

[jr] Re: POV-Ray 3.7 crashes on photons or radiosity [1081 days 11 hours and 28 minutes ago]

Sat, 22 Apr 2023 19:55:00 GMT

hi,

Cousin Ricky <ric### [at] yahoocom> wrote:
> I get a segmentation fault with this scene:
> ...
> I used self-compiled POV-Ray 3.7.0.10 for Unix.  This code renders fine
> with 3.8-beta 2, ...

yep, v3.7.0.8 on Debian 11/bullseye too segfaults.  though fine with beta.2,
WFP's povr informs: "Check_Photon_Light_Group called and internal code is
incomplete.Internal Error."

regards, jr.

[Cousin Ricky] POV-Ray 3.7 crashes on photons or radiosity [1081 days 11 hours and 54 minutes ago]

Sat, 22 Apr 2023 19:28:41 GMT

I get a segmentation fault with this scene:

----------[BEGIN CODE]---------
// +W300 +H240
#version 3.7;

global_settings
{ assumed_gamma 1
  max_trace_level 255
  photons { spacing 0.05 media 100 }
  radiosity
  { count 200
    error_bound 0.5
    pretrace_end 1 / image_width
    pretrace_start 16 / image_width
    recursion_limit 2
  }
}

camera
{ orthographic
  location -10 * z
  right 10 * x
  up 8 * y
}

light_source { <-0.6, 1, -2> * 1000, rgb 1 parallel point_at 0 }
background { rgb 0.25 }

#default { finish { ambient 0.125 diffuse 0.75 } }

#declare v_Scale = <3, 3, 2>;

difference
{ sphere { 0, 1 scale v_Scale }
  sphere { 0, 1 scale v_Scale - 0.5 }
  pigment { rgbf 1 }
  finish
  { reflection { 0, 1 fresnel } conserve_energy
    specular albedo 0.05 roughness 0.001
  }
  interior
  { ior 1.51673
    fade_color <0, 0.8, 0.4>
    fade_power 1001
    fade_distance v_Scale.z / 2
  }
  photons { target refraction on reflection on collect off }
}

plane
{ -z, -v_Scale.z - 0.001
  pigment { checker rgb 0.5 rgb 1 scale 2 translate x }
}
-----------[END CODE]----------

I used self-compiled POV-Ray 3.7.0.10 for Unix.  This code renders fine
with 3.8-beta 2, and the scene description file from which this code was
extracted rendered to completion with 3.7-RC7 back in 2013, so something
happened between 3.7-RC7 and 3.7.0.10 that did not carry over into 3.8.

The code renders fine if I delete both the photons *and* the radiosity,
but if I include either one, the scene seg faults.

Does anyone else get a seg fault with their POV-Ray 3.7?  Does anyone
see any mistakes I may have made in the code?

POV-Ray versions: POV-Ray 3.7.0.10 (self-compiled)
Operating system: openSUSE Leap 15.3 GNU/Linux
Hardware: Lenovo Ideapad Slim 7
CPU: Intel Core i7

[kurtz le pirate] Re: Slice of apple pie [1089 days and 22 minutes ago]

Sat, 15 Apr 2023 07:00:27 GMT

On 13/04/2023 13:50, William F Pokorny wrote:
> On 4/11/23 06:40, Bald Eagle wrote:
>>> I believe what your are seeing is the fact the disc, like the plane, is
>>> defined in the code as having and inside (as being a 'basic object'
>>> rather than a 'patch object') so it can be used in CSG.
> 
>> That's certainly what it looks like to me.   That slice is HUGE.
> 
> Thanks for the confirmation.
> 
> I spent a little time this morning looking at the code and playing. It 
> turns out the disc is auto bounded using the radius & other info - as it 
> can. Where flat relative to the x,z plane the box y min and max values 
> are set to the initial vector, y value. x and z to the +-r, +-r values. 
> The automatic bounding box has is infinitely thin and it is rays hitting 
> this box determine when we look for ray -> surface intersections.
> 
> The bounding determination, where things are not simple in being at the 
> origin and axis aligned, is more complicated.
> 
> An alternative to clipping the ray-surface intersections internal to a 
> shape, would be to use two opposing discs with a very small space 
> between them (tiny inside sliver region) like this:
> 
> #declare DiscOrigin = <0,0,0>;
> #declare DiscNormal = <0,1,-1>;
> #declare I01 = intersection {
>      Wedge(275)
>      disc  {
>          DiscOrigin+(+1e-8*DiscNormal),
>          +1*DiscNormal, 1, 0.5 }
>      disc  {
>          DiscOrigin+(-1e-8*DiscNormal),
>          -1*DiscNormal, 1, 0.5 }
>      pigment { color Green }
> }
> 
> This, as a generic approach, is likely more stable numerically as any 
> 'edge noise' has to happen between the to opposing discs. Remembering 
> here too discs can have holes.
> 
> Bill P.
> 



Thank Bill for all these explanations. But as I said, using the cylinder
instead of the disc does the job perfectly.

@Bald Eagles : shapes.inc contains some interesting macros.
I'm surprised you don't know ;)







-- 
Kurtz le pirate
Compagnie de la Banquise

[William F Pokorny] Re: Slice of apple pie [1090 days 19 hours and 32 minutes ago]

Thu, 13 Apr 2023 11:50:45 GMT

On 4/11/23 06:40, Bald Eagle wrote:
>> I believe what your are seeing is the fact the disc, like the plane, is
>> defined in the code as having and inside (as being a 'basic object'
>> rather than a 'patch object') so it can be used in CSG.

> That's certainly what it looks like to me.   That slice is HUGE.

Thanks for the confirmation.

I spent a little time this morning looking at the code and playing. It 
turns out the disc is auto bounded using the radius & other info - as it 
can. Where flat relative to the x,z plane the box y min and max values 
are set to the initial vector, y value. x and z to the +-r, +-r values. 
The automatic bounding box has is infinitely thin and it is rays hitting 
this box determine when we look for ray -> surface intersections.

The bounding determination, where things are not simple in being at the 
origin and axis aligned, is more complicated.

An alternative to clipping the ray-surface intersections internal to a 
shape, would be to use two opposing discs with a very small space 
between them (tiny inside sliver region) like this:

#declare DiscOrigin = <0,0,0>;
#declare DiscNormal = <0,1,-1>;
#declare I01 = intersection {
     Wedge(275)
     disc  {
         DiscOrigin+(+1e-8*DiscNormal),
         +1*DiscNormal, 1, 0.5 }
     disc  {
         DiscOrigin+(-1e-8*DiscNormal),
         -1*DiscNormal, 1, 0.5 }
     pigment { color Green }
}

This, as a generic approach, is likely more stable numerically as any 
'edge noise' has to happen between the to opposing discs. Remembering 
here too discs can have holes.

Bill P.

[Bald Eagle] Re: Slice of apple pie [1092 days 20 hours and 38 minutes ago]

Tue, 11 Apr 2023 10:45:00 GMT

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

> I believe what your are seeing is the fact the disc, like the plane, is
> defined in the code as having and inside (as being a 'basic object'
> rather than a 'patch object') so it can be used in CSG.

That's certainly what it looks like to me.   That slice is HUGE.

Thanks for the pointer to Wedge () - I thought it was in one of those inc files,
but wasn't sure where.   It's shapes.inc


Simply adding clipped_by and bounded_by makes for a quick fix/workaround

//The same macro but using the "disc" object show the issue
//(image on the right)
#macro corner2 (r,e,a)
 #if(a<360)
  difference {
   disc { <0,0,0>, y, r }
   object { complementWedge(a) }
   clipped_by {box {<-r, -e, -r>, <r, e, r>}}
   bounded_by {clipped_by}
   }
 #else
  disc { <0,0,0>, y, r }
 #end
#end



- BW

[William F Pokorny] Re: Slice of apple pie [1093 days 12 hours and 27 minutes ago]

Mon, 10 Apr 2023 18:56:09 GMT

On 4/10/23 14:38, William F Pokorny wrote:
>> The same macro but using the "disc" object show the issue
>> (image on the right)
> 
> I believe what your are seeing is the fact the disc, like the plane, is 
> defined in the code as having and inside (as being a 'basic object' 
> rather than a 'patch object') so it can be used in CSG.

Just hit me I forgot to answer Bald Eagles 'Wedge' question.

It's a macro shipped with POV-Ray which uses the intersections (and 
perhaps differences) of two planes to create a wedge (pie slice region) 
of space which is usually used in a follow on intersection (or 
difference) with other stuff.

Bill P.

[William F Pokorny] Re: Slice of apple pie [1093 days 12 hours and 45 minutes ago]

Mon, 10 Apr 2023 18:38:12 GMT

On 4/10/23 10:49, kurtz le pirate wrote:
> The same macro but using the "disc" object show the issue
> (image on the right)

I believe what your are seeing is the fact the disc, like the plane, is 
defined in the code as having and inside (as being a 'basic object' 
rather than a 'patch object') so it can be used in CSG.

Neither the disc or plane have an actual finite inside. But, with the 
plane especially it's convenient to use it when defining many objects 
via csg - though the bounding of the result is often bad (infinite in 
some aspect or in total).

The disc being set up in a similar manner to the plane is questionable 
in my opinion. Perhaps when it got done 30 plus years ago it made more 
sense to do it. There have long been scenes where the disc 'is' getting 
used in csg & it's been left as is rather than treating it a pure, 
finite patch object.

Aside: The documentation says the disc's inside is no different than a 
plane's, but your image makes me wonder if it's not constrained to the 
radius of the disc in at least some aspects. Maybe due the 
inside/outside csg status flips somehow? There is not a completely, 
surface bounded inside region in your example, but it kinda looks like 
there is(a).

(a) - Maybe rays are constrained to the disc if they travel through the 
plane in which the disc sits though the insided-ness is still like the 
plane's when that inside test is run...

Don't know. I've never gone through the disc code in detail & never used 
it myself, IIRC, unless it was in code I picked up somewhere. Kinda want 
to play a little with it as I wonder, but, have not the time now.

Bill P.

[Bald Eagle] Re: Slice of apple pie [1093 days 14 hours and 3 minutes ago]

Mon, 10 Apr 2023 17:20:00 GMT

kurtz le pirate <kur### [at] gmailcom> wrote:

> The same macro but using the "disc" object show the issue

That's pretty weird.

What is "Wedge"?  Without that, it's hard to definitively debug this.


- BW

[kurtz le pirate] Slice of apple pie [1093 days 16 hours and 33 minutes ago]

Mon, 10 Apr 2023 14:49:43 GMT

Hello,

As the subject indicates, the goal is to create a "slice" of the disk.

With this macro, everything works fine (image on the left)
#macro corner(r,e,a)
 #if(a<360)
  difference {
   cylinder { <0, -e, 0>, <0, e, 0>, r }
   object { complementWedge(a) }
   }
 #else
  cylinder { <0, -e, 0>, <0, e, 0>, a }
 #end
#end


The same macro but using the "disc" object show the issue
(image on the right)
#macro corner(r,e,a)
 #if(a<360)
  difference {
   disc { <0,0,0>, y, r }
   object { complementWedge(a) }
   }
 #else
  disc { <0,0,0>, y, r }
 #end
#end



With the help of this macro :
#macro complementWedge(a)
 object {
  Wedge(360-a)
  rotate a*y
  }
#end



Bug ?
Note that the use of cylinder does not bother me more than that.


-- 
Kurtz le pirate
Compagnie de la Banquise

[Tor Olav Kristensen] Re: "mandel" as function in isosurface has unexp... [1204 days 16 hours and 48 minutes ago]

Tue, 20 Dec 2022 14:35:00 GMT

"Bald Eagle" <cre### [at] netscapenet> wrote:
> Lars Rohwedder <rok### [at] gmxde> wrote:
>...

> > So I had expected that a formula like 0.9 - mandel would give the
>
> > What went wrong here?
>
> Part of what's going wrong is that mandel is a POV-Ray pattern that has a built
> in color map.   And that wreaks hell with everything right from the beginning.
>
> I'd say try using:
>
> #declare Mandel = function { pigment {mandel 1000 exterior 1, 1 color_map {[0
> rgb 0] [1 rgb 1]}}}
>...

Hi Bill and Lars

AFAIK, patterns can not have built in color maps, while pigments can.
So here I would rater suggest a pattern function instead of a pigment function:

#declare MandelbrotFn =
    function {
        pattern {
            mandel 1000
            exterior 1, 1
        }
    }
;

Pattern functions do not return colors as pigment functions do, but float values
between 0 and 1.

Patterns and pattern functions (and other functions returning floats) can be
used to select colors from color maps in pigments, e.g. like this:

    plane {
        +z, 0
        pigment {
            mandel 1000
            color_map {
                [ 0.0 color rgb <0, 0, 0> ]
                [ 0.2 color rgb <1, 0, 0> ]
                [ 0.4 color rgb <1, 1, 0> ]
                [ 1.0 color rgb <1, 1, 1> ]
                [ 1.0 color rgb <0, 0, 0> ]
            }
        }
    }

- or like this:

    #declare MandelFn = function { pattern { mandel 1000 } };

    plane {
        +z, 0
        pigment {
            function { MandelFn(x, y, z) }
            color_map {
                [ 0.0 color rgb <0, 0, 0> ]
                [ 0.2 color rgb <1, 0, 0> ]
                [ 0.4 color rgb <1, 1, 0> ]
                [ 1.0 color rgb <1, 1, 1> ]
                [ 1.0 color rgb <0, 0, 0> ]
            }
        }
    }

--
Tor Olav
http://subcube.com
https://github.com/t-o-k

[Bald Eagle] Re: [solved] "mandel" as function in isosurface ... [1208 days 19 hours and 53 minutes ago]

Fri, 16 Dec 2022 11:30:00 GMT

Lars Rohwedder <rok### [at] gmxde> wrote:

> > Can you cite that with a link, or is that your working hypothesis?
>
> https://www.povray.org/documentation/view/3.6.1/377/
>
> See the explanations for "interior" and "exterior" types 0 and 1.

Yeah, I did.  Just did again.
The way it's written still doesn't make it any clearer to me.  ;)  :/

> A default color map is not mentioned there at all, hence I did not know
> about that. :-/

Right, we've come across that here and there, and I only really caught on when I
was plotting the function values and using the result as a pigment as well.   My
first post should have been enough to make that clear to me, but ....  density.

Wholeheartedly agree that the default internal color map ought to be explicitly
mentioned if not listed and explained in detail.

> Thank you a lot! Changing the color map into a stupid black-to-white
> ramp solves the problem.
>
> See attached .pov files and renderings.
>
> > Maybe you post your full scene as an attachment, and someone can
> > figure this out.
>
> I did it in my original posting.

Right-o.   It was a night-time last ditch effort, and I was just going off the
last post.  The first post rolled off my stack.

I'm glad it has worked out for you   :)

Just a thought - given the fractal nature, and the high function gradient -
maybe this approach will give you a smoother result?

https://www.mitchr.me/SS/mandelbrot/index.html

All the best,

BW

[Lars Rohwedder] [solved] "mandel" as function in isosurface has ... [1208 days 23 hours and 55 minutes ago]

Fri, 16 Dec 2022 07:27:29 GMT

>> According to the documentation of isosurface, all points with
>> function value  < threshold are "inside" the isosurface object.
> 
> Wellll...... it's an isoSURFACE, so there really is no inside, unless
> (IIRC) for csg you use all_intesections
> 
>> The "mandel" pattern is "low" (near zero) far away from the
>> Mandelbrot set, increases slowly near the border of the set and is
>> 1 inside the "apple shape" set itself (with default values for
>> "interior" and "exterior".
> 
> Can you cite that with a link, or is that your working hypothesis?

https://www.povray.org/documentation/view/3.6.1/377/

See the explanations for "interior" and "exterior" types 0 and 1.
A default color map is not mentioned there at all, hence I did not know
about that. :-/


>> So I had expected that a formula like 0.9 - mandel would give the
> 
>> What went wrong here?
> 
> Part of what's going wrong is that mandel is a POV-Ray pattern that
> has a built in color map.   And that wreaks hell with everything
> right from the beginning.

I see. It should be mentioned in the documentation of the mandel
pattern. :-/

> I'd say try using:
> 
> #declare Mandel = function { pigment {mandel 1000 exterior 1, 1
> color_map {[0 rgb 0] [1 rgb 1]}}}
> 
> But you're having more success than I am.

Thank you a lot! Changing the color map into a stupid black-to-white
ramp solves the problem.

See attached .pov files and renderings.

> Maybe you post your full scene as an attachment, and someone can
> figure this out.

I did it in my original posting.

Thanks again and enjoy the renderings (or use them as inspirations for
own "weird christmas tree" ideas. ;-)

Lars R.

[Bald Eagle] Re: "mandel" as function in isosurface has unexp... [1209 days 5 hours and 48 minutes ago]

Fri, 16 Dec 2022 01:35:00 GMT

Lars Rohwedder <rok### [at] gmxde> wrote:

> According to the documentation of isosurface, all points with function
> value  < threshold are "inside" the isosurface object.

Wellll...... it's an isoSURFACE, so there really is no inside, unless (IIRC) for
csg you use all_intesections

> The "mandel" pattern is "low" (near zero) far away from the Mandelbrot
> set, increases slowly near the border of the set and is 1 inside the
> "apple shape" set itself (with default values for "interior" and "exterior".

Can you cite that with a link, or is that your working hypothesis?

> So I had expected that a formula like 0.9 - mandel would give the

> What went wrong here?

Part of what's going wrong is that mandel is a POV-Ray pattern that has a built
in color map.   And that wreaks hell with everything right from the beginning.

I'd say try using:

#declare Mandel = function { pigment {mandel 1000 exterior 1, 1 color_map {[0
rgb 0] [1 rgb 1]}}}

But you're having more success than I am.

Maybe you post your full scene as an attachment, and someone can figure this
out.   All I'm getting right now is a hard-to-visualize infinitely thin layer.

You can try z-mandel.red or mandel (x, y, 0), or any of the other usual tricks.

- BW

[Lars Rohwedder] Re: "mandel" as function in isosurface has unexp... [1209 days 11 hours and 52 minutes ago]

Thu, 15 Dec 2022 19:30:33 GMT

Am 15.12.22 um 19:36 schrieb Bald Eagle:
> Lars Rohwedder <rok### [at] gmxde> wrote:
>> I'd expected that the areas "far outside" of the Mandelbrot set (outside
>> of the red cylinder) would have "low" values, so they are far "outside"
>> of the isosurface. But they aren't, so the result is that the whole
>> contained_by box is filled.
>>
>> Is it a bug how mandel pattern & isosurface work together or is the bug
>> in my scene file? :-/
>>
>> Lars R.
> 
> It looks like the pattern drops off to zero.

Correct.

According to the documentation of isosurface, all points with function 
value  < threshold are "inside" the isosurface object.

The "mandel" pattern is "low" (near zero) far away from the Mandelbrot 
set, increases slowly near the border of the set and is 1 inside the 
"apple shape" set itself (with default values for "interior" and "exterior".

So I had expected that a formula like 0.9 - mandel would give the 
desired result:

   * the points inside the Mandelbrot set will be <0, so are consideded 
as "inside" the rendered shape.
   * the points far away of the Mandelbrot set will be >0, so are 
"outside" of the rendered shape.

But the rendering looks completely different than expected, see attached 
mandel-0.9.png

Changing the formula to 0.5-mandel2(x,y,z) it looks much more than a 
Mandelbrot set, but it is "inverse": the Mandelbrot set is "outside", 
the surrounding areay is inside. Hence I switched the sign, so the 
forumla becomes mandel(x,y,z)-0.5.

So the inside of the Mandelbrot set becomes the inside of the 
isosurface, as expected, but also the far away areas are "inside", which 
is _not_ what I expected.

What went wrong here?

Lars R.

pS: The "open" keyword just removes the visibility of the contained_by 
object, but I consider it helpful to see what is insided and what it is 
outside of the isosurface object.

[Bald Eagle] Re: "mandel" as function in isosurface has unexp... [1209 days 12 hours and 43 minutes ago]

Thu, 15 Dec 2022 18:40:00 GMT

Lars Rohwedder <rok### [at] gmxde> wrote:
> I'd expected that the areas "far outside" of the Mandelbrot set (outside
> of the red cylinder) would have "low" values, so they are far "outside"
> of the isosurface. But they aren't, so the result is that the whole
> contained_by box is filled.
>
> Is it a bug how mandel pattern & isosurface work together or is the bug
> in my scene file? :-/
>
> Lars R.

It looks like the pattern drops off to zero.

Maybe try adding "open" to your isosurface statement.

https://wiki.povray.org/content/Reference:Isosurface

"When the isosurface is not fully contained within the contained_by object,
there will be a cross section. When this happens, you will see the surface of
the container. Using the open keyword, these cross section surfaces are removed,
and the inside of the isosurface becomes visible.

Note: Using open slows down the render speed, and it is not recommended for use
with CSG operations."

Might have to add "all_intersections" as well, if things still don't look good.
(just guessing)

Here's the pattern with 1000 iterations on an xy plane.

[Lars Rohwedder] "mandel" as function in isosurface has unexpecte... [1209 days 18 hours and 28 minutes ago]

Thu, 15 Dec 2022 12:54:42 GMT

I'd expected that the areas "far outside" of the Mandelbrot set (outside 
of the red cylinder) would have "low" values, so they are far "outside" 
of the isosurface. But they aren't, so the result is that the whole 
contained_by box is filled.

Is it a bug how mandel pattern & isosurface work together or is the bug 
in my scene file? :-/

Lars R.

[Bald Eagle] Re: Using phong with shadowless [1233 days 19 hours and 48 minutes ago]

Mon, 21 Nov 2022 11:35:00 GMT

Cousin Ricky <ric### [at] yahoocom> wrote:
> On 2022-11-20 13:55 (-4), Bald Eagle wrote:
> > While experimenting with some code, I was using a shadowless light, and noticed
> > that I wasn't getting a phong highlight on a sphere with that finish.
> >
> > Is this for some reason the intended behaviour, or an actual bug?
>
> It is documented non-judgmentally, which suggests that it is deliberate.
>  See:
> https://wiki.povray.org/content/Reference:Light_Source#Shadowless_Lights
>
> As for why, I can only guess.  But I tend to use shadowless lights as
> fill lighting, for which highlights are undesirable anyway.  Perhaps the
> dev team had the same idea.

"Also note that shadowless lights will not cause highlights on the illuminated
objects."

Well ...  not a bug, and your reasoning makes sense.
I was just taken off guard, as it was my only light source.

Thank you, Sir.

[Cousin Ricky] Re: Using phong with shadowless [1234 days 2 hours and 27 minutes ago]

Mon, 21 Nov 2022 04:56:04 GMT

On 2022-11-20 13:55 (-4), Bald Eagle wrote:
> While experimenting with some code, I was using a shadowless light, and noticed
> that I wasn't getting a phong highlight on a sphere with that finish.
> 
> Is this for some reason the intended behaviour, or an actual bug?

It is documented non-judgmentally, which suggests that it is deliberate.
 See:
https://wiki.povray.org/content/Reference:Light_Source#Shadowless_Lights

As for why, I can only guess.  But I tend to use shadowless lights as
fill lighting, for which highlights are undesirable anyway.  Perhaps the
dev team had the same idea.

[Tor Olav Kristensen] Re: Using phong with shadowless [1234 days 9 hours and 58 minutes ago]

Sun, 20 Nov 2022 21:25:00 GMT

"Bald Eagle" <cre### [at] netscapenet> wrote:
> While experimenting with some code, I was using a shadowless light, and noticed
> that I wasn't getting a phong highlight on a sphere with that finish.
>
> Is this for some reason the intended behaviour, or an actual bug?
>...


It looks like a bug to me. I can confirm that the behavior is the same for
POV-Ray for Windows Version 3.7.0.msvc10.win64 (The official version)

Here's a minimal scene for v3.7:

// ===== 1 ======= 2 ======= 3 ======= 4 ======= 5 ======= 6 ======= 7

#version 3.7;

global_settings { assumed_gamma 1.0 }

sphere {
    0*z, 2
    texture {
        pigment { color blue 0.2 }
        finish { phong 1 }
    }
}

background { color rgb <1.0, 1.0, 0.8> }

light_source {
    100*<1, 1, -2>
    color rgb <1, 1, 1>
    shadowless
}

camera {
    translate -10*z
}

// ===== 1 ======= 2 ======= 3 ======= 4 ======= 5 ======= 6 ======= 7

--
Tor Olav
http://subcube.com
https://github.com/t-o-k

[Bald Eagle] Using phong with shadowless [1234 days 13 hours and 23 minutes ago]

Sun, 20 Nov 2022 18:00:00 GMT

While experimenting with some code, I was using a shadowless light, and noticed
that I wasn't getting a phong highlight on a sphere with that finish.

Is this for some reason the intended behaviour, or an actual bug?


Minimal scene:


#version 3.8;
global_settings {assumed_gamma 1.0}



#declare Camera_Orthographic = true;
#declare Camera_Position = <0, 0, -100> ;
#declare Camera_Look_At  = <0, 0,  0> ;
// functions as a zoom for the orthographic view: 4 zooms in 4x, 8 zooms in 8x,
etc.
#declare Fraction = 75;

// ###########################################
camera {
 #if (Camera_Orthographic = true)
  orthographic
  right     x*image_width/(Fraction)
  up   y*image_height/(Fraction)
 #else
  right     x*image_width/image_height
  up y
 #end
 location  Camera_Position
 look_at   Camera_Look_At}
// ###########################################

sky_sphere {pigment {rgb <1, 1, 0.8>}}
#declare LS = <10, 10, -20>;
light_source {LS rgb 1 } //shadowless}

#declare Color = z*0.2; //<1, 0.9, 0.0>;
sphere {0, 1.2 texture {pigment {rgb Color} finish {phong 1}} }

[Le Forgeron] Re: uv_mapping bug on cylinders [1341 days 14 hours and 28 minutes ago]

Fri, 5 Aug 2022 16:55:07 GMT

Le 04/08/2022 Ã  20:21, Chris R a Ã©critÂ :
> Le_Forgeron <jgr### [at] freefr> wrote:

>> Any hope to get the full simplified scene of the picture ?
>> (it's for my experiment, you can send it directly if you do not want to
>> bother the newsgroups)
>>
>> William clearly summarised the sequence of events.
> 
> I simplified it even further in the attached .pov file.
> 
> -- Chris R.

Thanks.

The script frightened me a bit for hgpovray38 until I remembered to 
scale down the texture (by factor of 1/30 or so) to be able to see the 
pattern. Moving the second cylinder is safe.
I also moved the light further away.

[Chris R] Re: uv_mapping bug on cylinders [1342 days 12 hours and 58 minutes ago]

Thu, 4 Aug 2022 18:25:00 GMT

Le_Forgeron <jgr### [at] freefr> wrote:
> Le 03/08/2022 à 16:36, Chris R a écrit :
> > I encountered an issue with v3.8 beta 2 using uv_mapping textures on cylinders
> > while creating a label for a bottle.  I did search through the newsgroups for
> > any other report of this and didn't find anything that matches my problem.
> >
> > The original texture is fairly complex and involves using an object pattern with
> > a text object as the "object" and fully-specified textures for the ink and the
> > background of the label as the texture list.  However, I was able to simplify it
> > considerably to the following:
> >
> >              cylinder {
> >                  <0, 0, 0>,
> >                  <0, 20, 0>,
> >                  5
> >                  texture { uv_mapping pigment { brick color rgb 0 color rgb 1 } }
> >              }
> >              cylinder {
> >                  <0, 0, 0>,
> >                  <0, 20, 0>,
> >                  5
> >                  texture { uv_mapping pigment { brick color rgb 0 color rgb 1 } }
> >                  translate <20, 0, 0>
> >              }
> >
>
> Hello,
>
> Any hope to get the full simplified scene of the picture ?
> (it's for my experiment, you can send it directly if you do not want to
> bother the newsgroups)
>
> William clearly summarised the sequence of events.

I simplified it even further in the attached .pov file.

-- Chris R.

[Le Forgeron] Re: uv_mapping bug on cylinders [1342 days 14 hours and 52 minutes ago]

Thu, 4 Aug 2022 16:31:09 GMT

Le 03/08/2022 Ã  16:36, Chris R a Ã©critÂ :
> I encountered an issue with v3.8 beta 2 using uv_mapping textures on cylinders
> while creating a label for a bottle.  I did search through the newsgroups for
> any other report of this and didn't find anything that matches my problem.
> 
> The original texture is fairly complex and involves using an object pattern with
> a text object as the "object" and fully-specified textures for the ink and the
> background of the label as the texture list.  However, I was able to simplify it
> considerably to the following:
> 
>              cylinder {
>                  <0, 0, 0>,
>                  <0, 20, 0>,
>                  5
>                  texture { uv_mapping pigment { brick color rgb 0 color rgb 1 } }
>              }
>              cylinder {
>                  <0, 0, 0>,
>                  <0, 20, 0>,
>                  5
>                  texture { uv_mapping pigment { brick color rgb 0 color rgb 1 } }
>                  translate <20, 0, 0>
>              }
> 

Hello,

Any hope to get the full simplified scene of the picture ?
(it's for my experiment, you can send it directly if you do not want to 
bother the newsgroups)

William clearly summarised the sequence of events.

[Thomas de Groot] Re: uv_mapping bug on cylinders [1342 days 18 hours and 42 minutes ago]

Thu, 4 Aug 2022 12:41:19 GMT

Op 4-8-2022 om 12:36 schreef Bald Eagle:
> Thomas de Groot <tho### [at] degrootorg> wrote:
>> ...which reminds me to ask you (curiosity): how does
>>
>> #declare U = function (X, Y, Z) {(0.5 + atan2 (N(Z, X,Y,Z), N(X,
>> X,Y,Z))/(2*pi))}
>> #declare V = function (X, Y, Z) {(0.5 + asin(N(Y, X,Y,Z))/pi)}
>>
>> work? is puzzling, as far as atan2 and asin are concerned.
>>
>> --
>> Thomas
> 
> I don't have the file accessible to me ATM, but IIRC, the N() function is
> probably just a select () for whichever vector component is specified as the
> first argument. (*)
> 
> Then the atan2 returns an angle between -pi and pi, based on z and x.
> Dividing by tau gives values between -0.5 and 0.5, and then everything is
> shifted to between 0 and 1.
> 
> asin returns an angle between -pi/2 and pi/2.
> Dividing by pi gives values between -0.5 and 0.5, and then everything is shifted
> to between 0 and 1.
> 
> 
> (*) And the way THAT works, is taking the specified vector components and doing
> something like x*(-1) + y*0 + z*(2).  That should give you a -1, a 0, or a 2
> depending on which cardinal vector is specified.
> select () then returns one of three scalar values depending on what component it
> spits out.
> 


OK thanks. Sorry for diverting from the original post subject. I'll shut 
up now. :-)

-- 
Thomas

[Bald Eagle] Re: uv_mapping bug on cylinders [1342 days 20 hours and 43 minutes ago]

Thu, 4 Aug 2022 10:40:00 GMT

Thomas de Groot <tho### [at] degrootorg> wrote:
> ...which reminds me to ask you (curiosity): how does
>
> #declare U = function (X, Y, Z) {(0.5 + atan2 (N(Z, X,Y,Z), N(X,
> X,Y,Z))/(2*pi))}
> #declare V = function (X, Y, Z) {(0.5 + asin(N(Y, X,Y,Z))/pi)}
>
> work? is puzzling, as far as atan2 and asin are concerned.
>
> --
> Thomas

I don't have the file accessible to me ATM, but IIRC, the N() function is
probably just a select () for whichever vector component is specified as the
first argument. (*)

Then the atan2 returns an angle between -pi and pi, based on z and x.
Dividing by tau gives values between -0.5 and 0.5, and then everything is
shifted to between 0 and 1.

asin returns an angle between -pi/2 and pi/2.
Dividing by pi gives values between -0.5 and 0.5, and then everything is shifted
to between 0 and 1.

(*) And the way THAT works, is taking the specified vector components and doing
something like x*(-1) + y*0 + z*(2).  That should give you a -1, a 0, or a 2
depending on which cardinal vector is specified.
select () then returns one of three scalar values depending on what component it
spits out.

[Thomas de Groot] Re: uv_mapping bug on cylinders [1343 days and 43 minutes ago]

Thu, 4 Aug 2022 06:40:01 GMT

Op 04/08/2022 om 01:35 schreef Bald Eagle:
> Supplemental Aside #3:
> 
> You can also uv-map an object by writing your own function to texture the
> object's surface.   If you're into that sort of thing.
> 
>
http://news.povray.org/povray.binaries.images/thread/%3Cweb.5d5757a84c72a7284eec112d0%40news.povray.org%3E/?ttop=430135
> &toff=50
> 

...which reminds me to ask you (curiosity): how does

#declare U = function (X, Y, Z) {(0.5 + atan2 (N(Z, X,Y,Z), N(X, 
X,Y,Z))/(2*pi))}
#declare V = function (X, Y, Z) {(0.5 + asin(N(Y, X,Y,Z))/pi)}

work? is puzzling, as far as atan2 and asin are concerned.

-- 
Thomas

[Bald Eagle] Re: uv_mapping bug on cylinders [1343 days 7 hours and 43 minutes ago]

Wed, 3 Aug 2022 23:40:00 GMT

Supplemental Aside #3:

You can also uv-map an object by writing your own function to texture the
object's surface.   If you're into that sort of thing.

http://news.povray.org/povray.binaries.images/thread/%3Cweb.5d5757a84c72a7284eec112d0%40news.povray.org%3E/?ttop=430135
&toff=50

[William F Pokorny] Re: uv_mapping bug on cylinders [1343 days 9 hours and 2 minutes ago]

Wed, 3 Aug 2022 22:21:00 GMT

On 8/3/22 10:44, Chris R wrote:
> "Chris R" <car### [at] comcastnet> wrote:
>> I encountered an issue with v3.8 beta 2 using uv_mapping textures on cylinders
>> while creating a label for a bottle.  I did search through the newsgroups for
>> any other report of this and didn't find anything that matches my problem.
>>
>> The original texture is fairly complex and involves using an object pattern with
>> a text object as the "object" and fully-specified textures for the ink and the
>> background of the label as the texture list.  However, I was able to simplify it
>> considerably to the following:
>>
>>              cylinder {
>>                  <0, 0, 0>,
>>                  <0, 20, 0>,
>>                  5
>>                  texture { uv_mapping pigment { brick color rgb 0 color rgb 1 } }
>>              }
>>              cylinder {
>>                  <0, 0, 0>,
>>                  <0, 20, 0>,
>>                  5
>>                  texture { uv_mapping pigment { brick color rgb 0 color rgb 1 } }
>>                  translate <20, 0, 0>
>>              }
>>
>> As you can see, the second cylinder is translated after applying the texture,
>> but if you look at the brick pattern, it appears the uv_mapping is being applied
>> to the translated object first, because the bricks do not line up.
>>
>> In my bottle example, the text doesn't show up at all in the translated bottle,
>> because the entire bottle is outside of the text object's boundaries after it is
>> translated.
>>
>> -- Chris R.
> 
> Just as additional information, adding a "translate <20, 0, 0>" after the
> pigment declaration in the second texture corrects the problem.
> 
> -- Chris R.
> 
> 
IIRC the uv_mapping feature for cylinders and cones(a) is currently 
disabled in recent v3.8 / v4.0 code. I believe you are getting some sort 
of default planar mapping(b).

(a) - And other shape(s) where mapping didn't exist in v3.7.

(b) - Unsure what corrections for transforms and mapping spaces might be 
getting done or not with it. You could roughly test for planar mapping 
by moving the right cylinder in x by 5+1e-6, say.

---
More if interested. As remembered by my old flaky memory...

Cylinders and some other shapes did not previously support uv_mapping in 
v3.6/v3.7 though the keyword was allowed by the parser with no warning 
it's not really working. Jerome added code to do the mapping for 
cylinders, cones and other shape(s).

Christoph, later found a longstanding issue related to unstable mapping 
orientation - and he disabled all the new to v3.8/v4.0 uv_mapping 
updates. The problem noted exists for older mappings too, like the ovus, 
but it had uv mapping in v3.7 and Christoph decided to leave it as is 
for v3.8.

Last I knew, the documentation reflects the uv mapping as it was with 
the new uv_mapping shapes and not the current code state.

Jerome proposed fix for Christoph's concern, which I think is in 
hgpovray38, but I've not looked at it in detail. It wasn't 
adopted/merged in the official code.

Aside: I 'sort of' understand Christoph's concerns and Jerome's 
proposal, but I have additional questions relating to shapes like 
spheres which the parser 'sometimes' flattens to an already transformed 
position/orientation. I'd guess any better uv_mapping specification/code 
would have to track/work with the parser to maintain any specified 
uv_mapping orientation there too.

Aside 2: There are two additional ways to do cylindrical mapping of 
textures via warps and image_maps.

Bill P.

[Chris R] Re: uv_mapping bug on cylinders [1343 days 16 hours and 38 minutes ago]

Wed, 3 Aug 2022 14:45:00 GMT

"Chris R" <car### [at] comcastnet> wrote:
> I encountered an issue with v3.8 beta 2 using uv_mapping textures on cylinders
> while creating a label for a bottle.  I did search through the newsgroups for
> any other report of this and didn't find anything that matches my problem.
>
> The original texture is fairly complex and involves using an object pattern with
> a text object as the "object" and fully-specified textures for the ink and the
> background of the label as the texture list.  However, I was able to simplify it
> considerably to the following:
>
>             cylinder {
>                 <0, 0, 0>,
>                 <0, 20, 0>,
>                 5
>                 texture { uv_mapping pigment { brick color rgb 0 color rgb 1 } }
>             }
>             cylinder {
>                 <0, 0, 0>,
>                 <0, 20, 0>,
>                 5
>                 texture { uv_mapping pigment { brick color rgb 0 color rgb 1 } }
>                 translate <20, 0, 0>
>             }
>
> As you can see, the second cylinder is translated after applying the texture,
> but if you look at the brick pattern, it appears the uv_mapping is being applied
> to the translated object first, because the bricks do not line up.
>
> In my bottle example, the text doesn't show up at all in the translated bottle,
> because the entire bottle is outside of the text object's boundaries after it is
> translated.
>
> -- Chris R.

Just as additional information, adding a "translate <20, 0, 0>" after the
pigment declaration in the second texture corrects the problem.

-- Chris R.

[Chris R] uv_mapping bug on cylinders [1343 days 16 hours and 43 minutes ago]

Wed, 3 Aug 2022 14:40:00 GMT

I encountered an issue with v3.8 beta 2 using uv_mapping textures on cylinders
while creating a label for a bottle.  I did search through the newsgroups for
any other report of this and didn't find anything that matches my problem.

The original texture is fairly complex and involves using an object pattern with
a text object as the "object" and fully-specified textures for the ink and the
background of the label as the texture list.  However, I was able to simplify it
considerably to the following:

            cylinder {
                <0, 0, 0>,
                <0, 20, 0>,
                5
                texture { uv_mapping pigment { brick color rgb 0 color rgb 1 } }
            }
            cylinder {
                <0, 0, 0>,
                <0, 20, 0>,
                5
                texture { uv_mapping pigment { brick color rgb 0 color rgb 1 } }
                translate <20, 0, 0>
            }

As you can see, the second cylinder is translated after applying the texture,
but if you look at the brick pattern, it appears the uv_mapping is being applied
to the translated object first, because the bricks do not line up.

In my bottle example, the text doesn't show up at all in the translated bottle,
because the entire bottle is outside of the text object's boundaries after it is
translated.

-- Chris R.

[William F Pokorny] Re: Problem with transparent object and quartics [1372 days 20 hours and 32 minutes ago]

Tue, 5 Jul 2022 10:50:39 GMT

On 6/30/22 04:26, William F Pokorny wrote:
> - It should be once user bounding is in place you can flip renders 
> between -ur and +ur and see the infinite shape count reported in the 
> text output change.

My sleeping dreams...

On waking this morning I had the thought the above statement likely 
only applies with my povr branch where the +ur/-ur behavior has no 
exceptions.

The official POV-Ray branches have hidden, user bounds stripping 
exceptions. I'd make a moderate bet the polynomial shape is one of those 
exceptions. If right, the infinite count will NOT go up with +ur in the 
official POV-Ray branches - and the render result won't revert.

Bill P.

[William F Pokorny] Re: Problem with transparent object and quartics [1377 days 22 hours and 56 minutes ago]

Thu, 30 Jun 2022 08:26:32 GMT

On 6/27/22 10:23, Chris R wrote:
> In the scene, there is a quartic "drip" with translucent texture and an ior of
> 1.33 sitting behind a hollow box with a transparent pigment.  When I render it,
> the sides of the box become visible and seem to take on the texture/interior of
> the drip rather than the completely transparent texture I assigned.

The short explanation
---------------------
It's an issue with infinite shapes and inside determination which, here, 
can be fixed by manually bounding - and then rendering turning the 
stripping of user bounding(+ur) off with -ur.

I used a sloppy bounding box shape of:

           bounded_by { box {
             <-10, 0.1,  -2>,
             <10, 20.1,  +2>
             }
         }

A longer and still wildly incomplete description
--------------------------------------------------

The polynomial shape is generally treated as an infinite shape unless 
the user manually bounds it - and users always should... The 
insided-ness of any particular region - on seeing surfaces as the ray 
'travels'  becomes a flip of the coin without bounding(a). The shapes: 
cubic, quartic and poly have long been mapped to the polynomial shape 
internally(b).

(a) - Lying some. The better the manual bounding the smaller the lies.
(b) - Even the older explicit shape code often had similar issues as do 
shapes still with custom code like the quadric(b1).

(b1) - Which itself has unreliable auto-bounding - which at its worst 
differs depending upon CPU/compilers/build settings as reported a few 
years ago.

Some background. Internally, there is an initial atmospheric IOR value 
which is 1.0 unless changed in code as there is no way to access it via 
SDL. At any surface a working IOR is calculated based on the transition 
from the current IOR to the one specified by the new surface. The 
infinite shapes IOR value, if inside that shape, get used instead for 
the 'about to exit region' IOR value(c).

(c) - Yes, I think where we have >1 infinite shape testing as initially 
inside, what happens or even knowing what should happen is likely messy.

Other SDL ways to verify what is happening.
------------------------------------------

- We can add and interior { ior 1.33 } to the box making its IOR same as 
the infinite ior (from the not really inside inside ior of 1.33).

- We can flip the insided-ness of the quartic to be correct by adding 
the 'inverse' keyword rather than by adding user/manual bounding, but 
this a less 'good' option.

- We can trip the issue with the infinite plane rather than the quartic 
by changing to 'plane { -y, 0 ... } and setting the interior ior to 1.33.

- Things like a sphere with inverse, an ior of 1.33 and all boudning 
off(d) should work as a trigger too, but I didn't try it.
(d) - This an experiment which cannot be done with official v3.7/v3.8 
versions because -mb doesn't fully turn off bounding as it did in v3.6 
and prior.


Other random ramblings
----------------------

- The quartic drop is inside the box.

- The drops IOR treatment is backward in cases where it showed up in the 
shipped test case.

- In my povr branch once it was getting the proper IOR / insided-ness 
treatments it was a noisy result without 'sturm on'. Probably similar 
will be seen in official releases, but povr's solvers are different.

- The issue here is not at all tangled in the order reduction code 
problems in the shipped versions of POV-Ray as I supposed might be so in 
the binary images group thread.

- I changed the scene so the box is using filtered transparency and a 
partially transparent inside texture to better see the box.

- Image attached with the user bounding in place and using -ur to turn 
off the stripping of such user bounding.

- It should be once user bounding is in place you can flip renders 
between -ur and +ur and see the infinite shape count reported in the 
text output change.

- How the insided-ness gets done is different shape to shape. I'm not 
sure the user bounding get's used to 'initialize' the insided-ness in 
all shapes. It might be inverse is sometimes needed too(e)
(e) - IIRC a few old shapes don't handle inverse correctly (quadrics one 
I think).

- Anytime the inside test is off/wrong resulting csg can be too, though, 
this not an issue with unions.

Bill P.

[Chris R] Re: Problem with transparent object and quartics [1380 days 16 hours and 53 minutes ago]

Mon, 27 Jun 2022 14:30:00 GMT

"Chris R" <car### [at] comcastnet> wrote:
> I found an issue when rendering a scene that included a quartic object with a
> water-like texture and interior, and a transparent box, (intended to hold
> media), in the same scene.  The original discussion can be found here:
>
>
https://news.povray.org/povray.binaries.images/thread/%3Cweb.62b4a6ddb354b68f4ebf5035cc1b6e%40news.povray.org%3E/
>
> I was able to simplify the scene down to just a few elements that cause the
> problem to appear, and have attached a scene file.  (It doesn't appear to depend
> on the resolution or AA settings in the render).
>
> In the scene, there is a quartic "drip" with translucent texture and an ior of
> 1.33 sitting behind a hollow box with a transparent pigment.  When I render it,
> the sides of the box become visible and seem to take on the texture/interior of
> the drip rather than the completely transparent texture I assigned.
>
> I will attach a sample rendering in a follow-up post.
>
> -- Chris R.

Here's a quick rendering of the bug

[Chris R] Problem with transparent object and quartics [1380 days 16 hours and 58 minutes ago]

Mon, 27 Jun 2022 14:25:00 GMT

I found an issue when rendering a scene that included a quartic object with a
water-like texture and interior, and a transparent box, (intended to hold
media), in the same scene.  The original discussion can be found here:

https://news.povray.org/povray.binaries.images/thread/%3Cweb.62b4a6ddb354b68f4ebf5035cc1b6e%40news.povray.org%3E/

I was able to simplify the scene down to just a few elements that cause the
problem to appear, and have attached a scene file.  (It doesn't appear to depend
on the resolution or AA settings in the render).

In the scene, there is a quartic "drip" with translucent texture and an ior of
1.33 sitting behind a hollow box with a transparent pigment.  When I render it,
the sides of the box become visible and seem to take on the texture/interior of
the drip rather than the completely transparent texture I assigned.

I will attach a sample rendering in a follow-up post.

-- Chris R.

[Cousin Ricky] Re: Union disables hollowness [1469 days 14 hours and 51 minutes ago]

Wed, 30 Mar 2022 16:31:30 GMT

On 2022-03-30 02:23 (-4), William F Pokorny wrote:
> 
> Try flipping the order of objects in the union with the inherited hollow
> and "I think" you'll get again a v3.6 result with v3.7 onward versions
> of POV-Ray.

Yes, it wasn't until after my initial post that I suspected this was the
same as issue #307.  Reversing the order confirmed that it is the same
bug.  In fact, I was the one who discovered it back in 2017, although it
was Christoph who figured out the nature of the bug.

> Overall, the issue has been well down on my 'povr' todo list for a long
> while because to me it's not clear what the right thing to do is. Seeing
> clearly will take a significant investigation I think.

It's still in triage on GitHub.

[Cousin Ricky] Re: Union disables hollowness (issue #307) [1469 days 14 hours and 55 minutes ago]

Wed, 30 Mar 2022 16:27:28 GMT

On 2022-03-29 02:13 (-4), Thomas de Groot wrote:
> Op 28/03/2022 om 20:33 schreef Cousin Ricky:
>> Never mind.Â  I did some further testing, and discovered that this is the
>> same bug as GitHub issue #307.
> 
> 
> Wasn't this the problem with fog{} ?

No, the problem wasn't fog{}; it was an inappropriate override of
'hollow', which killed the media, or in this most recent case, fog.

https://news.povray.org/povray.binaries.scene-files/thread/%3C596094bf%241%40news.povray.org%3E/

[William F Pokorny] Re: Union disables hollowness [1470 days 1 hour ago]

Wed, 30 Mar 2022 06:23:05 GMT

On 3/28/22 13:43, Cousin Ricky wrote:
> If a hollow object is included in a union, the hollow property is
> disabled.  This apparent bug was introduced in POV-Ray 3.7; the hollow
> property is inherited fine in 3.6.
> 
> The following scene illustrates the problem.  The left side shows the
> pole and pennant created separately.  The middle shows a union of the
> pole and pennant.  The right side shows a union of the pole and pennant,
> with an additional hollow keyword at the union level.

In years past, I've dug a little into object modifier propagation 
differences between v3.6 and v3.7+. IIRC a lot of them come from POV-Ray 
(v3.7+) now taking the default modifiers for the union(c) from the last 
object of the union rather than the first (a)(b).

Try flipping the order of objects in the union with the inherited hollow 
and "I think" you'll get again a v3.6 result with v3.7 onward versions 
of POV-Ray.

---

(a) - Whether this v3.6 to v3.7+ change is intentional or not I don't 
know. There was a lot of C++ - ification after v3.6 and, it could just 
be this happened on the conversion to std::vector.

(b) - A useful bit of confirmation for me, if the order flip works for 
v3.7+, would be to know whether the same flip causes v3.6 to return the
the darker blue?

(c) - IIRC the differences in modifier defaulting are not confined to 
'union' csg.

---

Overall, the issue has been well down on my 'povr' todo list for a long 
while because to me it's not clear what the right thing to do is. Seeing 
clearly will take a significant investigation I think.

Questions in your scene start with a mesh using hollow without a well 
defined interior. They move on to what's right for hollow with fog.

Fog is an after effect which traces to the first surface it sees after 
which it calculates an effective result. Why did/does 'hollow' change 
the 'fog' result at all? I'm suggesting the dark blue is the 'correct' 
result - and an issue unrelated to the modifier union inheritance changes.

I don't immediately know 'why' we get the fog blue over the dark blue 
background. Is it the ordering of triangle vertices so the normal 
direction is such that the surface intersection with the mesh 'looks 
like' the backside of an object? Something else custom with hollow itself?

I'm rambling about the 'hollow' modifier alone. What about other 
modifiers in csg between v3.6 and v3.7+ ? All modifiers would need to be 
considered for a complete response.

Bill P.

[Thomas de Groot] Re: Union disables hollowness (issue #307) [1471 days 1 hour and 9 minutes ago]

Tue, 29 Mar 2022 06:13:37 GMT

Op 28/03/2022 om 20:33 schreef Cousin Ricky:
> On 2022-03-28 13:43 (-4), Cousin Ricky wrote:
>> If a hollow object is included in a union, the hollow property is
>> disabled.  This apparent bug was introduced in POV-Ray 3.7; the hollow
>> property is inherited fine in 3.6.
> 
> Never mind.  I did some further testing, and discovered that this is the
> same bug as GitHub issue #307.


Wasn't this the problem with fog{} ?

-- 
Thomas

[Cousin Ricky] Re: Union disables hollowness (issue #307) [1471 days 12 hours and 50 minutes ago]

Mon, 28 Mar 2022 18:33:10 GMT

On 2022-03-28 13:43 (-4), Cousin Ricky wrote:
> If a hollow object is included in a union, the hollow property is
> disabled.  This apparent bug was introduced in POV-Ray 3.7; the hollow
> property is inherited fine in 3.6.

Never mind.  I did some further testing, and discovered that this is the
same bug as GitHub issue #307.

[Cousin Ricky] Re: Union disables hollowness [1471 days 13 hours and 30 minutes ago]

Mon, 28 Mar 2022 17:52:47 GMT

On 2022-03-28 13:43 (-4), Cousin Ricky wrote:
> If a hollow object is included in a union, the hollow property is
> disabled.  This apparent bug was introduced in POV-Ray 3.7; the hollow
> property is inherited fine in 3.6.
> 
> The following scene illustrates the problem.  [snip]

I forgot to say, this scene has a dark blue background with a light blue
ground fog.  The pennants are rectangular objects with a transparent
pigment for the non-triangular parts.  The bug manifests as the dark
background showing through the transparent parts of the pennant.

[Cousin Ricky] Union disables hollowness [1471 days 13 hours and 40 minutes ago]

Mon, 28 Mar 2022 17:43:10 GMT

If a hollow object is included in a union, the hollow property is
disabled.  This apparent bug was introduced in POV-Ray 3.7; the hollow
property is inherited fine in 3.6.

The following scene illustrates the problem.  The left side shows the
pole and pennant created separately.  The middle shows a union of the
pole and pennant.  The right side shows a union of the pole and pennant,
with an additional hollow keyword at the union level.

------------------------[BEGIN CODE]-------------------------
#version max (3.6, min (3.8, version));

//---------------- ENVIRONMENT -------------------

global_settings { assumed_gamma 1 }
#default { finish { diffuse 0.6 ambient <0.07, 0.08, 0.11> } }
background { blue 0.2 }
fog
{ fog_type 2
  distance 100000
  fog_alt 10000
  fog_offset 0
  color rgb <0.45, 0.6, 0.9>
}
light_source
{ <0, 1, -1> * 10000, rgb <1.05, 1.00, 0.97>
  parallel point_at 0
}

#include "screen.inc"
Set_Camera (<0.65, -0.4, -7>, <0.65, 0.1, 0>, 45)
Screen_Object
( text
  { ttf "cyrvetic" concat ("v", str (version, 0, 2)) 0.001, 0
    pigment { rgb 0 }
    scale 0.09
  },
  <0, 1>, <0.02, 0.02>, yes, 1
)

plane { y, -1 pigment { rgb 0.5 } }

//-------------------- TEST ----------------------

#declare p_Pennant = pigment
{ object
  { prism
    { -1, 1, 4, <0, 0>, <0, 1>, <1.5, 0.5>, <0, 0>
      rotate -90 * x
    }
    color rgbt 1 color red 1
  }
}
#declare Penant = mesh
{ triangle { <0, 0, 0>, <0, 1, 0>, <1.5, 1, 0> }
  triangle { <0, 0, 0>, <1.5, 1, 0>, <1.5, 0, 0> }
  pigment { p_Pennant }
  hollow
}

#declare Pole = cylinder
{ -y, 1.1 * y, 0.06 translate -0.1 * x
  pigment { rgb 0.8 }
}

#declare SPACE = 1.85;

// Separate objects
object { Penant translate -SPACE * x }
object { Pole translate -SPACE * x }

// Union with inherited hollow
union
{ object { Penant }
  object { Pole }
}

// Union with redundant hollow
union
{ object { Penant }
  object { Pole }
  hollow
  translate SPACE * x
}
-------------------------[END CODE]--------------------------

POV-Ray 3.8 (not shown) renders the same as 3.7.

[Kenneth] Re: file write fail ignored [1610 days 7 hours and 22 minutes ago]

Wed, 10 Nov 2021 00:01:06 GMT

Dick Balaska <dic### [at] buckosoftcom> wrote:
> On 10/13/2021 5:32 PM, Kenneth wrote:
>
> > Yes, that's the way it has been (in Windows versions) since the state-file
> > feature was added. I thought this was by design(!) It's usually not a
> > problem...

>
> Add to your .ini file
> Create_Continue_Trace_Log=Off
>
> I, too, do only animations and hate it when those random state files,
> that I'll never use, don't get deleted.
>

Thanks! I had forgotten about that feature.

[Dick Balaska] Re: file write fail ignored [1616 days 3 hours and 53 minutes ago]

Thu, 4 Nov 2021 03:30:01 GMT

On 10/13/2021 5:32 PM, Kenneth wrote:

> Yes, that's the way it has been (in Windows versions) since the state-file
> feature was added. I thought this was by design(!) It's usually not a problem--
> I just delete the file when not needed-- unless it happens to get made while
> rendering (and stopping) animations. Then it sometimes shows up within the
> sequence of images in my output-image folder (because I usually do not use the
> state-file to 'continue the trace' during such renders.) My animation apps then
> stop processing any further images at the point where that file is detected--
> but that's just a temporary annoyance, until I delete it.
> 

Add to your .ini file
Create_Continue_Trace_Log=Off

I, too, do only animations and hate it when those random state files, 
that I'll never use, don't get deleted.

dik

[Kenneth] Re: file write fail ignored [1637 days 9 hours and 48 minutes ago]

Wed, 13 Oct 2021 21:35:00 GMT

William F Pokorny <ano### [at] anonymousorg> wrote:
>
> (1) - Yep, and with this, we picked up a related puzzle with radiosity.
> Parts of the samples related code is running all the time! Meaning
> whether we have radiosity in the scene or not, whether the quality level
> supports radiosity or not - this samples code runs for each render
> block.

Wow! Good detective work.

>
> (2) - I learned yesterday the state file location is derived from the
> output image location! I wrongly thought the state file (aka continue
> trace log) was always local to where the render command was issued, but
> it ends up wherever you write the output image file.

Yes, that's the way it has been (in Windows versions) since the state-file
feature was added. I thought this was by design(!) It's usually not a problem--
I just delete the file when not needed-- unless it happens to get made while
rendering (and stopping) animations. Then it sometimes shows up within the
sequence of images in my output-image folder (because I usually do not use the
state-file to 'continue the trace' during such renders.) My animation apps then
stop processing any further images at the point where that file is detected--
but that's just a temporary annoyance, until I delete it.

[William F Pokorny] Re: file write fail ignored [1637 days 15 hours and 15 minutes ago]

Wed, 13 Oct 2021 16:08:05 GMT

On 10/13/21 10:44 AM, jr wrote:
> hi,
> 
> William F Pokorny <ano### [at] anonymousorg> wrote:
>> On 10/9/21 3:49 AM, jr wrote:
>>> William F Pokorny <ano### [at] anonymousorg> wrote:
>>>> On 10/6/21 5:01 AM, jr wrote:
>>>>> ...
>>>> This a bug is basically the same as the radiosity file append bug.
>>           x
>>> a known issue, ok.  thanks.
>>
>> No. Well, it perhaps now is.
> 
> good, I think.  :-)
> 
> 
>> ...
>> I've not spent much time with POV-Ray's IO code.
> 
> sounds like opening a can of worms, only to find a multi-pack of can of worms
> inside..  think it .. bad not to have access to (tech) notes dealing with design
> etc of the "new" IO class.  bazaar, huh?!
> 
> coincidentally, have just posted a new macro in p.text.scene-files, 'Filed()', a
> CSV file handler, hope you'll find that useful when "stirring the worms" ;-).
> 

Thanks jr, I'll use it do some testing.

--- An update

+ Using 'if ((fid != nullptr) && (*fid))' is frequently proving useful.

+ My additional concern in radiosity.cpp's Save was justified. We are 
sometimes running the Save() code per render block(1) - without 
complaint from POV-Ray - when we in fact don't have a valid file handle. 
This particular issue is fixed in povr.

+ In many places finding the IO checking to be correct, which is good 
news. The less good news is, in a number of those situations, the code 
to generate messages for the end user is commented out or too generic to 
be of much help(2).

+ Unfortunately, we are often failing in complete silence. Stuff 
sometimes runs cleanly to all appearances, when there are in fact user 
file specification issues.

+ With povr, I've checked in a set of updates to add and/or improve 
warning/error messages both where the file IO checking was OK and where 
it was not. For example, I made changes to the previous randiosity.cpp 
samples file fix so that we now generate messages related to the 
radiosity samples file usage.

+ I think I now understand some of what changed v3.7 to v3.8 to 
introduce issues with the fopen keyword and invalid files.

+ I've got doubts about getting everything scrubbed anytime soon. Given 
the code (the IO class usage) is different file to file, use to use over 
a large code base. I don't currently see any easy way to flag potential 
problems aside from trying things and reviewing code.

Bill P.

(1) - Yep, and with this, we picked up a related puzzle with radiosity. 
Parts of the samples related code is running all the time! Meaning 
whether we have radiosity in the scene or not, whether the quality level 
supports radiosity or not - this samples code runs for each render 
block. The 'additional radiosity concern,' fixed now in the povr branch, 
extended what code was always run due testing for only != nullptr 
(testing true for a valid file handle). A puzzle / optimization for 
another day.

(2) - I learned yesterday the state file location is derived from the 
output image location! I wrongly thought the state file (aka continue 
trace log) was always local to where the render command was issued, but 
it ends up wherever you write the output image file. Further, if your 
output image location is bogus, the error message seen relates to the 
state file and not the output image file - which is confusing. I changed 
the error messages in a way which I hope will help.

[jr] Re: file write fail ignored [1637 days 16 hours and 38 minutes ago]

Wed, 13 Oct 2021 14:45:00 GMT

hi,

William F Pokorny <ano### [at] anonymousorg> wrote:
> On 10/9/21 3:49 AM, jr wrote:
> > William F Pokorny <ano### [at] anonymousorg> wrote:
> >> On 10/6/21 5:01 AM, jr wrote:
> >>> ...
> >> This a bug is basically the same as the radiosity file append bug.
>          x
> > a known issue, ok.  thanks.
>
> No. Well, it perhaps now is.

good, I think.  :-)

> ...
> I've not spent much time with POV-Ray's IO code.

sounds like opening a can of worms, only to find a multi-pack of can of worms
inside..  think it .. bad not to have access to (tech) notes dealing with design
etc of the "new" IO class.  bazaar, huh?!

coincidentally, have just posted a new macro in p.text.scene-files, 'Filed()', a
CSV file handler, hope you'll find that useful when "stirring the worms" ;-).

regards, jr.

[William F Pokorny] Re: file write fail ignored [1638 days 19 hours and 15 minutes ago]

Tue, 12 Oct 2021 12:07:47 GMT

On 10/9/21 3:49 AM, jr wrote:
> hi,
> 
> William F Pokorny <ano### [at] anonymousorg> wrote:
>> On 10/6/21 5:01 AM, jr wrote:
>>> ...
>> This a bug is basically the same as the radiosity file append bug.
         x
> 
> a known issue, ok.  thanks.
> 

Hi jr,

No. Well, it perhaps now is. I wasn't smart enough to consider the 
radiosity sample file issue might indicate a general problem.

If you see other similar file/IO issues, please report them. Thanks to 
you both for reporting this one. Internally, it led to two issues in 
that the write and append modes were both not working.

---
I'd taken the radiosity samples file bug to be a one off problem. On 
seeing the same root cause for this fopen keyword issue, it's looking 
more like a systemic problem with user file IO in v3.8. :-(

While away from my computer the past few days, I found myself thinking 
about this issue. And prior to leaving, I'd looked back through the 
radiosity samples file fix to radiosity.cpp; This time looking at other 
IStream/OStream class usage. I saw additional concerning code.

I've not spent much time with POV-Ray's IO code. We have an IO class 
which doesn't end up as nullptr on a failed open, but rather an 
allocated class object with extra information - like the file name. Our 
our always allocated 'file handle, handler' can be in a fail state or 
not. That state could be due an attempt to open a file - or I guess any 
other cause thereafter.

I'm far from understanding all the particulars - including not 
understanding what changed in the v3.7 to v3.8 work that we have these 
issues popping up. There was obviously some IO class work - and quite a 
lot of code re-factoring around IO. I found a commit from 2018 making 
changes so the #read directive 'again worked.' Did #read not work in 
v3.7 and/or some other post v3.7 versions?

Further, I'm unsure why the FOPEN, Parse_Fopen() code is using a 
shared_ptr<IStream> when I see no reason for a shared pointer(1). The 
v3.7 code doesn't use a shared_ptr.

Plus, for the read code, there is extra code appending common suffixes 
(I guess potentially .csv here?) before failing. On unix/linux I'd like 
all the 'guess a file suffix' code gone! I believe, even on windows 
where suffixes are hidden by default, this 'guess a suffix' code likely 
causes user confusion as often as not(2).

Oh, I think I might now understand why using the 'if (*readPtr)' was 
causing  segfaults. It's that the particular 'open for read' code - 
looking for files while guessing suffixes - is 'sometimes' returning 
simply 'nullptr'.

So, sometimes, the 'if (fid != nullptr)' test is what you have to use 
while elsewhere you need 'if (*fid)'. This suggests, to be robust, we 
should be using 'if ((fid != nullptr) && (*fid))' in the latter case. 
Hmm... Or maybe in all cases as it should be safe and it's consistent!

I guess, I should spend time digging into POV-Ray's IO code though I'd 
rather be playing elsewhere... :-(

Bill P.

(1) - I had the thought, maybe with shared_ptr() what the coder was 
after was safe clean up when the last referencing object went out of 
scope / was deleted. But, if so, why wasn't the same thing done with the 
write and append OStream pointers... And if cleanup the reason, I think, 
these days, a unique_ptr is likely better.

(2) - "Cannot find file 'fopen_HAPPY_r.inc', even after trying to append 
file type extension." <-- Message used where it doesn't makes sense 
given the passed file name already has a valid extension and POV-Ray 
should not be second guessing the user.

[jr] Re: file write fail ignored [1641 days 23 hours and 33 minutes ago]

Sat, 9 Oct 2021 07:50:00 GMT

hi,

William F Pokorny <ano### [at] anonymousorg> wrote:
> On 10/6/21 5:01 AM, jr wrote:
> > ...
> This a bug is basically the same as the radiosity file append bug.

a known issue, ok.  thanks.


regards, jr.

[William F Pokorny] Re: file write fail ignored [1644 days 19 hours and 53 minutes ago]

Wed, 6 Oct 2021 11:30:11 GMT

On 10/6/21 5:01 AM, jr wrote:
> hi,
> 
> -----<snip>-----
> #version 3.8;
> 
> global_settings {assumed_gamma 1}
> box {0,1}
> 
> #if (0)
> #declare dir_ = "/badName/";
> #else
> #declare dir_ = "/tmp/";
> #end
> 
> #declare arr_ = array [3] {"foo","bar","baz"};
> 
> #fopen fp_ concat(dir_,"wtest.txt") write
> 
> #for (i_,0,2)
>    #if (2 != i_) #local c_ = ","; #else #local c_ = ""; #end
>    #write (fp_,concat("\"",arr_[i_],"\"",c_))
> #end
> 
> #fclose fp_
> -----<snip>-----
> 
> when I change the '#if' to use a non-existing directory, the alpha.9945627 and
> beta.2, as well as WFP's povr, all silently ignore the fact that no file was
> (could be) created, and do not return an error.  both on Linux and Windows.
> 
> (thanks for the discovery goes to TdG who ran into this issue while testing some
> code of mine)
> 

This a bug is basically the same as the radiosity file append bug.

It looks like after v3.7 some file IO class work got done making the 
test for successful opens on write and append(a) 'if (*(wfile))' instead 
of the more common / expected 'if (wfile != nullptr)'.

(a) - Read too depending on the set up and usage.

To complicate things...

1) Though POV-Ray's IStream is using the same base class as OStream, 
because the read pointer is a shared_ptr, you must use
the usual 'if (rfile != nullptr)' test for success on reads. The 
override version in fact segfaults for me when I tried it - and I've not 
gotten my head around the C++ reason(s) why.

2) The read open success/fail, from a users perspective, is working but 
it's due overlapping code in a function called Locate_File() and not due 
the testing in Parse_Fopen(). Meaning, I think, but I'm too lazy to 
chase it at the moment, that the read 'if (rfile != nullptr)' is 
probably also not working in Parse_Fopen(), but we are covered so it 
doesn't matter.

3) Given this and the radiosity bug,I have to wonder if we have other 
file open write / append bugs in v3.8. What other file opens might be 
write or append in POV-Ray?

Anyhow, updates not checked in, but fopen write/append fixes will be in 
the next povr tarball.

Bill P.

[jr] file write fail ignored [1644 days 22 hours and 18 minutes ago]

Wed, 6 Oct 2021 09:05:00 GMT

hi,

-----<snip>-----
#version 3.8;

global_settings {assumed_gamma 1}
box {0,1}

#if (0)
#declare dir_ = "/badName/";
#else
#declare dir_ = "/tmp/";
#end

#declare arr_ = array [3] {"foo","bar","baz"};

#fopen fp_ concat(dir_,"wtest.txt") write

#for (i_,0,2)
  #if (2 != i_) #local c_ = ","; #else #local c_ = ""; #end
  #write (fp_,concat("\"",arr_[i_],"\"",c_))
#end

#fclose fp_
-----<snip>-----

when I change the '#if' to use a non-existing directory, the alpha.9945627 and
beta.2, as well as WFP's povr, all silently ignore the fact that no file was
(could be) created, and do not return an error.  both on Linux and Windows.

(thanks for the discovery goes to TdG who ran into this issue while testing some
code of mine)


regards, jr.

[William F Pokorny] Re: problem with '#break' in macro [1670 days 14 hours and 28 minutes ago]

Fri, 10 Sep 2021 16:54:33 GMT

On 9/10/21 11:26 AM, Kenneth wrote:
> William F Pokorny <ano### [at] anonymousorg> wrote:
>>
>> [source code snippets]
>>
>> The variation above works for me in all v3.7+ versions I have in hand.
>>
> 
> Just discovered that the following also produces the error and fails-- unless
> the #debug is there. Seems that in this case, the inner #end actually *needs*
> something to follow it! I tried adding #break and/or #end here and there
> (guesswork!) to try and MAKE it work without the #debug, but no luck so far.
> 
> #declare R = seed(4711);
> #for (I, 1, 100)
>    #if (rand(R) < 1.1) // always less than 1.1
>       #break // terminate loop early
>    #else
>    #end
>    // #debug concat(str(I,0,0), " iterations and counting\n")
> #end
> 
Thanks! This example a stinker - my hack doesn't fix it. I don't 
immediately see a way to handle this case. After the break it reads all 
the way to through the last '#end' in both v3.8 beta 2 and my hacked 
povr code.

In other words, by the time it's done with the work to read to the end 
of the block containing the break, the parser finds itself not inside 
any nested block from which to break.

If the #debug is not commented, it stops there and breaks from the for 
loop block.

Added your test case to the others. Unsure when I might pick up looking 
at it again.

Bill P.

[William F Pokorny] Re: problem with '#break' in macro [1670 days 14 hours and 43 minutes ago]

Fri, 10 Sep 2021 16:40:04 GMT

On 9/10/21 10:20 AM, jr wrote:
> hi,
> 
> William F Pokorny <ano### [at] anonymousorg> wrote:
>> On 9/7/21 5:34 AM, jr wrote:
>>> ...
>> My quick test as to whether on the right track was to create a scene
>> file like jr's original, but with macro internals looking like:
>>
>>     #if (f_)
>>       #debug "ok.\n"
>>     #else
>>       #debug "break.\n"
>>       #break
>>     #end
> 
> the intention in the code was using 'f_' as a guard, that is I added the '#else'
> only to demonstrate.
> 
Hi. What you coded is perfectly OK. I wasn't saying anything other than 
my re-code was some confirmation the 'else' token after the break was at 
the core of the problem. Your code should work!

Bill P.

[Kenneth] Re: problem with '#break' in macro [1670 days 15 hours and 53 minutes ago]

Fri, 10 Sep 2021 15:30:00 GMT

William F Pokorny <ano### [at] anonymousorg> wrote:
>
> [source code snippet]
> The code above works with the code variations recently posted. However,
> it's admittedly a slap shot. More thought and testing needed.
>
> My quick test as to whether on the right track was to create a scene
> file like jr's original, but with macro internals looking like:
>
>    #if (f_)
>      #debug "ok.\n"
>    #else
>      #debug "break.\n"
>      #break
>    #end
>
> The variation above works for me in all v3.7+ versions I have in hand.
>

Just discovered that the following also produces the error and fails-- unless
the #debug is there. Seems that in this case, the inner #end actually *needs*
something to follow it! I tried adding #break and/or #end here and there
(guesswork!) to try and MAKE it work without the #debug, but no luck so far.

#declare R = seed(4711);
#for (I, 1, 100)
  #if (rand(R) < 1.1) // always less than 1.1
     #break // terminate loop early
  #else
  #end
  // #debug concat(str(I,0,0), " iterations and counting\n")
#end

[jr] Re: problem with '#break' in macro [1670 days 16 hours and 58 minutes ago]

Fri, 10 Sep 2021 14:25:00 GMT

hi,

William F Pokorny <ano### [at] anonymousorg> wrote:
> On 9/7/21 5:34 AM, jr wrote:
>> ...
> My quick test as to whether on the right track was to create a scene
> file like jr's original, but with macro internals looking like:
>
>    #if (f_)
>      #debug "ok.\n"
>    #else
>      #debug "break.\n"
>      #break
>    #end

the intention in the code was using 'f_' as a guard, that is I added the '#else'
only to demonstrate.

> The variation above works for me in all v3.7+ versions I have in hand.

thanking both you and "the Southern Walker" ;-) for taking a look, I think
Kenneth's code is more illustrative of the problem.

regards, jr.

[William F Pokorny] Re: problem with '#break' in macro [1670 days 19 hours and 30 minutes ago]

Fri, 10 Sep 2021 11:52:25 GMT

On 9/7/21 5:34 AM, jr wrote:
> hi,
> 
> the docs say "Note: As of version 3.7 the #break directive can now be used: ...
> anywhere within a #macro to preliminarily terminate the macro."
> <https://wiki.povray.org/content/Reference:Conditional_Directives#Index_Entry_break>
> 
> but I get an error "File 'brktst.pov' line 10: Parse Error: Invalid context for
> #break", from both v3.7.0.8 and v3.8 POV-Rays.  the "scene":
> 
> #version 3.7;
> 
> global_settings {assumed_gamma 1}
> 
> #macro m_flag(f_)
>    #if (!f_)
>      #break
>    #else
>      #debug "ok.\n"
>    #end
> #end
> 
> m_flag(true)
> m_flag(false)
> 

Recently sidetracked by RL and otherwise focused elsewhere code wise...

Looking quickly, I think the function Parser::Break() in the file 
parser_tokenizer.cpp needs a test to handle seeing an 'else block' after 
the 'break' in the 'if block' when the if conditional tests true.

     while ( (Cond_Stack.size() > 1) &&
             (Cond_Stack.back().Cond_Type != WHILE_COND) &&
             (Cond_Stack.back().Cond_Type != FOR_COND) &&
             (Cond_Stack.back().Cond_Type != CASE_TRUE_COND) &&
             (Cond_Stack.back().Cond_Type != INVOKING_MACRO_COND) )

should read:

     while ( (Cond_Stack.size() > 1) &&
             (Cond_Stack.back().Cond_Type != WHILE_COND) &&
             (Cond_Stack.back().Cond_Type != FOR_COND) &&
             (Cond_Stack.back().Cond_Type != ELSE_COND) &&
             (Cond_Stack.back().Cond_Type != CASE_TRUE_COND) &&
             (Cond_Stack.back().Cond_Type != INVOKING_MACRO_COND) )

The code above works with the code variations recently posted. However, 
it's admittedly a slap shot. More thought and testing needed.

My quick test as to whether on the right track was to create a scene 
file like jr's original, but with macro internals looking like:

   #if (f_)
     #debug "ok.\n"
   #else
     #debug "break.\n"
     #break
   #end

The variation above works for me in all v3.7+ versions I have in hand.

Bill P.

[Kenneth] Re: problem with '#break' in macro [1670 days 21 hours and 8 minutes ago]

Fri, 10 Sep 2021 10:15:00 GMT

This is more strange than I thought.

Compare these two #for-loop examples. The first is my modified version-- fatal
error; the 2nd is almost identical to the doc's example, which *does* at least
parse OK. The only difference is where the #debug(...) is placed. The 1st
version is kind of like your #macro, with the inner #else actually being used
for something; the 2nd makes no use of the #else, and successfully parses. I
have no idea as to why there should be a difference.

// [doc's version, slightly modified]
#local R = seed(4711);
#for (I, 1, 100)
  #if (rand(R) < 1.1) // always less than 1.1
       #break // terminate loop early
  #else
       #debug concat(str(I,0,0), " iterations and counting\n")
  #end
#end


// [doc's version, almost as-is]
#local R = seed(4711);
#for (I, 1, 100)
  #if (rand(R) < 1.1)
       #break // terminate loop early
  #else
  #end
       #debug concat(str(I,0,0), " iterations and counting\n")
#end

[Kenneth] Re: problem with '#break' in macro [1670 days 21 hours and 58 minutes ago]

Fri, 10 Sep 2021 09:25:00 GMT

[Windows 10, using one of the v3.8.0 'experimental' builds that piggy-back on
v3.7.0]

Confirmed, when  m_flag(false).

I also tried the #for-loop example given in the docs (slightly modified)...

#declare R = seed(4711);
#for (I, 1, 10)
  #if (rand(R) < 1.1)
     #break // terminate loop early
  #else
   #debug concat(str(I,0,0), " iterations and counting\n")
  #end
#end

Same fatal error message.

It would seem that these additional uses of #break were never actually
implemented(?)...or maybe that there is some undocumented extra syntax missing.

Just guesses, of course.

[jr] problem with '#break' in macro [1673 days 21 hours and 48 minutes ago]

Tue, 7 Sep 2021 09:35:00 GMT

hi,

the docs say "Note: As of version 3.7 the #break directive can now be used: ...
anywhere within a #macro to preliminarily terminate the macro."
<https://wiki.povray.org/content/Reference:Conditional_Directives#Index_Entry_break>

but I get an error "File 'brktst.pov' line 10: Parse Error: Invalid context for
#break", from both v3.7.0.8 and v3.8 POV-Rays.  the "scene":

#version 3.7;

global_settings {assumed_gamma 1}

#macro m_flag(f_)
  #if (!f_)
    #break
  #else
    #debug "ok.\n"
  #end
#end

m_flag(true)
m_flag(false)


regards, jr.

[Bald Eagle] Re: initialise array from csv file [1675 days 14 hours and 43 minutes ago]

Sun, 5 Sep 2021 16:40:00 GMT

"jr" <cre### [at] gmailcom> wrote:
> hi,
>
> I am trying to initialise an array via an '#include', as described in clipka's
> message <http://news.povray.org/52dab911%40news.povray.org>.  but, no dice with
> the three versions I tried: v3.8 alpha.9945627 and beta.2, and v3.7.0.8.
>
> the test data:
> $ cat tst.csv
> 1,2,3,4,
> 5,6,7,8,
> 9,10,11,12,
> 13,14,15,16
> $
>
> in the scene I use:
>
> #declare arr_ = array [16] { #include "tst.csv" };
>
> I get two different error messages, v3.7.0.8: "Parse Error: Insufficent number
> of initializers".  and for the v3.8 POV-Ray's: "Parse Error: Expected 'array
> initializer element', # found instead".
>
>
> regards, jr.

I think that just because of the way the parser works, certain implementations
and syntax structures are allowed - and able to be properly recognized/tokenized
and accepted by the parser, and others aren't.

You may have to resort to reading in your csv file with a loop and individually
assigning array elements.

try getting rid of the [16] and see what that gets you.
try your nice little () parsing trick
maybe a macro inside the {} would work

I got tied up with a surprise project, and it's eating up my weekend.

- Bill

[jr] initialise array from csv file [1675 days 19 hours and 43 minutes ago]

Sun, 5 Sep 2021 11:40:00 GMT

hi,

I am trying to initialise an array via an '#include', as described in clipka's
message <http://news.povray.org/52dab911%40news.povray.org>.  but, no dice with
the three versions I tried: v3.8 alpha.9945627 and beta.2, and v3.7.0.8.

the test data:
$ cat tst.csv
1,2,3,4,
5,6,7,8,
9,10,11,12,
13,14,15,16
$

in the scene I use:

#declare arr_ = array [16] { #include "tst.csv" };

I get two different error messages, v3.7.0.8: "Parse Error: Insufficent number
of initializers".  and for the v3.8 POV-Ray's: "Parse Error: Expected 'array
initializer element', # found instead".


regards, jr.

[Kenneth] Re: bump maps inverted in spherical warp [1704 days 7 hours and 38 minutes ago]

Sat, 7 Aug 2021 23:45:00 GMT

"Kenneth" <kdw### [at] gmailcom> wrote:

> My guess is that the 'dummy' pattern is not imposed on the pbfr texture
> because there is only one entry in the texture_map's index... so the dummy
> pattern doesn't matter.
>
> ... and the texture_map supplies the 'hook' for the warp{...}, that Clipka
mentioned.

[Kenneth] Re: bump maps inverted in spherical warp [1704 days 11 hours and 23 minutes ago]

Sat, 7 Aug 2021 20:00:00 GMT

Cousin Ricky <ric### [at] yahoocom> wrote:
> On 2021-08-05 2:40 AM (-4), Kenneth wrote:
> >
> > Apparently, a warp{...} cannot be added to a previously-#declared texture. I
> > sometimes run into similar problems; some things can be added, some can't.
>
> ...I should share the solution Thomas suggested to me, which
> worked well.
>
>   https://news.povray.org/54eb1a57@news.povray.org

That's an interesting trick!

Here's Thomas's example:

texture {
   granite
   texture_map {
     [0 MyTexture1] // pre-#declared texture
     [1 MyTexture2] // pre-#declared texture
   }
   warp {turbulence 1}
}

Modified a little, it works for the OP's problem:

#declare tmoon =
texture{
      gradient x // [a simple DUMMY pattern, because some kind of pattern is
                 // needed for a texture_map]
      texture_map{
       [.5 pbfr] // the pre-#declared texture-- and only one entry
            }
      warp{turbulence .2}
 }

My guess is that the 'dummy' pattern is not imposed on the pbfr texture
because there is only one entry in the texture_map's index... so the dummy
pattern doesn't matter.

Here's a small test scene of my own:
-------
#version 3.7; // or 3.8
global_settings{assumed_gamma 1.0}

camera {
  perspective
  location  <.5, .5, -1>
  look_at   <.5, .5,  0>
  right     x*image_width/image_height
  angle 67
}

background{rgb .1}

// my own pre-#declared texture
#declare pbfr =
texture{
 pigment{hexagon rotate 90*x scale .1}
 finish{ambient 1 emission 0 diffuse 0}
 }

// adding a warp(...) to the #declared texture...
#declare tmoon =
texture{
      gradient x // [DUMMY pattern]
      texture_map{
          [.5 pbfr]
                }
      warp{turbulence .2}
 }

box{0,<1,1,.1>
texture{tmoon}
}
--------

BTW, warp{spherical} also works-- but with that I see tiny speckles that look
like coincident surface problems(??). It's not due to the earlier hexagon
pattern; I substituted 'bumps' there and still see some speckles. Maybe due to
the texture_map trick itself, somehow? Or the final box's position?

[Cousin Ricky] Re: bump maps inverted in spherical warp [1705 days 6 hours and 7 minutes ago]

Sat, 7 Aug 2021 01:16:14 GMT

On 2021-08-05 2:40 AM (-4), Kenneth wrote:
> 
> Apparently, a warp{...} cannot be added to a previously-#declared texture. I
> sometimes run into similar problems; some things can be added, some can't.

I just remembered I ran into this problem a few years ago.  Now that
clipka has convincingly explained why this falls squarely into "feature"
category, I should share the solution Thomas suggested to me, which
worked well.

  https://news.povray.org/54eb1a57@news.povray.org

[clipka] Re: bump maps inverted in spherical warp [1705 days 19 hours and 47 minutes ago]

Fri, 6 Aug 2021 11:35:59 GMT

Am 06.08.2021 um 02:20 schrieb William F Pokorny:

> If I comment that last warp{}, and un-comment two warp{}s above - or use 
> instead the plain pigment inside the texture with the warp{}, I get no 
> complaint about any 'pointless' warps(a) - though some of them certainly 
> are.

The primary reason is that textures - in general - are nothing but mere 
containers to bundle pigments, finishes and normal perturbations into a 
coherent unit. As such, they provide no functionality of their own.

Specifically, they have no "hook" built into them to plug a warp into.


Exceptions to the rule are patterned and layered textures, which both 
add extra functionality of their own. And patterned textures do provide 
a "hook" for a warp to plug into.


Yes, in theory we could have non-patterned textures propagate any warps 
to their pigments, finishes and normals. We mustn't do that for 
patterned textures though. Also, what should happen if the pigment, 
finish or normal already has a warp? Should the texture warp be ignored, 
appended, prepended, or override the pigment/finish/normal warp? What 
should happen in this context to things that may or may not be converted 
into warps under the hood, such as turbulence?

It would also mean that we'd have to add room for extra data to the 
generic texture data structure, at least during parsing, because we 
can't propagate the warp before the scene has been fully assembled: The 
texture could be re-used someplace else and the pigment replaced with a 
different one, for instance, in which case that new one would also have 
to have the warp propagated to it.
And currently we're using the same data structures for both parsing and 
rendering, so any extra memory we reserve for the parsing step is also 
memory that will be unavailable during the render proper for other 
stuff, such as storing image data, radiosity samples, photon maps and 
the like. It would also be unused memory sitting right in the middle of 
other data we might need frequently, potentially displacing useful data 
from the CPU caches and thus maybe even dragging down performance.

TL;DR: I think there are too many worms in that can to open it up 
without need.

[Bald Eagle] Re: bump maps inverted in spherical warp [1706 days 6 hours and 18 minutes ago]

Fri, 6 Aug 2021 01:05:00 GMT

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

> I think you've got it Bill. The behavior, though, looks inconsistent to
> me. Maybe if I think about it more, it's how it must be?

Well, there are so many ways to go about it.

> (a) - Not done any debugging to see if the 'pointless' warps / modifiers
> end up used.
>
> Aside 1: turbulence{} trips this parse error too.
>
> Aside 2: transforms can be pointless too and like turbulence and warp we
> 'sometimes' get PossibleError warnings for those though I'm not aware of
> any hard errors there.

Indeed.  However, I would imagine that one might code up something that just
loops through a bunch of things that these may or may not have any visible
effect on, and it's just a throwaway operation for those instances.

> Aside 3: With image based mapping, the usual approach would be to use
> the appropriate map type inside the bump_map{} block - here 'map_type 1'
> spherical - though the warp{spherical} modifier should work too.

Probably the best approach, I would imagine.   Tailor made for the purpose.

> Aside 3a: There is too 'uv_mapping' for spheres which can be used inside
> texture, pigment and normal blocks.

There is, though I still haven't figured out how to separate the the normal from
the uv mapped texture...  Someday...

> :-) Nothing if not lots of knobs,  buttons and switches!

No.  Kidding.
There are days when I am truly astounded that all of the bits of things the user
wants to do and demands of the parser and modifier hierarchy all more or less
work after processing billions of cycles of under-the-hood raytracing black
magic.

[William F Pokorny] Re: bump maps inverted in spherical warp [1706 days 7 hours and 3 minutes ago]

Fri, 6 Aug 2021 00:20:11 GMT

On 8/5/21 6:10 PM, Bald Eagle wrote:
> "pkoning" <nomail@nomail> wrote:
> 
>> That doesn't seem to be the explanation.  I rewrote it without any declared
>> identifiers and it still fails:
> 
>> Same message, complaining about the warp.
> 
> Because you have it in the wrong place.
> You have a plain srgb pigment - no _pattern_.  So there is nothing to warp.
> Move the warp up into the normal statement and it works.
> 
> #declare tmoon = texture
> {
>    pigment { color srgb <0.55 0.60 0.65> }
>    finish { specular 0.1 }
>    normal {
>      bump_map {
>        png "plasma2.png"
>        bump_size 8e-3 *5
>      }
>      warp {spherical}
>    }
> 
>    scale <rfeature, rfeature * 2, 1>
>    no_bump_scale
> }
> 

I think you've got it Bill. The behavior, though, looks inconsistent to 
me. Maybe if I think about it more, it's how it must be?

Looking at something like this:

//---
#version 3.8;
global_settings { assumed_gamma 1 }

#declare pmoon = pigment {
     color rgb <0.55 0.60 0.65> warp {spherical}
}
#declare tmoon = texture {
     // pigment { color rgb <0.55 0.60 0.65> warp { spherical } }
     pigment {
         function { 0.5 }
         color_map {
             [ 0 color rgb <0.55 0.60 0.65> ]
             [ 1 color rgb <0.55 0.60 0.65> ]
         }
       //warp {spherical}
     }
     finish { specular 0.1 }
     normal {
         bump_map {
             png "plasma2.png"
              bump_size 8e-3 *5
         }
       //warp {spherical}
       }

     warp {spherical} // Parser sees this as illegal

     scale <1, 2, 1>
     no_bump_scale
}
//---

I get :

File 'hmm.pov' line 7: Possible Parse Error: Unmatched {
File 'hmm.pov' line 26: Parse Error: No matching }, warp found instead

If I comment that last warp{}, and un-comment two warp{}s above - or use 
instead the plain pigment inside the texture with the warp{}, I get no 
complaint about any 'pointless' warps(a) - though some of them certainly 
are.

There are likely situations where top level warps / turbulence could be 
applied and passed to contained blocks, but I believe it would be hard 
(impossible?) to do generally...

Drifting, the above examples touch on why I find myself sometimes 
wanting to be able to declare warp ids.

(a) - Not done any debugging to see if the 'pointless' warps / modifiers 
end up used.

Aside 1: turbulence{} trips this parse error too.

Aside 2: transforms can be pointless too and like turbulence and warp we 
'sometimes' get PossibleError warnings for those though I'm not aware of 
any hard errors there.

Aside 3: With image based mapping, the usual approach would be to use 
the appropriate map type inside the bump_map{} block - here 'map_type 1' 
spherical - though the warp{spherical} modifier should work too.

Aside 3a: There is too 'uv_mapping' for spheres which can be used inside 
texture, pigment and normal blocks.

:-) Nothing if not lots of knobs,  buttons and switches!

Bill P.

[Bald Eagle] Re: bump maps inverted in spherical warp [1706 days 9 hours and 8 minutes ago]

Thu, 5 Aug 2021 22:15:00 GMT

"pkoning" <nomail@nomail> wrote:

> That doesn't seem to be the explanation.  I rewrote it without any declared
> identifiers and it still fails:


> Same message, complaining about the warp.

Because you have it in the wrong place.
You have a plain srgb pigment - no _pattern_.  So there is nothing to warp.
Move the warp up into the normal statement and it works.

#declare tmoon = texture
{
  pigment { color srgb <0.55 0.60 0.65> }
  finish { specular 0.1 }
  normal {
    bump_map {
      png "plasma2.png"
      bump_size 8e-3 *5
    }
    warp {spherical}
  }

  scale <rfeature, rfeature * 2, 1>
  no_bump_scale
}

[pkoning] Re: bump maps inverted in spherical warp [1706 days 9 hours and 58 minutes ago]

Thu, 5 Aug 2021 21:25:00 GMT

"Kenneth" <kdw### [at] gmailcom> wrote:
> ...
> Apparently, a warp{...} cannot be added to a previously-#declared texture. I
> sometimes run into similar problems; some things can be added, some can't.
>
> Your syntax is like this:
>
> #declare tmoon = texture
> {
>   pbfr // [previously-#declared]
>   scale <rfeature, rfeature * 2, 1>
>   no_bump_scale
>   warp {spherical}
> }
>
> Interestingly, the no_bump_scale *is* OK there. I was surprised at that.

That doesn't seem to be the explanation.  I rewrote it without any declared
identifiers and it still fails:

#declare tmoon = texture
{
  pigment { color srgb <0.55 0.60 0.65> }
  finish { moon_finish }
  normal {
    bump_map {
      png "robo-bfr.png"
      bump_size 8e-3 *5
    }
  }
  warp {spherical}
  scale <rfeature, rfeature * 2, 1>
  no_bump_scale
}

Same message, complaining about the warp.

[pkoning] Re: bump maps inverted in spherical warp [1706 days 10 hours and 3 minutes ago]

Thu, 5 Aug 2021 21:20:00 GMT

"Kenneth" <kdw### [at] gmailcom> wrote:
> "pkoning" <nomail@nomail> wrote:
>
> >
> > Just  now I tried to reproduce it but I'm seeing a different baffling issue:
> > when I take out the "cells" pattern and replace it by a reference to a plain
> > texture, the parser complains that the "warp" modifier is not expected.  See
> > attached.
> >
> > Possible Parse Error: Unmatched {
> >
> >  line 100
> > Parse Error: No matching }, warp found instead
>
> Apparently, a warp{...} cannot be added to a previously-#declared texture. I
> sometimes run into similar problems; some things can be added, some can't.
>
> Your syntax is like this:
>
> #declare tmoon = texture
> {
>   pbfr // [previously-#declared]
>   scale <rfeature, rfeature * 2, 1>
>   no_bump_scale
>   warp {spherical}
> }
>
> Interestingly, the no_bump_scale *is* OK there. I was surprised at that.

Yes, that's documented to affect the texture it is applied to and all its
offspring.

It's strange that warp works the way you mentioned, it makes it very hard to
use.  The fact that it's an undocumented behavior doesn't help.  (I suppose it
makes sense if it's considered a bug -- I think it should be.)

[Thorsten] Re: bump maps inverted in spherical warp [1706 days 21 hours and 40 minutes ago]

Thu, 5 Aug 2021 09:42:34 GMT

On 05.08.2021 09:28, Kenneth wrote:
> "pkoning" <nomail@nomail> wrote:
>>
>> ...the parser complains that the "warp" modifier is not expected.  See
>> attached.
>>
>> Possible Parse Error: Unmatched {
>> ...
>> Parse Error: No matching }, warp found instead
> 
> By the way: As Clipka pointed out in a another recent thread, those "unmatched
> {" warnings/errors are sometimes 'generic', in that they simply flag some kind
> of 'possible' error that isn't clearly known to the parser. Yeah, it's kind of
> confusing sometimes, to figure out what the true problem is. ;-)

Actually, the reason this is called "possible error" (my naming back 
then) has to do with the message driven changes to output from POV-Ray 
3.5 onward. Before, the parser would simply output to a text stream, so 
it was perfectly feasible to output some text somewhere and the next 
line would make sense out of it (from the user's perspective). However, 
there might be a long and complex call chain of internal parser 
functions between the place that detected the likely error and the place 
that actually knows it is an error.

In modern integrated development environments (IDEs) it is at last 
handled much better because the parsers hand them a full trace of all 
the steps they took to get where they are and the user gets a kind of 
trace where the parser went with each step and what it expected or 
allowed. So yes, error reporting evolved over the last 15 years. But it 
would require a very well structured parser, which POV-Ray doesn't have 
due to its age (and no, it is not easy to rewrite either, nor is it a 
beginner's task).

Thorsten

[Kenneth] Re: bump maps inverted in spherical warp [1706 days 23 hours and 53 minutes ago]

Thu, 5 Aug 2021 07:30:00 GMT

"pkoning" <nomail@nomail> wrote:
>
> ...the parser complains that the "warp" modifier is not expected.  See
> attached.
>
> Possible Parse Error: Unmatched {
>...
> Parse Error: No matching }, warp found instead

By the way: As Clipka pointed out in a another recent thread, those "unmatched
{" warnings/errors are sometimes 'generic', in that they simply flag some kind
of 'possible' error that isn't clearly known to the parser. Yeah, it's kind of
confusing sometimes, to figure out what the true problem is. ;-)

[Kenneth] Re: bump maps inverted in spherical warp [1707 days and 38 minutes ago]

Thu, 5 Aug 2021 06:45:00 GMT

"pkoning" <nomail@nomail> wrote:

>
> Just  now I tried to reproduce it but I'm seeing a different baffling issue:
> when I take out the "cells" pattern and replace it by a reference to a plain
> texture, the parser complains that the "warp" modifier is not expected.  See
> attached.
>
> Possible Parse Error: Unmatched {
>
>  line 100
> Parse Error: No matching }, warp found instead

Apparently, a warp{...} cannot be added to a previously-#declared texture. I
sometimes run into similar problems; some things can be added, some can't.

Your syntax is like this:

#declare tmoon = texture
{
  pbfr // [previously-#declared]
  scale <rfeature, rfeature * 2, 1>
  no_bump_scale
  warp {spherical}
}

Interestingly, the no_bump_scale *is* OK there. I was surprised at that.

[pkoning] Re: bump maps inverted in spherical warp [1707 days 16 hours and 58 minutes ago]

Wed, 4 Aug 2021 14:25:00 GMT

clipka <ano### [at] anonymousorg> wrote:
> Am 03.08.2021 um 22:19 schrieb pkoning:
> > I'm using a normal with a bump map, wrapped around a sphere using
> > warp{spherical}.  It looks normal in the northern hemisphere, but the bumps are
> > changed to depressions in the southern.
>
> This is a known issue that has been around for... well, ever since
> warped bump maps were first introduced, I guess.
>
> Sometimes the bumps even seem to turn "sideways".

And sometimes it doesn't happen.  Before today I haven't noticed it, though I
may have overlooked it.  In earlier tests I was using a plain texture instead of
the "cells" pattern, and then I don't remember seeing it.

Just  now I tried to reproduce it but I'm seeing a different baffling issue:
when I take out the "cells" pattern and replace it by a reference to a plain
texture, the parser complains that the "warp" modifier is not expected.  See
attached.

Possible Parse Error: Unmatched {

"/Users/pkoning/Documents/svn/tajemnica/bumpmap.pov"
 line 100
Parse Error: No matching }, warp found instead

[clipka] Re: bump maps inverted in spherical warp [1708 days and 16 minutes ago]

Wed, 4 Aug 2021 07:07:05 GMT

Am 03.08.2021 um 22:19 schrieb pkoning:
> I'm using a normal with a bump map, wrapped around a sphere using
> warp{spherical}.  It looks normal in the northern hemisphere, but the bumps are
> changed to depressions in the southern.

This is a known issue that has been around for... well, ever since 
warped bump maps were first introduced, I guess.

Sometimes the bumps even seem to turn "sideways".

[pkoning] bump maps inverted in spherical warp [1708 days 10 hours and 58 minutes ago]

Tue, 3 Aug 2021 20:25:00 GMT

I'm using a normal with a bump map, wrapped around a sphere using
warp{spherical}.  It looks normal in the northern hemisphere, but the bumps are
changed to depressions in the southern.
I've reproduced this on 3.8.0 alpha on Linux, as well as both 3.7 and 3.8 beta
on Macintosh.  Attached is a scene file that reproduces it (bumpmap.pov), along
with the two
bump map images it uses and the resulting image.  The "equator" on the image is
3 rows from the top, so you can see the top 3 rows are correct and the ones
below that are inverted.  (Light is above the camera.)
--paul

[jr] Re: alpha.9945627 "Constant" rounded [1708 days 15 hours and 13 minutes ago]

Tue, 3 Aug 2021 16:10:00 GMT

hi,

William F Pokorny <ano### [at] anonymousorg> wrote:
> On 8/1/21 7:02 AM, William F Pokorny wrote:
> ...
> --- The ini files need to look like:
> ...
> declare='S1="Heard.a"'

_thanks_.


regards, jr.

[William F Pokorny] Re: alpha.9945627 "Constant" rounded [1709 days 19 hours and 52 minutes ago]

Mon, 2 Aug 2021 11:30:25 GMT

On 8/1/21 7:02 AM, William F Pokorny wrote:
...
> 
> The ini parsing is somehow different than the command line parsing :-(.
> 
> Hmmm. I guess povray doesn't die during the actual ini parsing of the 
> string, maybe it just marks the type incorrectly as a float.
> 
...

OK. After a day banging around in code and wrapper scripts. On my Ubuntu 
20.04 system and I expect most unix/linux/osx, you can declare multiple 
strings and constants on the command line and in ini files - no matter 
the recent >v3.6 branch. Constants (excepting, for now, the upcoming 
povr branch) support only single float precision or a little less.

--- The ini files need to look like:

declare=D1=1.0123456789012348
declare='S1="Heard.a"'
declare=D2=2.0123456789012345
declare='S2="bump and"'
declare=D3=3.0123456789012342
declare='S3=" jumped=up = 2 times "'

--- The command line. Note extra quotes where spaces in string. The back 
slash escaped newline characters are not strictly needed and used for 
clarity.

p380b1 +mv3.8 +iFloatAndStrings.inc \
       declare=D1=1.0123456789012348 \
       declare=\'S1=\"Heard.a\"\' \
       declare=D2=2.0123456789012345 \
       declare=\'S2=\""bump and"\"\' \
       declare=D3=3.0123456789012342 \
       declare=\'S3=\""jumped up = 2 times"\"\'

--- The simplifications and complications

The povr branch - for some fix in the past I've not run down - allows 
simpler and more conventional command line quoting:

povr +mv3.8 +iFloatAndStrings.inc \
     declare=D1=1.0123456789012348 \
     declare=S1=\"Heard.a\" \
     declare=D2=2.0123456789012345 \
     declare=S2=\""bump and"\" \
     declare=D3=3.0123456789012342 \
     declare=S3=\""jumped up = two times"\"

There are wrapper script complications which had me chasing my backside 
for the better part of yesterday when you have strings with spaces. You 
must set the IFS (Internal Field Separator) environment variable in such 
scripts to newline characters.

With shell / 'sh' povray wrapper scripts this is done by adding two 
lines ahead of the use of the $@ argument passing / pass-through. Note, 
there is below, an invisible newline character between the single quotes.

IFS='
'

In bash / 'bash' povray wrapper scripts you need to add a similar 
setting with a single line ahead of the $@ use:

IFS=$'\n'

Expect other shell languages would need adjustments too and there are 
probably alternate methods to preserver the spaces. I'm a hack at shell 
wrapper scripts.

Bill P.

[William F Pokorny] Re: alpha.9945627 "Constant" rounded [1710 days 20 hours and 20 minutes ago]

Sun, 1 Aug 2021 11:02:22 GMT

On 7/29/21 9:22 AM, jr wrote:
...
>> Multiple declares on the command line should also be non-functional,
>> with only the last setting "surviving".
>>
>> I didn't actually test them in an INI file, but on the faux command line
>> on the Windows interface.
> all seems to work fine under Linux, see below.  did same test with beta.1, same
> results.
...

I had the thought on getting up this morning perhaps what Christoph was 
seeing for multiple declares not working (windows?) was also tangled in 
me 'not really' running the recent v3.8 beta 1. Perhaps v3.8 beta 1 has 
such issues. Running just now it does't - for float declarations.

My results (Ununtu 20.04) match jr's for all the v3.8 versions I tried 
including povr. Multiple declares of floats work.

What doesn't work is an ini file containing declares to strings:

declare=D1=1.0123456789012348
declare=S1=\"Heard\"
declare=D2=2.0123456789012345
declare=S2=\"a\"
declare=D3=3.0123456789012342
declare=S3=\"bump\"

I tried a good many quoting variations. In both p380b1 and my most 
recent povr I get:

Expected 'string expression', float function 'float identifier' found 
instead

'after' parsing the ini file and where I hit the SDL line:

#debug concat("S1 = ",S1," \n")

---
I'd make a bet, the above ini specific failing explains our current 
documentation for cmd/ini declares supporting only floats!

https://wiki.povray.org/content/Reference:Scene_Parsing_Options

The ini parsing is somehow different than the command line parsing :-(.

Hmmm. I guess povray doesn't die during the actual ini parsing of the 
string, maybe it just marks the type incorrectly as a float.

Bill P.

[jr] Re: alpha.9945627 "Constant" rounded [1713 days 17 hours and 58 minutes ago]

Thu, 29 Jul 2021 13:25:00 GMT

hi,

clipka <ano### [at] anonymousorg> wrote:
> Am 29.07.2021 um 13:50 schrieb William F Pokorny:
> > On 7/29/21 7:05 AM, clipka wrote:
> >> On a related note:
> >>
> >> - Multiple `Declare=...` settings in an INI file will not work as
> >> expected. Only one value will come through.
> >>
> >> - Using `Declare='Foo="..."'` cannot be used to declare an empty
> >> string. Trying to do so will give a string containing `"` (a single
> >> instance of the double quote character).
> >
> > Good catch. I just did see notices for your new issues. I did some
> > testing with multiple and mixed declares on the command line and those
> > worked OK, but only simple single declares for ini testing - I don't use
> > ini files myself except when working to debug a scene from someone else.
>
> Multiple declares on the command line should also be non-functional,
> with only the last setting "surviving".
>
> I didn't actually test them in an INI file, but on the faux command line
> on the Windows interface.

all seems to work fine under Linux, see below.  did same test with beta.1, same
results.


regards, jr.




jr@swift:1:wfp$ c### [at] xyzpov

#version 3.8;

global_settings {assumed_gamma 1}
box {0,1}

#declare s_ = datetime(now);

#debug concat("datetime v3.8 default: '",s_,"'.\n")

#if (defined(A))
  #debug concat("A = ",str(A,0,0),".\n")
#end

#if (defined(B))
  #debug concat("B = ",str(B,0,0),".\n")
#end

#if (defined(C))
  #debug concat("C = ",str(C,0,0),".\n")
#end


jr@swift:2:wfp$ c### [at] xyzini

width = 32
height = 32

display = off
render_console = off
statistic_console = off
output_to_file = off

input_file_name = xyz.pov

declare = A=4
declare = B=5
declare = C=6


jr@swift:3:wfp$ povparse xyz.pov declare=A=1 declare=B=2 declare=C=3
Persistence of Vision(tm) Ray Tracer Version 3.8.0-alpha.9945627.unofficial
  ...
==== [Parsing...] ==========================================================
datetime v3.8 default: '2021-07-29 13:15:35Z'.
A = 1.
B = 2.
C = 3.
==== [Rendering...] ========================================================
Rendered 1024 of 1024 pixels (100%)
POV-Ray finished


jr@swift:4:wfp$ povparse xyz
  ...
==== [Parsing...] ==========================================================
datetime v3.8 default: '2021-07-29 13:15:43Z'.
A = 4.
B = 5.
C = 6.
==== [Rendering...] ========================================================
Rendered 1024 of 1024 pixels (100%)
POV-Ray finished

[clipka] Re: alpha.9945627 "Constant" rounded [1713 days 18 hours and 26 minutes ago]

Thu, 29 Jul 2021 12:56:32 GMT

Am 29.07.2021 um 13:50 schrieb William F Pokorny:
> On 7/29/21 7:05 AM, clipka wrote:
>> On a related note:
>>
>> - Multiple `Declare=...` settings in an INI file will not work as 
>> expected. Only one value will come through.
>>
>> - Using `Declare='Foo="..."'` cannot be used to declare an empty 
>> string. Trying to do so will give a string containing `"` (a single 
>> instance of the double quote character).
> 
> Good catch. I just did see notices for your new issues. I did some 
> testing with multiple and mixed declares on the command line and those 
> worked OK, but only simple single declares for ini testing - I don't use 
> ini files myself except when working to debug a scene from someone else.

Multiple declares on the command line should also be non-functional, 
with only the last setting "surviving".

I didn't actually test them in an INI file, but on the faux command line 
on the Windows interface.

[William F Pokorny] Re: alpha.9945627 "Constant" rounded [1713 days 19 hours and 33 minutes ago]

Thu, 29 Jul 2021 11:50:13 GMT

On 7/29/21 7:05 AM, clipka wrote:
> On a related note:
> 
> - Multiple `Declare=...` settings in an INI file will not work as 
> expected. Only one value will come through.
> 
> - Using `Declare='Foo="..."'` cannot be used to declare an empty string. 
> Trying to do so will give a string containing `"` (a single instance of 
> the double quote character).

Good catch. I just did see notices for your new issues. I did some 
testing with multiple and mixed declares on the command line and those 
worked OK, but only simple single declares for ini testing - I don't use 
ini files myself except when working to debug a scene from someone else.

Bill P.

[clipka] Re: alpha.9945627 "Constant" rounded [1713 days 20 hours and 17 minutes ago]

Thu, 29 Jul 2021 11:05:35 GMT

On a related note:

- Multiple `Declare=...` settings in an INI file will not work as 
expected. Only one value will come through.

- Using `Declare='Foo="..."'` cannot be used to declare an empty string. 
Trying to do so will give a string containing `"` (a single instance of 
the double quote character).

[William F Pokorny] Re: alpha.9945627 "Constant" rounded [1714 days 18 hours and 16 minutes ago]

Wed, 28 Jul 2021 13:06:46 GMT

On 7/26/21 3:23 PM, clipka wrote:
> Am 26.07.2021 um 17:37 schrieb Cousin Ricky:
> 
>>> it appears that when I use a "Constant"[*] on the command-line, its 
>>> value gets
>>> rounded to six digits, see below.  for the alpha, and the current 
>>> beta.  (and
>>> 'povr')  have not tried from an ini file.
>>
>> This has been the case since 3.7.0.  POV-Ray 3.6 would read at least 9
>> digits, but was unreliable beyond 8 digits.
>>
>> I brought this up during the release candidate phase of 3.7, but nothing
>> was done.  The fact that it was changed from unreliable greater
>> precision to reliable lower precision suggests that the change was
>> deliberate, but I'd need confirmation from the developers.
>>
>>
https://news.povray.org/povray.beta-test/thread/%3Cweb.5019e866aa48f60685de7b680%40news.povray.org%3E/

>>
> 
...
> 
> I'll get that sorted out before the next beta, provided one of you folks 
> submits an issue report on GitHub to remind me.

See: https://github.com/POV-Ray/povray/issues/428

For those, like me, not realizing we can declare strings on the command 
line due:

https://wiki.povray.org/content/Reference:Scene_Parsing_Options,

it might be worth reading about the issue on github. Even in existing 
v3.7/v3.8 code strings can be defined in a useful - if not completely 
clean - manner.

Bill P.

[clipka] Re: alpha.9945627 "Constant" rounded [1716 days 12 hours ago]

Mon, 26 Jul 2021 19:23:19 GMT

Am 26.07.2021 um 17:37 schrieb Cousin Ricky:

>> it appears that when I use a "Constant"[*] on the command-line, its value gets
>> rounded to six digits, see below.  for the alpha, and the current beta.  (and
>> 'povr')  have not tried from an ini file.
> 
> This has been the case since 3.7.0.  POV-Ray 3.6 would read at least 9
> digits, but was unreliable beyond 8 digits.
> 
> I brought this up during the release candidate phase of 3.7, but nothing
> was done.  The fact that it was changed from unreliable greater
> precision to reliable lower precision suggests that the change was
> deliberate, but I'd need confirmation from the developers.
> 
>
https://news.povray.org/povray.beta-test/thread/%3Cweb.5019e866aa48f60685de7b680%40news.povray.org%3E/

Yeeeeah... digging through the code right now, and that's some very 
asinine code I'm looking at right there. Whoever made that change back 
in 2005 must have had their head screwed on backwards that day.

And I mean, VERY asinine.

I'll get that sorted out before the next beta, provided one of you folks 
submits an issue report on GitHub to remind me.

[Cousin Ricky] Re: alpha.9945627 "Constant" rounded [1716 days 15 hours and 45 minutes ago]

Mon, 26 Jul 2021 15:37:49 GMT

On 2021-07-26 7:46 AM (-4), jr wrote:
> 
> it appears that when I use a "Constant"[*] on the command-line, its value gets
> rounded to six digits, see below.  for the alpha, and the current beta.  (and
> 'povr')  have not tried from an ini file.

This has been the case since 3.7.0.  POV-Ray 3.6 would read at least 9
digits, but was unreliable beyond 8 digits.

I brought this up during the release candidate phase of 3.7, but nothing
was done.  The fact that it was changed from unreliable greater
precision to reliable lower precision suggests that the change was
deliberate, but I'd need confirmation from the developers.

https://news.povray.org/povray.beta-test/thread/%3Cweb.5019e866aa48f60685de7b680%40news.povray.org%3E/

[jr] alpha.9945627 "Constant" rounded [1716 days 19 hours and 33 minutes ago]

Mon, 26 Jul 2021 11:50:00 GMT

hi,

it appears that when I use a "Constant"[*] on the command-line, its value gets
rounded to six digits, see below.  for the alpha, and the current beta.  (and
'povr')  have not tried from an ini file.

[*] <https://wiki.povray.org/content/Reference:Scene_Parsing_Options#Constant>


regards, jr.



jr@swift:2:now$ c### [at] tstpov

#version 3.8;

global_settings {assumed_gamma 1}
box {0,1}

#if (!defined(Seed))
  #declare seed_ = mod((now-int(now))*1e16,1e9);
#else
  #declare seed_ = Seed;
#end

#debug concat("seed_ = ",str(seed_,0,0),".\n")

jr@swift:3:now$ povray tst.pov +w32 +h32 -d -f -gr -gs
Persistence of Vision(tm) Ray Tracer Version 3.8.0-alpha.9945627.unofficial
   ...
==== [Parsing...] ==========================================================
seed_ = 242007125.
==== [Rendering...] ========================================================
Rendered 1024 of 1024 pixels (100%)
POV-Ray finished

jr@swift:4:now$ povray tst.pov +w32 +h32 -d -f -gr -gs declare=Seed=242007125
  ...
==== [Parsing...] ==========================================================
seed_ = 242007000.
==== [Rendering...] ========================================================
Rendered 1024 of 1024 pixels (100%)
POV-Ray finished

[Bald Eagle] Re: alpha.10064268 macro problem [1773 days 18 hours and 43 minutes ago]

Sun, 30 May 2021 12:40:00 GMT

clipka <ano### [at] anonymousorg> wrote:

> ... and here I am, trying to CLEAN UP the parser code...
> *shrieks in horror*

"No one expects the Spanish Inquisition!"

Yeah - I'm not personally editing anything in that source code any time soon.
But I will do a few backflips on the SDL side to create some ugly hacks that
mimic the desired functionality.  As much as it sucked to implement, it worked
quite nicely, and I added some other things to invoke identifiers by numeric
identifier (so I could easily loop through all the defined objects in the scene
file) or an alias.

Gave a nice nesting diagram in the #debug stream too, labeling the entry and
exit of each control structure with a user-defined label.

[clipka] Re: TGA Alpha channel [1774 days 9 hours and 48 minutes ago]

Sat, 29 May 2021 21:35:19 GMT

Am 07.02.2021 um 12:08 schrieb William F Pokorny:

> As bugs go, a relatively easy one. :-)

It sure must have been hard work to create it in the first place... I 
have no idea how _that_ happened.

> In the file: source/base/image/targa.cpp and the function Write:
> 
> bool opaque = options.AlphaIsEnabled();
> 
> should be:
> 
> bool opaque = !options.AlphaIsEnabled();

Thanks. Confirming both diagnosis and remedy.

[clipka] Re: alpha.10064268 macro problem [1774 days 11 hours and 58 minutes ago]

Sat, 29 May 2021 19:25:19 GMT

Am 04.04.2021 um 19:48 schrieb Bald Eagle:
> Instead of a boolean, return an integer flag to be further processed.
> (POV-Ray treats any non-zero value as "true")
> Then you can initially process the result as a boolean like you do, but then
> have a follow-up procedure that instantiates the sphere, maybe using #select.
> 
> Or maybe you can just do that with the simple "boolean" as well...

Just skimming the thread, but from what I'm gathering, it seems that the 
crux of the matter is that there's some construct where a macro would 
essentially have to emit ("return") _two_ values separately: A status 
result (boolean, apparently) that would have to be plonked into an 
`#if(BOOLEAN)`, and an object that would have to be plonked elsewhere.

Fun fact: Unless my memory has been badly scrambled in the days of my 
abscence, modern POV-Ray v3.8 can do such exciting stuff, using 
tuple-style assignments, like so:

     #declare (Foo,Bar) = (VALUE1,VALUE2);

This allows you to design a macro that is structured like so (and as a 
matter of fact the syntax was introduced for exactly this very purpose):

     #macro Frobnitz()
         // Construct the stuff we want to emit ("return")
         #local V1 = ...;
         #local V2 = ...;
         // Actually emit ("return") the stuff, tuple-style
         (V1,V2)
     #end

And then invoke it from some other code like so:

     #declare (Foo,Bar) = Frobnitz();
     // test for `Foo`
     #if(Foo)
         // emit `Bar` to actually plonk it into the scene
         object { Bar }
     #end

Hope this helps.

Oh, and in case you have a macro that may not have an object to emit as 
the second value, try this (IIRC think it should work):

     #macro Frobnitz()
         #if(GOOD)
           #local V2 = ...;
           (true,V2)
         #else
           (false,)
         #end
     #end

And then invoke it from some other code like so:

     #declare Bar = sphere { ... } // provide default for Bar
     #declare (Foo, optional Bar) = Frobnitz();
     // test for `Foo`
     #if(Foo)
         // emit `Bar` to actually plonk it into the scene
         object { Bar }
     #end

(I'm not 100% sure I recall the `optional` semantics properly; IIRC it 
leaves the variable unchanged if no value is given, but it might also 
set it to undefined instead. Also, I'm not 100% the comma in `(false,)` 
is necessary or not. It's docomented... somewhere.)


Oh, and of course array- and vector-style assignments were also 
introduced on that occasion, just for funsies:

     #declare A = array[2] {VALUE1,VALUE2};
     #declare [Foo,Bar] = A; //(*)

     #declare V = <VALUE1,VALUE2>;
     #declare <Foo,Bar> = V;

(*) I _think_ that was the syntax. Mighth have been curly braces instead 
of square brackets though, i.e `#declare {Foo,Bar} = A;`. Again, it's 
documented... somewhere.

[clipka] Re: alpha.10064268 macro problem [1774 days 12 hours and 28 minutes ago]

Sat, 29 May 2021 18:54:52 GMT

Am 04.04.2021 um 02:40 schrieb Bald Eagle:

> I was also thinking that since we don't have an 'alias' directive, we might be
> able to track the nesting level with something like:
> 
> #macro If (A)
>       #declare Level = Level + 1;
>       #if (A)
> #end
> 
> and then a corresponding EndIf () macro could decrement the counter...

... and here I am, trying to CLEAN UP the parser code...
*shrieks in horror*

[clipka] Re: alpha.10064268 undef behaviour [1774 days 13 hours and 18 minutes ago]

Sat, 29 May 2021 18:04:34 GMT

Am 13.08.2020 um 15:23 schrieb William F Pokorny:

> In symboltable.cpp Christoph added:
> 
> // TODO See captured issue:
> // jr_Parse_alpha_10064268_to_10064268_Aug13_2020
>
//Â Â Â Â Â Â Â Â 
POV_EXPERIMENTAL_ASSERT((ttype != FLOAT_TOKEN_CATEGORY) &&
>
//Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â 
(ttype != FLOAT_ID_TOKEN) &&
>
//Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â 
(ttype != VECTOR_TOKEN_CATEGORY) &&
>
//Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â 
(ttype != COLOUR_TOKEN_CATEGORY));

Yeh, that's the offending statement; but...

> // I "think" Christoph wanted something like that below.
> // BUT! Why didn't he just differently order FLOAT_ID_TOKEN,
> // VECTOR_ID_TOKEN as he looks to have ordered COLOUR_ID_TOKEN
> // This looks like something not complete and certainly not clean.
> 
> 
Â Â Â Â Â Â Â 
POV_EXPERIMENTAL_ASSERT(((ttype != FLOAT_TOKEN_CATEGORY) ||
> 
Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â 
(ttype == FLOAT_ID_TOKEN)) &&
> 
Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â 
((ttype != VECTOR_TOKEN_CATEGORY) ||
> 
Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â 
(ttype == VECTOR_ID_TOKEN)) &&
> 
Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â 
(ttype != COLOUR_TOKEN_CATEGORY));

... that doesn't make any sense whatsoever, because `(ttype == 
FLOAT_ID_TOKEN)` can only hold true if `(ttype != FLOAT_TOKEN_CATEGORY)` 
is true anyway.

Nay, the answer is a different one. `(ttype != FLOAT_ID_TOKEN)` 
shouldn't have made it in there in the first place. Also, there's one 
*_CATEGORY value missing from the list, namely 
`SIGNATURE_TOKEN_CATEGORY`. Which for reasons of neatness should be the 
first in the list.

I'll commit a fix to the repo soon.

[jr] Re: alpha.10064268 macro problem [1827 days 21 hours and 18 minutes ago]

Tue, 6 Apr 2021 10:05:00 GMT

hi,

"Tor Olav Kristensen" <tor### [at] TOBEREMOVEDgmailcom> wrote:
> "jr" <cre### [at] gmailcom> wrote:
> >...
> > while on the subject, and given you seem interested :-), I'm pondering how to
> > reduce duplication of essentially identical/near identical code; am thinking
> > that an "odometer" type macro to compute the set of indices would allow me to
> > write much more "compact" walker macros.  any suggestions?  cheers.
>
> Bill's recent suggestion to you made me think of ways to iterate over the
> indices of an array.
>
> As my favorite programming language is Python, I tried out my ideas there.

chalk and cheese.  when, years ago, I heard that Python requires one to use
specific whitespace in order for the code to be "correct", I lost interest.

> So if you are familiar with Python, have a look at attached PDF-file.
> The code in the 2 last cells shouldn't be hard to convert to POV-Ray's SDL.

I had a v quick look just now, there are unfamiliar operators (like '//') so I'm
not sure, but it looks like I hit on the right idea when reducing 'Foreach()' to
calling the payload "product of dims" times[*].  (must have lucked out :-))
I'll try and find some time in next days to see whether I can replicate yr PDF
code in Tcl.

regards, jr.

[*] 20-odd lines in SDL isn't too shabby.

[Tor Olav Kristensen] Re: alpha.10064268 macro problem [1828 days 5 hours and 3 minutes ago]

Tue, 6 Apr 2021 02:20:00 GMT

"jr" <cre### [at] gmailcom> wrote:
>...
> while on the subject, and given you seem interested :-), I'm pondering how to
> reduce duplication of essentially identical/near identical code; am thinking
> that an "odometer" type macro to compute the set of indices would allow me to
> write much more "compact" walker macros.  any suggestions?  cheers.

Bill's recent suggestion to you made me think of ways to iterate over the
indices of an array.

As my favorite programming language is Python, I tried out my ideas there.

So if you are familiar with Python, have a look at attached PDF-file.
The code in the 2 last cells shouldn't be hard to convert to POV-Ray's SDL.

--
Tor Olav
http://subcube.com
https://github.com/t-o-k

[jr] Re: alpha.10064268 macro problem [1828 days 8 hours and 53 minutes ago]

Mon, 5 Apr 2021 22:30:00 GMT

hi,

"Bald Eagle" <cre### [at] netscapenet> wrote:
> I did a bit of hazy early-morning brainstorming.

(incorrigible  :-))

> You would be able to condense all of your nested #if statements if you were to
> write the largest one but then be able to skip certain nest levels.

the new code, published in p.t.scene-files a moment ago, is completely different
from previous.  for instance, only two walkers - void and bool.

> Can you use the parse thing to assemble a macro of the proper size on the fly?

don't see why it could not be used for that.

> Can conditionals be stored in an array?   Then you might be able to switch
> between #if and // nothing and #end and // nothing as needed.

never tried.  :-)


regards, jr.

[Bald Eagle] Re: alpha.10064268 macro problem [1828 days 9 hours and 38 minutes ago]

Mon, 5 Apr 2021 21:45:00 GMT

Also, will any of these help?

https://stackoverflow.com/questions/25070766/nested-for-loops-recursion

https://corysimon.github.io/articles/recursion/

https://www.vitoshacademy.com/vba-nested-loops-with-recursion/


etc...


https://duckduckgo.com/?q=nested+loops+by+recursive

[Bald Eagle] Re: alpha.10064268 macro problem [1828 days 10 hours and 3 minutes ago]

Mon, 5 Apr 2021 21:20:00 GMT

I did a bit of hazy early-morning brainstorming.

You would be able to condense all of your nested #if statements if you were to
write the largest one but then be able to skip certain nest levels.

Can you use the parse thing to assemble a macro of the proper size on the fly?

Can conditionals be stored in an array?   Then you might be able to switch
between #if and // nothing and #end and // nothing as needed.

Do we have some clever way to do the equivalent of:

select (flag, conditional // comment)

or

(flag ? conditional : comment)

Because that would be wicked cool.

[jr] Re: alpha.10064268 macro problem [1829 days 1 hour and 8 minutes ago]

Mon, 5 Apr 2021 06:15:00 GMT

hi,

"Tor Olav Kristensen" <tor### [at] TOBEREMOVEDgmailcom> wrote:
> "jr" <cre### [at] gmailcom> wrote:
> >...
> > :-)
> >
> > seriously though, thank you for this clear outline of "events".  excellent.  I
> > seem to think too much in terms of (conventional) function/procedure when using
> > SDL.  (time for coffee + thinking cap :-))
>
> No problem. It was an interesting challenge to find out what was going on.
> It can take a while to become familiar with how POV-Ray's macros really work and
> how they can be best utilized.

too true.  (I fear :-))

> Then back to your code:
> How about writing out (appending ?) all the "user macro" calls to a file while
> "walking" the array, and then include that file for parsing afterwards ?
> If you do it that way then the fore_call macro can return a single value
> suitable for the ! operator.

the thought never occurred, and, to be honest, does not appeal.  too "indirect"
for me, I guess.  having said that, I see no reason why the user could not write
a payload macro to do that, where useful.

> BTW: Are you aware that there are some macro parameters that are never used ?

off-hand I can only think of 'a_' in the 'fore_call'.  I thought I'd need it
since the 'cmd_' string refers to it (and I thought expansion happens in line
107).

while on the subject, and given you seem interested :-), I'm pondering how to
reduce duplication of essentially identical/near identical code; am thinking
that an "odometer" type macro to compute the set of indices would allow me to
write much more "compact" walker macros.  any suggestions?  cheers.

regards, jr.

[Tor Olav Kristensen] Re: alpha.10064268 macro problem [1829 days 8 hours and 38 minutes ago]

Sun, 4 Apr 2021 22:45:00 GMT

"jr" <cre### [at] gmailcom> wrote:
>...
> :-)
>
> seriously though, thank you for this clear outline of "events".  excellent.  I
> seem to think too much in terms of (conventional) function/procedure when using
> SDL.  (time for coffee + thinking cap :-))

No problem. It was an interesting challenge to find out what was going on.
It can take a while to become familiar with how POV-Ray's macros really work and
how they can be best utilized.

Then back to your code:
How about writing out (appending ?) all the "user macro" calls to a file while
"walking" the array, and then include that file for parsing afterwards ?
If you do it that way then the fore_call macro can return a single value
suitable for the ! operator.

BTW: Are you aware that there are some macro parameters that are never used ?

--
Tor Olav
http://subcube.com
https://github.com/t-o-k

[jr] Re: alpha.10064268 macro problem [1829 days 12 hours and 3 minutes ago]

Sun, 4 Apr 2021 19:20:00 GMT

"Bald Eagle" <cre### [at] netscapenet> wrote:
> "jr" <cre### [at] gmailcom> wrote:
> ...
> > good thought, yes.  (and your hunch that the problem lies in the .inc was spot
> > on too)
>
> I kinda thought it had to do with the fore_call, but I didn't catch that it was
> the #if statement operating ON the fore_call that was the real issue.
> TOK to the rescue again.
>
> > I'm not yet quite sure how, but the code needs to be .. re-structured.
> > one/the concern is the size of the .inc file; ironically,  the "troublesome"
> > 'fore_call()' was written to reduce duplication of code within the "walkers".
>
> Can't you just add the sphere right after the #if, or just add an #else,
> depending on when you want the sphere instantiated?

as I said, not quite sure.  over the coming days I'll do two things: move the
logic of 'fore_call' into the "walker" macros -- 9 items :-(, and re-write the
interface to 'Foreach(array,dictionary)', which will get rid of 'fore_verbose',
give the user named flags (no quite enum, but hey), and keeps all arguments in
one place.

regards, jr.

[Bald Eagle] Re: alpha.10064268 macro problem [1829 days 12 hours and 48 minutes ago]

Sun, 4 Apr 2021 18:35:00 GMT

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

> good thought, yes.  (and your hunch that the problem lies in the .inc was spot
> on too)

I kinda thought it had to do with the fore_call, but I didn't catch that it was
the #if statement operating ON the fore_call that was the real issue.
TOK to the rescue again.

> I'm not yet quite sure how, but the code needs to be .. re-structured.
> one/the concern is the size of the .inc file; ironically,  the "troublesome"
> 'fore_call()' was written to reduce duplication of code within the "walkers".

Can't you just add the sphere right after the #if, or just add an #else,
depending on when you want the sphere instantiated?

[jr] Re: alpha.10064268 macro problem [1829 days 12 hours and 58 minutes ago]

Sun, 4 Apr 2021 18:25:00 GMT

hi,

"Bald Eagle" <cre### [at] netscapenet> wrote:
> Instead of a boolean, return an integer flag to be further processed.
> (POV-Ray treats any non-zero value as "true")
> Then you can initially process the result as a boolean like you do, but then
> have a follow-up procedure that instantiates the sphere, maybe using #select.

good thought, yes.  (and your hunch that the problem lies in the .inc was spot
on too)  I'm not yet quite sure how, but the code needs to be .. re-structured.
one/the concern is the size of the .inc file; ironically,  the "troublesome"
'fore_call()' was written to reduce duplication of code within the "walkers".

regards, jr.

[Bald Eagle] Re: alpha.10064268 macro problem [1829 days 13 hours and 33 minutes ago]

Sun, 4 Apr 2021 17:50:00 GMT

Instead of a boolean, return an integer flag to be further processed.
(POV-Ray treats any non-zero value as "true")
Then you can initially process the result as a boolean like you do, but then
have a follow-up procedure that instantiates the sphere, maybe using #select.

Or maybe you can just do that with the simple "boolean" as well...

[jr] Re: alpha.10064268 macro problem [1829 days 15 hours and 53 minutes ago]

Sun, 4 Apr 2021 15:30:00 GMT

hi,

"Tor Olav Kristensen" <tor### [at] TOBEREMOVEDgmailcom> wrote:
> "jr" <cre### [at] gmailcom> wrote:
> > ...
> You don't have to know a lot about the parser. You only have to pay attention to
> what the macros "insert" or "leave behind".
>
> The fore_call macro inserts two items: a call to the fore_exec macro and the
> number 1.
>
> And the call to the fore_exec macro inserts the contents of the parse_fore.tmp
> file, which is this: bigSphere(7,a_[7])
>
> That call to the bigSphere macro again calls the mkSphere macro, which inserts
> the sphere { } statement.
>
> Now the resulting if statement looks somewhat like this:
>
> #if (! sphere { } 1)
>
> - and that's not good...

:-)

seriously though, thank you for this clear outline of "events".  excellent.  I
seem to think too much in terms of (conventional) function/procedure when using
SDL.  (time for coffee + thinking cap :-))


regards, jr.

[Tor Olav Kristensen] Re: alpha.10064268 macro problem [1829 days 16 hours and 43 minutes ago]

Sun, 4 Apr 2021 14:40:00 GMT

"jr" <cre### [at] gmailcom> wrote:
> hi,
>
> "Tor Olav Kristensen" <tor### [at] TOBEREMOVEDgmailcom> wrote:
> > "jr" <cre### [at] gmailcom> wrote:
> > > ...
> > > the below shows the error message I'm getting when I try to create an object
> > > from within the "payload" macro; ...
> >
> > I suspect that your problem is that your bigSphere and mkSphere macros insert
> > the code for a sphere as the argument to the ! (logical not) operator.
>
> first off thank you for taking a look.  appreciated.
>
>
> > I think it is happening in this line in your fore_walker1D macro:
> >
> >       #if (!fore_call(a_,cmd_,fore_flagBoolean(f_)))
>
> you mean the parser (ultimately) emits code like '#if (!sphere {...})'?  that
> would certainly explain the expect numeric expression message.  disclaimer first
> :-): I know nothing of the POV-Ray parser or its internal "voodoo"
> managing/unwinding the call stack, and (all) too little about parsing in
> general.
>
> when I look at the 'fore_call()' macro code, given that the "payload" is a
> void-type macro, the '#else' branch (line 106) will be used.  I expect(ed) the
> sphere to be inserted replacing line 107.  certainly, when debug is enabled, the
> subsequent '#debug concat()' always displays the value it's received in line
> 108.  so, not knowing the parser etc, how [cw]ould the sphere code wind up in
> 'fore_walker1D'?

You don't have to know a lot about the parser. You only have to pay attention to
what the macros "insert" or "leave behind".

The fore_call macro inserts two items: a call to the fore_exec macro and the
number 1.

And the call to the fore_exec macro inserts the contents of the parse_fore.tmp
file, which is this: bigSphere(7,a_[7])

That call to the bigSphere macro again calls the mkSphere macro, which inserts
the sphere { } statement.

Now the resulting if statement looks somewhat like this:

#if (! sphere { } 1)

- and that's not good...

--
Tor Olav
http://subcube.com
https://github.com/t-o-k

[jr] Re: alpha.10064268 macro problem [1829 days 17 hours and 13 minutes ago]

Sun, 4 Apr 2021 14:10:00 GMT

hi,

"Tor Olav Kristensen" <tor### [at] TOBEREMOVEDgmailcom> wrote:
> "jr" <cre### [at] gmailcom> wrote:
> > ...
> > the below shows the error message I'm getting when I try to create an object
> > from within the "payload" macro; ...
>
> I suspect that your problem is that your bigSphere and mkSphere macros insert
> the code for a sphere as the argument to the ! (logical not) operator.

first off thank you for taking a look.  appreciated.

> I think it is happening in this line in your fore_walker1D macro:
>
>       #if (!fore_call(a_,cmd_,fore_flagBoolean(f_)))

you mean the parser (ultimately) emits code like '#if (!sphere {...})'?  that
would certainly explain the expect numeric expression message.  disclaimer first
:-): I know nothing of the POV-Ray parser or its internal "voodoo"
managing/unwinding the call stack, and (all) too little about parsing in
general.

when I look at the 'fore_call()' macro code, given that the "payload" is a
void-type macro, the '#else' branch (line 106) will be used.  I expect(ed) the
sphere to be inserted replacing line 107.  certainly, when debug is enabled, the
subsequent '#debug concat()' always displays the value it's received in line
108.  so, not knowing the parser etc, how [cw]ould the sphere code wind up in
'fore_walker1D'?

regards, jr.

[Tor Olav Kristensen] Re: alpha.10064268 macro problem [1829 days 19 hours and 23 minutes ago]

Sun, 4 Apr 2021 12:00:00 GMT

"jr" <cre### [at] gmailcom> wrote:
> hi,
>
> I've run into a problem which I cannot understand.  I'm working on a 'Foreach'
> macro, to process arrays.  it works as expected, except..
>
> the below shows the error message I'm getting when I try to create an object
> from within the "payload" macro; first run displays the values supplied from an
> array, with the offending line (208) commented out.
>...

Hi jr

I suspect that your problem is that your bigSphere and mkSphere macros insert
the code for a sphere as the argument to the ! (logical not) operator.

I think it is happening in this line in your fore_walker1D macro:

      #if (!fore_call(a_,cmd_,fore_flagBoolean(f_)))

--
Tor Olav
http://subcube.com
https://github.com/t-o-k

[jr] Re: alpha.10064268 macro problem [1829 days 20 hours and 58 minutes ago]

Sun, 4 Apr 2021 10:25:00 GMT

hi,

"Bald Eagle" <cre### [at] netscapenet> wrote:
> "jr" <cre### [at] gmailcom> wrote:
> ...
> > intrigued.  what can you not do with just '#end's?
>
>
http://news.povray.org/povray.advanced-users/thread/%3Cweb.5ba2723e83bd6a1ec437ac910%40news.povray.org%3E/

still not entirely clear, will try and re-read this (interesting) thread later.


> I was also thinking that since we don't have an 'alias' directive, we might be
> able to track the nesting level with something like:
>
> #macro If (A)
>      #declare Level = Level + 1;
>      #if (A)
> #end
>
> and then a corresponding EndIf () macro could decrement the counter...

some mechanism like that seems useful, it would need to "loadable on demand", ie
abstracted into its own include.


> I was also trying to simplify reading ASCII stl files in, ...

check yr inbox.


regards, jr.

[jr] Re: alpha.10064268 macro problem [1829 days 21 hours and 18 minutes ago]

Sun, 4 Apr 2021 10:05:00 GMT

hi,

William F Pokorny <ano### [at] anonymousorg> wrote:
> ...
> I'm short on time; busy with real life for a few days.
>
> I did quickly run your code with my current povr branch recompiled with
> my new --disable-no-lc-identifiers ./configure option or aka -jr ;-).

</grin>  _like_


> My branch has all the parser fixes identified since the last v3.8
> commit. I see the issue too so none of those a help.

thank you, good (or rather not) to know that 'povr' gives same result.  hope yr
schedule will leave you time for coffees.  :-)


regards, jr.

[William F Pokorny] Re: alpha.10064268 macro problem [1829 days 22 hours and 24 minutes ago]

Sun, 4 Apr 2021 08:59:19 GMT

On 4/3/21 2:37 PM, jr wrote:
> hi,
> 
...

Hi jr,
I'm short on time; busy with real life for a few days.

I did quickly run your code with my current povr branch recompiled with 
my new --disable-no-lc-identifiers ./configure option or aka -jr ;-).

My branch has all the parser fixes identified since the last v3.8 
commit. I see the issue too so none of those a help.

Bill P.

[Bald Eagle] Re: alpha.10064268 macro problem [1830 days 6 hours and 38 minutes ago]

Sun, 4 Apr 2021 00:45:00 GMT

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

> </grin>  thanks.  can do with some lightheartedness.  :-)

No, truly.  You're busting in on my turf.
I have not seen such a tangle of ever-changing errors and line numbers since the
last 4 times I broke POV-Ray.
This is a real head-scratcher you've coded up.

> intrigued.  what can you not do with just '#end's?

http://news.povray.org/povray.advanced-users/thread/%3Cweb.5ba2723e83bd6a1ec437ac910%40news.povray.org%3E/

I was also thinking that since we don't have an 'alias' directive, we might be
able to track the nesting level with something like:

#macro If (A)
     #declare Level = Level + 1;
     #if (A)
#end

and then a corresponding EndIf () macro could decrement the counter...

I was also trying to simplify reading ASCII stl files in, and since they are SO
similar to the mesh {} syntax, an alias or ignore or error trapping or a
comma-free #read from file mechanism would be really nice to process external
files with....

I suppose after I get some of the mountain of SDL POV-Ray stuff off my plate, I
should really start learning to read the source code more accurately and figure
out how to add functionality to it.

[jr] Re: alpha.10064268 macro problem [1830 days 7 hours and 3 minutes ago]

Sun, 4 Apr 2021 00:20:00 GMT

hi,

"Bald Eagle" <cre### [at] netscapenet> wrote:
> "jr" <cre### [at] gmailcom> wrote:
>
> > (do you need to top up caffeine level?  :-))
>
> Yes.
> Though with what you've got going on, I'm gonna need either some crystal meth -
> or a crystal ball - to see how you've gone and broken things this time.   :P

</grin>  thanks.  can do with some lightheartedness.  :-)


> ...
> > (and please give it a whirr with some "normal" macros.  any errors?)
> Give WHAT a whirr...

the 'Foreach()'.  I'm sure you've plenty data (lingering in arrays).  if the
payload macros just do calculations etc, I'd expect it to run w/out issues.


> > yes, self prefers braced blocks (think Tcl), eg '#for () { ... }'.
>
> Well, yes, that would be functional.
>
> But I would still prefer #endif #endfor #endwhile #endmacro
> as it would allow some interesting coding that wouldn't otherwise be possible

intrigued.  what can you not do with just '#end's?


regards, jr.

[Bald Eagle] Re: alpha.10064268 macro problem [1830 days 7 hours and 28 minutes ago]

Sat, 3 Apr 2021 23:55:00 GMT

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

> (do you need to top up caffeine level?  :-))

Yes.
Though with what you've got going on, I'm gonna need either some crystal meth -
or a crystal ball - to see how you've gone and broken things this time.   :P

I think that with this, you are trying to get into the running on "Who breaks
POV-Ray the most?"

> (and please give it a whirr with some "normal" macros.  any errors?)
Give WHAT a whirr...


> yes, self prefers braced blocks (think Tcl), eg '#for () { ... }'.

Well, yes, that would be functional.

But I would still prefer #endif #endfor #endwhile #endmacro
as it would allow some interesting coding that wouldn't otherwise be possible
with equally ambiguous {'s

[jr] Re: alpha.10064268 macro problem [1830 days 8 hours and 8 minutes ago]

Sat, 3 Apr 2021 23:15:00 GMT

hi,

"Bald Eagle" <cre### [at] netscapenet> wrote:
> To CYA, check your "end"s    :D

are you looking at an unmodified file?  if yes, as posted, the indentation looks
correct.

> I noticed that you have a
> #ifndef (fore_include_temp)
>
> but I'm not sure where it should be terminated.

line 429.  :-)

> Also, I'm not sure if there are enough #ends in
> #macro Foreach(arr_,mac_,flg_,optional dim_)

no spare or missing '#end's, I'm confident.

(do you need to top up caffeine level?  :-))
(and please give it a whirr with some "normal" macros.  any errors?)

> I would sorely love different terminators for #macro, #if, #for, #while, etc....

yes, self prefers braced blocks (think Tcl), eg '#for () { ... }'.

regards, jr.

[Bald Eagle] Re: alpha.10064268 macro problem [1830 days 8 hours and 38 minutes ago]

Sat, 3 Apr 2021 22:45:00 GMT

To CYA, check your "end"s    :D

I noticed that you have a
#ifndef (fore_include_temp)

but I'm not sure where it should be terminated.

Also, I'm not sure if there are enough #ends in
#macro Foreach(arr_,mac_,flg_,optional dim_)






I would sorely love different terminators for #macro, #if, #for, #while, etc....

[jr] Re: alpha.10064268 macro problem [1830 days 9 hours and 3 minutes ago]

Sat, 3 Apr 2021 22:20:00 GMT

hi,

"Bald Eagle" <cre### [at] netscapenet> wrote:
> "jr" <cre### [at] gmailcom> wrote:
> ...
> I commented out the macro call in bigSphere  (look at you, using capital
> letters... :o)  and put an actual sphere in its place.
> Same error.

yes, I too tried that.

> Put a 1 on the line above it.   Same error as last time.
>
> But when I closed the ), this time I got
>
> Parse Error: Unbalanced #end directives in include file.
> at File: fore_demo.pov Line: 213 Col: 1
> e[0] = 0  e[1] = 0  e[2] = 'one'  e[3] = 7.
> Parse Warning: Unbalanced ) in include file
>
> So the error gets triggered in the scene file, but seems to be actually due to
> an omission in some nested thing in the include file.
> Also, 213 is a different line than when I did the 0) in the mkSphere macro.

maybe I should have mentioned earlier.  before I got to the stage of calling
payload macros, I worked to get the "walking" done properly.  for that I've a
test scene with arrays from one to five dims, and the 'fore_call()' at the time
only spat out the 'cmd_' content, ie the index/indices of the current element.
while it is possible that I fucked up, I did test pretty thoroughly.

my gut feeling, given the "because it is looking for a numeric expression", is
that the parser somehow expects a RHS where it sees an object/primitive.

(and to add to the indignation :-), earlier I'd written a camera {} and left
forgot to fill in the details, and .. not a beep from the program.)

> If you can't find the issue, you may have to resort to mapping the nesting
> levels like I did in that blood cells scene.

yes, last resort though.  I do hope "one of the gods" can shed some light on
this.

regards, jr.

[Bald Eagle] Re: alpha.10064268 macro problem [1830 days 9 hours and 18 minutes ago]

Sat, 3 Apr 2021 22:05:00 GMT

Further,
if I put a 2) before the #debug statement in bigSphere, it complains about line
_214_ instead.

You've got an extra ( somewhere that got injected or a missing ), or something
even harder to track down.

Just on the off chance:
The file is clean and has none of those weird non-ASCII characters, ...?

[Bald Eagle] Re: alpha.10064268 macro problem [1830 days 9 hours and 28 minutes ago]

Sat, 3 Apr 2021 21:55:00 GMT

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

> yes, as it should, having just a '0)' before the primitive.  I don't get the
> line before thing but suspect it's for the same reason -- extra ("spurious")
> characters.

Right on, but we're looking at "as it shouldn't".

I commented out the macro call in bigSphere  (look at you, using capital
letters... :o)  and put an actual sphere in its place.
Same error.

Put a 1 on the line above it.   Same error as last time.

But when I closed the ), this time I got

Parse Error: Unbalanced #end directives in include file.
at File: fore_demo.pov Line: 213 Col: 1
e[0] = 0  e[1] = 0  e[2] = 'one'  e[3] = 7.
Parse Warning: Unbalanced ) in include file

So the error gets triggered in the scene file, but seems to be actually due to
an omission in some nested thing in the include file.
Also, 213 is a different line than when I did the 0) in the mkSphere macro.

If you can't find the issue, you may have to resort to mapping the nesting
levels like I did in that blood cells scene.

[jr] Re: alpha.10064268 macro problem [1830 days 10 hours and 8 minutes ago]

Sat, 3 Apr 2021 21:15:00 GMT

hi,

"Bald Eagle" <cre### [at] netscapenet> wrote:
> "jr" <cre### [at] gmailcom> wrote:
> ...
> > File 'fore_demo.pov' line 199: Parse Error: Expected 'numeric expression',
> >  sphere found instead
>
> Because it is looking for a numeric expression that you somehow left out.

hmm, the 'bigSphere' macro does work until one tries to instantiate an object,
it runs otherwise.  and, well, I cannot see anything amiss.

> When I insert a line before the sphere and put "0", I get:
>
> Possible Parse Error: Unmatched (
> at File: foreach.inc Line: 344 Col: 11
> Parse Error: No matching ), sphere found instead
>
> But then curiously, when I put "0)" I get:
>
> Parse Warning: Unbalanced ) in include file
> Parse Warning: Unbalanced } in include file
> Parse Error: Unbalanced #end directives in include file.

yes, as it should, having just a '0)' before the primitive.  I don't get the
line before thing but suspect it's for the same reason -- extra ("spurious")
characters.

as for adding more output in the include, the error does occur in the scene
file.  (btw, a 'bool' type payload with debug on will print return info).

thanks for looking.

regards, jr.

[Bald Eagle] Re: alpha.10064268 macro problem [1830 days 10 hours and 48 minutes ago]

Sat, 3 Apr 2021 20:35:00 GMT

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

> I've run into a problem which I cannot understand.  I'm working on a 'Foreach'
> macro, to process arrays.  it works as expected, except..

> File 'fore_demo.pov' line 199: Parse Error: Expected 'numeric expression',
>  sphere found instead

Because it is looking for a numeric expression that you somehow left out.

When I insert a line before the sphere and put "0", I get:

Possible Parse Error: Unmatched (
at File: foreach.inc Line: 344 Col: 11
Parse Error: No matching ), sphere found instead

But then curiously, when I put "0)" I get:

Parse Warning: Unbalanced ) in include file
Parse Warning: Unbalanced } in include file
Parse Error: Unbalanced #end directives in include file.

Other than that, you have too much clever stuff going on for me to follow.
Add in more debug statements to follow your code flow.

I added:

#macro fore_exec(s_)
  #local fn_ = "/tmp/parse_fore.tmp";
  #fopen fp_ fn_ write
  #write (fp_, s_)
  #fclose fp_
  #debug "fore_exec(s_).... \n" // BW
  #debug concat (s_, "\n")
  #include fn_
#end

#macro fore_call(a_,s_,f_)
  #if (f_)
    #local rtn_ = fore_exec(s_);
  #else
   #debug "fore_call 1.... \n" // BW
    fore_exec(s_)
    #local rtn_ = 1;
  #end
  #if (fore_debug)
    #debug concat("call '",s_,"' returned '",str(rtn_,0,0),"'.\n")
  #end
  #debug "fore_call 2.... \n" // BW
  rtn_
#end

and

#macro mkSphere (p_, d_, c_)
 #debug "executing mkSphere... \n"
 0)
  sphere {
    p_, d_
    pigment {colours_[c_]}
  }
#end

[jr] alpha.10064268 macro problem [1830 days 12 hours and 43 minutes ago]

Sat, 3 Apr 2021 18:40:00 GMT

hi,

I've run into a problem which I cannot understand.  I'm working on a 'Foreach'
macro, to process arrays.  it works as expected, except..

the below shows the error message I'm getting when I try to create an object
from within the "payload" macro; first run displays the values supplied from an
array, with the offending line (208) commented out.

jr@swift:1:$ povparse fore_demo.pov
Persistence of Vision(tm) Ray Tracer Version 3.8.0-alpha.10064268.unofficial
  ...
==== [Parsing...] ==========================================================
e[0] = 0  e[1] = 0  e[2] = 'one'  e[3] = 7.
e[0] = 2  e[1] = 1  e[2] = 'two'  e[3] = 6.
e[0] = 4  e[1] = 2  e[2] = 'three'  e[3] = 5.
e[0] = 6  e[1] = 3  e[2] = 'four'  e[3] = 3.
e[0] = 1  e[1] = 4  e[2] = 'five'  e[3] = 2.
e[0] = 3  e[1] = 5  e[2] = 'six'  e[3] = 4.
e[0] = 5  e[1] = 6  e[2] = 'seven'  e[3] = 1.
e[0] = 7  e[1] = 7  e[2] = 'eight'  e[3] = 0.
File 'fore_demo.pov' line 216: Parse Warning: No objects in scene.
==== [Rendering...] ========================================================
Rendered 1024 of 1024 pixels (100%)
POV-Ray finished


jr@swift:2:$ povparse fore_demo.pov
   ...
==== [Parsing...] ==========================================================
e[0] = 0  e[1] = 0  e[2] = 'one'  e[3] = 7.
File 'fore_demo.pov' line 199: Parse Error: Expected 'numeric expression',
 sphere found instead
Fatal error in parser: Cannot parse input.
Render failed


zip attached.  (the demo scene is meant to double as draft documentation, hence
the format)


regards, jr.

[Ton] Re: TGA Alpha channel [1885 days 7 hours and 28 minutes ago]

Sun, 7 Feb 2021 23:55:01 GMT

William F Pokorny <ano### [at] anonymousorg> wrote:
>
> As bugs go, a relatively easy one. :-)
>
> In the file: source/base/image/targa.cpp and the function Write:
>
> bool opaque = options.AlphaIsEnabled();
>
> should be:
>
> bool opaque = !options.AlphaIsEnabled();
>
> Bill P.

That sure was a simple solution, thanks Bill.

Cheers
Ton.

[William F Pokorny] Re: TGA Alpha channel [1885 days 20 hours and 14 minutes ago]

Sun, 7 Feb 2021 11:08:33 GMT

On 2/6/21 3:06 PM, William F Pokorny wrote:
> On 2/5/21 7:41 PM, Ton wrote:
...
>> When I use +UA, povray says: makecloud2001.tga, 32 bpp with alpha 
>> Targa, but
>> this time I don't have the alpha channel, and tga2df3 generates a cloud.
>>
...
> 
> I believe I see it in my povr branch based off v3.8.
> 
...
> I'm tired. I'll try and run the issue down tomorrow.
> 

As bugs go, a relatively easy one. :-)

In the file: source/base/image/targa.cpp and the function Write:

bool opaque = options.AlphaIsEnabled();

should be:

bool opaque = !options.AlphaIsEnabled();

Bill P.

[William F Pokorny] Re: TGA Alpha channel [1886 days 11 hours and 16 minutes ago]

Sat, 6 Feb 2021 20:06:51 GMT

On 2/5/21 7:41 PM, Ton wrote:
> I'm playing with Gilles Tran MakeCloud macro, and the output from tga2df3 didn't
> look like a cloud.
> After some investigation I found that the TGA output file is confused.
> When I use -UA, povray says: makecloud2001.tga, 24 bpp Targa, but the output
> file contains an alpha channel (every fourth byte is 0xFF).
> When I use +UA, povray says: makecloud2001.tga, 32 bpp with alpha Targa, but
> this time I don't have the alpha channel, and tga2df3 generates a cloud.
> 
> My povray version is POV-Ray 3.8.0-x.10064738.unofficial, and UberPOV 1.37.1.0
> has the same problem.
> 

I believe I see it in my povr branch based off v3.8.

To a quick verification .png output is OK, but .tga files look backward 
to the +UA/-UA control... The reported information looks too at the 
control setting and not at what actually got written.

I'm tired. I'll try and run the issue down tomorrow.

Bill P.

[Ton] TGA Alpha channel [1887 days 6 hours and 38 minutes ago]

Sat, 6 Feb 2021 00:45:00 GMT

I'm playing with Gilles Tran MakeCloud macro, and the output from tga2df3 didn't
look like a cloud.
After some investigation I found that the TGA output file is confused.
When I use -UA, povray says: makecloud2001.tga, 24 bpp Targa, but the output
file contains an alpha channel (every fourth byte is 0xFF).
When I use +UA, povray says: makecloud2001.tga, 32 bpp with alpha Targa, but
this time I don't have the alpha channel, and tga2df3 generates a cloud.

My povray version is POV-Ray 3.8.0-x.10064738.unofficial, and UberPOV 1.37.1.0
has the same problem.

I couldn't find any mention of this in the newsgroups, but if people are aware
then I apologize for rubbing it in again.

Cheers
Ton.

[jr] Re: alpha.10064268 undef behaviour [2063 days 13 hours and 38 minutes ago]

Thu, 13 Aug 2020 17:45:00 GMT

hi,

William F Pokorny <ano### [at] anonymousorg> wrote:
> ...
> For the near future, the diff - aside from comments I added here and
> there in the povr code base should I eventually dig deeper - is simply
> replacing the current POV_EXPERIMENTAL_ASSERT() with the modified one in
> my post.

ok, good info.  cheers.


regards, jr.

[William F Pokorny] Re: alpha.10064268 undef behaviour [2063 days 14 hours and 56 minutes ago]

Thu, 13 Aug 2020 16:27:03 GMT

On 8/13/20 10:17 AM, jr wrote:
...
> 
> if, after some time, the change you made to 'symboltable.cpp' looks to be
> trouble-free, could you post a diff for users (me :-)) to try, please?
> 
...

If something changes in approach for povr, I'll try to remember.

For the near future, the diff - aside from comments I added here and 
there in the povr code base should I eventually dig deeper - is simply 
replacing the current POV_EXPERIMENTAL_ASSERT() with the modified one in 
my post.

Bill P.

[jr] Re: alpha.10064268 undef behaviour [2063 days 17 hours and 3 minutes ago]

Thu, 13 Aug 2020 14:20:00 GMT

hi,

William F Pokorny <ano### [at] anonymousorg> wrote:
> On 8/13/20 6:48 AM, jr wrote:
> > ...
> > I was looking over my 'queues.inc' code[*], and got errors ...
>
> The two which fail are using float id tokens where the first does not.

thank you for looking into it.  did a quick test loading a few strings via
'qqPut()' and yes, that works as should.  (strange that the content of an array
element should matter)

> ...
> I'm going to run with the change at the bottom for a while in povr and
> see what happens. Your test cases again run with the change.

yeah, forgot to mention, 'povr' was same as alpha.10064268.

> I think though this a v38 release issue where somebody needs to spend a
> chunk of time 'really' getting to understand the state of the current
> parser code to determine the 'right' solution. I'm guessing a little
> given the code state - and that state doesn't looks clean to me.

if, after some time, the change you made to 'symboltable.cpp' looks to be
trouble-free, could you post a diff for users (me :-)) to try, please?

regards, jr.

[William F Pokorny] Re: alpha.10064268 undef behaviour [2063 days 18 hours ago]

Thu, 13 Aug 2020 13:23:05 GMT

On 8/13/20 6:48 AM, jr wrote:
> hi,
> 
> I was looking over my 'queues.inc' code[*], and got errors when running the
> test/demo scenes.  all three test scenes work ok when using the alpha.9945627,
> but with the alpha.10064268, which I installed a few days after posting :-), I
> get:
...
> 

The two which fail are using float id tokens where the first does not.

In symboltable.cpp Christoph added:

// TODO See captured issue:
// jr_Parse_alpha_10064268_to_10064268_Aug13_2020
//         POV_EXPERIMENTAL_ASSERT((ttype != FLOAT_TOKEN_CATEGORY) &&
//                                 (ttype != FLOAT_ID_TOKEN) &&
//                                 (ttype != VECTOR_TOKEN_CATEGORY) &&
//                                 (ttype != COLOUR_TOKEN_CATEGORY));

// I "think" Christoph wanted something like that below.
// BUT! Why didn't he just differently order FLOAT_ID_TOKEN,
// VECTOR_ID_TOKEN as he looks to have ordered COLOUR_ID_TOKEN
// This looks like something not complete and certainly not clean.

         POV_EXPERIMENTAL_ASSERT(((ttype != FLOAT_TOKEN_CATEGORY) ||
                                  (ttype == FLOAT_ID_TOKEN)) &&
                                 ((ttype != VECTOR_TOKEN_CATEGORY) ||
                                  (ttype == VECTOR_ID_TOKEN)) &&
                                 (ttype != COLOUR_TOKEN_CATEGORY));

I'm going to run with the change at the bottom for a while in povr and 
see what happens. Your test cases again run with the change.

I think though this a v38 release issue where somebody needs to spend a 
chunk of time 'really' getting to understand the state of the current 
parser code to determine the 'right' solution. I'm guessing a little 
given the code state - and that state doesn't looks clean to me.

Bill P.

[jr] alpha.10064268 undef behaviour [2063 days 20 hours and 33 minutes ago]

Thu, 13 Aug 2020 10:50:01 GMT

hi,

I was looking over my 'queues.inc' code[*], and got errors when running the
test/demo scenes.  all three test scenes work ok when using the alpha.9945627,
but with the alpha.10064268, which I installed a few days after posting :-), I
get:

Persistence of Vision(tm) Ray Tracer Version 3.8.0-alpha.10064268.unofficial
 ...
==== [Parsing...] ==========================================================
found 33 in B in first 500.
File '/usr/local/share/povray-3.8/extra/queues.inc' line 59: Possible Parse
 Error: Uncategorized error thrown at parser/symboltable.cpp line 440.
Fatal error in parser: Uncategorized error.
Render failed

==== [Parsing...] ==========================================================
found 33 in B in first 500.
File '/usr/local/share/povray-3.8/extra/queues.inc' line 118: Possible Parse
 Error: Uncategorized error thrown at parser/symboltable.cpp line 440.
Fatal error in parser: Uncategorized error.
Render failed

==== [Parsing...] ==========================================================
the quick brown fox jumped
total 5 elements queued.
quick, the brown fox jumped
File 'tstqp.pov' line 176: Parse Warning: No objects in scene.

lines 59 and 118 contain an '#undef', as does line 225.  yet, two tests fail,
one succeeds, and I cannot see a difference.

[*] <http://news.povray.org/web.5dddb9c6ed272ff4feeb22ff0%40news.povray.org>


regards, jr.

[William F Pokorny] Re: alpha.10064268 outputting strings [2119 days 18 hours and 6 minutes ago]

Thu, 18 Jun 2020 13:16:52 GMT

On 6/18/20 2:27 AM, Thorsten wrote:
> On 18.06.2020 01:50, William F Pokorny wrote:
...
>>
>> Thanks for those links. I have no recollection of either thread...
> 
...
> 
> In short, as you can see, the string implementation touches many parts 
> of POV-Ray, and in order to make much progress, all these points would 
> have to be fixed simultaneously.
> 

Thank you for overview. :-)

Bill P.

[Thorsten] Re: alpha.10064268 outputting strings [2120 days and 56 minutes ago]

Thu, 18 Jun 2020 06:27:01 GMT

On 18.06.2020 01:50, William F Pokorny wrote:
> On 6/17/20 5:43 PM, B. Gimeno wrote:
> ...
>>
>> Not sure of anything after reading this:
>>
http://news.povray.org/povray.beta-test/message/%3C5c2e6746%40news.povray.org%3E/#%3C5c2e6746%40news.povray.org%3E

>>
>> ....and that someone was inquirinq in a similar way 20 years ago.
>>
http://news.povray.org/povray.beta-test/thread/%3C3BADC84E.1AB6A6C0%40post8.tele.dk%3E/?mtop=176162

> 
> Thanks for those links. I have no recollection of either thread...

Well, I do ;-)

To answer some of the questions, assuming nothing has been changed in 
the meantime ...

Practically, there are four uses of strings in POV-Ray. One is for TTF 
output. Here, UTF-8 cannot be used internally, but UCS2/4 is used, and 
the strings are converted for this use. The reason is that UTF-8 is a 
variable length encoding (as is UTF-16), which is not very efficient to 
decode on the fly, though when building the extrusions for text objects, 
that would hardly matter, but anyway, that is the way it is.

The other main use is for include files and all other files. Here a path 
is needed. 20 years back, opening anything but ASCII based paths was a 
mess, and to an extend it still is. There was some abstraction put in 
place, and by all means, here Unicode or more precisely the charset, 
should also work these days.

The next use case is for debug output.This output goes to the console or 
message window in a GUI. Originally, neither supported Unicode (20 years 
ago), so there comes the implementation: Replace any character code => 
128 with a space. This eliminates the need to support Unicode or UTF-8 
in those windows and on terminals.

And this brings us to the similar use: The output of text files. They 
used to use the same implementation. And from what I am reading, i guess 
nothing has changed.

Oh, and for the 256 character limit, that comes from yet another source: 
The tokenizer responsible for parsing strings reuses the same buffer as 
it uses for parsing tokens. So if this hasn't been changed, that is 
where the limit comes from.

In short, as you can see, the string implementation touches many parts 
of POV-Ray, and in order to make much progress, all these points would 
have to be fixed simultaneously.

Thorsten

[William F Pokorny] Re: alpha.10064268 outputting strings [2120 days 7 hours and 33 minutes ago]

Wed, 17 Jun 2020 23:50:19 GMT

On 6/17/20 5:43 PM, B. Gimeno wrote:
...
> 
> Not sure of anything after reading this:
>
http://news.povray.org/povray.beta-test/message/%3C5c2e6746%40news.povray.org%3E/#%3C5c2e6746%40news.povray.org%3E
> 
> ....and that someone was inquirinq in a similar way 20 years ago.
>
http://news.povray.org/povray.beta-test/thread/%3C3BADC84E.1AB6A6C0%40post8.tele.dk%3E/?mtop=176162
> 

Thanks for those links. I have no recollection of either thread...

Bill P.

[B Gimeno] Re: alpha.10064268 outputting strings [2120 days 9 hours and 38 minutes ago]

Wed, 17 Jun 2020 21:45:06 GMT

"jr" <cre### [at] gmailcom> wrote:
> hi,
> > By the way, has anyone managed to write unicode characters (\unnnn) above the
> > ascii 128 limit to a text file? I would like to play with the rest of the ascii
> > characters but I only get blank spaces; Yes, I have already tried utf-8 in
> > general settings, but I do not intend to generate a text object in an image
> > using a truetype font or an ANSI extended font, but a separate plain text file
> > whose content is dumped by Pov-Ray.
>
> if the '\Unnnn' notation does not work, perhaps can you output (byte-wise) UTF8
> code points?  <https://www.utf8-chartable.de/>

Not sure of anything after reading this:
http://news.povray.org/povray.beta-test/message/%3C5c2e6746%40news.povray.org%3E/#%3C5c2e6746%40news.povray.org%3E

....and that someone was inquirinq in a similar way 20 years ago.
http://news.povray.org/povray.beta-test/thread/%3C3BADC84E.1AB6A6C0%40post8.tele.dk%3E/?mtop=176162


onemiGB

[jr] Re: alpha.10064268 outputting strings [2120 days 13 hours and 8 minutes ago]

Wed, 17 Jun 2020 18:15:01 GMT

hi,

"B. Gimeno" <nomail@nomail> wrote:
> Here is the reference to the old 256 limit in v3.6
> ...
> And the link to the updated 3.8 version:
> ...
>   "up to 256 ASCII characters"

thanks.  no idea why I misremembered.


> I propose to use as many concat() as necessary, if that was the problem.

yes, I think that will be the only option, now.


> By the way, has anyone managed to write unicode characters (\unnnn) above the
> ascii 128 limit to a text file? I would like to play with the rest of the ascii
> characters but I only get blank spaces; Yes, I have already tried utf-8 in
> general settings, but I do not intend to generate a text object in an image
> using a truetype font or an ANSI extended font, but a separate plain text file
> whose content is dumped by
> Pov-Ray.

if the '\Unnnn' notation does not work, perhaps can you output (byte-wise) UTF8
code points?  <https://www.utf8-chartable.de/>


regards, jr.

(natty macro, btw.  will try it later on.  thanks)

[B Gimeno] Re: alpha.10064268 outputting strings [2120 days 15 hours and 8 minutes ago]

Wed, 17 Jun 2020 16:15:00 GMT

Here is the reference to the old 256 limit in v3.6

https://www.povray.org/documentation/view/3.6.1/510/
STRING_LITERAL STRING_LITERAL:
    "up to 256 ASCII characters"


And the link to the updated 3.8 version:
http://wiki.povray.org/content/Reference:Strings#String_Functions
STRING:
  STRING_FUNCTION   |
  STRING_IDENTIFIER |
  STRING_LITERAL STRING_LITERAL:
  "up to 256 ASCII characters"

I propose to use as many concat() as necessary, if that was the problem.


By the way, has anyone managed to write unicode characters (\unnnn) above the
ascii 128 limit to a text file? I would like to play with the rest of the ascii
characters but I only get blank spaces; Yes, I have already tried utf-8 in
general settings, but I do not intend to generate a text object in an image
using a truetype font or an ANSI extended font, but a separate plain text file
whose content is dumped by
Pov-Ray.

Regards
BGimeno

[jr] alpha.10064268 outputting strings [2121 days 17 hours and 13 minutes ago]

Tue, 16 Jun 2020 14:10:01 GMT

hi,

thought I had read that strings, in 3.8, are no longer limited to 256 characters
length, however, cannot find that reference now.

the (edited) output below is debug info about a quadtree.  I build the lists of
points in the nodes' "buckets", for display, in a string with '#local S =
concat(S,...);'.

the list for node #22 is truncated, and the newline "swallowed", whereas node
#35's list is printed in full.

the tree has 100+ nodes and truncation occurs for more than half of nodes (with
points).

so what is the status of strings in 3.8?  does the 256 char limit still apply?



Persistence of Vision(tm) Ray Tracer Version 3.8.0-alpha.10064268.unofficial
....
==== [Parsing...] ==========================================================
-----[quadtree dump]----------------------------------------------------
          root node id: 1
             area from: <-5.0000, -5.0000>
                    to: <5.0000, 5.0000>
               # nodes: 125
           bucket size: 10
              # points: 500
....
                bucket: <-3.8206, -4.8561, 0.0000>
   <-4.4137, -3.8171, 0.0000>
   <-4.8114, -4.8691, 0.0000>
   <-4.1970, -4.0342, 0.0000>
   <-4.7922, -4...
               node id: 23
....
                bucket: <1.3956, -4.6061, 0.0000>
   <1.7214, -4.7567, 0.0000>
   <2.3263, -4.5134, 0.0000>
   <1.8115, -4.9289, 0.0000>
   <2.0349, -4.3726, 0.0000>
   <2.4509, -4.1583, 0.0000>

               node id: 36
....



(also posting a couple of search results from the same tree in p.b.image)


regards, jr.

[guarnio] Re: object too far from camera is not shown [2153 days 17 hours and 13 minutes ago]

Fri, 15 May 2020 14:10:01 GMT

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

>
> Try to keep everything within 1x10(+/-)6 and you should be fine.
>

Thank you, I'll use your advice!

[guarnio] Re: object too far from camera is not shown [2153 days 17 hours and 13 minutes ago]

Fri, 15 May 2020 14:10:00 GMT

> Old, and known, problem: precision and range of value is limited on
> computers.
>
> Do not model the solar system with such precision, not with such small
> units.


Thank you, I'll reduce the precision of the distances and divide them all by
10^5. I didn't know the issue with using too many digits.

You have been very helpful

[Bald Eagle] Re: object too far from camera is not shown [2180 days 11 hours and 13 minutes ago]

Sat, 18 Apr 2020 20:10:01 GMT

"guarnio" <gua### [at] gmailcom> wrote:

> I'm gonna share the code with "position_SUN" vector declared at the beginning,
> you can just change that and see that just dividing the cut off distance is
> dividing the sun's distance ("position_SUN" vector) by /30 (in this case the sun
> still appears), while dividing only by /28 makes the sun completely disappear.
> I hope someone will be able to help me with what the problem is,

Welcome to the large family of people who have coded the solar system.  :D

http://news.povray.org/povray.newusers/thread/%3C4e46a998%40news.povray.org%3E/

and several other threads like it.  see the old discussions about rendering
Ringworld, and the custom version of POV-Ray that was needed.

There's only so large or so small you can get, numerically, before you run into
the problem of "how is that number represented by the computer in a physical way
using 0's and 1's"  You either run off the end one way or the other.

Try to keep everything within 1x10(+/-)6 and you should be fine.

http://news.povray.org/povray.binaries.animations/thread/%3C5922e351%40news.povray.org%3E/

http://news.povray.org/povray.binaries.animations/message/%3Cweb.5916900b4e8509949c5d6c810%40news.povray.org%3E/

etc.

[Le Forgeron] Re: object too far from camera is not shown [2180 days 15 hours and 7 minutes ago]

Sat, 18 Apr 2020 16:16:08 GMT

Le 18/04/2020 Ã  16:15, guarnio a Ã©critÂ :
> I hope someone will be able to help me with what the problem is,
> Thanks in advance.

Old, and known, problem: precision and range of value is limited on
computers.

Do not model the solar system with such precision, not with such small
units.

Precision is good around 0, but is terrible for any other value.

Imagine there is a 4 digits precision, you can keep track of 1.000,
0.009 and 0.001, but 1.009 is the same as 1.000.

Precision of float is 7 digits, precision of double is 11 digits.

Kilometre is not suitable for your model in povray.
 (150 000 000 in your code)

The radius of Earth is 6371 km; that could be the unit sphere, as long
as you do not want to model more than Mars orbit.

If it bother you to divide everything with non-round number, use the
next bigger value (10 000km = 1 pov-unit)

Last hint: take the habit to put comments in your code when defining
magic value (such as 150000000) to remember the unit of such quantity.
( 696342 is the the radius of sun, in km; approximatively)

[guarnio] object too far from camera is not shown [2180 days 17 hours and 3 minutes ago]

Sat, 18 Apr 2020 14:20:00 GMT

Hi everybody,

i'm working on a solar system model and was trying to generate the sun. Since
the camera is gonna stay in the earth-lunar vicinity, the Sun is going to be
approximately 150 million km away from the camera. Whilst creating the pictures
i noticed the Sun didn't show up even when it's location was looked at by the
camera. I'm gonna post the code below, as a texture for the sun just download
any texture you want from the internet (or this
https://www.solarsystemscope.com/textures/download/8k_sun.jpg).

I'm gonna share the code with "position_SUN" vector declared at the beginning,
you can just change that and see that just dividing the cut off distance is
dividing the sun's distance ("position_SUN" vector) by /30 (in this case the sun
still appears), while dividing only by /28 makes the sun completely disappear.
I hope someone will be able to help me with what the problem is,
Thanks in advance.

here's the code


global_settings {
noise_generator 2
assumed_gamma 1.6
}
#include "colors.inc"

#declare position_SUN= <150000000,0,0>;

camera {
   perspective
   location <0, 0, 0>
   up <0,1,0>
   right <1.6,0,0>
   look_at position_SUN
   angle 35.4515
}

#declare SUN = sphere {
   position_SUN 696342
   texture {
      pigment {
         image_map {
            jpeg
            "/home/guarn/MEGA/Auto_Navigation/Textures/8k_sun.jpg"
            map_type 1
            interpolate 2
         }
         translate position_SUN
      }
         finish {
            ambient 1
      }
   }
    translate -position_SUN
 scale <1, 1, 1>
    rotate y*0
    rotate x*0
    translate position_SUN
}

light_source {
   position_SUN, rgb<1,1,1>
   looks_like { SUN }
   area_light
   <696342,0,0>, <0,696342,0>, 50, 50
   adaptive 1
   parallel
   jitter
   circular
   orient
}

[William F Pokorny] Re: Parse error:Uncategorizederrorthrownatparser... [2208 days 14 hours and 16 minutes ago]

Sat, 21 Mar 2020 17:07:09 GMT

On 3/26/19 6:46 AM, William F Pokorny wrote:
> On 3/25/19 7:41 PM, clipka wrote:
>> Am 25.03.2019 um 23:55 schrieb clipka:
>>
>>> If `Cond_Stack.back().PMac->endPosition == CurrentFilePosition()` 
>>> throws an exception, it means either of two things:
>>>
>>> (A) The positions compared are from two different files, which means 
>>> the calling code has failed to check whether it is even in the right 
>>> file.
>>>
>>> (B) The line/column tracking is buggy, and yields different positions 
>>> in different situations.
>>
>>
>> Well, looking at the code of `IsEndOfInvokedMacro()` again, it 
>> _strongly_ reeks of scenario (A):
>>
>> Â Â Â Â  return
(Cond_Stack.back().PMac->endPosition ==
>>
Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â 
CurrentFilePosition()) &&
>>
Â Â Â Â Â Â Â Â Â Â Â 
(Cond_Stack.back().PMac->source.fileName ==
>>
Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â 
mTokenizer.GetInputStreamName());
>>
>> should probably be swapped around, like so:
>>
>> Â Â Â Â  return
(Cond_Stack.back().PMac->source.fileName ==
>>
Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â 
mTokenizer.GetInputStreamName()) &&
>>
Â Â Â Â Â Â Â Â Â Â Â 
(Cond_Stack.back().PMac->endPosition ==
>>
Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â 
CurrentFilePosition());
>>
>> so that the `LexemePosition` comparison operator is only invoked if 
>> the file names match.
>>
...

Documenting that Christoph's suggested code change up top, which fixed 
the bug with Warren's original test case and related test cases I 
created, is NOT in the v38 master branch as of commit 74b3ebe0 (March 8, 
2019).

Christoph - I think - planned to fix the core issue, but this has not 
happened as of today so the bug persists.

Bill P.

[William F Pokorny] Re: alpha.10064268 freezes [2209 days 10 hours and 58 minutes ago]

Fri, 20 Mar 2020 20:25:21 GMT

On 3/20/20 2:35 PM, Warren wrote:
> If you are ever looking for a polyvalent build system for the POVRay sources (as
> much for Windows than Linux than other platforms), you should take a look at
> "CMake" (www.cmake.org). Personnally , I use it for my projects and don't regret
> it. All you have to do is writing a file:
> CMakeLists.txt (with the cmake scripting language.)
> Then the user who has downloaded (for example) the POVRay source code can choose
> the compiler, the project type (that can be 'Codelite project'/'Visual studio
> project'/'Unix Makefile'/'MinGW makefile' or many else).
> 
> Cmake is well known nowadays. ;-)
> 

Yes, I'm aware of cmake having looked at many build systems while 
digging into a particular build issue back in 2017. I think it's 
strengths come to good support for IDEs and common usage which increased 
especially while the autotools package support was unstable and 
fractured in the 2000s. It's weakness is it needs to be installed to be 
used(1); that it created it's own scripting language(2) which you have 
to learn; and that like autotools you can get into version issues(2).

At a high level I'm headed in the opposite direction to cmake and 
'autotools' support everything model with my cut down *nix only version 
of POV-Ray. I'm looking to support much less in the way of OSs and 
architectures to make my hobby like simpler.

Bill P.

(1) Not how POV-Ray is being provided today, but the autotools approach 
is the developer creates the configure script and only that configure 
script is packaged for a users/administrators to run ahead of a 
compile/install. Nothing extra needs to be installed on the system 
beyond having a compliant c++ compiler which is kinda cool.

(2) One build system I liked over both cmake and autotools -  partly due 
me already knowing tcl - was a tool called autosetup. It requires tcl to 
run, but the package includes a tiny implementation of tcl called jim 
tcl which it will compile on the fly - given an ansi-c compiler on the 
system - if need be. This build system becomes part of a project's code 
so no versioning issues. It's basically a couple guys though - and aimed 
too at just *nix and mostly c/c++. In theory at least - gnu autoconf / 
gnu make there is surer, if not at any given time better - support given 
it's a GNU tool needed for linux and gnu core tool compiles.

Aside (2a): Seeing autosetup I wondered if the cmake guys could have 
saved themselves some implementation effort by starting with an 
extension language like tcl, lua or maybe scheme/guile. GNU make itself 
now supports guile written functions - and dll extensions 'experimentally.'

[Warren] Re: alpha.10064268 freezes [2209 days 12 hours and 43 minutes ago]

Fri, 20 Mar 2020 18:40:01 GMT

If you are ever looking for a polyvalent build system for the POVRay sources (as
much for Windows than Linux than other platforms), you should take a look at
"CMake" (www.cmake.org). Personnally , I use it for my projects and don't regret
it. All you have to do is writing a file:
CMakeLists.txt (with the cmake scripting language.)
Then the user who has downloaded (for example) the POVRay source code can choose
the compiler, the project type (that can be 'Codelite project'/'Visual studio
project'/'Unix Makefile'/'MinGW makefile' or many else).

Cmake is well known nowadays. ;-)

[William F Pokorny] Re: alpha.10064268 freezes [2209 days 14 hours and 18 minutes ago]

Fri, 20 Mar 2020 17:05:21 GMT

On 3/20/20 6:20 AM, jr wrote:
...
> 
> intriguing.  does "substantially cut down" translate into subset of (current)
> features?
> 
Eventually I hope; got a list in my head.

The initial work has more to do with how things are organized and built. 
Attempting gnu make instead of autotool's automake -> make, for example. 
Lots of little things are wrong - or not quite right - in our *nix build 
system. Starting too from a new base with many of my branches merged.

Initial git repository included large boost and other libraries for 
windows builds. The size required is now much smaller due Christoph's 
work to move to c++11 threads, but as a code repository that old library 
data doesn't go away. On *nix we don't need these libraries in the 
repository at all.

The documentation(1), includes, sample scenes and code are all in the 
same repository and I think it would be better as 4 different ones. 
Though, I'm focused today on the one with the code.

Dumping the other than linux code. Otherwise, pruning the code and 
comments as much as I can. To do my own thing - with any chance of 
wrapping my head around the whole - code needs to be a POV-Ray cut down. 
I don't know windows coding and have no interest in learning. I don't 
care about the windows editor interfaces, certain functionality, etc.

A second reason to work on a cut down is my son bought me a Raspberry Pi 
4 (4GB) board for Christmas. There, even more so than on my main 
machine, I want to develop and run things entirely on a ramdisk. This 
limits the playpen as a whole to 2GB or so.

Bill P.

(1) - Recently someone submitted a github request asking for the 
documentation to be pulled out as its own repository (and with a 
documentation specific license IIRC). Seems a pretty common approach on 
github(1a). I just want that, the editor templates etc out of the way. 

(1a) - Documentation images/binaries are also often handled 'off to the 
side' of git/mercurial distributed type code control systems and these 
files are in our git repository.

[jr] Re: alpha.10064268 freezes [2209 days 20 hours and 58 minutes ago]

Fri, 20 Mar 2020 10:25:01 GMT

hi,

William F Pokorny <ano### [at] anonymousorg> wrote:
> On 12/9/19 5:03 PM, jr wrote:
> ...
> Apparently I started a response months back and didn't finish it.
> (Thunderbird was not showing anything sitting in my drafts folder.)

try handkerchief + knots.  :-)


> Up front. I'm changing direction. I'm working toward a personal,
> substantially cut down, *nix only version of POV-Ray. With new git (or
> perhaps mercurial) repositories once I get done with all the pruning.
> Meaning, while the branches I've posted are today still pull-able
> against the last commit to master more than a year ago, I no longer plan
> to update/re-base those branches should POV-Ray development resume.

intriguing.  does "substantially cut down" translate into subset of (current)
features?


> -----
> Now, completing the response to your months old questions:
>
> >
> > slightly confused by the interpolation options, they're not "regular" POV-Ray?
> Yes and no.
> ...
> Aside: Today interpolations 1 & 2 have seam and ringing artefacts,
> respectively, limiting their usefulness as functions / shapes. ...

the problem I'm seeing with media, artifacts (almost like "shadows") when using
interpolation(s).


> > after some thought, the 'Density File Pattern Updates' + 'Non-portable 32 bit
> > DF3 write capability' + perhaps 'Both image_map and pigment_map support in
> > density block'.  would that combination "play nice"?
> >
> Yes, should be you can use all those at once. I've made an effort to
> keep the branches independent even changing a couple slightly in the
> interim so they don't collide(1,2).

good, thanks.


> ...
> >> We have a single physical web site. When it goes down ...
> > it would be nice to have mirror or two.  (personally, I think that if "the gods"
> > put the content on a DVD (or two) and offered those for sale, I'd buy.  and
> > while on money, if I could take out an annual subscription of 10-15
â‚¬ or USD to
> > help maintain .. POV-Ray, I would.  (and am quite certain that I'm not alone in
> > that))
> >
> Christoph had button up at one point (for uberpov only?), but it was to
> some new-ish site and I'm leery of those. I'd subscribe too to support
> POV-Ray - if the payment mechanism reputable.

:-)  personally like using PayPal, but see below.


> Have you seen where github itself is pushing / supporting better ways to
> financially support open source projects (GitHub sponsors)? For example:
> ...

I like the apparent simplicity of a single button, but wasn't familiar with any
of the names except Patreon.  but yes, contributing via the project's home page
does seem sensible.


> I'd pay for a web-news group database searchable dump too (perhaps USB
> over DVD... :-) ) ...

(just) showing my age.  :-)


> Aside: Chris taught me individual groups can be searched via google with
> arguments:

yes, although I tend to just use 'site: povray.org'.  there's a whole vocabulary
for narrowing searches (including '+' and '-' attached to individual
words/terms, though haven't a good reference to hand).


> ...
> Anyway... Having a paid support mechanism / data-products of some kind
> or not, would be up to the core team / Chris I'd guess.

given his (understandable) pride in reaching the 25 year milestone recently, one
would hope he'll read our remarks and (deign to) comment; not holding my
breath..


> FYI. I captured your February dictionary parsing bug test case for my
> own use - thanks. No idea if/when I might get to looking at it, but it's
> now one of my parser test cases.
>
> My apologies for the SLOW response.

no need.  cheers.


regards, jr.

[William F Pokorny] Re: alpha.10064268 freezes [2210 days 18 hours and 21 minutes ago]

Thu, 19 Mar 2020 13:01:55 GMT

On 12/9/19 5:03 PM, jr wrote:
...
Apparently I started a response months back and didn't finish it. 
(Thunderbird was not showing anything sitting in my drafts folder.)

Up front. I'm changing direction. I'm working toward a personal, 
substantially cut down, *nix only version of POV-Ray. With new git (or 
perhaps mercurial) repositories once I get done with all the pruning. 
Meaning, while the branches I've posted are today still pull-able 
against the last commit to master more than a year ago, I no longer plan 
to update/re-base those branches should POV-Ray development resume.

-----
Now, completing the response to your months old questions:

> 
> slightly confused by the interpolation options, they're not "regular" POV-Ray?
Yes and no.

In my 'Density File Pattern Updates' branch interpolation 0 is the only 
option which remains untouched(a). Interpolations 1 & 2 work the same 
except the voxel half offset is fixed - voxels values are centered as 
they always should have been (Christoph asked me to add options 11 & 12 
IIRC which work with the half voxel offsets/overruns as before or like 1 
& 2 today, so there was a path for folks to duplicate the incorrect 
behavior for replication of old scenes).

(a) - Lying. There is a somewhat substantial performance improvement 
achieved by avoiding duplicate work.

There are new interpolations 3,4,5 which use a kind of exponential 
blobbing and aimed mostly at creating base isosurface functions/shapes 
though, of course, they can be used as patterns too.

There are some new pattern value generation helper interpolations in 9 & 
10 which look for the nearest non-zero, '0' interpolation which can then 
be used for complex patterning on shapes. This relates to general 
efforts. I've been attempting to come up with better ways to texture 
which allowing a larger set of pattern and shape modifiers. Warp{} the 
isosurface (or collection of placed objects) and use the same warp for 
the shape's texturing. I've posted examples of this a few times.

Interpolations 9 & 10 are basically exploring the idea of painting 
shapes with DF3s - using DF3 files as a texture mapping method.

Aside: Today interpolations 1 & 2 have seam and ringing artefacts, 
respectively, limiting their usefulness as functions / shapes. The same 
sort of problem we have today in v3.8 with the new blob potential 
pattern use - because blob shapes themselves have continuity issues when 
actually blobbing.

...
> 
> after some thought, the 'Density File Pattern Updates' + 'Non-portable 32 bit
> DF3 write capability' + perhaps 'Both image_map and pigment_map support in
> density block'.  would that combination "play nice"?
> 
Yes, should be you can use all those at once. I've made an effort to 
keep the branches independent even changing a couple slightly in the 
interim so they don't collide(1,2).

(1) - Single branches are tested alone. For multiple pulls, I test this 
only in the order of pulls I use to build my 'povr' version. So, there 
is a chance when pulling multiple branches I missed some detail where 
order matters.

(2) - I did a lot of work in the solver branch to standardize / cleanup 
epsilons and other 'magic' values which were all over the place in use 
and effectiveness. Thus far I've not used those fixes in other branches 
- though it's gotten harder and harder not to do this. The wave modifier 
/ pattern / function cleanup I've been working on need the better set 
'epsilon-like' values too.

>> ...
>> Once personal wiki's are up. They are sitting out there not very
>> visible. Is there even a page which lists user wikis?
> 
> know what you mean.  although they all have "sitemap"s, few provide table of
> contents.  (self-defeating, imo)
> 
Yep, agree.

> 
>> ...
>> With user wikis there is always the problem that we might not completely
>> understand what we are trying to document ;-). What to do when well
>> intention-ed, but wrong pages get posted?
> 
> isn't that what the "discussion" page is there for?
> 
> inadvertent errors would be corrected, I'm (fairly) sure.
> 
Yes, ideally.

> 
>> ...
>> We have a single physical web site. When it goes down or my local
>> network connection does, I'd like to have local copy of the wiki,
>> library and the newsgroup postings as I do for the documentation. Or at
>> least have snapshots of these available on the cloud - github or
>> wherever.
>> A few expert folk maintain their own web sites for what might go on a
>> wiki, but that an investment. Plus, knowing where all these web sites
>> are today means maintaining a list of links to them yourself.
> 
> it would be nice to have mirror or two.  (personally, I think that if "the gods"
> put the content on a DVD (or two) and offered those for sale, I'd buy.  and
> while on money, if I could take out an annual subscription of 10-15
â‚¬ or USD to
> help maintain .. POV-Ray, I would.  (and am quite certain that I'm not alone in
> that))
>
Christoph had button up at one point (for uberpov only?), but it was to 
some new-ish site and I'm leery of those. I'd subscribe too to support 
POV-Ray - if the payment mechanism reputable.

Have you seen where github itself is pushing / supporting better ways to 
financially support open source projects (GitHub sponsors)? For example:

https://www.youtube.com/watch?v=FYkBA9epUEk

and

https://www.youtube.com/watch?v=e_zhHQXTwVo

and

https://help.github.com/en/github/administering-a-repository/displaying-a-sponsor-button-in-your-repository

I've watched a few of the videos and they're good in pointing out that, 
in other than single developer projects, support means more than just 
gathering money. It means establishing and maintaining a governing group 
deciding direction / how to spend. Otherwise you can end up with a pile 
of money and no idea/mechanism for how to spend it...

I'd pay for a web-news group database searchable dump too (perhaps USB 
over DVD... :-) ) - the news server representation is only correct for 
the more current posts (last 10 years or so). Searches done via 
thunderbird don't turn up - say pre 2007 stuff - though how far back it 
works depends some on the group. If you know it's an old topic, the web 
search is the only way to go - but a few times now I've struggled 
finding what I want with this google based method.

Aside: Chris taught me individual groups can be searched via google with 
arguments:

site:news.povray.org/povray.bugreports/ freezes

but that doesn't turn up anything, where say:

site:news.povray.org/povray.bugreports/ crash

does. Not dug much, but it seems like the google indexing is perhaps 
done only once in a while - like it's lagging substantially (a year?). 
Don't know. The by group method is useful, but I find myself not 
counting on the google search completely either at this point.

Anyway... Having a paid support mechanism / data-products of some kind 
or not, would be up to the core team / Chris I'd guess.

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

FYI. I captured your February dictionary parsing bug test case for my 
own use - thanks. No idea if/when I might get to looking at it, but it's 
now one of my parser test cases.

My apologies for the SLOW response.

Bill P.

[GioSeregni] Re: GIF interlaced are not properly recognized [2226 days 9 hours and 38 minutes ago]

Tue, 3 Mar 2020 21:45:01 GMT

Le_Forgeron <jgr### [at] freefr> wrote:
> Le 03/03/2020 Ã  07:04, GioSeregni a Ã©critÂ :
> > Hi all.
> > I went crazy with the code because with "ONCE" activated I kept seeing GIF
> > images strechted and repeated 4 times.
> > The same images, which I hadn't saved recently, were regular.
> > Then I understand, now Irfanview has the INTERLACED option by default, but this
> > is not recognized and the decoding of the image is wrong.
> > Regards
> > G.
> >
> >
>
> Well, the problem should be handled in povray,
> since FS#314, but seems the correction did not make it in the official
> code. (not the 3.7 stable anyway)
>
> But it is already fixed on the official master.
>
> For the curious, in source/base/image/gif.cpp, the check for interlaced
> gif should look at buffer[8] and not buffer[9] (for & 0x40)
>
> Now, you won't be happy with the correction either, because interlaced
> gif are not supported but you will get an interruption at parse time
> instead of rendering (so it will save you time).


Thanks for your kind reply, it's ok, in my opinion the problem arises if the
user doesn't know it, because if he thinks it's his code's fault he can work
hours without finding a solution.Best Regards and thanks again!
G.

[Le Forgeron] Re: GIF interlaced are not properly recognized [2226 days 11 hours and 32 minutes ago]

Tue, 3 Mar 2020 19:50:59 GMT

Le 03/03/2020 Ã  07:04, GioSeregni a Ã©critÂ :
> Hi all.
> I went crazy with the code because with "ONCE" activated I kept seeing GIF
> images strechted and repeated 4 times.
> The same images, which I hadn't saved recently, were regular.
> Then I understand, now Irfanview has the INTERLACED option by default, but this
> is not recognized and the decoding of the image is wrong.
> Regards
> G.
> 
> 

Well, the problem should be handled in povray,
since FS#314, but seems the correction did not make it in the official
code. (not the 3.7 stable anyway)

But it is already fixed on the official master.

For the curious, in source/base/image/gif.cpp, the check for interlaced
gif should look at buffer[8] and not buffer[9] (for & 0x40)

Now, you won't be happy with the correction either, because interlaced
gif are not supported but you will get an interruption at parse time
instead of rendering (so it will save you time).

[GioSeregni] GIF interlaced are not properly recognized [2227 days 1 hour and 18 minutes ago]

Tue, 3 Mar 2020 06:05:00 GMT

Hi all.
I went crazy with the code because with "ONCE" activated I kept seeing GIF
images strechted and repeated 4 times.
The same images, which I hadn't saved recently, were regular.
Then I understand, now Irfanview has the INTERLACED option by default, but this
is not recognized and the decoding of the image is wrong.
Regards
G.

[jr] Re: The '#box' directive doesn't give error at p... [2249 days 16 hours and 33 minutes ago]

Sun, 9 Feb 2020 14:50:00 GMT

hi,

"Warren" <nomail@nomail> wrote:
> >> jr and Bald Eagle have written [...].
>
> I wasn't aware of all that at all :-(.

on the bright side, as documented, everything works.  (mostly ;-))


regards, jr.

[Warren] Re: The '#box' directive doesn't give error at p... [2249 days 21 hours and 33 minutes ago]

Sun, 9 Feb 2020 09:50:01 GMT

>> jr and Bald Eagle have written [...].

I wasn't aware of all that at all :-(.

[jr] Re: The '#box' directive doesn't give error at p... [2250 days 17 hours and 18 minutes ago]

Sat, 8 Feb 2020 14:05:01 GMT

hi,

"Bald Eagle" <cre### [at] netscapenet> wrote:
> ...
> If you have an example which results in an actual error at parse time,
> I'd like to get it.
>
> I have a collection of parser test cases and I spent time yesterday
> capturing/creating parser test cases for these '#' variants. I didn't
> come up with anything that generated an actual parse error - or render
> problem - only the warnings above.


File 'be_error.pov' line 25: Possible Parse Error: Uncategorized error thrown at
 parser/symboltable.cpp line 157.
Fatal error in parser: Uncategorized error.
Render failed

file 'be_error.pov':
----------<snip>----------
#version 3.8;

global_settings {assumed_gamma 1}

#if (0)
#macro AA()
  #local d_ = dictionary;
  #local d_.k  = 1;
  d_
#end
#else
#macro AA()
  #local k_ = 1;
dictionary {.k: k_}
#end
#end

#macro BB(dict_)
  #debug concat("key k = ",str(dict_.k,0,0),"\n")
#end

#macro CC()
  #local d_ = AA();
  BB(d_)
#end

CC()

----------<snip>----------

the 'else' branch works as expected.

hth.


regards, jr.

[jr] Re: The '#box' directive doesn't give error at p... [2250 days 17 hours and 33 minutes ago]

Sat, 8 Feb 2020 13:50:00 GMT

hi,

"Bald Eagle" <cre### [at] netscapenet> wrote:
> "jr" <cre### [at] gmailcom> wrote:
>
> > I remember reading (in one of the newsgroup posts) about an issue/bug regarding
> > the '#default {}' directive, which also works without the '#'.  fwiw:
>
> Yes, and there was more than that as well.
>
> see:
>
http://news.povray.org/povray.general/thread/%3Cweb.5d8f1cd3fe1f4a21e462584c0%40news.povray.org%3E/?mtop=428173&moff=
5


thanks for digging this out, sad to say I'd forgotten the a lot (most?) of the
details.


> ...
> If you have an example which results in an actual error at parse time,
> I'd like to get it.

I happened to come across an error a few days ago  :-), I'll try and reproduce
it with a little scene, to post.


> I have a collection of parser test cases and I spent time yesterday
> capturing/creating parser test cases for these '#' variants. I didn't
> come up with anything that generated an actual parse error - or render
> problem - only the warnings above.
>
> I did come up with a case with isolated #s ahead of a bare 'declare'
> which did NOT generate the warnings above (I found a parser bug) though
> the render result was still fine.
>
> .....
>
> Unsure if you were agreeing we should be getting such warnings, or
> saying POV-Ray does generate such a warning. If the latter, I never saw
> that while trying different things. If warnings for #Primitive_Name do
> sometimes happen, I'd like an example test case for my collection.
>
> Also had the thought last night, Does say '#accuracy 0.001' work..? It
> does.

I think I'm mostly with Alain on this, both '#object' and '#accuracy' are ..
objectionable imo.


> So, yes - there's still a lot of work that needs to be done with the parser.
> And that may explain why clipka's locked himself in an isolation chamber for
> quite some time now.   If that's what he's actually doing, then he may need
> years of therapy...

when was the last time?  must be a year by now.


regards, jr.

[Bald Eagle] Re: The '#box' directive doesn't give error at p... [2250 days 17 hours and 53 minutes ago]

Sat, 8 Feb 2020 13:30:00 GMT

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

> I remember reading (in one of the newsgroup posts) about an issue/bug regarding
> the '#default {}' directive, which also works without the '#'.  fwiw:

Yes, and there was more than that as well.

see:
http://news.povray.org/povray.general/thread/%3Cweb.5d8f1cd3fe1f4a21e462584c0%40news.povray.org%3E/?mtop=428173&moff=5

3) And a lesson for me!
Saw #object (which you shouldn't need for the trace) and #cylinder;
Thought, "Does that really work?" It does! You can also stick '#' on the
end on some lines or code #declare CylinderZ = #cylinder {} and nary a
peep or problem from the parser - new or old versions. The usual and
recommended syntax is object {} and cylinder {}.

A declare without the leading # works too but we get:

File 'tmp.pov' line 40: Parse Warning: Should have '#' before 'declare'.
File 'tmp.pov' line 40: Possible Parse Error: 'declare' should be changed to
  '#declare'. Future versions may not support 'declare' and may require
  '#declare'.

Given this warning, I'd think we should be getting one on #object {} and
the like too as the other side of the syntax change push - now that I
understand there is another side.

Suppose this behavior related to Christoph's recommendation to me back
in February to use default {} rather than #default {} though it's the
latter which is still in the documentation. The idea, as I understand
it, is to get to where the #<token> is used only with SDL language
control elements.

and

If you have an example which results in an actual error at parse time,
I'd like to get it.

I have a collection of parser test cases and I spent time yesterday
capturing/creating parser test cases for these '#' variants. I didn't
come up with anything that generated an actual parse error - or render
problem - only the warnings above.

I did come up with a case with isolated #s ahead of a bare 'declare'
which did NOT generate the warnings above (I found a parser bug) though
the render result was still fine.

.....

Unsure if you were agreeing we should be getting such warnings, or
saying POV-Ray does generate such a warning. If the latter, I never saw
that while trying different things. If warnings for #Primitive_Name do
sometimes happen, I'd like an example test case for my collection.

Also had the thought last night, Does say '#accuracy 0.001' work..? It
does.

So, yes - there's still a lot of work that needs to be done with the parser.
And that may explain why clipka's locked himself in an isolation chamber for
quite some time now.   If that's what he's actually doing, then he may need
years of therapy...

[jr] Re: The '#box' directive doesn't give error at p... [2250 days 18 hours and 13 minutes ago]

Sat, 8 Feb 2020 13:10:00 GMT

hi,

"Warren" <nomail@nomail> wrote:
> While I was making a new scene with POVRay, I found (by sheer luck) something
> weird, with the following scene:
>
> #version 3.7;
>
> global_settings{ assumed_gamma 1.0 }
>
> background{ color srgb 1 }
>
> camera{
>     location < 1, 1, -2 >
>     look_at <0, 0.5, 0>
> }
>
> light_source{ < 1, 2, -3 > * 1000000 color srgb 1 }
>
> #box{< 0, 0, 0>, < 1, 7/47, 1 > pigment{ color srgb < 1, 1, 0> } }
>
> //End of file
>
> In this .pov file you can notice there's that '#box' keyword that doesn't
> prevent the POVRay parser from making a new image (I can see a yellow box in a
> white background). Before I report that bug , I wondrered if there was a
> preprocessor keyword in the Scene Description Language which name is box, but I
> didn't find anything in google or qwant. The above scene has been tested with
> povray 3.7.0.8 unofficial and povray 3.8.0 alpha unofficial both compiled with
> g++-9.2.0. The end line type of the scene file is CRLF and working renders were
> done with "Lubuntu 19.10 eoan ermine".

I remember reading (in one of the newsgroup posts) about an issue/bug regarding
the '#default {}' directive, which also works without the '#'.  fwiw:

#version 3.7;
#global_settings{ assumed_gamma 1.0 }
#background{ color srgb 1 }
#camera{
    location < 1, 1, -2 >
    look_at <0, 0.5, 0>
}
#light_source{ < 1, 2, -3 > * 1000000 color srgb 1 }
#box{< 0, 0, 0>, < 1, 7/47, 1 > pigment{ color srgb < 1, 1, 0> } }

too renders the image (3.8.0-alpha.10064268.unofficial).


regards, jr.

[Warren] The '#box' directive doesn't give error at parse... [2250 days 18 hours and 58 minutes ago]

Sat, 8 Feb 2020 12:25:01 GMT

Hello/Hi,

While I was making a new scene with POVRay, I found (by sheer luck) something
weird, with the following scene:

#version 3.7;

global_settings{ assumed_gamma 1.0 }

background{ color srgb 1 }

camera{
    location < 1, 1, -2 >
    look_at <0, 0.5, 0>
}

light_source{ < 1, 2, -3 > * 1000000 color srgb 1 }

#box{< 0, 0, 0>, < 1, 7/47, 1 > pigment{ color srgb < 1, 1, 0> } }

//End of file

In this .pov file you can notice there's that '#box' keyword that doesn't
prevent the POVRay parser from making a new image (I can see a yellow box in a
white background). Before I report that bug , I wondrered if there was a
preprocessor keyword in the Scene Description Language which name is box, but I
didn't find anything in google or qwant. The above scene has been tested with
povray 3.7.0.8 unofficial and povray 3.8.0 alpha unofficial both compiled with
g++-9.2.0. The end line type of the scene file is CRLF and working renders were
done with "Lubuntu 19.10 eoan ermine".

[Bald Eagle] cutaway_textures fails in difference {} [2259 days 5 hours and 38 minutes ago]

Fri, 31 Jan 2020 01:45:00 GMT

Doing too much real work - no energy to focus on the complicated POV-Ray stuff,
so I was just doing a simple doodle.

I recalled cutaway_textures for what I needed, but when I used it in a
difference with an untextured object, the default gray shows up.

I would up using rgbt 1 for the differenced-away object, but the result is
pretty bad.

Cutaway_textures seems to work fine in the intersection {}, and the result is
MUCH better.

See:
http://news.povray.org/povray.binaries.images/message/%3Cweb.5e3385683e47cf574eec112d0%40news.povray.org%3E/#%3Cweb.5e3
385683e47cf574eec112d0%40news.povray.org%3E

Here's the relevant code block:

#declare Bowl =
intersection {
 difference {
  object {Block}
  object {Inner}
  cutaway_textures
 }
 object {Outer}
 cutaway_textures
}

[jr] Re: alpha.10064268 freezes [2311 days 9 hours and 18 minutes ago]

Mon, 9 Dec 2019 22:05:01 GMT

hi,

William F Pokorny <ano### [at] anonymousorg> wrote:
> On 12/6/19 10:59 AM, jr wrote:
> ...
> >> Interpolation with respect to media... Not completely sure what you
> >> mean, but, there are directions on my wiki page at:
> >
> > in a 'density {}' loaded from df3.
> >
> Ah, OK. Depending on how you're using the df3 in media it might be worth
> giving my wiki page: ,,,
> a read. There are issues with the df3 interpolation which can make using
> it tricky.

slightly confused by the interpolation options, they're not "regular" POV-Ray?
which of the 'playpen' branches deals with those?


> > right, had a quick look at your wiki page.  so generally, first git clone
> > POV-Ray master, then the checkout/pull sequence near bottom (with name of
> > branch)?  I found an ebook/pdf (by S Chacon), am resigned to having to read it.
> > ...in the coming days.  :-)
>
> Yeah, you got the idea. Intent was to set it up so folks building
> POV-Ray themselves could roll their own derivatives of POV-Ray chosing
> what branches they want to merge into the current master for their
> version. Might be they have three branches of their own, might want to
> use 2 of mine, 3 of SuperCoder12StrandedOnMarsEatingPotatoes etc.

after some thought, the 'Density File Pattern Updates' + 'Non-portable 32 bit
DF3 write capability' + perhaps 'Both image_map and pigment_map support in
density block'.  would that combination "play nice"?


> >> ...
> >> (1) - The inability to add new links to discussion and documentation
> >> made the wiki much less useful - and I've more or less just been letting
> >> my pages sit as is for long time.
> >
> > I've been toying with the idea of trying to get a wiki page, for the df3-tools
> > mainly.  but the site seems quite static, not really encouraging contribution (I
> > feel).
> >
> ...
> (1) - Zim a neat tool. Though it's spell checker broke for time while I
> was using it due a Ubuntu release...

thanks.  not an immediate need (for me), have O'Reilly's "MediaWiki", but have
some time ago switched to using the 'fossil' in-built wiki for most stuff.


> ...
> Once personal wiki's are up. They are sitting out there not very
> visible. Is there even a page which lists user wikis?

know what you mean.  although they all have "sitemap"s, few provide table of
contents.  (self-defeating, imo)


> ...
> With user wikis there is always the problem that we might not completely
> understand what we are trying to document ;-). What to do when well
> intention-ed, but wrong pages get posted?

isn't that what the "discussion" page is there for?

inadvertent errors would be corrected, I'm (fairly) sure.


> ...
> We have a single physical web site. When it goes down or my local
> network connection does, I'd like to have local copy of the wiki,
> library and the newsgroup postings as I do for the documentation. Or at
> least have snapshots of these available on the cloud - github or
> wherever.
> A few expert folk maintain their own web sites for what might go on a
> wiki, but that an investment. Plus, knowing where all these web sites
> are today means maintaining a list of links to them yourself.

it would be nice to have mirror or two.  (personally, I think that if "the gods"
put the content on a DVD (or two) and offered those for sale, I'd buy.  and
while on money, if I could take out an annual subscription of 10-15 € or USD to
help maintain .. POV-Ray, I would.  (and am quite certain that I'm not alone in
that))


regards, jr.

[William F Pokorny] Re: alpha.10064268 freezes [2313 days 16 hours and 2 minutes ago]

Sat, 7 Dec 2019 15:20:55 GMT

On 12/6/19 10:59 AM, jr wrote:
...
>> Interpolation with respect to media... Not completely sure what you
>> mean, but, there are directions on my wiki page at:
> 
> in a 'density {}' loaded from df3.
> 
Ah, OK. Depending on how you're using the df3 in media it might be worth 
giving my wiki page:

  http://wiki.povray.org/content/User:Wfpokorny/DensityFile

a read. There are issues with the df3 interpolation which can make using 
it tricky.

> right, had a quick look at your wiki page.  so generally, first git clone
> POV-Ray master, then the checkout/pull sequence near bottom (with name of
> branch)?  I found an ebook/pdf (by S Chacon), am resigned to having to read it.
> ...in the coming days.  :-)
> 

Yeah, you got the idea. Intent was to set it up so folks building 
POV-Ray themselves could roll their own derivatives of POV-Ray chosing 
what branches they want to merge into the current master for their 
version. Might be they have three branches of their own, might want to 
use 2 of mine, 3 of SuperCoder12StrandedOnMarsEatingPotatoes etc.

> 
>> ...
>> (1) - The inability to add new links to discussion and documentation
>> made the wiki much less useful - and I've more or less just been letting
>> my pages sit as is for long time.
> 
> I've been toying with the idea of trying to get a wiki page, for the df3-tools
> mainly.  but the site seems quite static, not really encouraging contribution (I
> feel).
> 
...
Don't have time for real hobby coding this morning before being tied up 
for some days. Why not some rambling thoughts about the wiki...

---
Over the last month or more, Maurice has been substantially improving the

http://wiki.povray.org/content/HowTo:Use_POV-Ray_with_Blender

page which can be found off of the

http://wiki.povray.org/content/HowTo:Contents

page. This evidence not everything is stale on the wiki. Folks do make 
updates.

But, I agree the wiki is kinda stale. Writing wikis not too bad for 
simple one page an image two sorts of things. For more, I find it 
cumbersome.

In addition to trouble creating links to other pages:

To write more than one page, as with the density file pattern stuff, I 
found the coding and previewing via the web cumbersome.  I ended up 
using a linux tool called Zim to first code, review, organize and refine 
the pages locally(1). The wiki encoding though was slightly different 
than that of POV-Ray's wiki implementation. It was a pain to transfer 
everything to the POV-Ray wiki(2). I got some of this wrong due cut and 
pasting, formatting differences, etc.

(1) - Zim a neat tool. Though it's spell checker broke for time while I 
was using it due a Ubuntu release...

(2) - Now that everything on the POV-Ray wiki, major revisions can no 
longer easily be done locally within Zim...

I found myself revising / changing images, but there is no way to delete 
old ones yourself, so you end up being overly careful using images. With 
some I replaced the image with much simpler "delete me" ones hoping some 
admin would see this and do it. Suppose behavior might be due a wiki 
being able to back up to old versions, but if I'm creating the first 
release of some documentation I don't want all the old versions to exist 
but just the 'released' one.

Once personal wiki's are up. They are sitting out there not very 
visible. Is there even a page which lists user wikis? Maintained pages 
sit on a wiki where lots of stuff has fallen out of date and needs 
revision. People see that general staleness and shy away both from 
reading the wiki entries - and from updating old ones.

Normal users cannot update the stuff they don't own. A few super users 
can - spam concerns again I guess. This forces normal users into a "can 
I get the attention of a super user;" then into a sort of type this, 
then this, kinda of loop with them; on seeing some wrong or wanting some 
change. This loop too is cumbersome. It gets to there being nobody being 
paid to stay on top of the wiki and documentation always. Someone always 
finding and refining issues as their job. We have similar issues with 
the core documentation/build and release systems too as mentioned 
elsewhere.

With user wikis there is always the problem that we might not completely 
understand what we are trying to document ;-). What to do when well 
intention-ed, but wrong pages get posted? Wikipedia has this problem 
too. What they've done with subjects like Math is gather/(pay?) experts 
as arbiters for what's written - much better end result, but still you 
occasionally run across mistakes and biases in what's written.

We have a single physical web site. When it goes down or my local 
network connection does, I'd like to have local copy of the wiki, 
library and the newsgroup postings as I do for the documentation. Or at 
least have snapshots of these available on the cloud - github or 
wherever.

A few expert folk maintain their own web sites for what might go on a 
wiki, but that an investment. Plus, knowing where all these web sites 
are today means maintaining a list of links to them yourself.

Back to the Zim tool, its github wiki page at:

https://github.com/jaap-karssenberg/zim-wiki/wiki

is an interesting model for putting a wiki on github. The wiki link on 
the Zim web site links to the github wiki above.

Bill P.

[jr] Re: alpha.10064268 freezes [2314 days 15 hours and 23 minutes ago]

Fri, 6 Dec 2019 16:00:01 GMT

hi,

William F Pokorny <ano### [at] anonymousorg> wrote:
> On 12/4/19 12:10 PM, jr wrote:
> ...
> > sounds like a good starting point.  artefacts seem to appear when I use
> > interpolation, so interested in the difference that code will make.  what is the
> > build/install procedure?  (sorry to use up yr time, mostly familiar with the
> > usual '.tar's, not "pulling" (+ merging?))
> ...
> Interpolation with respect to media... Not completely sure what you
> mean, but, there are directions on my wiki page at:

in a 'density {}' loaded from df3.


> http://wiki.povray.org/content/User:Wfpokorny
> Though the branches available are out of date on it(1). You can get a
> current list of published branches on github. A graph/network view be
> seen by going to:
> https://github.com/wfpokorny/povray/network
> and you can also see a list using the branch switching list-pick button
> on the page:
> https://github.com/wfpokorny/povray
>
> You have to be in a position to build your own *nix versions of POV-Ray
> If you're not, well, what I have out there today isn't going to be
> useful to you.

right, had a quick look at your wiki page.  so generally, first git clone
POV-Ray master, then the checkout/pull sequence near bottom (with name of
branch)?  I found an ebook/pdf (by S Chacon), am resigned to having to read it.
...in the coming days.  :-)


> ...
> (1) - The inability to add new links to discussion and documentation
> made the wiki much less useful - and I've more or less just been letting
> my pages sit as is for long time.

I've been toying with the idea of trying to get a wiki page, for the df3-tools
mainly.  but the site seems quite static, not really encouraging contribution (I
feel).


regards, jr.

[William F Pokorny] Re: alpha.10064268 freezes [2315 days 19 hours and 42 minutes ago]

Thu, 5 Dec 2019 11:40:23 GMT

On 12/4/19 12:10 PM, jr wrote:
...
>>
>> I've never published a merged branch of all the branches I run as 'povr'
>> - partly because what I run contains more branches / differences to
>> master than those I've published to github. Also 'povr' is meant to be a
>> temporal thing based on the current master branch into which continually
>> re-based to master branches are merged.
>>
>> That said, my published solver branch addresses many artifacts media and
>> otherwise - and extends the range over which containers work for media.
>> This work though is limited to shapes using the common solvers.
> 
> sounds like a good starting point.  artefacts seem to appear when I use
> interpolation, so interested in the difference that code will make.  what is the
> build/install procedure?  (sorry to use up yr time, mostly familiar with the
> usual '.tar's, not "pulling" (+ merging?))
> 
...
> 

Interpolation with respect to media... Not completely sure what you 
mean, but, there are directions on my wiki page at:

http://wiki.povray.org/content/User:Wfpokorny

Though the branches available are out of date on it(1). You can get a 
current list of published branches on github. A graph/network view be 
seen by going to:

https://github.com/wfpokorny/povray/network

and you can also see a list using the branch switching list-pick button 
on the page:

https://github.com/wfpokorny/povray

You have to be in a position to build your own *nix versions of POV-Ray 
If you're not, well, what I have out there today isn't going to be 
useful to you.

You need to have git installed and to have a local clone of povray to 
follow the pick and chose branches to merge into your personal version 
of POV-Ray method on the wiki. If you are compiling via download and 
just want to try a single branch, you can switch to it, download the 
branch to your machine & compile normally.

Bill P.

(1) - The inability to add new links to discussion and documentation 
made the wiki much less useful - and I've more or less just been letting 
my pages sit as is for long time.

[jr] Re: alpha.10064268 freezes [2316 days 14 hours and 8 minutes ago]

Wed, 4 Dec 2019 17:15:01 GMT

hi,

William F Pokorny <ano### [at] anonymousorg> wrote:
> On 12/3/19 12:07 PM, jr wrote:
> >
> ...
> >>
> >> Anyway, very likely more than a month before I'd have the time to look
> >> at this in any depth.
> >
> > also no problem (for me).  out of interest, what advantages does your fork have
> > wrt media artefacts, media in general?
> >
> ...
> >
>
> :-) Simple question with a non-simple answer...
>
> I've never published a merged branch of all the branches I run as 'povr'
> - partly because what I run contains more branches / differences to
> master than those I've published to github. Also 'povr' is meant to be a
> temporal thing based on the current master branch into which continually
> re-based to master branches are merged.
>
> That said, my published solver branch addresses many artifacts media and
> otherwise - and extends the range over which containers work for media.
> This work though is limited to shapes using the common solvers.

sounds like a good starting point.  artefacts seem to appear when I use
interpolation, so interested in the difference that code will make.  what is the
build/install procedure?  (sorry to use up yr time, mostly familiar with the
usual '.tar's, not "pulling" (+ merging?))

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

thank you for this link.  bookmarked.  much to take in.


regards, jr.

[William F Pokorny] Re: alpha.10064268 freezes [2316 days 17 hours and 35 minutes ago]

Wed, 4 Dec 2019 13:47:57 GMT

On 12/3/19 12:07 PM, jr wrote:
> 
...
>>
>> Anyway, very likely more than a month before I'd have the time to look
>> at this in any depth.
> 
> also no problem (for me).  out of interest, what advantages does your fork have
> wrt media artefacts, media in general?
> 
...
> 

:-) Simple question with a non-simple answer...

I've never published a merged branch of all the branches I run as 'povr' 
- partly because what I run contains more branches / differences to 
master than those I've published to github. Also 'povr' is meant to be a 
temporal thing based on the current master branch into which continually 
re-based to master branches are merged.

That said, my published solver branch addresses many artifacts media and 
otherwise - and extends the range over which containers work for media. 
This work though is limited to shapes using the common solvers.

There is a published branch addressing the photon media deposit banding. 
I assume that was some debugging left in as I see no reason to introduce 
banding except to get some visual feedback of the sampling periodicity 
while developing code.

There is a published branch for one version of a change published for 
jitter and adaptive media 3 which helps scene-performance up to 5%, if 
your scene is media dominated and you're not using media jitter - and 
one shouldn't with media method 3 unless they want noise.

Non-published branches...

I have another version of the media 3 jitter changes which is faster 
still, but it's also more intrusive code wise and so more difficult to 
re-base. I didn't use/re-base this branch in my last create a 'povr' 
pass.

Suppose some of the recent pattern and wave modifier work touches media 
too and issues fixed more likely to show up with media given the 
containing shapes like isosurfaces, but also the sampling periodicity is 
more likely to numerically land badly. With that last though, the 
sampling, if set deep enough, probably mostly hides any wave modifier 
issues.

Aside: At one time I naively thought there was an issue or two with 
media, but a year plus back mentally carrying 8-10 media media artifact 
causes. It's a bunch of stuff - and media turns out to be a great way to 
test for underlying problems! Though, if you asked me in this moment to 
list them all, I'd be hard pressed to do it. Not worked specifically on 
media in a while. For me, newer work tends to push the old out of my 
head - given the lack of space, the near continual wind storm and 
general clutter up there... :-)

Oh, I never got to testing code, but I started a local branch supporting 
a second emission specific media absorption specification/control. In a 
scene Norbert posted a year or more back based on Gilles Tran's cloud 
technique using scattering, emission and absorption together with media 
there was color clipping due how the emission was cleverly used and this 
demonstrated that media emission needs it's own media, 
emission-absorption control(1).

Lastly, something not fixed in any code of which I'm aware - I tried and 
failed for a fix. One needs to be sure light sources are outside any 
media container, if you want all the media related controls/attenuation 
to best work(2). True even if you have to cut a small void in the media 
container around your lights to get this set up. See:

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

Bill P.

(1) Or - maybe - should always internally absorb at a color matching the 
emission color. This, I think, would align OK with physical behavior for 
florescent media, but it would be more limiting and it would change the 
look of current scenes with emissive media.

(2) I've since stumbled across a post from back in the 2000s where 
someone else (Bruno Cabasson?) had discovered this issue too suggesting 
the same work-around. IIRC even with the workaround we are left not 
being able to turn media attenuation off in containers.

[jr] Re: alpha.10064268 freezes [2316 days 20 hours and 13 minutes ago]

Wed, 4 Dec 2019 11:10:01 GMT

hi,

> William F Pokorny <ano### [at] anonymousorg> wrote:
> > On 12/3/19 8:37 AM, jr wrote:
> > ...
> > ...
> > If true, this, I think, amounts to overlapped textures and it's why I
> > assumed your image_map would have transparency everywhere except the
> > 'decal.' Maybe the lack of any transparency/alpha channel is tangled in
> > the reason for the crash?

re-rendered the name plate ("decal") with '+ua', appears to make no difference.


regards, jr.

[jr] Re: alpha.10064268 freezes [2317 days 14 hours and 13 minutes ago]

Tue, 3 Dec 2019 17:10:00 GMT

hi,

William F Pokorny <ano### [at] anonymousorg> wrote:
> On 12/3/19 8:37 AM, jr wrote:
> ...
> Alright... So, all you did to get the crash/freeze was add a second
> pigment { image_map {...}} after the first pigment {} leaving both
> un-commented when you run the object collection's most current android
> robot scene?

correct.

> If true, this, I think, amounts to overlapped textures and it's why I
> assumed your image_map would have transparency everywhere except the
> 'decal.' Maybe the lack of any transparency/alpha channel is tangled in
> the reason for the crash? That you are sometimes getting stuff to sort
> of work puzzles me too.
>
> And apologies I wasn't clear I was interested in v3.70 (stable) over
> anything after, though whatever you see with the v3.71 release is
> interesting and perhaps useful to know too.

no problem, version 3.7.0.8 too hangs (pigment as shown).

> And my brain cells being earlier stirred have since remembered the other
> image_map issue had something to do - I think - with adding transparency
> via the 'transmit' keyword. Head also popped the question of whether the
> fix for Warren's macro issue of this past April made it into the master
> branch. I still have my local branch fix, so maybe not? I usually delete
> my local fixes once things fixed in master.
>
> Anyway, very likely more than a month before I'd have the time to look
> at this in any depth.

also no problem (for me).  out of interest, what advantages does your fork have
wrt media artefacts, media in general?


regards, jr.

[William F Pokorny] Re: alpha.10064268 freezes [2317 days 16 hours and 5 minutes ago]

Tue, 3 Dec 2019 15:17:55 GMT

On 12/3/19 8:37 AM, jr wrote:
> hi,
> 
...
> 
Alright... So, all you did to get the crash/freeze was add a second 
pigment { image_map {...}} after the first pigment {} leaving both 
un-commented when you run the object collection's most current android 
robot scene?

If true, this, I think, amounts to overlapped textures and it's why I 
assumed your image_map would have transparency everywhere except the 
'decal.' Maybe the lack of any transparency/alpha channel is tangled in 
the reason for the crash? That you are sometimes getting stuff to sort 
of work puzzles me too.

And apologies I wasn't clear I was interested in v3.70 (stable) over 
anything after, though whatever you see with the v3.71 release is 
interesting and perhaps useful to know too.

And my brain cells being earlier stirred have since remembered the other 
image_map issue had something to do - I think - with adding transparency 
via the 'transmit' keyword. Head also popped the question of whether the 
fix for Warren's macro issue of this past April made it into the master 
branch. I still have my local branch fix, so maybe not? I usually delete 
my local fixes once things fixed in master.

Anyway, very likely more than a month before I'd have the time to look 
at this in any depth.

Bill P.

[jr] Re: alpha.10064268 freezes [2317 days 17 hours and 43 minutes ago]

Tue, 3 Dec 2019 13:40:00 GMT

hi,

William F Pokorny <ano### [at] anonymousorg> wrote:
> On 12/3/19 4:53 AM, jr wrote:
> > "jr" <cre### [at] gmailcom> wrote:
> ...
> > some more information (fwiw).  same error in alpha.9945627.  without the 'once'
> > keyword the scene renders (but not useful since the decal repeats).
>
> I've not much hobby time at the moment and what I have is going toward
> other stuff. As always, having a small-ish complete scene which shows
> the problem would be a help to whomever debugs.

using the scene from the collection zip verbatim, except for adding an
equivalent pigment, does illustrate the issue.

> - What happens if you leave 'once' but scale up enough to be sure the
> robot is covered by the image_map-once? Don't worry about how it would
> look.

no difference in the 3.8 versions.  3.7.1-alpha.8656843 - v interesting.  using
the pigment as shown, I get the single decal but the other texture has turned
transparent and the droid looks like a weird mix of glass and (white) emissive
media.  :-)

> - What happens with v3.7? The image_map alpha channel / transparency
> handling was re-worked in v3.8 IIRC.
>
> - Have a vague recollection of another image_map alpha channel /
> transparency related issue in v3.8 too for which I don't think there was
> a resolution. I don't remember details at the moment. If so, we should
> find that thread and add a link here to it and visa versa.

the image is 8-bit rgb, no alpha, in case it matters.


regards, jr.

[William F Pokorny] Re: alpha.10064268 freezes [2317 days 18 hours and 53 minutes ago]

Tue, 3 Dec 2019 12:30:19 GMT

On 12/3/19 4:53 AM, jr wrote:
> "jr" <cre### [at] gmailcom> wrote:
...
> 
> some more information (fwiw).  same error in alpha.9945627.  without the 'once'
> keyword the scene renders (but not useful since the decal repeats).
> 

I've not much hobby time at the moment and what I have is going toward 
other stuff. As always, having a small-ish complete scene which shows 
the problem would be a help to whomever debugs.

- What happens if you leave 'once' but scale up enough to be sure the 
robot is covered by the image_map-once? Don't worry about how it would 
look.

- What happens with v3.7? The image_map alpha channel / transparency 
handling was re-worked in v3.8 IIRC.

- Have a vague recollection of another image_map alpha channel / 
transparency related issue in v3.8 too for which I don't think there was 
a resolution. I don't remember details at the moment. If so, we should 
find that thread and add a link here to it and visa versa.

Bill P.

[jr] Re: alpha.10064268 freezes [2317 days 21 hours and 28 minutes ago]

Tue, 3 Dec 2019 09:55:00 GMT

"jr" <cre### [at] gmailcom> wrote:
> using alpha.10064268, dies with:
>
>   Fatal error in renderer: Frontend halted render.
>
> I'm trying to add a logo/decal to an Android model (version 4, POVCollection
> #590224).
>
> the code is taken from 'androidrobot_posed.pov', with minor modification, and
> the error occurs when the pigment is uncommented.
> when I reverse the order of the pigments, POV-Ray runs ok, but, of course, that
> is no help.
> -----<snip>-----
> #declare droid_ = union {
>   object {
>
> AndroidRobot_Posed(no,HeadRotate,LArmRotate,RArmRotate,LLegRotate,RLegRotate)
>     pigment {ANDROIDROBOT_C_COLOR}
> //    pigment {image_map {png "plate.png" once} scale .2}
>     finish {
>       reflection {.5 metallic}
>       diffuse DIFFUSE * .5
>       ambient C_AMBIENCE * .5
>       specular 1.788 metallic
>       roughness .05
>       brilliance 1.857
>     }
>   }
>   union {
>     object {UserDefinedEye}
>     object {UserDefinedEye scale <1,1,-1>}
>     AndroidRobot_Head_x (HeadRotate)
>   }
>   rotate 90 * y
>   translate -ANDROIDROBOT_V_BASE
> };
>
> object {droid_}

some more information (fwiw).  same error in alpha.9945627.  without the 'once'
keyword the scene renders (but not useful since the decal repeats).


regards, jr.

[jr] alpha.10064268 freezes [2318 days 14 hours and 3 minutes ago]

Mon, 2 Dec 2019 17:20:00 GMT

hi,

using alpha.10064268, dies with:

  Fatal error in renderer: Frontend halted render.

I'm trying to add a logo/decal to an Android model (version 4, POVCollection
#590224).

the code is taken from 'androidrobot_posed.pov', with minor modification, and
the error occurs when the pigment is uncommented.

when I reverse the order of the pigments, POV-Ray runs ok, but, of course, that
is no help.


regards, jr.


-----<snip>-----
#declare droid_ = union {
  object {

AndroidRobot_Posed(no,HeadRotate,LArmRotate,RArmRotate,LLegRotate,RLegRotate)
    pigment {ANDROIDROBOT_C_COLOR}
//    pigment {image_map {png "plate.png" once} scale .2}
    finish {
      reflection {.5 metallic}
      diffuse DIFFUSE * .5
      ambient C_AMBIENCE * .5
      specular 1.788 metallic
      roughness .05
      brilliance 1.857
    }
  }
  union {
    object {UserDefinedEye}
    object {UserDefinedEye scale <1,1,-1>}
    AndroidRobot_Head_x (HeadRotate)
  }
  rotate 90 * y
  translate -ANDROIDROBOT_V_BASE
};

object {droid_}

[jr] Re: local in macro [2322 days 12 hours and 8 minutes ago]

Thu, 28 Nov 2019 19:15:01 GMT

hi,

"Bald Eagle" <cre### [at] netscapenet> wrote:
> > ...
> Not sure exactly what you're trying to do here, but try this and see if this
> helps explain anything.   I think Kenneth had some issues with this sort of
> thing too a while back.
> ...

my work-around for the issue will be (from now) to treat macro parameters as
read only.  confused by the documentation, I guess.  reading through the
language directives stuff (local vs declare, macros) I expect the local variable
('n_') to genuinely be local since the reassignment is a '#local' construct, but
it seems that it remains linked "by reference" regardless.  anyway, thanks for
the thought.

regards, jr.

[Bald Eagle] Re: local in macro [2322 days 15 hours and 58 minutes ago]

Thu, 28 Nov 2019 15:25:01 GMT

> #version 3.8;
>
> global_settings {assumed_gamma 1}
>
> #macro Decr(n_)
>   #if (1 <= n_)
>     #local n_ = n_ - 1;
>   #end
>   #debug concat("local n_ = ",str(n_,0,0),"\n")
> #end
>
>
> #if (1)
> #for (i_,0,3)
>   Decr(i_)
>   #debug concat("loop i_ = ",str(i_,0,0),"\n")
> #end
> #end
>
>
> #if (0)
> #declare i_ = 0;
> #while (4 > i_)
>   Decr(i_)
>   #debug concat("loop i_ = ",str(i_,0,0),"\n")
>   #declare i_ = i_ + 1;
> #end
> #end

Not sure exactly what you're trying to do here, but try this and see if this
helps explain anything.   I think Kenneth had some issues with this sort of
thing too a while back.

#version 3.8;

global_settings {assumed_gamma 1}

#declare Bailout = 0;
#declare Bailoutmax = 10;

#macro Decr (n_)
 #debug concat("starting macro with n_ = ",str(n_,0,0),"\n")
 #if (n_ >= 1)
  #local n_ = n_ - 1;
 #end


 #if (Bailout = Bailoutmax)
  #error "Stopping code - Bailout has reached max"
 #end

 #debug concat("     exiting macro with n_ = ",str(n_,0,0),"\n")
 n_

#end


#if (1)
 #declare Counter = 10;
 #for (i_, 0, 3)
  #declare Counter = Decr (Counter);
  #declare Bailout = Bailout + 1;

 #end
#end


#if (0)
 #declare i_ = 0;
 #while (i_ < 4)
  #declare i_ = Decr (i_);
  #debug concat("while loop i_ = ",str(i_,0,0),"\n")
  #declare Bailout = Bailout + 1;
  #declare i_ = i_ + 1;
 #end
#end

#error "stop render"

[jr] local in macro [2322 days 18 hours and 58 minutes ago]

Thu, 28 Nov 2019 12:25:01 GMT

hi,

upgraded from alpha.9945627 because I ran into a problem, to alpha.10064268, but
no change.

reading section 3.3.2.2.2 "declare vs local", it says if "#local is used inside
a #macro then the identifier is local to that macro.  When the macro is invoked
and the #local directive is parsed, the identifier is created."

maybe I misread this, but the macro parameter appears to just work as an
input/output.  the following test scene .. misbehaves on both versions:

-----<snip>-----
#version 3.8;

global_settings {assumed_gamma 1}

#macro Decr(n_)
  #if (1 <= n_)
    #local n_ = n_ - 1;
  #end
  #debug concat("local n_ = ",str(n_,0,0),"\n")
#end


#if (1)
#for (i_,0,3)
  Decr(i_)
  #debug concat("loop i_ = ",str(i_,0,0),"\n")
#end
#end


#if (0)
#declare i_ = 0;
#while (4 > i_)
  Decr(i_)
  #debug concat("loop i_ = ",str(i_,0,0),"\n")
  #declare i_ = i_ + 1;
#end
#end
-----<snip>-----


regards, jr.

[jr] Re: sphere slicing problem [2342 days 5 hours and 33 minutes ago]

Sat, 9 Nov 2019 01:50:01 GMT

"jr" <cre### [at] gmailcom> wrote:
> "jr" <cre### [at] gmailcom> wrote:
> > William F Pokorny <ano### [at] anonymousorg> wrote:
> > > ...
> > > What I had in mind was to create two pigments ...
>
> ok, a first basic test confirms the approach works.  ...

that test was done with two images, names hardwired.  while listening to BBC
Radio 6 Music celebrating an 'Chemical Brothers' album, I managed to get ..
stuff done.  :-)  cannot be bothered to render a full rotation of the resulting
DF3s, so have posted a VMRL version[*].  next (in the coming days) I'll see how
it goes with a couple of complex shapes.  happy days..

[*] in p.b.misc again.

regards, jr.

[jr] Re: sphere slicing problem [2344 days 14 hours and 18 minutes ago]

Wed, 6 Nov 2019 17:05:01 GMT

"jr" <cre### [at] gmailcom> wrote:
> William F Pokorny <ano### [at] anonymousorg> wrote:
> > ...
> > What I had in mind was to create two pigments which are planar image
> > maps of say sliceDown00.png and sliceUp00.png, respectively. Call these
> > PigDown and PigUp. (You might need to rotate/scale to align with the
> > final orthographic camera - max_extent() can grab the input image x,y
> > size)
> >
> > Wrap these two pigments in functions (only way they'll get used):
> >
> > #declare FnDown = function { pigment { PigDown } }
> > #declare FnUp = function { pigment { PigUp } }

ok, a first basic test confirms the approach works.  thanks.  it seems that in
the combined pigment, the lines are less smooth than in the two source images.
need to explore this over the coming days.  did I say "thank you"?  :-)


regards, jr.

[jr] Re: sphere slicing problem [2346 days 11 hours and 33 minutes ago]

Mon, 4 Nov 2019 19:50:12 GMT

hi,

"Bald Eagle" <cre### [at] netscapenet> wrote:
> So, just thinking out loud about this a little more,
>
> If much of the issues arise from the angle between the camera and the surface,
> I'm wondering what sort of improvement there would be if the scene were done
> with an orthographic camera, but set off to the side by some angle.

won't work unfortunately.  either object is in view, or not.

> ...


regards, jr.

[jr] Re: sphere slicing problem [2346 days 11 hours and 33 minutes ago]

Mon, 4 Nov 2019 19:50:11 GMT

hi,

William F Pokorny <ano### [at] anonymousorg> wrote:
> On 11/3/19 1:31 PM, jr wrote:
> > yes, 'df3util' can import PNG, either as grayscale or _one_ of RGBA, so I don't
> > see/use colours at that stage.  :-(  still, I'd like to understand better the
> > way you outlined in the previous post, ie using a third cam to post-process the
> > two perspective cams slices (iiuc).
> ...
> What I had in mind was to create two pigments which are planar image
> maps of say sliceDown00.png and sliceUp00.png, respectively. Call these
> PigDown and PigUp. (You might need to rotate/scale to align with the
> final orthographic camera - max_extent() can grab the input image x,y
> size)
>
> Wrap these two pigments in functions (only way they'll get used):
>
> #declare FnDown = function { pigment { PigDown } }
> #declare FnUp = function { pigment { PigUp } }
>
> Use these in the use_defined the PigmentMaxUpDownPerspective I mentioned
> previously and use that texture with ambient 1 or emission 1 (diffuse 0
> use no lights) to texture a plane. Place this plane in front of an
> orthographic camera and render to get your real sample taking the max
> r,g,b values for each pixel from the down, up slices. This third render
> is your slice00 sample.

a fair amount of work + organising but (gut feeling) up + down combined ought to
catch 100% of the info.  (perhaps even at slightly less insane quality settings
than used now. :-))  I need to work out real detail[*] but think two template
scenes and three ini files should cover it.

[*] pen + paper.  :-)

> Here we are using POV-Ray as an image processing
> tool. Something at which it's very good - if not as fast as dedicated
> image processing tools.

lack of speed is a drawback during development, but hey..

> FYI. There might be typos in my SDL, I didn't set up a small scene as I
> often do.

I'm glad you're giving such detailed advice + feedback, and will probably need
more in a few days time.  :-)  thanks.


regards ,jr.

[Bald Eagle] Re: sphere slicing problem [2346 days 12 hours and 8 minutes ago]

Mon, 4 Nov 2019 19:15:00 GMT

So, just thinking out loud about this a little more,

If much of the issues arise from the angle between the camera and the surface,
I'm wondering what sort of improvement there would be if the scene were done
with an orthographic camera, but set off to the side by some angle.

Then you'd get an oblique view of the slice, and the ray-object intersection
that the solver would have to deal with wouldn't hit the same issues.

Then you take that render and scale it to stretch it back out and faux-undo the
angled view.  Perhaps if it only required a few degrees offset, it might not
introduce significant distortion.

[William F Pokorny] Re: sphere slicing problem [2346 days 17 hours and 59 minutes ago]

Mon, 4 Nov 2019 13:23:31 GMT

On 11/3/19 1:31 PM, jr wrote:
> hi,
> 
> William F Pokorny <ano### [at] anonymousorg> wrote:
> 
> yes, 'df3util' can import PNG, either as grayscale or _one_ of RGBA, so I don't
> see/use colours at that stage.  :-(  still, I'd like to understand better the
> way you outlined in the previous post, ie using a third cam to post-process the
> two perspective cams slices (iiuc).
> 
...

What I had in mind was to create two pigments which are planar image 
maps of say sliceDown00.png and sliceUp00.png, respectively. Call these 
PigDown and PigUp. (You might need to rotate/scale to align with the 
final orthographic camera - max_extent() can grab the input image x,y 
size)

Wrap these two pigments in functions (only way they'll get used):

#declare FnDown = function { pigment { PigDown } }
#declare FnUp = function { pigment { PigUp } }

Use these in the use_defined the PigmentMaxUpDownPerspective I mentioned 
previously and use that texture with ambient 1 or emission 1 (diffuse 0 
use no lights) to texture a plane. Place this plane in front of an 
orthographic camera and render to get your real sample taking the max 
r,g,b values for each pixel from the down, up slices. This third render 
is your slice00 sample. Here we are using POV-Ray as an image processing 
tool. Something at which it's very good - if not as fast as dedicated 
image processing tools.

FYI. There might be typos in my SDL, I didn't set up a small scene as I 
often do.

Bill P.

[jr] Re: sphere slicing problem [2347 days 12 hours and 48 minutes ago]

Sun, 3 Nov 2019 18:35:01 GMT

hi,

William F Pokorny <ano### [at] anonymousorg> wrote:
> On 11/3/19 8:56 AM, jr wrote:
> > William F Pokorny <ano### [at] anonymousorg> wrote:
> ...
> > open to ideas.  more function voodoo, I bet.  :-)
>
> :-) Ah sorry, I aimed my response toward doing as much in POV-Ray as
> possible given you seemed averse to intersecting the shapes with solid
> pigments and using a stand-alone edge detection program.

yes, SDL as much as possible/feasible.  not so much "averse" as .. ignorant of,
ie I have not had cause to use such s/wares before.  if you know of a suitable
utility which will process a set of images like the ones I'm likely to
encounter, please recommend.

> To just try the -render perspective camera above, below and combine
> idea- do one set of frames with the camera above and stick those frames
> in a directory aboveFramesDir and similarly a camera below scan.
>
> You're already using your own image->df3 program. Read in both above
> frame and below frame images and take the max r,g,b found before you
> write the df3 sample position. If the method works, refinements in
> position etc, can wait until you find you need them. Might be the basic
> idea doesn't work for some reason I don't see(1)...

yes, 'df3util' can import PNG, either as grayscale or _one_ of RGBA, so I don't
see/use colours at that stage.  :-(  still, I'd like to understand better the
way you outlined in the previous post, ie using a third cam to post-process the
two perspective cams slices (iiuc).

> (1) - There are issues where any scan approach will run into
> complications beyond those being considered presently. Interior textures
> different than outside textures for objects scanned, for example.

another can of worms.  </sigh>  ;-)

regards, jr.

[William F Pokorny] Re: sphere slicing problem [2347 days 14 hours and 37 minutes ago]

Sun, 3 Nov 2019 16:45:56 GMT

On 11/3/19 8:56 AM, jr wrote:
> hi,
> 
> William F Pokorny <ano### [at] anonymousorg> wrote:
...
> 
> open to ideas.  more function voodoo, I bet.  :-)
> 

:-) Ah sorry, I aimed my response toward doing as much in POV-Ray as 
possible given you seemed averse to intersecting the shapes with solid 
pigments and using a stand-alone edge detection program.

To just try the -render perspective camera above, below and combine 
idea- do one set of frames with the camera above and stick those frames 
in a directory aboveFramesDir and similarly a camera below scan.

You're already using your own image->df3 program. Read in both above 
frame and below frame images and take the max r,g,b found before you 
write the df3 sample position. If the method works, refinements in 
position etc, can wait until you find you need them. Might be the basic 
idea doesn't work for some reason I don't see(1)...

Bill P.

(1) - There are issues where any scan approach will run into 
complications beyond those being considered presently. Interior textures 
different than outside textures for objects scanned, for example.

[jr] Re: sphere slicing problem [2347 days 17 hours and 23 minutes ago]

Sun, 3 Nov 2019 14:00:01 GMT

hi,

William F Pokorny <ano### [at] anonymousorg> wrote:
> On 11/1/19 1:39 PM, William F Pokorny wrote:
> > On 11/1/19 10:16 AM, jr wrote:
> ...
> >>
> >> I now think that if, perhaps, there is a relatively simple and
> >> accurate way of
> >> calculating camera parameters for both camera types such that the
> >> object is seen
> >> in exactly the same size/position, perhaps one could merge the
> >> results.Â  any
> >> thought(s) welcome.
> >
> > Maybe...
> ...
>
> Woke up this morning with a thought.

:-)

> If you're willing to render each
> sample as three frames your idea might fly using two perspective cameras.
> While in general using whatever you are using set up wise for best
> results:
> Using a perspective camera down in the first frame of a sample; A
> perspective camera up in the second frame of a sample; In the last frame
> use the results of the of the first two sample frames for planar
> pigments which themselves would be used in a user defined pigment
> applied to a plane with no lights but an ambient 1 finish and an
> orthographic camera.
> In frame 3/3 of each sample in the scan the user defined pigment would
> be something like:
> #declare PigmentMaxUpDownPerspective = pigment {
>      user_defined {
>          function { max(FnUp(x,y,z).r,FnDown(x,y,z).r) },
>          function { max(FnUp(x,y,z).g,FnDown(x,y,z).g) },
>          function { max(FnUp(x,y,z).b,FnDown(x,y,z).b) },
>          ,
>      }
> }

while I can see/appreciate the concept, I'll need to think about how to approach
this.  I have never used more than one camera at a time, for instance.  and then
there's the .. function voodoo.  :-)  FnUp/FnDown are what?  the contents of the
slice wrapped somehow in a function?

> There is planar-position distortion due the perspective camera. You
> would want to keep the angle small(1) to limit this.

the opposite to what I've been doing so far.  I use(d) the angle and location to
fine tune the shape to fill the frame.

> Further for each
> sample the up / down cameras should be equal distance to the middle of
> each sample's slice. In other words, the camera positions should be
> based upon the middle of each sample slice.

another thing different.  until now I have used the lowest point, but will
incorporate this as a first change.

> Aside: A user defined perspective camera simultaneously up and down an
> option too - say alternating rows at twice the vertical height - could
> be rendered in one frame. You'd have to be willing to scale down
> vertically only with some post render program/process.

open to ideas.  more function voodoo, I bet.  :-)

> Bill P.
> (1) - Small perspective camera angles will tend to work against you in
> being more parallel - more like the orthographic - some balancing
> required. Small perspective camera angles also require the camera be
> further away. So, I'll also mention there are accuracy issues especially
> with higher order polynomial shapes when the camera rays start far away.
> The accuracy issue is improved if you use my updated solver branch, but
> still significantly present. The sphere is essentially order 2, so with
> it your OK accuracy wise even at large distances away for the camera.

while I've never compiled a patched version of POV-Ray, I'm willing to give it a
try (with a little hand-holding).


regards, jr.

[William F Pokorny] Re: sphere slicing problem [2348 days 23 hours and 45 minutes ago]

Sat, 2 Nov 2019 07:38:10 GMT

On 11/1/19 1:39 PM, William F Pokorny wrote:
> On 11/1/19 10:16 AM, jr wrote:
...
>>
>> I now think that if, perhaps, there is a relatively simple and 
>> accurate way of
>> calculating camera parameters for both camera types such that the 
>> object is seen
>> in exactly the same size/position, perhaps one could merge the 
>> results.Â  any
>> thought(s) welcome.
>>
> 
> Maybe... 
...

Woke up this morning with a thought. If you're willing to render each 
sample as three frames your idea might fly using two perspective cameras.

While in general using whatever you are using set up wise for best 
results:

Using a perspective camera down in the first frame of a sample; A 
perspective camera up in the second frame of a sample; In the last frame 
use the results of the of the first two sample frames for planar 
pigments which themselves would be used in a user defined pigment 
applied to a plane with no lights but an ambient 1 finish and an 
orthographic camera.

In frame 3/3 of each sample in the scan the user defined pigment would 
be something like:

#declare PigmentMaxUpDownPerspective = pigment {
     user_defined {
         function { max(FnUp(x,y,z).r,FnDown(x,y,z).r) },
         function { max(FnUp(x,y,z).g,FnDown(x,y,z).g) },
         function { max(FnUp(x,y,z).b,FnDown(x,y,z).b) },
         ,
     }
}

There is planar-position distortion due the perspective camera. You 
would want to keep the angle small(1) to limit this. Further for each 
sample the up / down cameras should be equal distance to the middle of 
each sample's slice. In other words, the camera positions should be 
based upon the middle of each sample slice.

Aside: A user defined perspective camera simultaneously up and down an 
option too - say alternating rows at twice the vertical height - could 
be rendered in one frame. You'd have to be willing to scale down 
vertically only with some post render program/process.

Bill P.

(1) - Small perspective camera angles will tend to work against you in 
being more parallel - more like the orthographic - some balancing 
required. Small perspective camera angles also require the camera be 
further away. So, I'll also mention there are accuracy issues especially
with higher order polynomial shapes when the camera rays start far away.
The accuracy issue is improved if you use my updated solver branch, but 
still significantly present. The sphere is essentially order 2, so with 
it your OK accuracy wise even at large distances away for the camera.

[William F Pokorny] Re: sphere slicing problem [2349 days 13 hours and 44 minutes ago]

Fri, 1 Nov 2019 17:39:14 GMT

On 11/1/19 10:16 AM, jr wrote:
> hi,
> 
> William F Pokorny <ano### [at] anonymousorg> wrote:
>> ... This means for
>> you, you'll have both coincident (sometimes wrongly ordered)
>> intersections and ones less and less likely to align with the
>> orthographic camera rays as the sampled surface becomes parallel to the
>> ray. Such rays, if they hit, would be near tangents to the surface - the
>> shortest of these tends to get filtered in many objects too for a few
>> reasons.
> 
> the image posted in p.b.misc shows a lo-res Y-axis scan, orthographic camera on
> the left, perspective on the right.  and the 'surface becomes parallel' thing is
> clearly where expected on the left.  I cannot fathom though why for the
> perspective camera the problem manifests above "the bulge" instead of the
> centre; cameras in both stationed directly above the sphere.

It's the same, sampled-surface being mostly parallel to the rays, issue. 
The results are about what I'd expect. With the perspective camera the 
rays are not parallel to the y axis, but some rays are still essentially 
running parallel/tangent to the parts of the sphere causing that upper 
bulge.

> 
> I now think that if, perhaps, there is a relatively simple and accurate way of
> calculating camera parameters for both camera types such that the object is seen
> in exactly the same size/position, perhaps one could merge the results.  any
> thought(s) welcome.
> 

Maybe... I had the thought while traveling it might be possible to get 
further for your simple sphere with my hard_object patch by creating a 
thin skin to the sphere - an aim for that pattern was to create the 
peeling paint isosurface skins more or less automatically(1).

(1) - The issue immediately hit was performance. The inside test is 
really slow for some objects and for all shapes it slows dramatically as 
the complexity of the input objects gets complex. With large CSGs for 
example, it looks to be just trundling through all the shapes. 
Performance aside, while the hard_object pattern handles convex shapes 
really well, it struggles with a shape's concave parts. It can get noisy 
/ fill in crevices.

> I also find the patterns appearing in many of the sliced rings interesting, the
> regularity of the spacing etc holds information -- I just can't .. parse it. :-(
>   if anyone's interested I can post the frame/slice images.
...

Perhaps reasons, but doubt the usefulness for anything found.

Bill P.

[jr] Re: sphere slicing problem [2349 days 17 hours and 3 minutes ago]

Fri, 1 Nov 2019 14:20:01 GMT

hi,

William F Pokorny <ano### [at] anonymousorg> wrote:
> ... This means for
> you, you'll have both coincident (sometimes wrongly ordered)
> intersections and ones less and less likely to align with the
> orthographic camera rays as the sampled surface becomes parallel to the
> ray. Such rays, if they hit, would be near tangents to the surface - the
> shortest of these tends to get filtered in many objects too for a few
> reasons.

the image posted in p.b.misc shows a lo-res Y-axis scan, orthographic camera on
the left, perspective on the right.  and the 'surface becomes parallel' thing is
clearly where expected on the left.  I cannot fathom though why for the
perspective camera the problem manifests above "the bulge" instead of the
centre; cameras in both stationed directly above the sphere.

I now think that if, perhaps, there is a relatively simple and accurate way of
calculating camera parameters for both camera types such that the object is seen
in exactly the same size/position, perhaps one could merge the results.  any
thought(s) welcome.

I also find the patterns appearing in many of the sliced rings interesting, the
regularity of the spacing etc holds information -- I just can't .. parse it. :-(
 if anyone's interested I can post the frame/slice images.

regards, jr.

[Thorsten Froehlich] Re: POV-Ray 3.7 from MacPorts crashing [2361 days 11 hours and 33 minutes ago]

Sun, 20 Oct 2019 19:50:06 GMT

"Dan Byers" <goofygraffix_at_geemail_dot_com> wrote:
> Thanks for the replies, everyone.  Found the issue, and the crash report had the
> answer (who knew, right?  HA!).  I was rendering with Display=on, which produced
> all this lovely jibber-jabber:
> ************************************************************************************
> 2019-10-16 19:14:34.479 povray[38836:474601] *** Terminating app due to uncaught
> exception 'NSInternalInconsistencyException', reason: 'NSWindow drag regions
> should only be invalidated on the Main Thread!'
> *** First throw call stack:
> (
>  0   CoreFoundation                      0x00007fff301fbd63
> __exceptionPreprocess + 250
>  1   libobjc.A.dylib                     0x00007fff660eabd4 objc_exception_throw
> + 48
>  2   CoreFoundation                      0x00007fff3021630c -[NSException raise]
> + 9
>  3   AppKit                              0x00007fff2d3e07b3
> -[NSWindow(NSWindow_Theme)
> _postWindowNeedsToResetDragMarginsUnlessPostingDisabled] + 310
>  4   AppKit                              0x00007fff2d3ddce1 -[NSWindow
> _initContent:styleMask:backing:defer:contentView:] + 1416
>  5   AppKit                              0x00007fff2d3dd753 -[NSWindow
> initWithContentRect:styleMask:backing:defer:] + 42
>  6   libSDL-1.2.0.dylib                  0x0000000107b37649 -[SDL_QuartzWindow
> initWithContentRect:styleMask:backing:defer:] + 262
>  7   libSDL-1.2.0.dylib                  0x0000000107b353cc QZ_SetVideoMode +
> 1289
>  8   libSDL-1.2.0.dylib                  0x0000000107b2d091 SDL_SetVideoMode +
> 581
>  9   povray                              0x0000000107828694
> _ZN12pov_frontend14UnixSDLDisplay4ShowEv + 598
>  10  povray                              0x000000010783cddd
> _ZN3vfe15VirtualFrontEnd7ProcessEv + 1833
>  11  povray                              0x0000000107830a87
> _ZN3vfe10vfeSession15ProcessFrontendEv + 27
>  12  povray                              0x0000000107830dd4
> _ZN3vfe10vfeSession12WorkerThreadEv + 546
>  13  libboost_thread-mt.dylib            0x0000000108104c47
> _ZN5boost12_GLOBAL__N_112thread_proxyEPv + 119
>  14  libsystem_pthread.dylib             0x00007fff67655d76 _pthread_start + 125
>  15  libsystem_pthread.dylib             0x00007fff676525d7 thread_start + 15
> )
> libc++abi.dylib: terminating with uncaught exception of type NSException
> /Users/danb/Documents/Movies/EC009/src/RenderStill.sh: line 3: 38836 Abort trap:
> 6           povray mac_still
>
> ***************************************************************
> Switched Display=off, and it renders just fine.
>
> I code for a living, so you'd think I'd read the damn crash report a little more
> thoroughly BEFORE I go running & screaming to the hills... smdh... screw it,
> it's Friday and I'm gonna go hang out with the better half & watch some stupid
> TV...
>
> Thanks again, everyone :D
>
> Dan

[Thorsten Froehlich] Re: POV-Ray 3.7 from MacPorts crashing [2361 days 11 hours and 38 minutes ago]

Sun, 20 Oct 2019 19:45:01 GMT

"Dan Byers" <goofygraffix_at_geemail_dot_com> wrote:
> Thanks for the replies, everyone.  Found the issue, and the crash report had the
> answer (who knew, right?  HA!).  I was rendering with Display=on, which produced
> all this lovely jibber-jabber:
> ************************************************************************************
> 2019-10-16 19:14:34.479 povray[38836:474601] *** Terminating app due to uncaught
> exception 'NSInternalInconsistencyException', reason: 'NSWindow drag regions
> should only be invalidated on the Main Thread!'
> *** First throw call stack:
> (
>  0   CoreFoundation                      0x00007fff301fbd63
> __exceptionPreprocess + 250
>  1   libobjc.A.dylib                     0x00007fff660eabd4 objc_exception_throw
> + 48
>  2   CoreFoundation                      0x00007fff3021630c -[NSException raise]
> + 9
>  3   AppKit                              0x00007fff2d3e07b3
> -[NSWindow(NSWindow_Theme)
> _postWindowNeedsToResetDragMarginsUnlessPostingDisabled] + 310
>  4   AppKit                              0x00007fff2d3ddce1 -[NSWindow
> _initContent:styleMask:backing:defer:contentView:] + 1416
>  5   AppKit                              0x00007fff2d3dd753 -[NSWindow
> initWithContentRect:styleMask:backing:defer:] + 42
>  6   libSDL-1.2.0.dylib                  0x0000000107b37649 -[SDL_QuartzWindow
> initWithContentRect:styleMask:backing:defer:] + 262
>  7   libSDL-1.2.0.dylib                  0x0000000107b353cc QZ_SetVideoMode +
> 1289
>  8   libSDL-1.2.0.dylib                  0x0000000107b2d091 SDL_SetVideoMode +
> 581
>  9   povray                              0x0000000107828694
> _ZN12pov_frontend14UnixSDLDisplay4ShowEv + 598
>  10  povray                              0x000000010783cddd
> _ZN3vfe15VirtualFrontEnd7ProcessEv + 1833
>  11  povray                              0x0000000107830a87
> _ZN3vfe10vfeSession15ProcessFrontendEv + 27
>  12  povray                              0x0000000107830dd4
> _ZN3vfe10vfeSession12WorkerThreadEv + 546
>  13  libboost_thread-mt.dylib            0x0000000108104c47
> _ZN5boost12_GLOBAL__N_112thread_proxyEPv + 119
>  14  libsystem_pthread.dylib             0x00007fff67655d76 _pthread_start + 125
>  15  libsystem_pthread.dylib             0x00007fff676525d7 thread_start + 15
> )
> libc++abi.dylib: terminating with uncaught exception of type NSException
> /Users/danb/Documents/Movies/EC009/src/RenderStill.sh: line 3: 38836 Abort trap:
> 6           povray mac_still
>
> ***************************************************************
> Switched Display=off, and it renders just fine.
>
> I code for a living, so you'd think I'd read the damn crash report a little more
> thoroughly BEFORE I go running & screaming to the hills... smdh... screw it,
> it's Friday and I'm gonna go hang out with the better half & watch some stupid
> TV...
>
> Thanks again, everyone :D

It crashes in libsdl, so obviously the port of libsdl isn’t working. This
isn’t
a POV-Ray problem.

[Dan Byers] Re: POV-Ray 3.7 from MacPorts crashing [2363 days 6 hours and 43 minutes ago]

Sat, 19 Oct 2019 00:40:01 GMT

Thanks for the replies, everyone.  Found the issue, and the crash report had the
answer (who knew, right?  HA!).  I was rendering with Display=on, which produced
all this lovely jibber-jabber:
************************************************************************************
2019-10-16 19:14:34.479 povray[38836:474601] *** Terminating app due to uncaught
exception 'NSInternalInconsistencyException', reason: 'NSWindow drag regions
should only be invalidated on the Main Thread!'
*** First throw call stack:
(
 0   CoreFoundation                      0x00007fff301fbd63
__exceptionPreprocess + 250
 1   libobjc.A.dylib                     0x00007fff660eabd4 objc_exception_throw
+ 48
 2   CoreFoundation                      0x00007fff3021630c -[NSException raise]
+ 9
 3   AppKit                              0x00007fff2d3e07b3
-[NSWindow(NSWindow_Theme)
_postWindowNeedsToResetDragMarginsUnlessPostingDisabled] + 310
 4   AppKit                              0x00007fff2d3ddce1 -[NSWindow
_initContent:styleMask:backing:defer:contentView:] + 1416
 5   AppKit                              0x00007fff2d3dd753 -[NSWindow
initWithContentRect:styleMask:backing:defer:] + 42
 6   libSDL-1.2.0.dylib                  0x0000000107b37649 -[SDL_QuartzWindow
initWithContentRect:styleMask:backing:defer:] + 262
 7   libSDL-1.2.0.dylib                  0x0000000107b353cc QZ_SetVideoMode +
1289
 8   libSDL-1.2.0.dylib                  0x0000000107b2d091 SDL_SetVideoMode +
581
 9   povray                              0x0000000107828694
_ZN12pov_frontend14UnixSDLDisplay4ShowEv + 598
 10  povray                              0x000000010783cddd
_ZN3vfe15VirtualFrontEnd7ProcessEv + 1833
 11  povray                              0x0000000107830a87
_ZN3vfe10vfeSession15ProcessFrontendEv + 27
 12  povray                              0x0000000107830dd4
_ZN3vfe10vfeSession12WorkerThreadEv + 546
 13  libboost_thread-mt.dylib            0x0000000108104c47
_ZN5boost12_GLOBAL__N_112thread_proxyEPv + 119
 14  libsystem_pthread.dylib             0x00007fff67655d76 _pthread_start + 125
 15  libsystem_pthread.dylib             0x00007fff676525d7 thread_start + 15
)
libc++abi.dylib: terminating with uncaught exception of type NSException
/Users/danb/Documents/Movies/EC009/src/RenderStill.sh: line 3: 38836 Abort trap:
6           povray mac_still

***************************************************************
Switched Display=off, and it renders just fine.

I code for a living, so you'd think I'd read the damn crash report a little more
thoroughly BEFORE I go running & screaming to the hills... smdh... screw it,
it's Friday and I'm gonna go hang out with the better half & watch some stupid
TV...

Thanks again, everyone :D

Dan

[jr] Re: sphere slicing problem [2363 days 8 hours and 53 minutes ago]

Fri, 18 Oct 2019 22:30:01 GMT

hi,

"Bald Eagle" <cre### [at] netscapenet> wrote:
> "jr" <cre### [at] gmailcom> wrote:
> adding it seems to make no discernable difference to what I now get.
>
> I don't think he was suggesting it would - he was just commenting on my "ex post
> facto" differencing comment.  That's a whole different story.

</blush>  misread.  apologies.

> > however, _the_ problem is the "pathological" case of parallel-to-camera, as Bill
> > P identified when he asked "what happens with a box".  I'm currently wondering
> > whether using a perspective camera for "difficult" shapes mightn't be better.
> > and for shapes like spheres + tori I may get milage our of lowering the vertical
> > resolution (ie thicker slices).
>
> This almost makes me wonder if you can do some sort of weird wide-angle /
> panoramic render and then re-map it with --- for lack of a better understanding
> and proper vocabulary - an anamorphic camera

I can see what you mean but that's way beyond my .. pay grade.

ideally there'd be a simple way of, say, using a (slightly) offset perspective
camera, and relating that angle to some compensating factor to approximate the
orthographic equivalent (a bit like an effect using a matrix to slant/skew an
object, then reversing that).

> > the Lohmueller tip is confusing.  haven't tried yet but the documentation is
> > quite clear that the direction vector is not used with prthographic cameras.
> > have you come across working code which utilises the "trick"?
> I believe you can just make a simple animation of a camera getting closer and
> closer to a shape with a gradient pigment along the object-camera axis.  Maybe
> slightly off-axis, so that you can see the effect better.
> The camera will start to exclude all of the parts of the object "behind" it, and
> you'll effectively get a slicing effect.
> I've done this plenty of times by accident when setting up scenes with the
> orthographic camera.

:-)  yes, I too have found myself .. inside, unexpectedly.  anyway, the
"remainder" would still need to be cut/sliced, so it looks like using a box to
intersect seems unavoidable.


regards, jr.

[Bald Eagle] Re: sphere slicing problem [2363 days 10 hours and 53 minutes ago]

Fri, 18 Oct 2019 20:30:01 GMT

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

adding it seems to make no discernable difference to what I now get.

I don't think he was suggesting it would - he was just commenting on my "ex post
facto" differencing comment.  That's a whole different story.

> however, _the_ problem is the "pathological" case of parallel-to-camera, as Bill
> P identified when he asked "what happens with a box".  I'm currently wondering
> whether using a perspective camera for "difficult" shapes mightn't be better.
> and for shapes like spheres + tori I may get milage our of lowering the vertical
> resolution (ie thicker slices).

This almost makes me wonder if you can do some sort of weird wide-angle /
panoramic render and then re-map it with --- for lack of a better understanding
and proper vocabulary - an anamorphic camera

> the Lohmueller tip is confusing.  haven't tried yet but the documentation is
> quite clear that the direction vector is not used with prthographic cameras.
> have you come across working code which utilises the "trick"?

I believe you can just make a simple animation of a camera getting closer and
closer to a shape with a gradient pigment along the object-camera axis.  Maybe
slightly off-axis, so that you can see the effect better.

The camera will start to exclude all of the parts of the object "behind" it, and
you'll effectively get a slicing effect.
I've done this plenty of times by accident when setting up scenes with the
orthographic camera.

[jr] Re: sphere slicing problem [2363 days 11 hours and 23 minutes ago]

Fri, 18 Oct 2019 20:00:01 GMT

hi,

Le_Forgeron <jgr### [at] freefr> wrote:
> Le 14/10/2019 Ã  19:20, Bald Eagle a Ã©critÂ :
> > "jr" <cre### [at] gmailcom> wrote:
> >> does not for me.  :-(  I get solid (filled) circles, not rings.
> > Ah.
> >> that may not always be an option.  the idea is to slice arbitrary objects
> >> (suitably scaled + positioned).  the object may not always be my own work
> >> though.
> > Sounds like that ex-post facto texturing lots of people would like...
>
> what about then, using cutaway_texture ?

hey, thanks.  like Bald Eagle, I had not seen this "object modifier" before.
alas, adding it seems to make no discernable difference to what I now get.  in
accordance withe the reference, I changed the "slice" to:
box {p1, p2 hollow no_reflection no_shadow
  texture {pigment {srgbt 1}}
  interior_texture {pigment {srgbt 1}}
}

and use it in:
intersection {
  object {O}
  object {S}
  cutaway_texture
  double_illuminate
}

with "tight" antialias settings in the .ini this gives reasonably good results.

however, _the_ problem is the "pathological" case of parallel-to-camera, as Bill
P identified when he asked "what happens with a box".  I'm currently wondering
whether using a perspective camera for "difficult" shapes mightn't be better.
and for shapes like spheres + tori I may get milage our of lowering the vertical
resolution (ie thicker slices).

> I have a feeling it was made for these people.

and in reply to Bald Eagle:

the Lohmueller tip is confusing.  haven't tried yet but the documentation is
quite clear that the direction vector is not used with prthographic cameras.
have you come across working code which utilises the "trick"?

regards, jr.

[Bald Eagle] Re: sphere slicing problem [2363 days 14 hours and 3 minutes ago]

Fri, 18 Oct 2019 17:20:00 GMT

Le_Forgeron <jgr### [at] freefr> wrote:

> what about then, using cutaway_texture ?
>
> http://wiki.povray.org/content/Reference:Cutaway_Textures
>
> I have a feeling it was made for these people.

Aha.  That looks very nice indeed.   I'm not sure if I ever knew about that one,
or it just got lost in the noise.   Thanks very much for pointing that one out -
another nice feature that could probably use an example scene just to show it
off and make it more memorable.

Thanks, Jerome!   :)

[Le Forgeron] Re: sphere slicing problem [2363 days 14 hours and 58 minutes ago]

Fri, 18 Oct 2019 16:25:15 GMT

Le 14/10/2019 Ã  19:20, Bald Eagle a Ã©critÂ :
> 
> "jr" <cre### [at] gmailcom> wrote:
> 
>> does not for me.  :-(  I get solid (filled) circles, not rings.
> 
> Ah.
> 
>> that may not always be an option.  the idea is to slice arbitrary objects
>> (suitably scaled + positioned).  the object may not always be my own work
>> though.
> 
> Sounds like that ex-post facto texturing lots of people would like...

what about then, using cutaway_texture ?

http://wiki.povray.org/content/Reference:Cutaway_Textures

I have a feeling it was made for these people.

> 
> try using 2 "clipped_by" objects instead of an intersection?
> 
> I really never use that command - so maybe others have advice.
> 
>

[William F Pokorny] Re: POV-Ray 3.7 from MacPorts crashing [2363 days 18 hours and 50 minutes ago]

Fri, 18 Oct 2019 12:33:02 GMT

On 10/16/19 8:36 PM, Dan Byers wrote:
> Okay, here's the story.  I have an automated process for rendering that uses the
> command-line version of POV-Ray, compiled and distributed by MacPorts, for my
> iMac.  3.7 has always been a bit dodgy on my Mac -- the GUI version runs just
> fine, but starting with MacOS Mojave and continuing on to Catalina, the
> command-line version crashes, hard, to the point where it's effectively useless,
...

Any progress solving the problem?

Very odd the gui would be stable and the command line not, if running 
identical scenes with the same options.

What first popped into my head was perhaps your command line was issued 
from the mac-equivalent of an *nix xterm shell where your user limits 
had been set too low for some necessary resource. I check my settings on 
linux with 'ulimit -a'. After that maybe something different in your 
command shell environment such as an alias command setting in conflict 
with an argument or... If you've got non-ascii file names, that's 
another possibility - should the gui you use be scrubbing them up or 
something. There are open issues for the non-ascii file names.

Otherwise pointers Bald_Eagle offered good places to start.

If no progress with v3.7, worth giving a recent v3.8 a try. Fixes 
aplenty there.

Bill P.

[jr] Re: sphere slicing problem [2364 days 18 hours and 48 minutes ago]

Thu, 17 Oct 2019 12:35:01 GMT

"jr" <cre### [at] gmailcom> wrote:
> William F Pokorny <ano### [at] anonymousorg> wrote:
> > On 10/15/19 10:26 AM, jr wrote:
> > ...
> > I believe there are two issues in your approach. I think +am3 is able to
> > help with the coincident surfaces type, but not the 'things got so
> > small' they are sitting between our camera rays(a) type.
> >
> > (a) - Hmm, you might get some improvement too by moving to larger
> > renders for this reason. Ray spacing is relative to the scene is smaller
> > the larger the render.
>
> will give this a try too, later (Wednesdays usually busy with RL).
> the current render outputs 256x256, will check whether doubling makes a visual
> difference.
> > >> (1) - And perhaps help more with more aggressive options (more than +am3).

I added 'double_illumination' to both of objects in the intersection ("slice"),
as per BE's suggestion, and a transparent 'interior_texture' to the box, and
found that helped some.  I then doubled the resolution of the render (to
512x512), and tried "better" values for antialias_{confidence,depth,threshold},
again, small improvements.  I've posted an animation of it in p.b.misc, same
subject.  as can be seen, Bill P's advice re the near parallel (to camera) rays
was v accurate -- unfortunately.  I want to avoid going down the multi-pass
approach suggested, given that, in the end, the colour would still be
"generated" by eval_pigment.  so I'll use the rig as is now, and accept that
I'll have to drop resolution in some instances or avoid some shape(s)
altogether, and will have a look at the camera (cf BE Lohmueller tip) when I
find the .. energy.  meanwhile new ideas/insights would be appreciated.

regards, jr.

[Bald Eagle] Re: POV-Ray 3.7 from MacPorts crashing [2365 days 6 hours and 23 minutes ago]

Thu, 17 Oct 2019 01:00:01 GMT

This is Yvo Smellenbergh's sig info:

POV-Ray 3.7 unofficial: http://megapov.inetart.net/povrayunofficial_mac/
UberPOV Mac: http://megapov.inetart.net/uberpov_mac/index.html#Mac
MegaPOV: http://megapov.inetart.net
E-mail: yvo(DOT)s(AT)gmx.net

Maybe use
http://news.povray.org/povray.macintosh/

I'm sure it's heading-appropriate in either section...

[Dan Byers] POV-Ray 3.7 from MacPorts crashing [2365 days 6 hours and 43 minutes ago]

Thu, 17 Oct 2019 00:40:00 GMT

Okay, here's the story.  I have an automated process for rendering that uses the
command-line version of POV-Ray, compiled and distributed by MacPorts, for my
iMac.  3.7 has always been a bit dodgy on my Mac -- the GUI version runs just
fine, but starting with MacOS Mojave and continuing on to Catalina, the
command-line version crashes, hard, to the point where it's effectively useless,
and it doesn't matter if I use MacPort's version or one I compile myself from
the *nix source; the errors are the same.  Tried looking up a contact at
MacPorts to report this, but no maintainer is listed for the POV port, so I'm
turning to this forum and you kind people for whatever assistance you can
provide.  The last crash I was able to capture the error messages, which I would
think would be helpful (the crash report for Apple has gobs of data).

Anyway, any help would be appreciated.  If I posted this in the wrong forum,
please accept my apologizes and kindly direct me to the correct forum/venue.
Thank you.

Dan Byers

[jr] Re: sphere slicing problem [2365 days 21 hours and 53 minutes ago]

Wed, 16 Oct 2019 09:30:01 GMT

hi,

William F Pokorny <ano### [at] anonymousorg> wrote:
> On 10/15/19 10:26 AM, jr wrote:
> ...
> >
> >> This means for
> >> you, you'll have both coincident (sometimes wrongly ordered)
> >> intersections and ones less and less likely to align with the
> >> orthographic camera rays as the sampled surface becomes parallel to the
> >> ray. Such rays, if they hit, would be near tangents to the surface - the
> >> shortest of these tends to get filtered in many objects too for a few
> >> reasons.
> >
> > and that's the core problem I guess.  when the surface is seen along the "thin"
> > edge.  </sigh>
> >
> > could you please elaborate on "coincident (sometimes wrongly ordered)
> > intersections"?  with my (admittedly) limited understanding I would have thought
> > that a box/sphere intersection must be the same as a sphere/box.  in the macro
> > I'd "oversized" the slice (box) in the plane to avoid coincident surfaces
> > at/near the bounding box.
> >
>
> .........then the troll-of-inside_tests jumps from under the bridge... :-)
>
> I can elaborate some, but I don't understand it all. What exactly
> happens depends on much. Scene scale, what objects and so what
> intersection code, which solvers, the inside tests are often coded
> differently for performance relative to the intersection tests -and
> more.

ok, understood.

> When there are coincident or near coincident surfaces POV-Ray can get
> confused about the actual order (or existence) of intersections. I don't
> know gaming engines, but others have said the problem is similar to the
> z buffer problem in gaming. So. I was speaking of this fundamental
> internal issue when I said "sometimes wrongly ordered." Nothing to do
> with your intersection object order - which shouldn't matter to a 'first
> order.' Though, I'd not be too surprised if sometimes it did.

yes.  not knowing the innards of POV-Ray, object order _should_ not matter, but
there's always the occasional .. stab of doubt (particularly when things aren't
going well.  :-)).

> ...
> Where you want to see red, you have the second type - intersecting surfaces.

wondering whether[*] making the slice have an interior with explicit ior etc
might make a difference.

[*] will try later.

> ...
> I believe there are two issues in your approach. I think +am3 is able to
> help with the coincident surfaces type, but not the 'things got so
> small' they are sitting between our camera rays(a) type.
>
> (a) - Hmm, you might get some improvement too by moving to larger
> renders for this reason. Ray spacing is relative to the scene is smaller
> the larger the render.

will give this a try too, later (Wednesdays usually busy with RL).
the current render outputs 256x256, will check whether doubling makes a visual
difference.


> >> (1) - And perhaps help more with more aggressive options (more than +am3).
> >
> > ?? do you a mean smaller aa threshold?
>
> Maybe. I was though thinking more about AA depth (+r<n>) and IIRC +am3
> has a confidence setting of some kind. I've played with the new AA
> method 3, but not much. It can be very slow.

I've never used confidence, and usually stay away from the recursion limit.
still, much to think about, interplay of options etc, will tinker with those
too.  thanks.

> > yes, for my purposes, 'eval_pigment' doesn't do.  as I wrote in reply to BE, a
> > variant of 'trace' would be nice; perhaps reversing the normal and use it as a
> > camera ray to get the colour.  it would be useful, even given the provisos you
> > mention, because it would work on an in-situ object as is.
>
> Hmm. Another bit of code I've hardly used. I have it in my head
> eval_pigment is passed a pigment and it returns the raw pigment value at
> the x,y,z of the intersection. No normals no other factors, but maybe
> that's sort of your point? You want something which evaluates - maybe -
> overlapped textures on an object at a point?

sure.  the "problem" I have with eval_pigment is that it works irrespective of
lighting, which is unhelpful (imo).

you're right, evaluating a point on a (textured) surface is indeed what I'm
after; a feature/function sorely missing from POV-Ray, cf the feedback available
(for cameras etc) in 'hgpovray'.


> We do have the user defined functional camera in v38. If we can capture
> the normal and intersections, it should be these can be turned into
> object facing camera rays the reverse of raw surface normal.

I do not even understand the concept, I guess.  (when I first heard "mesh
camera" I'd naively thought it'd be like an insect's compound eye view.  :-))

> ...
> >> What are you really trying to do - and for what inputs and outputs?
> >
> > :-)  my current "motivation" is creating .. fodder for my shiny, new program.
> > it reads three DF3s (with the RGB components) and outputs a VRML PROTO with that
> > data as a 'PointSet'.
> >
> > inputs - arbitrary ("pretty" :-)) objects (or whole, small-ish scenes).
> >
>
> :-) I didn't completely follow what your trying with VRML. I don't know
> it. If you get something going, fire off a news post or two. I'll keep
> thinking about the edge detection, maybe something will pop into my head
> worth trying.

basically, "export" RGB DF3 data to a custom (VRML) node, making it available as
a 'PointSet' (node type).  the idea is to take some object made with POV-Ray,
scan it into DF3, export it, and view/peruse at leisure in some virtual world;
my pet project/ambition is to fashion a gallery with various .. exhibits.

I posted a grayscale version of 'spiral.df3' a month or so ago (cf BE) but
cannot find it now.  :-(  will in the coming days start a new off-topic thread
on the subject.

> Will mention some were creating cartoon images on the fly from scenes
> years ago. Prior work which might be worth looking over. I think most
> approached it with multiple renders, but...long time ago.

maybe one of the other "old timers" reads this _and_ can remember.  </grin>

> Aside: I play with df3s and have downloaded several of your utilities
> with the intent of giving them a whirl. Not gotten to it... :-(

:-)  (when (if!) you do, I really could do with some feedback.  (he said,
selfishly))


regards, jr.

[jr] Re: sphere slicing problem [2365 days 22 hours and 23 minutes ago]

Wed, 16 Oct 2019 09:00:01 GMT

hi,

"Bald Eagle" <cre### [at] netscapenet> wrote:
> ...
> With regard to the slicing problem:
> I'm wondering if you can use/abuse the orthographic camera itself to get what
> you want.
> I came across this when Ton posted a link to FL's site.
> see:
> http://www.f-lohmueller.de/pov_tut/scale_model/s_mod_150e.htm
>
> Maybe with some sort of no_shadow or double_illuminate keywords, you could get
> it to light the surface of that interior "slice".

nice.

had a very cursory look at the FL page, not sure I understood but using the
direction vector is .. interesting, and I'll give this a try.

already using no_shadow but will see if double_illuminate (on the slice) makes a
difference.

thank you very much + "bless yr little cotton socks".  :-)

regards, jr.

[Bald Eagle] Website error [2366 days 8 hours and 3 minutes ago]

Tue, 15 Oct 2019 23:20:01 GMT

Tried to use the search function, and I got:

Unauthorized access to internal API. Please refer to
https://support.google.com/customsearch/answer/4542055

twice.    :O
I reloaded and the third time it worked.   Weird.

[William F Pokorny] Re: sphere slicing problem [2366 days 9 hours and 29 minutes ago]

Tue, 15 Oct 2019 21:53:59 GMT

On 10/15/19 10:26 AM, jr wrote:
...
> 
>> This means for
>> you, you'll have both coincident (sometimes wrongly ordered)
>> intersections and ones less and less likely to align with the
>> orthographic camera rays as the sampled surface becomes parallel to the
>> ray. Such rays, if they hit, would be near tangents to the surface - the
>> shortest of these tends to get filtered in many objects too for a few
>> reasons.
> 
> and that's the core problem I guess.  when the surface is seen along the "thin"
> edge.  </sigh>
> 
> could you please elaborate on "coincident (sometimes wrongly ordered)
> intersections"?  with my (admittedly) limited understanding I would have thought
> that a box/sphere intersection must be the same as a sphere/box.  in the macro
> I'd "oversized" the slice (box) in the plane to avoid coincident surfaces
> at/near the bounding box.
> 

.........then the troll-of-inside_tests jumps from under the bridge... :-)

I can elaborate some, but I don't understand it all. What exactly 
happens depends on much. Scene scale, what objects and so what 
intersection code, which solvers, the inside tests are often coded 
differently for performance relative to the intersection tests -and 
more.

When there are coincident or near coincident surfaces POV-Ray can get 
confused about the actual order (or existence) of intersections. I don't 
know gaming engines, but others have said the problem is similar to the 
z buffer problem in gaming. So. I was speaking of this fundamental 
internal issue when I said "sometimes wrongly ordered." Nothing to do 
with your intersection object order - which shouldn't matter to a 'first 
order.' Though, I'd not be too surprised if sometimes it did.

---
Starting a little ahead of your question, when we talk about coincident 
surfaces in these newsgroups we really mean coincident, as in box face 
overlapping a box face; intersecting surfaces, where one surface flows 
through another surface - and sometimes we get patches/effective surface 
patches sharing all or part of an edge.

Where you want to see red, you have the second type - intersecting surfaces.

Ray tracing runs in a numerically noisy environment. Where we hit the 
coincident surface issue it means we have surfaces and intersections all 
within some ever changing (ray to ray and more) numerically noisy 
window/tolerance.

I'm not going to try to enumerate particular situations where your 
approach works and it doesn't with respect to coincident surfaces / 
numerical noise issues; other than to say, sometimes you get the result 
you want and sometimes not.

I believe there are two issues in your approach. I think +am3 is able to 
help with the coincident surfaces type, but not the 'things got so 
small' they are sitting between our camera rays(a) type.

(a) - Hmm, you might get some improvement too by moving to larger 
renders for this reason. Ray spacing is relative to the scene is smaller 
the larger the render.

> 
>> (1) - And perhaps help more with more aggressive options (more than +am3).
> 
> ?? do you a mean smaller aa threshold?
> 

Maybe. I was though thinking more about AA depth (+r<n>) and IIRC +am3 
has a confidence setting of some kind. I've played with the new AA 
method 3, but not much. It can be very slow. When I was working on those 
mazes, I had a situation where with +am3 running fine and I changed the 
ground color. Suddenly the runs times went up 100 fold - as if the 
adaptive mechanism was suddenly off. Maybe a bug, maybe just the 
behavior - not gotten back to look.

Aside: Method 3's ability to hone in on detail missing the original 
camera rays also makes it good at enhancing bugs/artefacts! I recommend 
using it when you are trying to pick up tiny details, and method 2 
otherwise.

> 
> yes, for my purposes, 'eval_pigment' doesn't do.  as I wrote in reply to BE, a
> variant of 'trace' would be nice; perhaps reversing the normal and use it as a
> camera ray to get the colour.  it would be useful, even given the provisos you
> mention, because it would work on an in-situ object as is.
> 

Hmm. Another bit of code I've hardly used. I have it in my head 
eval_pigment is passed a pigment and it returns the raw pigment value at 
the x,y,z of the intersection. No normals no other factors, but maybe 
that's sort of your point? You want something which evaluates - maybe - 
overlapped textures on an object at a point?

We do have the user defined functional camera in v38. If we can capture 
the normal and intersections, it should be these can be turned into 
object facing camera rays the reverse of raw surface normal.

Still glossing over lots of detailed issues about what folks 'really' 
want vs what we'd really get.

>> What are you really trying to do - and for what inputs and outputs?
> 
> :-)  my current "motivation" is creating .. fodder for my shiny, new program.
> it reads three DF3s (with the RGB components) and outputs a VRML PROTO with that
> data as a 'PointSet'.
> 
> inputs - arbitrary ("pretty" :-)) objects (or whole, small-ish scenes).
> 

:-) I didn't completely follow what your trying with VRML. I don't know 
it. If you get something going, fire off a news post or two. I'll keep 
thinking about the edge detection, maybe something will pop into my head 
worth trying.

Will mention some were creating cartoon images on the fly from scenes 
years ago. Prior work which might be worth looking over. I think most 
approached it with multiple renders, but...long time ago.

Aside: I play with df3s and have downloaded several of your utilities 
with the intent of giving them a whirl. Not gotten to it... :-(

Bill P.

[Bald Eagle] Re: sphere slicing problem [2366 days 12 hours and 38 minutes ago]

Tue, 15 Oct 2019 18:45:00 GMT

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

> > Your after the textures (and lighting... +AM3 best bet for that) at the
> > edges - others have warned in posts about the complications thereof.
> > What eval_pigment does is what can somewhat simply and reliably be done.
> > For the rest angles of rays camera, shadow, slightly adjacent rays, etc
> > play a part in the resultant pixel color.
>
> yes, for my purposes, 'eval_pigment' doesn't do.  as I wrote in reply to BE, a
> variant of 'trace' would be nice; perhaps reversing the normal and use it as a
> camera ray to get the colour.  it would be useful, even given the provisos you
> mention, because it would work on an in-situ object as is.

Well, we've played with locating 3D points in space based on 2D screen
coordinates, and I and at least one other have played with analyzing the color
maps of existing images - so you could render your frames, and then use
eval_pigment to scan the final rendered/lit/textured/shadowed, etc result in a
2-stage process using the rendered frames as image_maps in Step 2.

So perhaps you could use trace in Step 1 to compile a list of pixels to analyze
and store, and then use eval_pigment in Step 2 to only look at those pixels in
an image map of the rendered frames...

With regard to the slicing problem:
I'm wondering if you can use/abuse the orthographic camera itself to get what
you want.
I came across this when Ton posted a link to FL's site.
see:
http://www.f-lohmueller.de/pov_tut/scale_model/s_mod_150e.htm

Maybe with some sort of no_shadow or double_illuminate keywords, you could get
it to light the surface of that interior "slice".

[jr] Re: sphere slicing problem [2366 days 16 hours and 53 minutes ago]

Tue, 15 Oct 2019 14:30:01 GMT

hi,

William F Pokorny <ano### [at] anonymousorg> wrote:
> On 10/15/19 5:52 AM, jr wrote:
> > ...
> Looks like generally your are looking to do a scan of any object to find
> the edges? Though the use a of transparent box to do this is inspired -
> it won't work reliably for the reasons I suggested in my earlier post.
> Expect scanning a box works even less well?

had not tried, but now guess that would indeed be the result.

> Guessing at what might be confusing, when POV-Ray does CSG, it isn't
> creating intermediate shapes or surfaces. It's describing the treatment
> for the ray surface intersections found along the ray.

that might explain "strange" interiors.  I did a scan of FMunoz's robot and was
surprised by the "junk" showing up inside.  :-)

> This means for
> you, you'll have both coincident (sometimes wrongly ordered)
> intersections and ones less and less likely to align with the
> orthographic camera rays as the sampled surface becomes parallel to the
> ray. Such rays, if they hit, would be near tangents to the surface - the
> shortest of these tends to get filtered in many objects too for a few
> reasons.

and that's the core problem I guess.  when the surface is seen along the "thin"
edge.  </sigh>

could you please elaborate on "coincident (sometimes wrongly ordered)
intersections"?  with my (admittedly) limited understanding I would have thought
that a box/sphere intersection must be the same as a sphere/box.  in the macro
I'd "oversized" the slice (box) in the plane to avoid coincident surfaces
at/near the bounding box.

> If you want to try something that might be better with your current set
> up, the new v38 +am3 anti-alias mode might help(1). It can be slow.
> Here, if it works better, it would sort of be picking up 'enough' noise
> (enough intersections in the chance right way) to resolve the edges. I
> still expect it to struggle on the middle most rings no matter and
> perhaps not help much when scanning a box say with whole sides parallel
> to the camera rays.

bingo!  yes, using sampling_method=3 in the .ini makes a massive difference, the
rings now stay coherent almost up to the 80th frame.  but, as you thought, the
middle is still no better.

still, worth knowing.  (I tend to use method 2 but will now switch)

> (1) - And perhaps help more with more aggressive options (more than +am3).

?? do you a mean smaller aa threshold?

> There is edge detection of Bald_Eagle's solid shapes which can be run in
> gimp, photoshop, command line packages like netpbm and such. You can
> emulate edge detection methods in POV-Ray too folks have done it, but
> using something canned for 2d I expect easier/faster.

don't really use GIMP/netpbm/ImageMagick very much.  I can imagine having a tool
which, having performed edge detection, could extrapolate, to some degree,
what's missing and fill in.  (never had the need to even want such a tool :-))

> Your after the textures (and lighting... +AM3 best bet for that) at the
> edges - others have warned in posts about the complications thereof.
> What eval_pigment does is what can somewhat simply and reliably be done.
> For the rest angles of rays camera, shadow, slightly adjacent rays, etc
> play a part in the resultant pixel color.

yes, for my purposes, 'eval_pigment' doesn't do.  as I wrote in reply to BE, a
variant of 'trace' would be nice; perhaps reversing the normal and use it as a
camera ray to get the colour.  it would be useful, even given the provisos you
mention, because it would work on an in-situ object as is.

> If your looking to create meshes only for a few of the simpler shapes
> like spheres and boxes you can create meshes from the HF macros in
> shapes.inc.

no, no meshes.  since I don't have modelling software, I've (currently) little
exposure to them.

> What are you really trying to do - and for what inputs and outputs?

:-)  my current "motivation" is creating .. fodder for my shiny, new program.
it reads three DF3s (with the RGB components) and outputs a VRML PROTO with that
data as a 'PointSet'.

inputs - arbitrary ("pretty" :-)) objects (or whole, small-ish scenes).

> Knowing that maybe some method to get you edges can be worked out. Maybe
> someone remembers a macro or two that already does what you need.

no, I think you're probably correct about the limitations of the approach.  the
only alternative I think of now would be to scan a given object six times (from
either end of each axis) and somehow "stitch together" one result from that
data; I'm doing something like that already in the 'xmlVolumeFromObject' macro
that came with the 'df3-tools', but that results in many redundant points (which
bloat the already large files).  not quite sure where to go from here..

regards, jr.

[jr] Re: sphere slicing problem [2366 days 17 hours and 33 minutes ago]

Tue, 15 Oct 2019 13:50:00 GMT

hi,

"Bald Eagle" <cre### [at] netscapenet> wrote:
> I did this real quick - I'm off to work - but try putting the object LAST in the
> hierarchy so that the CSG inherits ITS texture properties, not the other way
> around.
>
>  #version 3.8;
>  global_settings {assumed_gamma 1.0 }
>  #include "colors.inc"
> #declare Aspect = image_width/image_height;
>  camera {
>   location <0, 5, -10>
>   right x*Aspect
>   look_at <0, 0, 0>
>  }
> light_source {<0, 5, -10> color White}
> plane {z, 1 pigment {White*0.2}}
> #declare Line = 0.015;
> #declare LinePigment = pigment {Yellow+White/2}
> #declare Slice = 0.1;
> #declare Sphere = difference {sphere {0, 0.5 } sphere {0, 0.3 }}
> #declare Box = box {<-1, 0, -1> <1, -Slice, 1>}
> #declare E = 0.000001;
> #for (M, -0.5, 0.5, Slice)
>  intersection {
>   object {Box translate y*M}
>   object {Sphere}
>   translate x*M*10
>   pigment {Red}
>  }
> #end


hey, thanks.  ran the following modification with '+kfi0 +kff11':

#version 3.8;

global_settings {assumed_gamma 1.0}

#include "colors.inc"

camera {
  orthographic
  location <0, 5, 0>
  look_at <0, 0, 0>
  sky <0,0,1>
}

light_source {<0, 5, 10> color White}
light_source {<0, 5, -10> color White}
light_source {<10, 5, 0> color White}
light_source {<-10, 5, 0> color White}

#declare Slice = 0.1;
#declare Sphere = sphere {0,.5 pigment {Red}};
#declare Box = box {<-1, 0, -1> <1, -Slice, 1> pigment {srgbt 1}};

#if (11 > frame_number)
  #declare M = -.5 + frame_number * Slice;
  intersection {
    object {Sphere}
    object {Box translate y*M}
  }
#end

order of elements in intersection not the problem, nor the container, as I
understand now.  see reply to Bill P for rest.


regards, jr.

[William F Pokorny] Re: sphere slicing problem [2366 days 19 hours and 47 minutes ago]

Tue, 15 Oct 2019 11:35:40 GMT

On 10/15/19 5:52 AM, jr wrote:
> "jr" <cre### [at] gmailcom> wrote:
>> "Bald Eagle" <cre### [at] netscapenet> wrote:
>>> Nope.  It's putting textures in too early.  The clear texture is what eliminates
>>> the surface[s] of the slice.
>> ...
> 
> just for the record, after trying suggested variations (clipped_by, bounded_by),
> I also tried with 'no_image' for both object and "slice", separate and together.
>   still the same looking output: of 200 frames only the first (and last) twenty
> or so result in complete rings, then progressive "break up", to nothing shown at
> all for circa ten frames around the middle.
> 

Looks like generally your are looking to do a scan of any object to find 
the edges? Though the use a of transparent box to do this is inspired - 
it won't work reliably for the reasons I suggested in my earlier post.
Expect scanning a box works even less well?

Guessing at what might be confusing, when POV-Ray does CSG, it isn't 
creating intermediate shapes or surfaces. It's describing the treatment 
for the ray surface intersections found along the ray. This means for 
you, you'll have both coincident (sometimes wrongly ordered) 
intersections and ones less and less likely to align with the 
orthographic camera rays as the sampled surface becomes parallel to the 
ray. Such rays, if they hit, would be near tangents to the surface - the 
shortest of these tends to get filtered in many objects too for a few 
reasons.

If you want to try something that might be better with your current set 
up, the new v38 +am3 anti-alias mode might help(1). It can be slow. 
Here, if it works better, it would sort of be picking up 'enough' noise 
(enough intersections in the chance right way) to resolve the edges. I 
still expect it to struggle on the middle most rings no matter and 
perhaps not help much when scanning a box say with whole sides parallel 
to the camera rays.

(1) - And perhaps help more with more aggressive options (more than +am3).

There is edge detection of Bald_Eagle's solid shapes which can be run in 
gimp, photoshop, command line packages like netpbm and such. You can 
emulate edge detection methods in POV-Ray too folks have done it, but 
using something canned for 2d I expect easier/faster.

Your after the textures (and lighting... +AM3 best bet for that) at the 
edges - others have warned in posts about the complications thereof. 
What eval_pigment does is what can somewhat simply and reliably be done. 
For the rest angles of rays camera, shadow, slightly adjacent rays, etc 
play a part in the resultant pixel color.

If your looking to create meshes only for a few of the simpler shapes 
like spheres and boxes you can create meshes from the HF macros in 
shapes.inc.

What are you really trying to do - and for what inputs and outputs? 
Knowing that maybe some method to get you edges can be worked out. Maybe 
someone remembers a macro or two that already does what you need.

Bill P.

[Bald Eagle] Re: sphere slicing problem [2366 days 20 hours and 13 minutes ago]

Tue, 15 Oct 2019 11:10:00 GMT

I did this real quick - I'm off to work - but try putting the object LAST in the
hierarchy so that the CSG inherits ITS texture properties, not the other way
around.

 #version 3.8;
 global_settings {assumed_gamma 1.0 }
 #include "colors.inc"

#declare Aspect = image_width/image_height;

 camera {
  location <0, 5, -10>
  right x*Aspect
  look_at <0, 0, 0>
 }

light_source {<0, 5, -10> color White}

plane {z, 1 pigment {White*0.2}}

#declare Line = 0.015;
#declare LinePigment = pigment {Yellow+White/2}

#declare Slice = 0.1;
#declare Sphere = difference {sphere {0, 0.5 } sphere {0, 0.3 }}
#declare Box = box {<-1, 0, -1> <1, -Slice, 1>}

#declare E = 0.000001;

#for (M, -0.5, 0.5, Slice)
 intersection {
  object {Box translate y*M}
  object {Sphere}

  translate x*M*10
  pigment {Red}
 }
#end

[jr] Re: sphere slicing problem [2366 days 21 hours and 28 minutes ago]

Tue, 15 Oct 2019 09:55:00 GMT

"jr" <cre### [at] gmailcom> wrote:
> "Bald Eagle" <cre### [at] netscapenet> wrote:
> > Nope.  It's putting textures in too early.  The clear texture is what eliminates
> > the surface[s] of the slice.
> ...

just for the record, after trying suggested variations (clipped_by, bounded_by),
I also tried with 'no_image' for both object and "slice", separate and together.
 still the same looking output: of 200 frames only the first (and last) twenty
or so result in complete rings, then progressive "break up", to nothing shown at
all for circa ten frames around the middle.

regards, jr.

[jr] Re: sphere slicing problem [2366 days 23 hours and 58 minutes ago]

Tue, 15 Oct 2019 07:25:01 GMT

good morning,

"Bald Eagle" <cre### [at] netscapenet> wrote:
> "jr" <cre### [at] gmailcom> wrote:
> > ...
> > I'd _love_ a trace()-like function which returns a colour (instead of a normal).
>
> That is called eval_pigment, Sir.

no, no, no!  not even close, I tried.

if you look at the macro in 'functions.inc' you'll see why, eval_pigment doesn't
"do" objects, all you get is a colour read from the pigment at the given
co-ordinate.  does not work for all pigments as you say (and I'd need it to work
on textures, anyway), and lighting is not taken into account either.

regards, jr.

[Bald Eagle] Re: sphere slicing problem [2367 days 8 hours and 3 minutes ago]

Mon, 14 Oct 2019 23:20:00 GMT

"jr" <cre### [at] gmailcom> wrote:
> hi,
>
> "Bald Eagle" <cre### [at] netscapenet> wrote:
> > "jr" <cre### [at] gmailcom> wrote:
> > > does not for me.  :-(  I get solid (filled) circles, not rings.
> > ...
> > Sounds like that ex-post facto texturing lots of people would like...
>
> I'd _love_ a trace()-like function which returns a colour (instead of a normal).

That is called eval_pigment, Sir.

http://wiki.povray.org/content/Reference:Functions.inc

Pre defined functions
eval_pigment(Pigm, Vect): This macro evaluates the color of a pigment at a
specific point. Some pigments require more information than simply a point,
slope pattern based pigments for example, and will not work with this macro.
However, most pigments will work fine.

Parameters:

Vect = The point at which to evaluate the pigment.
Pigm = The pigment to evaluate.

[jr] Re: sphere slicing problem [2367 days 10 hours and 28 minutes ago]

Mon, 14 Oct 2019 20:55:06 GMT

hi,

"Bald Eagle" <cre### [at] netscapenet> wrote:
> "jr" <cre### [at] gmailcom> wrote:
> > does not for me.  :-(  I get solid (filled) circles, not rings.
> ...
> Sounds like that ex-post facto texturing lots of people would like...

I'd _love_ a trace()-like function which returns a colour (instead of a normal).

> try using 2 "clipped_by" objects instead of an intersection?

good thought, had overlooked that.  so I modified the macro to return the box
dimensions only and used that in a clipped_by, but, no dice.  in fact, visually
identical.

> I really never use that command - so maybe others have advice.

fingers crossed.  and, thank you.

regards, jr.

[Bald Eagle] Re: sphere slicing problem [2367 days 13 hours and 58 minutes ago]

Mon, 14 Oct 2019 17:25:00 GMT

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

> does not for me.  :-(  I get solid (filled) circles, not rings.

Ah.

> that may not always be an option.  the idea is to slice arbitrary objects
> (suitably scaled + positioned).  the object may not always be my own work
> though.

Sounds like that ex-post facto texturing lots of people would like...

try using 2 "clipped_by" objects instead of an intersection?

I really never use that command - so maybe others have advice.

[jr] Re: sphere slicing problem [2367 days 14 hours and 38 minutes ago]

Mon, 14 Oct 2019 16:45:05 GMT

hi,

"Bald Eagle" <cre### [at] netscapenet> wrote:
> "jr" <cre### [at] gmailcom> wrote:
> > (replying to both you and Bald Eagle here)
> > think BE is right in that it is probably a "small, simple" thing.  currently
> > thinking it may be the camera.
>
> Nope.  It's putting textures in too early.  The clear texture is what eliminates
> the surface[s] of the slice.

ok.

> I tried this and it looks ok to me.
> try this fix, where I moved your sphere texture to the final object {} and
> commented out the hollow and texturing of your slicing box.

does not for me.  :-(  I get solid (filled) circles, not rings.

promising though and I now have a lead (here goes hope :-))

> In reality, nothing should have any textures normals or finishes, and you should
> do it ALL in the final object {}.

that may not always be an option.  the idea is to slice arbitrary objects
(suitably scaled + positioned).  the object may not always be my own work
though.


regards, jr.

[Bald Eagle] Re: sphere slicing problem [2367 days 15 hours and 8 minutes ago]

Mon, 14 Oct 2019 16:15:00 GMT

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

> (replying to both you and Bald Eagle here)
>
> think BE is right in that it is probably a "small, simple" thing.  currently
> thinking it may be the camera.

Nope.  It's putting textures in too early.  The clear texture is what eliminates
the surface[s] of the slice.

I tried this and it looks ok to me.

try this fix, where I moved your sphere texture to the final object {} and
commented out the hollow and texturing of your slicing box.

In reality, nothing should have any textures normals or finishes, and you should
do it ALL in the final object {}.




#version 3.8;

// macro snipped from its .inc file.
#declare SR_EPS = 0.001;

#macro sr_slice(o_, r_, n_)
//  #if (sr_chk_res(r_))
//    #error "oops, bad resolution.\n"
//  #elseif (sr_chk_obb(o_))
//    #error "oops, bad object position/dimension.\n"
//  #end
  #local lb_ = min_extent(o_);
  #local ub_ = max_extent(o_);
  #local D_ = ub_ - lb_;
  /* oversize(d) slice */
  #local tx_ = D_.x * .1;
  #local tz_ = D_.z * .1;
  /* number slices + thickness + offset */
  #local N_ = int(D_.y * r_.y + .5);
  #local T_ = D_.y / N_;
  #local O_ = T_ * n_;
  /* verify {n_} is in range */
  #if ((0 > n_) | (N_ <= n_))
    #error "oops, bad frame/slice number.\n"
  #end
  #local S_ = box {
    <lb_.x-tx_, O_, lb_.z-tz_>-SR_EPS, <ub_.x+tx_, O_+T_, ub_.z+tz_>+SR_EPS
    no_reflection no_shadow
    //texture {pigment {colour srgbt 1}}
  };
  intersection {
    object {o_}
    object {S_}
  }
#end


/* environment */

global_settings {assumed_gamma 1}

background {colour srgb 0}


/* lights */
#if (1)
  /* white lights at corners of an imaginary cube */
  #local LD = 50;
  #local Lpos = array [8] {
    <-LD,LD,-LD>, <LD,LD,-LD>, <-LD,-LD,-LD>, <LD,-LD,-LD>,
    <-LD,LD,LD>, <LD,LD,LD>, <-LD,-LD,LD>, <LD,-LD,LD>
  };
  #for(I_,0,7)
    light_source {Lpos[I_] srgb 1 parallel shadowless}
  #end
#else
  /* white lights along axes */
  #local LD = 50;
  #local Lpos = array [6] {
    <-LD,0,0>, <LD,0,0>, <0,-LD,0>, <0,LD,0>, <0,0,-LD>, <0,0,LD>
  };
  #for(I_,0,5)
    light_source {Lpos[I_] srgb 1 parallel shadowless}
  #end
#end


/* object.
 * fully textured and scaled, its bounding box must run from origin
 * to positive, small-ish <x,y,z>.
 */

#declare Obj = sphere {0,1
  translate +1
};

//#debug concat("min: <",vstr(3,min_extent(Obj),",",0,6),">\n")
//#debug concat("max: <",vstr(3,max_extent(Obj),",",0,6),">\n")


/* cameras.
 * perspective for development, orthographic for slicing.
 */

#if (1)
  camera {
    orthographic
    location <1,5,1>
    look_at <1,0,1>
    sky <0,0,1>
    angle 50
  }
#else
  camera {
    perspective
    location <1,1,-5>
    look_at <1,1,1>
    up <0,1,0>
    right x * (image_width/image_height)
  }
#end

// only Y matters.
#declare Res = <10,100,10>;

//sr_feedback(Obj,Res)
object {sr_slice(Obj,Res,frame_number) texture {pigment {srgb <1,0,0>}} }

[jr] Re: sphere slicing problem [2367 days 17 hours and 3 minutes ago]

Mon, 14 Oct 2019 14:20:01 GMT

hi,

(replying to both you and Bald Eagle here)

think BE is right in that it is probably a "small, simple" thing.  currently
thinking it may be the camera.

William F Pokorny <ano### [at] anonymousorg> wrote:
> On 10/14/19 7:09 AM, jr wrote:
> > ...
>
> I'm mostly otherwise busy today, but a scene file would help.

yes, my bad.  just posted a zip in p.b.misc.

> I don't
> understand how you are getting rings from the box and sphere
> intersection. ...Unless this why you made the box is transparent?

yes.  and I should have said, there's nothing special about the sphere.  this
"slicing rig" is meant to work with arbitrary objects.  the red sphere is just
testing.

> ...
> Or given the orthographic camera a torus changed frame by frame might be
> better - rings could be of constant width except at the very top and
> bottom.

my current hypothesis: my orthographic camera setup is wrong.

regards, jr.

[William F Pokorny] Re: sphere slicing problem [2367 days 18 hours and 1 minute ago]

Mon, 14 Oct 2019 13:22:01 GMT

On 10/14/19 7:09 AM, jr wrote:
> hi,
> 
> I'm working on a macro which, given an object positioned at origin, a vertical
> resolution, and a frame_number N, returns the Nth "slice", ie the intersection
> of object and a (transparent) box.
> 
> when I scan a simple (red) sphere[*], the first few frames, and the last few
> look exactly as expected, however, on the frames between more and more
> information is missing, up to 100% in the middle.
> 
> puzzled, and no idea what the problem might be.
> 
> I've posted a zip with a set of example frames in povray.binaries.misc.
> 
> [*] lit by eight light at corners of imaginary cube, recorded with orthographic
> camera positioned above.
> 
> regards, jr.
> 

I'm mostly otherwise busy today, but a scene file would help. I don't 
understand how you are getting rings from the box and sphere 
intersection. ...Unless this why you made the box is transparent?

Supposing so. Guess you see one opaque sphere surface cleanly top and 
bottom except at the very edges. Where both box transparent surfaces 
well inside the sphere you'd use those transparent intersections.

At the edges - even where it looks like things are working - you'd get, 
not coincident surfaces, but coincident intersections for at least one 
surface of the transparent box. Perhaps that's the problem?

If ring slices the aim, perhaps something like:

intersection {
   difference { 'sphOuter' 'sphInner' }
   box {... translate <0,frameOffset,0> }
   texture { }
}

Or given the orthographic camera a torus changed frame by frame might be 
better - rings could be of constant width except at the very top and 
bottom.

Bill P.

[Bald Eagle] Re: sphere slicing problem [2367 days 18 hours and 3 minutes ago]

Mon, 14 Oct 2019 13:20:01 GMT

"jr" <cre### [at] gmailcom> wrote:
Without code, I can only speculate.
Is the sphere hollow?
Do you apply a transparent pigment/texture to the box?

Looks like some small simple thing that's being overlooked.

[jr] sphere slicing problem [2367 days 20 hours and 13 minutes ago]

Mon, 14 Oct 2019 11:10:01 GMT

hi,

I'm working on a macro which, given an object positioned at origin, a vertical
resolution, and a frame_number N, returns the Nth "slice", ie the intersection
of object and a (transparent) box.

when I scan a simple (red) sphere[*], the first few frames, and the last few
look exactly as expected, however, on the frames between more and more
information is missing, up to 100% in the middle.

puzzled, and no idea what the problem might be.

I've posted a zip with a set of example frames in povray.binaries.misc.

[*] lit by eight light at corners of imaginary cube, recorded with orthographic
camera positioned above.


regards, jr.

[jr] Re: povray.conf contains evil directory [2370 days 15 hours and 38 minutes ago]

Fri, 11 Oct 2019 15:45:01 GMT

hi,

William F Pokorny <ano### [at] anonymousorg> wrote:
> On 10/11/19 9:25 AM, jr wrote:
> > Dick Balaska <dic### [at] buckosoftcom> wrote:
> >> On 10/11/19 7:22 AM, jr wrote:
> >>> Dick Balaska <dic### [at] buckosoftcom> wrote:
> >>>> ...
> >>>> For me, on debian/ubuntu/mint, povray/qtpovray ends up at
> >>>> /usr/share/povray-3.7
> >>>> /usr/share/qtpovray-3.8
> >>> weird.  neither is "system" software, so should go under '/usr/local' (or
> >>> '/opt'), aiui.
> >>
> >> /usr/share: Architecture-independent (shared) data.
> >> https://en.wikipedia.org/wiki/Filesystem_Hierarchy_Standard
> >
> > thanks.  could have sworn there's a section 7 man page too, but cannot find it
> > now.  :-(
> >
> >> I have 351 directories of foo under /usr/share
> >> /usr/local is for stuff I build myself.  I didn't, I installed the
> >> "official" debian package.
> >>
> >> /opt is for optional.   Good for whole self contained self-downloaded
> >> packages.  Like /opt/eclipse and /opt/Qt.
> >
> > still, strange choice.  conflict between build system and packaging tool?  in my
> > (nvh) opinion, the packages should install under '/usr/local', and the
> > "architecture independent" stuff under '/usr/local/share'.
> >
> > wrt '/opt', _if_ POV-Ray installed as '/opt/povray/{bin,etc,share}', I'd be ok
> > with that too.
> >
> > if you create your own (qtpovray) package, does that differ from the official
> > package?  (blame the maintainer!  ;-))
> >
> >> I'm curious, on your slackware system, where do your *.vim files live?
> >> (like filetype.vim)  The povray %INSTALLDIR% is a cousin of that.
> >
> > '/usr/share/vim'.  however, the editor is (of course) part of the system s/ware.
> >
> > regards, jr.
> >
>
> With respect to /opt/<package>, on my Ubuntu system at the moment I have
> the /opt mount point, but nothing there. When you install something like
> /opt/eclipse, does that install update PATH and so on for everyone on
> the system?
>
> The user PATH is set up already with /usr/bin and /usr/local/bin so an
> executable placed in either of those directories naturally gets picked up.
>
> With respect to the povray etc directory, I think builds are hard coded
> to look for it and those two files, but uncertain of details. If
> correct, it means any change will be more than just deleting that
> povray.conf line. We'd need to find another home for those /etc files.
>
> I'm not very familiar with the package build process, but for my
> /usr/local installs the necessary /etc directory was created - povray
> stuff 3.7 and 3.8 versions is all that's there. Does this sort of
> directory creation not happen on /usr/share distribution package installs?
>
> Is perhaps <>/etc out of favor as a directory these days?

can only answer one of the questions.  typically a package installing in '/opt'
provides a 'somepackage.{sh,csh}' to go into '/etc/profile.d' where the shell
picks it up on login; Qt5 is an example, all it does is set an environment
variable and append the PATH.

like you, I never had "trouble" with POV-Ray installing under '/usr/local', it
just works.  why would/should the 'povray.{conf,ini} not go under
/usr/local/etc'?


regards, jr.

[William F Pokorny] Re: povray.conf contains evil directory [2370 days 16 hours and 5 minutes ago]

Fri, 11 Oct 2019 15:17:34 GMT

On 10/11/19 9:25 AM, jr wrote:
> hi,
> 
> Dick Balaska <dic### [at] buckosoftcom> wrote:
>> On 10/11/19 7:22 AM, jr wrote:
>>> Dick Balaska <dic### [at] buckosoftcom> wrote:
>>>> ...
>>>> For me, on debian/ubuntu/mint, povray/qtpovray ends up at
>>>> /usr/share/povray-3.7
>>>> /usr/share/qtpovray-3.8
>>> weird.  neither is "system" software, so should go under '/usr/local' (or
>>> '/opt'), aiui.
>>
>> /usr/share: Architecture-independent (shared) data.
>> https://en.wikipedia.org/wiki/Filesystem_Hierarchy_Standard
> 
> thanks.  could have sworn there's a section 7 man page too, but cannot find it
> now.  :-(
> 
>> I have 351 directories of foo under /usr/share
>> /usr/local is for stuff I build myself.  I didn't, I installed the
>> "official" debian package.
>>
>> /opt is for optional.   Good for whole self contained self-downloaded
>> packages.  Like /opt/eclipse and /opt/Qt.
> 
> still, strange choice.  conflict between build system and packaging tool?  in my
> (nvh) opinion, the packages should install under '/usr/local', and the
> "architecture independent" stuff under '/usr/local/share'.
> 
> wrt '/opt', _if_ POV-Ray installed as '/opt/povray/{bin,etc,share}', I'd be ok
> with that too.
> 
> if you create your own (qtpovray) package, does that differ from the official
> package?  (blame the maintainer!  ;-))
> 
>> I'm curious, on your slackware system, where do your *.vim files live?
>> (like filetype.vim)  The povray %INSTALLDIR% is a cousin of that.
> 
> '/usr/share/vim'.  however, the editor is (of course) part of the system s/ware.
> 
> regards, jr.
> 

With respect to /opt/<package>, on my Ubuntu system at the moment I have 
the /opt mount point, but nothing there. When you install something like 
/opt/eclipse, does that install update PATH and so on for everyone on 
the system?

The user PATH is set up already with /usr/bin and /usr/local/bin so an 
executable placed in either of those directories naturally gets picked up.

With respect to the povray etc directory, I think builds are hard coded 
to look for it and those two files, but uncertain of details. If 
correct, it means any change will be more than just deleting that 
povray.conf line. We'd need to find another home for those /etc files.

I'm not very familiar with the package build process, but for my 
/usr/local installs the necessary /etc directory was created - povray 
stuff 3.7 and 3.8 versions is all that's there. Does this sort of 
directory creation not happen on /usr/share distribution package installs?

Is perhaps <>/etc out of favor as a directory these days?

Bill P.

[jr] Re: povray.conf contains evil directory [2370 days 17 hours and 53 minutes ago]

Fri, 11 Oct 2019 13:30:00 GMT

hi,

Dick Balaska <dic### [at] buckosoftcom> wrote:
> On 10/11/19 7:22 AM, jr wrote:
> > Dick Balaska <dic### [at] buckosoftcom> wrote:
> >> ...
> >> For me, on debian/ubuntu/mint, povray/qtpovray ends up at
> >> /usr/share/povray-3.7
> >> /usr/share/qtpovray-3.8
> > weird.  neither is "system" software, so should go under '/usr/local' (or
> > '/opt'), aiui.
>
> /usr/share: Architecture-independent (shared) data.
> https://en.wikipedia.org/wiki/Filesystem_Hierarchy_Standard

thanks.  could have sworn there's a section 7 man page too, but cannot find it
now.  :-(

> I have 351 directories of foo under /usr/share
> /usr/local is for stuff I build myself.  I didn't, I installed the
> "official" debian package.
>
> /opt is for optional.   Good for whole self contained self-downloaded
> packages.  Like /opt/eclipse and /opt/Qt.

still, strange choice.  conflict between build system and packaging tool?  in my
(nvh) opinion, the packages should install under '/usr/local', and the
"architecture independent" stuff under '/usr/local/share'.

wrt '/opt', _if_ POV-Ray installed as '/opt/povray/{bin,etc,share}', I'd be ok
with that too.

if you create your own (qtpovray) package, does that differ from the official
package?  (blame the maintainer!  ;-))

> I'm curious, on your slackware system, where do your *.vim files live?
> (like filetype.vim)  The povray %INSTALLDIR% is a cousin of that.

'/usr/share/vim'.  however, the editor is (of course) part of the system s/ware.

regards, jr.

[Dick Balaska] Re: povray.conf contains evil directory [2370 days 18 hours and 34 minutes ago]

Fri, 11 Oct 2019 12:49:18 GMT

On 10/11/19 7:22 AM, jr wrote:
> hi,
> 
> Dick Balaska <dic### [at] buckosoftcom> wrote:
>> ...
>> For me, on debian/ubuntu/mint, povray/qtpovray ends up at
>> /usr/share/povray-3.7
>> /usr/share/qtpovray-3.8
> 
> weird.  neither is "system" software, so should go under '/usr/local' (or
> '/opt'), aiui.
> 
> 
> regards, jr.
> 
> 

/usr/share: Architecture-independent (shared) data.
https://en.wikipedia.org/wiki/Filesystem_Hierarchy_Standard

I have 351 directories of foo under /usr/share

/usr/local is for stuff I build myself.  I didn't, I installed the 
"official" debian package.

/opt is for optional.   Good for whole self contained self-downloaded 
packages.  Like /opt/eclipse and /opt/Qt.

I'm curious, on your slackware system, where do your *.vim files live? 
(like filetype.vim)  The povray %INSTALLDIR% is a cousin of that.

-- 
dik
Rendered 1024 of 2073600 pixels (0%)

[jr] Re: povray.conf contains evil directory [2370 days 19 hours and 58 minutes ago]

Fri, 11 Oct 2019 11:25:00 GMT

hi,

Dick Balaska <dic### [at] buckosoftcom> wrote:
> ...
> For me, on debian/ubuntu/mint, povray/qtpovray ends up at
> /usr/share/povray-3.7
> /usr/share/qtpovray-3.8

weird.  neither is "system" software, so should go under '/usr/local' (or
'/opt'), aiui.


regards, jr.

[Dick Balaska] Re: povray.conf contains evil directory [2370 days 20 hours and 53 minutes ago]

Fri, 11 Oct 2019 10:29:38 GMT

On 10/11/19 4:13 AM, William F Pokorny wrote:
> On 10/10/19 2:30 AM, Dick Balaska wrote:
>> Line 94 of the default unix povray.conf contains a reference to
>> %INSTALL_DIR%/../../etc
>>
>> https://github.com/POV-Ray/povray/blob/master/unix/povray.conf
>>
>> This is the exact unix directory we *don't* want povray to read.
>>
>> This line should be removed.
> 
> On my Ubuntu system this resolves to /usr/local/etc for an actual system 
> install - which is OK I think. It's where the system wide povray.conf 
> and povray.ini files are installed and these I believe set the file i/o 
> access rights all users picking up the common install would get.
> 
> Am I missing something?
> 
> On your system are you ending up with /etc readable due a different tool 
> install directory structure, or?
> 
> Bill P.

For me, on debian/ubuntu/mint, povray/qtpovray ends up at
/usr/share/povray-3.7
/usr/share/qtpovray-3.8


so the evil dir is
/usr/etc
which does not exist.

Technically, the evil dir is undefined.
I still submit that there is no legitimate reason to ever access 
%INSTALL_DIR%/../anything
especially etc, which just makes it an incompetent evil.

-- 
dik
Rendered 95232 of 2073600 pixels (22%)

[William F Pokorny] Re: povray.conf contains evil directory [2370 days 23 hours and 9 minutes ago]

Fri, 11 Oct 2019 08:13:33 GMT

On 10/10/19 2:30 AM, Dick Balaska wrote:
> Line 94 of the default unix povray.conf contains a reference to
> %INSTALL_DIR%/../../etc
> 
> https://github.com/POV-Ray/povray/blob/master/unix/povray.conf
> 
> This is the exact unix directory we *don't* want povray to read.
> 
> This line should be removed.

On my Ubuntu system this resolves to /usr/local/etc for an actual system 
install - which is OK I think. It's where the system wide povray.conf 
and povray.ini files are installed and these I believe set the file i/o 
access rights all users picking up the common install would get.

Am I missing something?

On your system are you ending up with /etc readable due a different tool 
install directory structure, or?

Bill P.

[Dick Balaska] povray.conf contains evil directory [2372 days and 52 minutes ago]

Thu, 10 Oct 2019 06:30:26 GMT

Line 94 of the default unix povray.conf contains a reference to
%INSTALL_DIR%/../../etc

https://github.com/POV-Ray/povray/blob/master/unix/povray.conf

This is the exact unix directory we *don't* want povray to read.

This line should be removed.
-- 
dik
Rendered 1024 of 2073600 pixels (0%)

[Andreas Kaiser] Re: Two BBox calculation bugs in CSG and Quadric? [2406 days 10 hours and 25 minutes ago]

Thu, 5 Sep 2019 20:57:25 GMT

On Tue, 3 Sep 2019 08:59:44 -0400, William F Pokorny wrote:

>On 9/2/19 6:30 PM, Bald Eagle wrote:
>> 
>> William F Pokorny <ano### [at] anonymousorg> wrote:
>> 
>>>> Generally current POV code could be improved in such situations.
>>>> E.g look at void Box::Compute_BBox(): It assigns its DBL vectors to
>>>> the float vectors of BBox without checking and might lose almost all
>>>> of its significant digits that way.
>> 
>> I haven't dug down to _that_ level of the source code, so forgive me if this is
>> a naive question, but does POV-Ray make use of "extended precision" floats?
>> 
>> https://en.wikipedia.org/wiki/Extended_precision
>> 
>
>Not in any of the mainstream versions. My solver patch branch:
>
>   https://github.com/wfpokorny/povray/tree/fix/polynomialsolverAccuracy
>
>supports a PRECISE_FLOAT macro mechanism for the common solver code. 
>It's expensive. Even long double which is on my i3 still hardware backed 
>was something like +150% slower IIRC. More detail on these and 128 bit 
>float experiments are posted about elsewhere.
>
>My first concern with the comment to which you attached your question 
>isn't the potential loss of accuracy on any particular conversion given 
>our hard coded +-1e7 range limit, but that we are doing all these double 
>to single conversions which are fast opcodes, but not free.
>
>There is a storage savings to using single floats and - in theory - a 
>potential to fit more single floats in any one SIMD register for 
>potentially faster math. However, I think due other v37/v38 code changes 
>the SIMD aspect mostly not happening in practice even on machine 
>targeted compiles. Such gains mostly don't happen with machine generic 
>compiles in any case.
>
>A valid first accuracy concern - not an AABBs growing and growing by 
>rotations concern - I think is that we don't today accumulate as many 
>transforms (stored as doubles IIRC) as possible before updating the 
>bounding boxes, but rather - often enough - do them as they come. Each 
>seeing double to float conversions and potential value snapping. 
>Andreas's suggestion is to do the bounding box update once to a 'final' 
>transform and I agree this likely better.
>
>> 
>...
>>> issues with our ray -> shape/surface solvers. Today the practical scene
>>> limits, due ray intersection accuracy, set the working range to >1e-2 to
>>> maybe <1e5. Though, one can do better or worse depending on many factors.
>> 
>> Perhaps there's a way to track the min/max ranges and report on them in the
>> scene statistics?  It might help in debugging scenes, and interpreting user
>> feedback when there are avoidable problems simply due to scale.
>> 
>
>I have thought about the parsing + bounding process creating a least 
>enclosing environment box which users can access. The exposure I see is 
>more than the final scene scale. It's that users can today use 
>intermediate original definitions or transformations which corrupt the 
>accuracy of the final rendered representation mostly without notice.
>
>> 
>>> The idea of accumulating transforms before calculating the AABBs has
>>> merit I think, though I don't see it that simply done. Usually not too
>>> many transforms after the primitive is created we are into CSG and
>>> optimal AABBs at that level don't, to me, look easy - excepting some
>>> cases. Better over optimal AABBs perhaps.
>> 
>> Now that I have enough experience, and have asked enough newbie questions, I can
>> properly envision that CSG code tangle.  eek.   A naive question might be
>> whether or not a primitive could be internally/virtually/temporarily translated
>> to the origin and that "metadata" stored somehow.  Then the composed transform
>> matrix could be applied, and perhaps a modified ray/object intersection test
>> could be done in a domain where the float errors wouldn't mess everything up...
>> 
>
>What you describe sometimes happens today and sometimes not. Numerically 
>for the solvers I'd like it to happen more often, but what that really 
>means for some shapes - sphere_sweeps for example, isn't all that clear. 
>Further there are other trade offs in play. On my list is a completely 
>different implementation for spheres using a normalized representation 
>so I can do some comparisons.
>
>The new solver approach discussed elsewhere might support trade-offs 
>traditional solvers don't - normalization is potentially less important 
>numerically with the new approach. It's complicated - so much so I daily 
>doubt what I can really do - especially given my personal C++ 
>impediment. Some recent ideas potentially break from recent POV-Ray code 
>direction too which means I'm not sure what, longer term.
>
>> Sort of an automated version of your suggestion here:
>>
http://news.povray.org/povray.newusers/message/%3C5bfac735%241%40news.povray.org%3E/#%3C5bfac735%241%40news.povray.org%
>> 3E
>> 
>> "Today, you can 'sometimes' clean up many of the artifacts by
>> scaling the entire scene up (or down) by 100 or 1000x."
>> 
>
>I now know the scene scaling is two edged. You can get into as many 
>issues scaling up as down. It just happens, I think, given the 
>asymmetric nature of our current practical range, and that people tend 
>to create data about zero, that scaling up often better centers scenes 
>for POV-Ray's current numerical condition.
>
>Bill P.

I will add deferral of transformation computation and AABB calculation
next although I was doing something different right now.

I will also write down some issues with current use & intersection
calculation of AABBs.

Meanwhile here is a good read (note: really old but valid):
Search the web for "Goldberg What Every Computer Scientist Should Know
About Floating-Point Arithmetic".
The web page at oracle looked broken for me with Chrome wrt. equations
but was fine with Firefox. There are a lot of pdf versions as well.

You don't need to follow every equation, just read over them and get
an idea what can go wrong with floating-point calculations and why.
Most important are rounding errors and cancellation during subsequent
calculations with some good examples.

You'll wonder how well POV-Ray actually works :D
And we'll improve it to work even better ;)

[William F Pokorny] Re: Two BBox calculation bugs in CSG and Quadric? [2408 days 18 hours and 23 minutes ago]

Tue, 3 Sep 2019 12:59:45 GMT

On 9/2/19 6:30 PM, Bald Eagle wrote:
> 
> William F Pokorny <ano### [at] anonymousorg> wrote:
> 
>>> Generally current POV code could be improved in such situations.
>>> E.g look at void Box::Compute_BBox(): It assigns its DBL vectors to
>>> the float vectors of BBox without checking and might lose almost all
>>> of its significant digits that way.
> 
> I haven't dug down to _that_ level of the source code, so forgive me if this is
> a naive question, but does POV-Ray make use of "extended precision" floats?
> 
> https://en.wikipedia.org/wiki/Extended_precision
> 

Not in any of the mainstream versions. My solver patch branch:

   https://github.com/wfpokorny/povray/tree/fix/polynomialsolverAccuracy

supports a PRECISE_FLOAT macro mechanism for the common solver code. 
It's expensive. Even long double which is on my i3 still hardware backed 
was something like +150% slower IIRC. More detail on these and 128 bit 
float experiments are posted about elsewhere.

My first concern with the comment to which you attached your question 
isn't the potential loss of accuracy on any particular conversion given 
our hard coded +-1e7 range limit, but that we are doing all these double 
to single conversions which are fast opcodes, but not free.

There is a storage savings to using single floats and - in theory - a 
potential to fit more single floats in any one SIMD register for 
potentially faster math. However, I think due other v37/v38 code changes 
the SIMD aspect mostly not happening in practice even on machine 
targeted compiles. Such gains mostly don't happen with machine generic 
compiles in any case.

A valid first accuracy concern - not an AABBs growing and growing by 
rotations concern - I think is that we don't today accumulate as many 
transforms (stored as doubles IIRC) as possible before updating the 
bounding boxes, but rather - often enough - do them as they come. Each 
seeing double to float conversions and potential value snapping. 
Andreas's suggestion is to do the bounding box update once to a 'final' 
transform and I agree this likely better.

> 
...
>> issues with our ray -> shape/surface solvers. Today the practical scene
>> limits, due ray intersection accuracy, set the working range to >1e-2 to
>> maybe <1e5. Though, one can do better or worse depending on many factors.
> 
> Perhaps there's a way to track the min/max ranges and report on them in the
> scene statistics?  It might help in debugging scenes, and interpreting user
> feedback when there are avoidable problems simply due to scale.
> 

I have thought about the parsing + bounding process creating a least 
enclosing environment box which users can access. The exposure I see is 
more than the final scene scale. It's that users can today use 
intermediate original definitions or transformations which corrupt the 
accuracy of the final rendered representation mostly without notice.

> 
>> The idea of accumulating transforms before calculating the AABBs has
>> merit I think, though I don't see it that simply done. Usually not too
>> many transforms after the primitive is created we are into CSG and
>> optimal AABBs at that level don't, to me, look easy - excepting some
>> cases. Better over optimal AABBs perhaps.
> 
> Now that I have enough experience, and have asked enough newbie questions, I can
> properly envision that CSG code tangle.  eek.   A naive question might be
> whether or not a primitive could be internally/virtually/temporarily translated
> to the origin and that "metadata" stored somehow.  Then the composed transform
> matrix could be applied, and perhaps a modified ray/object intersection test
> could be done in a domain where the float errors wouldn't mess everything up...
> 

What you describe sometimes happens today and sometimes not. Numerically 
for the solvers I'd like it to happen more often, but what that really 
means for some shapes - sphere_sweeps for example, isn't all that clear. 
Further there are other trade offs in play. On my list is a completely 
different implementation for spheres using a normalized representation 
so I can do some comparisons.

The new solver approach discussed elsewhere might support trade-offs 
traditional solvers don't - normalization is potentially less important 
numerically with the new approach. It's complicated - so much so I daily 
doubt what I can really do - especially given my personal C++ 
impediment. Some recent ideas potentially break from recent POV-Ray code 
direction too which means I'm not sure what, longer term.

> Sort of an automated version of your suggestion here:
>
http://news.povray.org/povray.newusers/message/%3C5bfac735%241%40news.povray.org%3E/#%3C5bfac735%241%40news.povray.org%
> 3E
> 
> "Today, you can 'sometimes' clean up many of the artifacts by
> scaling the entire scene up (or down) by 100 or 1000x."
> 

I now know the scene scaling is two edged. You can get into as many 
issues scaling up as down. It just happens, I think, given the 
asymmetric nature of our current practical range, and that people tend 
to create data about zero, that scaling up often better centers scenes 
for POV-Ray's current numerical condition.

Bill P.

[Bald Eagle] Re: Two BBox calculation bugs in CSG and Quadric? [2409 days 8 hours and 48 minutes ago]

Mon, 2 Sep 2019 22:35:00 GMT

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

> > Generally current POV code could be improved in such situations.
> > E.g look at void Box::Compute_BBox(): It assigns its DBL vectors to
> > the float vectors of BBox without checking and might lose almost all
> > of its significant digits that way.

I haven't dug down to _that_ level of the source code, so forgive me if this is
a naive question, but does POV-Ray make use of "extended precision" floats?

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

> While it's work that happened before I was as deep in the source code,
> the bounding box code was substantially re-worked v37 to v38. A number
> of issues were fixed while re-factoring the code. The work mostly, or
> all, Christoph's (clipka's) I believe.

> My current opinion is accuracy issues due bounding follow accuracy
> issues with our ray -> shape/surface solvers. Today the practical scene
> limits, due ray intersection accuracy, set the working range to >1e-2 to
> maybe <1e5. Though, one can do better or worse depending on many factors.

Perhaps there's a way to track the min/max ranges and report on them in the
scene statistics?  It might help in debugging scenes, and interpreting user
feedback when there are avoidable problems simply due to scale.

> The idea of accumulating transforms before calculating the AABBs has
> merit I think, though I don't see it that simply done. Usually not too
> many transforms after the primitive is created we are into CSG and
> optimal AABBs at that level don't, to me, look easy - excepting some
> cases. Better over optimal AABBs perhaps.

Now that I have enough experience, and have asked enough newbie questions, I can
properly envision that CSG code tangle.  eek.   A naive question might be
whether or not a primitive could be internally/virtually/temporarily translated
to the origin and that "metadata" stored somehow.  Then the composed transform
matrix could be applied, and perhaps a modified ray/object intersection test
could be done in a domain where the float errors wouldn't mess everything up...

Sort of an automated version of your suggestion here:
http://news.povray.org/povray.newusers/message/%3C5bfac735%241%40news.povray.org%3E/#%3C5bfac735%241%40news.povray.org%
3E

"Today, you can 'sometimes' clean up many of the artifacts by
scaling the entire scene up (or down) by 100 or 1000x."

[William F Pokorny] Re: Two BBox calculation bugs in CSG and Quadric? [2409 days 15 hours and 42 minutes ago]

Mon, 2 Sep 2019 15:40:51 GMT

On 8/31/19 5:09 PM, Andreas Kaiser wrote:
> On Mon, 26 Aug 2019 08:24:31 -0400, William F Pokorny wrote:
> 
...
>>
>> See: https://github.com/POV-Ray/povray/issues/379
> 
> Thanks Bill for creating the issue.
> 
> I assume it was the limited accuracy of float (used in BBox code)
> which caused some problems: There are only 7 significant digits.
> E.g. when you translate a BBox over a large distance it literally
> loses its bits.
> Also adding some +/-EPSILON to the bounds when its size is 1.0e05
> already no longer works.

Yes, thanks, conversion to float a good candidate reason for this 
special treatment. Wonder why it's only applied to CSG and the quadric. 
Is it because the quadric can be part of CSG and there's something about 
quadric bounding making the CRITICAL_LENGTH code necessary for it alone..?

> 
> Generally current POV code could be improved in such situations.
> E.g look at void Box::Compute_BBox(): It assigns its DBL vectors to
> the float vectors of BBox without checking and might lose almost all
> of its significant digits that way.
> 
> bool Inside_BBox(const Vector3d& point, const BoundingBox& bbox):
> It doesn't handle the implicit +/-BOUND_HUGE means +/-Infinity at all.
> 
> The recurring recalcution of an object's BBox while parsing the scene
> file makes things worse and is completely superfluous:
> - do some consecutive rotations and the resulting AABB will grow each
> time
> - translate over some large distances and off are the bits.
> 
> An object's AABB is used in the tracing stage only, IMHO POV-Ray
> should simply compose all transformations during the parsing stage and
> then compute the AABB once.
> This could help a lot to keep AABBs as correct and close to their
> objects as possible.
> 

While it's work that happened before I was as deep in the source code, 
the bounding box code was substantially re-worked v37 to v38. A number 
of issues were fixed while re-factoring the code. The work mostly, or 
all, Christoph's (clipka's) I believe.

With the little I 'really' understand about the two bounding methods, I 
agree, don't and I'm unsure what you mean in parts. Certainly there is 
room for improvement.

My current opinion is accuracy issues due bounding follow accuracy 
issues with our ray -> shape/surface solvers. Today the practical scene 
limits, due ray intersection accuracy, set the working range to >1e-2 to 
maybe <1e5. Though, one can do better or worse depending on many factors.

Further, numerical errors (excluding the extreme crash test kind) in 
bounding are in a different numerical domain. They matter less to the 
'visual' result than errors happening in the ray - surface/shape 
equation normalized / somewhat-normalized domain.

Numerical error in the transforms / inverse transforms matter more, but 
also not as much as the ray surface intersections to 'visual' result.

With bounding - larger is OK/safe. Missing during bounds testing of 
course bad and there is a little of that going on of which we are aware 
in v37 and v38. It's one of a tangle of issues part of the 
https://github.com/POV-Ray/povray/pull/358 effort.

The idea of accumulating transforms before calculating the AABBs has 
merit I think, though I don't see it that simply done. Usually not too 
many transforms after the primitive is created we are into CSG and 
optimal AABBs at that level don't, to me, look easy - excepting some 
cases. Better over optimal AABBs perhaps.

Aside: We've been looking a little at bits of the bbox code due a v37 to 
v38 performance degrade: https://github.com/POV-Ray/povray/issues/363. 
Something for the, what that's worth, basket - maybe my understanding of 
the bounding mechanism will deepen some as a result. I'll keep what 
you've said in mind as I thrash around.

Bill P.

[Andreas Kaiser] Re: Two BBox calculation bugs in CSG and Quadric? [2411 days 10 hours and 13 minutes ago]

Sat, 31 Aug 2019 21:09:31 GMT

On Mon, 26 Aug 2019 08:24:31 -0400, William F Pokorny wrote:

>On 8/21/19 6:09 AM, William F Pokorny wrote:
>> On 8/20/19 8:33 PM, Andreas Kaiser wrote:
>...
>>>
>>> I don't remember anything in the code where it might help to set a big
>>> but finite AABB to +/- infinity.
>> 
>> Yes, same here, but this looks to me to be the intent of that code.
>> 
>I've confirmed this is the behavior for the csg code with the test scene 
>attached to the github issue.
>
>>> Actually this turns off BBox testing for the corresponding object.
>>>
>> 
>> I was thinking this too when I responded, but it's perhaps not entirely 
>> true in 3.7 onward.
>> 
>> It's the case changes in 3.7/3.8 leave a last level bounding test around 
>> the object even when bounding is off by -mb or +mb<count>. I have code 
>> branch - now some years old - which re-enables the 3.6 and prior like 
>> behavior of -mb. In other words, my branch really disables the inner 
>> most bounding box test in a way similar to 3.6.
>> 
>> I'm wondering this morning whether that last level of bounding box test 
>> is off for infinite objects? Though I have that patch, I just don't 
>> remember the behavior of the code well enough to know without 
>> investigation. If that inner most bounding test still gets done, it 
>> might be this code hack is - in 3.7/3.8 - of no value in any case.
>> 
>
>In some quick tests it looks like when an object is infinite it's not 
>tripping the bounding tests avoided by my patch branch. Given this at 
>least sometimes true there is some potential for this code to be fixing 
>or addressing some issue. In other words, see enough already to ignore 
>the rambling above.
>
>...
>> 
>> Lastly, I'd suggest we open up a github issue. Whether a bug or 
>> intentional, seems to me the code related to CRITICAL_LENGTH should be 
>> investigated.
>> 
>
>See: https://github.com/POV-Ray/povray/issues/379

Thanks Bill for creating the issue.

I assume it was the limited accuracy of float (used in BBox code)
which caused some problems: There are only 7 significant digits.
E.g. when you translate a BBox over a large distance it literally
loses its bits.
Also adding some +/-EPSILON to the bounds when its size is 1.0e05
already no longer works.

Generally current POV code could be improved in such situations.
E.g look at void Box::Compute_BBox(): It assigns its DBL vectors to
the float vectors of BBox without checking and might lose almost all
of its significant digits that way.

bool Inside_BBox(const Vector3d& point, const BoundingBox& bbox):
It doesn't handle the implicit +/-BOUND_HUGE means +/-Infinity at all.

The recurring recalcution of an object's BBox while parsing the scene
file makes things worse and is completely superfluous:
- do some consecutive rotations and the resulting AABB will grow each
time
- translate over some large distances and off are the bits.

An object's AABB is used in the tracing stage only, IMHO POV-Ray
should simply compose all transformations during the parsing stage and
then compute the AABB once.
This could help a lot to keep AABBs as correct and close to their
objects as possible.

[William F Pokorny] Re: Two BBox calculation bugs in CSG and Quadric? [2416 days 18 hours and 58 minutes ago]

Mon, 26 Aug 2019 12:24:31 GMT

On 8/21/19 6:09 AM, William F Pokorny wrote:
> On 8/20/19 8:33 PM, Andreas Kaiser wrote:
...
>>
>> I don't remember anything in the code where it might help to set a big
>> but finite AABB to +/- infinity.
> 
> Yes, same here, but this looks to me to be the intent of that code.
> 
I've confirmed this is the behavior for the csg code with the test scene 
attached to the github issue.

>> Actually this turns off BBox testing for the corresponding object.
>>
> 
> I was thinking this too when I responded, but it's perhaps not entirely 
> true in 3.7 onward.
> 
> It's the case changes in 3.7/3.8 leave a last level bounding test around 
> the object even when bounding is off by -mb or +mb<count>. I have code 
> branch - now some years old - which re-enables the 3.6 and prior like 
> behavior of -mb. In other words, my branch really disables the inner 
> most bounding box test in a way similar to 3.6.
> 
> I'm wondering this morning whether that last level of bounding box test 
> is off for infinite objects? Though I have that patch, I just don't 
> remember the behavior of the code well enough to know without 
> investigation. If that inner most bounding test still gets done, it 
> might be this code hack is - in 3.7/3.8 - of no value in any case.
> 

In some quick tests it looks like when an object is infinite it's not 
tripping the bounding tests avoided by my patch branch. Given this at 
least sometimes true there is some potential for this code to be fixing 
or addressing some issue. In other words, see enough already to ignore 
the rambling above.

...
> 
> Lastly, I'd suggest we open up a github issue. Whether a bug or 
> intentional, seems to me the code related to CRITICAL_LENGTH should be 
> investigated.
> 

See: https://github.com/POV-Ray/povray/issues/379

[William F Pokorny] Re: Two BBox calculation bugs in CSG and Quadric? [2421 days 21 hours and 13 minutes ago]

Wed, 21 Aug 2019 10:09:48 GMT

On 8/20/19 8:33 PM, Andreas Kaiser wrote:
> On Mon, 19 Aug 2019 17:41:16 -0400, William F Pokorny wrote:
> 
...
>>
>> That bit of code came in with v3.0, but I have no idea why. I 'think' it
>> might be doing what's intended...
>>
>> The aim isn't to shrink the bounding box, but rather to make it so
>> large, if already >1e6 on any side, that it is seen as an infinite
>> object and not included in normal bounding. BOUND_HUGE is larger than
>> MAX_DISTANCE (1e7). I say this without verifying that this the real
>> behavior though.
>>
>> Bill P.
> 
> I don't remember anything in the code where it might help to set a big
> but finite AABB to +/- infinity.

Yes, same here, but this looks to me to be the intent of that code.

> Actually this turns off BBox testing for the corresponding object.
> 

I was thinking this too when I responded, but it's perhaps not entirely 
true in 3.7 onward.

It's the case changes in 3.7/3.8 leave a last level bounding test around 
the object even when bounding is off by -mb or +mb<count>. I have code 
branch - now some years old - which re-enables the 3.6 and prior like 
behavior of -mb. In other words, my branch really disables the inner 
most bounding box test in a way similar to 3.6.

I'm wondering this morning whether that last level of bounding box test 
is off for infinite objects? Though I have that patch, I just don't 
remember the behavior of the code well enough to know without 
investigation. If that inner most bounding test still gets done, it 
might be this code hack is - in 3.7/3.8 - of no value in any case. 

> What should be done (and is done most often) is to clip all
> coordinates of a BBox to +/-BOUND_HUGE/2.
> IMHO this should be done in Make_BBox(...) always, not in the caller's
> code.
> 

I agree with you and take the code to which you point to be a hack of 
some sort to get around some bounding based issue. Unfortunately, there 
is not a central library of test cases for past problem scenes. I don't 
myself have access to the perforce code control system so don't even 
know who introduced the code. We can only remove the hack and see 
whether anything breaks.

I work mostly with my own version of POV-Ray. I'll put it on my list to 
create a branch which removes these hacks before I build my next 
personal POV-Ray version. Suppose some test cases aimed at triggering 
the code hack in order too. I'm pretty certain I have nothing in my 
personal test case collection which will trigger this code.

Lastly, I'd suggest we open up a github issue. Whether a bug or 
intentional, seems to me the code related to CRITICAL_LENGTH should be 
investigated.

Bill P.

[Andreas Kaiser] Re: Two BBox calculation bugs in CSG and Quadric? [2422 days 6 hours and 50 minutes ago]

Wed, 21 Aug 2019 00:33:08 GMT

On Mon, 19 Aug 2019 17:41:16 -0400, William F Pokorny wrote:

>On 8/19/19 4:28 PM, Andreas Kaiser wrote:
>> 
>> see CSG::Compute_BBox() in CSG.cpp and Quadric::Compute_BBox(Vector3d&
>> ClipMin, Vector3d& ClipMax) in Quadric.cpp:
>> ...
>>              Make_BBox_from_min_max(BBox, NewMin, NewMax);
>>   
>>              /* Beware of bounding boxes too large. */
>> 
>>              if((BBox.size[X] > CRITICAL_LENGTH) ||
>>                 (BBox.size[Y] > CRITICAL_LENGTH) ||
>>                 (BBox.size[Z] > CRITICAL_LENGTH))
>>                  Make_BBox(BBox, -BOUND_HUGE/2, -BOUND_HUGE/2,
>> -BOUND_HUGE/2, BOUND_HUGE, BOUND_HUGE, BOUND_HUGE);
>> 
>> CRITICAL_LENGTH is defined as 1.0e06, BOUND_HUGE/2 as 1.0e10 in both
>> cases.
>> 
>> This code will never shrink/limit the resulting BBox like the comment
>> above might suggest.
>> It will 'blow up' instead all dimensions of a BBox if just one of its
>> dimensions exceeds CRITICAL_LENGTH (which is still smaller than the
>> resulting dimension(s)).
>>   
>> I have no idea what the original intention might have been.
>>
>
>That bit of code came in with v3.0, but I have no idea why. I 'think' it 
>might be doing what's intended...
>
>The aim isn't to shrink the bounding box, but rather to make it so 
>large, if already >1e6 on any side, that it is seen as an infinite 
>object and not included in normal bounding. BOUND_HUGE is larger than 
>MAX_DISTANCE (1e7). I say this without verifying that this the real 
>behavior though.
>
>Bill P.

I don't remember anything in the code where it might help to set a big
but finite AABB to +/- infinity.
Actually this turns off BBox testing for the corresponding object.

What should be done (and is done most often) is to clip all
coordinates of a BBox to +/-BOUND_HUGE/2.
IMHO this should be done in Make_BBox(...) always, not in the caller's
code.

[William F Pokorny] Re: Two BBox calculation bugs in CSG and Quadric? [2423 days 9 hours and 42 minutes ago]

Mon, 19 Aug 2019 21:41:17 GMT

On 8/19/19 4:28 PM, Andreas Kaiser wrote:
> 
> see CSG::Compute_BBox() in CSG.cpp and Quadric::Compute_BBox(Vector3d&
> ClipMin, Vector3d& ClipMax) in Quadric.cpp:
> ...
>              Make_BBox_from_min_max(BBox, NewMin, NewMax);
>   
>              /* Beware of bounding boxes too large. */
> 
>              if((BBox.size[X] > CRITICAL_LENGTH) ||
>                 (BBox.size[Y] > CRITICAL_LENGTH) ||
>                 (BBox.size[Z] > CRITICAL_LENGTH))
>                  Make_BBox(BBox, -BOUND_HUGE/2, -BOUND_HUGE/2,
> -BOUND_HUGE/2, BOUND_HUGE, BOUND_HUGE, BOUND_HUGE);
> 
> CRITICAL_LENGTH is defined as 1.0e06, BOUND_HUGE/2 as 1.0e10 in both
> cases.
> 
> This code will never shrink/limit the resulting BBox like the comment
> above might suggest.
> It will 'blow up' instead all dimensions of a BBox if just one of its
> dimensions exceeds CRITICAL_LENGTH (which is still smaller than the
> resulting dimension(s)).
>   
> I have no idea what the original intention might have been.
>

That bit of code came in with v3.0, but I have no idea why. I 'think' it 
might be doing what's intended...

The aim isn't to shrink the bounding box, but rather to make it so 
large, if already >1e6 on any side, that it is seen as an infinite 
object and not included in normal bounding. BOUND_HUGE is larger than 
MAX_DISTANCE (1e7). I say this without verifying that this the real 
behavior though.

Bill P.

[Andreas Kaiser] Two BBox calculation bugs in CSG and Quadric? [2423 days 10 hours and 55 minutes ago]

Mon, 19 Aug 2019 20:28:11 GMT

see CSG::Compute_BBox() in CSG.cpp and Quadric::Compute_BBox(Vector3d&
ClipMin, Vector3d& ClipMax) in Quadric.cpp:
...
            Make_BBox_from_min_max(BBox, NewMin, NewMax);
 
            /* Beware of bounding boxes too large. */

            if((BBox.size[X] > CRITICAL_LENGTH) ||
               (BBox.size[Y] > CRITICAL_LENGTH) ||
               (BBox.size[Z] > CRITICAL_LENGTH))
                Make_BBox(BBox, -BOUND_HUGE/2, -BOUND_HUGE/2,
-BOUND_HUGE/2, BOUND_HUGE, BOUND_HUGE, BOUND_HUGE);

CRITICAL_LENGTH is defined as 1.0e06, BOUND_HUGE/2 as 1.0e10 in both
cases.

This code will never shrink/limit the resulting BBox like the comment
above might suggest.
It will 'blow up' instead all dimensions of a BBox if just one of its
dimensions exceeds CRITICAL_LENGTH (which is still smaller than the
resulting dimension(s)).
 
I have no idea what the original intention might have been.

[Warren] Re: Bug between plane and media [2431 days 21 hours and 58 minutes ago]

Sun, 11 Aug 2019 09:25:01 GMT

@Bald Eagle : Ok, I see (after testing your scene). Until now, I
thought the plane object was only a thin leaf, but now it's over. ;-D . To tell
the truth I was a little surprised that long time object like plane cause such
simple 'bug' that nobody found out before. Thank you anyway.

[Bald Eagle] Re: Bug between plane and media [2432 days 8 hours and 3 minutes ago]

Sat, 10 Aug 2019 23:20:01 GMT

//A scene that works and displays a checkered plane in the background with a
media in the view:
#version 3.8;
global_settings{ assumed_gamma 1.0 }
camera{
 location <0, 1, -6>
 look_at <0, 0, 0>
 sky y
 right 1*x
 up 1*y
 direction 1*z
 rotate -x*90
}

light_source{ <20, 20, -40> color srgb 1 }

#declare Mode = 0;  // <--- change this to see what I mean


plane{z, 4 pigment{ checker color srgb <0, 0, 1>, color srgb <1, 1, 0> }
#if (Mode) inverse #end

}

sphere{ 0, 1 hollow on pigment{ color srgbft <0, 0, 0, 0, 1> }
  interior{
    media{ emission 1 samples 1,30 intervals 10
      density{
        spherical density_map{
          [0 color srgb 0 ]
          [0.4 color srgb <1, 1, 0> ]
          [1 color srgb <1, 0, 0> ]
        }
       warp{ turbulence 0.25 lambda 4 omega 0.6 }
      }
    }
  }
  translate -2*z
}

//But if I change the plane statement line with the following:
//plane{z, 4 pigment{ checker color srgb <0, 0, 1>, color srgb <1, 1, 0> } }

[Bald Eagle] Re: Bug between plane and media [2432 days 12 hours and 13 minutes ago]

Sat, 10 Aug 2019 19:10:00 GMT

"Warren" <nomail@nomail> wrote:

Hi Warren -
I haven't rendered your scene yet, but I have the sneaking suspicion that what
you're seeing is the inversion of the plane.


"But if I change the plane statement line with the following:
plane{z, 4 pigment{ checker color srgb <0, 0, 1>, color srgb <1, 1, 0> } }

Removing the minus signs from 'z' and '4' hide the media when I render that
scene, but the checkered plane is well displayed."

So, a plane isn't an infinitely thin sheet - it's a "half-space".
Take the POV universe and slice it in half - one side of the slice is "inside"
the plane, and the other part is "outside".

Maybe texture your plane with rgbft 1 and see if you media "reappears".

I think when you switch from -z to z, the boundary/dividing plane stays the same
since you change the sign of the offset as well, but now you've switched inside
and outside.

Maybe add "inverse" to your new plane and see what happens.
Difference away another perpendicular plane, or a very large box, and see if
that uncovers a region of visible media.

Bill

[Warren] Bug between plane and media [2432 days 18 hours and 43 minutes ago]

Sat, 10 Aug 2019 12:40:01 GMT

Hello / Hi
Some time ago I made a scene which includes a media in a sphere and a plane
among other objects. At first the above media wasn't displayed in the rendered
image. I first thought it was me who had done things wrong (bad coordinates,
etc..). But after some further investigations and tweaks in my scene, I had the
conviction the problem was due to a bug (though I'm not sure at 100%). I post
two scenes sums below with the essentials parts (no undeeded objects, just
enough to make the bug appearing: a plane and a media in a sphere with of course
a camera and a light source):

//A scene that works and displays a checkered plane in the background with a
media in the view:
#version 3.8;
global_settings{ assumed_gamma 1.0 }
camera{
 location <0, 1, -6>
 look_at <0, 0, 0>
 sky y
 right 1*x
 up 1*y
 direction 1*z
}

light_source{ <20, 20, -40> color srgb 1 }

plane{-z, -4 pigment{ checker color srgb <0, 0, 1>, color srgb <1, 1, 0> } }

sphere{ 0, 1 hollow on pigment{ color srgbft <0, 0, 0, 0, 1> }
  interior{
    media{ emission 1 samples 1,30 intervals 10
      density{
        spherical density_map{
          [0 color srgb 0 ]
          [0.4 color srgb <1, 1, 0> ]
          [1 color srgb <1, 0, 0> ]
        }
       warp{ turbulence 0.25 lambda 4 omega 0.6 }
      }
    }
  }
  translate -2*z
}

But if I change the plane statement line with the following:
plane{z, 4 pigment{ checker color srgb <0, 0, 1>, color srgb <1, 1, 0> } }

Removing the minus signs from 'z' and '4' hide the media when I render that
scene, but the checkered plane is well displayed.

Here is the output of the 'povray --version' command in the terminal:

POV-Ray 3.8.0-x.10064738.unofficial

This is an unofficial version compiled by:
 Antoine FAURE <www.ant01.fr>
 The POV-Ray Team is not responsible for supporting this version.

Copyright 1991-2019 Persistence of Vision Raytracer Pty. Ltd.
This is free software; see the source for copying conditions.  There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.

Built-in features:
  I/O restrictions:          enabled
  X Window display:          enabled (using SDL)
  Supported image formats:   gif tga iff ppm pgm hdr png jpeg tiff openexr
  Unsupported image formats: -

Compilation settings:
  Build architecture:  x86_64-pc-linux-gnu
  Built/Optimized for: x86_64-pc-linux-gnu (using -march=native)
  Compiler vendor:     gnu
  Compiler version:    g++-8 8
  Compiler flags:      -pipe -Wno-multichar -Wno-write-strings
-fno-enforce-eh-specs -Wno-non-template-friend -Wsuggest-override -s -O3
-ffast-math -march=native -pthread

------------------------------------
You will notice that changing '#version 3.8;' to '#version 3.7;' doesn't change
anything ( just the same result while rendering scene ).

[TreeLimb Jim] Re: array mixed crashes in parser [2458 days 2 hours and 48 minutes ago]

Tue, 16 Jul 2019 04:35:00 GMT

"jr" <cre### [at] gmailcom> wrote:
> > //==== THIS GENERATES ERROR ====
> > #declare ColorDictionary = array mixed[2] {
> >  dictionary  { // Upper
> >   ["0"      ]: array[10] { 0,0,0,0,0, 0,0,0,0,0 }
> >   ["1001"]: array[10] { 0,0,0,0,0, 0,0,0,0,0 }
> >   ["1002"]: array[10] { 0,0,0,0,0, 0,0,0,0,0 }
> >   ...

Fixed quite a few things in my code. Best behavior so far:
1. >>>IMPORTANT<<< Dictionary names must be STRING but the initial character
must be an alpha character. This must be documented somewhere already. It makes
it handy to use
the dot delimiter as well as not to confuse elements inside the square brackets
as elements of an array.

2. Declare the array of dictionaries and THEN initialize them as in the
following rewrite:

#declare ColorDictionary = array mixed[2] { dictionary, dictionary }
#declare init10 = array[10] { 0,0,0,0,0, 0,0,0,0,0 }

#macro initColorDictionary()
// Upper
  #declare ColorDictionary[0].m0 = init10
  #declare ColorDictionary[0].m1001 = init10
  #declare ColorDictionary[0].m1002 = init10
// Lower
  #declare ColorDictionary[1].m0 = init10
  #declare ColorDictionary[1].m1001 = init10
  #declare ColorDictionary[1].m1002 = init10
#end

initColorDictionary()

I believe I'm getting closer to coding around a few things about concurrently
declaring and initializing but not simultaneously declare and initializing
arrays, including the superset called mixed arrays.

From preliminary explorations, in mixed arrays, my suggestion during alpha
development is to keep the same data type as initialized for that element and
quite likely, the dimension of the arrays and elements composed of arrays, too.
( brings memories of the horrors of writing context-free grammars and LEX/YACC )

[dick balaska] Re: Unresponsive crash in qtpovray with [acciden... [2460 days 13 hours and 53 minutes ago]

Sat, 13 Jul 2019 17:29:58 GMT

On 7/13/19 12:43 PM, Bald Eagle wrote:
> 
> 
> So, in a bit of haste, I ran my scene with
> 
> #declare Inverse = function (x, y, z, R, S) {log( 1-Inverse(x,y,z,R,S) )}
> 
> which of course calls itself, and POV-Ray issued a warning and stopped, but it
> also became unresponsive and gave me this in the terminal window
> 
> *** Error in `qtpovray': realloc(): invalid old size: 0x00007f580801dcd0 ***
> *** Error in `qtpovray': malloc(): memory corruption: 0x00007f580801d420 ***
> 
> Just throwing that out there.
> 

WORKSFORME

Can you post a whole scene that tips over?

----------
#version 3.7;
#declare Inverse = function (x, y, z, R, S) {log( 1-Inverse(x,y,z,R,S))}
----------

chdir:  /home/dick/povray/projects/animtest
command:  +Irecursivememdeath.pov

Possible Parse Error: Recursive function calls are not allowed!
at File: recursivememdeath.pov Line: 2 Col: 73
Possible Parse Error: assumed_gamma not specified in this POV-Ray v3.7
or later scene. Future versions of POV-Ray may consider this a fatal
error. To avoid this warning, explicitly specify 'assumed_gamma 1.0' in
the global_settings section. See the documentation for more details.
Parse Warning: No objects in scene.
-- 
dik
Rendered 1024 of 921600 pixels (0%)

[Bald Eagle] Unresponsive crash in qtpovray with [accidental]... [2460 days 14 hours and 38 minutes ago]

Sat, 13 Jul 2019 16:45:01 GMT

So, in a bit of haste, I ran my scene with

#declare Inverse = function (x, y, z, R, S) {log( 1-Inverse(x,y,z,R,S) )}

which of course calls itself, and POV-Ray issued a warning and stopped, but it
also became unresponsive and gave me this in the terminal window

*** Error in `qtpovray': realloc(): invalid old size: 0x00007f580801dcd0 ***
*** Error in `qtpovray': malloc(): memory corruption: 0x00007f580801d420 ***

Just throwing that out there.

povray 3.8.0-alpha.9861167.unofficial

This is an unofficial version compiled by:
 Dick Balaska - qtpovray edition <dic### [at] buckosoftcom>
 The POV-Ray Team is not responsible for supporting this version.

Copyright 1991-2018 Persistence of Vision Raytracer Pty. Ltd.
This is free software; see the source for copying conditions.  There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.

[jr] Re: array mixed crashes in parser [2461 days 16 hours and 3 minutes ago]

Fri, 12 Jul 2019 15:20:00 GMT

hi,

"TreeLimb Jim" <all### [at] yahoocom> wrote:
> Possible Parse Error: ...
> //==== THIS GENERATES ERROR ====
> #declare ColorDictionary = array mixed[2] {
>  dictionary  { // Upper
>   ["0"      ]: array[10] { 0,0,0,0,0, 0,0,0,0,0 }
>   ["1001"]: array[10] { 0,0,0,0,0, 0,0,0,0,0 }
>   ["1002"]: array[10] { 0,0,0,0,0, 0,0,0,0,0 }
>   ...

I think the problem is due to the names you give to the keys.  iiuc, the first
character cannot be a digit (3.3.1.10 Array, cf indices follow generic rules for
identifiers).

regards, jr.

[TreeLimb Jim] Re: array mixed crashes in parser [2462 days 6 hours and 43 minutes ago]

Fri, 12 Jul 2019 00:40:00 GMT

Time to change the Subject line

Again, I'm not going to peruse the code. That's above my pay grade and those
that are gefingerpoken it will sort it out. [Ref:
https://en.wikipedia.org/wiki/Blinkenlights]

Possible Parse Error: Uncategorized error thrown at
/Volumes/WDVrijstuk/PovRayUnofficial_3.8.0-alpha. 10013324-avx
source/source/parser/parser_tokenizer.cpp line 2413.


//==== THIS GENERATES ERROR ====
#declare ColorDictionary = array mixed[2] {
 dictionary  { // Upper
  ["0"      ]: array[10] { 0,0,0,0,0, 0,0,0,0,0 }
  ["1001"]: array[10] { 0,0,0,0,0, 0,0,0,0,0 }
  ["1002"]: array[10] { 0,0,0,0,0, 0,0,0,0,0 }
//  ["0"      ]: initZero10  // Do you think this would?
//  ["1001"]: initZero10  // And why was it a workaround
//  ["1002"]: initZero10  // In my previous post
 },
 dictionary {  // Lower
  ["0"      ]: array[10] { 0,0,0,0,0, 0,0,0,0,0 }
  ["1001"]: array[10] { 0,0,0,0,0, 0,0,0,0,0 }
//  ["0"      ]: initZero10  // Ibidem
//  ["1001"]: initZero10  // That's ibidem-way in Pig Latin
 }
};


//==== Que Voila? THIS DOES NOT GENERATE ERROR
#declare ColorDictionary = array[2] { dictionary, dictionary };

#macro initARPSliderCapColorDictionary()
 #declare ARPSliderCapColorDictionary[0] = dictionary  { // Upper
  ["0"      ]: array[10] { 0,0,0,0,0, 0,0,0,0,0 }
  ["1001"]: array[10] { 0,0,0,0,0, 0,0,0,0,0 }
  ["1002"]: array[10] { 0,0,0,0,0, 0,0,0,0,0 }
//  ["0"      ]: initZero10
//  ["1001"]: initZero10 // But this does when used ---
//            ^^^^^^^ Parse Error: Expected 'numeric expression',
string literal found instead
//  ["1002"]: initZero10 //
// };

 #declare ColorDictionary[1] = dictionary {  // Lower
  ["0"      ]: array[10] { 0,0,0,0,0, 0,0,0,0,0 }
  ["1001"]: array[10] { 0,0,0,0,0, 0,0,0,0,0 }
//  ["0"      ]: initZero10  // As above
//  ["1001"]: initZero10
// So <Return> is not necessarily the terminating character for dictionary
containers
 };
#end

initARPSliderCapColorDictionary()



So, consume these experiments in all their richness while I re-code the project.
The next chapter is to find out what is generating a hard crash in
3.8.0-alpha.10013324 but not in 3.8.0-alpha.9844500

[TreeLimb Jim] Re: array mixed crashes in parser [2462 days 8 hours and 18 minutes ago]

Thu, 11 Jul 2019 23:05:00 GMT

Thanks for all your coaching so far. I'm not certain whether these are hints to
a solution or hints to a work-around.

One hint was array initialization. Another hint was about substitution. This
helped me deconstruct why my specific implementation may function or break:

Recall, this is the thrown error:
"Possible Parse Error: Uncategorized error thrown at
/Volumes/WDVrijstuk/PovRayUnofficial_3.8.0-alpha. 10013324-avx
source/source/parser/parser_tokenizer.cpp line 2413."

// ==== THIS FAILS ====
#declare SampleSystem2 = dictionary  {
 .LeftMain2515:  array mixed[3][4] {
  { 1001, 1, array[20][2],array[20][2] },
  { 1023, 1, array[10] {0,0,0,0,0,0,0,0,0,0}, array[10]{0,0,0,0,0,0,0,0,0,0}},
  { 1036, 1, array[10] {0,0,0,0,0,0,0,0,0,0}, array[10]{0,0,0,0,0,0,0,0,0,0}},
  }
 .RightMain2515: array mixed[3][4] {
  { 1016, 1, array[20][2] , array[20][2] },
  { 1023, 1, array[10]{0,0,0,0,0,0,0,0,0,0},array[10]{0,0,0,0,0,0,0,0,0,0}},
  { 1002, 1, array[20][2] , array[20][2] },
  }
 .Keyboard:   array[1] { 3212 }
};

// ==== THIS DOES NOT GENERATE ERROR  ====
#declare initVect20 = array[20][2] ;
#declare initZero5 = array[10]{0,0,0,0,0,0,0,0,0,0};
#declare SampleSystem2 = dictionary  {
 .LeftMain2515:  array mixed[3][4] {
  { 1001, 1, initVect20 , initVect20 },
  { 1023, 1,initZero10, initZero10 },
  { 1036, 1,initZero10, initZero10 },
  }
 .RightMain2515: array mixed[3][4] {
  { 1016, 1, initVect20 , initVect20 },
  { 1023, 1,initZero10, initZero10 },
  { 1002, 1, initVect20 , initVect20 },
  }
 .Keyboard:   array[1] { 3212 }
};


It doesn't stop there, but I think I'm describing the problem. My next post
will demonstrate further the complexity of implementing "mixed-type" elements.

[Bald Eagle] Re: array mixed crashes in parser [2462 days 20 hours and 18 minutes ago]

Thu, 11 Jul 2019 11:05:01 GMT

"TreeLimb Jim" <all### [at] yahoocom> wrote:

> What I am up to is modeling the ARP 2500 modular synthesizer.
>
> https://encyclotronic.com/synthesizers/arp/2500-r167/
>
> Instead of planting arbitrary knob positions and the matrix switch panels for
> every instance of module, I used some data abstraction. An entire System is a
> dictionary, divided into one or more cabinets filled with info on the modules'
> state.

Excellent.   You're completely psychotic.
I like that in a POV-Ray user.   :D

Also keep in mind that vectors can be up to 7 elements long.
And instead of strings, you can store colors as rgb vectors.
And "save" those vectors in #declared constants.
#declare White = <1, 1, 1>;
Then those words are vectors, not strings.

and if you really needed to store strings, but for whatever reason couldn't, you
could do something like:

#declare _one = 1;
#declare _two = 2;
#declare _three = 3;

#declare Label = array [3] {"One", "Two", "Three"};
and then access the Label element with a "named" value:

#declare SliderLabel = Label [_two];

Just some random pre-coffee ideas that may or may not have any real value.
Hoping to see some of your WIP's   =)

[TreeLimb Jim] Re: array mixed crashes in parser [2463 days 4 hours and 18 minutes ago]

Thu, 11 Jul 2019 03:05:01 GMT

Using the files in scenes/language/arrays/ I extended each sample .pov file to
include a cursory extension of storing and accessing data in mixed arrays, a
dictionary, and a dictionary containing a mixed array. Just basic data types,
float, string, vector. Baseline worked fine, no problems.

//  Example Data structure snip from "array3 mixed dictionary.pov"
#declare MyDictionary = dictionary {
 .Digit:
  array mixed[4][10]
  {
    {<7,7,7>,6,7,0,2,1,6,5,5,0},
    {<1,1,1>,2,3,4,5,6,7,8,9,0},
    {<0,0,0>,9,8,7,6,5,4,3,2,1},
    {<1,1,1>,1,2,2,3,3,4,4,5,5}
  }
}
// Works!

One test scenario yet to be tested is to implement a multi-dimensional array,
partially initialized. Sounds similar to my problem.

OT Observation: Within a dictionary one can declare another dictionary

// Data structure snip [condensed] from my project
// Dictionary element representingthe
 .CustomCaps:  array[2] {
  dictionary  { // Upper
   ["1004.3"]: array[5]{ Blue, Green, Yellow, Black, Black } // Never shown
   ["1006.1"]: array[5]{ arpPink, Yellow, White, White, Red } // not a 1006
   ["1016" ]: array[5]{ Black, Black, Black, Black, Black } // Never shown
   ["1023.1"]: array[5]{ Blue, Green, Yellow, Black, Blue }
   ["1027.2"]: array[5]{ Orange, Orange, Green, Green, Red }
   ["1045" ]: array[5]{ Red, Red, Red, Green, Yellow } // PT
   }
  dictionary {  // Lower
   ["1004.3"]: array[5]{ Black, Yellow, Green, Red, White } // Never shown
   ["1006.1"]: array[5]{ Yellow, arpPink, arpPink, arpPink, arpPink } // custom
   ["1016" ]: array[5]{ Gray, Black, White, Black, Yellow } // Never shown
   ["1023.1"]: array[5]{ Yellow, Green, Blue, arpPink, Red }
   ["1027.1"]: array[5]{ White, White, White, Yellow, Yellow }
   ["1027.2"]: array[5]{ Orange, Orange, Green, Green, Red }

   }
  }
// This time implementing string labels, represents the colored slider caps for
a particular module

OT Observation: no message flagging when  .pov files used #version 3.7 or 3.8
and mixed arrays or dictionary implemented. No biggie, I used to test software.

Oh, and kudos for all those working on the parser. I'm trying to stay just an
end user.

[TreeLimb Jim] Re: array mixed crashes in parser [2463 days 4 hours and 48 minutes ago]

Thu, 11 Jul 2019 02:35:00 GMT

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

> Are you aware of:
>
http://news.povray.org/povray.text.tutorials/thread/%3C3f13449b$1@news.povray.org%3E/

This is fantastic -- IF I have to write a work around.

> Not sure if that helps at all.

I wouldn't have been even closely where to begin searching the archives. Much
thanks.

[[ What I really want is a way to keep track of a core object's location and
orientation as it becomes part of more complex objects ]]

What I am up to is modeling the ARP 2500 modular synthesizer.

https://encyclotronic.com/synthesizers/arp/2500-r167/

Instead of planting arbitrary knob positions and the matrix switch panels for
every instance of module, I used some data abstraction. An entire System is a
dictionary, divided into one or more cabinets filled with info on the modules'
state. For now the data structure is:

//=============Code==========

#declare System = dictionary {
  .ACabinet: array <mixed> [ slotsInCabinet ][ controlValues ] {
    // First slot
    { moduleID.float, panelSize.float, topJackPosition[20].{locVect, rotVect},
bottomJackPositions[20].{locVect, rotVect} }
    //  Middle slots
    { moduleID.float, panelSize.float, topSliderPositions[],
bottomSliderPositions[] }
   // Last slot, same as the first
  } // end of .ACabinet
.... more cabinets and components
} // end of System

[Bald Eagle] Re: array mixed crashes in parser [2463 days 6 hours and 28 minutes ago]

Thu, 11 Jul 2019 00:55:00 GMT

"TreeLimb Jim" <all### [at] yahoocom> wrote:

> During initial scene development I had complex sets of (single-type) arrays
> which became a nightmare to extend.

Are you aware of:
http://news.povray.org/povray.text.tutorials/thread/%3C3f13449b$1@news.povray.org%3E/

Not sure if that helps at all.

> I'd also be glad to create a mixed array and then initialize a dictionary
> element. That'll help debugging but not in the spirit of the outcome. It may
> soon be.
>
>
> > 3) those internal array declarations don't look right to me
>
> I'm not sure what you are referring to as 'internal' array declarations. I'll
> discuss the composition of this complex data type in a later posting.

IIRC, it looked like you were trying to declare a dictionary, composed of
arrays, that had elements, all in one go.

I was just looking at the syntax of the array declarations, and they didn't
strike me as "properly formed", but it was hard to puzzle out that little
snippet.

No worries - if what you have is working for you, then carry on!   :)

[TreeLimb Jim] Re: array mixed crashes in parser [2463 days 7 hours and 58 minutes ago]

Wed, 10 Jul 2019 23:25:00 GMT

"Bald Eagle" <cre### [at] netscapenet> wrote:
> 1) I'm not sure what the dots that look like an ellipsis are.

Three sequential dots are indeed ellipses. I posted a correction where there
were two dots in the initial post should have been whitespace followed by the
dot-prefixed naming convention.

> 2) I think it would be easier to declare a (very small) mixed array first and
> THEN create a dictionary for it

This would be a logical progression, with experimentation due.
I'd be glad to work with a mixed array data type and then to extend the code to
read it as a dictionary.
During initial scene development I had complex sets of (single-type) arrays
which became a nightmare to extend.

I'd also be glad to create a mixed array and then initialize a dictionary
element. That'll help debugging but not in the spirit of the outcome. It may
soon be.

> 3) those internal array declarations don't look right to me

I'm not sure what you are referring to as 'internal' array declarations. I'll
discuss the composition of this complex data type in a later posting.

>>> THIS IS CERTAIN <<<
They work fine and fantastic in Pov-Ray 3.8.0a.9844500. In fact, I'm continuing
developing the scene in 9844500/

Presently, with 9844500, the uninitialized { integer, integer, array[10],
array[10]} declaration of the first element of the dictionary, .LeftMain2515:
entry is now, for my purposes { integer, integer, array[20], array[20]}  and
works as interpreted by Reference:Array:

http://wiki.povray.org/content/Reference:Array

> 3) then you could see if you can create a dictionary using a direct declaration
> of the mixed array

This would be a logical progression, with experimentation due.

[Bald Eagle] Re: array mixed crashes in parser [2463 days 10 hours and 33 minutes ago]

Wed, 10 Jul 2019 20:50:00 GMT

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

> if there'd been a complete example.  :-(  anyway, I guess the OP will have
> solved the problem already.

Maybe.  The way I read his initial post was that he was trying to run an
"example snippet" - maybe from a file included with the distribution.

I looked in
/usr/share/qtpovray-3.8/scenes/language/arrays/
but nothing there had any mixed array or dictionary examples, but maybe I'm
looking in the wrong place.

The only things I found online were the wiki link I provided, and some example
code for _mixed_ by Ingo.

Maybe he will return with clarification and a solution...

[jr] Re: array mixed crashes in parser [2463 days 11 hours and 3 minutes ago]

Wed, 10 Jul 2019 20:20:02 GMT

hi,

"Bald Eagle" <cre### [at] netscapenet> wrote:
> I don't have any time to look at this, and array syntax can get picky even on a
> good day, I also have NO experience with dictionaries (perhaps jr can chime in
> here if he sees it) so just take a look at:

if there'd been a complete example.  :-(  anyway, I guess the OP will have
solved the problem already.

regards, jr.

[Bald Eagle] Re: array mixed crashes in parser [2463 days 21 hours and 3 minutes ago]

Wed, 10 Jul 2019 10:20:01 GMT

I don't have any time to look at this, and array syntax can get picky even on a
good day, I also have NO experience with dictionaries (perhaps jr can chime in
here if he sees it) so just take a look at:

http://wiki.povray.org/content/Reference:Array


1) I'm not sure what the dots that look like an ellipsis are.
2) I think it would be easier to declare a (very small) mixed array first and
THEN create a dictionary for it
3) those internal array declarations don't look right to me
3) then you could see if you can create a dictionary using a direct declaration
of the mixed array

[TreeLimb Jim] Re: array mixed crashes in parser [2464 days 2 hours and 8 minutes ago]

Wed, 10 Jul 2019 05:15:00 GMT

> #declare EmptySystem = dictionary  {
> ..LeftMain2515: array mixed[7][4] {
> ...

#declare EmptySystem = dictionary  {
   .LeftMain2515: array mixed[7][4] {
....

[TreeLimb Jim] array mixed crashes in parser [2465 days 6 hours and 48 minutes ago]

Tue, 9 Jul 2019 00:35:01 GMT

Dictionary and mixed arrays, what a pleasant adoption.

Developed my files with POV-Ray-3.8.0-alpha.9844500-avx

Running in POV-Ray-3.8.0-alpha.10013324-avx, the example snippet:

#declare EmptySystem = dictionary  {
..LeftMain2515: array mixed[7][4] {
{ 1001, 1, array[10] , array[10] },
{ 1001, 1, array[10] { 0,0,0,0,0, 0,0,0,0,0 }, array[10]{ 0,0,0,0,0, 0,0,0,0,0 }
},
{ 1001, 1, array[10] { 0,0,0,0,0, 0,0,0,0,0 }, array[10]{ 0,0,0,0,0, 0,0,0,0,0 }
},
....

provides an ungraceful exit from parsing:
Possible Parse Error: Uncategorized error thrown at
/Volumes/WDVrijstuk/PovRayUnofficial_3.8.0-alpha. 10013324-avx
source/source/parser/parser_tokenizer.cpp line 2413.

Fatal error in parser: Uncategorized error.


Tried some very simple implementations of array mixed to same result.


Using the OS X front end so I couldn't regress through the intermediate builds
and find where it broke.

[Mike Horvath] Re: Bug in screen.inc [2481 days 18 hours and 18 minutes ago]

Sat, 22 Jun 2019 13:05:04 GMT

Sorry, I will post an example scene later in the day when I get the chance.


Michael

[Mike Horvath] Re: Bug in screen.inc [2482 days 9 hours and 41 minutes ago]

Fri, 21 Jun 2019 21:41:56 GMT

On 6/20/2019 9:16 PM, Bald Eagle wrote:
> Mike Horvath <mik### [at] gmailcom> wrote:
> 
>> Can the camera itself scale by some value? Thanks for the tip.
> 
> I'm guessing ... yes?
> 
>
http://news.povray.org/povray.advanced-users/thread/%3C5a7f9271%241%40news.povray.org%3E/
> 
> 
> 
> 
> 

I also tried setting the aspect ratio to a negative value.

Set_Camera_Aspect(-4,3)

This flips the image correctly, but the text disappears. You can confirm 
this in the demo scene.

Michael

[Mike Horvath] Re: Bug in screen.inc [2483 days 4 hours and 49 minutes ago]

Fri, 21 Jun 2019 02:33:45 GMT

On 6/20/2019 9:16 PM, Bald Eagle wrote:
> Mike Horvath <mik### [at] gmailcom> wrote:
> 
>> Can the camera itself scale by some value? Thanks for the tip.
> 
> I'm guessing ... yes?
> 
>
http://news.povray.org/povray.advanced-users/thread/%3C5a7f9271%241%40news.povray.org%3E/
> 

I tried `scale <-1,1,1>` but it had the incorrect effect. It flipped the 
coordinate axes, not the actual image like what should happen.

Michael

[Bald Eagle] Re: Bug in screen.inc [2483 days 6 hours and 3 minutes ago]

Fri, 21 Jun 2019 01:20:00 GMT

Mike Horvath <mik### [at] gmailcom> wrote:

> Can the camera itself scale by some value? Thanks for the tip.

I'm guessing ... yes?

http://news.povray.org/povray.advanced-users/thread/%3C5a7f9271%241%40news.povray.org%3E/

[Mike Horvath] Re: Bug in screen.inc [2483 days 6 hours and 18 minutes ago]

Fri, 21 Jun 2019 01:04:49 GMT

On 6/20/2019 6:46 PM, Bald Eagle wrote:
> It's been a while since I've picked through the code of that, but:
> 
> Might the solution be as simple as taking all of the screen.inc output (union {}
> )
>   and scaling it <-1, 1, 1>  ?
> 
> 
> 

Can the camera itself scale by some value? Thanks for the tip.


Michael

[Bald Eagle] Re: Bug in screen.inc [2483 days 8 hours and 33 minutes ago]

Thu, 20 Jun 2019 22:50:01 GMT

Mike Horvath <mik### [at] gmailcom> wrote:
> The include file "screen.inc" can't cope whith a scene (such as some
> exported LDraw scenes) where the "right" vector of the camera is
> negative. For instance, I'm not sure why, but the program LDView always
> outputs the right vector as:
>
>  right LDXCamAspect * < -1,0,0 >
>
> The resulting image ends up flipped horizontally compared to what it's
> supposed to be.
>
> Michael

It's been a while since I've picked through the code of that, but:

Might the solution be as simple as taking all of the screen.inc output (union {}
)
 and scaling it <-1, 1, 1>  ?

[Mike Horvath] Bug in screen.inc [2483 days 14 hours and 16 minutes ago]

Thu, 20 Jun 2019 17:06:50 GMT

The include file "screen.inc" can't cope whith a scene (such as some 
exported LDraw scenes) where the "right" vector of the camera is 
negative. For instance, I'm not sure why, but the program LDView always 
outputs the right vector as:

	right LDXCamAspect * < -1,0,0 >

The resulting image ends up flipped horizontally compared to what it's 
supposed to be.

Michael

[jr] Re: file directory problem [2555 days 9 hours and 3 minutes ago]

Tue, 9 Apr 2019 22:20:00 GMT

hi,

clipka <ano### [at] anonymousorg> wrote:
> Am 08.04.2019 um 01:04 schrieb jr:
> > all_file = /tmp/render/sf/LOG
>
> Is there perhaps a directory named `LOG`?
>
> Also, what happens if you just specify `all_file=LOG`?

bingo.  'LOG' is created in same directory as frame_* files.  automatically.
nice.

thank you.

regards, jr.

[clipka] Re: file directory problem [2555 days 9 hours and 53 minutes ago]

Tue, 9 Apr 2019 21:30:12 GMT

Am 08.04.2019 um 01:04 schrieb jr:

> the .ini file contains (edited):
> 
> all_file = /tmp/render/sf/LOG

Is there perhaps a directory named `LOG`?

Also, what happens if you just specify `all_file=LOG`?

> output_file_name = /tmp/render/sf/frame_

Or is `frame_` perhaps a directory?

[jr] Re: file directory problem [2555 days 12 hours and 58 minutes ago]

Tue, 9 Apr 2019 18:25:05 GMT

hi,

Le_Forgeron <jgr### [at] freefr> wrote:
> >> Le 08/04/2019 ÃƒÂ  01:04, jr a
ÃƒÂ©critÃ‚Â :
> >>> Persistence of Vision(tm) Ray Tracer Version 3.8.0-alpha.10013324.unofficial
>
> which paths ?
> /usr/local/etc/povray/3.8 or
> /usr/local/etc/povray/3.7 ?

only 3.8 versions installed on this machine.


> Can you recompile with --enable-debug, and have a look at the start of
> the output when you launch povray ?

ok.  will do, next couple of days or so.  thanks.


regards, jr.

[Le Forgeron] Re: file directory problem [2555 days 13 hours and 56 minutes ago]

Tue, 9 Apr 2019 17:26:52 GMT

Le 09/04/2019 Ã  15:02, jr a Ã©critÂ :
> hi,
> 
> Le_Forgeron <jgr### [at] freefr> wrote:
>> Le 08/04/2019 ÃƒÂ  01:04, jr a
ÃƒÂ©critÃ‚Â :
>>> Persistence of Vision(tm) Ray Tracer Version 3.8.0-alpha.10013324.unofficial
>>> ....
>>> Stream output files must reside in same directory as image output file.
>>> Render failed
> 
>> Basic problem due to IO restrictions being active (default).
> 
> for laughs I changed 'File I/O Security' to 'none' in both the site-wide and the
> personal configuration files.  no dice.  same error, even though both stream +
> image output files would "reside in same directory".
> 

which paths ?

/usr/local/etc/povray/3.8 or
/usr/local/etc/povray/3.7 ?

Can you recompile with --enable-debug, and have a look at the start of
the output when you launch povray ?

I have that:

PATHS
  HOME        = /home/jerome
  SYSCONF     = /usr/local/etc/povray/3.8/povray.conf
  USERCONF    = /home/jerome/.povray/3.8/povray.conf
  SYSINI      = /usr/local/etc/povray/3.8/povray.ini
  SYSINI_OLD  = /usr/local/etc/povray.ini
  USERINI     = /home/jerome/.povray/3.8/povray.ini
  USERINI_OLD = /home/jerome/.povrayrc
PARSE CONF '/usr/local/etc/povray/3.8/povray.conf'
  CANONICALIZE '%INSTALLDIR%/include/'
    su: /usr/local/share/povray-3.8/include/
    su: /usr/local/share/povray-3.8/include/
    su: /usr/local/share/povray-3.8/include/
    su: /usr/local/share/povray-3.8/include/
PERMITTED ADD '/usr/local/share/povray-3.8/include/'
  CANONICALIZE '%INSTALLDIR%/scenes/'
    su: /usr/local/share/povray-3.8/scenes/
    su: /usr/local/share/povray-3.8/scenes/
    su: /usr/local/share/povray-3.8/scenes/
    su: /usr/local/share/povray-3.8/scenes/
PERMITTED ADD '/usr/local/share/povray-3.8/scenes/'
  CANONICALIZE '%INSTALLDIR%/../../etc/'
    su: /usr/local/share/povray-3.8/../../etc/
    su: /usr/local/share/povray-3.8/../../etc/
    su: /usr/local/share/povray-3.8/../../etc/
    su: /usr/local/share/povray-3.8/../../etc/
    su: /usr/local/share/../etc/
PERMITTED ADD '/usr/local/share/../etc/'
  CANONICALIZE '%HOME%/'
    su: %HOME%/
    su: /home/jerome/
    su: /home/jerome/
    su: /home/jerome/
PERMITTED ADD '/home/jerome/'
  CANONICALIZE '/tmp/'
    su: /tmp/
    su: /tmp/
    su: /tmp/
    su: /tmp/
PERMITTED ADD '/tmp/'
  CANONICALIZE './'
    su: ./
    su: ./
    su: ./
    su: ./
PERMITTED ADD '/usr/local/etc/povray/3.8/'
I/O RESTRICTIONS
  file_io  = 0	config->file_io  = 0
  shellout = 1	config->shellout = 1
PARSE CONF '/home/jerome/.povray/3.8/povray.conf'
  CANONICALIZE '%INSTALLDIR%/include/'
    su: /usr/local/share/povray-3.8/include/
    su: /usr/local/share/povray-3.8/include/
    su: /usr/local/share/povray-3.8/include/
    su: /usr/local/share/povray-3.8/include/
PERMITTED ADD '/usr/local/share/povray-3.8/include/'
  CANONICALIZE '%INSTALLDIR%/scenes/'
    su: /usr/local/share/povray-3.8/scenes/
    su: /usr/local/share/povray-3.8/scenes/
    su: /usr/local/share/povray-3.8/scenes/
    su: /usr/local/share/povray-3.8/scenes/
PERMITTED ADD '/usr/local/share/povray-3.8/scenes/'
  CANONICALIZE '%INSTALLDIR%/../../etc/'
    su: /usr/local/share/povray-3.8/../../etc/
    su: /usr/local/share/povray-3.8/../../etc/
    su: /usr/local/share/povray-3.8/../../etc/
    su: /usr/local/share/povray-3.8/../../etc/
    su: /usr/local/share/../etc/
PERMITTED ADD '/usr/local/share/../etc/'
  CANONICALIZE '%HOME%/'
    su: %HOME%/
    su: /home/jerome/
    su: /home/jerome/
    su: /home/jerome/
PERMITTED ADD '/home/jerome/'
  CANONICALIZE '/tmp/'
    su: /tmp/
    su: /tmp/
    su: /tmp/
    su: /tmp/
PERMITTED ADD '/tmp/'
  CANONICALIZE './'
    su: ./
    su: ./
    su: ./
    su: ./
PERMITTED ADD '/usr/local/etc/povray/3.8/'
I/O RESTRICTIONS
  file_io  = 0	config->file_io  = 0
  shellout = 2	config->shellout = 2
PERMITTED PATHS
  READ* = "/usr/local/share/povray-3.8/include/"
  READ* = "/usr/local/share/povray-3.8/scenes/"
  READ* = "/usr/local/share/../etc/"
  READ* = "/home/jerome/"
  WRITE* = "/tmp/"
  WRITE = "/home/jerome/"
OPTIONS (6)
  version = off(--version|-version|--V, )
  temppath = (, POV_TEMP_DIR)
  help = off(--help|-help|-h|-?, )
  generation = off(--generation, )
  benchmark = off(--benchmark|-benchmark, )
  scaled = on(, POV_DISPLAY_SCALED)



> 
> regards, jr.
> 
>

[jr] Re: file directory problem [2555 days 18 hours and 18 minutes ago]

Tue, 9 Apr 2019 13:05:00 GMT

hi,

Le_Forgeron <jgr### [at] freefr> wrote:
> Le 08/04/2019 Ã  01:04, jr a Ã©critÂ :
> > Persistence of Vision(tm) Ray Tracer Version 3.8.0-alpha.10013324.unofficial
> > ....
> > Stream output files must reside in same directory as image output file.
> > Render failed

> Basic problem due to IO restrictions being active (default).

for laughs I changed 'File I/O Security' to 'none' in both the site-wide and the
personal configuration files.  no dice.  same error, even though both stream +
image output files would "reside in same directory".

regards, jr.

[jr] Re: file directory problem [2556 days 15 hours and 8 minutes ago]

Mon, 8 Apr 2019 16:15:00 GMT

hi,

Le_Forgeron <jgr### [at] freefr> wrote:
> Le 08/04/2019 Ã  01:04, jr a Ã©critÂ :
> > Stream output files must reside in same directory as image output file.
>
> Basic problem due to IO restrictions being active (default).
>
> Well, not a real problem, works as intended, to protect the innocents.

fingers crossed.  :-)

> see ...
> So, as the message can be read: your log file must be in the same
> directory as the image output file.
>
> you need to tune the configuration of the io-restrictions to be more
> relaxed.

so this is the private 'povray.conf':
; POV-Ray 3.8
[File I/O Security]
restricted
[Shellout Security]
allowed
[Permitted Paths]
read* = /usr/share/fonts/local
read* = %INSTALLDIR%/include
read* = %INSTALLDIR%/scenes
read* = %INSTALLDIR%/extra
read+write* = /tmp
read+write* = %HOME%


and /tmp and its descendants work.  usually.  what needs to be relaxed?


regards, jr.

[Le Forgeron] Re: file directory problem [2556 days 15 hours and 34 minutes ago]

Mon, 8 Apr 2019 15:48:48 GMT

Le 08/04/2019 Ã  01:04, jr a Ã©critÂ :
> hi,
> 
> getting an error I cannot understand.
> 
> Script started on Sun 07 Apr 2019 23:52:16 BST
> jr@crow:1:sinkflip$ pov38 sf2b1
> Persistence of Vision(tm) Ray Tracer Version 3.8.0-alpha.10013324.unofficial
> ....
> Rendering frame 1 of 72 (#0)
> 
> Rendering frame 1 of 72 (#0)
> 
> 
> Stream output files must reside in same directory as image output file.
> Stream output files must reside in same directory as image output file.
> Render failed
> 
> 

Basic problem due to IO restrictions being active (default).

Well, not a real problem, works as intended, to protect the innocents.

see
http://wiki.povray.org/content/Documentation:Unix_Section_4#I.2FO_Restrictions

> http://wiki.povray.org/content/Documentation:Unix_Section_4#I.2FO_Restrictions

So, as the message can be read: your log file must be in the same
directory as the image output file.

you need to tune the configuration of the io-restrictions to be more
relaxed.

I live in a dangerous world, my default compilation option is
--disable-io-restrictions, but that's me, and it might not be good for all.

> 
> the .ini file contains (edited):
> 
> all_file = /tmp/render/sf/LOG
> 
> initial_frame = 0
> final_frame = 71
> 
> input_file_name = sf2b1.pov
> 
> output_file_name = /tmp/render/sf/frame_
> 
> 
> regards, jr.
> 
>

[jr] file directory problem [2557 days 8 hours and 18 minutes ago]

Sun, 7 Apr 2019 23:05:00 GMT

hi,

getting an error I cannot understand.

Script started on Sun 07 Apr 2019 23:52:16 BST
jr@crow:1:sinkflip$ pov38 sf2b1
Persistence of Vision(tm) Ray Tracer Version 3.8.0-alpha.10013324.unofficial
....
Rendering frame 1 of 72 (#0)

Rendering frame 1 of 72 (#0)


Stream output files must reside in same directory as image output file.
Stream output files must reside in same directory as image output file.
Render failed



the .ini file contains (edited):

all_file = /tmp/render/sf/LOG

initial_frame = 0
final_frame = 71

input_file_name = sf2b1.pov

output_file_name = /tmp/render/sf/frame_


regards, jr.

[William F Pokorny] Re: Parseerror:Uncategorizederrorthrownatparser/... [2566 days 16 hours and 51 minutes ago]

Fri, 29 Mar 2019 14:31:49 GMT

On 3/28/19 6:49 AM, William F Pokorny wrote:
> On 3/26/19 8:10 AM, clipka wrote:
...
> 
> Second, on enabling the POV_ASSERT source code mechanism, took the time 
> to do some full compiles with a known fail assert of 1 == 0 and the 
> short of it for *nix is doing something like:
> 
> ./configure COMPILED_BY="wfp__POV_DEBUG" CXXFLAGS="-DPOV_DEBUG"
> 
> works. 
...
> 

With the thought I might help others doing debug by rambling more about 
my ignorance/learning while attempting to debug this issue...

Woke up this morning remembering seeing a core file when I did my 
POV_ASSERT(1 == 0) test with a compile where POV_DEBUG was really 
defined. This got me wondering why I didn't get a core file with initial 
failing code here given an assert ran and I did a debug compile. A core 
file would have have made it easy to look at the call stack with gdb.

Well, looking at the source code this morning it's because we have this 
set up today for the parser related asserts in ./parser/configparser.h :

#ifndef POV_PARSER_DEBUG
     #define POV_PARSER_DEBUG POV_DEBUG
#endif

...

#if POV_PARSER_DEBUG
     #define POV_PARSER_ASSERT(expr) POV_ASSERT_HARD(expr)
#else
     #define POV_PARSER_ASSERT(expr) POV_ASSERT_SOFT(expr)
                                  // POV_ASSERT_DISABLE(expr)
#endif

I wasn't previously getting POV_DEBUG set so I was getting a soft assert 
which parse.cpp catches triggering a more graceful - but less 
informative (no core file) - program exit. Trying my debug compile again 
just now with POV_DEBUG set, I do get a core file and gdb gives me :

     ...
#4  0x000055a82da4b703 in pov_parser::LexemePosition::operator==
     o=...) at parser/parsertypes.cpp:62
#5  0x000055a82da40420 in pov_parser::Parser::IsEndOfInvokedMacro
     at parser/parser_tokenizer.cpp:964
#6  0x000055a82da44dcd in pov_parser::Parser::Get_Token
     at parser/parser_tokenizer.cpp:289
#7  0x000055a82da05cf7 in pov_parser::Parser::Parse_Frame
     at parser/parser.cpp:6559
#8  0x000055a82da06591 in pov_parser::Parser::Run
     at parser/parser.cpp:242
#9  0x000055a82d9cb3ef in pov::ParserTask::Run
     at backend/control/parsertask.cpp:81
...

Today, I'd find my way to IsEndOfInvokedMacro in less than an hour 
instead of the full day it took me to trace top down - so to speak.

The lessons I learned: Get POV_DEBUG set in your compile while debugging 
any issue. If still no core file generated and tangled in a POV-Ray code 
assert, be sure you're getting a hard assert and not a soft one. I 
didn't know we had 'soft' POV_ASSERT* version until today.

Bill P.

[William F Pokorny] Re: Parseerror:Uncategorizederrorthrownatparser/... [2567 days 20 hours and 33 minutes ago]

Thu, 28 Mar 2019 10:49:32 GMT

On 3/26/19 8:10 AM, clipka wrote:
> Am 26.03.2019 um 11:46 schrieb William F Pokorny:
> 
>> Quick additional question. Is it the --enable-debug configure flag 
>> that - normally - turns on the pov asserts? I've never verified this 
>> assumption of mine by creating a pov assert in the code I know should 
>> fail.
> 
> To be honest, I haven't a clue. I'm not sure what the `--enable-debug` 
> flag does exactly (it's some standard mechanism in the Automake tools), 
> nor whether and how assertions are enabled or disabled in Unix builds.
> 
> I'm pretty sure that `--enable-debug` does enable the creation of debug 
> information in the binaries, so that a debugging tool can correlate 
> binary code addresses with original source code lines, so that you can 
> e.g. set breakpoints and step through the code line by line with a 
> debugger. I also wouldn't be surprised if it turns off optimizations by 
> default, because those tend to re-order instructions and make a 
> line-by-line correlation impossible. Whether it does anything beyond 
> that I do not know. It might dictate whether `NDEBUG` is defined or not, 
> which would conceivably disable/enable assertions.

Back at it this morning.

First, flipping the file name compare so it's ahead of the file position 
compare (and assert) works fine too with all the test cases I have that 
fail.

Second, on enabling the POV_ASSERT source code mechanism, took the time 
to do some full compiles with a known fail assert of 1 == 0 and the 
short of it for *nix is doing something like:

./configure COMPILED_BY="wfp__POV_DEBUG" CXXFLAGS="-DPOV_DEBUG"

works. The -D<var> form on the define is added as a compiler flag to do 
the POV_DEBUG define, which, turns on the POV asserts that exist in the 
code (except I guess where not otherwise controlled or hard-set).

Lastly, on the --enable-debug flag, it is not today defining POV_DEBUG 
which is what turns on the POV_ASSERTs. Most of my actual debug compiles 
use a configure command like:

./configure COMPILED_BY="wfp" --disable-optimiz --disable-strip \ 
CXXFLAGS="-Og -ggdb fverbose-asm"

so --enable-debug isn't strictly needed for debugging though on line 
documentation I read just now indicates - by default anyway - it does 
something equivalent given certain arguments. Looks like you can select 
what sort of debugging gets turned on - and you can provide a second 
argument defining variables explicitly (ie POV_DEBUG) and there is the 
NDEBUG you mentioned (boost seems to use this some) getting set by 
default if the flag's argument turns debugging off (or the flag's not 
used but enabled?). What some documentation says only; Not sure what 
works or not for --enable-debug with our current set up without doing a 
bunch of compiles and tests. An investigation for another time. The flag 
doesn't control the POV_ASSERTs today via NDEBUG in any case - so at 
best it might provide another way to define POV_DEBUG using that second 
argument.

Bill P.

[clipka] Re: Parse error:Uncategorizederrorthrownatparser... [2569 days 19 hours and 12 minutes ago]

Tue, 26 Mar 2019 12:10:24 GMT

Am 26.03.2019 um 11:46 schrieb William F Pokorny:

> Quick additional question. Is it the --enable-debug configure flag that 
> - normally - turns on the pov asserts? I've never verified this 
> assumption of mine by creating a pov assert in the code I know should fail.

To be honest, I haven't a clue. I'm not sure what the `--enable-debug` 
flag does exactly (it's some standard mechanism in the Automake tools), 
nor whether and how assertions are enabled or disabled in Unix builds.

I'm pretty sure that `--enable-debug` does enable the creation of debug 
information in the binaries, so that a debugging tool can correlate 
binary code addresses with original source code lines, so that you can 
e.g. set breakpoints and step through the code line by line with a 
debugger. I also wouldn't be surprised if it turns off optimizations by 
default, because those tend to re-order instructions and make a 
line-by-line correlation impossible. Whether it does anything beyond 
that I do not know. It might dictate whether `NDEBUG` is defined or not, 
which would conceivably disable/enable assertions.

[William F Pokorny] Re: Parse error: Uncategorizederrorthrownatparse... [2569 days 20 hours and 37 minutes ago]

Tue, 26 Mar 2019 10:46:20 GMT

On 3/25/19 7:41 PM, clipka wrote:
> Am 25.03.2019 um 23:55 schrieb clipka:
> 
>> If `Cond_Stack.back().PMac->endPosition == CurrentFilePosition()` 
>> throws an exception, it means either of two things:
>>
>> (A) The positions compared are from two different files, which means 
>> the calling code has failed to check whether it is even in the right 
>> file.
>>
>> (B) The line/column tracking is buggy, and yields different positions 
>> in different situations.
> 
> 
> Well, looking at the code of `IsEndOfInvokedMacro()` again, it 
> _strongly_ reeks of scenario (A):
> 
>  Â Â Â  return (Cond_Stack.back().PMac->endPosition ==
> 
Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â 
CurrentFilePosition()) &&
> 
Â Â Â Â Â Â Â Â Â Â 
(Cond_Stack.back().PMac->source.fileName ==
> 
Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â 
mTokenizer.GetInputStreamName());
> 
> should probably be swapped around, like so:
> 
>  Â Â Â  return
(Cond_Stack.back().PMac->source.fileName ==
> 
Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â 
mTokenizer.GetInputStreamName()) &&
> 
Â Â Â Â Â Â Â Â Â Â 
(Cond_Stack.back().PMac->endPosition ==
> 
Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â 
CurrentFilePosition());
> 
> so that the `LexemePosition` comparison operator is only invoked if the 
> file names match.
> 
> 
> I guess you got really lucky in your test (and the OP unlucky in their 
> use case), in that you happen to have created the following scenario:
> 
> - A macro is invoked.
> - That macro includes a different file.
> - That included file happens to have a `#` (e.g. `#declare`) at the same 
> file offset as the `#end` of the macro.
> - However, the `#` happens to be in a different line and/or column.
> 
> 
> In such a scenario, encountering the `#`, the parser would first test 
> whether this is the `#end` of the macro it has been waiting for, calling 
> `IsEndOfInvokedMacro()`.
> 
> `IsEndOfInvokedMacro()` in turn would checks whether the current file 
> position matches that of the macro's `#end` by calling 
> `LexemePostition::operator==`.
> 
> `LexemePostition::operator==` in turn would find that the file position 
> does match. It would then verify that the match also reflects in line 
> and column, and find that they differ, and report this inconsistency via 
> an Exception.
> 
> `IsEndOfInvokedMacro()` wouldn't even get a chance to test whether it is 
> looking at the right file, because its author (duh, I wonder who that 
> stupid git might have been...) chose to do the two tests in the wrong 
> order.
> 
> 
> Now aside from the stupid git who authored `IsEndOfInvokedMacro()` 
> there's someone else to blame for the situation, namely whoever thought 
> it was a good idea to keep the stack of include files separate from the 
> stack of pending "conditions". If they were using one and the same 
> structure, having `INVOKING_MACRO_COND` on top of the stack would imply 
> that we're in the file with the `#end`, and the file name test would be 
> redundant.
> 
> I think it should be possible to merge the include stack into the 
> "condition" stack without adverse effects, but I haven't finished work 
> on that yet.
> 
> 
> I should note that I haven't tested this hypothesis and fix for the 
> error yet; I intend to do that as soon as I find the time, but of course 
> you're welcome to beat me to it.

Thanks for the detailed explanations and, though I'm busy with RL 
starting in a little while today, I think you've figured it out.

I know from looking at the values the position was matching and the line 
and column were not. Further, when I look at my test cases (all some 
pretty close variation of Warren's original) the failing ones all have 
the # of the declare in just the right spot as you suggested. I'd not 
recognized this was so.

My patch, then, just avoided the assertion in the 
LexemePosition::operator== I suppose. I also didn't know the parser 
assertions were today on always and I wasn't thinking an assert could 
cause the exception.

Quick additional question. Is it the --enable-debug configure flag that 
- normally - turns on the pov asserts? I've never verified this 
assumption of mine by creating a pov assert in the code I know should 
fail.

Bill P.

[clipka] Re: Parse error: Uncategorizederrorthrownatparse... [2570 days 7 hours and 41 minutes ago]

Mon, 25 Mar 2019 23:41:39 GMT

Am 25.03.2019 um 23:55 schrieb clipka:

> If `Cond_Stack.back().PMac->endPosition == CurrentFilePosition()` throws 
> an exception, it means either of two things:
> 
> (A) The positions compared are from two different files, which means the 
> calling code has failed to check whether it is even in the right file.
> 
> (B) The line/column tracking is buggy, and yields different positions in 
> different situations.


Well, looking at the code of `IsEndOfInvokedMacro()` again, it 
_strongly_ reeks of scenario (A):

     return (Cond_Stack.back().PMac->endPosition ==
                 CurrentFilePosition()) &&
            (Cond_Stack.back().PMac->source.fileName ==
                 mTokenizer.GetInputStreamName());

should probably be swapped around, like so:

     return (Cond_Stack.back().PMac->source.fileName ==
                 mTokenizer.GetInputStreamName()) &&
            (Cond_Stack.back().PMac->endPosition ==
                 CurrentFilePosition());

so that the `LexemePosition` comparison operator is only invoked if the 
file names match.


I guess you got really lucky in your test (and the OP unlucky in their 
use case), in that you happen to have created the following scenario:

- A macro is invoked.
- That macro includes a different file.
- That included file happens to have a `#` (e.g. `#declare`) at the same 
file offset as the `#end` of the macro.
- However, the `#` happens to be in a different line and/or column.


In such a scenario, encountering the `#`, the parser would first test 
whether this is the `#end` of the macro it has been waiting for, calling 
`IsEndOfInvokedMacro()`.

`IsEndOfInvokedMacro()` in turn would checks whether the current file 
position matches that of the macro's `#end` by calling 
`LexemePostition::operator==`.

`LexemePostition::operator==` in turn would find that the file position 
does match. It would then verify that the match also reflects in line 
and column, and find that they differ, and report this inconsistency via 
an Exception.

`IsEndOfInvokedMacro()` wouldn't even get a chance to test whether it is 
looking at the right file, because its author (duh, I wonder who that 
stupid git might have been...) chose to do the two tests in the wrong order.


Now aside from the stupid git who authored `IsEndOfInvokedMacro()` 
there's someone else to blame for the situation, namely whoever thought 
it was a good idea to keep the stack of include files separate from the 
stack of pending "conditions". If they were using one and the same 
structure, having `INVOKING_MACRO_COND` on top of the stack would imply 
that we're in the file with the `#end`, and the file name test would be 
redundant.

I think it should be possible to merge the include stack into the 
"condition" stack without adverse effects, but I haven't finished work 
on that yet.


I should note that I haven't tested this hypothesis and fix for the 
error yet; I intend to do that as soon as I find the time, but of course 
you're welcome to beat me to it.

[clipka] Re: Parse error: Uncategorized errorthrownatpars... [2570 days 8 hours and 27 minutes ago]

Mon, 25 Mar 2019 22:55:29 GMT

Am 24.03.2019 um 15:59 schrieb William F Pokorny:

> That was painful to run down, but changing Parser::IsEndOfInvokedMacro() 
> in the file source/parser/parser_tokenizer.cpp as in the attached file 
> fixes the issue.

Well, that's a lead I might investigate. But as you don't seem to be 
confidently understanding what's going on, I'll be going with the 
presumption that this is not a proper fix but just a patch.

> Have to admit I'm not sure even now I completely understand what was 
> happening (how it could happen perhaps). We seem to have been comparing 
> structures in the original - which I don't think c++ does by default?
> 
> return (Cond_Stack.back().PMac->endPosition ==
> CurrentFilePosition()) && ...
> 
> If this true though, why no compile warning or error?

That's easily explained: The data is of type `LexemePosition`, which is 
a struct defining an overloaded comparison operator.

(In C++, structs and classes are the same category of beasts. The only 
semantic difference between `struct` and `class` is the default member 
and base class access: `struct` implies `public` by default, while 
`class` implies `private` by default. According to the language 
standard, it is even perfectly valid to pre-declare a type as `struct` 
and later define it as `class` or vice versa.)

The `LexemePosition` type holds a file offset, as well as a line and 
column number.

Comparison is done by file offset, but the code also features an 
assertion, which tests whether the comparison by line and column yields 
the same result. If the assertion fails, debug builds bomb (i.e. core 
dump or break into a debugger), and non-debug builds throw an exception 
to trigger a parse error.

(Usually such assertion tests are only enabled in debug builds, but in 
the parser they're currently deliberately enabled in all builds, because 
I don't fully trust my current understanding of the parser and the 
refactoring work I have based on that understanding.)

If `Cond_Stack.back().PMac->endPosition == CurrentFilePosition()` throws 
an exception, it means either of two things:

(A) The positions compared are from two different files, which means the 
calling code has failed to check whether it is even in the right file.

(B) The line/column tracking is buggy, and yields different positions in 
different situations.


> In any case, once 
> in a while on the structure compare some error got thrown and caught by 
> the parser code and no message was set which is why we get the unhelpful 
> generic something wrong message.

This is the default error message for failed assertions. Unfortunately 
somewhere along the chain of error message handling the location 
information for the assertion seems to be lost, the original exception 
should include the nformation that it was triggered in `parsertypes.h` 
line 62 (in my version of the file at any rate), maybe even that it was 
in function `LexemePosition::operator==` (depending on compiler). Maybe 
it's worth investigating and fixing that.

[William F Pokorny] Re: Parse error: Uncategorized error thrownatpar... [2571 days 16 hours and 24 minutes ago]

Sun, 24 Mar 2019 14:59:02 GMT

On 3/22/19 6:44 AM, William F Pokorny wrote:
> On 3/21/19 3:18 PM, clipka wrote:
>> Am 20.03.2019 um 19:27 schrieb William F Pokorny:
>>
> ...
>>
>> Can't reproduce on Windows; neither with DOS line endings (CR+LF) nor 
>> with Unix line endings (LF).
>>
>> I'm running a slightly modified version, but if any of those 
>> modifications make any difference, I wouldn't know which ones.
>>
>> Do you have the time and energy to investigate this further?
> 
> Not today with a family visit later, but I'll put it on the list to play 
> with the issue more this weekend.
> 
> 

That was painful to run down, but changing Parser::IsEndOfInvokedMacro() 
in the file source/parser/parser_tokenizer.cpp as in the attached file 
fixes the issue.

Have to admit I'm not sure even now I completely understand what was 
happening (how it could happen perhaps). We seem to have been comparing 
structures in the original - which I don't think c++ does by default?

return (Cond_Stack.back().PMac->endPosition ==
CurrentFilePosition()) && ...

If this true though, why no compile warning or error? In any case, once 
in a while on the structure compare some error got thrown and caught by 
the parser code and no message was set which is why we get the unhelpful 
generic something wrong message. Mostly calls to the compare above 
seemed to work - including ones prior to the failing one for the test 
case - returning false always.

I'm tempted to add a throw on a true test for the re-coded version then 
run a bunch of stuff to see if it true ever really happens. Have we been 
doing something like comparing pointers (and so false) always? But, I've 
already spent a day on this and I don't feel like spending additional 
time.

For the particular test cases you can also hard code that function to 
return false always and things work because that test is always false 
for it.

Lastly, I did try a debug -Og compile thinking maybe we had some 
compiler issue here, but it failed in the same way.

Anyone who better understands what happened / how direct struct compares 
could sort of seem to work, please feel free to jump in and explain.

Bill P.

[William F Pokorny] Re: Parse error: Uncategorized error thrown atpa... [2573 days 20 hours and 38 minutes ago]

Fri, 22 Mar 2019 10:44:33 GMT

On 3/21/19 3:18 PM, clipka wrote:
> Am 20.03.2019 um 19:27 schrieb William F Pokorny:
> 
...
> 
> Can't reproduce on Windows; neither with DOS line endings (CR+LF) nor 
> with Unix line endings (LF).
> 
> I'm running a slightly modified version, but if any of those 
> modifications make any difference, I wouldn't know which ones.
> 
> Do you have the time and energy to investigate this further?

Not today with a family visit later, but I'll put it on the list to play 
with the issue more this weekend.

Bill P.

[clipka] Re: Parse error: Uncategorized error thrown at p... [2574 days 12 hours and 4 minutes ago]

Thu, 21 Mar 2019 19:18:32 GMT

Am 20.03.2019 um 19:27 schrieb William F Pokorny:

> I can confirm the v38 issue. Also running Ubuntu 18.04 though g++7 vs 
> Warren's 8.
> 
> It seems the v3.8 branch (commit 74b3ebe) needs a space ahead of the 
> macro #end statement to work as follows:
> 
> #macro LoadThing(filePath)
>  Â Â Â  #include filePath
> 
Â #endÂ Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â 
// <-- Add extra space before #end and OK
> 
> LoadThing("zoomBangCrash.inc")
> 
> and whenever the include file has an empty line, C++ comment style line, 
> C++ comment line and then a declare line. The following for 
> zoomBangCrash.inc, less the line numbers, is also a v3.8 parse issue if 
> there is no space ahead of the main file macro #end:
> 
> 01
> 02 //
> 03 //
> 04 #declare A=1;

Can't reproduce on Windows; neither with DOS line endings (CR+LF) nor 
with Unix line endings (LF).

I'm running a slightly modified version, but if any of those 
modifications make any difference, I wouldn't know which ones.

Do you have the time and energy to investigate this further?

[Warren] Re: Parse error: Uncategorized error thrown at p... [2574 days 12 hours and 58 minutes ago]

Thu, 21 Mar 2019 18:25:00 GMT

William F Pokorny <ano### [at] anonymousorg> wrote:
> On 3/19/19 4:01 PM, Warren wrote:
> > Hello / Hi
> > I have installed PovRay 3.8.0-x.10064738.unofficial last sunday on Ubuntu with
> > the sources compilation.
> > To easily switch between several povray versions I have the following files in
> > 'usr/local/bin' :
> > 'povray3-7' which is the binary of the stable 3.7 branch
> > 'povray3-8' which is the binary of the 3.8.0[etc] described above
> > and a file 'povray' which is a symbolic link that can point to one of the two
> > binaries above.
> >
> > I have a scene that renders with povray 3.7 but doesn't with v3.8.
> > With the 3.8 version, povray outputs the following message in the console:
> >
> ...
> >
>
> I can confirm the v38 issue. Also running Ubuntu 18.04 though g++7 vs
> Warren's 8.
>
> It seems the v3.8 branch (commit 74b3ebe) needs a space ahead of the
> macro #end statement to work as follows:
>
> #macro LoadThing(filePath)
>      #include filePath
>   #end                 // <-- Add extra space before #end and OK
>
> LoadThing("zoomBangCrash.inc")
>
> and whenever the include file has an empty line, C++ comment style line,
> C++ comment line and then a declare line. The following for
> zoomBangCrash.inc, less the line numbers, is also a v3.8 parse issue if
> there is no space ahead of the main file macro #end:
>
> 01
> 02 //
> 03 //
> 04 #declare A=1;
>
> Perturb the include much and things work whether there is a space before
> the macro #end or not. Change the #declare A=1; to #declare Sphere00 =
> sphere { 0, 1 } for example and things are fine.
>
> Bill P.

Hello / Hi
I made the changes you suggested and everything works fine now (I get all the
textures I normally have when I use v3.7 but with the v3.8 this time). In fact,
I use the v3.8 because there's a bug in the v3.7 with the conic_sweep prisms
when the camera is orthographic and its direction perpendicular to the caps of
the pyramid ( I posted a message about this bug some time ago, it seemed povray
3.7 fail to find roots ). Thank you for your support :-D

[William F Pokorny] Re: Parse error: Uncategorized error thrown at p... [2575 days 12 hours and 55 minutes ago]

Wed, 20 Mar 2019 18:27:33 GMT

On 3/19/19 4:01 PM, Warren wrote:
> Hello / Hi
> I have installed PovRay 3.8.0-x.10064738.unofficial last sunday on Ubuntu with
> the sources compilation.
> To easily switch between several povray versions I have the following files in
> 'usr/local/bin' :
> 'povray3-7' which is the binary of the stable 3.7 branch
> 'povray3-8' which is the binary of the 3.8.0[etc] described above
> and a file 'povray' which is a symbolic link that can point to one of the two
> binaries above.
> 
> I have a scene that renders with povray 3.7 but doesn't with v3.8.
> With the 3.8 version, povray outputs the following message in the console:
> 
...
> 

I can confirm the v38 issue. Also running Ubuntu 18.04 though g++7 vs 
Warren's 8.

It seems the v3.8 branch (commit 74b3ebe) needs a space ahead of the 
macro #end statement to work as follows:

#macro LoadThing(filePath)
     #include filePath
  #end                 // <-- Add extra space before #end and OK

LoadThing("zoomBangCrash.inc")

and whenever the include file has an empty line, C++ comment style line, 
C++ comment line and then a declare line. The following for 
zoomBangCrash.inc, less the line numbers, is also a v3.8 parse issue if 
there is no space ahead of the main file macro #end:

01
02 //
03 //
04 #declare A=1;

Perturb the include much and things work whether there is a space before 
the macro #end or not. Change the #declare A=1; to #declare Sphere00 = 
sphere { 0, 1 } for example and things are fine.

Bill P.

[Warren] Parse error: Uncategorized error thrown at pars... [2576 days 11 hours and 18 minutes ago]

Tue, 19 Mar 2019 20:05:01 GMT

Hello / Hi
I have installed PovRay 3.8.0-x.10064738.unofficial last sunday on Ubuntu with
the sources compilation.
To easily switch between several povray versions I have the following files in
'usr/local/bin' :
'povray3-7' which is the binary of the stable 3.7 branch
'povray3-8' which is the binary of the 3.8.0[etc] described above
and a file 'povray' which is a symbolic link that can point to one of the two
binaries above.

I have a scene that renders with povray 3.7 but doesn't with v3.8.
With the 3.8 version, povray outputs the following message in the console:

==== [Parsing...] ==========================================================
File 'trees/kapok.tree' line 4: Possible Parse Error: Uncategorized error thrown
 at parser/parsertypes.cpp line 62.
Fatal error in parser: Uncategorized error.
Render failed

And I don't know how to solve this problem, even after parsing by myself
'kapok.tree' file.

Here is the output of the frist lines of 'kapok.tree' :
// TREE_NAME=Defaut;
//ROOT
#declare ROOTS=4;
#declare ROOT_RANDOM=13;
#declare FIRST_ROOT_AT_TRUNK=70;
#declare ROOT_LENGTH=200;
#declare ROOT_THICKNESS_CHANGE=0.85;

-----------------
In the pov file I have this line that loads 'kapok.tree' :
LoadTree("trees/kapok.tree")

And the 'LoadTree()' macro is defined like that :
#macro LoadTree(filePath)
 #include filePath
 #include "povtree/TOMTREE-1.5.inc"
#end

---------------
When I input 'povray --version' in the console, I have the following output:

POV-Ray 3.8.0-x.10064738.unofficial

This is an unofficial version compiled by:
 Antoine FAURE <https://www.ant01.fr>
 The POV-Ray Team is not responsible for supporting this version.

Copyright 1991-2019 Persistence of Vision Raytracer Pty. Ltd.
This is free software; see the source for copying conditions.  There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.

Built-in features:
  I/O restrictions:          enabled
  X Window display:          enabled (using SDL)
  Supported image formats:   gif tga iff ppm pgm hdr png jpeg tiff openexr
  Unsupported image formats: -

Compilation settings:
  Build architecture:  x86_64-pc-linux-gnu
  Built/Optimized for: x86_64-pc-linux-gnu (using -march=native)
  Compiler vendor:     gnu
  Compiler version:    g++-8 8
  Compiler flags:      -pipe -Wno-multichar -Wno-write-strings
-fno-enforce-eh-specs -Wno-non-template-friend -Wsuggest-override -s -O3
-ffast-math -march=native -pthread

In the hope that helps...

[jr] Re: slope problem [2623 days 12 hours and 13 minutes ago]

Thu, 31 Jan 2019 19:10:00 GMT

hi,

clipka <ano### [at] anonymousorg> wrote:
> Am 31.01.2019 um 19:21 schrieb jr:
> > so how can one "fudge" it, ie make the cylinders end a predictable distance from
> > each sphere?
>
> Preusuming you have the "central" sphere at P1, and a "remote" sphere at
> P2, and you want a distance of D between sphere centers and the cylinder
> ends, then
>
>      V = P2 - P1
>
> is the vector describing direction _and_ distance of the cylinder you want;
>
>      Vn = vnormalize(Vn)
>
> is the unit-length directionof that vector; and
>
>      Q1 = P1 + Vn*D
>      Q2 = P2 - Vn*D
>
> are the points you want the cylinder ends to be at.

thank you very much, will try.

(and thanks re light positioning)


regards, jr.

[clipka] Re: slope problem [2623 days 12 hours and 35 minutes ago]

Thu, 31 Jan 2019 18:47:36 GMT

Am 31.01.2019 um 18:53 schrieb jr:

>> Or I'm misunderstanding you, and what you're really complaining about
>> are the illusionary effects, due to the spheres' "center of light" not
>> coinciding with their center of mass - and likewise for the cylinders'
>> "axis of light" not coinciding with their "axis of mass".
> 
> does "shadowless" not ameliorate this effect?

No; for the illusionary offsets to vanish, you need to light the objects 
straight from the front.

[clipka] Re: slope problem [2623 days 12 hours and 38 minutes ago]

Thu, 31 Jan 2019 18:44:23 GMT

Am 31.01.2019 um 19:21 schrieb jr:
> hi,
> 
>> clipka <ano### [at] anonymousorg> wrote:
>>> Well, that's pretty much what I see them doing.
>>
>> given that the "end" is a sphere, I would have expected the cylinders to
>> terminate in a curved shape, equidistant.  but I see a right angle.
> 
> ouch, sorry, I see now.  need to arrange the other spheres spherically to get
> the equidistant ends.
> 
> 
>>> Of course since the distance changes as the angle changes, so do the
>>> gaps (because you computed each of them to be 5% of the total distance,
>>> from sphere center to start of cylinder).
> 
> so how can one "fudge" it, ie make the cylinders end a predictable distance from
> each sphere?

Preusuming you have the "central" sphere at P1, and a "remote" sphere at 
P2, and you want a distance of D between sphere centers and the cylinder 
ends, then

     V = P2 - P1

is the vector describing direction _and_ distance of the cylinder you want;

     Vn = vnormalize(Vn)

is the unit-length directionof that vector; and

     Q1 = P1 + Vn*D
     Q2 = P2 - Vn*D

are the points you want the cylinder ends to be at.

[jr] Re: slope problem [2623 days 12 hours and 58 minutes ago]

Thu, 31 Jan 2019 18:25:01 GMT

hi,

> clipka <ano### [at] anonymousorg> wrote:
> > Well, that's pretty much what I see them doing.
>
> given that the "end" is a sphere, I would have expected the cylinders to
> terminate in a curved shape, equidistant.  but I see a right angle.

ouch, sorry, I see now.  need to arrange the other spheres spherically to get
the equidistant ends.

> > Of course since the distance changes as the angle changes, so do the
> > gaps (because you computed each of them to be 5% of the total distance,
> > from sphere center to start of cylinder).

so how can one "fudge" it, ie make the cylinders end a predictable distance from
each sphere?

regards, jr.