POV-Ray : Newsgroups : povray.text.scene-files : bounding box calculator : Re: bounding box calculator Server Time
23 Feb 2024 03:10:34 EST (-0500)
  Re: bounding box calculator  
From: jr
Date: 3 Nov 2019 13:35:00
Message: <web.5dbf1ce734d8ef06feeb22ff0@news.povray.org>

"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.
> So the issues I'm running into currently, are that SDL doesn't have the syntax
> needed to replicate statements in python or c++, or POV-Ray simply doesn't have
> the ability to perform certain of the operations.

unfortunately I'll not be much help there, I do not speak c++ nor python.
however, the SDL is Turing complete aiui.  (though too cumbersome for all sorts
of stuff)

> So I need to interpret certain statements to first even understand what they do,
> and then rewrite those parts in a way that can be performed in SDL.
> for (std::uint32_t row = 0; row < m_size && (index % 100) == 0; row++)
> m[row].resize(m[row].size() + 100);
> etc.

what is it you're doing that requires a row to grow?

> That's why I figured using the existing, working, tested libraries in c++,
> python, Fortran, Ruby, R, Matlab, etc. would be fastest and most reliable.
> I mean I could be wrong, but I think it would pay dividends.
> And I still can't understand why the value of the FFT isn't understood.  ALL of
> the major graphics packages use FFT for myriad effects, edge detection, etc...

back to the subject on hand.  the problem would be having to scan points on the
surface of a sphere, with some precision/resolution, followed by consecutively
smaller spheres, until "contact".  what did I miss?

regards, jr.

Post a reply to this message

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