• entries
316
485
• views
324578

# D3D11 with MS3D + D3D11 Programming Tip #1

1290 views

D3D11 with MS3D

I spent some time updating my geometry classes to allow for all of the myriad primitive topologies that are allowed for in D3D11. Its a bit surprising to see, but there are 32 different types of control patch primitives for use with the new tessellation shader stages. I basically allow my index buffer classes to add individual indices and let the application take care of ensuring that there is an appropriate number of indices for a given number of primitives of a given type. One by-product of adding this functionality is that I needed to be able to determine how many primitives are going to be rendered when a user specifies the number of indices and the topology type. Have you ever tried to figure out how to do this with a triangle strip with adjacency? Here's an image to show you what I mean - can you figure out the formula???

It took me a good 15 minutes of thinking about it to get it straight [rolleyes]! Anyhow, after getting my geometry classes straightened out, I ported over my geometry loader. The bottom line is that I can now load in my MilkShape3D files again, letting me render the old standby (do you know who it is?):

D3D11 Programming Tip #1

I'm going to periodically post programming tips that I come across while working with D3D11, and this is going to be the first one. When building a renderer around D3D11, it is pretty commong to create a function that recieves an object description that creates a state of some sort, such as a BlendState, RasterizerState, or DepthStencilState. Typically these descriptions are an actual D3D11 struct, and they can be quite verbose and unsightly to type out. Here is an example of how it would look to do create a DepthStencil state in this manner:

D3D11_DEPTH_STENCIL_DESC State;State.DepthEnable = true;State.DepthWriteMask = D3D11_DEPTH_WRITE_MASK_ALL;State.DepthFunc = D3D11_COMPARISON_LESS;State.StencilEnable = FALSE;State.StencilReadMask = D3D11_DEFAULT_STENCIL_READ_MASK;State.StencilWriteMask = D3D11_DEFAULT_STENCIL_WRITE_MASK;		State.FrontFace.StencilFunc = D3D11_COMPARISON_ALWAYS;State.FrontFace.StencilPassOp = D3D11_STENCIL_OP_KEEP;State.FrontFace.StencilFailOp = D3D11_STENCIL_OP_KEEP;State.FrontFace.StencilDepthFailOp = D3D11_STENCIL_OP_KEEP;	State.BackFace.StencilFunc = D3D11_COMPARISON_NEVER;State.BackFace.StencilPassOp = D3D11_STENCIL_OP_KEEP;State.BackFace.StencilFailOp = D3D11_STENCIL_OP_KEEP;State.BackFace.StencilDepthFailOp = D3D11_STENCIL_OP_KEEP;Renderer.CreateDepthStencilState( State );

This isn't too bad for one or two states, but by the time you get to 5 or 10 it becomes a real mess. Instead, if you create a class to wrap the structure you can take away a couple of nice advantages:

1. The constructor can be used to initialize the description to a known set of values.
2. Requesting the state to be created by the renderer is still simple - just pass a pointer.
3. You can add methods for setting the description to particular common settings.

So, given a class header like this:

class DepthStencilStateConfigDX11{public:	DepthStencilStateConfigDX11();	virtual ~DepthStencilStateConfigDX11();	void SetDefaults();	void SetDepthEnable( bool state );	void SetDepthWriteMask( D3D11_DEPTH_WRITE_MASK state );	void SetDepthComparisonFunction( D3D11_COMPARISON_FUNC state );	void SetStencilEnable( bool state );	void SetStencilReadMask( UINT8 state );	void SetStencilWriteMask( UINT8 state );	void SetFrontFace( D3D11_DEPTH_STENCILOP_DESC state );	void SetBackFace( D3D11_DEPTH_STENCILOP_DESC state );	D3D11_DEPTH_STENCIL_DESC GetDepthStencilDesc();protected:	D3D11_DEPTH_STENCIL_DESC m_State;	friend RendererDX11;};

Now you can create the state object in the renderer like so:

DepthStencilStateConfigDX11 DepthStencilState;Renderer.CreateDepthStencilState( &DepthStencilState );

I have implemented these configuration classes for each of the state objects, and I will be adding them into the texture, buffer, and resource view creation schemes. It is a nice and clean solution, plus you can use it to add sanity checks on all of the different configurations and make sure there are no invalid state combinations.

could that be senor cow the cowering cow?

Not a cow - but it is a mammal...

If you want a hint: He's been prominently featured in my journal before, so you could peruse a bit and figure it out... It's surprising how much information you get from depth cues like shading, and how much it takes away when you don't have them...

Good guess though!

Elephant. What do I win? :-)

Thanks for the tip.

I tried rating you up, but I must have done that some time ago since it didn't move your score...

You'll have to settle for knowing that you were able to 'see in the dark'... I wonder what else I could render without shading to see if you can figure it out...

Regarding your tip, Richard [legalize] Thomson has also posted a somewhat sexier approach on his blog.

Just thought it might be of interest to you.

Quote:
 Original post by Ashkan Regarding your tip, Richard [legalize] Thomson has also posted a somewhat sexier approach on his blog. Just thought it might be of interest to you.
Thanks for the link - that is an interesting method for doing the configuration. However, the state setup methods have to guarantee that they don't overwrite one another on the subsequent calls, otherwise you could end up with some confusing results. I have continued to implement the config classes I mentioned above, and I am finding that if I have a single method to do a complete configuration then it works out well. You can do something along the lines of:

RasterizerConfig config; // sets defaults in constructor
config.SetWireframeDefaults(); // modified the needed wireframe parameters

I think it is quite clear what is going on, and if you always set the default in the constructor then you can easily allocate a configuration on the stack and use it as a basis for the more advanced configurations later on...

## Create an account

Register a new account