Home » Community » Forums » Graphics Programming and Theory » Shader Engine Design Decisions
  Intel sponsors gamedev.net search:   
[Control Panel] [Register] [Bookmarks] [Who's Online] [Active Topics] [Stats] [FAQ] [Search]

Add Forum to Favorites |  Send Topic To a Friend | View Forum FAQ | Track this topic


 Last Thread Next Thread 
 Shader Engine Design Decisions
Post New Topic  Post Reply 
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

 User Rating: 1039   |  Rate This User  Send Private MessageView Profile Report this Post to a Moderator | Link

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



 User Rating: 1737   |  Rate This User  Send Private MessageView ProfileView JournalView GD Showcase Entries Report this Post to a Moderator | Link

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.

 User Rating: 1053   |  Rate This User  Send Private MessageView Profile Report this Post to a Moderator | Link

Quote:
Original post by MumbleFuzz
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.


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)]

 User Rating: 1828   |  Rate This User  Send Private MessageView ProfileView JournalView GD Showcase Entries Report this Post to a Moderator | Link

Quote:
Original post by Emmanuel Deloget
Quote:
Original post by MumbleFuzz
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.


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,


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.

 User Rating: 1053   |  Rate This User  Send Private MessageView Profile Report this Post to a Moderator | Link

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


 User Rating: 1069   |  Rate This User  Send Private MessageView Profile Report this Post to a Moderator | Link

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 ;)


 User Rating: 909   |  Rate This User  Send Private MessageView Profile Report this Post to a Moderator | Link

Quote:
Original post by Talria
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.


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

 User Rating: 1039   |  Rate This User  Send Private MessageView Profile Report this Post to a Moderator | Link

Quote:
Original post by David Hart
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.

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.


 User Rating: 909   |  Rate This User  Send Private MessageView Profile Report this Post to a Moderator | Link

All times are ET (US)

Post Reply
 Last Thread Next Thread 
Forum Rules:
You may not post new threads
You may post replies
You may not edit your posts
You may not use HTML in your posts
Jump To:
Administrative Options: