I'm just impressed as hell because I can't see the pattern in it.Mate Kovacs said:Yeah, it took me a lot of time to make that kanji-map (from four separate irregular maps).
What do you plan to use the effect for?
Pixel Shaders : How creative are you?
- Thread starter Reverend
- Start date
What do you plan to use the effect for?
Mate Kovacs
Newcomer
And I forgot to tell that on the first 3 pictures only an 80x50 portion of the whole (128x128) index-map is wrapped on the quad, because I wanted to mimic a VGA character mode. And on the last 2 pictures only a 64x64 portion is used in order to make those beautiful kanjis more noticeable.digitalwanderer said:I'm just impressed as hell because I can't see the pattern in it.
Nothing serious. (I'm graduating from high-school these days.
) But I think it could be useful if I wanted to make a game like System Shock or DeusEx. You can spare a lot of texture/vertex memory when you need to render interactive displays.Mintmaster
Veteran
For simple bump mapping, yes. But you are being very short sighted.DemoCoder said:
EMBM gives you dependent texture reads. There are TONS of effects you can do with EMBM, but DP3 gives you one thing only without dependent texturing: bump mapping. That's it.
EMBM can give you:
-bump mapping, though not as correct as DP3 for simple Lambertian lighting
-advanced lighting, like colour change with angle, anisotropic lighting
-reflective bumpy surfaces
-heat waves like in Gran Turismo 3, Doom 3
-per pixel refraction/reflection modulation for frosted glass, raindrops and streaks on windows, water (much more correct, in fact, than texm3x3vspec water which is what all the developers jumped on)
-offset/parallax mapping
ATI, Matrox should have had a better demo and devrel team to sell this feature. Some of the above effects require some creativity, but dependent texturing has done worlds more for computer graphics than DP3. You really didn't give much thought in your above statements, which I say are completely wrong.
You have to think outside the name "EMBM" to realize how powerful it is.
Woah, I'm quite impressed it looks that good with PS1.4. I implemented a tile shader about a year ago using PS2.0 and later PS2.x because you really need gradient instructions and texldd to get proper LOD calculation at the tile edges.Mate Kovacs said:
You might be interested in reading the Tile-Based Texture Mapping chapter in GPU Gems 2 by Li-Yi Wei.
Mintmaster, fixed-function EMBM and generalized dependent texture reads are not the same. And almost every kind of per-pixel lighting calculation needs dot product operations.
Mintmaster said:
Now who's the one that's shortsighted? DP3 only gives bump mapping? No it doesn't. Atleast not on NVidia's old HW. Dot product is the fundamental building block for all vector mathematics. It is the workhouse of all shaders. Virtually any interesting operation you want to do in a shader requires DP3/DP4 instructions. DP3 allows you to do tons of effects without dependent texturing. For example, per-pixel phong was done on GF2 with register combiners. Not every interesting effect requires a perturbed map lookup, in fact, there are plenty of interesting shaders effects done without dependent lookup. Without DP3, and with only EMBM, you would lose far more flexibility and your performance would suck.
"Completely wrong"? Talk about a reactionary comment. Dependent texturing != EMBM. EMBM as implemented by Matrox was far more limited than the way DP3 could be utilized in register combiners. Not until PS1.4 and PS2.0 did dependent lookups become really useful.
Your comments are like saying "EMBM has done worlds more for computer graphics than ADD or MUL. So I say you are completely wrong."
ADD, MUL, and DP3 are fundamental. EMBM was an hardcoded macro op. The decomposition of EMBM into TEX, DP instructions provided a superior and more flexible solution.
So I stand by my assertion that DP3 is more useful than EMBM, as are the other primitive ALU ops, such as ADD, MUL, MUX, etc
Hmm, reverend, your question is pretty weird... You can use fragment shaders to archieve a great variety of effects... That's all I can say. If you look for most creative effect implementatons, that's another thing. I mean, the question is not "what can you do with fs" but "what do you want to do with it". The most interesting effect I ever implemented by now was a kind of complex lighting, where the light sources where of custom form(like an neon body effect). I wasn't programming graphics for about a year now... Gotta start it again
DudeMiester
Regular
I made a crazy pixel shader once in CG. It was phong lighting, but I took the specular highlight, added a circular ripple pattern, then made it darken the surface. Then I modulated the final colour with something very hard to describe.
//Crazy wave that consists of many rings around the center of the screen
float Wave1=cos(sin(dot(IN.PixelPos, IN.PixelPos)*10));
//Even crazier wave that consists of horizontal bands that use the texture as an offset
float Wave2=cos((IN.PixelPos.y+TexCol.x/2)*20)*0.5+1;
//Here's how it's combined
OUT.Colour.rgb=(DiffuseLight.xxx*TexColour.rgb-SpecularLight.xxx*Wave1)*LightColor.rgb*Wave2;
Actually you can just download it yourself (SM3.0 required ... I think, lol):
http://ca.geocities.com/dudemiester@rogers.com/SimpleProg.zip
//Crazy wave that consists of many rings around the center of the screen
float Wave1=cos(sin(dot(IN.PixelPos, IN.PixelPos)*10));
//Even crazier wave that consists of horizontal bands that use the texture as an offset
float Wave2=cos((IN.PixelPos.y+TexCol.x/2)*20)*0.5+1;
//Here's how it's combined
OUT.Colour.rgb=(DiffuseLight.xxx*TexColour.rgb-SpecularLight.xxx*Wave1)*LightColor.rgb*Wave2;
Actually you can just download it yourself (SM3.0 required ... I think, lol):
http://ca.geocities.com/dudemiester@rogers.com/SimpleProg.zip
Mate Kovacs
Newcomer
In fact, from a greater distance it looks very odd, because the whole texture starts flickering, due to the lack of "manual filtering" in the shader. So I'll read that paper, thank you.Xmas said:
But unfortunately I've got a Radeon8500, so only PS1.4 to play around with.Back on topic.....
Well, there's been a whole lot of work on very interesting pixel shaders on the research front, but not a whole lot from games yet as far as I can see. I think the main issue is that in order to do anything interesting, you have to have custom shaders for lots of different things. There just haven't been the tools available to do that efficiently. So, personally, I feel that UE3 is going to provide the shader generation scheme that is going to allow really unique-looking materials and thus really put shader usage to the forefront.
Well, there's been a whole lot of work on very interesting pixel shaders on the research front, but not a whole lot from games yet as far as I can see. I think the main issue is that in order to do anything interesting, you have to have custom shaders for lots of different things. There just haven't been the tools available to do that efficiently. So, personally, I feel that UE3 is going to provide the shader generation scheme that is going to allow really unique-looking materials and thus really put shader usage to the forefront.
Chalnoth said:Dude, that's Chinese, sheesh....digitalwanderer said:I like the japanese version better than the english one.
Chinese and Japanese share many Hanzi/Kanji characters. Given characters in isolation or randomized, it could be either. Only in a grammatical context can you tell. In the Matrix movies, they used Japanese characters (Katakana), rotated on their side.
Actually, they were flipped left/right in The Matrix (This is really obvious for an English-speaker if you just look at the numbers interspersed in the text).DemoCoder said:
But yeah, I suppose that is true. I don't know enough about how the characters are stored in the computer to know whether or not you'd typically place Hiragana/Katakana within the same table as Kanji (Although you probably would, because there are only around 40 each of the Hiragana and Katakana, but about 3,000 Kanji, or 30,000 if it's Chinese).
Mate Kovacs
Newcomer
While I was reading that paper I noticed that my algorithm is much simpler, and easier to implement.
Here's the shader code:
I think the instructions marked with [1] and [2] need further explanation. These two instructions are depending on the number of tiles on the tile-map, and the number of indices on the index-map. In the above case the tile-map consists of 32x16 tiles, and the index-map consists of 64x64 indices (which are 2D displacement vectors, in fact). Thus the texture coordinates within an index-map texel (n;m) are range in [n/64;(n+1)/64[ and [m/64;(m+1)/64[ respectively. The displacement coordinates on the index-map are set to multiples of 1/64, so we can think of them as they were integers i and j added to n and m respectively. So after the displacement is applied, the texture coordinates range in [(n+i)/64;(n+i+1)/64[ and [(m+j)/64;(m+j+1)/64[. (Thus with properly setting i and j, we are able to put any tile into that (n;m) place of the virtual texture.) But within the (n+i;m+j) tile on the tile-map the texture coordinates must range in [(n+i)/32;(n+i+1)/32[ and [(m+j)/16;(m+j+1)/16[, so we need to scale them, and that's why those instructions are there.
EDIT: I forgot to mention that the index-map sampler needs to be in nearest-point mode (or at least it's magfilter).
Here's the shader code:
Code:
ps_1_4
texcrd r0.rgb,t0
texld r1,t0
add r0.rg,r0,r1
mov_x2 r0.r,r0 ;[1]
mov_x4 r0.g,r0 ;[2]
phase
texld r0,r0EDIT: I forgot to mention that the index-map sampler needs to be in nearest-point mode (or at least it's magfilter).
This is how my shaders look like:
PS2.0 version (LOD artifacts at tile edges)
And the PS2.x variant that fixes the problems
Unfortunately, texldd is very slow (I only have a Radeon 9600/9800, so I need to use refrast anyway). NVidia states texldl or texldb is much faster, but I didn't try it yet.
PS2.0 version (LOD artifacts at tile edges)
Code:
ps_2_0
dcl_2d s0
dcl_2d s1
dcl t0
def c0, 0.03125, 0.03125, 0, 0
def c1, 0.25, 0.5, 0, 0
mul r0, t0, c0
texld r0, r0, s0
frc r1.xy, t0
mad r0.y, -r0.y, r1.y, r0.y
mad r1.xy, r1, c1, r0
texld r0, r1, s1
mov oC0, r0And the PS2.x variant that fixes the problems
Code:
ps_2_x
dcl_2d s0
dcl_2d s1
dcl t0
def c0, 0.03125, 0.03125, 0, 0
def c1, 0.25, 0.5, 0, 0
mul r0.xy, t0, c0
texld r0, r0, s0
mul r1.xy, t0, c1
dsx r2.xy, r1
dsy r3.xy, r1
frc r1.xy, t0
mad r0.y, -r0.y, r1.y, r0.y
mad r1.xy, r1, c1, r0
texldd r0, r1, s1, r2, r3
mov oC0, r0Mintmaster
Veteran
I don't know what your definition of bump mapping is, but mine includes phong shading. When I say bump mapping, I mean per pixel lighting. It is the use of a different normal vector across the face of a polygon. Phong shading could be done per vertex before with gourad interpolation, and bump mapping, or more specifically normal mapping, allows it to be done per pixel.DemoCoder said:
I don't see how you can interpret "bump mapping" any other way. In offline 3D renderering programs you usually use height maps, but these are just details.
Other than per pixel lighting, what effect can you do with DP3 without dependent texture reads? I can't think of anything, and you haven't mentioned anything either.
I don't know what your definition of flexibility is either. DP3 --> per pixel lighting (I'm still waiting to hear all the magical shaders you keep mentioning). EMBM --> tons of effects, as mentioned above, including per pixel lighting. Please, prove me wrong on this point before you go any further.
Performance would suck? If properly designed, it won't suffer much at all. The original Radeon had 75% of the EMBM performance of GF3. The R300/R420 and NV40 have nearly zero performance impact from dependent texture reads. You're just replacing a math op with a texture op for strict DP3, and remember that a texture read can replace many math functions because it is essentially a lookup table. Even for your phong shading example, if the specular exponent is not unity, EMBM will likely be faster.
I really have no idea what's going through your mind when you make these statements.
Again, you're thinking short-sightedly. Remember render to texture? You can do plenty of ops, then multipass and essentially get a dependent texture read to anywhere. Like I said before, it requires some creativity, but EMBM gives the hardware a new dimension of capability.
Uhh, no, my comments aren't saying that. DP3 can be broken down into ADD and MUL, and so is not fundamental. I'm not suggesting you do that, though, because EMBM gives a very good approximation for per pixel lighting - the only thing I see DP3 is useful for without dependent texturing.
Take a look. That is only lighting, not even the reflections that EMBM is capable of. DP3 won't look any better.
True, just as for PS 1.1 dependent texture lookups (e.g. texm3x3vspec). But using render to target, you can overcome many limitations of the hardcoded nature.
More to the point of this discussion, neither DP3 nor any other method can come close to achieving some of the effects EMBM is capable of. EMBM, on the other hand, can give you lighting that is quite close to the "correct" DP3, and can give you more advanced lighting as well.
Well, I disagree. I've given you boatloads of evidence to support my position.
You've given me nothing but semantic arguments related to your definitions of "bump-mapping", "fundamental", and "hardcoded".
ehe... somehow I knew I opened Pandora's box with stating that nVidia didn't want to implement EMBM.
as said, Radeon 7xxx series were capable doing DOT3 as well as EMBM, so with register com....
GOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAALLLL!!!!!
(finland leads 2-0 against russia in ice hockey wc match...)
were I was?? oh yeah...
...biners and 3 tmus it should be far more capable than NV1x -series chips. Still, NV1x got native support to Doom3 and Radeon 7xxx didn't.
so, it is not always about who has got best features, but who is able to make best deals.
as said, Radeon 7xxx series were capable doing DOT3 as well as EMBM, so with register com....
GOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAALLLL!!!!!
(finland leads 2-0 against russia in ice hockey wc match...)
were I was?? oh yeah...
...biners and 3 tmus it should be far more capable than NV1x -series chips. Still, NV1x got native support to Doom3 and Radeon 7xxx didn't.
so, it is not always about who has got best features, but who is able to make best deals.
Mate Kovacs
Newcomer
Oh, f*ck, I missed it!Nappe1 said:
Mintmaster said:
You're the one playing semantic arguments by attempting to redefine what bump mapping means. Traditional per-pixel phong shading doesn't even use a texture map AT ALL, so it is not mapping of any sort, but merely per-pixel renormalization of light vectors and half angle vectors which have been distorted by linear interpolation. You're trying to tell people that something that doesn't even use texture lookups is a form of bump mapping? You made a an overly broad statement and now YOU are the one trying to wiggle out of it with semantics.
And now your poo-pooing all per-pixel lighting? Isn't the whole *raison d'etre* of pixel shaders, their first and foremost function before all others, to compute lighting? Lighting is fundamentally the most important aspect of 3D rendering, it's what distinguishes photorealism from photounrealism.
Storing per-pixel geometry data (normals, tangents, PRT, PTM, etc) and using it with dp3 is now relegated by you to mere "bump mapping" (and you equate bump mapping == per pixel lighting) as if per-pixel lighting is something not important.
I don't know what to say. I used to have alot of respect for you, but your responses in this thread are quite weird. You have a tendency to conflate meanings and lump things together (bump mapping == per pixel lighting, EMBM == dependant texture lookups) as if they are one in the same, whereas most people see a subset relationship, not an equivalence.