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.
>
> 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,
>
http://news.povray.org/povray.programming/thread/%3Cweb.5db79f027e60be924eec112d0%40news.povray.org%3E/
>
> 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