Jump to content
  • Advertisement
Sign in to follow this  
CDProp

How does your renderer handle different materials?

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

This may be more of a code design question, but it's so heavily dependent on DirectX, that I think this is a better place for it. I am writing a RenderList class. It's pretty simple. It just holds a list of Mesh objects to be rendered (my own Mesh class, not the D3DX one), a method to add a new Mesh to the list, a method to sort the list (primarily by material, secondarily by texture), a method to clear the list, and a method to Render the list. The Mesh class has three main components: Transform, Geometry, and Material. The purpose of the Material is to hold all of the properties like specularity, UV offsets, which textures to use, etc. It also holds a reference to the Effect that renders the Mesh. I plan on having many different material types, e.g. 'Leather', 'Stone', etc., in my game. There will be one Effect per material type, and so obviously there will be several objects that will use each type, but each Mesh still needs its own unique Material object because each object may use different textures, or have different values for specularity and specular sharpness, and that sort of thing. The problem is that my RenderList class is going to need to be responsible (as far as I can tell) for setting all of the effect parameters, however I want the user of my RenderList class to be able to create his or her own Effects and Material types. So, my first idea was to create an abstract Material class that holds nothing but a reference to an Effect. That way, I have a 'placeholder' Material class that my Mesh and RenderList classes can use, but thanks to polymorphism, the user of my RenderList class can derive their own Material types, adding things like Specularity and Textures where necessary. The base Material class would contain a pure virtual SetEffectParameters() method that they must override. And if they choose, they could give their derived class a static instance of itself to be used as a sort of cache, so that they can keep track of the paramaters for the last object rendered with that Effect, and the SetEffectParameters() method can be designed to only set those parameters that are different. I love this idea for the most part, but the one glaring thing I hate about it is that I have to use pointers. What I mean is, my Mesh class can no longer contain a Material, it has to contain a Material*, because Material is an abstract class, and even though I can make it non-abstract with empty methods, I don't really want to, because I must be able to have Mesh::m_Material dynamically bound to a derived type. So I'm just picturing this from the perspective of the user who, whenever they want to create a new Mesh, they must provide a reference to a separate Material that is guaranteed to persist throughout the life of the Mesh, which sounds like a major pain in the ass. I would much rather just have a Material object as part of Mesh's composition, so that users can just pass in a temp Material object to Mesh's constructor or something, but with this method, I can't do that. I was wondering if anyone who has had the patience to read all of this might have a better system that they use, which they could describe to me. I was thinking of maybe creating a single master Material class, with everything a use could possibly need in it, as well as a bit field that the user can use to specify which fields are actually used, along with a function pointer so that the user can create a custom function for setting the effect parameters. I could write my own function, perhaps as a method of RenderList, to set the Effect parameters, but doing so would compel users of my class use specific names for their Effect parameters when they're writing their Effects, which is undesirable.

Share this post


Link to post
Share on other sites
Advertisement
You can look at what I did in this post:

http://www.gamedev.net/community/forums/topic.asp?topic_id=522072

Examining the effect and material headers should make it clear.

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!