On 20/10/2025 12:49, William F Pokorny wrote:
> On 10/20/25 03:53, kurtz le pirate wrote:
>> Let an array of "4D" vectors.
>> This code works well :
>>
>> #write ( FH, 
>> Array[i].x,",",Array[i].y,",",Array[i].z,",",Array[i].filter )
> 
> Below the contents of a documentation scene I'm adding to the next yuqk 
> release (R20). What's going on is part of a larger tangle due when and 
> how the features involved were implemented over time.
> 
> Bill P.
> 
> //---
> // Odd behavior with 'write' and 5D color vectors...
> 
> #declare V2 = <1,2>;
> #declare V3 = <1,2,3>;
> #declare V4 = <1,2,3,4>;
> #declare V5 = <1,2,3,4,5>; // Internally this a 'color vector'
> 
> #fopen FH "zzz" write
> 
> // These are OK in yuqk or in v3.8 beta 2
> #write (FH,V3.x,",",V3.y,",",V3.z)
> #write (FH,V4.x,",",V4.y,",",V4.z,",",V4.t)
> #write (FH,(V5.x),",",(V5.y),",",(V5.z))
> #write (FH,(V5.x),",",(V5.y),",",(V5.z)",",(V5.t))
> #write (FH,(V5.x),",",(V5.y),",",(V5.z)",",(V5.t)",",(V5.transmit))
> #write (FH,V2)
> #write (FH,V3)
> #write (FH,V4)
> 
> // This fails in yuqk and in v3.8 beta 2 because 'write' only
> // supports 2D, 3D and 4D vectors.
> #if (0)
> #write (FH,V5)
> #end
> 
> // This fails in v3.8 beta 2 because 'write' only supports 2D, 3D
> // and 4D vectors. Due how the dot operator works, incorrectly,
> // for the v3.8 tuple feature the V5.transmit is first seen as a 5D
> // color vector - before it is seen as a float due the dot operator.
> #if (0)
> #write (FH,V5.transmit)
> #end
> 
> // These fail in yuqk due fixes with the tuple assignment feature of
> // v3.8 which changes how the dot operators are evaluated. The yuqk
> // fork always sees 'V5' before it thinks about the dot operator. In
> // other words, with yuqk you must wrap all, 5D color vector, element
> // to float conversions in ()s with write!
> #if (0)
> #write (FH,V5.x,",",V5.y,",",V5.z)
> // #write (FH,V5.x,",",V5.y,",",V5.z,",",V5.t)
> // #write (FH,V5.x,",",V5.y,",",V5.z,",",V5.transmit)
> #end
> 
> #fclose FH
> 
> #error "Stop early"
> //---
> 
> Bill P.

Thanks Bill.


I see "This fails in v3.8 beta 2 because 'write' only supports 2D, 3D 
and 4D vectors."

So in a way, it's not coming from me.
Phew!


One more thing to add (or not?) to your to-do list for v4.




-- 
kurtz le pirate
compagnie de la banquise

Post a reply to this message

On 20/10/2025 13:20, Alain Martel wrote:
> Le 2025-10-20 à 03:53, kurtz le pirate a écrit :
>>
>>
>> Hello,
>>
>> Let an array of "4D" vectors.
>> This code works well :
>>
>> #write ( FH, 
>> Array[i].x,",",Array[i].y,",",Array[i].z,",",Array[i].filter )
>>
>>
>>
>>
>> Now with and array of "5D" vectors.
>> Base on the same schema i code this :
>>
>> #write ( FH, 
>> Array[i].x,",",Array[i].y,",",Array[i].z,",",Array[i].filter,",",Array[i].transmit
)
>>
>> And i get this error : "Expected 'string', colour identifier found 
>> instead".
>>
>>
>> On <https://wiki.povray.org/content/Reference_Talk:Vector_Expressions> 
>> from Bald Eagle, you can read :
>> #declare Vector = < 1, 2, 3, 4, 5>;
>> ...
>> #declare Fifth_Component = Vector.transmit;// 5
>>
>>
>> The fifth element corresponds well to the keyword "transmit".
>> So why did this error occur?
>>
>> I got around the issue like this :
>> #declare _x = Array[i].x;
>> #declare _y = Array[i].y;
>> #declare _z = Array[i].z;
>> #declare _f = Array[i].filter;
>> #declare _t = Array[i].transmit;
>> #write ( FH, _x,",",_y,",",_z,",",_f,",",_t )
>>
>> However, I would like to understand what is wrong with my syntax.
>> Thank you for your help.
>>
> 
> Working from William's reply, I have this workaround :
> Replace :
> #write 
> (
FH,Array[i].x,",",Array[i].y,",",Array[i].z,",",Array[i].filter,",",Array[i].transmit
)
> 
> With :
> #declare Trans = Array[i].transmit;
> #write ( FH, 
> Array[i].x,",",Array[i].y,",",Array[i].z,",",Array[i].filter,",",Trans )
> 

Yes Alain, shorter as my workaround but in the same spirit.




-- 
kurtz le pirate
compagnie de la banquise

Post a reply to this message

Do we have a comprehensive list of unfixed bugs for various POV-Ray features?

It might be helpful to have some method by which we list known limitations and
bugs in the actual documentation until such time that they get fixed.

- BW

Post a reply to this message

"Bald Eagle" <cre### [at] netscapenet> wrote:
> Do we have a comprehensive list of unfixed bugs for various POV-Ray features?
>
> It might be helpful to have some method by which we list known limitations and
> bugs in the actual documentation until such time that they get fixed.

That's what github is for. Once a bug is identified as a bug (here on the forum)
post it and the information gathered on github. Or post it directly on github
and discuss there. Personally I prefer here,

ingo

Post a reply to this message

"ingo" <nomail@nomail> wrote:
> "Bald Eagle" <cre### [at] netscapenet> wrote:
> > Do we have a comprehensive list of unfixed bugs for various POV-Ray features?


> That's what github is for. Once a bug is identified as a bug (here on the forum)
> post it and the information gathered on github. Or post it directly on github
> and discuss there. Personally I prefer here,


An expected reply, and exactly the kind of thing I'm trying to avoid.
Just look at the 30-year collection of information that we have here on the
newsgroup.  Too vast, too spread out, and currently unreliably searchable.
And I don't want to go to github and have to then sift through all of that.

What I'd like is a consolidated, up-to-date list that anyone can look at
"at-a-glance" and be able to readily assess the state of every keyword and
primitive, and distribution include file, etc.

Right here on our own, locally-controlled server space.
Because I prefer "here" as well.

I should be able to scroll down to, or search for #read, and only see _existing_
bugs (unless I want to view the bug report and remediation history).  Every new
POV-Ray task should not trigger a new, epic quest.

3rd party stuff is undeniably useful.  However I disdain _reliance_ upon it.
Just look at the Object Collection fiasco.

Here again, I will shamelessly make a plug for some kind of project management
system.

- BW

Post a reply to this message

hi,

"Bald Eagle" <cre### [at] netscapenet> wrote:
> "ingo" <nomail@nomail> wrote:
> > "Bald Eagle" <cre### [at] netscapenet> wrote:
> > > Do we have a comprehensive list of unfixed bugs for various POV-Ray features?
> > That's what github is for. Once a bug is identified as a bug (here on the forum)
> > post it and the information gathered on github. Or post it directly on github
> > and discuss there. Personally I prefer here,
> ...
> What I'd like is a consolidated, up-to-date list that anyone can look at
> "at-a-glance" and be able to readily assess the state of every keyword and
> primitive, and distribution include file, etc.
> Right here on our own, locally-controlled server space.
> Because I prefer "here" as well.

+1 wrt "here".

a wiki page, with simple "bullet" list ?


regards, jr.

Post a reply to this message

"Bald Eagle" <cre### [at] netscapenet> wrote:
>
> Here again, I will shamelessly make a plug for some kind of project management
> system.
>

Github has that and many other tools, but you have to pay.
https://github.com/features/issues I'm not a github user so I know little of it.

I asked their "thing" for a summary:

Copilot said: Here is a summary of the issues

Here is a summary of the issues for POV-Ray, ordered by severity (highest to
lowest). Please note: this is based on public issue titles, labels, and visible

project maintainers.
Critical Bugs & Vulnerabilities

    Potential Vulnerabilities (Cloned Functions)
        Fix potential vulnerable cloned function
        Fix potential vulnerable cloned functions
        Fix potential vulnerable cloned function Severity: Security-related,
likely the most urgent.

    Bug: Functionality Failure
        [BUG] function "trace" fails to find intersections in distances of more
than 10⁷ units Severity: Major feature broken for large distances.

    Build/Compatibility Failures
        [BUILD][UNIX] Failure on macOS w/ Xcode 16.4, error: unknown type name
'Fixed'
        [BUILD][UNIX] Build fails with strict-aliasing violations
        [BUILD][UNIX] Test for Boost Libraries fail on Apple silicon (Homebrew
path change) Severity: Prevents build on certain platforms.

    Bug: Parse/Error Handling
        [BUG] Parse error when using povray built by GCC 13, no error with GCC
12
        [BUG] doesn't give an error if a polygon is not 2D
        [BUG][UNIX] Failed to parse command line option with space in filename
Severity: Could lead to silent failures or unpredictable behavior.

    Bug: Memory/Allocation
        Assigned interior causes a bad allocation error Severity: May cause
crashes or data corruption.

    Bug: Incorrect Rendering
        Photons do not work properly with true inverse power fading
        Option "Keep Single Instance" is not working for *.inc files
        Error in POV-RAY output generated from Project Chrono Demo Severity: Can
result in incorrect output or broken features.

Medium Severity

    Performance/Optimization
        Usage of Enhanced Math Library for better performance
        AVX512 version for POVRAY Severity: Performance improvements, not
critical but useful.

    Feature Requests: Important for Users
        [FEATURE] support all Opentype font formats
        [FEATURE] LaTeX support
        Can we develop POV-RayMCP similar to BlenderMCP? Severity: Not bugs, but
could be important for project adoption.

Low Severity / Minor Issues

    Minor Bugs and UI Issues
        Debug string is not displayed in console if start with more than 14
hyphens
        Need to run POVRAY on a single thread
        Updates to screen.inc
        Issue a parse warning for out-of-domain arguments to the srgb keywords
        remove unecessary nullptr check before 'delete' and 'delete[]'
        Apply translate and rotate to user_defined cameras.
        Fixing some missing stuff in VS 2022
        What about 3.7 branch ? Severity: Minor bugs, enhancements, or
low-priority tasks.

Note:

    This list is based on 30 issues (API limit). For a complete and up-to-date
list, view all POV-Ray issues on GitHub.

on user impact, security, or strategic goals.
    If you want a more detailed triage or deeper analysis of a specific issue,
let me know!


ingo

Post a reply to this message

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

> +1 wrt "here".
>
> a wiki page, with simple "bullet" list ?

This would likely suffice, if there were someone to compile the present list,
and it were editable by a sufficiently wide user list.

Maybe a talk page or something.

I could likely write a simple spreadsheet to list keyword, file, macro,
whatever, who reported the bug, the link to the thread, who volunteered to fix
it, date, present status, etc.
That could be updated periodically to reflect the state of things.

Or maybe there's a way to format data on the wiki for retrieval by a spreadsheet
so that any local copies of the spreadsheet that people download can get
updated.

A record of the code development history - even as a simple text file - ought to
be provided in the distribution.

"I'm putting together a team.  People with special abilities."
- BW

Post a reply to this message

William F Pokorny <ano### [at] anonymousorg> wrote:
> On 10/20/25 03:53, kurtz le pirate wrote:
> > Let an array of "4D" vectors.
> > This code works well :
> >
> > #write ( FH, Array[i].x,",",Array[i].y,",",Array[i].z,",",Array[i].filter )
>
> Below the contents of a documentation scene I'm adding to the next yuqk
> release (R20). What's going on is part of a larger tangle due when and
> how the features involved were implemented over time.
>
> Bill P.
>
> //---
> // Odd behavior with 'write' and 5D color vectors...
>
> #declare V2 = <1,2>;
> #declare V3 = <1,2,3>;
> #declare V4 = <1,2,3,4>;
> #declare V5 = <1,2,3,4,5>; // Internally this a 'color vector'
>
> #fopen FH "zzz" write
>
> // These are OK in yuqk or in v3.8 beta 2
> #write (FH,V3.x,",",V3.y,",",V3.z)
> #write (FH,V4.x,",",V4.y,",",V4.z,",",V4.t)
> #write (FH,(V5.x),",",(V5.y),",",(V5.z))
> #write (FH,(V5.x),",",(V5.y),",",(V5.z)",",(V5.t))
> #write (FH,(V5.x),",",(V5.y),",",(V5.z)",",(V5.t)",",(V5.transmit))
> #write (FH,V2)
> #write (FH,V3)
> #write (FH,V4)
>
> // This fails in yuqk and in v3.8 beta 2 because 'write' only
> // supports 2D, 3D and 4D vectors.
> #if (0)
> #write (FH,V5)
> #end
>
> // This fails in v3.8 beta 2 because 'write' only supports 2D, 3D
> // and 4D vectors. Due how the dot operator works, incorrectly,
> // for the v3.8 tuple feature the V5.transmit is first seen as a 5D
> // color vector - before it is seen as a float due the dot operator.
> #if (0)
> #write (FH,V5.transmit)
> #end
>
> // These fail in yuqk due fixes with the tuple assignment feature of
> // v3.8 which changes how the dot operators are evaluated. The yuqk
> // fork always sees 'V5' before it thinks about the dot operator. In
> // other words, with yuqk you must wrap all, 5D color vector, element
> // to float conversions in ()s with write!
> #if (0)
> #write (FH,V5.x,",",V5.y,",",V5.z)
> // #write (FH,V5.x,",",V5.y,",",V5.z,",",V5.t)
> // #write (FH,V5.x,",",V5.y,",",V5.z,",",V5.transmit)
> #end
>
> #fclose FH
>
> #error "Stop early"
> //---
>
> Bill P.

So,
I'm curious about all of this.
There seems to be an awful lot of bouncing around under the hood, and a fair
amount of replicated code for things like splines, etc.

How are the vector components stored, and why do they need to be recast into
floats?

I see that there is no 5d vector defined in math/vector.h - it is in
base/colour.h

Can we somehow consolidate/unify the colors and the vectors, or do we want to
somehow completely separate them with a means to interconvert as per clipka?


#write converts everything to strings first?

Post a reply to this message

hi,

"Bald Eagle" <cre### [at] netscapenet> wrote:
> "jr" <cre### [at] gmailcom> wrote:
> > a wiki page, with simple "bullet" list ?
> This would likely suffice, if there were someone to compile the present list,
> and it were editable by a sufficiently wide user list.
> Maybe a talk page or something.

to begin with, I think, getting "the list" going is priority, as one of your
pages perhaps.  medium to long-term, and when the details are fixed, we can move
the page.


> I could likely write a simple spreadsheet to list keyword, file, macro,
> whatever, who reported the bug, the link to the thread, who volunteered to fix
> it, date, present status, etc.
> That could be updated periodically to reflect the state of things.
> Or maybe there's a way to format data on the wiki for retrieval by a spreadsheet
> so that any local copies of the spreadsheet that people download can get
> updated.

we do have tables.  I also think that the list(ing) should be kept simple,
mostly just a reference/index providing links to the details (like "who
volunteered").


> A record of the code development history - even as a simple text file - ought to
> be provided in the distribution.

back when s/wares used to provide a 'ChangeLog' file, for the exact purpose.


regards, jr.

Post a reply to this message