Advertisement Jump to content


This topic is now archived and is closed to further replies.


is this good or bad?

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

what about using ProcessVertices() to transform everything on the scene, and then render all the passes needed with the same results from ProcessVertices. wouldn''t that be faster than re-rendering everything for multiple passes? i imagine it''d be slower if there are 2, maybe 3 or less passes though.

Share this post

Link to post
Share on other sites
Often each pass has another light so it won''t work then. It would work for terrain splatting or other multipass texturing tricks, but I dunno if ProcessVertices is much slower.

Share this post

Link to post
Share on other sites
The most important thing to remember about ProcessVertices is it will *ALWAYS* be performed by the CPU so will never take advantage of any hardware vertex processing (H/W T&L) on the graphics chip (which should be thought of as "write only" devices in most cases).

Whether ProcessVertices() to transform and light (perhaps with a vertex shader) then multiple Draw*Primitive() calls from the transformed ProcessVertices result will be faster than multiple calls to Draw*Primitive() with untransformed data is pretty much application AND hardware dependent.

If your app is running on a machine with a non-T&L device (e.g. TNT, G400 etc, basically anything before a GeForce 256*), then using ProcessVertices in this way for multi-pass will ALWAYS be a good thing.

On a machine with hardware shader support (or just hardware T&L if your app uses fixed function vertex processing), whether it''s a win is something you should profile - and will be dependent on things such as:

- how complex your vertex shader is (more complex = more CPU cycles inside ProcessVertices)

- whether you have a lot of static vertex buffers (buffers for ProcessVertices should always be in system memory, the optimal place for static vertex data is in video or AGP memory which implies a lot of copying across the AGP bus which may be avoided with the multiple passes).

- the speed of the hardware T&L versus the speed of the software processing on the CPU.

- the amount of other demands there are for the CPU (anything which forces even a partial serialisation between CPU and GPU and burns lots of CPU cycles isn''t good *IF* you have lots of other work such as physics which needs doing on the CPU).

[*consumer level - 3DLabs had T&L parts out before nVidia, but they were aimed at the professional artist market]

Simon O''Connor
Creative Asylum Ltd

Share this post

Link to post
Share on other sites

  • Advertisement

Important Information

By using, you agree to our community Guidelines, Terms of Use, and Privacy Policy. 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!