Continued on GLSL, one of the problems with GLSL, if we treat it as anything more than an engine building block, is that it provides too much raw control. This leads to shaders making assumptions about the outside world. For example, if we write a GLSL shader right now completely independent of any specific engine, we would normally have to assume *inside the shader* how many lights there are in the scene, and what type they are. We would also have to assume how the lighting computation is done for each light source. So we might write a shader which assumes that there is one point light directly above the model. Thats hardly general or useful, its going to shade things like theres one point light even if we have a scene with a dozen lights. Its going to be ignoring whats inside the scene, its going to be ignoring the outside world. Now we can alleviate this somewhat by describing uniform attributes for the shader, and requiring the engine using the shader to pass in lighting information from the scene. This immediately makes the shader engine-dependent, and that would not require any kind of code generation mechanism. However, the shader would still be assuming how the light computation is done for each type of light. All shaders would be assuming this, so if we come up with an improved way to compute point lights in the future with phong shading or come up with an efficient realtime way to support area lights, for example, we would have to go back and rewrite every single shaders lighting code weve written so far by hand to make them all match. This would be a real nightmare, even if its just copying and pasting the same code everywhere and asking third parties to do the same. So the shading pipeline Im working on seeks to take the control out of the shaders hands for these things, instead providing them built-in functions native to my engine like light() which returns the direct light computation for a fragment. The code for such functions are generated on the fly, and regenerated as we add/remove/change lights in my softwares scene. This still leaves the shader to allow it to decide what to do with the amount of light its receiving when it calls the light() function. It still has full control over how it behaves as a material. But now its a shader that *responds* to the outside world, not a shader *ignoring* the outside world. Anyway, this is what Im working on now. It basically means people writing GLSL code for my engine will have an additional set of auxiliary functions they can and should call to get information about the outside world.
Posted on: Wed, 31 Dec 2014 21:10:08 +0000
Trending Topics
Recently Viewed Topics
© 2015