Talk:Shader/Archive 1

Is this clear enough

Today's addition is: " It is also used to refer to video graphics hardware units that run these programs." While I understand its meaning ("this GPU has 8 fragment shaders" to mean "this GPU has 8 fragment shader processing units"), I believe it should be clarified. I tried rewriting this but I've realized I'm not confident enough with my English to get a decent result.

Is it the case to say this is actually a misuse of the word? I know this is actually very acknowledged (especially by DirectX folks and hardware sites) but I still believe it should be pointed out. MaxDZ8 18:32, 29 December 2005 (UTC)

Confusing/Too Technical (propose improvements here)

Would it be possible to add some pictures to this thing? That would help a ton. -FWIW.

I'm taking a note this is a often requested feature. I think I'll also write something on graphics pipeline, since the two things are deeply interconnected.

MaxDZ8 talk 09:28, 1 June 2006 (UTC)

From Bemmu: How about before & after images where first no shaders are used and then with shaders? I still have no idea what they do.

Too technical? The whole story is "the shaders make your picture increadibly realistic". This is coherent with the descriptions one finds all over the WEB. And this confuses people, making them to think about shaders like very cool image filtering algorithms. And this is where the problem appears. For this reason, it should be strongly emphasized that the shaders are not methods of 3D-rendering. People must know that they (shaders) are rather general-purpose programs (processes, (virtual) processors, computers, etc.). --Javalenok 18:36, 21 April 2006 (UTC)

Unluckly, it is not as easy. By themselves, shaders are so flexible they can simply provide the same functionality or implement a totally different one. A kind of comparison like this would be of little use in many cases because of no visible difference. In some others it is not possible (take for example parallax mapping) since there's no fixed function (non-shader) complement - in this case, sure there's a difference but not because of the shader itself. In some cases it would be like comparing apples to oranges.

I mean: shaders provide a functionality set. In the old paradigm, those features are pre-assembled so you can't have something different. With shaders you can compose all those "functionalities" as you wish so you actually have a superset of the old paradigm.

I would suggest to propose a set of "interesting shaders" to explain.

As a side note, there will be some explanations concerning the different shader models in that page in the form of "PSM3 allows you to do that while PSM2 doesn't".

I agree this is a problem but frankly, I am not sure of how can I fix it. MaxDZ8 _talk 17:23, 9 March 2006 (UTC)

From Bemmu: But certainly there are things shaders are generally used for? Can you do per-pixel phong shading with pixel shaders? Examples please.

I have noted this as a requested shader on my page. Note some per-pixel lighting can be done without shaders (although it's simplier) but don't hold your breath for it: it'll take a while. What should be covered?
MaxDZ8 talk 07:36, 23 August 2006 (UTC)

I found this article very hard going. It seems to have been written by someone who has a very good understanding of the area, but could really do with a broad edit, to simplify concepts and make the key points more visible. Rufous 17:10, 21 January 2006 (UTC)

I completey agree! I would really like to see more diagrams and examples as what's being described. I feel like I'm being crushed by this Death Star of text. User:NavStar

It is obvious that at least a pipeline diagram should be produced. It's on my todo list since 2005.

I would like to point out that writing you need a diagram without writing what diagram you need is just as saying nothing. There's the problem on wikipedia that not all articles are well written. Take for example bump mapping - there's really nothing technical involved, just two figures. Parallax mapping is even worse. I'll try to improve this but as you may have noticed from my contributions, I'm a bit off and the required changes are pretty extensive.

MaxDZ8 talk 06:18, 25 May 2006 (UTC)

Well, your point is taken. Maybe we should split this in two (or even more) articles? I understand your reasoning and I am ready in cooperating our efforts. Actually, I have some complaints:

1. I believe shader languages should really be discussed in their own page. (done it, MaxDZ8 _talk 18:15, 6 March 2006 (UTC))
2. Section 2.3 and 2.4 should really be moved to other pages, but those are just stubs for now. I decided to keep everything here until I fix the other pages.
3. I really don't know what the average Joe wants to know so feedback here is welcome. I think it's interesting providing some gory details but if you tell me it's not, I'll live with it.
4. I understand the meanings of vertex and fragment shaders are key concept and shall be moved somewhere other. Although fragment is the correct term (especially when FSAA is used) I would also consider pixel. Done, fragment is gone, pixel is now used (MaxDZ8 _talk 18:15, 6 March 2006 (UTC)).

MaxDZ8 17:51, 22 January 2006 (UTC)

Err, I prefer using Pixel rather than Fragment although it is not totally correct because it is more popular term. However, it is better if you put both in the article like: Fragment Shader (Eg.Pixel Shader). CMIIW, ok? Also, a number of picture/diagram may help explaining differences between Fragment and Vertex.Draconins 09:41, 2 February 2006 (UTC)

Ok, I'll use both fragment and pixel interchangeably, pointing out the differences in a paragraph. Diagrams will take some time but I could do it (is there any tool to make nice diagrams easily?). MaxDZ8 _talk 14:11, 2 February 2006 (UTC)

TODO for this page:

• Explain fragment/pixel in a paragraph (above). This has been done, according to your needs, the term pixel has been preferred - even the OpenGL folks seems to be converging to it anyway (MaxDZ8 _talk 18:15, 6 March 2006 (UTC)).
• Add info on shader models in other page (now redirecting here) (below)
• Put shader languages in its own page (is there the need for more info?) (above) Done, maybe it would be nice to check it out a bit (MaxDZ8 _talk 18:15, 6 March 2006 (UTC)).

I guess I'll be able to do that by the end of the month. I'm a little busy now. MaxDZ8 _talk 18:29, 3 February 2006 (UTC)

rethink automatic redirection from shader model to shader

Hi, when I look for shader model I get redirected to this shader page. I think it's would be better to create a new page shader model and explain and compare the different shader model versions against each other. At least I was expecting to find this information when I was looking for shader model. --Cyc 11:19, 3 February 2006 (UTC)

I agree with you, this information is definetly necessary and deserves its own page. Unluckly I never put so much attention on the various DirectX shader models until lately so I'm a bit off there. In case no one other will propose a writing, I'll do it. MaxDZ8 _talk 18:20, 3 February 2006 (UTC)

I've finally found some time to work on those pages and applied some changes. The shader model page is still a stub but I'm working on it. Don't hold your breath, it's going to take more than just a while. MaxDZ8 _talk 18:15, 6 March 2006 (UTC)

Shader definition

The shader described in the first paragraph (Shaders...programs executed by multiple graphic processors running in parallel on a video card) is not the same thing as a shader described two paragraphs below (Initially introduced in Pixar's RenderMan, shaders...). I'm not sure how the rest of the industry uses the word, but as I understand it, a shader is simply a description (in a special shading language) of the material properties of a surface (e.g. is it red or green, is it shiny or dull, is it smooth or bumpy?). The whole vertex shader/pixel shader/GPU/video card stuff seems like pretty esoteric implementation details to me. Those details are definitely worthy of a page, but perhaps this particular page (Shader) should be about the basic definition of the shader. After all, outside of video games, almost everybody else (Renderman, etc.) is running their shaders in software. Kjl 03:05, 22 April 2006 (UTC)

Ah, I see. I've been trolling through the Shader article's history, and it seems that the article has gotten more confusing and less correct recently. In particular, the Revision as of 18:13, 4 March 2006 (See http://en.wikipedia.org/w/index.php?title=Shader&oldid=42220265 ) is a much better article on computer graphics shaders. A shader is not, as it is stated in the current article, a program that is run on specific graphics hardware, etc.. A shader is a description of surface properties. It was a mistake to remove renderman SL, opengl SL, Gelato SL, etc.. The real-time vertex + pixel shaders running on dedicated GPUs is a relatively new development, and is an addition to, not a replacement for other shaders. I would recommend reverting to that revision and starting to clean up from there. Kjl 08:31, 22 April 2006 (UTC)

Absolutly not. The word shader does have several meanings. It is used to identify the program describing surface properties but also the program implementation using a specific language. A shader is also the "compiled" object which is ran on hw (this also applies to sw shaders since they end up being processed anyway). Although incorrectly used, the word shader is being widespreadly used to identify the processing units used to process shading informations. The removal of the shader languages has been proposed on the talk page and I've realized shader languages are a different topic. There's no real difference between hw and sw shaders by themselves: the difference between "old" shaders and new ones is that they use different pipeline paradigms. I believe reverting would not help improving this more than it hurts. HW shaders must be covered in detail because they initiated a small revolution in the computing market by imposing a new programming paradigm with great results. I am confident discriminating old-type shaders from new ones will likely make things worse. As another plus, the average Joe is more likely to come here checking for the various HW shaders... this stuff is technical and esoteric. MaxDZ8 _talk 13:06, 22 April 2006 (UTC)

"HW shaders must be covered in detail because they initiated a small revolution in the computing market by imposing a new programming paradigm with great results". I suppose that's true. It's confusing because there are 2 (actually, more than 2 ;) ) uses of the word "shader" in the various graphics industries, but I still think that shaders should be covered from the general standpoint first (e.g. "What is a shader? A shader determines what a surface looks like in 3D computer graphics. Some shaders run in SW, and some run in HW"). I do agree that many average joe's are coming here from a computer-game point of view and so may be interested in pixel and vertex shaders running in HW, but I think equally many will be coming from the direction of special effects and CG in movies/tv/print. From that direction, it is not clear at all what shaders are in the context of that process (modeling (making 3D geometry), animation, lighting (placing lights in a scene), and shading (special programs running on parallel GPUs?; No - shading to define material color and other properties)). Kjl 22:59, 22 April 2006 (UTC)

Ok, I think I've got your point. Thank you, I'll try to fix this as soon as I'll update the page. Do you think it would be adeguate to define shaders as "special programs"? After all, recent shaders does not define color or position... it just happens they compute properties which are... well, color and position. I mean to say I would try to make this as generic as possible.

Cool - yeah I just think an opening paragraph explaining what exactly a shader does in the context of rendering pictures would be really useful (both for SW and HW shaders). Otherwise it would be like describing the intricacies of boat hull design, materials, and construction without mentioning that boats are meant to float on water ;) Unfortunately I don't have any knowledge of HW shaders (so I would be very interested to know how HW shaders fit into video card pipelines), but I know how SW shaders work, and I think that at least a top-level view of that should be on this page. (e.g. "shaders have access to surface normals and incoming lights, and compute the resultant color. Renderers deal with managing objects, cameras, and lights, and run object and light shaders as appropriate to construct the final image.") Kjl 16:38, 24 April 2006 (UTC)

You're right. After all most shaders will always process rendering data. I'm not sure of how to fix this (should be in the intro or in a section?) and I have too little time now to tackle the problem. I agree however this is The Right Way, even if a little over-simplified, since the problem can easily be fixed in a later article section.

As for SW shaders, could you provide some insights in them? I'm not sure I've told you that I'm out of ideas for covering them.

MaxDZ8 talk 08:59, 9 May 2006 (UTC)

As for the historical reference, should this be covered here or on another page? Information here seems to be pretty scarce...

MaxDZ8 _talk 13:01, 23 April 2006 (UTC)

Just to let you know, I've updated a prototype of shader models, to let you know some work is in progress behind the scenes, although slowly... MaxDZ8 _talk

MaxDZ8 - I'm back from the dead - sorry I never responded to you back in April. I added a very sloppy intro paragraph; sloppy because I don't know enough about HW/game shaders to add generalized shader information that I only know for sure is true about SW shaders. The intro hopefully provides a framework to which we can all add or fix information. The intro paragraph is an attempt to be a basic summary of what the purpose of a shader is and how it fits into the graphics pipeline. Kjl 00:46, 17 October 2006 (UTC)

I see. I'm a thinking at the little issue, which is the removal of the previous information (instead of the "addition" of new one). Ayway, the new text just reads better and I am confident this is a real improvement so thank you for your contribution!
MaxDZ8 talk 08:12, 17 October 2006 (UTC)

Today's addition

Since I noticed the intro gone too crazy to read, I've took some time to update it. I basically started from my last edit and walked up the history tree, taking whatever I found useful or interesting and melting togheter the whole thing. I hope I've succeeded in this.

An exception must be made for last edit, by 71.127.155.96, which has been virtually reverted. Reasons for this include:

1. I believe too much detail is lost when compared to prev version.
2. A reference is about a shading language rather than the shading technology itself, the other one was simply too abstracted to give useful informations.
3. GPGPU was totally lost. Telling that shaders can be used for generic computation is important.

MaxDZ8 talk 08:59, 9 May 2006 (UTC)

Hi , I believe the below statement , with the line "blinn lighting model, often referred as bump mapping" to be incorrect. The blinn lighting model is never referred to as bump mapping. You may be able to apply a bump map to a blinn shader, but that's true of Lambert, Phong or many other. Bump mapping is not intrinsically linked to Blinn.

"Lighting & Shadowing Considering the lighting equation, we have seen the trend to move evaluations to fragment granularity. Initially, the lighting computations were performed at vertex level (phong lighting model) but improvements in fragment processor designs allowed to evaluate much more complex lighting equations such as the blinn lighting model, often referred as bump mapping." Hixster 16:52, 7 July 2006 (UTC)

Yes, you're right. This was written because to the mass market "Blinn shading", "bump mapping" and "per-pixel lighting" are synonymous. As you say however, the approximation isn't technically correct (nor many other things market guys do). I thought this would not be a problem but reading your comment I realize this shall be fixed and I'm going to do this now.
MaxDZ8 talk 08:22, 8 July 2006 (UTC)

Bad Article. Too Specific. Should be targeting newbie audience. —The preceding unsigned comment was added by 137.226.101.48 (talk • contribs) 10:35, 28 July 2006 (UTC)

When is "Blinn shading" ever used to mean bump mapping? Jim Blinn came up with several different lighting models; the most commonly used one probably the Blinn-Phong shading model that is part of the OpenGL fixed functional vertex shader. I can find articles (PDF) describing the "Blinn lighting model" as a cheaper approximation to Cook-Torrance lighting, but the only place I can find any reference to bump mapping as "Blinn shading" or "Blinn lighting" is in this wikipedia article. Do you have any sources for this usage? It is Jim Blinn's idea, but his lighting model certainly isn't the same as his bump mapping method. - Rainwarrior 22:11, 28 July 2006 (UTC)

There are some papers on NV developer identifying bumpy as "blinn" (I'm not even sure they're still online) - no doubt, as said above, this is NOT technically correct. Since you have found no other sources for it, feel free to modify the thing: it's your right on the wiki and you also managed to point out the sources.
Technically, "Blinn lighting" is subsititing the reflection vector with an half-angle vector. "Blinn bump mapping" means fetching a normal perturbation and it has been introduced in the much-speaked-about paper "Simulation of wrinkled surfaces" (1978) - which de facto invented bump mapping. This has been used on the past to indicate bump mapping even when done on normalmapping instead of Blinn's method.
Anyway, it's a thing which is 30 years old. I personally would not care about those small issues, considering the state of the thing but you can obviously not agree and I would not stop you.
MaxDZ8 talk 09:57, 29 July 2006 (UTC)

I'm not sure whether you are saying that you are in disagreement or agreement with me. I was responding to this text in the article:

...evaluate much more complex lighting equations such as the blinn lighting model, often commonly referred as bump mapping (in this case however note the two terms are not technically synonimous but they are commonly used interchangeably because of wrong marketing issues)...

If it had said "Blinn technique of bump mapping" or something like that it would have seemed fine to me, but it says "blinn lighting model, often commonly referred as bump mapping". My question is: when was bump mapping referred to as the "Blinn lighting model"? The passage refers to marketing issues? - Rainwarrior 10:08, 29 July 2006 (UTC)

Agreement/Disagreement: I'm really neutral to this so you're encouraged carry on your improvements. I didn't realize you were questioning something.

when was...: first shading experiments, roughtly NV5-NV1x era. If I'll be able to find the original docs I'll point a link, but don't wait for it.

MaxDZ8 talk 07:14, 31 July 2006 (UTC)

Okay, I'm going to modify that paragraph for the following reasons:

1. Per vertex lighting is gouraud shading. (OpenGL by default gouraud shades using the Blinn-Phong reflection model.)

2. Per pixel lighting is phong shading.

3. There is no need to discuss confusion about bump mapping terminology here, if anywhere it should be part of bump mapping. I just think that introducing an incorrect term and then explaining why it is incorrect is... well, strange.

I also wonder about the importance the paragraph that follows puts on dynamic loops. I know that it makes programming a little easier, but it doesn't really open up any new possibilities that the conditional jump didn't already provide. Finite loops could be unrolled anyway. - Rainwarrior 09:40, 31 July 2006 (UTC)

By wording it that way, you've convinced me you're doing The Right Thing. Thank you very much for contributing to the article improving the wiki and discussing it here!

As for loops, conditionals are performed in 3 ways: compile-time-constant, uniform (static) and varying (dynamic). Parallax occlusion mapping is an example of dynamic looping (basically step raytracing on a heightfield) which cannot be unrolled, although it's possible to do it with static brenching for some additional cost. I'm not sure I get your point here. MaxDZ8 talk 08:08, 1 August 2006 (UTC)

Ahh, yes, you're right. On further thought, I realize that eventually the number of jumps is going to exceed the maximum code size for the shader. (Not to mention be completely unwieldly.) I will revise my statement to say that the given example of multiple lights is unsuitable. However, mention of parallax occlusion and other things for which dynamic loops are more or less integral (fractal procedural textures as well, perhaps?) would be a good thing. - Rainwarrior 09:49, 1 August 2006 (UTC)

Complaint from to 68.4.22.65 to MaxDZ8

MaxDZ8: You shouldn't have reverted my changes but I'm going to just let it be. I think the way you are approaching this topic in completely the wrong way and that is why it is confusing for people. You are jumping straight into real time shaders and getting very specific. Most of what you have written doesn't really belong in this article at all. The topic is shaders, this article should be more generalized. A better example would be the definitions expressed in the Renderman Companion or Programming Mental Ray, not what is here. Read the comments of these people. They are not looking for a detailed description of the mechanics of real time rendering. The paragraph and definitions I wrote were an attempt to sort out what you had said so beginners could understand. Right now it doesn't work. My two cents. —The preceding unsigned comment was added by 68.4.22.65 (talk • contribs) 00:04, 2 August 2006 (UTC)

Sorry for this intrusion, I have compared your revision. In my humble opinion, your definition is also doesn't work and need to be formalized. When I read your revision, your definition tell us about real time shader, not a generalized way. If you refer to Renderman Companion or Programming Mental Ray, in my humble opinion too, it only tells us about production shader. Anyway, be careful of using words like: "Most of what you have written doesn't really belong in this article at all." Those kind of words can easily stage a flame war. Your intention may be good, but really be careful of using "doesn't really belong in this article at all". You may need to add something like "I value your writing, however ..." or "In my humble opinion, ....".Draconins 09:44, 2 August 2006 (UTC)

Not saying your words aren't valueable, but they seem like a sub topic or different topic; Something that belongs on it's own article and linked from the Shader page. So in that sense they don't belong. But they would make a great addition under a different heading, In my humble opinion. Shader is such a loose term and it's causing a lot of confusion, obviously. -68.4.22.65

Okay, your comment is much better now (^^). Furthermore, now I know better what you mean. Correct me if I am wrong, you want several definitions/overviews on different shaders with their own subtitle/section plus their own page. If so, I agree that several concept must be explained separately (such as Pixel Shader and Vertex Shader Differences, which are sometimes hard to be understood by beginners), MaxDZ8 is actually working on this matter, check the page's history. However, since the material on each matters to small, for me, it is okay to include everything on this page until detailed information exist. Or may be any other comment? Draconins 14:16, 3 August 2006 (UTC)

The main problems are Grammatical, not Technical

Hello I don't wish to be offensive, this is purely a technical observation. Your understanding of the subject matter appears to be excellent. However, your writing/explanatory abilities, if I may be so arrogant as to say so, seem to need quite a bit of work.

I would _strongly_ recommend that you sit down with somebody who is good at writing technical documents, especially in English (I suspect English is not your first language or am I wrong?), and clean up the phraseology. All the information is in there, its just that this is a dense field and requires particularly clear language to explain.

Best Regards

Thank you, I understand this is really the issue. I'll try to improve on that ().

Can someone help me here?

MaxDZ8 talk 08:35, 31 August 2006 (UTC)

Shader example

Since today I needed to retrieve a bunch of files from a filtered server which allowed only 1 at once I had put some time on a companion shader article about parallax occlusion mapping which is here. The basic idea is to use it as some sort of "external example". It's work in progress, this has been posted to let you know you're being listened. MaxDZ8 talk 09:36, 1 September 2006 (UTC)