Go Back   Winamp & SHOUTcast Forums > Visualizations > MilkDrop

Reply
Thread Tools Search this Thread Display Modes
Old 19th February 2012, 07:07   #1
mfbscs
Junior Member
 
Join Date: Dec 2001
Posts: 41
Milkdrop and fractals (Seeking input from Martin)

Hi all, a little intro on me and MD:

I've been using MD since it originally came out and have always found it to be the absolute best visualizer out there. I’ve showed it to all of my friends and family and have spent countless hours watching it. I even ran an HDMI cable from my PC across my living room to my HDTV so I could output MD to it while listening to music =) However, I've never much posted on the boards until now, so hello!

From time to time over the years I would occasionally look for new visualizers, but always come up disappointed, so I just stopped looking. MD remains king.

I was recently watching the documentary DMT: The Spirit Molecule and saw some visuals from the Electric Sheep project that use the Flam3 fractal flame algorithm from Scott Draves. I was completely blown away at how beautiful they were. I kicked myself for not knowing about this earlier! I did some research and unfortunately found that while the output is amazing, its usability is zero. It follows a rather stupid system of rendering individual frames and then outputting them to a crappy looking low resolution video. As far as real-time visualizations go, this is a non-starter.

In search of more information, I posted the following message over on their forum. Rather than copy it here, I’ll link it:

http://www.electricsheep.org/node/4261

So I’d like to ask that same question here, and hopefully get a reply from Martin/Nitorami, since it seems he knows the limits of what MD can do better than anyone else. So here it goes again:

-MD renders at 60 fps, and Electric Sheep (ES) renders at roughly one frame per hour (200k x slower)! I do not understand how this can be the case, given that MD images are pretty close in visual quality and overall aesthetics. MD also has some fractal looking presets.

So my real question remains the same as on the link above: Is it possible to have some middle ground between rendering at 60fps and 1 fpH, that would still allow for decent looking fractal flame (or similar fractal) images to be drawn in real-time? If such a thing is possible, I think it would propel MD even farther than where it is now.

Any feedback would be great, and I think this would be a helpful topic for everyone to discuss since I did a search on the forums here and nothing came up. I'm a developer myself, 5 years in school and 10 years professionally, but I've never worked on MD presets.

And a final word to Martin: You are the best preset writer by far. Your originality is unmatched and I sincerely thank you for putting in the time to not only write these presets, but to document and respond here on the boards. Major kudos for all of that.
mfbscs is offline   Reply With Quote
Old 19th February 2012, 23:14   #2
Nitorami
Major Dude
 
Join Date: Mar 2008
Location: Erlangen
Posts: 641
Send a message via ICQ to Nitorami
Hi mfbscs

Thanks for the honours, and a difficult question. What can I say ... phew! Well first, MD does not do any rendering in the first place. The system, as it's meant to be, is approximately:

Draw user defined waves (simple dots or lines)
Draw user defined shapes (simple polygons)
The shapes can alternatively be used as "mirror", instead of painting a solid color, they would copy another part of the screen, with adjustable zoom and rotation.
All this outputs to the screen, PLUS (***) an adjustable copy of the previous frame, scaled, rotated, zoomed, shifted.

That is basically all. The multiple mirroring, rotating etc. steps can already generate nice fractal like images - sort of. Normally for a 2D fractal you would run, say, up to 100 iterations on each individual pixel, to generate the image. In MD, you would copy (overlay, add, subtract - whatever) the previous (rotated, shifted, zoomed etc.) frame, where the rotation etc. would follow similar rules as in the fractal equations. This is not the same of course but can generate similar effects, and is computational cheap. The 100 iterations are replaced by 100 overlaid copies over time. After all, the mandelbrot equation is not more than rotation and addition in each step. Geiss already used this trick for his Julia fractal presets, and it runs well even on rather old GPUs, and with MD1.

Back to step (***), MD since version 2 provides the possibilty to program the GPU directly via HLSL. If you use that, you are not limited to simple per screen zoom, rotate, shift etc. operations but can operate on a per pixel basis. I used this for the "mandelbrot orbit trap" preset, which actually calculates the mandelbrot fractal, as per textbook, per pixel, on the GPU, with an iteration depth of 50 (I think). Which means the GPU does 50 iterations per frame per pixel, i.e. some 4e9 complex multiplications per second. This takes average GPUs quite to their limits, irrespective of whether you do it with MD or otherwise.
Now I don't know whether ES makes use of the GPU or not. If it does the calculations on the CPU, it can be expected to be MUCH slower. The advantage of the CPU is its universality, while the GPU achives its speed by massive parallel processing.

As I watch some ES pictures, it looks as if they use per pixel processing to calculate the basic fractal, supported by simple rotate, shift & copy operations as in MD to increase complexity. GPU or CPU I do not know. They appear to be 2D, hence I guess many of them could be made in MD as well, possibly at a reasonable frame rate.

With MD, the trouble starts when you get into 3D or geometry. A GPU can handle, at incredible speed, 3D objects with a z coordinate, projection, shading, lighting, shadows etc., as seen in games. MD only supports a flat mesh - you can use a the power of modern video cards, but only in a plane. Things as ray tracing, rendering, shadows etc. are not possible because MD only knows the xy-plane. It is possible to overcome this to a certain degree, as you may have seen from my mandelbrot presets, but these are really dirty tricks, and not true 3D.

Conclusion - I think that many of the sheep should be feasible in MD, using HLSL, at a reasonable frame rate. On an artistic view, the beauty of the sheep may be due to the fact that they ARE static. I often made the experience that beautiful structures lose their charm as soon as they are animated by simple algorithms such as mirror, copy & co. which the eye resolves immediately as soon as there is movement.
Nitorami is offline   Reply With Quote
Old 19th February 2012, 23:41   #3
mfbscs
Junior Member
 
Join Date: Dec 2001
Posts: 41
Wow, thank you so much for the info. If AOL/Winamp aren't paying you for this stuff, they need to be.

You pretty much summed it up, so my only replies would be...

1) I know AOL is being tight with the source for MD 2.0, and is also not supporting bug fixes or any other development at this time, as evidenced from the other posts on this board. Would it be possible to put some pressure on them by saying "Either improve it, or let us do it". Perhaps an MD 3.0 could make some of things you described possible?

2) Seeing that #1 will probably not happen, I was thinking that if you are at the end of what you can possibly dream up doing with MD, perhaps you could try making a preset that looked similar (as close as is reasonably possible) to ES/fractal flames?

3) There are a few implementations of Flam3 on the GPU. Fractron9000 is one such program. You can move around the fractals in realtime, but I don't think MD could do all of that. Again, my aim is some type of middle ground.

4) If you'd like to see more of what they look like when moving, check out the documentary DMT The Spirit Molecule.

Thanks again.
mfbscs is offline   Reply With Quote
Old 19th February 2012, 23:48   #4
mfbscs
Junior Member
 
Join Date: Dec 2001
Posts: 41
Also, here is the PDF describing the core of the algorithm in math terms.

http://www.flam3.com/flame_draves.pdf
mfbscs is offline   Reply With Quote
Old 20th February 2012, 11:02   #5
Nitorami
Major Dude
 
Join Date: Mar 2008
Location: Erlangen
Posts: 641
Send a message via ICQ to Nitorami
On 1) I am in no way affiliated to AOL, and cannot tell whether they will disclose it some time, but I think the answer is no. Not sure whether they are aware / interested they still own it in the first place. The repeated discussions about that topic lead to nowhere. However it is possible to clone MD2, as demonstrated by...
http://forums.winamp.com/showpost.ph...2&postcount=17
So it does not seem to be too difficult to rebuild MD2 from scratch, and it seems to run fairly well. The main difficulty is certainly to make it entirely compatible, in order to use the old presets. Without this restriction however, it should not be a huge problem to write your own "MD3" or however you would call it.

2) I'll have a look when I get around to it. For your better understanding, these are the main limitations:
CPU: You can program any fractals you like using the per frames equations. There is a full programming language and unlimited storage space. But you can only draw 4096 polygons per frame, which makes it painfully slow.
GPU: I would not seriously consider anything else than the shaders for programming fractals. That is fairly well possible in MD2, except for 3D/ volumetric calculations. Realistic smoke and flames for instance require 3D modelling, which cannot be done in MD2. That is however not such a serious drawback, because the 3rd dimension increases the numeric effort to a degree it cannot be handled anywhere near to realtime anyway on a standard machine. I only got anywhere with my mandelbox flights because I found a trick to reduce the 3D space effectively to 2D. Concluding, in MD2 we have (a) no z coordinate.

We neither have (b) objects. We cannot place an object such as a polygon to the screen at position (x,y) other than by using the shapes provided by the CPU. That is not too bad because fractals normally don't need objects. Except e.g. Incendia, which can create stunning images by placing 3D objects at positions determined by fractal equations and then rendering them... calculation time: bloody ages.

We have (c) no memory over frames except the screen. The shaders cannot remember anything between two frames other than the RGB of each pixel. That defeats concepts to distribute the calculation over several frames. It would be an obvious idea to do only, say, 30 iterations per frame, store the intermediate results and continue in the next frame, but that is not possible.

There is (d) no way to exclude pixels from being calculated. This limitation is owed to the physical structure of the shader units. The shader always executes the complete code for each pixel per frame. So if we consider to render only one per 8 pixels per frame, to reduce the GPU load and make it run smoother - that does not work. AFAIK, the shader always executes all branches of conditional statements and discards those not required so there is no benefit in excluding pixels by IF conditions or similar.

There is (e) a limitation to the number of GPU instructions. With shader model 3 it is 1024 (may be higher nowadays, don't know). This puts a limitation to the complexitiy of fractal equations and iterations, at least if the compiler unrolls the loops for speed. Whether it does or not you can never be sure. The compiler can be advised not to unroll loops but MD2 does not provide access to this control. This limitation is however not too bad because 1024 instructions will make the GPU stutter along at very low framerate anyway, which is no fun to watch.

The numeric precision is (f) limited to IEEE single. That imposes serious restrictions to the level of zoom possible.

3) I don't know Fractron, and I seriously try to avoid installing MS's shitty framework whatever dot com... that said, I think I already installed it for Incendia and it caused me a lot of problems. I hate software that requires this crap.

4) Can you point me to this documentary ? Do I need to install Fractron for it ?

5) Thanks for the pdf, this is interesting reading. Will have a closer look.
Nitorami is offline   Reply With Quote
Old 20th February 2012, 15:57   #6
Nitorami
Major Dude
 
Join Date: Mar 2008
Location: Erlangen
Posts: 641
Send a message via ICQ to Nitorami
Ok I have now understood how these IFS fractals work. Putting it into my own words -

Pick a random point (x,y), iteratively apply a convergent function, which is for each iteration step randomly selected from a limited pool of functions. Because of the convergence properties of all functions, a stable output (x1,y1) can be reasonably expected after not more than 20 iteration steps. Plot this point (x1,y1). If you like, apply dedicated colour schemes for more beauty.

This is a classic case for straightforward programming, and actually Amandio C and Flexi have already made MD presets for simple Sierpinski fractals, using the CPU (via waves and shapes equations). As expected, it can be done on the CPU, but there is no reason why it should be faster with MD than with any other software.

Unfortunately this fractal scheme is quite the opposite of how shaders work, so I cannot see how the massive GPU power could be utilised (other than for post processing, mirror and rotation etc.). There are probably higher shader functions to assist that but not in MD. In MD's flat mesh, the same equation is run for every pixel, and the only way to NOT get a uniformly coloured screen is the uv variable, which is (0;0) for the top left and (1;1) for the bottom right corner.

It is therefore rather twisted with that to implement an IFS scheme on the GPU. I came up with the following poor solution, in pseudo code:

(The shader does this for each pixel simultaneously, once per frame)
Start with float2 zz = (0;0); //don't need a random starting point for the Sierpinski triangle
For n = 1 to 20 do begin
randomly apply one of the three Sierpinski transformations to zz
end;

Now we have an altered value of zz, but what can we do with it ? In ordinary language it would be obvious, simply plot(zz). This is not possible in shaders. The easiest way to understand this is by imagining the shader units as parallel processors, one for each pixel, with a simple RGB float3 output, which determines the colour of this pixel. Each processor can read the colour values from other pixels of the PAST frame (which MD stores in a buffer), but the output is hardwired to "his" pixel. We cannot therefore say "paint the pixel over there at xy".

The only way to achieve something is to check whether our output value zz happens to be close to the position of THIS pixel (coded as float2 uv), and if yes, set it to white. This is however a huge waste, because it will happen rarely. Most of the shader processors would grind along uselessly, because the output coordinate zz will never fall on their position uv.

Therefore as far as I understand, IFS fractals cannot reasonably be implemented on the GPU using MD2. But of course with waves or shapes... might be a job for Amandio C to try out
Nitorami is offline   Reply With Quote
Old 20th February 2012, 17:01   #7
Nitorami
Major Dude
 
Join Date: Mar 2008
Location: Erlangen
Posts: 641
Send a message via ICQ to Nitorami
OK I made a few experiments with function V17 of the pdf. Other than the Sierpinski triangle, the trigonometric functions make it rather chaotic and noisy... takes a long time to settle. Better grab a fast compiler, write your own code and optimise it for speed.
Nitorami is offline   Reply With Quote
Old 20th February 2012, 17:06   #8
mfbscs
Junior Member
 
Join Date: Dec 2001
Posts: 41
Thanks for the great info. I'm definitely saddened to see that it's not possible, but oh well, all of your other presets will keep me busy with plenty of viewing time anyway.

Regarding that documentary, I saw it on Netflix. Google it and perhaps you can find another place to view it.

Fractron is just a standalone program that does some nice Fractal rendering. Another is Apophysis. Just fun things to toy with.

Oh well, thanks again for the effort, I mostly just wanted an answer as to whether or not this was possible.
mfbscs is offline   Reply With Quote
Old 20th February 2012, 17:10   #9
mfbscs
Junior Member
 
Join Date: Dec 2001
Posts: 41
BTW, the flam3 algorithm is open source and is used in those other programs I mentioned. I'm sure they've already optimized it to death. I was mostly just looking to see if such a thing was even remotely possible in MD.

MD draws most presets at 60fps, and flam3 draws at one frame per hour, which is roughly 200,000 times slower. I was just hoping that there was possibly some middle ground.
mfbscs is offline   Reply With Quote
Old 20th February 2012, 21:14   #10
Nitorami
Major Dude
 
Join Date: Mar 2008
Location: Erlangen
Posts: 641
Send a message via ICQ to Nitorami
See here for a simple GPU powered IFS renderer. May come close to your middle ground, it runs at approximately 5fps on my machine at acceptable quality.

http://www.reocities.com/simesgreen/gpuflame/index.html

This here is even better
http://www.cs.uaf.edu/~olawlor/2011/gpuifs/
Nitorami is offline   Reply With Quote
Old 29th February 2012, 18:18   #11
Amandio C
Senior Member
 
Join Date: Dec 2008
Posts: 399
Hi. Now that someone mentioned it, about a year ago I spent some time fiddling with IFS drawings. I never posted them, so here are a few presets. The animation possibilities are very limited unless by using textured shapes or shader deformations. The equations for the appolonian gasket were found on the web, but the author's name was not mentioned.
Attached Files
File Type: zip amandio c - IFS.zip (21.7 KB, 266 views)
Amandio C is offline   Reply With Quote
Old 29th February 2012, 21:41   #12
Flexi
wellspring of milk
Major Dude
 
Flexi's Avatar
 
Join Date: Apr 2007
Location: 54.085108,12.127497
Posts: 2,007
Send a message via ICQ to Flexi
Martin, never say never! I'm daring now, but I won't fully agree with you in some points. I have not thought it through completely but here is an idea that is lurking on my mind for quite a while now. There might be just a different approach to the render result of the mentioned IFS algorithm - sort of a 2D distance-estimated / probability density approach. The problem is, there are two paradigms clashing here. One is, that a quite respectable number of randomly chosen points get played through the chaos game and end up in basins that are basically the pixels (leaving out the anti aliasing and tone mapping here). The other is to map a pixel position to a density. To come to the densities analytically can be done with pretty much the same chaos game, "only" reversed. In the document, the first example is a Sierpinski carpet. I'd say, it must be possible to approach this result too by recursively calculating up the probability density. I too see the immense complexity, but maybe with a Monte-Carlo simplification it's in reach again. I mean, what is it so much different from the 3D Mandelboxes then?
*just pondering*
Flexi is offline   Reply With Quote
Old 1st March 2012, 07:44   #13
Nitorami
Major Dude
 
Join Date: Mar 2008
Location: Erlangen
Posts: 641
Send a message via ICQ to Nitorami
Well, yes, there might be a way like that. Actually, this paper (located under the above link to an efficient GPU implementation)

http://www.cs.uaf.edu/~olawlor/paper...r_ifs_2011.pdf

describes an alternative method which is apparently much faster but so far I haven't even understood the introduction... "Schauder-Tychono Fixed Point Theorem 1. Let K
be a non-empty, compact, convex subset of a locally convex topological vector space. Given any continuous mapping F : K ! K, there exists a fixed point a 2 K such that F(a) = a."

Nitorami is offline   Reply With Quote
Old 1st March 2012, 16:44   #14
Flexi
wellspring of milk
Major Dude
 
Flexi's Avatar
 
Join Date: Apr 2007
Location: 54.085108,12.127497
Posts: 2,007
Send a message via ICQ to Flexi
wait, there's glsl source code...
i should have read your last link!
my bad.

awesome find!
Flexi is offline   Reply With Quote
Old 1st March 2012, 22:17   #15
Amandio C
Senior Member
 
Join Date: Dec 2008
Posts: 399
Martin, you mentioned MD stores each pixel RGB values of the last frame. How do we access this data? I hope this makes sense.
Amandio C is offline   Reply With Quote
Old 2nd March 2012, 15:46   #16
Nitorami
Major Dude
 
Join Date: Mar 2008
Location: Erlangen
Posts: 641
Send a message via ICQ to Nitorami
That's easy - By GetPixel(uv) or tex2D (sampler_main, uv)
Or use the blurred versions GetBlur1, GetBlur2, GetBlur3 (uv)

Only works inside the shaders of course. The wave and frames section have no clue about what is on the screen.
Nitorami is offline   Reply With Quote
Old 3rd March 2012, 19:59   #17
Amandio C
Senior Member
 
Join Date: Dec 2008
Posts: 399
Thank you. Another question. Are the formulas in the warp shader iterated for each pixel, remembering the previous ret value in each iteration?
In this example, are the successive x,y calculated using the previous x, y of each pixel ?

float c,d,x,y;
shader_body
{
c = ret.x; x = ret.y+1; y = ret.z+1;
x += sin(x+q1+uv.x);
y += cos(y-q1-uv.y);
d= sqrt(x*x+y*y);

c = abs(c); c -= int(c);
x = abs(x); x -= int(x);
y = abs(y); y -= int(y);

ret.x = d; ret.y = x-1; ret.z = y-1;

}
Amandio C is offline   Reply With Quote
Old 4th March 2012, 08:34   #18
Nitorami
Major Dude
 
Join Date: Mar 2008
Location: Erlangen
Posts: 641
Send a message via ICQ to Nitorami
That will not work, because ret is only an output variable. c=ret.x at the code start will result in zero or a random value.

To use the previous frame, you need to initialize
ret = GetPixel(uv_orig);

Then, you use ret.x=sqrt(x*x+y*y) ; however the term is most likely >1 and will be limited to 1, hence you'll get a red screen. You can assign any value to ret, but in the end it will be limited to (0,0,0) = black to (1,1,1) = white, because it is then sent to the screen. Same for GetPixel(uv).
Nitorami is offline   Reply With Quote
Old 4th March 2012, 18:50   #19
Nitorami
Major Dude
 
Join Date: Mar 2008
Location: Erlangen
Posts: 641
Send a message via ICQ to Nitorami
IFS in warp shader

This is a first try to run IFS code in the shader. The code still has a number of flaws, dor instance it should be grayscale but tends to shift to one colour, it flickers etc. but basically works.

If you like to try other formula, please edit only in the marked section of the warp shader, otherwise you'll be likely to break the code, it is quite sensitive to changes and it took me quite long to balance it. When using known formula, please note they will not deliver the expected result, because they need to be inverted... for instance if your formula is

x = 0.5*x + 0.5,

you need to invert it to

x = 2*(x-0.5).
Attached Files
File Type: milk martin - IFS experiment 1.milk (7.5 KB, 237 views)
Nitorami is offline   Reply With Quote
Old 4th March 2012, 20:51   #20
Amandio C
Senior Member
 
Join Date: Dec 2008
Posts: 399
Thanks.
In the example I was trying to use the ret.y, ret.z buffers to transport x, y from pixel to pixel and frame to frame, in a way similar with instances in shapes.
Hopefully there would be some red-tone iterated-looking output, but I suppose this is a wrong approach.

I only get a blank screen with your preset, some issue with the ATI card maybe ?
Amandio C is offline   Reply With Quote
Old 4th March 2012, 20:58   #21
Nitorami
Major Dude
 
Join Date: Mar 2008
Location: Erlangen
Posts: 641
Send a message via ICQ to Nitorami
I know the blank screen may be a problem if the screen is black when the preset starts... just try to add some waves, e.g. a "simple waveform"
Nitorami is offline   Reply With Quote
Old 4th March 2012, 22:00   #22
Amandio C
Senior Member
 
Join Date: Dec 2008
Posts: 399
Ok thanks the grid is visible. It doesn't look like an IFS fractal though
Amandio C is offline   Reply With Quote
Old 4th March 2012, 22:08   #23
Nitorami
Major Dude
 
Join Date: Mar 2008
Location: Erlangen
Posts: 641
Send a message via ICQ to Nitorami
Well it should look like this, and move
Attached Thumbnails
Click image for larger version

Name:	ifs_sample.jpg
Views:	408
Size:	8.5 KB
ID:	49490  
Nitorami is offline   Reply With Quote
Old 4th March 2012, 22:42   #24
Amandio C
Senior Member
 
Join Date: Dec 2008
Posts: 399
I only get a rectangular grid here.
Amandio C is offline   Reply With Quote
Old 5th March 2012, 15:07   #25
Nitorami
Major Dude
 
Join Date: Mar 2008
Location: Erlangen
Posts: 641
Send a message via ICQ to Nitorami
You are probably right, another nvidia/ATI incompatibility issue.

On your idea to transport values from frame to frame using ret - that is possible in principle, but ret is limited to [0..1], and uses only 8 bit per colour, which is a quite serious restriction. Precision will be rather low, after all, ret is only meant to transport a colour, not data. Unfortunately we have no other channel in MD.
Nitorami is offline   Reply With Quote
Old 5th March 2012, 19:31   #26
Amandio C
Senior Member
 
Join Date: Dec 2008
Posts: 399
Yes, it's surely the video card's fault, sometimes a rectangular grid is drawn, others concentric circles, depending on the type of simple wave used. I will check it later on another pc, I'm curious to see it working.
I thought about keeping ret.y and ret.z between 0 and 1, then dividing by say 100 at the end of the code, to eliminate any visible output of blue and green, and to multiply by 100 in the beginning to obtain the previous values. But with the 8-bit restriction it won't work, I suppose. Besides, to reproduce the instances iterations, there had to be iterations inside each frame, without the need of loops.
Amandio C is offline   Reply With Quote
Old 6th March 2012, 06:37   #27
mfbscs
Junior Member
 
Join Date: Dec 2001
Posts: 41
Hey guys, sorry for the absence. My video card died on me (ATI 4890 HD, never again). But I am now the proud owner of an nVidia Gtx 460.

I see you've started to look at ways to possibly do IFS with MD. Very cool!

In the meantime, I've began looking at the source code from Dr. Orion Lawlor's GPU IFS renderer. I've also been in contact with him, pointed him to this thread and hope to discuss things further. The code is pretty much in a prototype stage that is tightly coupled to the GUI. My aim is to first split it out into a library that other projects can link to, and from there figure out how to add to it.

Personally, here is how I see things:

Although the Flam3 algorithm was developed quite some time ago, it has never been able to be rendered in real-time on affordable hardware until now. The only example I know of that does it, is Dr. Lawlor's. So this seems like a unique opportunity for starting something that could end up having a large impact on future visualization software. (Correct me if I'm wrong on those assumptions). For those reasons, I think it is worth spending my scarce spare time on to see how far we can take it. Perhaps even put it on an open source repository some day if all goes well, but we'll have to wait and see.

That's all I've got for now. Good luck on future presets and thanks for the replies.
mfbscs is offline   Reply With Quote
Old 6th March 2012, 08:21   #28
Nitorami
Major Dude
 
Join Date: Mar 2008
Location: Erlangen
Posts: 641
Send a message via ICQ to Nitorami
Here is another trial version. I would expect it to run on ATI because less dependant on calibration. Main problem is brightness, the IFS rendering is basically done by repeated mirroring / rotation of a nonlinear plane as propsed by Dr Lawlor ...well, as far as I understood it.

Consider a simple example: We use one formula and apply it repeatedly. Applying x = x*0.5; y = y*0.5 in wave code would quickly converge to (0;0), regardless which starting point (x,y) we use.

In warp shader, the code
uv1 = uv-0.5; //center uv1 first
uv1 = 2*uv1; //apply transformation
ret = GetPixel (uv1);

will do the same. It is the equivalent to the wave code. Instead of repeatedly drawing pixels, we repeatedly copy the (distorted) screen back to itself.

There are some problems, such as when 2*uv1 falls outside [0;1], the texture will be wrapped around, resulting in regular patterns, smear, all gray etc. Clipping the texture is not a solution but causes other artefacts. Second problem is to maintain brightness without fading to black or white. And we need a seed. If the starting screen is black, it will always remain black.

In the first version, I tried to sprinkle a small bit of uniform noise as seed. This version simply uses the poles of the equations as light source. These are the points where the transformation is zero, i.e. a pixel will be copied back to the same pixel. Much better because the light moves with the structure and does not cause artifacts.

The example here uses a variation of the 3 Sierpinski formula. The flicker is because we have no buffer in MD other than the previous frame, and hence can only run ONE of the formulas per frame.

The code is very simple and easy to modify, just play with the 3 formula in the warp section.
Attached Files
File Type: milk martin - IFS experiment 6c.milk (6.2 KB, 227 views)
Nitorami is offline   Reply With Quote
Old 6th March 2012, 18:08   #29
Amandio C
Senior Member
 
Join Date: Dec 2008
Posts: 399
I still have the same output with the ATI card. I can't seem to upload images here, sorry. It's a white square and diagonal grid on a black background, only visible using simple wave type 2 and tweaking the size and opacity.
Amandio C is offline   Reply With Quote
Old 9th March 2012, 20:46   #30
Nitorami
Major Dude
 
Join Date: Mar 2008
Location: Erlangen
Posts: 641
Send a message via ICQ to Nitorami
I don't know what the problem with ATI is... I'd like to find out but I have no ATI card.
Here is another version. Not that it will run on ATI cards anyway.
Attached Files
File Type: milk martin - IFS bubbles.milk (8.6 KB, 241 views)

Last edited by Nitorami; 9th March 2012 at 21:50.
Nitorami is offline   Reply With Quote
Old 10th March 2012, 08:10   #31
Nitorami
Major Dude
 
Join Date: Mar 2008
Location: Erlangen
Posts: 641
Send a message via ICQ to Nitorami
Just noted that I had set shaders to version 4 in my IFS presets, and this is known to cause trouble with ATI cards. Sorry, corrected that. I hope this will work.
Attached Files
File Type: milk martin - IFS bubbles.milk (8.5 KB, 248 views)
Nitorami is offline   Reply With Quote
Old 10th March 2012, 23:20   #32
Amandio C
Senior Member
 
Join Date: Dec 2008
Posts: 399
It works fine now, thanks. I have no idea how you made it, but il looks very cool.
Amandio C is offline   Reply With Quote
Old 11th March 2012, 04:26   #33
mfbscs
Junior Member
 
Join Date: Dec 2001
Posts: 41
Quote:
Originally Posted by Nitorami View Post
The flicker is because we have no buffer in MD other than the previous frame, and hence can only run ONE of the formulas per frame.
Thanks Martin.

I'm curious if you think the flicker could be fixed if they were to release a new version of Milkdrop?
mfbscs is offline   Reply With Quote
Old 11th March 2012, 09:25   #34
Nitorami
Major Dude
 
Join Date: Mar 2008
Location: Erlangen
Posts: 641
Send a message via ICQ to Nitorami
Well, I don't think there is much development going on with milkdrop. Technically it should be easy to provide a second (invisible) buffer, but I don't think it will happen in MD. I would wish for a lot of other features but that would end up in a different visualiser. As long as it is MD, compatibility must be maintained.

BTW you can get rid of the flicker at certain cost... simply use only one color channel to calculate the image, then after three frames (when all formula are through) copy this channel to the other two, using some weighting to generate colours. In the comp shader, you only show these two channels, using simple colour mapping to reconstruct the missing colour.
That works quite well, but effectively reduces the fps to a third which may be visible for fast movements. In another platform than MD, it should be possible to calculate all formula, possible even twice or three times, during a single frame, using a background buffer.
Nitorami is offline   Reply With Quote
Old 12th March 2012, 03:39   #35
mfbscs
Junior Member
 
Join Date: Dec 2001
Posts: 41
Thanks for the info, I appreciate it.

I really, really wish that AOL would either improve MD, or allow someone else to do it. I wonder if Ryan Geiss could put some pressure on them.
mfbscs is offline   Reply With Quote
Old 21st March 2012, 15:04   #36
dasraiser
Junior Member
 
Join Date: Oct 2009
Posts: 13
hey awesome eye candy as usual

i had a look at you code, nice method, replaced you selector line with these and its sort of helped with the flicker, at the expense of look :/

sel = (q2+floor(uv.x*1440))%2; //1440x900 my monitor resolution :/ couldn't remember var
sel =(sel+floor(uv.y*900))%2;
dasraiser is offline   Reply With Quote
Old 21st March 2012, 17:35   #37
Nitorami
Major Dude
 
Join Date: Mar 2008
Location: Erlangen
Posts: 641
Send a message via ICQ to Nitorami
Good plan, removes the flicker, and the resulting moiré pattern is tolerable. But it also reduces the number of equations used from 3 to 2, so the structure becomes simpler.
Nitorami is offline   Reply With Quote
Old 23rd April 2012, 04:06   #38
mfbscs
Junior Member
 
Join Date: Dec 2001
Posts: 41
Martin, I'm curious, what is your development background? Are you a professional developer? And if so, do you work with graphics programming at your job? I'm a developer myself (5 years school + 10 years working), but I don't work with graphics much. Just trying to get an idea of where people come from on this forum.

Also, Geiss told you to message him on another thread. Just thought I'd tell you in case you didn't see it. Hopefully he has something good to say!
mfbscs is offline   Reply With Quote
Old 23rd April 2012, 19:19   #39
Nitorami
Major Dude
 
Join Date: Mar 2008
Location: Erlangen
Posts: 641
Send a message via ICQ to Nitorami
Hi mfbscs

Thanks for notifying me, I already contacted Ryan on his email. He is working for google and is apparently not involved in milkdrop any longer.

As to myself, I am an electrical engineer and amateur programmer, and the bits I know about shaders I learned from milkdrop more or less by trial and error. I am not much of an artist but was fascinated with milkdrop when I discovered it four years ago, and it became a way for me to balance for my rather boring industry job, and to express my musical and artistic talents I had not even known they exist... that's all really. I loved milkdrop for its easy access to shader power and its unsurpassable wysiwyg feeling, but it has aged and its limitations have become a pain for me. Pity there does not seem to be any further development, but considering the general lack of interest I can understand it.
Nitorami is offline   Reply With Quote
Old 27th May 2012, 06:56   #40
mfbscs
Junior Member
 
Join Date: Dec 2001
Posts: 41
Thanks for the info Martin, I'm always curious what peoples' backgrounds are. That's very cool you got into it even though it's totally different from your regular job.

An utter shame though that such an awesome technology has been laid to rest. I can't stress enough how much that saddens me, to see something so great essentially get thrown away for no good reason.

As for the future, I was thinking of giving Morphyre a try. Has anyone played with it yet?
mfbscs is offline   Reply With Quote
Reply
Go Back   Winamp & SHOUTcast Forums > Visualizations > MilkDrop

Thread Tools Search this Thread
Search this Thread:

Advanced Search
Display Modes

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off

Forum Jump