In DirectX 9, we can use the D3DXCreateTeapot function to create a teapot mesh for render, but, it seems D3D 11 has no such function, is there any library or function in D3D11 that can draw a teapot? We usually need a common 3D model to perform some graphics effects and teapot is always the default one.
Utah teapot
DirectX 11 doesn't provide common geometry anymore.
You can look at this project, which has common geometric primitives (including teapot) and some other bits:
http://directxtk.codeplex.com/
Related
I want to simply render a 2D image to the window. After hours of digging into DirectX, still can't find a way to do it. Can I simply load the image into buffer then let swapchain to display this buffer of image?
The SimpleTexture sample on GitHub demonstrates exactly this scenario for C++.
DX11 Win32
DX11 UWP
DX12 Win32
DX12 UWP
As you are new to DirectX, you may also want to look at the DirectX Tool Kit for DX11 / DX12 which provides a very simple to use SpriteBatch class.
I wonder, which format for Normal Maps is the correct one to use within SceneKit content, for iOS? As referenced here: DirectX vs. OpenGL normal maps.
OpenGL or DirectX? Or does is not matter?
I had to figure it out by testing the OpenGL vs. DirectX Normal Map Typus side by side on planes. This gives me the following results:
This means, if you have the choice between the OpenGL or the DirectX Normal Map, you better choose OpenGL.
I had a good search before starting here, this question:
How to set RenderState in DirectX11?
is far too general; in studying the first answer, I suspect I need the Blend State, but it's not obvious how to set up an alpha comparison.
And searching stack overflow for D3DRS_ALPHAREF produced only seven other questions: https://stackoverflow.com/search?q=D3DRS_ALPHAREF none of which are even remotely close.
I'm using this for a program that does a two pass render to transition from one image to a second. I have a control texture that is the same size as the textures I'm rendering, and is single channel luminance.
The last lines of my pixel shader are:
// Copy rgb from the source texture
out.color.rgb = source.color.rgb;
// copy alpha from the control texture.
out.color.a = control.color.r;
return out;
Then in my render setup I have:
DWORD const reference = static_cast<DWORD>(frameNum);
D3DCMPFUNC const compare = pass == 0 ? D3DCMP_GREATEREQUAL : D3DCMP_LESS;
m_pd3dDevice->SetRenderState(D3DRS_ALPHAREF, reference);
m_pd3dDevice->SetRenderState(D3DRS_ALPHAFUNC, compare);
Where frameNum is the current frame number of the transition: 0 through 255.
-- Edit -- For those not intimately familiar with this particular capability of DirectX 9, the final stage uses the compare function to compare the alpha output from the pixel shader with the reference value, and then it actually draws the pixel iff the comparison returns a true value.
The net result of all this is that the luminance level of the control texture controls how early or late each pixel changes in the transition.
So, how exactly do I do this with DirectX 11?
Yes, I realize there are other ways to achieve the same result, passing frameNum to a suitably crafted pixel shader could get me to the same place.
That's not the point here, I'm not looking for an alternative implementation, I am looking to learn how to do alpha comparisons in DirectX 11, since they have proven a useful tool from time to time in DirectX 9.
If you are moving from Direct3D 9 to Direct3D 11, it is useful to take a brief stop at what changed in Direct3D 10. This is covered in detail on MSDN. One of the points in that article is:
Removal of Fixed Function
It is sometimes surprising that even in a Direct3D 9 engine that fully exploits the programmable pipeline, there remains a number of areas that depend on the fixed-function (FF) pipeline. The most common areas are usually related to screen-space aligned rendering for UI. It is for this reason that you are likely to need to build a FF emulation shader or set of shaders which provide the necessary replacement behaviors.
This documentation contains a white paper containing replacement shader sources for the most common FF behaviors (see Fixed Function EMU Sample). Some fixed-function pixel behavior including alpha test has been moved into shaders.
IOW: You do this in a programmable shader in Direct3D 10 or later.
Take a look at DirectX Tool Kit and in particular the AlphaTestEffect (implemented in this cpp and shader file).
In the documentation of SCNView it is stated that:
SceneKit supports OpenGL ES 3.0, but some features are disabled when rendering in a OpenGL ES 3.0 context
I could not find anywhere which features were disabled. I wanted to use my own shader with SceneKit (assigning a SCNProgram to my material) and I tried to use a 3D texture. But I got the following error:
SceneKit: error, C3DBaseTypeFromString: unknown type name 'sampler3D'
So I'm guessing that 3D textures are part of the disabled features but I could not find a confirmation anywhere. Do I have to give up on SceneKit and do all my rendering with OpenGL manually just to use 3D textures?
Bonus question: Why Apple would support only a subset of OpenGL ES 3.0 in SceneKit since iOS has full support?
Some features of SceneKit don't work in an ES3 context. You should still be able to use all ES3 features in your OpenGL code.
This looks like an error in SceneKit detecting the uniform declaration for use with its higher-level APIs... so you won't be able to, say, bind an SCNMaterialProperty to that uniform with setValue:forKey:. However, you should still be able to use the shader program -- you'll have to bind it with glBindTexture/glActiveTexture instead (inside a block you set up with handleBindingOfSymbol:usingBlock:).
I was wondering if it is worth it to use shaders to draw a 2D texture in xna. I am asking because with openGL it is much faster if you use GLSL.
Everything on a modern GPU is drawn using a shader.
For the old immediate-style rendering (ie: glBegin/glVertex), that will get converted to something approximating buffers and shaders somewhere in the driver. This is why using GLSL is "faster" - because it's closer to the metal, you're not going through a conversion layer.
For a modern API, like XNA, everything is already built around "buffers and shaders".
In XNA, SpriteBatch provides its own shader. The source code for the shader is available here. The shader itself is very simple: The vertex shader is a single matrix multiplication to transform the vertices to the correct raster locations. The pixel shader simply samples from your sprite's texture.
You can't really do much to make SpriteBatch's shader faster - there's almost nothing to it. There are some things you can do to make the buffering behaviour faster in specific circumstances (for example: if your sprites don't change between frames) - but this is kind of advanced. If you're experiencing performance issues with SpriteBatch, be sure you're using it properly in the first place. For what it does, SpriteBatch is already extremely well optimised.
For more info on optimisation, see this answer.
If you want to pass a custom shader into SpriteBatch (eg: for a special effect) use this overload of Begin and pass in an appropriate Effect.