Sorry your browser is not supported!

You are using an outdated browser that does not support modern web technologies, in order to use this site please update to a new browser.

Browsers supported include Chrome, FireFox, Safari, Opera, Internet Explorer 10+ or Microsoft Edge.

Code Snippets / [DBP] Interactive Mandelbrot fractal zoomer

Author
Message
Diggsey
17
Years of Service
User Offline
Joined: 24th Apr 2006
Location: On this web page.
Posted: 12th Sep 2010 02:03
Move the mouse to pan, and click to zoom in.

Remove the 'remstart'/'remend' lines to use double precision, which will let you zoom in further, but is much slower.


[b]
bergice
16
Years of Service
User Offline
Joined: 5th Jun 2007
Location: Oslo,Norway
Posted: 12th Sep 2010 18:56
That is so cool!

Why does it stop zooming if i go far enough in by the way?

9cdfb439c7876e703e307864c9167a15
Diggsey
17
Years of Service
User Offline
Joined: 24th Apr 2006
Location: On this web page.
Posted: 12th Sep 2010 20:20
Floating point innaccuracies

[b]
Neuro Fuzzy
16
Years of Service
User Offline
Joined: 11th Jun 2007
Location:
Posted: 13th Sep 2010 08:58
Pretty cool.

You should add some prettifying stuff. I'd calculate the whole thing a couple iterations higher, and then average the results for a smoother transition between parts of the mandelbrot set and numbers no one cares about

Green Gandalf
VIP Member
19
Years of Service
User Offline
Joined: 3rd Jan 2005
Playing: Malevolence:Sword of Ahkranox, Skyrim, Civ6.
Posted: 13th Sep 2010 12:45
Quote: "which will let you zoom in further, but is much slower."


It's practically instantanteous if you use the GPU via a shader.

You still have the floating point inaccuracies though which limit the amount of zoom.
Green Gandalf
VIP Member
19
Years of Service
User Offline
Joined: 3rd Jan 2005
Playing: Malevolence:Sword of Ahkranox, Skyrim, Civ6.
Posted: 16th Sep 2010 15:25 Edited at: 17th Sep 2010 13:14
Diggsey,

You might like to have a look at this collection of shaders which I'm working on.

When running the demo you can press 1, 2, 3 or 4 for different fractals or colouring schemes. You can zoom in or out using the +/- keys and can play with the colour scale of the burning ship shader using the n/m keys. You can also use the arrow keys to move the camera left, right, up or down.

As in your demo there comes a point as you zoom in when the floating point inaccuracies either pixelate the image or prevent you moving left or right.

The burning ship shader uses PS3 and I expect the other two would work better with PS3 as well - the HLSL coding is certainly a lot easier and more intuitive too.

Your Mandelbrot colouring scheme looks good. Are you up to doing something similar for my shaders?

Edit Revised demo and shaders attached. The shaders are all PS3 now. They could obviously be reduced to a single shader with several techniques since the only difference is in one line of code in the basic iteration. I just couldn't be bothered though.

Attachments

Login to view attachments
Diggsey
17
Years of Service
User Offline
Joined: 24th Apr 2006
Location: On this web page.
Posted: 16th Sep 2010 19:13 Edited at: 16th Sep 2010 19:14
I'm afraid I can't do much to your existing code as it depends upon not having early exit from the iteration loop (and x and y very rapidly reach infinity, so I can't use the final distance to do the colouring). I did actually make a GPU version right after I posted this thread though, which you can see here:

DBPro:


HSLS (requires v3):


[b]
Green Gandalf
VIP Member
19
Years of Service
User Offline
Joined: 3rd Jan 2005
Playing: Malevolence:Sword of Ahkranox, Skyrim, Civ6.
Posted: 16th Sep 2010 23:55 Edited at: 17th Sep 2010 00:58
Quote: "I'm afraid I can't do much to your existing code as it depends upon not having early exit from the iteration loop (and x and y very rapidly reach infinity, so I can't use the final distance to do the colouring). "


Did you look at the BurningShip shader? That uses PS3 and has early exit as you require. The original version was similar to the Mandelbrot and Mandelbar shaders so they can be rewritten in the same way - the only thing that will be different really is the formula used in the iterations.

In fact your Mandelbrot HLSL is very similar to my BurningShip shader. I'll try it out and report back.

Edit Just tried your shader. Very nice. Looks like efficient code too. The DBPro controls were easy to use as well. I'll check the shader code carefully tomorrow and see why I couldn't get something similar working for my BurningShip fractal. Thanks for posting that demo.
Green Gandalf
VIP Member
19
Years of Service
User Offline
Joined: 3rd Jan 2005
Playing: Malevolence:Sword of Ahkranox, Skyrim, Civ6.
Posted: 17th Sep 2010 13:11
I've now edited my shaders so they all use PS3 and cleaned out some redundant code - the net result is that code is a bit more like yours now.

The burning ship shader that I posted yesterday contained some redundant code from an earlier version that didn't have early exit from the main loop. Hopefully that's all been cleaned up in the new download for my earlier post.

Incidentally, do you know why the shader compiler doesn't seem to allow a texture read inside the loop?
Diggsey
17
Years of Service
User Offline
Joined: 24th Apr 2006
Location: On this web page.
Posted: 17th Sep 2010 16:16
The loops are expanded by the compiler, so you would end up with 20 or so texture reads.

[b]
Green Gandalf
VIP Member
19
Years of Service
User Offline
Joined: 3rd Jan 2005
Playing: Malevolence:Sword of Ahkranox, Skyrim, Civ6.
Posted: 17th Sep 2010 16:39 Edited at: 17th Sep 2010 18:09
That's what I thought - but the asm code isn't expanded in SM3 as far as I can tell. In fact I don't see how it can be since I can make nIters very large which would make an enormous unrolled loop.

This is what the MS DX9 documentation says:

Quote: "Dependent Read Limit
There are no dependent read limits.

Texture Instruction Limit
There is no limit on texture instructions.

Instruction Count
Each pixel shader is allowed anywhere from 512 up to the number of slots in MaxPixelShader30InstructionSlots (not more than 32768). The number of instructions run can be much higher because of the looping support. MaxPShaderInstructionsExecuted should be at least 2^16.
"


So something else is going on - unless the documentation is wrong (which it is in places unfortunately ).

Edit There are at least three other possibilities: DarkShader is incorrectly flagging a warning as an error;
a bug in the shader compiler;
a bug that I can't see in my shader code.

Edit2 We can probably rule out a DarkShader error - FX Composer gives exactly the same error and says

"loop does not appear to terminate in a timely manner (1024 iterations)"

even when I set nIters to just 4! Here are the code fragments I tested:

Works:



Doesn't work:



The evidence is pointing to an obscure undocumented limitation or a compiler bug. What do you think?

Edit3 Done some delving on the MS site and it seems that the problem is an obscurely documented feature of the "if" construct. Here is what it says in remarks on the "if Statement" page. Note especially the reference to tex2D in the penultimate paragraph:

Quote: "Remarks
When the compiler uses the branch method for compiling an if statement it will generate code that will evaluate only one side of the if statement depending on the given condition. For example, in the if statement:

Copy[branch] if(x)
{
x = sqrt(x);
}
The if statement has an implicit else block, which is equivalent to x = x. Because we have told the compiler to use the branch method with the preceding branch attribute, the compiled code will evaluate x and execute only the side that should be executed; if x is zero, then it will execute the else side, and if it is non-zero it will execute the then side.

Conversely, if the flatten attribute is used, then the compiled code will evaluate both sides of the if statement and choose between the two resulting values using the original value of x. Here is an example of a usage of the flatten attribute:

Copy[flatten] if(x)
{
x = sqrt(x);
}
There are certain cases where using the branch or flatten attributes may generate a compile error. The branch attribute may fail if either side of the if statement contains a gradient function, such as tex2D. The flatten attribute may fail if either side of the if statement contains a stream append statement or any other statement that has side-effects.

An if statement can also use an optional else block. If the if expression is true, the code in the statement block associated with the if statement is processed. Otherwise, the statement block associated with the optional else block is processed.
"


The relevant page on the site is:

if statement

Edit4 I think I've found the relevant part of the documentation. The reason seems subtle but makes sense when you read it all. The following is an extract from the relevant page of the MS DX9 SDK docs. You'll find it by searching for the heading:

Quote: "Interaction of Per-Pixel Flow Control With Screen Gradients
The pixel shader instruction set includes several instructions that produce or use gradients of quantities with respect to screen space x and y. The most common use for gradients is to compute level-of-detail calculations for texture sampling, and in the case of anisotropic filtering, selecting samples along the axis of anisotropy. Typically, hardware implementations run the pixel shader on multiple pixels simultaneously (such as a 2x2 grid), so that gradients of quantities computed in the shader can be reasonably approximated as deltas of the values at the same point of execution in adjacent pixels.

When flow control is present in a shader, the result of a gradient calculation requested inside a given branch path is ambiguous when adjacent pixels may execute separate flow control paths. Therefore, it is deemed illegal to use any pixel shader operation that requests a gradient calculation to occur at a location that is inside a flow control construct which could vary across pixels for a given primitive being rasterized.
"


Sorry about all the edits but it was probably worth it in the end.
Green Gandalf
VIP Member
19
Years of Service
User Offline
Joined: 3rd Jan 2005
Playing: Malevolence:Sword of Ahkranox, Skyrim, Civ6.
Posted: 17th Sep 2010 19:39 Edited at: 17th Sep 2010 19:42
Ok. I think this needs a new post now.

Here's the final pixel shader code for the burning ship fractal. The value of nIters used was 400. It compiles if you take control of mipmapping by using the tex2Dgrad texture lookup function instead of tex2D inside the if statement block. The compiled pixel shader is now 37 instructions instead of 47 which would appear to be a saving and gives simpler code. Interestingly though, the 47 instruction version from the earlier download runs faster when uncapped on my machine.




Here's a zoomed in screenshot of one of the smaller "ships" where you can see the burning ship and all the weird ghostly structures behind it.



I can see further optimisations (e.g. why compute x0 and y0 in the pixel shader?) but this'll do for now. At least I've learnt something new about PS3 today.

Attachments

Login to view attachments

Login to post a reply

Server time is: 2024-03-28 13:18:00
Your offset time is: 2024-03-28 13:18:00