[marcosscriven]

From the docs:

"It's important to note that When rendering with these infinitely-tiled images, the mapping that is rendered is actually the inverse of the function given. This is because it is prohibitively expensive to compute images of the function itself. (In fact, we are rendering a kind of "pull-back".) Specifically, when rendering a pixel in the image, the location of that pixel in the complex plane is passed to your function, which produces a complex value. That transformed value specifies a location in the original image. This procedure is fast, but plots the inverse of the function given. So, if you want to plot e.g. log(z), then you should instead put in e^z."

[brandonpelfrey]

Yeah, this seemed kind of "unfortunate" when I started this project, but it still turned out to be an interesting/fun toy.

The issue is that when you compute where f(z) sends each point in the complex plane to, you would need to color in the pixel corresponding to that transformed point. f() is user-defined, so it could be a very weird function that could cover some portions of the image we're trying to draw but not others, etc. Moreover, even if I had some kind of procedure for determining which x's to sample so f(x) lay inside the image we're trying to draw, it's not amenable to GLSL. This is typically referred to scatter vs. gather-type operations.