POV-Ray : Newsgroups : povray.text.scene-files : bounding box calculator : Re: bounding box calculator Server Time
5 May 2024 12:57:13 EDT (-0400)
  Re: bounding box calculator  
From: Bald Eagle
Date: 4 Nov 2019 14:50:06
Message: <web.5dc07fe634d8ef064eec112d0@news.povray.org>
"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

Copyright 2003-2023 Persistence of Vision Raytracer Pty. Ltd.