Pixel/Vertex Shaders & Engine Design
Author
Hi, I'm just working on integrating HLSL shaders into my 3D Engine, and I'd like to know how other people handle them. I am used to using the Fixed Function pipeline and I'm very new to shaders. I understand how the shaders work and I've implimented a very simple one that can draw textured objects.
Do people generaly have a seperate shader program for each object/model they draw? Or do you have one shader that does everything. Where would you advise placing the shader code, inside the modelling class or in some main drawing area of the engine. i.e. should each model be totally self contained with its own shaders and drawing code or should the shaders be handled somewhere else that each model calls..
Just looking for some general design hints before I start getting in too deep.
Thanks,
Chris
You might want to check out this thread: clicky
It's how YannL has his system setup (and probably by now a few others as well, myself one of them).
Etnu: Normal HTML anchor tags should be used for links.
[Edited by - Etnu on August 26, 2004 9:38:02 PM]
It's how YannL has his system setup (and probably by now a few others as well, myself one of them).
Etnu: Normal HTML anchor tags should be used for links.
[Edited by - Etnu on August 26, 2004 9:38:02 PM]
I've glanced at YannL's thread a few times and it sounds great. I'll probably endup doing something like that eventually. I'm using a material based system currently. The materials are exported into a file along with the geometry data aswell. While each material is loaded, the loading function checks whether certian material properties are present (eg: diffuse, mask, bump) and loads the approprite fragment shader. (currently I only use one vertex shader) The result of this is that I must have a large number of different fragment shaders to allow for different possibilities.
I havn't started batching by material so my current rendering setup goes like this:
-get an object to render
-draw that objects material
-bind that material's vertex and fragment shaders
-bind that material's texture maps to approprite channles
-draw the objects polygons
-next object..
I havn't started batching by material so my current rendering setup goes like this:
-get an object to render
-draw that objects material
-bind that material's vertex and fragment shaders
-bind that material's texture maps to approprite channles
-draw the objects polygons
-next object..
Author
Thanks for your replies, i think that thread is over my head, I'm just starting with shaders so I guess i'd better try something simple to start. What are fragment shaders?
Quote:Original post by cpcollis
What are fragment shaders?
fragment shaders, or fragment programs, are just different names for a pixel shader.
Etnu: thanks.
cpcollis: Just a small note; that system can also easily be used with fixed function graphics. I currently do that as well, since I'm also just starting to get into shaders, and there is still a lot of stuff I can do with fixed function. A shader in that thread is just how the surface should be replicated. This can often be done with fixed function as well.
cpcollis: Just a small note; that system can also easily be used with fixed function graphics. I currently do that as well, since I'm also just starting to get into shaders, and there is still a lot of stuff I can do with fixed function. A shader in that thread is just how the surface should be replicated. This can often be done with fixed function as well.
Quote:
Do people generaly have a seperate shader program for each object/model they draw? Or do you have one shader that does everything. Where would you advise placing the shader code, inside the modelling class or in some main drawing area of the engine. i.e. should each model be totally self contained with its own shaders and drawing code or should the shaders be handled somewhere else that each model calls..
Just looking for some general design hints before I start getting in too deep.
Thanks,
Chris
Assuming no sophisiticated post processing techniques, a game engine typically will compute the dynamic lighting conditions of a given scene, for each object select the appropriote shader (from a family of shaders) for that set of lights/conditions, sort the objects based on the shaders they use, then draw the objects, changing the shaders the minimum number of times.
Make a totally atomic graphics system where each object knows how to draw itself, while being a clean implementation, does not perform well. Typically, engines utilize some kind of dynamic scene graph - paying careful attention to not spend too much time creating/managing it. This does mean that whatever object rendering the scene has to know a great deal about the objects it is rendering.
Author
EvilDecl81 I've been meaning to impliment something like this but wasn't sure how to go about it. I've come up with a rough idea which if you have the time I'd like your feedback on. What I have is a structure which holds a lot of info like:
Theres perhaps a few other identifies to say how the data should be used. Each model/object/thing to be drawn sends one of these structures to the engine. The engine stores an array of these structures but doesn't draw them immediatly. Once all objects have sent their structures and say the "EndScene()" function gets called, the engine sorts the structs by effect, then by texture and then draws them out to the device. Is this the sort of thing you are suggesting? Any holes you can see with this approach, or a better suggestion is very welcome :)
Thanks,
Chris
public struct DrawingObject{ public PrimitiveType PrimitiveType; public VertexBuffer VertexBuffer; public IndexBuffer IndexBuffer; public int EffectID; public int BaseVertex; public int MinVertexIndex; public int NumVerticies; public int StartIndex; public int PrimitiveCount; public Matrix World;}Theres perhaps a few other identifies to say how the data should be used. Each model/object/thing to be drawn sends one of these structures to the engine. The engine stores an array of these structures but doesn't draw them immediatly. Once all objects have sent their structures and say the "EndScene()" function gets called, the engine sorts the structs by effect, then by texture and then draws them out to the device. Is this the sort of thing you are suggesting? Any holes you can see with this approach, or a better suggestion is very welcome :)
Thanks,
Chris
Quote:Original post by cpcollis
EvilDecl81 I've been meaning to impliment something like this but wasn't sure how to go about it. I've come up with a rough idea which if you have the time I'd like your feedback on. What I have is a structure which holds a lot of info like:
*** Source Snippet Removed ***
Theres perhaps a few other identifies to say how the data should be used. Each model/object/thing to be drawn sends one of these structures to the engine. The engine stores an array of these structures but doesn't draw them immediatly. Once all objects have sent their structures and say the "EndScene()" function gets called, the engine sorts the structs by effect, then by texture and then draws them out to the device. Is this the sort of thing you are suggesting? Any holes you can see with this approach, or a better suggestion is very welcome :)
Thanks,
Chris
Something like this should work well enough. Don't get to caught up in lots of abstraction layers or too much generality, its the overall concept of having a scene manager that's important.
This become a requirement when you want to start doing things like alpha blending, post-process effects, etc.
This topic is closed to new replies.
Advertisement
Popular Topics
Advertisement
