• entries
732
1562
• views
494807

# Material girl

109 views

I've been enhancing the material system these past couple of days -- I've added GLSL materials, material rendering stacks and other features. I decided it was time to implement a couple of classes to make material management easier.

I went off and implemented a "material cache," which holds onto materials that have been requested recently. The important thing here is that I'm now loading materials -- they're defined in XML, like so...
                "data/shaders/gooch"/>        "9"/>        "data/shaders/pie"/>
Of course, there's little bugs (Include directives don't catch infinite recursion, there's no support for multiple passes of shaders, and it's arguably pretty useless right now without a material stack added), but it's pretty awesome overall and seems to work. I've also added a multitexture material type, but haven't had a chance to test it out yet.

The end result of all this chicanery? It could be the nice new Gooch shader that I added to my little bag of tricks.
The mission of making Novarunner the most pointlessly gorgeous space trading sim ever is starting to get there. Now just to find some models.

Looking nice, Mike. Thanks for heading my naggings to post an entry. [smile]

Looks sweet Rav! I wish I had those bad boys working in my game.

I'm not quite understanding the true power of the material rendering stack and how it relates to things you might otherwise do in the scene graph. Is this like material sorting? Can you give an example of how a rendering stack would work?

If you don't mind me asking, how are you handling shader parameters? Say you have a GLSL shader that takes two UV sets (texture coordinates), how do you specify which mesh data gets bound to each input?

And how about lighting parameters? Have you just defined a standard lighting setup/rig for your game, and every shader is expected to have that parameters which match the lights you've defined (e.g. one point and one directional light or whatever it is)? Or have you worked out a cunning way to support dynamic lighting environments?

Quote:
 Original post by Ravuya The mission of making Novarunner the most pointlessly gorgeous space trading sim ever is starting to get there. Now just to find some models.

I think we might have to get out the chloroform and kidnap us some artists.

Quote:
 I'm not quite understanding the true power of the material rendering stack and how it relates to things you might otherwise do in the scene graph. Is this like material sorting? Can you give an example of how a rendering stack would work?
Ah, it's just a series of 'materials' that get applied and removed. It really has no special power, but the stack lets me keep track of when I've applied and removed them so I get rid of them in the proper order so GL doesn't get cranky.

The nice thing is that the "stack" itself is a material, so anything that supports one material can support a tree of 'em with no extra bother (hence the recursive goodness).

Quote:
 If you don't mind me asking, how are you handling shader parameters? Say you have a GLSL shader that takes two UV sets (texture coordinates), how do you specify which mesh data gets bound to each input?
My material class exposes three functions, textureCoordinate(vec2), passVector(name, vec3) and passScalar(name, float). They all do different things with it -- for example, bump mapping uses the texture coordinate with glMultiTexCoord, and the shader just passes along the vector and scalar to a uniform of that name.

I provide some default vectors and uniforms from each actor when rendering it (position, time).

Quote:
 And how about lighting parameters? Have you just defined a standard lighting setup/rig for your game, and every shader is expected to have that parameters which match the lights you've defined (e.g. one point and one directional light or whatever it is)? Or have you worked out a cunning way to support dynamic lighting environments?
I wish I had figured out something cunning. It's just a static light at (0,0,0) currently. One of my goals is certainly to make this suck less.

Yeah, I've totally bailed on a real solution for lighting in shaders for now too. As I understand it, in GLSL, you can actually access the standard GL lights, so you could write a loop for each defined light and support nearly anything. Unfortunately, there aren't analogous mechanisms in the other languages, so it's a bit of a limited solution.

The most promising thing I was reading about is a generalised light model which allows you to represent any basic light type with a common set of parameters. It adds a few instructions to the shader, but it allows you to write shaders that use any lighting combination.

Still, what you have looks very cool - much nicer than the ugly and combersome fixed function rubbish I'm using.

## Create an account

Register a new account

• ### What is your GameDev Story?

In 2019 we are celebrating 20 years of GameDev.net! Share your GameDev Story with us.