Jump to content
  • Advertisement
Sign in to follow this  
brekehan

Organizing Shaders - Shader Manager?

This topic is 3808 days old which is more than the 365 day threshold we allow for new replies. Please post a new topic.

If you intended to correct an error in the post then please contact us.

Recommended Posts

Going through the first few tutorials on MSDN while I update my DX engine from 9 to 10. It would seem that almost any class I create that would be rendered is going to need its own vs and ps depending on the information that is part of its vertices. For instance BasicObject2D position default white color simply needs vs and ps to use supplied vertices and color white BasicObject3D position color needs vs and ps that use supplied position, multiply by matrices, and use supplied color. And of course, if I want to be flexible, I should allow a client of my lib to supply his or her own shaders for each object while documenting constraints. This makes me think that I should probably make some kind of shader manager, where vs and ps can be obtained by a string name and provided to the different objects. the manager could be responsible for compiling them at load time and selecting proper versions, etc. Do you forum users think this is a needed component? Has anyone done anything simular? How do you handle swithing and organizing your various shaders? It has been to long for me to look far into the future on more complicated things. P.S. This is native C++ code, no XNA advice please.

Share this post


Link to post
Share on other sites
Advertisement
Quote:
Original post by brekehan
Has anyone done anything simular?
Unluckly, I did. Since the result is still pretty weak and probably will always be, I could say I'm still doing it.
Quote:
Original post by brekehan
This makes me think that I should probably make some kind of shader manager, where vs and ps can be obtained by a string name and provided to the different objects. the manager could be responsible for compiling them at load time and selecting proper versions, etc.
If you stick to D3D10 you'll probably have an easier life than me. I had to think in a cross platform way at the time so it turned out a massively difficult task.

What I had to do was more or less to go for an overhauled FX framework.
Do yourself a favor: make sure if you can fit in the FX framework. It's quite powerful and ready to go. Unluckly, I couldn't.

At the end, I had to wrote a subsystem which enumerated "source code objects". Another independent subsystem then processed those object to extract function objects which were mangled to produce the HLSL code - that means that matching a vertex or pixel shader actually required to match a package, a function name and a function syntax (overloading is supported).
As said, just living whith FX shortcircuits a few steps but depending on how much complex your idea is, this may or may not work.

Quote:
Original post by brekehan
Do you forum users think this is a needed component?
Evidence suggests it's not strictly need in all cases. Most games I've seen simply go to load an HLSL blob and generate their shaders with far less hassle...
Quote:
Original post by brekehan
And of course, if I want to be flexible, I should allow a client of my lib to supply his or her own shaders for each object while documenting constraints.
...this is THE problem. In fourth-gen 3d pipes, you cannot really assume something about shaders and thus vertices. Problem's complexity will rise dramatically as you fight for more and more flexibility. Try to make some examples on how much flexibility you need/want to expose.

Share this post


Link to post
Share on other sites
There is definitely scope for utilizing a library/component along the lines you've described.

The big thing I would draw your attention to is the complexity involved. Initially it may not seem like such a huge task, but before long it gets bigger and bigger. You realise that you need to abstract out and manage more and more parts of your pipeline etc...etc... and you easily create yourself a huge amount of work.

Before you go down this path, carefully consider how much of this management you really need and the associated effort involved in developing it. Be sure to define the scope up-front and in black-and-white: feature-creep is a dangerous enemy here [wink]

Also, do some research into the tools and processes you want to support via this approach - its very easy to try and rewrite your own form of FX framework and eventually hit against the problem that you then have to create tools to work with your chosen format and/or write conversions from common/standard formats to your closed one. If you can re-use standards and conform with existing tools and pipelines then you could save yourself a lot of effort.

In my case, a thin layer across FX10 has been plenty sufficient enough. Something that gets rid of a lot of repeated code and does an extra amount of sanity/error checking. YMMV.

hth
Jack

Share this post


Link to post
Share on other sites
Sign in to follow this  

  • Advertisement
×

Important Information

By using GameDev.net, you agree to our community Guidelines, Terms of Use, and Privacy Policy.

GameDev.net is your game development community. Create an account for your GameDev Portfolio and participate in the largest developer community in the games industry.

Sign me up!