Old 25th January 2009, 18:51   #1
Flexi
wellspring of milk
Major Dude
 
Flexi's Avatar
 
Join Date: Apr 2007
Location: 54.089866,12.11168,18.75
Posts: 2,058
Send a message via ICQ to Flexi
need some help verifying a bug

i played a little with some old code experiments and i stumbled upon an old bug with the Blur1.

I discovered it by using Blur2 which effectively builds on the Blur1

file: /Winamp/Plugins/Mildrop2/data/blur1_ps.fx
code:
//texture PrevFrameImage;
//sampler2D sampler_main = sampler_state { Texture = <PrevFrameImage>; };
//float4 _c0; // source texsize (.xy), and inverse (.zw)
//float4 _c1; // w1..w4
//float4 _c2; // d1..d4
//float4 _c3; // scale, bias, w_div




void PS( float2 uv : TEXCOORD,
out float4 ret : COLOR0 )
{
// LONG HORIZ. PASS 1:
//const float w[8] = { 4.0, 3.8, 3.5, 2.9, 1.9, 1.2, 0.7, 0.3 }; <- user can specify these
//const float w1 = w[0] + w[1];
//const float w2 = w[2] + w[3];
//const float w3 = w[4] + w[5];
//const float w4 = w[6] + w[7];
//const float d1 = 0 + 2*w[1]/w1;
//const float d2 = 2 + 2*w[3]/w2;
//const float d3 = 4 + 2*w[5]/w3;
//const float d4 = 6 + 2*w[7]/w4;
//const float w_div = 0.5/(w1+w2+w3+w4);
#define srctexsize _c0
#define w1 _c1.x
#define w2 _c1.y
#define w3 _c1.z
#define w4 _c1.w
#define d1 _c2.x
#define d2 _c2.y
#define d3 _c2.z
#define d4 _c2.w
#define fscale _c3.x
#define fbias _c3.y
#define w_div _c3.z

// note: if you just take one sample at exactly uv.xy, you get an avg of 4 pixels.
//float2 uv2 = uv.xy;// + srctexsize.zw*float2(0.5,0.5);
float2 uv2 = uv.xy + srctexsize.zw*float2(1,1); // + moves blur UP, LEFT by 1-pixel increments

float3 blur =
( tex2D( sampler_main, uv2 + float2( d1*srctexsize.z,0) ).xyz
+ tex2D( sampler_main, uv2 + float2(-d1*srctexsize.z,0) ).xyz)*w1 +
( tex2D( sampler_main, uv2 + float2( d2*srctexsize.z,0) ).xyz
+ tex2D( sampler_main, uv2 + float2(-d2*srctexsize.z,0) ).xyz)*w2 +
( tex2D( sampler_main, uv2 + float2( d3*srctexsize.z,0) ).xyz
+ tex2D( sampler_main, uv2 + float2(-d3*srctexsize.z,0) ).xyz)*w3 +
( tex2D( sampler_main, uv2 + float2( d4*srctexsize.z,0) ).xyz
+ tex2D( sampler_main, uv2 + float2(-d4*srctexsize.z,0) ).xyz)*w4
;
blur.xyz *= w_div;

blur.xyz = blur.xyz*fscale + fbias;

ret.xyz = blur;
ret.w = 1;
//ret.xyzw = tex2D(sampler_main, uv + 0*srctexsize.zw);
}



If I'm right, this 1 pixel increment is misplaced and should be commented out.

So here's my question. when watching my example preset you should notice that the lower right corner will hardly be filled with the effect. after commenting out the pixel increment in the fx file and restarting Milkdrop everything is fine - can you please tell me if you notice the same differences. I must admit the resulting difference is veeerry subtle - but at least it's noticeable.
Attached Files
File Type: milk flexi - quantum processing.milk (10.4 KB, 251 views)
Flexi is offline   Reply With Quote
Old 25th January 2009, 20:42   #2
Nitorami
Major Dude
 
Join Date: Mar 2008
Location: Erlangen
Posts: 856
Flexi

on my GeForce 7600 GT your preset fades to white within a few seconds, starting from the top left corner, whether I patch the fx file or not.
Nitorami is offline   Reply With Quote
Old 25th January 2009, 21:28   #3
Flexi
wellspring of milk
Major Dude
 
Flexi's Avatar
 
Join Date: Apr 2007
Location: 54.089866,12.11168,18.75
Posts: 2,058
Send a message via ICQ to Flexi
hm, i can't help, i guess that must be another bug.
all the presets where i grabbed a difference from a blurred image seem to throw out different dx/dy values on your machine - as i suspect by the screen shots you gave me.
the value should never be minor -1 or bigger 1.
on the last screenshot of the alienation preset i saw that the dx value should have been at 1 - 1 = 0, but instead it looked like there was a NaN error - i really don't know how that comes but that's not the bug where i pointed my original post at.
Flexi is offline   Reply With Quote
Old 26th January 2009, 00:01   #4
Cope
Senior Member
 
Cope's Avatar
 
Join Date: Jul 2008
Location: Germany
Posts: 149
Yeah flexi I do see a difference, it's slight but it's there in the bottom right corner.

Murphey's fighting Occam, and I'm in the stands.
Cope is offline   Reply With Quote
Old 26th January 2009, 00:53   #5
Flexi
wellspring of milk
Major Dude
 
Flexi's Avatar
 
Join Date: Apr 2007
Location: 54.089866,12.11168,18.75
Posts: 2,058
Send a message via ICQ to Flexi
thanks.
but these Nvidia issues are even more annoying. it would be really great to find a fix for that too.

martin, i guess you know or you can imagine what values are to be expected from the dx/dy variables.

correct screenshot by me:
http://forums.winamp.com/attachment....postid=2474779

your absurdly distorted one:
http://forums.winamp.com/attachment....postid=2474771

in that example it's the green color channel that acts as separating layer.
where the value for the green channel is at 1 the earth texture is mapped on the sphere, else the mars is painted.
the displacement vector is wrong by a factor of at least 100.
apart from that the GetBlur1(uv) works fine for you?
when taking the difference between two slightly shifted points the result is between -1 and 1?

i have no idea
maybe a a byte/float type cast error?
Flexi is offline   Reply With Quote
Old 26th January 2009, 02:52   #6
Saint Goody
Senior Member
 
Join Date: Apr 2008
Location: Somewhere in Southern Indiana
Posts: 184
something interesting on the topic of the 7600...

I just upgraded from my 7600GTs to a 9600gt and I'm noticing a difference in quite a few of the shader heavy presets.

I am the purple heathen.
Saint Goody is offline   Reply With Quote
Old 26th January 2009, 18:46   #7
Nitorami
Major Dude
 
Join Date: Mar 2008
Location: Erlangen
Posts: 856
@Saint Goody: Can you give an example please, with screenshot if possible, at least one made with your new card ? This would be interesting.

@Flexi:
GetBlur works fine for me, and dx,dy always seemed to deliver reasonable results. I guess one problem of the alienation preset is the warp shader code, which takes over the green channel from the previous frame 1:1. When I bypass the comp shader and watch the warp shader output for quite some time, and it looks reasonable EXCEPT that the last frame from the previous preset persists for a very long time - which is actually what I would expect.

ret.y = tex2D( sampler_fc_main, uv ).y

is bound to retain the content from the old preset. If something was wrong with the shader itself, e.g. a bias or a systematic rounding error, the picture would slowly fade to bright or dark.

By modulating dx and dy in the frame equations, you move the green colour over the screen. The amount of color should remain the same except for
(a) the additional green input from shape 1 (I am not sure what shape 2 does). Anyway, I would expect a slow built up of green due to this input.
(b) rounding error influences. For each frame, each green pixel is distributed and interpolated over other pixels in the vicinity (in floating point arithmetics), then passed on to ret and truncated to 8 bit. This process is restarted for every frame. I would not expect the total green energy to remain absolutely constant in this process, at least I would expect it to be chip specific. I am rather surprised that the green IS reasonably constant, despite the additional input from shape 1.

I think we should always apply an attenuation factor <1 on the previous frame. Factor 1 pertains the past frames forever and really is a balancing act. Unfortunately because of the 8bit precision of ret, factors close to one such as 0.998 are effectively equal to one. My proposal for very slow fades is to apply a factor 0.99 only once every ten frames such as

float k1 = 1-.01*(frame%10 == 0);
ret.y = tex2D( sampler_fc_main, uv ).y*k1;

Maybe this would help ?

Having said it and trying it out, I note there is another problem, which is probably what you meant in the first place: Earth and mars are not always painted at the same location but at entirely different places. Lets see: Aha, the displacement is gone when I set d_uv = 0. Whats going on ?

To find out, I set ret = d_uv.x. I see white areas similar to the green mask. This cannot be right, I should only see the borders. It is fine however when I replace GetBlur1 by GetPixel.

I split up the subtraction:
float3 hh1 = GetBlur1(uv + float2(1,0)*px);
float3 hh2 = GetBlur1(uv - float2(1,0)*px);
float3 dx = hh1 - hh2;

Result: Same. Clearly we have a compiler problem here. That's really bad. I found two workarounds:

1) use lum() for both GetBlurs individually, but this merges the channels

2) apply a factor other than 1 to the GetBlurs individually:
float3 dx = ( 2*GetBlur1(uv + float2(1,0)*px) - 2*GetBlur1(uv-float2(1,0)*px) );
float3 dy = ( 2*GetBlur1(uv + float2(0,1)*px) - 2*GetBlur1(uv-float2(0,1)*px) );
float2 d_uv = float2(dx.y,dy.y)/2;

That works... maybe the multiplication just forces the compiler to avoid a problematic optimisation step. Whatever. Unfortunately it introduces needless calculation steps. Factor 2 is probably the cheapest factor. 1.0 does not work.
Nitorami is offline   Reply With Quote
Old 26th January 2009, 19:11   #8
Flexi
wellspring of milk
Major Dude
 
Flexi's Avatar
 
Join Date: Apr 2007
Location: 54.089866,12.11168,18.75
Posts: 2,058
Send a message via ICQ to Flexi
Quote:
float3 dx = ( 2*GetBlur1(uv + float2(1,0)*px) - 2*GetBlur1(uv-float2(1,0)*px) );
float3 dy = ( 2*GetBlur1(uv + float2(0,1)*px) - 2*GetBlur1(uv-float2(0,1)*px) );
float2 d_uv = float2(dx.y,dy.y)/2;
thanks for pointing that out. nevertheless this is truly weird.

did you try this workaround with the 'quantum processing' demo preset?
the effect builds totally on the traveling wavefronts. basically it is a skin-dot-like reaction diffusion equation with an added movement on the gradients. the effect is self-energizing and should not fade out once it is started.

you can do wonderful chaos visualization with traveling wavefronts.
i hope the bug that you have found there was the last one for you

and the green color patches in the alienation preset (resp. all Milkcore derivatives) are meant to stay as they are unless the per-vertex code smears it like a graffitti
Flexi is offline   Reply With Quote
Old 26th January 2009, 19:26   #9
Nitorami
Major Dude
 
Join Date: Mar 2008
Location: Erlangen
Posts: 856
Yes, it works for quantum processing as well, but I need to use the factor 2 for ALL subtractive GetBlur operations, also when subtracting GetBlur1 from tex2D (sampler_main).

As you said, the bottom right corner looks differently. In my case, this corner has a higher tendency to remain white. Screenshot attached (downscaled for filesize ).
Attached Images
File Type: jpg clipboard01.jpg (58.8 KB, 152 views)
Nitorami is offline   Reply With Quote
Old 26th January 2009, 19:55   #10
Flexi
wellspring of milk
Major Dude
 
Flexi's Avatar
 
Join Date: Apr 2007
Location: 54.089866,12.11168,18.75
Posts: 2,058
Send a message via ICQ to Flexi
is this the resulting image when you have changed the .fx file?
Flexi is offline   Reply With Quote
Old 26th January 2009, 20:14   #11
Nitorami
Major Dude
 
Join Date: Mar 2008
Location: Erlangen
Posts: 856
No, wait - with the patch, ther right corner is definitely more symmetric with the other corners. Apart from that, I can't see any noticeable difference.
Nitorami is offline   Reply With Quote
Old 26th January 2009, 20:21   #12
Flexi
wellspring of milk
Major Dude
 
Flexi's Avatar
 
Join Date: Apr 2007
Location: 54.089866,12.11168,18.75
Posts: 2,058
Send a message via ICQ to Flexi
two bugs fixed at the same time
time to put on sunglasses and being proud

Flexi is offline   Reply With Quote
Old 26th January 2009, 20:33   #13
Nitorami
Major Dude
 
Join Date: Mar 2008
Location: Erlangen
Posts: 856
Users will only benefit if these bugs are pointed out to the milkdrop development team - how will this be achieved ?
Nitorami is offline   Reply With Quote
Old 26th January 2009, 21:26   #14
Flexi
wellspring of milk
Major Dude
 
Flexi's Avatar
 
Join Date: Apr 2007
Location: 54.089866,12.11168,18.75
Posts: 2,058
Send a message via ICQ to Flexi
I'm on the winamp-beta mailing list - i can send an email, but i will do some further tests beforehand - at the moment it looks like the change compromises the GetBlur1 behavior too much - i will write when i know more about the interdependencies.
Flexi is offline   Reply With Quote
Old 28th January 2009, 01:24   #15
Saint Goody
Senior Member
 
Join Date: Apr 2008
Location: Somewhere in Southern Indiana
Posts: 184
ehh, I reformatted and upgraded...

I'll see what I can dredge up, or maybe narrow it down to a specific effect.

The first thing I noticed was that my Irdu Lili preset seemed a lot more clearly defined and the colors seemed to cycle much more effectively.

I am the purple heathen.
Saint Goody is offline   Reply With Quote
Old 28th January 2009, 01:29   #16
Saint Goody
Senior Member
 
Join Date: Apr 2008
Location: Somewhere in Southern Indiana
Posts: 184
here:
Attached Files
File Type: milk goody + flexi - irdu lili.milk (12.4 KB, 159 views)

I am the purple heathen.
Saint Goody is offline   Reply With Quote
Old 28th January 2009, 08:41   #17
Flexi
wellspring of milk
Major Dude
 
Flexi's Avatar
 
Join Date: Apr 2007
Location: 54.089866,12.11168,18.75
Posts: 2,058
Send a message via ICQ to Flexi
the problem is the blurring algorithm is cut into two passes: one horizontal and one vertical. But between the two passes the picture is sampled down two half of the screens resolution and so the true gaussian blur is compromised by rounding errors from the resizing step.
blur1_ps.fx and blur2_ps.fx are the shader scripts for each pass. Blur2 and Blur3 are calculated by the same shader as i see it, but in every step with a smaller version.

i found this one:
http://www.gamerendering.com/2008/10...filter-shader/
and i even fully reimplemented the blur, but i couldnt get rid of the loss of quality by downscaling.

I would rather like to see that the two blur passes are executed before resizing the sampler (if at all for Blur1)
Flexi is offline   Reply With Quote
Reply
Go Back   Winamp & Shoutcast Forums > Visualizations > MilkDrop > MilkDrop Presets

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