Shader System Questions

cyansoft · 2004-05-22T05:10:47

Like many, I''ve been reading and rereading (and re-rereading) the famous "Materials and Shaders Implementation" thread, where the great Yann L. describes his engine''s pluggable effect/shader system. I think I''m starting to understand how the system works. But in the process of designing my own shader system, I came up with many questions that were never addressed in the original thread, are needed to provide more insight and ideas, or I''ve mistakenly overlooked because of the shear amount of discussion over this topic. 1) In Yann''s implementation, the actual shader class does not contain any render method. He says that the rendering occurs outside of the shader. I thought that the purpose of the shader is to implement all or part of an effect. Why keep the API specific rendering calls (i.e. glDrawElements) outside of the shader? What are the advantages/disadvantages of having the shader render the GC verses having the GC render itself? 2) For those whom implemented a shader system (or in the process of implementation), do you have every possible renderable object consist of GC''s that are piped into the renderer? Such objects include the HUD, the in-game GUI, the command console, and particle systems. What''s the advantages and disadvantages of having *everything* renderable go through renderer system? 3) If you were supporting multiple API''s/hardware (i.e. OpenGL, DX9, PS2, Game Cube, etc.), I would assume you would create a different set of shaders for each API, while carefully loading the correct set of shaders for the target API/hardware. This comes back to the first question, why keep the API specifics for rendering outside the shader? 4) When resolving the best shader for an effect based on the hardware capabilities and the user quality preferences, I assume when a GC is loaded from disk, it can ignore loading vertex stream data it does not need. For example, if bump mapping is not supported, then the tangents do not need to be in the vertex stream. 5) For those whom implemented effects, what kind of effects did you come up with and how did the implementation work out? What absolute minimum effects should a system provide? Here are the very basics others have mentioned in other threads: a) Diffused Texture .vertexstreamdata XYZ | UV(diffused) .gcdata TextureID(diffused) b) Lightmapped Diffused Texture .vertexstreamdata XYZ | UV(diffused) | UV(lightmap) .gcdata TextureID(diffused) | TextureID(lightmap) c) Gouraud Shaded .vertexstreamdata XYZ | RGBA | NxNyNz .gcdata LightID 6) How liberal are you about making a whole new effect verses adding an additional parameter to an effect? What’s your criterion in deciding? For example, say you want to render some geometry in wire frame mode. Would you create a new effect for this or add an additional parameter to an existing effect? 7) How do you provide parameters and vertex stream data to the shader via shader_params? Do you pass an object with methods to return pointers to the param data in the GC? Or do you store a single buffer in the GC, with the params and vertex stream data in a predefined order based on the required format for the effect? What are the advantages and disadvantages to each method? 8) How do you store your vertex data stream and the parameters in the GC? Do you use a single buffer as discussed in question 7, or do you use a specific GC class that''s inherited from a base GC, to be used by specific effect? 9) If you store your vertex data stream outside of the GC, in a buffer (i.e. OpenGL''s VAR/VBO/Vertex Array or DX9''s VB) do you have one buffer per GC (seams very inefficient), one per shader, one for the entire scene, or multiples buffers for optimized performance (I believe Yann once said that 1000 to 4000 triangles per buffer is the most optimal)? If you do use multiple buffers, how do you minimize switching buffers? 10) For level of detail purposes, imposters may need to be created. How would you design an effect to render a bunch of GC''s to a texture, in a preprocess pass, then render the generated texture on a quad in the main pass? Would this be as simple as passing a list of GC''s as a parameter for the effect? 11) How do you resolve using multiple shaders for multi-pass rendering? More specifically, how does the shader tell the GC it can only do part of the effect? And more importantly, how does the shader know it can only do part of the effect? Yann didn''t go into details on how the whole messaging system would work. Any ideas on how to implement this in a clean and efficient manner? 12) Besides the obvious SPGC sorting criteria such as render target, render pass, shader, texture(s), and depth from camera(transparent pass only), what other factors/state changes should be looked at and sorted by? 13) How can a shader be implemented to take advantage of OpenGL''s display lists? For obvious performance/memory usage reasons, display lists are perfect for static geometry that is repeated dozens or more times per frame. Compiling and executing a display cannot happen every frame, since compilation would outweigh any speed benefit. Wow! That was a lot of questions. I look forward in reading what others have done and to what suggestions they have for implementing such a complex system. Bob

Graphics and GPU Programming Programming

Started by cyansoft April 04, 2004 01:22 PM

113 comments, last by cyansoft 19 years, 11 months ago

Anonymous

May 21, 2004 08:34 AM

Hey!
After reading all the various threads relating to the implementation of a dll based shader system I decided to give it a go.
Ive made a test shader in a dll but im having trouble getting it to work (this is the the first time ive used dll''s)...
Ive created an abstract base class which the dll instanciates, the base class has some tools ala the design proposed in this and the other thread.

Basically, im having trouble figuring out a way of keeping the dll small... I can make it all work if i link in all the main engine stuff, but this is not desirable. Is there a way to access the engine states/etc from the dll without including it all in the dll?

python_regious

929

May 21, 2004 09:01 AM

Load the dll at runtime, that way you don''t have to link with the lib. This''ll decrease the build size by quite a margin.

You have to remember that you''re unique, just like everybody else.

If at first you don't succeed, redefine success.

Anonymous

May 21, 2004 09:17 AM

i do load it at runtime...
I''m having the trouble when compiling the dll. I''m always getting linking errors. e.g when i call one of the tool functions...which say, subsequently calls the renderer or something.. it gives errors because its trying to link into the renderer through the tools and its not there. I just cant think of how to seperate this!

Anonymous

May 21, 2004 10:06 AM

btw..sorry about the anonymous stuff, i cant seem to create an account, i dont receive the email!!

coelurus

259

May 22, 2004 05:10 AM

Pass an interface class of the main engine to all DLLs. If you use class-pointers all over the place, then you won''t have to link in anything.

Shader System Questions

This topic is closed to new replies.

Popular Topics

Recommended Tutorials

Shader System Questions

This topic is closed to new replies.

Popular Topics

Recommended Tutorials

Reticulating splines