Jump to content
  • Advertisement
Sign in to follow this  
zoiq

Creating a flexible material system.

This topic is 4562 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

I've been thinking about a way to flexibly approach material rendering. My thinking was that the application concept of a Material specifies which textures to use in conjuction with which pixel and vertex shaders (and other specifics, such as what type of inputs are required). The main problem with this concept, is that there are quite a few portions of the application which need to contain type information relating specifically to what goes into the vertex shader (and hence the pixel shader). As far as i can tell these are: In the vertex shader: The VS_INPUT and VS_OUTPUT structures. In the pixel shader: The PS_INPUT (which is the same as VS_OUTPUT) structure In application code: A struct matching the VS_INPUT as well as a matching VertexFormats definition for VertexBuffer creation A VertexDeclaration object, created from a matching VertexElement array (assuming that the material also defines the streams and offsets that each data element should occupy) Largely these are all the same information which each different area requires a definition for. I can think of several approaches, none of which feels entirely comfortable (such as code generation at compile time) to minimise the work in adding a new material. My goal is such that no application code need be written to add a new material, only shader code as necessary. Ideally, this means that no compile time code is generated. I'm interested to hear how other people have approached this problem or what solutions they might consider. thanks,

Share this post


Link to post
Share on other sites
Advertisement
this recent thread might be of interest.

If you use an effects-framework based approach (or similar) then the majority of the shader implementation can be kept data-driven. Thus you change your application to being nothing more than a "linker" between internal (or otherwise loaded) data and the effect used to render.

Using DXSAS and general FX-file reflection you can gain a lot of knowledge about the inputs required without actually know what the material looks like or how its computed...

The trick I've used is to have an additional file (XML in my case) that links geometry, textures, parameters and effects together - maybe not explicitly, possibly via aliases (e.g. a "CheapPlastic" material might resolve down to "Plastics.fx->BlinnPhongTechnique"). I then examine all of the pieces and see if they fit together - if they fit together, great. Otherwise you try to auto-generate missing data and fail if thats not possible.

If you draw a diagram on paper of what inputs are available (even just generically, "texture"), what might be required, who owns them - generated internally, loaded externally... it might become clearer...

Here's one I made earlier:


hth
Jack

Share this post


Link to post
Share on other sites
Thanks for the reply.
I've had a look through the DXSAS reference i found on MSDN, and while the semantics seem useful I interpret what i read there to be a method for binding application variables to the related shader variables.

What I am looking for is a way for a configuration file to specify shader or effect files and associated resources and once these have been loaded to have all the per frame application code related to creating the related vertex buffers (of the correct vertex formats) and binding stream sources work generically.

Does anyone else have input on this topic?
Is this considered a solved problem?

Share this post


Link to post
Share on other sites
Quote:
Original post by zoiq
What I am looking for is a way for a configuration file to specify shader or effect files and associated resources and once these have been loaded to have all the per frame application code related to creating the related vertex buffers (of the correct vertex formats) and binding stream sources work generically.

Do you mean kind of like a manifest that specifies everything about a certain object? Things like:

- Mesh filename
- Effect filename
- Some effect parameters
- Animations
- Special directories

If this is what you want, just throw it all in a text file in the format of your choice, and parse it at runtime. If this isn't what you were thinking of, please explain further.

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.

We are the game development community.

Whether you are an indie, hobbyist, AAA developer, or just trying to learn, GameDev.net is the place for you to learn, share, and connect with the games industry. Learn more About Us or sign up!

Sign me up!