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)
 // r=d-2(d·n)n
 //#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

"Bald Eagle" <cre### [at] netscapenet> wrote:
> 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)

I'm sorry Bill, but you have to provide some more information for us about
what you are doing here.


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

There already is a way:

select(A, B, C)

    A < 0: return B
    A = 0: return C
    A > 0: return C

select(-A, C, B)

    A < 0: return B
    A = 0: return B
    A > 0: return C

select(E - F, G, H)

    E < F: return G
    E = F: return H
    E > F: return H

select(F - E, H, G)

    E < F: return G
    E = F: return G
    E > F: return H


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

Post a reply to this message

"Bald Eagle" <cre### [at] netscapenet> wrote:
> 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}
>...

You are already thinking in the right ways...
To see how you can use that further, have a look here:

Subject: Source code for "With and without a light_source"
From: Tor Olav Kristensen
Date: 2003-06-23 18:20:41
https://news.povray.org/povray.text.scene-files/message/%3CXns93A54E262AE2torolavkhotmailcom%40204.213.191.226%3E

There's no vector cross expressions there. But that will require only 3 small
exressions.

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

Post a reply to this message

"Bald Eagle" <cre### [at] netscapenet> 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.
>...

To not have variables in functions is not necessarily a showstopper.

It just requires you to rewire your brain to program in a more "functional" way.
    ;-)
A lot of people struggle with this when they start programming in functional
languages.

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

Post a reply to this message

On 12/27/23 19:13, Tor Olav Kristensen wrote:
> "Bald Eagle" <cre### [at] netscapenet> wrote:
>> 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}
>> ...
> 
> You are already thinking in the right ways...
> To see how you can use that further, have a look here:
> 
> Subject: Source code for "With and without a light_source"
> From: Tor Olav Kristensen
> Date: 2003-06-23 18:20:41
>
https://news.povray.org/povray.text.scene-files/message/%3CXns93A54E262AE2torolavkhotmailcom%40204.213.191.226%3E
> 
> There's no vector cross expressions there. But that will require only 3 small
> exressions.
> 
> --
> Tor Olav
> http://subcube.com
> https://github.com/t-o-k
> 
> 

OK. When I get to implementing 21 bit float dot, cross functions for 
yuqk, I'll think about reflection / refraction functions too. I already 
implemented a f_normal() function and have had thoughts on perhaps 
implementing some sort of pre-range, bounded, f_trace() 'trace()' 
equivalent too, but we'll see...

Bill P.

Post a reply to this message

On 12/27/23 18:44, Tor Olav Kristensen wrote:
> I'm sorry Bill, but you have to provide some more information for us about
> what you are doing here.

Bill posted a test scene here:

http://news.povray.org/povray.bugreports/thread/%3Cweb.654c1b56f53b6bed1f9dae3025979125%40news.povray.org%3E/

I've not gotten around to looking at it myself, but it is on my to do 
list somewhere.

---

FYI. With credit, I've added the bottom part of your response - on the 
zero bucketing adjustments - to yuqk's select keyword documentation.

Bill P.

Post a reply to this message

William F Pokorny <ano### [at] anonymousorg> wrote:
> On 12/27/23 18:44, Tor Olav Kristensen wrote:
> > I'm sorry Bill, but you have to provide some more information for us about
> > what you are doing here.

https://arxiv.org/pdf/1511.04224.pdf

I was working on figuring out Stephen Marschner's procedural wood texture, and
part of the paper uses triangular waves and rectangular waves with specific
properties, as he states:

6.1.3 Seasonal growth
We turn the r coordinate volume into a time volume by scal-
ing its value and adding a smoothed triangular wave w (r)
to it. Each cycle of the smoothed triangle wave consists of
two linear segments connected by quadratic segments so as
to make the wave C1 continuous. The parameters are the
lengths of the two linear segments and the two quadratic
segments.
We scale the triangle wave so that when added to the radius,
half of the time the wood grows faster than the mean and
half of the time the wood grows more slowly. Then we add
1D noise n to generate variation in growth rate. All in all,
we have
tpre = r + w (r) (23)
t = tpre + n (tpre) (24)
This gives us the time at which any point in the wood was
laid down.
6.1.4 Growth rings
We can then create growth rings from the time volume. By
using a smoothed rectangular wave g = w (t), we can vary
the absorption of the wood according to the season. Simi-
larly to the triangle wave used to determine the growth rate,
each cycle of the smoothed rectangular wave consists of two
constant segments and two cubic segements so as to make
the wave C2 continuous, and the parameters are the relative
lengths of the two linear segments and the two quadratic
segments, plus the minimum and maximum values.

- BW

Post a reply to this message

With regard to recent work by Jonathan Bush,

It occurred to me that a fairly typical and frequently used operation in
constructing scene code is the remapping of a value in one domain to a value in
another domain (typically 0 to 1).

Rather than puzzling out single-use formulas for doing such a conversion, it
would be extremely convenient, especially to new users, to have a set if inbuilt
functions specifically for this purpose.

A basic set of formulas, proposed by Freya Holmer
https://www.youtube.com/watch?v=NzjF1pdlK7Y
is suggested for use below:
//------------------------------------------------------------------------

// Freya Holmer
#declare Lerp    = function (Start, End, Value) {(1 - Value) * Start + (End *
Value)}

#declare InvLerp = function (Start, End, Value) {(Value - Start) / (End -
Start)}

#declare ReMap   = function (OldMin, OldMax, NewMin, NewMax, Value) {Lerp
(NewMin, NewMax, InvLerp (OldMin, OldMax, Value) )}

//------------------------------------------------------------------------

While hunting down this code, I found a functions.inc file by WFP that had some
internal remapping functions (presumably for use in isosurfaces in povr/yuqk)
but the accompanying documentation was pretty complex, dense and hard to follow,
but it suggests that there are other remapping schemes may be desirable.

Similarly, an example scene to demonstrate/illustrate how <u, v> values get
remapped to <x, y, z> values on a parametric surface would likely be of interest
and use to those trying to understand how uv-mapping works.

Also, IIRC, there is some spline-based animation code, perhaps written by Rune
Johansen that employs some extensive remapping functions.

The point of this thread being that certain operations widely considered to be
basic operations in computer graphics should be inbuilt in yuqk / 4.0 rather
than require an awareness of multiple include files and other external libraries
by users as part of the rather steep learning curve.
Also, the power and speed of compiled source code, and the algorithmic nature of
source-code "functions" would reduce significant frustration in trying to write
complex scene code, and make POV-Ray more attractive and competetive in the
larger computer graphics community.

- BW

Post a reply to this message

On 1/2/24 07:34, Bald Eagle wrote:
> Rather than puzzling out single-use formulas for doing such a conversion, it
> would be extremely convenient, especially to new users, to have a set if inbuilt
> functions specifically for this purpose.
> 
> A basic set of formulas, proposed by Freya Holmer
> https://www.youtube.com/watch?v=NzjF1pdlK7Y
> is suggested for use below:
> //------------------------------------------------------------------------
> 
> // Freya Holmer
> #declare Lerp    = function (Start, End, Value) {(1 - Value) * Start + (End *
> Value)}
> 
> #declare InvLerp = function (Start, End, Value) {(Value - Start) / (End -
> Start)}
> 
> #declare ReMap   = function (OldMin, OldMax, NewMin, NewMax, Value) {Lerp
> (NewMin, NewMax, InvLerp (OldMin, OldMax, Value) )}
> 
> //------------------------------------------------------------------------
> 
> While hunting down this code, I found a functions.inc file by WFP that had some
> internal remapping functions (presumably for use in isosurfaces in povr/yuqk)
> but the accompanying documentation was pretty complex, dense and hard to follow,
> but it suggests that there are other remapping schemes may be desirable.

Yuqk's functions.inc documents a f_range2range() inbuilt which is likely 
equivalent to the the 'Remap' function above - though the value is the 
first parameter rather than the last.

Yes, yuqk's f_remap() is somewhat complicated. It could be used for one 
range to range pair, but it's aimed more at creating multiple roots 
(more particularly, isosurface shells) at particular value locations 
within an existing functions value's overall range. For example, 
multiple shells within f_sphere()'s return values where we'd normally be 
able to create only one shell about f_sphere()'s radius value / single 
root.

Providing inbuilt function(s?) for common interpolation methods is a 
good idea. Some time ago Ingo coded up an include with a largish set of 
gradients / interpolation methods. My aim is to someday create a 
f_interpolation() inbuilt which encapsulated most (or all?) of those and 
probably others. Maybe I'll at least create an initial version when I go 
after those additional 3x, 21 bit float functions...

I have started a directory of examples for the inbuilt functions which 
is shipped in the examples tar ball. Overall progress is admittedly slow.

Aside: I have large collection of scene files for playing with / testing 
the inbuilt functions, but those are mostly not good examples as coded. 
Plus, quite a few no longer work because of later yuqk changes...

Aside: The functions.inc file has a self test section at the bottom with 
the functions coded up for sanity testing purposes. That testing code 
sometimes works as decent example code.

Anyhow. In general, I agree with the suggestions in your post! :-)

Bill P.

Post a reply to this message

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

> Anyhow. In general, I agree with the suggestions in your post! :-)

I had a bit of time to wind down after work, and got sucked back into playing
with pigment function {}} patterns.

There are certain functions that we already have and that can be used in clever
ways (Thanks TOK) such as f_r and select ();

If I don't get to it at some point in the near future, I'd suggest an include
file that allows users to employ these in a somewhat more "code readable"
fashion.  By that I mean that f_r should have an alias function declared such as

#declare vector_length = function {f_r (x, y, z)}

and TOK's various select () permutations might be confusing to employ without a
little cheat sheet.

I'm considering writing some "help functions" that store the valid domains of
various functions, such that it's easy to output to the debug stream, use as a
protective wrapper / sanity check for avoiding parse errors, graphing the valid
domains of the functions, and probably an insert-menu cheat sheet would be a
simple but useful idea as well.

Anyway, that was a long-winded lead-in to the fact that I often find myself
needing to use some of the odder trigonometric functions and their inverses, and
the following ought to be in-built functions.

#declare fmod = function (Value, Modulo) {select (Value, 1 - mod (abs (Value),
Modulo), mod (abs (Value), Modulo))}  // this gives a mod function that remains
consistant across the origin

// trigonometric functions
#declare csc = function (N) {1/sin(N)}
#declare sec = function (N) {1/cos(N)}
#declare cot = function (N) {1/tan(N)}

// inverse trigonometric functions
#declare acsc = function (N) {asin(1 / N)}
#declare asec = function (N) {acos(1 / N)}
#declare acot = function (N) {atan(1 / N)}

This reminds me to look into hyperbolic and spherical functions as well...

With regard to interesting functions that (barring TOK-level functional coding)
likely can "only" be coded as algorithms in source, or would likely only be
useful if leverage the speed of being a compiled internal "function" (algorithm)
are:

GCD (HCF)
LCM
https://www.geeksforgeeks.org/mathematical-algorithms/mathematical-algorithms-gcd-lcm/

! factorial

Strangely, sgn (N) is not inbuilt.

And I guess until I run into something else, that's it for today's installment.
 :)

- BW

Post a reply to this message

On 1/4/24 13:29, Bald Eagle wrote:
> If I don't get to it at some point in the near future, I'd suggest an include
> file that allows users to employ these in a somewhat more "code readable"
> fashion.  By that I mean that f_r should have an alias function declared such as
> 
> #declare vector_length = function {f_r (x, y, z)}

Thanks for the input!

---

The yuqk fork already has inbuilt f_length() and f_length_sqr() 
functions. The former added in part as a clearer alternative to f_r(), 
but it and f_length_sqr() also wrap POV-Ray's internal vector template 
functions called length() and length_sqr(), respectively. The f_r() 
implementation is hard coded c++ math.

The f_r() and f_length() results should be identical for sane inputs, 
but pulling that internal code out to something SDL/VM accessible gives 
us a way to sanity test the both the internal template functionality and 
that equivalence as part of the include's self testing code.

Aside: The yuqk fork has too an f_hypot() function for two inputs (2D 
vectors). Initially it wrapped C++'s std:hypot() as being safer with 
respect to internal overflows, but I found the std::hypot performance 
slow. Today it's just sqrt(x*x + y*y) as the main reason to have the two 
input form over just f_length() with one input at zero, is performance.

As for sgn(), the yuqk fork has the inbuilt functions: f_sign(), 
f_sign0(), f_signpow() and f_signsqrt().

Bill P.

Post a reply to this message

xor (x, y)

"Hey, this looks like a cool pattern to _quickly_ implement..."

Famous last words.

Is bitwise_xor () a valid numeric expression for POV-Ray functions?   Nope.

So I had to make a function to grab the kth bit of the binary representation of
decimal integer N.
Then an xor function.
Then a function that reassembles the xor'd bits into a decimal value.
Then puzzle out how to properly visualize that in a pigment {function {}}
statement, given all the things peculiar to POV-Ray.

All in all quite a bit longer than I expected it to take.

Perhaps consider adding (probably under-the-hood) dec2bin conversion functions.

Also binary functions, taking decimal arguments.
You may just want to have generic binary functions that take 2 arguments - the
number as an argument, plus the base the argument is in (maybe hex).
Or maybe there's a whole other system of doing all that, which makes more sense.

 - BW

Post a reply to this message

Attachments:
Download 'mathpatterns1.png' (122 KB)

Preview of image 'mathpatterns1.png'

On 1/11/24 16:06, Bald Eagle wrote:
> Is bitwise_xor () a valid numeric expression for POV-Ray functions?   Nope.

A reason I added a collection of 64 bit inbuilt functions to the yuqk 
fork. The current set:

f_dec64x_ui1
f_enc64x_ui1
f_64x_ui1_and
f_64x_ui1_or
f_64x_ui1_xor
f_64x_ui1_not
f_64x_ui1_shr
f_64x_ui1_shl
f_64x_ui1_toflt
f_64x_ui1_fltto
f_64x_ui1_popcnt
f_64x_ui1_ror
f_64x_ui1_rol

Specifications in hex, binary - maybe, but at the moment I think these 
can be handled reasonably well with macros.

Bill P.

Post a reply to this message

William F Pokorny <ano### [at] anonymousorg> wrote:
> On 1/11/24 16:06, Bald Eagle wrote:

> A reason I added a collection of 64 bit inbuilt functions to the yuqk
> fork. The current set:
>
> f_dec64x_ui1
> f_enc64x_ui1
> f_64x_ui1_and
> f_64x_ui1_or
> f_64x_ui1_xor
> f_64x_ui1_not
> f_64x_ui1_shr
> f_64x_ui1_shl
> f_64x_ui1_toflt
> f_64x_ui1_fltto
> f_64x_ui1_popcnt
> f_64x_ui1_ror
> f_64x_ui1_rol

Very nice.  :)

> ... I think these can be handled reasonably well with macros.

:|

So, I'd be able to just plop a decimal argument in, and use binary functions on
it?
Simple code example?

Thanks.

- BW

Post a reply to this message

On 1/11/24 19:02, Bald Eagle wrote:
> So, I'd be able to just plop a decimal argument in, and use binary functions on
> it?
> Simple code example?

#version unofficial 3.8; // yuqk
#if (file_exists("version.inc"))
     #include "version.inc"
#end
#if (!defined(Fork_yuqk))
     #error "This POV-Ray SDL code requires the yuqk fork."
#end

#include "functions.inc"
#declare FnXor = function (a,b) {
//  f_64x_ui1_toflt(  // For explicit conversion back to float
     f_64x_ui1_xor(
         f_64x_ui1_fltto(a),
         f_64x_ui1_fltto(b),
         4  // Internal conversion xor result back to a float
     )
//  )
}

#debug concat("xor(7,3) ",str(FnXor(7,3),3,0),"\n")

#error "Stopping after parse"

Note. Due the differences in double and unsigned long integers, values 
are limited to a zero to pow(2,53)-1 range where doubles are involved.

Bill P.

Post a reply to this message

Just unloading some more thoughts for the record.

Prism has always annoyed me, because it only takes 2D vectors, and I wind up
having to do a lot of unnecessary conversions when I'm starting with 3D points,
and wanting to do something with prisms.

Apparently polygon {} already has the inbuilt feature that prism {} _should_
have.

"All points of a polygon are three-dimensional vectors that have to lay on the
same plane. If this is not the case an error occurs. It is common to use
two-dimensional vectors to describe the polygon. POV-Ray assumes that the z
value is zero in this case."
https://wiki.povray.org/content/Reference:Polygon


Exploring Thomas Fester's modeling-with-blobs method, it occurred to me that
blobs should have an _optional_ strength argument, and perhaps a new keyword
such as blob_strength can be included in a blob definition to set a default
strength.

The purpose of that would be to simply allow enclosing some vast collection of
spheres and cylinders in an extant scene to be wrapped by a blob {} statement
and still function - without having to edit every single damned line to include
a strength component.

Part of what I see in other software packages is the sophisticated handling of
data structures such that the user doesn't have to sit there and puzzle out how
to hand-reformat all of their data to fit into some other feature's input.

If I take the sine of a vector, I ought to get a vector with all the components
being the sines of the original vector components.
Same with taking the sine of a matrix.

POV-Ray currently has no "point" primitive, even though that's probably the
fundamental thing we all use that underlies all of the other primitives.
The "where" of everything.

We have center points for spheres, tori, endpoints for cylinders, corner points
for boxes, etc.

But when that data is embedded into a primitive {} statement, it's no longer
accessible to the SDL in any [convenient] way.

Something interesting would be to have an "extraction" feature whereby one could
enclose an object - lets say a simple union of cylinders and spheres - in curly
braces or parentheses, and the keyword operating on that would extract an array
of points and their associated primitive types.

The key idea here is the ability to elaborate on existing work, rather than
having to laboriously and time-consumingly deconstruct, dissect, analyze,
scheme, plan, and reconstruct an otherwise perfectly good data set so that you
can get on with the derivative work that you had in mind in the first place.

Another related idea is the fact that users frequently have a need to keep track
of objects and their positions, and need ways to maneuver them into specific
positions.


If I have two instances of an object, but they are hand-modeled or the result of
measurements or automated scripts - where the second is perhaps rotated and
translated into another specific position relative to the first (but obviously
not a COPY of the first placed with rotate or translate) then it would be useful
to have some 3D fitting algorithm that maps Item1 to Item2 and returns a
transform matrix. (obvious this is complicated and fraught with limitations)

A stumbling block that can be encountered is that all spheres are the same.  In
terms of the fact that they are all just sphere {} objects.  One can not track
any individual sphere.  This used to be an extremely limiting problem in
chemistry - because all atoms of the same type were the same.
Until we discovered isotopes.  They still react the same, but they have
different nuclear properties that we can look at and see that they are
different.
Being able to "tag" specific primitives with "metadata" that they carry with
them would be a useful feature, especially if that data could be queried.

This goes back to using the VISIO paradigm of SmartShapes and SmartSheets, but
one could readily see that if the only metadata associated with an object was
its normal vector, then that could potentially save an enormous amount of
calculation, since the metadata normal vector would be transformed along with
the object it is already attached to.

- BW

Post a reply to this message

"Bald Eagle" <cre### [at] netscapenet> wrote:
> Just unloading some more thoughts for the record.


If we had a struct specific for spheres, we'd still need to initialize it and
declare a sphere with it to later be able to identify that one specific sphere.

When I need something like that I use an external program to generate a large
array with struct like data and generate the spheres from that with a macro
loop. The index of the sphere is then the identifier. All sphere parameters are
accessible and modifiable through the array. Multiple sphere types, like your
isotopes, are then multiple type specific arrays. You could also put your
metadata in an/the array.

If we had structs, we'd put structs in the array(s) just the same way.

ingo

Post a reply to this message

"ingo" <nomail@nomail> wrote:

> If we had structs, we'd put structs in the array(s) just the same way.
>

missed a bit,

but in general, I would welcome access to any data inside of POV-Ray.

Also, it would be nice is something like this worked:


//sphere-struct
#macro Sphere(name, _centre, _radius)
  #declare name&_centre = _centre;
  #declare name&_radius = _radius;
  sphere{name_centre, name_radius}
#end

object{
  Sphere("first", <0,0,0>, 1)
  texture {pigment{rgb 1} finish {ambient 1}}
}

camera {
  location <0,0,-5>
  look_at <0,0,0>
}

#debug concat(str(first_radius,0,0), "\n")

Post a reply to this message

"ingo" <nomail@nomail> wrote:

> If we had a struct specific for spheres, we'd still need to initialize it and
> declare a sphere with it to later be able to identify that one specific sphere.

Well ... yeah.  But there are nuances to that, I guess.

We initialize blob spheres with a strength, so clearly we have an extant data
structure for spheres and cylinders that we can use/abuse to hold "metadata".
There's also the matter of automating such entry into arrays vs manual entry.
For automation, we need "handles" to grab things by and place them into the
array.
If primitives were assigned ID's when they were parsed (let's ignore any CSG
hierarchy for now), then there would be at least that.  I can run a #for loop on
everything if there were a last_assigned_id keyword or a way to check for an
undefined id.  And that way nearly everything would have a unique id (again,
ignoring CSG)
Also, returning to the idea of having a point {} primitive or a whole
point_cloud {}, it would make it vastly easier to put a specific coordinate
location into an array if the ability to do something like
center {sphere <x, y, z> Radius translate, rotate, scale, etc...}
were possible.  As it stands, I'd have to go through a whole rigamarole to
figure out exactly where that sphere center ended up, before I placed the value
into the array.
Then a year and a half later, when I wanted to do the same thing, I'd have to
excavate that code, remember how it worked, if the HDD it was on wasn't dead,
..... etc.

> When I need something like that I use an external program to generate a large
> array with struct like data and generate the spheres from that with a macro
> loop. The index of the sphere is then the identifier. All sphere parameters are
> accessible and modifiable through the array. Multiple sphere types, like your
> isotopes, are then multiple type specific arrays. You could also put your
> metadata in an/the array.
>
> If we had structs, we'd put structs in the array(s) just the same way.

Yes, of course, there's (almost) always "a way".
And this was exactly the answer I was expecting to be brought up by - someone.

The point is, that it helps people, especially new users, accomplish a task,
quickly and relatively easily, without tearing their hair out and screaming "F
POV-Ray, who uses this stupid program?"
What you propose is certainly an option, but I have a disdain for detachable
include files that can get lost or undergo versioning chaos, and as we all know,
SDL is SLOOOOOOW.

So yes - putting everything into arrays is the way to go.  But the question is:
how do we initially _get_ everything into the array?

It's fine if you have coding experience, and have the forethought and
organizational skills, and discipline to make it all happen, AND you're starting
from scratch.  But if all I want to do is use a sphere in a union as an
attachment point or center of rotation, then every time I transform that sphere,
I have all sorts of things to keep track of and calculate.  If I can just "grab"
that Nth sphere out of the union and instantly have that <x, y, z> coordinate in
hand, then it makes SO many tasks 1000 times easier.

What happens if Pavel Rae posts a nice scene that's all spheres and cylinders,
but I want to use the same assembly as a mesh?  Forget about the actual
conversion to that data structure - I don't even have access to the point data
yet.

And that's what people want.  We don't have a modeler, we don't have a GUI - so
we need _something_ to make the end-user experience ... better - or else we're
not competing in the marketplace of ideas and features, and computer graphics
power.

I hate gift cards, because the representative value is locked into one purpose.
$20 on a Wendy's card doesn't allow me to buy $20 of gas if I need it more than
a fast food lunch.  Currency is easily exchangeable for anything.  And what I'm
suggesting is looking at the data that's in a scene file as currency, not
informational value that's locked into a digital gift card because "that's what
the user intended it for".

You know I'm not just idly complaining, or lazy, or unmotivated - but sometimes
I would love to just be able to accomplish a task in an afternoon or a weekend,
rather than over a 5 year period, because the informational tools that I need
are within reach.  I'm sure I've delved into topics that people with actual
degrees in computer science haven't covered, or at least not to the depth I've
explored them.  And while I've learned a lot, and am better for it, sometimes it
would just be nice to let an idea flow, and come to fruition without having to
start another PhD-level investigation into matrices, calculus, tensors,
statistics, floating point math....

All this is just to brainstorm ideas and potential approaches.
We could even have a separate parser for all I care, that can handle the
analytical and algorithmic tasks separately, and be run separately, so as to not
further complicate the central code base.

But having certain tools available changes everything.
Try to copy something without ready access to a photocopier, scanner, or cell
phone camera.
Boom - you're back in the 1970's.

And I understand.   We don't have a developer.  We have 30 years of macros and
include files to sift through, and vast libraries of unexplored routines that
haven't even been converted to SDL, let alone implemented in source.

I'm just thinkin' out loud.

Post a reply to this message

"Bald Eagle" <cre### [at] netscapenet> wrote:
> "ingo" <nomail@nomail> wrote:
>
> I'm just thinkin' out loud.

I hear you, loud and clear.

Ok, this gets wild. The Nim programming language
https://nim-lang.org/docs/manual.html has 'real' macros. They can be used to
create a complete language. That language can be POV-Ray like. Using that you
can output POV-Ray SDL, loops unrolled and all.

The language is compiled, but it also has a interpreted script part, that is the
same language. The compiled part and the script part can be "linked". That way a
complete front end for POV-Ray could be build and you'd have a type system,
objects =structs, minimal OOP (only composition) and it looks a bit like python
but way faster. Sadly I'm way to incompetent to get something like that
together.

This is the mesh macros in nim:
https://gist.github.com/ingoogni/ca030e955daf7f8138cedfe488ca0013

Why I think of things like this? Because the effort of writing all those arrays
and remembering what they do and how they interact often gets too much (age).

ingo

Post a reply to this message

"ingo" <nomail@nomail> wrote:
> "Bald Eagle" <cre### [at] netscapenet> wrote:
> > "ingo" <nomail@nomail> wrote:
> >
> > I'm just thinkin' out loud.
>
> I hear you, loud and clear.
>
> Ok, this gets wild. The Nim programming language
> https://nim-lang.org/docs/manual.html has 'real' macros. They can be used to
> create a complete language. That language can be POV-Ray like. Using that you
> can output POV-Ray SDL, loops unrolled and all.
>
> The language is compiled, but it also has a interpreted script part, that is the
> same language. The compiled part and the script part can be "linked". That way a
> complete front end for POV-Ray could be build and you'd have a type system,
> objects =structs, minimal OOP (only composition) and it looks a bit like python
> but way faster. Sadly I'm way to incompetent to get something like that
> together.
>
> This is the mesh macros in nim:
> https://gist.github.com/ingoogni/ca030e955daf7f8138cedfe488ca0013
>
> Why I think of things like this? Because the effort of writing all those arrays
> and remembering what they do and how they interact often gets too much (age).
>
> ingo

Sorry to cross over if it's off topic, but about Nim, I asked a question on
this, or maybe something else depending on what you meant... in the other thread
I had started about curly braces / indentation scoped languages. thanks for
sharing your discoveries.

Post a reply to this message