Shawn Hargreaves Blog
2010 update: if you are using a version of XNA Game Studio >= 4.0, see here instead.
If you are mixing 3D rendering with 2D objects using SpriteBatch, you may notice that your 3D graphics no longer draw correctly after you have rendered sprites. This is because the SpriteBatch changes several device renderstates to values that may not be appropriate for drawing in 3D.An obvious way to avoid this problem is to pass SaveStateMode.SaveState when you call SpriteBatch.Begin, but there is a potential pitfall here. Saving and restoring device state can be slow, so if you do this a lot, your framerate will suffer.A more efficient approach is to always set whatever renderstates you need before you draw any graphics. SpriteBatch will automatically set what it needs for drawing in 2D, so you just need to set these back to what you want before drawing in 3D.So exactly which renderstates does SpriteBatch change? Here's the complete list:
GraphicsDevice.RenderState.CullMode = CullMode.CullCounterClockwiseFace; GraphicsDevice.RenderState.DepthBufferEnable = false; GraphicsDevice.RenderState.AlphaBlendEnable = true; GraphicsDevice.RenderState.AlphaBlendOperation = BlendFunction.Add; GraphicsDevice.RenderState.SourceBlend = Blend.SourceAlpha; GraphicsDevice.RenderState.DestinationBlend = Blend.InverseSourceAlpha; GraphicsDevice.RenderState.SeparateAlphaBlendEnabled = false; GraphicsDevice.RenderState.AlphaTestEnable = true; GraphicsDevice.RenderState.AlphaFunction = CompareFunction.Greater; GraphicsDevice.RenderState.ReferenceAlpha = 0; GraphicsDevice.SamplerStates.AddressU = TextureAddressMode.Clamp; GraphicsDevice.SamplerStates.AddressV = TextureAddressMode.Clamp; GraphicsDevice.SamplerStates.MagFilter = TextureFilter.Linear; GraphicsDevice.SamplerStates.MinFilter = TextureFilter.Linear; GraphicsDevice.SamplerStates.MipFilter = TextureFilter.Linear; GraphicsDevice.SamplerStates.MipMapLevelOfDetailBias = 0.0f; GraphicsDevice.SamplerStates.MaxMipLevel = 0;
SpriteBatch also modifies the Vertices, Indices, VertexDeclaration, VertexShader, and PixelShader properties on the GraphicsDevice.
Many of these settings are fine for both 2D and 3D rendering, but before you draw anything in 3D you will probably want to reset these states:
GraphicsDevice.RenderState.DepthBufferEnable = true; GraphicsDevice.RenderState.AlphaBlendEnable = false; GraphicsDevice.RenderState.AlphaTestEnable = false;
Depending on your 3D content, you may also want to set:
GraphicsDevice.SamplerStates.AddressU = TextureAddressMode.Wrap; GraphicsDevice.SamplerStates.AddressV = TextureAddressMode.Wrap;
Thanks man, I've been looking hours to fix this "bug".
Spent a few days trying to solve an error, went through tonnes of pages before finding this! Cheers!
Thanks for this - much appreciated.
WOW... thank you very, very, very much. What a time saver. You're the best.
Your link for the XNA v4 version goes to this same page. =(
Link fixed :-)
For Windows Phone 7, try this:
GraphicsDevice.BlendState = BlendState.Opaque;
GraphicsDevice.DepthStencilState = DepthStencilState.Default;
Ridiculous, forcing a manual reset of states changed by SpriteBatch. That's sloppy code.
it does seem kinda strange to me that you should have to reset what you set up each frame because its fliping your switches off state machine designs are'nt supposed to behave like that
Really the only sane way to achieve a high performance graphics API is to always set whatever state you need before each piece of drawing code (and use things like state objects to make this setting efficient).
It's not really feasible to adopt an "if you change something, put it back" policy, because that begs the question, put it back to what? What should the default states be? Every piece of code wants different defaults, and such designs lead to a world of terrible fragility when assumptions change or you try to integrate pieces of code that were written assuming different default states.
XNA adopts a policy of "assume nothing, and always set everything you care about before drawing anything", which is not only the most robust way to manage renderstates, but also by far the most efficient.
How could they have overlooked the fact that people will no doubt need sprites in 3D games/scenes? Either way this helped a lot, now i can display the HUD with the actual game not looking all wrong and weird. Thanks, 5/5