processed vs non-processed vertices

Started by
0 comments, last by dynamicman 22 years, 5 months ago
what are the advantages/disadvantages of processed/non-processed vertex buffer? Are there any performance gains when youpass processed verticies to drawprimative calls? In what situations would any of them be benificial? What situations would they be clearly non benificial.... I''ve heard (through NEXE) that multitexturing is easier with processed verticiesl... why?
Advertisement
The ProcessVertices() call is _always_ done in software, it won''t ever take advantage of hardware T&L. It _will_ take advantage of CPU enhancements such as SSE or 3DNow!

The only way to take advantage of hardware T&L is to call DrawPrimitive() with an unprocessed vertex buffer (i.e. one which does NOT have XYZRHW in it''s vertex format).

When performing multiple *passes* using the same polygons, then using ProcessVertices() can *sometimes* be better to use. Say you had a model of a car and you needed to render it multiple times to get different layers of effects (assuming your target hardware couldn''t do the desired blending in a *single pass multitexture*):

methodA:
SetupRenderingMode( Base layer drawing mode );
DrawPrimitive( unprocessedCarModel );
SetupRenderingMode( Bumpy layer drawing mode );
DrawPrimitive( unprocessedCarModel );
SetupRenderingMode( Shiny layer drawing mode );
DrawPrimitive( unprocessedCarModel );
SetupRenderingMode( DirtyDecal layer drawing mode );
DrawPrimitive( unprocessedCarModel );

methodB:
ProcessVertices( FROM:unprocessedCarModel, TO:processedCarModel );
SetupRenderingMode( Base layer drawing mode );
DrawPrimitive( processedCarModel );
SetupRenderingMode( Bumpy layer drawing mode );
DrawPrimitive( processedCarModel );
SetupRenderingMode( Shiny layer drawing mode );
DrawPrimitive( processedCarModel );
SetupRenderingMode( DirtyDecal layer drawing mode );
DrawPrimitive( processedCarModel );

For a graphics card with hardware T&L:
MethodB is faster *if* the time taken to process the vertices in software once is less than the time taken to let hardware transform them multiple times (methodA, four times).
Since hardware T&L is specialised to do one job (T&L''ing) and do it very quickly, if it is set up correctly and gets an optimally sized and indexed chunk of vertices to transform, it is usually much quicker than software T&L.
Even in cases where it isn''t, because it happens in parallel with the main CPU (assuming you''ve set stuff up properly), it leaves the main CPU free to do other things (so really takes no CPU time at all!).
Generally with hardware T&L you want to use methodA. But if you have quite a lot of passes you might want to profile and experiment with methodB (YMMV).

For a graphics card without hardware T&L, methodB is faster since only one software transform is done as opposed to four.


The only other time you use ProcessVertices() is when you need to read the result of a T&L operation. There is no way of getting to the result of the transformation inside DrawPrimitive(). PV is the only way to get it.

--
Simon O''''Connor
Creative Asylum Ltd
www.creative-asylum.com

Simon O'Connor | Technical Director (Newcastle) Lockwood Publishing | LinkedIn | Personal site

This topic is closed to new replies.

Advertisement