Jump to content
  • Advertisement
Sign in to follow this  
dessler.michelle

Differences between Device9::ProcessVertices and Device9::DrawPrimitive?

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

Hi there,

Can someone tell me what are the differences between Device9::ProcessVertices and Device9::DrawPrimitive?

In which scenario is better ProcessVertices?

Thank you,

Michelle.

Share this post


Link to post
Share on other sites
Advertisement
ProcessVertices just runs the vertex shader you specify on each element in the buffer(s) you bound to the pipeline, then saves out the result in the pDestBuffer argument-- see the MSDN documentation here. In most cases, I'd wager that you'll never actually need to do this unless you absolutely must use features in a more modern vertex shader model specification than is available or need to do some other special processing that doesn't work well in your traditional graphics pipeline. Additionally, I recall hearing that using this requires that software vertex processing be forced for the device, but I don't see any mention of this on the mentioned MSDN documentation page, so you'll probably want to test this and find out.

DrawPrimitive and friends, on the other hand, will actually go through the entire set of vertex and pixel shader stages, and will thus rasterize everything you feed it. This is the primary drawing workhorse in D3D; for the most part everything else exists to configure how these functions behave when invoked.

Share this post


Link to post
Share on other sites
These are complete two different methods. I never used ProcessVertices but from what I understand from msdn, it is used to manipulate vertices with a vertex shader and output them to a new vertex buffer. Draw primitive is used to display vertices on the screen.

Share this post


Link to post
Share on other sites

ProcessVertices just runs the vertex shader you specify on each element in the buffer(s) you bound to the pipeline, then saves out the result in the pDestBuffer argument-- see the MSDN documentation here. In most cases, I'd wager that you'll never actually need to do this unless you absolutely must use features in a more modern vertex shader model specification than is available or need to do some other special processing that doesn't work well in your traditional graphics pipeline. Additionally, I recall hearing that using this requires that software vertex processing be forced for the device, but I don't see any mention of this on the mentioned MSDN documentation page, so you'll probably want to test this and find out.

DrawPrimitive and friends, on the other hand, will actually go through the entire set of vertex and pixel shader stages, and will thus rasterize everything you feed it. This is the primary drawing workhorse in D3D; for the most part everything else exists to configure how these functions behave when invoked.


Once that vertex buffer is returned how we can draw its content in the screen? Do we have to use Device.DrawPrimitive() or there's a "special" command to send the vertices to the display avoiding traveling through the whole pipepline?

Share this post


Link to post
Share on other sites
You would still need to use DrawPrimitive(), but you can simplify the vertex shader.

Also note that DrawPrimitive() will be significantly slower than DrawIndexedPrimitive() unless the number of primitives is very small, because the index buffer enables the graphics card to cache results from the vertex shader.

Share this post


Link to post
Share on other sites

You would still need to use DrawPrimitive(), but you can simplify the vertex shader.


What do you mean with "you can simplify the vertex shader"?

I'm sorry by my silly questions but I'm new in DirectX.


Also note that DrawPrimitive() will be significantly slower than DrawIndexedPrimitive() unless the number of primitives is very small, because the index buffer enables the graphics card to cache results from the vertex shader.


Yes I knew that I just use DrawPrimitive() as an example but thanks anyways.

Share this post


Link to post
Share on other sites

[quote name='Adam_42' timestamp='1320169883' post='4879306']
You would still need to use DrawPrimitive(), but you can simplify the vertex shader.


What do you mean with "you can simplify the vertex shader"?

I'm sorry by my silly questions but I'm new in DirectX.


Also note that DrawPrimitive() will be significantly slower than DrawIndexedPrimitive() unless the number of primitives is very small, because the index buffer enables the graphics card to cache results from the vertex shader.


Yes I knew that I just use DrawPrimitive() as an example but thanks anyways.
[/quote]

Well remember that you've already done all the fancy skinning, etc. inside ProcessVertices() so you can make a very simple pass-through vertex shader that just shuttles things off to the rasterizer/pixel shader stage. There's no need to run your transformations, etc. again.

Share this post


Link to post
Share on other sites

Well remember that you've already done all the fancy skinning, etc. inside ProcessVertices() so you can make a very simple pass-through vertex shader that just shuttles things off to the rasterizer/pixel shader stage. There's no need to run your transformations, etc. again.


Now it makes sense to me.

Thank you guys once again for your help

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.

GameDev.net is your game development community. Create an account for your GameDev Portfolio and participate in the largest developer community in the games industry.

Sign me up!