"jr" <cre### [at] gmailcom> wrote:

> off the top of my head, write out the points/vectors to a CSV format file, then
> either use your spreadsheet-fu or describe the the necessary actions in kinda
> pseudo code so we can discuss whether/how to implement as a script/compiled
> utility.

From what I can gather, there are several approaches to this, and most of them
are iterative - which makes the spreadsheet thing difficult.
It's been a loooong time since I've written macros for spreadsheets, and the
last mammoth spreadsheet I wrote used _zero_ macros - for "security" (you can't
complain about having to enable macros, can you?) and as a sort of little
challenge.  ;)


> quick viewed the vids.  agree with 3Blue1Brown that "confusion" arises from
> having a "shaky" understanding of the basics.  :-)  (although a frown would be
> more appropriate)
>
> so, anything .. matrix you'd have to work through with me -- bite size.

Yeah, I've been watching Grant's videos for a while, and working through the
matrix stuff and linear algebra bit by bit for a while now.  I think there's
like 14 episodes in the linear algebra series, and if you just pop them on while
you're chilling out for a while, you'll get the gist and figure out which ones
focus on specific parts that make everything clear.   I usually cycle through 2
or 3 at a time and rewatch them so I can start to put it all together.

But like I said - all of the code exists already, so it's mostly a matter of
choosing whether to call it for use as an outside routine where the results are
then used by POV-Ray, finding a way insert the relevant code to perform the SVD
into a POV-Ray fork, or converting the code to SDL where anyone can play with
it.

But since the code is complicated, I'd rather have a reliable library that we
just implement to get the right results, so that if we decide we want to do the
work of converting it, then we can compare the output to what we know is right.
Otherwise debugging will be an unimaginable nightmare.

So I think it's less "understanding what SVD does and how it works" and just
blindly getting the code that does it to work for us.  Once it reliably spits
out the right numbers, then it's a toy/tool to use to learn what and how it does
it - if you want.

I'm envisioning a test scene where we take a unit sphere and scale it by 1/2
along one axis, by 1/3 along another, and then give it a < 45deg rotation around
all three axes.
When we "Undo" the rotations with SVD (which I think is what the eigenvectors
allow us to do), we already know exactly what we should end up with - the axis
aligned, scaled sphere (ellipsoid).

Using the
VRand_On_Sphere(Stream): Returns a random vector on the surface of a unit-radius
sphere located at the origin.
from rand.inc
and applying the scaling and rotations to those points (vectors), we can run the
SVD on that data and see what it does.



> > ...
> > "This is crazy, Bill."
> > (No it's not, Thomas - the dried frog pills are _working_!!!)
>
> chorus: "Oh no, they're not."  :-)

No really - TRY SOME.   :D
"Like, dude - if you thought that sRGB with radiosity was good, wait 'till you
see THESE colors...!"   B)

> I can "see" the concept, and like it.  potential problem: registration, to get
> exact re-alignment.

Well, I wasn't so much worried about that, as with how to integrate such a thing
with the ray-object root solver code.

Take any object, matrix transform it, and then just apply the inverse, and you
get exactly what you started with.

transform { Whatever }
followed by
transform { Whatever inverse }
is the same as doing nothing.

So the idea is sorta like trying to render the side of a cube that juuuuuust
slightly rotated so that you can just barely get a glimpse of the side that
rotated toward you.   Instead of trying to squint or zoom in to get a better
look, just rotate the cube the full 90 deg, get a solid unambiguous view of that
face, and then rotate it back once you KNOW what's there.

Eventually you can push things to the point where you run into rounding and
floating point precision, and propagated error - but that's true with everything
we do now.

> I'm working myself up to trying Bill P's custom POV-Ray soon.  but yes, support
> in the program source sounds like the way forward.

Well if you get it installed, give me some tips on how to shoe-horn it onto my
system.  I'm still not so good with the github and compile-it-yourself approach
to software installation.  For most things, I cross my fingers and hope that
there's a package.

Post a reply to this message

hi,

"Bald Eagle" <cre### [at] netscapenet> wrote:
> "jr" <cre### [at] gmailcom> wrote:
> ...
> So right now, I'm working off of this:
> ...
> and this:
>
https://www.codeproject.com/Articles/1268576/Singular-Values-Decomposition-SVD-In-Cplusplus11-B

had a quick look, the page appears to give you the lot.

thinking you ought to have a look at the GSL (GNU Scientific Library); I just
found an index entry for singular value decomp.

<https://www.gnu.org/software/gsl/>

regards, jr.

Post a reply to this message

"jr" <cre### [at] gmailcom> wrote:

> had a quick look, the page appears to give you the lot.

Right, it looked solid enough to pursue, though it will require a lot of
fiddling to adapt to SDL.

> thinking you ought to have a look at the GSL (GNU Scientific Library); I just
> found an index entry for singular value decomp.

I got that set up, and now need to learn how to use such things.

It appears that I have to write a c++ program and compile it, and then run it.


Looks like this guy has a short program written, where we could just delete or
comment out the Eigen stuff:

https://stackoverflow.com/questions/36959506/eigen-library-svd-is-slow-compared-to-gsl

If you can work something out that runs - tell me what format we need for the
data input - CSV would be nice ;) and then we can see what this thing _does_.

Can we run POV-Ray to #write trace() results to disk, and then call the c++ to
write the SVD data to a file?  Can that c++ program then restart POV-Ray to use
the SVD data? (have an if file exists block to switch between write data and
read data)?

Post a reply to this message

"jr" <cre### [at] gmailcom> wrote:
> ... I wrote a macro which "scans" an object's BB ...

find attached the second update of the 'Bounder'.

things have changed a little.  now, if the object's BB is found to be "(near)
optimal", the macro prints that and ends, otherwise, ie having some "slack", the
macro prints the difference lines as before, plus the optimised extents and
dimensions, as per Thomas's feedback.

also new, if "slack" is reported, two variables with the differences from the
BB's min/max extents are declared, to allow use of the info from in-scene.
after 'Bounder' has run, one can for instance:

#ifdef(Bounder_min_diff)
  // do something
#end

so.  version 3.  fingers crossed.


enjoy, jr.

Post a reply to this message

Attachments:
Download 'bounder.inc.txt' (9 KB)

hi,

"Bald Eagle" <cre### [at] netscapenet> wrote:
> "jr" <cre### [at] gmailcom> wrote:
> > had a quick look, the page appears to give you the lot.
> Right, it looked solid enough to pursue, though it will require a lot of
> fiddling to adapt to SDL.
>
> > thinking you ought to have a look at the GSL (GNU Scientific Library); I just
> > found an index entry for singular value decomp.
>
> I got that set up, and now need to learn how to use such things.
> It appears that I have to write a c++ program and compile it, and then run it.

'C', not 'C++'.  ;-)  (in an ideal world, anyway)

I think cutting and pasting that c++ code into a single source and getting that
to compile, or at least spit out errors, would be a good exercise, then.

> Looks like this guy has a short program written, where we could just delete or
> comment out the Eigen stuff:
>
>
https://stackoverflow.com/questions/36959506/eigen-library-svd-is-slow-compared-to-gsl

I'll look at that later.  one thing at a time.

> If you can work something out that runs - tell me what format we need for the
> data input - CSV would be nice ;) and then we can see what this thing _does_.

first I suggest get that c++ to build, as exercise.

I did not read the article too closely but am under the impression that if one
re-assembles the functions in one source file, it'll build.  do you want to use
this code as a starting point?  if yes, then that will determine/influence the
data format.

> Can we run POV-Ray to #write trace() results to disk, and then call the c++ to
> write the SVD data to a file?  Can that c++ program then restart POV-Ray to use
> the SVD data? (have an if file exists block to switch between write data and
> read data)?

yes, in all likelihood _but_ how's your 'C', Bill?  or are you .. wedded to
'C++'?


regards, jr.

Post a reply to this message

"jr" <cre### [at] gmailcom> wrote:

> 'C', not 'C++'.  ;-)  (in an ideal world, anyway)

I can't really ever tell the difference just by looking   :P

> I think cutting and pasting that c++ code into a single source and getting that
> to compile, or at least spit out errors, would be a good exercise, then.

.... a single source.  a .c file and then do a gcc compile to make a ... .bin?
..exe?


> first I suggest get that c++ to build, as exercise.

this one:
https://www.codeproject.com/Articles/1268576/Singular-Values-Decomposition-SVD-In-Cplusplus11-B

I have never "built" anything from scratch, so I really have no idea what I'm
doing or why.

> I did not read the article too closely but am under the impression that if one
> re-assembles the functions in one source file, it'll build.  do you want to use
> this code as a starting point?  if yes, then that will determine/influence the
> data format.

Sure, whatever.   but that guy's code is redundant to the gsl library.  If I've
already installed that - isn't that ... built? (*)



> yes, in all likelihood _but_ how's your 'C', Bill?  or are you .. wedded to
> 'C++'?

I used to write a bunch of stuff for different Arduinos - ATMega and Leonardo...
 still some confusion as to whether that's C or c++


But I'm sure I could learn.  I _would_ rather stick with one language, to
minimize confusion, and if POV-Ray source is in c++, then I'd prefer that, but
I'm sure one translates over to the other to some extent.

(*)

oem@oem-Inspiron-N5110 ~/Desktop $ apt-cache show gsl-bin
Package: gsl-bin
Source: gsl
Priority: optional
Section: math
Installed-Size: 63
Maintainer: Dirk Eddelbuettel <edd### [at] debianorg>
Architecture: amd64
Version: 2.5+dfsg-6~16.04
Replaces: gsl
Depends: libc6 (>= 2.7), libgsl23 (>= 2.5)
Conflicts: gsl
Filename: pool/main/g/gsl/gsl-bin_2.5+dfsg-6~16.04_amd64.deb
Size: 29470
MD5sum: d91cad88f7767c41d41d9194e79c5b51
SHA1: 722962da0169254fee7bc14b48b1ba948514df7f
SHA256: d2e80f2cabcdec706397145d324ea57c425b9184b1fb1afe8d80de711438468e
Description-en: GNU Scientific Library (GSL) -- binary package
 The GNU Scientific Library (GSL) is a collection of routines for
 numerical analysis.  The routines are written from scratch by the GSL
 team in C, and present a modern API for C programmers, while allowing
 wrappers to be written for very high level languages.
 .
 This package provides several example binaries.
 .
 URL: http://www.gnu.org/software/gsl/
Description-md5: 7553709bb194c39b6d774e61c06ec157
Multi-Arch: foreign

Package: gsl-bin
Priority: optional
Section: universe/math
Installed-Size: 62
Maintainer: Ubuntu Developers <ubu### [at] listsubuntucom>
Original-Maintainer: Dirk Eddelbuettel <edd### [at] debianorg>
Architecture: amd64
Source: gsl
Version: 2.1+dfsg-2
Replaces: gsl
Depends: libc6 (>= 2.7), libgsl2
Conflicts: gsl
Filename: pool/universe/g/gsl/gsl-bin_2.1+dfsg-2_amd64.deb
Size: 11250
MD5sum: d182e4dfa1ce45358d88dbf728871e3d
SHA1: b23fab8ea5f411ebfb6be076c0f43fd1271b613d
SHA256: 826ee499196a9fa12aabcd4ca66616334ae9abf8f11467c7b007f63666f56732
Description-en: GNU Scientific Library (GSL) -- binary package
 The GNU Scientific Library (GSL) is a collection of routines for
 numerical analysis.  The routines are written from scratch by the GSL
 team in C, and present a modern API for C programmers, while allowing
 wrappers to be written for very high level languages.
 .
 This package provides several example binaries.
 .
 URL: http://www.gnu.org/software/gsl/
Description-md5: 7553709bb194c39b6d774e61c06ec157
Multi-Arch: foreign
Homepage: http://www.gnu.org/software/gsl
Bugs: https://bugs.launchpad.net/ubuntu/+filebug
Origin: Ubuntu

Post a reply to this message

hi,

"Bald Eagle" <cre### [at] netscapenet> wrote:
> "jr" <cre### [at] gmailcom> wrote:
> > 'C', not 'C++'.  ;-)  (in an ideal world, anyway)
>
> I can't really ever tell the difference just by looking   :P
>
> > I think cutting and pasting that c++ code into a single source and getting that
> > to compile, or at least spit out errors, would be a good exercise, then.
>
> .... a single source.  a .c file and then do a gcc compile to make a ... .bin?
> ..exe?

one file, yes.  the usual extension is '.cpp'.  then compiling with:
  $ c++ myfile.cpp
should create an 'a.out' executable.

> > first I suggest get that c++ to build, as exercise.
>
> this one:
>
https://www.codeproject.com/Articles/1268576/Singular-Values-Decomposition-SVD-In-Cplusplus11-B
>
> I have never "built" anything from scratch, so I really have no idea what I'm
> doing or why.

now's the time.

> > I did not read the article too closely but am under the impression that if one
> > re-assembles the functions in one source file, it'll build.  do you want to use
> > this code as a starting point?  if yes, then that will determine/influence the
> > data format.
>
> Sure, whatever.   but that guy's code is redundant to the gsl library.  If I've
> already installed that - isn't that ... built? (*)

sure, but a library is just (a bag of) components.


> > yes, in all likelihood _but_ how's your 'C', Bill?  or are you .. wedded to
> > 'C++'?
>
> I used to write a bunch of stuff for different Arduinos - ATMega and Leonardo...
>  still some confusion as to whether that's C or c++

Arduino has a 'C' SDK afaik.

> But I'm sure I could learn.  I _would_ rather stick with one language, to
> minimize confusion, and if POV-Ray source is in c++, then I'd prefer that, but
> I'm sure one translates over to the other to some extent.

it does, and it doesn't.  while c++ was developed from c, and so has some vague
visual semblance, that exactly is a big problem -- people tend to overestimate
the "some extent".

from a practical point of view, forget the POV-Ray source for now, other than
for reading.  get working experience of the tool chain.

since I do not speak c++, I won't be too much help when, as we all do, you find
yourself in a battle with the finer points of the language, however, maybe Dick
Balaska will chip in.

> (*)
> oem@oem-Inspiron-N5110 ~/Desktop $ apt-cache show gsl-bin
> Package: gsl-bin

looks like you're good to go.  (effing weird this gratuitous splitting of
packages in to 'bin' and 'dev'.  but hey, "you pays your money and takes your
choice")


regards, jr.

Post a reply to this message

Op 04/11/2019 om 15:07 schreef jr:
> "jr" <cre### [at] gmailcom> wrote:
>> Thomas de Groot <tho### [at] degrootorg> wrote:
>>> ...
>>> - I include the test scene file for you to play with.
>>
>> thank you v much for this.  not only do I get those natty presentation settings
>> :-), but looking at the code I surmise you replaced the 'local's of the
>> difference vectors with 'declare's?  that's given me another idea for an
>> improvement: create two variables, 'Bounder_{min,max}_diff' and export
>> ('declare') them for in-scene use.  thoughts?
>

I did. Just changed #local to #declare.  ;-)
I suppose that using #local inside the macros is ok; #declare in the 
resuming section could be more useful for subsequent use.

> d'oh!  finally got the "why".  :-)  with yr permission will add the calculator,
> also will adopt the "proper" labelling in existing output.  thanks.
> 

Be my guest :-)

-- 
Thomas

Post a reply to this message

Op 04/11/2019 om 20:01 schreef Bald Eagle:
> Great job Thomas - those results are surprising, given the absolute mathematical
> nature of those shapes.
>

Thank you indeed, sir. I was curious to see if bounder.inc was universal 
or not. I assumed it was given the nature of the tests, and like you, I 
was surprised.

> I would have imagined that with something like a parametric, you'd be able to
> cycle through u and v real quick, and get a min and max value for each axis to
> use for the AABB dimensions.   I'm also still completely mystified as to why the
> parametric is such a slow-to-render object, and why the triangle approximation
> isn't a source-coded native primitive.
> 

These are mysteries on Earth and below the heavens which we may not be 
permitted to fathom...

-- 
Thomas

Post a reply to this message

Op 04/11/2019 om 09:09 schreef Thomas de Groot:
> - rotating the object changes the 'tightness' of the standard BB. I did 
> that with a simple cylinder: when properly aligned along one of the 
> axis, the BB test is always optimal; rotate the cylinder (e.g. 
> <45,45,45>) and do the test, and the standard BB becomes too wide.
> 

I have to correct this: The BB only becomes slightly less optimal in the 
example cited. With increasing complexity of the object however, 
optimisation kicks in.

-- 
Thomas

Post a reply to this message