 |
|
|
|
|
|
| |
| |
|
|
|
|
| |
| |
|
|
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] anonymous org> 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
|
|
| |
| |
|
|
|
|
| |
|
|
