DX11 Julia 4D

[Voxilla]

While I'm at it, here another fractal generator, this time rendering 4D Julia fractals.

I got the idea from Fellix, who suggested it in the Mandelbrot thread.

EDIT The shader code is now a direct port of the Cg version originally written by Keenman Crane.

 

[fellix]

Yay!
This thing should be quite branchy intensive.

 

[Voxilla]

Despite the complexity of the algorithm rendering speed is quite good at around 30 fps at 2560x1600.

I've just made a small update so the fractal can now be rotated with the mouse to have a better 3D view on it. The shape morphing can also be paused with the space bar for this purpose.

There are some oblivious shading artifacts, I'm not sure yet this is because of my port or because of the accuracy of the implementation.

 

[fellix]

Could someone make a screen video cap and upload it to YT for instance, so others with pre-DX11 systems can see some math beauty.

 

[Silent_Buddha]

Oh, that's pretty. Is there a way to slow it down?

Regards,
SB

 

[CNCAddict]

I'm gonna start to cry if someone doesn't post a video of this!! Super Kudos Voxilla for coding this up. I think you're the first to do any neato compute shader demos. Where is Humus

 

[Voxilla]

To tease you some more I've uploaded an enhanced version that fixes the rendering artifacts.
The shader code is now a direct port of the original Cg code instead of the Apple port.

The selfshadowing feature is now included as well and can be toggled with the S key.

 

[Mintmaster]

Voxilla, is there any advantage of doing this in the compute shader instead of the pixel shader? I always thought that this particular shader would be an excellent candidate for DX10.1's selective supersampling.

I guess double support will be useful if you want to investigate zoomed in portions of the set with a very high iteration count, but are they working yet?

 

[Voxilla]

Voxilla, is there any advantage of doing this in the compute shader instead of the pixel shader? I always thought that this particular shader would be an excellent candidate for DX10.1's selective supersampling.

I guess double support will be useful if you want to investigate zoomed in portions of the set with a very high iteration count, but are they working yet?

You mean doing this in the pixel shader I suppose, currently only a compute shader is used. What do you mean with the "selective supersampling", is this some MSAA ?

As this is ray tracing, you would need to shoot multiple rays per pixel, I think to get antialiasing.

Doubles are supported in shader 5, but there are some bugs in the Microsoft compiler preventing using them.

 

[Mintmaster]

As this is ray tracing, you would need to shoot multiple rays per pixel, I think to get antialiasing.

Of course, but you don't have to do it for the whole screen. I think there are only two situations where supersampling is needed:
1. After a ray hit, tif he normal is near perpendicular to the view direction, an edge may be nearby
2. When the distance function gets small (sub-pixel) but then starts getting large again, an edge is definately nearby

 

[DieH@rd]

Could someone make a screen video cap and upload it to YT for instance, so others with pre-DX11 systems can see some math beauty.

This.

 

[Voxilla]

Of course, but you don't have to do it for the whole screen. I think there are only two situations where supersampling is needed:
1. After a ray hit, tif he normal is near perpendicular to the view direction, an edge may be nearby
2. When the distance function gets small (sub-pixel) but then starts getting large again, an edge is definately nearby

I see what you mean. This fractal however has infinite detail, the more accurate you try to render edges the more of them you will find. As the current rendering is only a relative smooth approximation it may be worth investigation.
The problem can be considered rendering of an isosurface whose surface is at a certain distance 'D' from the fractal. To make it more accurate, a more accurate intersection with the isosurface would be needed. This could be done by an iterative approach similar to high quality isosurface volume rendering. Also for getting more accurate normals this would be needed. Once this is done right, adaptive supersampling near edges could be done as you describe.

 

[Voxilla]

I've just uploaded a new version 1.3.
This enables the software to run also on all DX10 GPUs.
In case no DX11 compute shader 5 can be run, a DX10 pixel shader 4 is used.

The animation speed is now also made independent of the speed of the GPU or the screen resolution. So the animation should look similar on all GPUs, only the number of rendered images per second can differ.

 

[Novum]

So how much faster is the CS compared to the PS on your HD5000?

 

[hoom]

Magnificent

I could stare at this for hours

 

[fellix]

Now, all I need is DC/OCL port of Apophysis!

 

[Voxilla]

So how much faster is the CS compared to the PS on your HD5000?

Good question. Now it automatically selects CS when possible.

I just did a test by forcing it to PS and to my surprise PS is faster than CS, 35 versus 49 fps (vsync off). I'm trying to think of a reasonable explanation for that, for the moment I can't.

 

[fellix]

I've just uploaded a new version 1.3.
This enables the software to run also on all DX10 GPUs.
In case no DX11 compute shader 5 can be run, a DX10 pixel shader 4 is used.

Black screen for me.

4890, Win7 x86, Cat 9.11b

 

[Voxilla]

Black screen for me.

4890, Win7 x86, Cat 9.11b

It seems people using Win7 are running into trouble with my DX11 thingies.
I have no Win7, so I can not figure out what goes wrong.

Could someone try to debug this on Win7, the source code is included ?

 

[Mintmaster]

Good question. Now it automatically selects CS when possible.

I just did a test by forcing it to PS and to my surprise PS is faster than CS, 35 versus 49 fps (vsync off). I'm trying to think of a reasonable explanation for that, for the moment I can't.

It could be that the drivers have a different compiler. You might also want to try to write some code that visualizes the thread and group numbering to see if your calculation for the position variable results in correctly tiled groups (it probably does). Also, see if numthread[8,8,1] helps.

One thing that's interesting about this shader is that the Cell group used it to show off how it's more powerful than GPUs. Of course, the original code was written in Cg and they compared it to G70, which is terrible at branching.