Welcome to Fractal Forums

To break my death grip on Timeroot's thread about alternate coordinate systems (http://www.fractalforums.com/theory/alternate-co-ordinate-systems/ (http://www.fractalforums.com/theory/alternate-co-ordinate-systems/)), I decided to start a new thread here. Not sure if I should have stayed in the sub-forums of the Mandelbulb department. But the fact remains that this fractal isn't quite the Mandelbulb, despite stealing all of those ideas. :-)

For explanations, formulas and even a few first tantalizing images, refer to Timeroot's linked thread above.

Now on to the new information. As I was debugging my own rendering code, I stumbled upon an odd and interesting image of what seems to be the inside of the riemandelettuce. The image itself doesn't have a straight forward meaning as an inside view, but is more of a weird kind of volume rendering, so take the appearing shapes with a grain of salt.

I found it noteworthy to see that there is a very large amount of "dust" filling the space between the minibulbs, obscuring the shape of the solid inside. A relatively high number of iterations is required to get sharply defined outlines of the solid inside (more than 100 in this case).

Looks promising, however, it needs a non-Zdepth-only render :)

Oh, I can render the usual outside views by now. They are not as pretty as the pictures done already by other people, but they suffice as evidence that at least three different rendering algorithms agree on essentially the same shape. (With a shifted coordinate origin in this particular example, which is why it isn't perfectly symmetrical.)

But I need to extend my distance transform to a signed distance transform, and I need to somehow isolate the solid from the dust in order to render surface views of the solid core of the riemandelettuce.

Okay, at long last, here is the first animation of the riemandelettuce. No artistic value, and the lighting is more of a bug rather than a feature.

http://www.vectorizer.org/riemandel1.mpg (http://www.vectorizer.org/riemandel1.mpg)   (3 megabytes)


The underlying voxel cube was sampled with 1000^3 voxels, with an iteration depth of 1000 iterations. The coordinate origin was slightly offset to break the perfect symmetry. I guess sampling missed thin sheets and filaments, which is why the north pole looks quite different than Jesse's renderings. Still, there are a lot of bits and pieces, and the overall feel is more solid than dusty. The arches between the 'bulbs are a nice touch.

I actually meant, that volume/inside/whatever-render should not only be a Z-depth-like render which doesn't show that many details...
The animation looks nice :)

The same in "high definition": http://www.vectorizer.org/riemandel1hd.mp4 (http://www.vectorizer.org/riemandel1hd.mp4)  (12 megabytes)

looks really good :)

Okay, here's the promised "too high definition" version.

The rotation is a bit slower, and the object tumbles so that you can take a close look at the pole and the antipole. The underlying volume was sampled on a 1600^3 grid. The 2d views were rendered with 4x4 supersampling on a jittered grid (to reduce the aliasing caused by the high voxel resolution). The lighting is still buggy, and no concern has been given to aesthetics. The bit rate is rather high, because some of my local friends complained about compression artifacts.

http://www.vectorizer.org/riemandeltumble2hd.mp4   (WARNING! 99 megabytes for an 1m20s loop)

This is pretty much the resolution limit for my brute force approach. As much as I would like to do close-ups and fly-bys, I cannot really do that with my current code base.


BTW, to those of you who are hunting for formulas with their own programs: if you are interested in doing quick and dirty animations (like the ones I have shown here), I would be willing to share my code. I am not particularly proud of it, but with a bit of cleaning up, I could probably let it loose upon the world without causing too many headaches ...

My code consists of a number of command line tools written for a unix environment, with the only "user interface" to speak of being a makefile. There are probably a few BSDisms in there that need fixing for Linux, but nothing too major.

If you are interested in toying with this kind of thing, drop me a note or a reply.

Really nice render Hobolt!

I see what you mean, that this thing is really noisy and it would be interesting to see the shapes of the inside...

There seems to be a lot of unconnected parts, is it so or are they really connected?

I suspect that all the chunks are connected by thin sheets or filaments. But my algorithm cannot capture such structures, they are lost between the sampled grid points.

I must apologize that I cannot uphold the artistic standards that many other fractal explorers are setting. But my first glimpse on the back side of the antipole was just too surprising to withhold it. This is part of the riemandelettuce as seen from outside and inside. Reminds me of classical architecture, but without columns to carry the dome.

http://www.vectorizer.org/insideAntipole.mp4 (http://www.vectorizer.org/insideAntipole.mp4) (15 megabytes)

Hobold, that is absolutely not true, its a different thing to display such details in comparison to the DE thresholded images.
If i would try to get this informations, i wouldnt get as good results as you!


Great, are these little dots caves inside the bulb?

Some of the little bubbles should be cavities (not all of them; some are clearly an artifact of cutting the shape open). That's if my code is free of bugs. But I personally would not bet on it.

I have done a similar animation of the polar region, but that one looks less interesting. And it exhibits some very obvious render bug, where apparently some rays overshoot and miss the surface. In theory, it should be impossible for my algorithm to overstep, but obviously theory and practice are the same thing only in theory. :-)

A very nice video :D

Well, most of what I present here are drafts. You and others put a lot more energy into finding good view points than I do. Instead of fixing the bugs in my renderer, I breathlessly throw more half-baked animations at you.

My renderer doesn't even provide any good depth cues. Except movement, that is. But if you halt one of my animations, the image immediately falls flat. Nor did I try to use colour to emphasize structures, like most of you are doing. So I am quite sure that I can objectively prove that my production of flickering pixels so far is just not in the same ballpark, with regards to the quality of visualization.

Maybe I am just too lazy, but I don't feel like I can ever catch up with the intuition for beauty that other fractal explorers have achieved. And so I set another goal for myself: produce images that are just good enough to pique the curiosity of you guys. If I can provide you with some inspiration for your work, the net result will be more numerous and more interesting imagery than if I strive to do it all perfect by myself.

And i dont want you to stop doing it  :dink:

At least, these detailed videos are totally impossible for me to do, not to mention the inside view. So these are valuable informations that were never shown before.

In that case ... here is the very same in a bit more detail:

http://www.vectorizer.org/insideAntipoleHD.mp4 (http://www.vectorizer.org/insideAntipoleHD.mp4) (40 megabytes)

Cool!

Your renderings looks so scientific! :)
I like "the  dust" around it too, as if it was just broken up.

I'd love to see something similar with a mandelbulb... but you know that already! ;)

J

I think they are rather bland and arbitrary, but I have fun hunting for new impressions. If some of you like this stuff, just the better!
My computer is thinking about that. :)

Another closer zoom on the antipole. It's interesting that some of the "bridges" ends don't meet, but are slightly tilted.

http://www.vectorizer.org/insideAntipole2HD.mp4 (http://www.vectorizer.org/insideAntipole2HD.mp4) (50 Megabytes)


I'm going to take a break from rendering, and spend my brain cycles thinking about the octree approach. But I'll be back ...!

The break was longer than anticipated ... and it wasn't going to be an algorithm based on octrees. Instead I am now using Syntopia's idea of brute force raytracing. Here is a high resolution view orbiting around the thing:

http://www.vectorizer.org/rmdltc/rmd8tumbleHD01.mp4

Iteration depth is a mere five, but the number of samples per ray is 1000 (with biased distribution), and there are sixteen rays per pixel. As usual I didn't pay much attention to realistic lighting or any artistic touch. Still looks infinitely better than the results of my old and lousy renderer.

A closer look, from a lower orbit, medium quality render: http://www.vectorizer.org/rmdltc/orbiting001.mkv

With animations now being computed frame by frame, I can animate parameters of the formula. For example this idea of moving the origin of the monopolar coordinate system. This is analogous to the difference between the sine and the cosine variants of the mandelbulb, with smooth transitions between the two.

Advance warning: this may look a little creepy, or gross, or disgusting, as the smaller bulbs are swirling around the object.

http://www.vectorizer.org/rmdltc/origin001.mkv

Still interesting, though. :)


I tried some inside renders as well, but those came out foggy and very noisy, as if there was dust inside. I don't know yet what went wrong.

I think it looks lovely!  :o O0 :o
I had to download to be able to see it though...

Oh, I find it gorgeous as well! Just wanted to soften the blow for viewers who don't
react well to fractals that look too organic and weird. Those can trigger ancient fears
sometimes ...


Yeah, sorry about that. The Matroska video containers (.MKV) are a compromise. A friend
of mine couldn't see the .mp4 or .mov videos, so I settled for some well established open
source format as my default.

Another low orbit flyover. This time a slowly morphing power 6 variant:

http://www.vectorizer.org/rmdltc/power6orbit001.mkv

BTW, Happy Holidays! :)

Low altitude power 8 animation loop, high resolution, no animated parameters:

http://www.vectorizer.org/rmdltc/orbiting003.mkv

Have made some progress porting the optimized brute force raytracer to OpenCL, but currently stuck with what might turn out to be a bug in OpenCL's atan2() implementation.

One more low altitude fly-over. This time in slow motion, so that the viewer has a chance to take in more details. The morphing of shapes is again caused by moving the coordinate origin, but this time the amount has been toned down. There is now a chance to visually parse what is going on ... at least I hope so. :)

http://www.vectorizer.org/rmdltc/slomorbit01.mkv   (90 seconds, almost 120MB)

Render time was twelve days. I still don't understand why the OpenCL kernel does not produce the same results as the almost identical scalar C++ function. :sad1:

It feels HUGE!
Imagine living on an unstable planet like that!

If only I could speed up rendering to a point where it makes sense to turn it into an application and hand it over to artists like you. THAT would be huge.

BTW, I had decided to render this one "upside down" on a whim, in order to trick myself out of seeing the same old, same old shapes. And the lighting was placed at grazing angle to emphasize the overall roughness (that didn't work out too well, though; too dark all in all). Perhaps it is no coincidence that you used the word "planet" rather than "landscape" - it would be my very first successful application of artistic design decisions. :)

(Beware: replying to my ancient thread.)

I rewrote my brute force renderer and updated lighting a bit. As a side effect, I made a new beauty shot of the Riemandelettuce:

(http://vectorizer.org/rmdltc/hiSky004.png)

I hadn't really planned to work on lighting this time around, but on further statistical improvements to the brute force rendering method. I have worked out the formulas for a sample biasing on steroids, but have yet to test it. The general idea is to compute the image from coarse to fine resolution. Then you can concentrate samples of unknown pixels at a distance of nearby hits. I'll be back with more information if this turns out to actually work.

Pretty impressive detail for a brute force render (I had to open the image in a new tab to see it 1:1 though); any details for us? E.g. CPU/GPU used, step sizes, ...

I'm working on a DE renderer and am quite unhappy with a lot of the rendering artifacts, especially when reflecting off smooth surfaces. I'm thinking DE to approach the surface alone won't be enough, one actually needs to go through the surface and then do root refinement (else reflections have steps).

Regarding your course->fine method, that sounds like a good way to do the primary rays, but for global illumination those are a very small % of the total rays cast, so it wouldn't help if you want high quality illumination.

it looks really good!
@hobold is this related? http://www.fractalforums.com/fragmentarium/ray-histogram-fusion/
@lycium is this related? http://www.fractalforums.com/programming/fast-fake-montecarlo-for-raymarching-%28not-sure-what-to-call-it-yet%29/

Nah, I don't like hacks and tricks :) My style is more "do it right, make it efficient, then throw lots of compute power at it" :D

I just plugged in a GTX 970 today, it's insane... you can do a lot with 4.4 teraflops of computing power! Example renders coming Soon (TM).

I largely followed Syntopia's non-DE renderer described in this thread:
http://www.fractalforums.com/3d-fractal-generation/rendering-3d-fractals-without-distance-estimators/
with minor statistical improvements: golden sampling, bisection refinement, and sampling restart after hit.
All in boring sequential C++ code (with multithreading across image rows, of course).

Lighting is all done in screen space on the depth buffer, also largely following Syntopia's lead. In my case the depth buffer contains euclidian distances in world space (from eye to target point), not a z coordinate of some camera transform. Like my earlier images, most of the lighting is contributed by a simple dot product of the surface normal with the direction towards an infinitely distant light source (not Phong's algorithm, but effectively the same shading).

Two small improvements made a huge visible difference. One is a highlight based on the reflected view ray. If the reflected direction comes close to the infinitely distant light direction, the overall color is faded towards pure white (there are the usual "roughness" and "intensity" parameters to control the size and strength of the highlights). Due to the fractal nature of the surface, this does not give the usual "glossy plastic" look, but has a tendency to brighten areas of pronounced tiny detail.

The other small improvement that made a big difference to overall perceived "solidity" is an embarrassingly simple fake of global illumination. Based on the "up" component of the surface normal, I vary the color of the added filler light. Object parts facing upwards get blue-ish light (think sky), downward facing get reddish-brown (ground or floor), and surfaces facing the horizon get neutral grey (the average of "top color" and "bottom color"). Interpolation is linear between the three.


Finally, the biggest improvement to the visible depth of the overall image, is a BLATANTLY WRONG and non-physical trick. Like Syntopia, I compute a fake occlusion factor that takes on values from 0.0 to 1.0 and selectively dims more distant parts of the surface if many neighbouring pixels are nearer. HOWEVER, I do not just multiply ambient light with occlusion. I also dim direct light with a down-weighed occlusion factor (i.e. an occlusion factor that is dragged a bit towards 1.0). This is BLATANTLY WRONG, but had the beautiful effect of making the direct lighting softer (i.e. now looking like an area light rather than a point light) and bringing out a ton of detail everywhere.

So I must disappoint lycium again. No breakthrough here, just pretty fakes. They do hold up reasonably well in animation, too. But computation times are completely unreasonable at the quality level of the beauty shot above, so I have no re-rendered animations to show yet. As I wrote earlier, a potentially very effective speedup should be possible, but it'll take me another while to set up that experiment.

The problem with these fake lighting methods is that the shadows will be inconsistent and often swim around as your camera pans/zooms (esp without extra pixels on the edges, which no one does for some reason). And I can't say I'm disappointed, just curious :) I'm from the offline rendering school, just a different approach.

One thing though, for 3D fractals it's pure computation / FLOPs and almost no memory access if you do it straightforwardly. This maps well to GPU computing, and then suddenly CPU rendering becomes completely meaningless in the face of ~300 euro 4 teraflop GPUs. Once you've tasted that power, there is absolutely no going back...

Fakes are fake, no way around it. But when I wrote that the fakes hold up well, I meant this:
http://vectorizer.org/rmdltc/tumbleLow001.mp4 (http://vectorizer.org/rmdltc/tumbleLow001.mp4)

Please excuse the low resolution and all the noise :) and just pay attention to the very limited appearance of creeping shadow clouds and the like. It's nowhere near good enough for hollywood, but it'll suffice to go hunting for more formulas without proper distance estimates.

Lovely render of the Riemandelettuce Hobold!

@hobold that animation looks promising, a little rough around the edges but the lighting looks good. :)
@lycium hack or trick I think it's a deeper reinterpreting of the data for better image quality (rhf) and maximizing the opportunities at the end of the ray (soc). I have been debating weather I should get another GTX760 (SLI for 2) or to invest in one bigger card  :-\

Just a short update on the "coarse to fine" idea.

The important thing is that it works, albeit not in the way I would have liked. It is very effective against the "rough edges", and generally reduces noise in regions of "dusty" detail. Overall image quality improvement is equivalent to increasing the number of sample maybe four or five times, while processing time increases only 10% or so.

Unfortunately this speedup cannot be used to further reduce the number of samples; brute force rendering simply requires a minimal number of samples to work at all. But higher levels of brute force do see a speedup.

I should do a proper writeup eventually. But since this works so nicely, I'll present the basics here so that other programmers can start tinkering with the idea.


1. The algorithm is recursive. In every iteration, horizontal and vertical resolutions are doubled. (I implemented it the other way round: with a full resolution image buffer and a power-of-two stride to neighbour pixels. The stride is halved after each iteration, and the image buffer is filled from sparse to dense until finally all pixels have been set.)

2. At the beginning of one doubling, the pixel buffer conceptually looks as if it is made up of many small 2x2 tiles, of which the top left pixel is already set, and the other three will be computed.

3. The first of two steps is to compute the bottom right pixel of every 2x2 tile. For that we can use four existing diagonal neighbours, as those are all top left of their respective 2x2 tile.

4. The second step computes both the top right and bottom left of each 2x2 tile, with the help of four horizontal and vertical neighbours.

5. In both cases, I simply use the minimum distance (from the eye/camera) of the four neighbours to set up a function that biases sample density. Samples are concentrated around the minimum neighbour distance, but cover the ray from eye point all the way to the given maximum view distance. So if there is any small contiguous object in front of other structures, we have a much higher statistical chance to hit it with rays through adjacent pixels. This is particularly true for the boundary of any object, i.e. its outline in front of an empty background.

6. There is an optional "third of two" steps. We can now check the top left pixel of each 2x2 tile. If any of the newly computed eight neighbours is nearer, it might be beneficial to re-sample that pre-existing pixel with an appropriately biased sample distribution. I am doing this, but it didn't have a glaringly obvious effect.


Now for the hard part: biasing samples to cluster around a desired distance.

For the sake of efficiency, I chose the actual warping function to be a third degree polynomial. This is the lowest degree that can meet all required constraints, but has enough degrees of freedom left to choose focus distance and sample density at the focus.

Crap. I just notice that I don't have the finished formulas with me. The derivation was too complicated that I could do it again on the spot. I'll be back here within a few days ...

Pretty sure I saw this described in the pouet raymarching thread (or one of them at least)... I think I saw you posting there too, or was it someone else? (definitely saw knighty there!)

No, that was not me. But the novelty is not in the recursive refinement, only in the specific use of neighbour's distances. Which I have yet to describe here (it involves inverting a rational function with an additional free parameter - could not have done that without Wolfram Alpha's help; cannot even remember the result offhand).

I am no regular on pouet, but I do recall a "paper" presented there which did something similar using distance estimation. They used the computed free distances not just to march along a single ray, but utilized the whole unbounding sphere to advance several adjacent rays, too.

I'll spare you the mathematical derivation and jump straight into code. But a few notes on intended usage first.

1. The scenario is that you start with uniformly distributed samples in the interval [0.0 .. 1.0] and want to concentrate samples around a given point p (also from [0.0 .. 1.0]) with a given sample density.

2. Biasing samples is cheap, but initializing a focused warp is expensive. Do not recompute a warp after each sample, but warp a few dozen samples to amortize this cost.

3. The code here fails when the focus distance is exactly 0.0 or 1.0, but works for all inner points of the interval. That's why there is an initWarp() without parameters; this is the old one that biases samples towards the hit point (the 1.0 end of the unit interval).

// encapsulates specific warps of density functions, which concentrate
// sample points near a desired focus point
class DensityWarp {
public:
  DensityWarp() {
    initIdentity();
  }
  
  ~DensityWarp() {}

  // warp sample points according to initialized polynomial
  double warp(const double Value) const {
    return ((a*Value + b)*Value + c)*Value;  // d is implied as 0.0
  }

  // map desired height to required saddle position (internal)
  double height2pos(const double Height) const {
    const double& x = Height;  // abbreviation
    
    const double subExpr = cbrt(-2.0*x*x*x + 3.0*x*x +
            sqrt(x*x*x*x - 2.0*x*x*x + x*x) - x);
    
    return cbrt(2.0)*(9.0*x - 9.0*x*x)/(9.0*subExpr) - subExpr/cbrt(2.0) + x;
  }

  // map desired height and slope to required inflection position (internal)
  double height2pos(const double Height, const double Slope) const {
    const double& x = Height;  // abbreviation
    const double& s = Slope;
    
    // common subexpression
    const double cx =
      cbrt(sqrt(4.0*cb(-3.0*s*s + 3.0*s - 9.0*x*x + 9.0*x)
      + sq(-54.0*s*s*x + 27.0*s*s - 54.0*x*x*x + 81.0*x*x - 27.0*x))
      - 54.0*s*s*x + 27.0*s*s - 54.0*x*x*x + 81.0*x*x - 27.0*x);

    return (1.0/(3.0*cbrt(2.0)*(-2.0*s - 1.0)))*cx 
      - (cbrt(2.0)*(-3.0*s*s + 3.0*s - 9.0*x*x + 9.0*x))/(3.0*(-2.0*s - 1.0)*cx)
      - (s + x)/(-2.0*s - 1.0);
  }

  void initIdentity() {
    a = 0.0;  // initialize to identity mapping
    b = 0.0;
    c = 1.0;
  }

  // initialize to quadratic focus on far end
  void initWarp() {
    a = 0.0;
    b = -1.0;
    c = 2.0;
  }

  // compute polynomial with desired focus point and "infinite" density
  void initWarp(const double Focus) {
    const double p = height2pos(Focus);
    const double denominator = 3.0*p*p - 3.0*p + 1.0;
    a = 1.0/denominator;
    b = -3.0*p/denominator;
    c = 3*p*p/denominator;
  }

  // compute polynomial with desired density at desired focus point
  // Slope should be 1.0/Density, where a Density of e.g. 5.0 means
  // five times more samples than an unbiased distribution
  void initWarp(const double Focus, const double Slope) {
    const double& s = Slope;
    const double p = height2pos(Focus, s);
    const double denominator = 3.0*p*p - 3.0*p + 1.0;
    a = -(s - 1.0)/denominator;
    b = (3.0*p*s - 3.0*p)/denominator;
    c = -((3.0*p - 1.0)*s - 3.0*p*p)/denominator;
  }

  double a,b,c;  // cubic coefficients a*x^3 + b*x^2 + c*x  (d always = 0)
};

Thanks to the (approximately) fourfold speedup described above, it took "only" 16 days (on a total of ten processor cores) to render a high quality animation loop in FullHD resolution. It's still not perfect, but worlds better than my earlier attempts which were all so flat and sterile. Enjoy!

http://vectorizer.org/rmdltc/tumbleHD002.mp4 (http://vectorizer.org/rmdltc/tumbleHD002.mp4)

Now one can finally see the true amount of detail. While this isn't the holy grail, I find it interesting that there is visibly less whipped cream. Instead of losing fractal detail along both latitude and longitude, the Riemandelettuce is more like flaky pastry, losing detail along only one of the spherical axes.