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