I have a problem - and it is all those "optimization" docs out there. Recently I decided to switch from multiple streamsources (that is, one streamsource for vertex data, one for normals, one for vertex coloring.. you get the point) and group all my vertex data into one vertexbuffer. According to most of the optimization-docs out there, the optimal size of a vertexbuffer is around 2-4Mb to remove redundant vertexbuffer switches. However, another doc claims that there is unnessescary to send more data than needed: do NOT send color as a float component when a byte is enough. Alright - that seems clever enough... but hey.. how am I supposed to keep the colordata - stored as bytes - in the same buffer that's containing floats? well, perhaps I can use a separate vertexbuffer for that.. yes that'll work. NO IT WONT. at least not in a efficient way. If you are supposed to store the colordata in a separate vertexbuffer you need to keep the colordata aligned to the vertexdata because you can not use several indexbuffers on one stream. So either ju keep using your colors as a float and keep then together with the rest of the vertex data, or you'll create a vertexbuffer big enough to align the colordata with the rest of the vertexdata - which is pure madness - because you'll waste tons of valueable video memory. Let's say you got a vertexformat containing position (xyz), normal (xyz) and two sets of texture coordinates (uv * 2) reaching and astounding 12 + 12 + 8 * 2 = 40 bytes. If you are to use a separate vertexdata for the colorbuffer, you're wasting 40b of data per vertex (just because the colordata needs to be offseted by 40b). BUT if you did use floats as you color component you'd only waste sizeof(float) - sizeof(byte) bytes per color component and vertex. However, the only way to use floats as color components is throught the programmable pipeline. Is there anyone around with some more information about this?

Hmm.. I thouht I had that in mind, but that was obviously wrong. :)

Quote:Original post by Illco
How was it obviously wrong?

I meant that I thought I had an explanation to why that wouldn't work :)

I don't have much experience with vertex declarations - why can't you just set the declaration type to byte instead of float?

You might want to have a read of Superpig's Journal - he has a nice entry on vertex data compression and decompression...

An obvious one is to reduce normals to 2D vectors and deduce the 3rd component in a shader, which should trim a float out of your vertex declaration.

hth
Jack