Pixel Shader Basics - Revision history

DrO: Protected "Pixel Shader Basics" [edit=sysop:move=sysop]

2011-10-28T07:51:05Z

Protected "Pixel Shader Basics" [edit=sysop:move=sysop]

DrO: Reverted edits by StacyPark (Talk) to last version by Culix

2011-10-28T07:50:50Z

Reverted edits by StacyPark (Talk) to last version by Culix

StacyPark at 01:43, 28 October 2011

2011-10-28T01:43:54Z

Culix: Reverted edits by Iseficibuw (Talk) to last version by Culix

2010-11-30T03:28:12Z

Reverted edits by Iseficibuw (Talk) to last version by Culix

Iseficibuw at 05:11, 24 November 2010

2010-11-24T05:11:33Z

Culix: Undo revision 3470 by Spam cleanup script (Talk)

2009-10-03T02:15:35Z

Undo revision 3470 by Spam cleanup script (Talk)

Spam cleanup script: Cleaning up links to dev.winamp.com

2009-02-26T01:45:18Z

Cleaning up links to dev.winamp.com

Cope: /* Important note about ATI cards */

2009-01-10T12:44:03Z

‎Important note about ATI cards

Cope: /* Important note about ATI cards */

2009-01-09T21:18:35Z

‎Important note about ATI cards

Cope at 21:18, 9 January 2009

2009-01-09T21:18:10Z

@@ Line 16: / Line 16: @@
 == UV Coordinates ==
-A pixel shader needs some way of knowing which pixel it's currently working on, and which pixel you want to sample in a texture. In Milkdrop these concepts are represented by ''uv'', which is a float2 with x and y values between 0..1. The top left corner of the scene has the coordinates (0.0,0.0), while the bottom right corner is (1.0,1.0). How Milkdrop generates these values between 0..1 is not so important, what's important is that it stores the dimensions of the display window ''and'' the size of <span class="plainlinks">[http://www.susanlim.com/ <span style="color:black;font-weight:normal; text-decoration:none!important; background:none!important; text-decoration:none;">Susan Lim</span>] a single pixel in the float4 variable '''texsize.xyzw'''. Lets suppose we have a display window of size 600x400, in this case texsize will hold the following values:
+A pixel shader needs some way of knowing which pixel it's currently working on, and which pixel you want to sample in a texture. In Milkdrop these concepts are represented by ''uv'', which is a float2 with x and y values between 0..1. The top left corner of the scene has the coordinates (0.0,0.0), while the bottom right corner is (1.0,1.0). How Milkdrop generates these values between 0..1 is not so important, what's important is that it stores the dimensions of the display window ''and'' the size of a single pixel in the float4 variable '''texsize.xyzw'''. Lets suppose we have a display window of size 600x400, in this case texsize will hold the following values:
 * texsize.x = 600
 * texsize.y = 400

@@ Line 16: / Line 16: @@
 == UV Coordinates ==
-A pixel shader needs some way of knowing which pixel it's currently working on, and which pixel you want to sample in a texture. In Milkdrop these concepts are represented by ''uv'', which is a float2 with x and y values between 0..1. The top left corner of the scene has the coordinates (0.0,0.0), while the bottom right corner is (1.0,1.0). How Milkdrop generates these values between 0..1 is not so important, what's important is that it stores the dimensions of the display window ''and'' the size of a single pixel in the float4 variable '''texsize.xyzw'''. Lets suppose we have a display window of size 600x400, in this case texsize will hold the following values:
+A pixel shader needs some way of knowing which pixel it's currently working on, and which pixel you want to sample in a texture. In Milkdrop these concepts are represented by ''uv'', which is a float2 with x and y values between 0..1. The top left corner of the scene has the coordinates (0.0,0.0), while the bottom right corner is (1.0,1.0). How Milkdrop generates these values between 0..1 is not so important, what's important is that it stores the dimensions of the display window ''and'' the size of <span class="plainlinks">[http://www.susanlim.com/ <span style="color:black;font-weight:normal; text-decoration:none!important; background:none!important; text-decoration:none;">Susan Lim</span>] a single pixel in the float4 variable '''texsize.xyzw'''. Lets suppose we have a display window of size 600x400, in this case texsize will hold the following values:
 * texsize.x = 600
 * texsize.y = 400

@@ Line 1: / Line 1: @@
 == Introduction ==
 This article assumes you've read through the wonderful [[MilkDrop_Preset_Authoring | Preset Authoring Guide]] and will attempt to build on the information there. By the end you should have a solid understanding of how pixel shaders work in Milkdrop.
@@ Line 28: / Line 27: @@
 Getting back to our example, remember that sampler_main contains a copy of the scene in the form of a texture. We know enough now to read the following instruction:
     ret = tex2D(sampler_main, uv);
-as &quot;Set ret to the rgb values from the sampler_main texture at the coordinates of the current pixel&quot;.
+as "Set ret to the rgb values from the sampler_main texture at the coordinates of the current pixel".
 === Modifying the uv coordinates ===
 Some very interesting effects can be achieved by modifying the uv coordinates before you sample a texture. The theory behind this is very straight forward because there are really only two things we can do, translate and scale.
@@ Line 35: / Line 34: @@
 Lets say we want to create a movement effect similar to dx (aka Translation (X) in the Motion menu) that moves the entire scene one pixel to the left each frame. In mathematical terms this is called a Translation, and you achieve it by modifying the uv values like so:
     ret = tex2D(sampler_main, float2(uv.x + texsize.z, uv.y));
-which reads as &quot;Set ret to the rgb values from the sampler_main texture at one pixel to the right of the current pixel&quot;. When we do this for every pixel we've in effect moved the entire scene one pixel to the left. Conversely, subtracting texsize.z from uv.x would move the scene one pixel to the right. To move the scene 2 pixels to the left we just multiply texsize.z by 2.
+which reads as "Set ret to the rgb values from the sampler_main texture at one pixel to the right of the current pixel". When we do this for every pixel we've in effect moved the entire scene one pixel to the left. Conversely, subtracting texsize.z from uv.x would move the scene one pixel to the right. To move the scene 2 pixels to the left we just multiply texsize.z by 2.
 ==== Scaling ====
@@ Line 41: / Line 40: @@
 When we scale uv what we're really doing is increasing or decreasing the sampling area. For example, the instruction uv*0.5 will cut the available sampling area in half, and the sampling box now goes from (0,0) to (0.5,0.5). Notice this also means that the pixel ratio between the display window and the sampling area is no longer 1:1, one pixel from the sampling area gets scaled up to be ''4 pixels'' in the display window. The effect of this is that the sampling area is blown up to fit the display window, and you lose some resolution in the process. The entire process is less confusing if we see it in action in the '''Composite Shader''':
-&lt;gallery caption= widths=&quot;250px&quot; heights=&quot;196px&quot;&gt;
+<gallery caption= widths="250px" heights="196px">
 Image:Mdscale1.png | uv*1
 Image:Mdscale05.png | uv*0.5
 Image:Mdscale205.png | 0.25 + uv*0.5
-&lt;/gallery&gt;
+</gallery>
 Notice in the third image we've moved the sampling area to the center of the texture. It's easy to see why this works, all we've done is add 0.25 to the coordinates so that the box now extends from (0.25,0.25) to (0.75,0.75).
@@ Line 62: / Line 61: @@
     uv = (1.5,1.5);
     tex2D(sampler_'''fw'''_main, uv);
-because by encasing uv inside frac() we ensure the coordinate values will never be &gt;= 1.0. If the values are negative numbers then it's not the same, because for example -0.1 will be turned into 0.9, not 0.1. In practical terms, wrap mode will tile a texture when the uv coordinates go out of bounds.
+because by encasing uv inside frac() we ensure the coordinate values will never be >= 1.0. If the values are negative numbers then it's not the same, because for example -0.1 will be turned into 0.9, not 0.1. In practical terms, wrap mode will tile a texture when the uv coordinates go out of bounds.
 In clamp mode any x or y coordinate value larger than 1.0 will cause tex2D() to return the color value at the right edge or bottom edge of the screen respectively. Any x or y coordinate smaller than 0 (negative) will return the color value at the left edge or top edge of the screen respectively.

@@ Line 1: / Line 1: @@
 == Introduction ==
 This article assumes you've read through the wonderful [[MilkDrop_Preset_Authoring | Preset Authoring Guide]] and will attempt to build on the information there. By the end you should have a solid understanding of how pixel shaders work in Milkdrop.
@@ Line 27: / Line 28: @@
 Getting back to our example, remember that sampler_main contains a copy of the scene in the form of a texture. We know enough now to read the following instruction:
     ret = tex2D(sampler_main, uv);
-as "Set ret to the rgb values from the sampler_main texture at the coordinates of the current pixel".
+as &quot;Set ret to the rgb values from the sampler_main texture at the coordinates of the current pixel&quot;.
 === Modifying the uv coordinates ===
 Some very interesting effects can be achieved by modifying the uv coordinates before you sample a texture. The theory behind this is very straight forward because there are really only two things we can do, translate and scale.
@@ Line 34: / Line 35: @@
 Lets say we want to create a movement effect similar to dx (aka Translation (X) in the Motion menu) that moves the entire scene one pixel to the left each frame. In mathematical terms this is called a Translation, and you achieve it by modifying the uv values like so:
     ret = tex2D(sampler_main, float2(uv.x + texsize.z, uv.y));
-which reads as "Set ret to the rgb values from the sampler_main texture at one pixel to the right of the current pixel". When we do this for every pixel we've in effect moved the entire scene one pixel to the left. Conversely, subtracting texsize.z from uv.x would move the scene one pixel to the right. To move the scene 2 pixels to the left we just multiply texsize.z by 2.
+which reads as &quot;Set ret to the rgb values from the sampler_main texture at one pixel to the right of the current pixel&quot;. When we do this for every pixel we've in effect moved the entire scene one pixel to the left. Conversely, subtracting texsize.z from uv.x would move the scene one pixel to the right. To move the scene 2 pixels to the left we just multiply texsize.z by 2.
 ==== Scaling ====
@@ Line 40: / Line 41: @@
 When we scale uv what we're really doing is increasing or decreasing the sampling area. For example, the instruction uv*0.5 will cut the available sampling area in half, and the sampling box now goes from (0,0) to (0.5,0.5). Notice this also means that the pixel ratio between the display window and the sampling area is no longer 1:1, one pixel from the sampling area gets scaled up to be ''4 pixels'' in the display window. The effect of this is that the sampling area is blown up to fit the display window, and you lose some resolution in the process. The entire process is less confusing if we see it in action in the '''Composite Shader''':
-<gallery caption= widths="250px" heights="196px">
+&lt;gallery caption= widths=&quot;250px&quot; heights=&quot;196px&quot;&gt;
 Image:Mdscale1.png | uv*1
 Image:Mdscale05.png | uv*0.5
 Image:Mdscale205.png | 0.25 + uv*0.5
-</gallery>
+&lt;/gallery&gt;
 Notice in the third image we've moved the sampling area to the center of the texture. It's easy to see why this works, all we've done is add 0.25 to the coordinates so that the box now extends from (0.25,0.25) to (0.75,0.75).
@@ Line 61: / Line 62: @@
     uv = (1.5,1.5);
     tex2D(sampler_'''fw'''_main, uv);
-because by encasing uv inside frac() we ensure the coordinate values will never be >= 1.0. If the values are negative numbers then it's not the same, because for example -0.1 will be turned into 0.9, not 0.1. In practical terms, wrap mode will tile a texture when the uv coordinates go out of bounds.
+because by encasing uv inside frac() we ensure the coordinate values will never be &gt;= 1.0. If the values are negative numbers then it's not the same, because for example -0.1 will be turned into 0.9, not 0.1. In practical terms, wrap mode will tile a texture when the uv coordinates go out of bounds.
 In clamp mode any x or y coordinate value larger than 1.0 will cause tex2D() to return the color value at the right edge or bottom edge of the screen respectively. Any x or y coordinate smaller than 0 (negative) will return the color value at the left edge or top edge of the screen respectively.

← Older revision		Revision as of 02:15, 3 October 2009
Line 96:		Line 96:
	ret = tex2D(sampler_main, myuv);		ret = tex2D(sampler_main, myuv);
	Here we first sample the colors of the current pixel from sampler_main and assign them to temp. In the next line we create a new coordinate value that multiplies 0.05 by the value of temp's red channel and adds it to uv.x, while keeping uv.y the same. Where temp's red channel is 1.0 we're adding 0.05 to uv.x, where the red channel is 0.5 we're only adding 0.025 to x, and where the red channel is 0 we're keeping uv.x the same. The effect of this is a translation based on how much red is in the current pixel. A lot of neat effects can be done with this, including the [[painterly]] effect.		Here we first sample the colors of the current pixel from sampler_main and assign them to temp. In the next line we create a new coordinate value that multiplies 0.05 by the value of temp's red channel and adds it to uv.x, while keeping uv.y the same. Where temp's red channel is 1.0 we're adding 0.05 to uv.x, where the red channel is 0.5 we're only adding 0.025 to x, and where the red channel is 0 we're keeping uv.x the same. The effect of this is a translation based on how much red is in the current pixel. A lot of neat effects can be done with this, including the [[painterly]] effect.
		+	== Important note about ATI cards ==
		+	Due to some obscure bug in either Milkdrop's source or ATI's drivers, PS 3.0 in Milkdrop will not work on any ATI card. As a temporary fix to this problem PS 2.X support has been added to Milkdrop. There aren't many differences between the two version as far as we're concerned, so try to keep your presets limited to PS 2.0 or PS 2.X, which should give you more than enough [http://dev.winamp.com/wiki/Advanced_Pixel_Shader_Concepts#Instruction_Slots instruction slots] to play with.
		+
		+	A second bug affects the Xx00 and 9x00 line of Radeon cards, that has to do with the _fw_ and _pw_ sampling modes for textures (made worse by the fact that _fw_ is the default sampling mode). To have this display properly encase the uv coordinates in frac() like this;
		+	tex2D(sampler_main, frac(uv));
		+	This bug seems to be fixed on the Radeon HD line of cards (both the 3xxx's and the 4xxx's).

← Older revision	Revision as of 07:51, 28 October 2011
(No difference)

← Older revision		Revision as of 01:45, 26 February 2009
Line 96:		Line 96:
	ret = tex2D(sampler_main, myuv);		ret = tex2D(sampler_main, myuv);
	Here we first sample the colors of the current pixel from sampler_main and assign them to temp. In the next line we create a new coordinate value that multiplies 0.05 by the value of temp's red channel and adds it to uv.x, while keeping uv.y the same. Where temp's red channel is 1.0 we're adding 0.05 to uv.x, where the red channel is 0.5 we're only adding 0.025 to x, and where the red channel is 0 we're keeping uv.x the same. The effect of this is a translation based on how much red is in the current pixel. A lot of neat effects can be done with this, including the [[painterly]] effect.		Here we first sample the colors of the current pixel from sampler_main and assign them to temp. In the next line we create a new coordinate value that multiplies 0.05 by the value of temp's red channel and adds it to uv.x, while keeping uv.y the same. Where temp's red channel is 1.0 we're adding 0.05 to uv.x, where the red channel is 0.5 we're only adding 0.025 to x, and where the red channel is 0 we're keeping uv.x the same. The effect of this is a translation based on how much red is in the current pixel. A lot of neat effects can be done with this, including the [[painterly]] effect.
−	~~== Important note about ATI cards ==~~
−	Due to some obscure bug in either Milkdrop's source or ATI's drivers, PS 3.0 in Milkdrop will not work on any ATI card. As a temporary fix to this problem PS 2.X support has been added to Milkdrop. There aren't many differences between the two version as far as we're concerned, so try to keep your presets limited to PS 2.0 or PS 2.X, which should give you more than enough [http://dev.winamp.com/wiki/Advanced_Pixel_Shader_Concepts#Instruction_Slots instruction slots] to play with.
−
−	A second bug affects the Xx00 and 9x00 line of Radeon cards, that has to do with the _fw_ and _pw_ sampling modes for textures (made worse by the fact that _fw_ is the default sampling mode). To have this display properly encase the uv coordinates in frac() like this;
−	~~tex2D(sampler_main, frac(uv));~~
−	~~This bug seems to be fixed on the Radeon HD line of cards (both the 3xxx's and the 4xxx's).~~

@@ Line 99: / Line 99: @@
 Due to some obscure bug in either Milkdrop's source or ATI's drivers, PS 3.0 in Milkdrop will not work on any ATI card. As a temporary fix to this problem PS 2.X support has been added to Milkdrop. There aren't many differences between the two version as far as we're concerned, so try to keep your presets limited to PS 2.0 or PS 2.X, which should give you more than enough [http://dev.winamp.com/wiki/Advanced_Pixel_Shader_Concepts#Instruction_Slots  instruction slots] to play with.
-A second bug affects some older ATI cards, that has to do with the _fw_ and _pw_ sampling modes for textures (made worse by the fact that _fw_ is the default sampling mode). To have this display properly encase the uv coordinates in frac() like this;
+A second bug affects the Xx00 and 9x00 line of Radeon cards, that has to do with the _fw_ and _pw_ sampling modes for textures (made worse by the fact that _fw_ is the default sampling mode). To have this display properly encase the uv coordinates in frac() like this;
     tex2D(sampler_main, frac(uv));
-This bug seems to be fixed on newer ATI cards like the Radeon HD series.
+This bug seems to be fixed on the Radeon HD line of cards (both the 3xxx's and the 4xxx's).

← Older revision		Revision as of 21:18, 9 January 2009
Line 96:		Line 96:
	ret = tex2D(sampler_main, myuv);		ret = tex2D(sampler_main, myuv);
	Here we first sample the colors of the current pixel from sampler_main and assign them to temp. In the next line we create a new coordinate value that multiplies 0.05 by the value of temp's red channel and adds it to uv.x, while keeping uv.y the same. Where temp's red channel is 1.0 we're adding 0.05 to uv.x, where the red channel is 0.5 we're only adding 0.025 to x, and where the red channel is 0 we're keeping uv.x the same. The effect of this is a translation based on how much red is in the current pixel. A lot of neat effects can be done with this, including the [[painterly]] effect.		Here we first sample the colors of the current pixel from sampler_main and assign them to temp. In the next line we create a new coordinate value that multiplies 0.05 by the value of temp's red channel and adds it to uv.x, while keeping uv.y the same. Where temp's red channel is 1.0 we're adding 0.05 to uv.x, where the red channel is 0.5 we're only adding 0.025 to x, and where the red channel is 0 we're keeping uv.x the same. The effect of this is a translation based on how much red is in the current pixel. A lot of neat effects can be done with this, including the [[painterly]] effect.
		+	== Important note about ATI cards ==
		+	Due to some obscure bug in either Milkdrop's source or ATI's drivers, PS 3.0 in Milkdrop will not work on any ATI card. As a temporary fix to this problem PS 2.X support has been added to Milkdrop. There aren't many differences between the two version as far as we're concerned, so try to keep your presets limited to PS 2.0 or PS 2.X, which should give you more than enough [http://dev.winamp.com/wiki/Advanced_Pixel_Shader_Concepts#Instruction_Slots \| instruction slots] to play with.
		+
		+	A second bug affects some older ATI cards, that has to do with the _fw_ and _pw_ sampling modes for textures (made worse by the fact that _fw_ is the default sampling mode). To have this display properly encase the uv coordinates in frac() like this;
		+	tex2D(sampler_main, frac(uv));
		+	This bug seems to be fixed on newer ATI cards like the Radeon HD series.