POV-Ray : Newsgroups : povray.text.scene-files : bounding box calculator : Re: bounding box calculator Server Time
25 Feb 2024 07:06:02 EST (-0500)
  Re: bounding box calculator  
From: jr
Date: 4 Nov 2019 07:30:01
Message: <web.5dc018fe34d8ef06feeb22ff0@news.povray.org>
hi,

"Bald Eagle" <cre### [at] netscapenet> wrote:
> "jr" <cre### [at] gmailcom> wrote:
> > as I wrote, I'm game for collaboration.  if you can express the spherical
> > bounding you're thinking off as "pseudo code" at least, I'm sure we could work
> > on something.
> ...
> > that's an interesting thought, re-orienting the object.  need to think about
> > that.
> (*)  Well that's what I was getting at with the ellipsoid and the rotating
> calipers.
>
> Right now, you can imagine the the bounding box is determined in a very
> hands-off kinda way.   If you took a book that was not axis-aligned, and
> squeezed it with axis-aligned calipers, it would "straighten out" until it was
> aligned with the minimal width parallel to the axis of measurement.
> ...
> It has to do with analyzing the orientation of the vectors - the trace ()
> results that you get from your "scan".

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.

> ...
> This goes by many names, but I found Singular Value Decomposition (SVD)
> but I guess there's Principal Component Analysis (PCA), Eigen Value
> Decomposition, etc.  Which can be different but are more or less equivalent and
> are often used interchangeably.
>
> Over here (1/4 to 1/3 of the way down):
> https://blog.statsbot.co/singular-value-decomposition-tutorial-52c695315254
> he says, "Suppose we have two, two-dimensional vectors, x₁=(x₁,
> y₁), and x₂=(x₂, y₂). We can fit an ellipse with major
> axis, a, and minor axis, b, to these two vectors as shown in the figure."
>
> And then look here at the 7:00 mark:
> https://www.youtube.com/watch?v=_4jaLZCoLPI
>
>
https://www.youtube.com/watch?v=PFDu9oVAE-g&list=PLZHQObOWTQDPD3MizzM2xVFitgF8hE_ab&index=14

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.

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

chorus: "Oh no, they're not."  :-)

> Well, yes - and no.  Because I can already see an application to your sphere
> slicing troubles in POV-Ray, the existing root-finding problems that Bill
> Pokorny is grappling with, and SVD.
>
> If the problem with your sphere slicing arises from root-finding troubles that
> POV-Ray experiences when trying to solve for rays that are parallel, or nearly
> so, to the object surface, then maybe if you added a "wiggle" to the object,
> solved for the root, and then unwiggled the intersection before rendering the
> result - then you'd get better renders with less holes.

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

> So if we implemented it in source - them maybe it could be applied to solve a
> lot of long-standing, underlying problems.  Or something like it.

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.

> ...


regards, jr.


Post a reply to this message

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