I figure I'll put this here, rather than embedding it in the midst of other
threads.

I'm currently working out some code to create some piece-wise functions with
very specific constraints.

During development, I noticed some odd mismatches, seemingly resulting from the
manner in which 3-argument select () statements work.

Using the 4-argument form and (repeating the equation to evaluate after a comma)
doesn't seem to correct this.

Specifically, each section of the piece-wise function never reaches the end of
its domain, and instead, the next section of the nested select statement starts
getting evaluated.
I shifted the 2nd segment up a bit to illustrate the problem in the attached
image. (disregard the file name)

https://wiki.povray.org/content/Reference:Numeric_Expressions
select(A, B, C [,D])
It can be used with three or four parameters Select compares the first argument
with zero, depending on the outcome it will return B, C or D. A,B,C,D can be
floats or fun(c)tions.
When used with three parameters, if A < 0 it will return B, else C (A >= 0).
When used with four parameters, if A < 0 it will return B. If A = 0 it will
return C. Else it will return D (A > 0).



Maybe that's something that I'm doing wrong, or maybe there's a hidden issue
with select () that's never been uncovered yet.

But it did make me think that there ought to be a way to reverse which "side" of
the evaluation A = 0 gets included in:

When used with three parameters (in the reverse case), if A <= 0 it will return
B, else C (A > 0).


Also, in past projects I have run into situations where I'd like to use matrix
transforms but with variable arguments.

Exposure of the elements of a matrix to SDL would be helpful when trying to
apply multiple matrix transforms to something and intermediate stages need to be
debugged, or simple matrix calculations need to be performed, letting
POV-Ray/yuqk do the heavy lifting.

Freya Holmer just put out another video on multiplying vectors, and mentioned
how when working with octonions, simply swizzling vector components allowed
rapid calculations to be performed using that "trick".

Vector swizzling (Vec.zxy) would be handy

Vector functions would be positively worth paying for.
Both user-defined, and inbuilt.
vectors allowed as arguments, vector components as arguments, and vector
results.
sin (<x, y, z>) ought to give me a result of <sin x, sin y, sin z>

Allowing arrays to be referenced or processed by functions would be great as
well.

Vector sizes and elements in things like prisms ought to be versatile and/or
standardized.  Having to convert points to a 2D vector is a PITA.

Access to data types would be great.
agnostic input data type for #read would be excellent as well.
There's also the issue of determining the number of elements in a vector.

Lots of functions in math.inc that ought to be inbuilt.

Lots more I'm sure.  Don't worry, I'll think of them   ;)

- BW

Post a reply to this message

Attachments:
Download 'cubicrectangularwave.png' (73 KB)

Preview of image 'cubicrectangularwave.png'

On 11/8/23 17:24, Bald Eagle wrote:
> I figure I'll put this here, rather than embedding it in the midst of other
> threads.

:-) The feature wish lists never get shorter. Elsewhere you'd mentioned 
stl import. I started a longer response there, but got side tracked.

The short version of it is:

- I believe hgpovray38 has a simple import method inbuilt today.

- My direction with yuqk is generally away from larger extensions like 
this being jammed into the POV-Ray core code. They make for a mess as 
seen by the user and those supporting / changing the internal code. I 
recently removed the julia_fractal shape, for example. We are not set up 
well for larger extensions except where they can be implemented as SDL 
coded includes or they work as inbuilt / user functions.

> 
> I'm currently working out some code to create some piece-wise functions with
> very specific constraints.
> 
> During development, I noticed some odd mismatches, seemingly resulting from the
> manner in which 3-argument select () statements work.
> 
> Using the 4-argument form and (repeating the equation to evaluate after a comma)
> doesn't seem to correct this.
> 
> Specifically, each section of the piece-wise function never reaches the end of
> its domain, and instead, the next section of the nested select statement starts
> getting evaluated.
> I shifted the 2nd segment up a bit to illustrate the problem in the attached
> image. (disregard the file name)
> 
> https://wiki.povray.org/content/Reference:Numeric_Expressions
> select(A, B, C [,D])
> It can be used with three or four parameters Select compares the first argument
> with zero, depending on the outcome it will return B, C or D. A,B,C,D can be
> floats or fun(c)tions.
> When used with three parameters, if A < 0 it will return B, else C (A >= 0).
> When used with four parameters, if A < 0 it will return B. If A = 0 it will
> return C. Else it will return D (A > 0).
> 

On my list to look at your select questions / ideas in more detail. What 
always pops to my mind when folks mention select() and bugs is whether 
we are switching on signed zeros - my head just isn't immediately 
remembering enough to say more at the moment.

> 
> 
> Maybe that's something that I'm doing wrong, or maybe there's a hidden issue
> with select () that's never been uncovered yet.
> 
> But it did make me think that there ought to be a way to reverse which "side" of
> the evaluation A = 0 gets included in:
> 
> When used with three parameters (in the reverse case), if A <= 0 it will return
> B, else C (A > 0).
> 
> 
> Also, in past projects I have run into situations where I'd like to use matrix
> transforms but with variable arguments.
> 
> Exposure of the elements of a matrix to SDL would be helpful when trying to
> apply multiple matrix transforms to something and intermediate stages need to be
> debugged, or simple matrix calculations need to be performed, letting
> POV-Ray/yuqk do the heavy lifting.
> 
> Freya Holmer just put out another video on multiplying vectors, and mentioned
> how when working with octonions, simply swizzling vector components allowed
> rapid calculations to be performed using that "trick".
> 
> Vector swizzling (Vec.zxy) would be handy
> 
> Vector functions would be positively worth paying for.
> Both user-defined, and inbuilt.
> vectors allowed as arguments, vector components as arguments, and vector
> results.
> sin (<x, y, z>) ought to give me a result of <sin x, sin y, sin z>
> 
> Allowing arrays to be referenced or processed by functions would be great as
> well.

A general capability not likely anytime soon.

I have added additional encodings into and out of a double's space to 
the yuqk fork. These effectively very tiny arrays which can be passed 
around in the parser and VM inside the double float space.

In some situations you can use an image_map created from a function as a 
function accessible array. There is an example of this in the 
histogram.pov file shipped now in the yuqk documentation tarball.

> 
> Vector sizes and elements in things like prisms ought to be versatile and/or
> standardized.  Having to convert points to a 2D vector is a PITA.
> 

The tuple / batch / bulk / list assignment methods are supposed to help 
some with this sort of vector type issue. Though I confess, I've not 
thought much about how to set it up efficiently / generally.

#local V = <0,0,0>; // 3D vector
#local <A,B> = V;   // Tuple method grabs first two elements of V
#local V = <A,B>;   // UV vector
prism {
   linear_spline
   0, 1, 10,
   V,
   ....

> Access to data types would be great.

The yuqk fork offers what is in setidtypes.inc.

> agnostic input data type for #read would be excellent as well.

Yeah, we really should be able to import STL with SDL itself...

> There's also the issue of determining the number of elements in a vector.

See setidtypes.inc

> 
> Lots of functions in math.inc that ought to be inbuilt.

I'd add shapes.inc, color.inc ...

Some of this has been done (see yuqk's math.inc), but yes, extending the 
core function set where we can makes sense.

> 
> Lots more I'm sure.  Don't worry, I'll think of them   ;)
> 
> - BW
>

Post a reply to this message

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

> - My direction with yuqk is generally away from larger extensions like
> this being jammed into the POV-Ray core code. They make for a mess as
> seen by the user and those supporting / changing the internal code.

Sorry, my Man, but I must respectfully disagree.
I'm not talking about binary STL, I'm talking about ASCII STL, or "STLA"
https://paulbourke.net/dataformats/stl/

It's a sparrow's fart away from being a legit POV-Ray mesh {} definition, which
is why I said it would be _trivial_ to implement.
Copy mesh{} code, paste mesh {} code, edit mesh {} code.   Done.
Just rather than mesh {}, call it stl {}.


> In some situations you can use an image_map created from a function as a
> function accessible array. There is an example of this in the
> histogram.pov file shipped now in the yuqk documentation tarball.

Yes, I have thought about doing that, but having the native capability rather
than a work-around would keep me focused, on task, and less closer to "complex
coding burnout".


> > Vector sizes and elements in things like prisms ought to be versatile and/or
> > standardized.  Having to convert points to a 2D vector is a PITA.
>
> The tuple / batch / bulk / list assignment methods are supposed to help
> some with this sort of vector type issue. Though I confess, I've not
> thought much about how to set it up efficiently / generally.

Being able to vector swizzle would solve a lot of the issue.
Doing it internally by just having the prism use regular 3D vectors, but only
using Vector.xz would work as well.

>
> #local V = <0,0,0>; // 3D vector
> #local <A,B> = V;   // Tuple method grabs first two elements of V

^^^ Very interesting.  I didn't know that was a valid construction.

> #local V = <A,B>;   // UV vector

#local V = V.xz;   would be the preferred embodiment.


With regard to the current shader, I've run into quite a number of stumbling
blocks that highlight the deeply ingrained problems and limitations of the
function parser.  I'm not saying that Thorsten didn't do a good job - it's just
that what we have isn't really adequate to the tasks I would (reasonably) like
to accomplish, and isn't conducive to moving forward toward 4.0.

When evaluating a pattern, things need to be coded in a certain "static" way.
What one might do in a macro - declaring variables to store intermediate
calculation results - isn't possible with functions.
Vector components are scalar values, but using Vector.x in a function argument
isn't allowed.
Fundamental computer graphics functions like inbuilt vlength () doesn't work.
Dot product?  Cross product?  c'mon.
We have "matrix" transforms, but we don't really have actual matrices that do
matrixy things.  At the very least we ought to have a projection matrix, simple
matrix multiplication, transpose, diagonal elements of square matrix, and a
determinant function.

I understand clipka's gripe that POV-Ray is a raytracer, and there are plenty of
3rd party software packages that can do x,y,and z ... but - to further address
your "complication" argument - I think that 4.0 ought to be able to natively
perform a lot of tasks that are fundamental mainstays in computer graphics and
gaming texts.

Yes, POV-Ray is a raytracer.  But if it chains itself to the mindset of early
90's CGI, then it's going to get neglected and buried.  People are going to be
discovering and implementing new and interesting things to do, and they're going
to want the capability to code it - in a sane, straightforward manner.

Thinking about features and ways to implement them will get us all to look at
the big picture and find a way to generalize a lot of the specialty code that
got written in fits and starts by 20 different people and just pasted onto the
existing code base.

We can find faster, more versatile and agile ways to do things, and open up the
code base to further expansion by making the addition of code modules easier to
implement.


- BW

Post a reply to this message

Le 14/11/2023 à 20:36, Bald Eagle a écrit :
 > William F Pokorny <ano### [at] anonymousorg> wrote:
 >
 >> - My direction with yuqk is generally away from larger extensions like
 >> this being jammed into the POV-Ray core code. They make for a mess as
 >> seen by the user and those supporting / changing the internal code.
 >
 > Sorry, my Man, but I must respectfully disagree.
 > I'm not talking about binary STL, I'm talking about ASCII STL, or "STLA"
 > https://paulbourke.net/dataformats/stl/
 >

You can always use a converter for STL from Ascii to Binary, it will be 
far simpler than having yet another extension of the parser, or even a 
dedicated parser. It's only once you have experimented handling the 
versatility of text input that you start to like strict binary encoding.


 > It's a sparrow's fart away from being a legit POV-Ray mesh {} 
definition, which
 > is why I said it would be _trivial_ to implement.
 > Copy mesh{} code, paste mesh {} code, edit mesh {} code.   Done.
 > Just rather than mesh {}, call it stl {}.

Somebody seems enthusiast about mesh... you have probably no idea yet of 
the nest of snakes you are to discover.

mesh{} and mesh2{} are two syntax for the same final data structure, but 
the latter is far faster to parse when the number of points starts 
increasing, as the computation are in mesh2{}, whereas mesh{} just do it 
on the fly for you.

 >
 > We can find faster, more versatile and agile ways to do things, and 
open up the
 > code base to further expansion by making the addition of code modules 
easier to
 > implement.
 >

Never forget portability & universality. Povray could run on Amiga.

Post a reply to this message

On 11/14/23 14:36, Bald Eagle wrote:
> With regard to the current shader, I've run into quite a number of stumbling
> blocks that highlight the deeply ingrained problems and limitations of the
> function parser.  I'm not saying that Thorsten didn't do a good job - it's just
> that what we have isn't really adequate to the tasks I would (reasonably) like
> to accomplish, and isn't conducive to moving forward toward 4.0.
> 
> When evaluating a pattern, things need to be coded in a certain "static" way.
> What one might do in a macro - declaring variables to store intermediate
> calculation results - isn't possible with functions.
> Vector components are scalar values, but using Vector.x in a function argument
> isn't allowed.
> Fundamental computer graphics functions like inbuilt vlength () doesn't work.
> Dot product?  Cross product?  c'mon.
> We have "matrix" transforms, but we don't really have actual matrices that do
> matrixy things.  At the very least we ought to have a projection matrix, simple
> matrix multiplication, transpose, diagonal elements of square matrix, and a
> determinant function.

Jerome's response reminded your post was on my - respond to it 
eventually lists (along with your select() bug report).

I agree with a lot of what you wrote and to the degree I'm able to push 
yuqk in some of those directions - near term - and within the confines 
of the current VM(a) I will (or perhaps already have).

I've implemented an f_length() inbuilt function for example.

What I've not gotten around to since adding the 3 x 21 bit float 
encoding / decode inbuilt functions is a set of inbuilt dot, cross, 
length 21 bit inbuilt functions. I'll bump those up my to do list. It 
would enable certain kinds of vector play withing the confines of the 
current VM and 'function compiler'. The 21 bit float accuracy is plenty 
of accuracy for most color work, for example - though not of course for 
other work.

(a) - The current VM has limits sure, but I've also found it to be solid 
code. I'm comfortable building on top of it with now a large amount of 
work which didn't require some completely new VM implementation.

Aside: A couple years ago I spend some time looking into and thinking 
about alternate 'simple' VMs (of the C++ template driven kind which has 
been used to enable old game collections on VMs emulating ancient 
hardware) along with some sort of accompanying assembler. The latter 
would solve solve issues with respect to lack of user accessible 
intermediate storage, for example, with minimal perturbation of the 
current parser and SDL. Thought was the SDL parser bit would be very 
roughly #declare Fn = fasm { ... }. I also had the thought there is no 
real reason we could not have multiple VM implementations going at the 
same time too - perhaps some for very specialized work / existing work 
based upon certain existing alternate architectures. Yes, now thinking 
aloud / dreaming a bit. :-)

Bill P.

Post a reply to this message

Le_Forgeron <jgr### [at] freefr> wrote:

Hi Jerome,

> You can always use a converter for STL from Ascii to Binary, it will be
> far simpler than having yet another extension of the parser, or even a
> dedicated parser. It's only once you have experimented handling the
> versatility of text input that you start to like strict binary encoding.

I'm not sure if I misunderstand you, or you misunderstand me.
I'd like for POV-Ray to be able to natively parse and implement a simple ASCII
stl file.

No one out there writes include files for POV-Ray in its mesh {} format.
But there are tens of thousands, if not millions or billions of stl files for
the exploding 3D printing community.
We don't currently have a modeler - but we have a ready made source of MODELS.
And obviously modelers to make stls.
Please tell me that I don't have to explain the obvious advantage of that any
more.

Being able to use an ASCII stl file by way of a simple #include statement would
be a profoundly useful tool for the user community.  And it would also act as a
tool to draw new users into POV-Ray, because we could make them aware of a new
(to them) tool that can digitally represent the model that they want to build,
or paint, or whatever.  More exposure = more users = more interest = more
exposure .... until we hit that threshold where some of the people who discover
POV-Ray _ARE_ software developers and we can get new people who are motivated
enough and competent enough to work on the source code.  And that brings along a
whole new source of new ideas and approaches to old problems that we may not
have thought of, and may not have been available until now.


> Somebody seems enthusiast about mesh... you have probably no idea yet of
> the nest of snakes you are to discover.

I'm not very enthusiastic about meshes (at the moment) but I do acknowledge that
there are good things about mathematical primitives - and severe limitations,
and the same goes for triangle meshes.

> mesh{} and mesh2{} are two syntax for the same final data structure, but
> the latter is far faster to parse when the number of points starts
> increasing, as the computation are in mesh2{}, whereas mesh{} just do it
> on the fly for you.

Yes Sir - I have coded scenes using both of those data structures, and so have
read (mostly) all of the applicable documentation.

> Never forget portability & universality. Povray could run on Amiga.

I'm not forgetting that at all.  At the same time, whether good or bad - the
Amiga days are long past, and if POV-Ray is to avoid stagnation and death, then
there needs to be a certain amount of innovation and modernization so that it
can leverage as much of the newer computer architecture developments as
possible.

I've learned a lot over the past 10 years, but I'm still not a computer science
major or software developer.  However, sometimes that's an advantage, because
I'm not restrained by any preconceived notion of "you can't do that!" and so I
find some crazy way to make things happen anyway.  ;)

I do understand that POV-Ray's primary means of rendering is not rasterization,
and does not rely primarily on triangles, but surely we may in some (other) way
take advantage of the massive parallel computing of GPUs.  I don't know what we
have in our codebase that would take advantage of that, but just experimenting
with the capability to access a GPU would be like tasting a new food.   Why do
it?  So that you know what it's like.  There's no other way to accomplish
gaining that knowledge.  Then you can proceed from there.  Maybe we like the
taste of GPU, maybe not.

I also stumble across all manner of ways that other people do things, and just
recently read of "just in time" compiling - so maybe that's something to discuss
for future development work.

(Good to see you again, we miss you here)

- BW

Post a reply to this message

In playing around with ray diagrams, it occurred to me that we have no inc-file
or inbuilt reflected ray macro or function (that I know of).

Since we have trace () that also supplies a surface normal, a nice complement to
that would be reflected_ray (Ray, SurfaceNormal).

-BE

Post a reply to this message

On 12/25/23 09:51, Bald Eagle wrote:
> In playing around with ray diagrams, it occurred to me that we have no inc-file
> or inbuilt reflected ray macro or function (that I know of).
> 
> Since we have trace () that also supplies a surface normal, a nice complement to
> that would be reflected_ray (Ray, SurfaceNormal).
> 

(or refracted, transmitted, media generated...)

I agree such capability would be useful(a) for diagrams - and probably 
mostly for debugging.

Assuming you want access to the real internally generated >first rays, 
the other forms are quite a bit harder / uglier to do than is trace(). 
Further, the results for other than initial / first rays are also 
tangled in render settings and options.

Bill P.

(a) - While doing the solver work back in 2017 /2018, I a couple times 
hacked in a capability to dump all the generated rays from single 
rendered pixels. The pixels were isolated by start/end column row 
command line flags (or ini settings). FWIW - It was hacked code and not 
SDL available functionality.

Post a reply to this message

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

> Assuming you want access to the real internally generated >first rays,

Nope.
Just something like:

#declare SFn_vdot = function (ax, ay, az, bx, by, bz) {ax*bx + ay*by + az*bz}

#declare f_Reflectionx = function (Dx, Dy, Dz, Nx, Ny, Nz) {Dx - 2 * SFn_vdot
(Dx, Dy, Dz, Nx, Ny, Nz)* Nx}
#declare f_Reflectiony = function (Dx, Dy, Dz, Nx, Ny, Nz) {Dy - 2 * SFn_vdot
(Dx, Dy, Dz, Nx, Ny, Nz)* Ny}
#declare f_Reflectionz = function (Dx, Dy, Dz, Nx, Ny, Nz) {Dz - 2 * SFn_vdot
(Dx, Dy, Dz, Nx, Ny, Nz)* Nz}

which in sane functions would like a macro formula:

#macro Reflection (Direction, Normal)

 //#local Refl = 2*Normal*(vdot(Normal, V)) - V;
 #local v_reflection = Direction - 2*vdot (Direction, Normal)*Normal;

 v_reflection

#end

> the other forms are quite a bit harder / uglier to do than is trace().
> Further, the results for other than initial / first rays are also
> tangled in render settings and options.

Oh, I can only imagine...  :O

Post a reply to this message

"Bald Eagle" <cre### [at] netscapenet> wrote:
>...
> Fundamental computer graphics functions like inbuilt vlength () doesn't work.
>...

For that you can use f_r() inside your own functions.

It's in functions.inc. It calls internal function no. 57.

https://wiki.povray.org/content/Reference:Functions.inc

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

Post a reply to this message