|
||||||||||||||||||
Add Forum to Favorites | Send Topic To a Friend | View Forum FAQ | Track this topic |
Last Thread Next Thread ![]() |
| Shader Engine Design Decisions |
|
![]() David Hart Member since: 10/20/2005 From: Angouleme, France |
||||
|
|
||||
| I am coding a 3DEngine in Managed DirectX with C#. I am about to implement the Material and Shader systems, and found myself in front of a difficult design decision: should I create a fixed list of shaders, making a simplier Material system, and making the artist work easier, OR should I allow users to create their own shaders, making the Material system more complicated, overcoming the fact that different shaders may need completely different variables set-up? What is excpected of an Engine nowadays? Do you know of any resources on that web that discuss such problems? Thx in advance. -------------------------------- David Hart |
||||
|
||||
![]() Dave Member since: 3/22/2004 From: London, United Kingdom |
||||
|
|
||||
| Hi, Shader Systems -------------- I had this same problem not long ago. I don't know about you but i decided that having custom shaders is a big plus and i was also making the user of my scene renderer able to script new shaders into the engine. What i did was had part of my shader script contain descriptions of the variables that are to be passed to the shader, like: mat4x4( D3DWORLDVIEWPROJ, "matWorldViewProj" ); So the second part is the name that the shader expects and that should be set when calling effect->SetMatrix(). Another example float3( 0,2,54, "label" ); This makes the engine much more flexible. Another idea is that you simply suply some examples along with your engine. Hope that helps and that you understand. ace |
||||
|
||||
![]() MumbleFuzz Member since: 3/18/2004 From: Oxford, United Kingdom |
||||
|
|
||||
| Have a look at this thread. It discusses at length the practicalities of writing a flexible DLL based material system, and, even if it seems a convoluted approach, will probably give you some ideas. This more recent thread raised a lot of related questions. Personally speaking, I'd like to avoid using a DLL system. I feel that shaders and materials ought to remain resources (and thus more easily modifiable, perhaps in a visual environment), not binary code. But in any case, those threads should give you some idea of what a modern engine may strive for. |
||||
|
||||
![]() Emmanuel Deloget GDNet News Lead Member since: 8/27/2003 From: France |
||||
|
|
||||
Quote: One of your DLL can simply load your external resource file and apply it, if you want :) The DLL idea described by Yann L in this thread is great, because it is very flexible and because it also allow you to easily implement fallbacks. But I agree that it can be complex to implement - and most of the time, if you use DX, the effect files can do the same job. Regards, -- Emmanuel D. [blog, in French] [blog, very bad googlized translation] [NEW: English version of teh blog! (WIP)] |
||||
|
||||
![]() MumbleFuzz Member since: 3/18/2004 From: Oxford, United Kingdom |
||||
|
|
||||
Quote: Well it's been a while since I read the whole thread, so I should really do that before I comment further . But - while it's certainly flexible - Yann himself points out that it "doesn't really allow for [easy] rapid prototyping and visual shader development". That's my main reason for wanting to try a different approach.Incidentally, has anyone used a metaprogramming language such as Sh? It looks like it would be significantly easier to use than most conventional shading languages. |
||||
|
||||
![]() Arex Member since: 7/1/2004 From: Helsinki, Finland |
||||
|
|
||||
| I'll describe something about my effect system : First of all the classes : --------------------------- Effect Pass Material Shader TextureLayers Texture Here is a example how I use it (it's kind complicated and very big, containing hundreds of functions) : E = CreateEffect("cool effect") // pass 0 E->CreatePass() E->CreateMaterial() // now create material E->GetCurrentMaterial()->CreateShader(... E->GetCurrentMaterial()->AddTextureLayer(... E->GetCurrentMaterial()->SetDiffuse(... // and so on // setup all render states, etc. for this pass E->AddRenderState(... E->AddPass() // next pass.. E->CreatePass().. That is the main idea of it, but of course for example, texturelayers (textures), shaders, materials, etc. can be created in other places and then can be just added to the pass (there are functions to do this), so it's pretty dynamic, and you don't need to create same materials, shaders, etc. many times, just pass the pointers to same kind of effects or do copy. :) For example when material was created elsewhere : E->CreatePass(MyMaterial) I'v found this to be very useful, anyway if you got more questions about it feel free to contact me or post here. :) Sincerely, Arto Ruotsalainen Dawn Bringer 3D - Tips & Tricks |
||||
|
||||
![]() Talria Member since: 10/31/2005 From: Chiputa, Zambia |
||||
|
|
||||
| It's not worth the trouble to have complex material system in practice. If you have simply a set of materials with some fixed set of exposed properties (e.g. diffuse/normal texture, etc.) which you link to proper vertex/pixel shaders in C++, it'll be enough 99.9% of the time and much more flexible and efficient. For example Unreal Engine 3 type of shader graph is total overkill in practice and more like a "me too!"-feature ;) |
||||
|
||||
![]() David Hart Member since: 10/20/2005 From: Angouleme, France |
||||
|
|
||||
Quote: I don't really agree. If you are coding a game, with specific needs in terms of shaders, your solution is more than acceptable. But as I am coding an engine, extensibility and flexibility are the key words. If I only do a hardcoded material that only accepts a finite set of variables (diffuse, normal, etc...), as soon as someone needs something "slightly" different, the amount of code needed to make it possible will be horrible. And the code itself will become ugly and hard to maintain. If I succeed in implementing a flexible design, adding shaders will be as easy as adding textures and will be done from the editor, without ever having to edit the base engine code. -------------------------------- David Hart |
||||
|
||||
![]() Talria Member since: 10/31/2005 From: Chiputa, Zambia |
||||
|
|
||||
Quote: But that engine is ment to be used to code a game, right? If you provide a simple way to create new shaders (I have done it, so I know it's possible) it's more extendable and flexible than any shader parser/graph can ever be. There wont be horrible amount of code to write, maintenance issues nor will you have to edit the base engine code, if there has been any kind of sense in the way the shader system has been designed. What you need is just a simple abstract base class which you implement for different shaders. |
||||
|
||||
All times are ET (US)![]() |
Last Thread Next Thread ![]() |
|