Jump to content
  • Advertisement
Sign in to follow this  
LargeJ

How to include your own shaders in material descriptions

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

Hello all,
I am writing my own rendering engine and I am doubting about how to handle materials. From what I know is that each material contains parameters on how to render a surface (including the shader to use). Up to now I use *.obj files to store and load the meshes. These files have a linked *.mtl file, but only include ambient, diffuse, specular, etc kind of shading methods. I can write some basic shaders producing these effects, but if I want to write my own specific shader. Is there an appropriate way to link this custom shader with its own specific parameters to the material description?

Just manually editing the *.mtl files sounds awkward, because you ignore the general *.mtl format.
Are there specific file formats in which the shader to use and the parameter values can all be set? Or do you create your own file format for the meshes in which you can specify all the information you need, including the parameters for the shader?

Jeffrey

Share this post


Link to post
Share on other sites
Advertisement
What i have done in my engine is i create my models in 3d max. i then export them to OpenCollada format. I then use my go between application to read the OpenCollada file, extract the information i need and using that information i am able to create my custom mesh file format ( where i either directly link to a material file, or i leave it open ended ).

the second part of the asset importing is with the information from the openCollada file, i can create my material file which is just really an xml file with the name of teh shaders that i want to use, and the parameters needed.

example might look this

<technique>diffuseNormalGloss</technique>
<parameters>
<parameter name="shininess" >0.1</parameter>
</parameters>
<samplers>
<sampler name="diffuse" >Diffuse_d.png</sampler>
<sampler name="normal" >Normal_n.png</sampler>
<sampler name="gloss" >Gloss_g.png</sampler>
</samplers>

then inside the engine, when i load in the model, if ithe material is linked, my material loader will parse thru that material ( xml ) file, and will set up a materialInstance of the diffuseNormalGloss technique.

since the parameters of this material don't change dynamically, i can create it once, and not have to update the buffers of it, and just apply.

this is a very simple setup, but it can be very creative, as the number and paramters you want to use are limitless ( within reason ). also, setting them up inside an xml file ( external file ), allows you to tweak the materials, without having to rebuild or recompile anything.

hope this helps

Share this post


Link to post
Share on other sites

On obj+mtl syntax.

I strongly suggest to ignore those details. MTL is hardly useful nowadays.
Just import materials as strings. A normal program supporting OBJ will resolve those strings against the MTL file.
Instead of resolving to MTL, use a custom resolution. I currently have a filter associating those strings to "engine materials" which are themselves a set of (shader pipeline + parameters for each stage + engine metadata).
So far, this has proven to be very flexible.
Switching to Collada won't solve the problem AFAIK.

On shader storage.

I suggest against storing shader code (in some form) in assets directly. In my experience, this recalls me of fairly complex inter-correlations between different subsystems I really wanted to keep separated. I think keeping the shaders as stand-alone resources (outside the asset) is more manageable.
However, you are correct in speculating some shader information (beside the shader code resource ID) must be stored in assets. In my case, that is the parameter blob for each stage. For me the parameter blob is a fairly complicated thing but yours does not have to! At its core one just needs to work with uniforms such as

  1. Specify where to put MVP/another matrix/some engine specific value
  2. Specify some constant such as a color modulation or a displacement amplitude multiplier.
  3. Set textures

Then there are the not-quite-shader things such as blending set up, ROPs, stream port settings. All of which are somewhat related to the shader.
As for varyings... I had very limited uses for "parametrized varying input" as I call it, mostly related to animation. I'd say it's not currently going to be required, your mileage might vary.

Share this post


Link to post
Share on other sites
Thanks for the replies. I will try to adjust my design by taking into account these insights. Apparently, I'm not even halfway there. Having a decent design is a pain in the ass.

Share this post


Link to post
Share on other sites
@Krohm
I'm trying to understand both suggestions and at the moment I'm as far as NiteLordz proposed. I don't really understand what the big difference/drawback is compared with your approach? Especially what you mean with the parameter blob.

And as another question. I now use mesh files in which submeshes refer to named materials. Each named material has a corresponding callback object so that it is able to do some initialization and contains the code to update the uniform parameters of the shader, etc. These material names/classes should be known by the system in order to instantiate the correct callback object. I can create a plugin system or manually register all callback objects. From a book I have, plugins can be implemented by dynamic linking (e.g. dll files, however this does not sound familiar/convenient from what I see in other rendering engines). And manually registering all callback objects can be useful, but sounds cumbersome too.
So what is the most common way of handling this kind of problem?

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!