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
21 Jun 2024 00:12:32 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.


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

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.