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