POV-Ray : Newsgroups : povray.binaries.images : Isosurface from magnitude of complex function with domain coloring : Re: Isosurface from magnitude of complex function with domain coloring Server Time
25 Apr 2024 10:01:03 EDT (-0400)
  Re: Isosurface from magnitude of complex function with domain coloring  
From: Bald Eagle
Date: 26 Dec 2021 09:30:00
Message: <web.61c87bcf6041c6701f9dae3025979125@news.povray.org>
"Tor Olav Kristensen" wrote:

> Thank you Bill !

Knowing partly what goes into all of this, I can see that it required a lot of
time and attention to detail - and you always post fairly polished images, even
if they are only WIPS.

>

> I'm not very familier wit Paul Nylander's work. Those macros seem like a good
> start for a library for complex calculations. But the Pow() macro could need
> some work to allow for the exponent to also be a complex number.

http://bugman123.com/index.html

Complex exponents --- Oh, it makes my head hurt to even thing about that.

> I did not create macros to do the calculations, but arrays of functions and
> macros that assemble functions into new functions. For each complex operator
> there's two functions; one for calculating the real part and one for calculating
> the imaginary part.

Yes, since you are doing isosurfaces, it would have to be that way.
Not having done a great deal personally with complex math, I wasn't about to
start writing things from scratch, and wanted to just see what "known good code"
would spit out.

>
> >...
> > I made these two to just keep track
> >
> > #macro Argument (Re, Im)
> >  atan2 (Re, Im)
> > #end
> >
> > #macro Modulus (Re, Im)
> >  sqrt (pow (Re, 2) + pow (Im, 2))
> > #end
>
> I like your Modulus() macro better than the Abs() macro, because it does not
> rely on the underlying implementation of how the complex numbers are
> represented. I think that as few as possible of the macros should depend on the
> underlying implementations.

I was just working off of the definitions of the terms.  Sometimes I mix and
match things without worrying about things too much, just to see what works
without overcomplicating things early on.

> Btw.: Why have you chosen to have a different
> atan2() call in your Argument() macro than in the Arg() macro ?

I believe the first one is Paul's, and the last one is one I wrote from scratch.
 Again, just from definition of the term.  If that gave rise to any "errors" - I
figured I could go back and fix them once I had some geometry rendered to
visually see what the problems were.


> > This is looking great!  I'm sure there are a lot of other interesting complex
> > surfaces to be explored.
>
> I've started on a Github repository for my library. It's here:
> https://github.com/t-o-k/POV-Ray-complex-functions
>
> Please note that this is a work in progress, so some features hasn't been added
> yet and much of it may change.

Nice.   That would probably be well suited to printing out and looking over
during coffee break.

> > I'm also wondering how hard it would be to use mod()
> > to have an infinite array of those "black hole vortices" on a plane - in either
> > a rectangular or an alternating/hexagonal arrangement...
>
> That's an interesting idea: to have a mod() operator that can handle complex
> values. But I don't know how to implement that...

Naive question: Wouldn't you just process the Re and Im parts with mod first
before passing them on to the subsequent functions?


Maybe check out
http://www.dimensions-math.org/Dim_E.htm

and perhaps get in touch with the authors, since they seem to have an amazing
grasp of both the math as well as POV-Ray.


Post a reply to this message

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