The problem is most graphics chips only support the two colour interpolators. So the only other thing you have left is texture coordinates...

If you have pixel shader support you can interpret the texture coordinates directly as colours!

Otherwise think of texture maps themselves as really being look up tables or palettes - toon shading commonly uses a 1D texture for example to look up single shades of colour. Because the texture coordinates are interpolated [in a perspective correct manner too], so the individual texels fetched will be too with bilinear filtering.

You can extend this idea depending on what range of colours you need. Say for example one of your colours needed to be some combination of red and green where red could range from 0 to 255 and green could range from 0 to 255. You could simply use a precalculated 2D texture where say the U axis was red (from 0 to 255) and the V axis was green. So that all the pixels in the texture would represent all the possible combinations of red and green. Then in each vertex you can vary the red or green contribution just by changing a set of U and V texture coordinates.

To do this with R,G and B would require a volume texture which is lots of memory and if you had volume texture support it''s likely you''d have pixel shader support. However since colour is additive, you could use one texture stage for the R and G 2D texture and the next stage for a B 1D texture and simply do an ADD between stages.

On a GeForce256 / GeForce2 level card, you can only reliably have 2 textures per single pass combined with the two usual iterated colours would give you the four you require with the texture based ones being limited to 2D or at best 6 sets of 2D with a cube texture. Another issue with that is you''ve used all the stages so you can''t do anything interesting like apply a base texture.


I do have to ask WHY do you need 6 per vertex colours? - I suspect you''re doing some sort of terrain blending system and need all these colours to simplify the representation of your vertex data and the way you use the D3D API. I''d advise you to rethink the reasoning and come up with a system which can use 2 except in extreme situations.


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

Ah so you don''t actually need to use these as colours which is what above is to solve.

Why not just change the vertex declaration. The "semantic type" and dcl_* instructions are only really used as hints and by any tesselator (such as N-Patch) and for FVF shaders.

For just shaders (i.e. no FVF use) you can set the data type in your D3DVERTEXELEMENT9 declaration entries to whatever you want!!! - if you want to use D3DDECLTYPE_UBYTE4 for your normals, colours, UVs etc, then there''s nothing stopping you really (assuming hardware support on early shader hardware you have to use D3DDECLTYPE_D3DCOLOR and scale in the shader).


BTW: that won''t optimise for what is typically called the "vertex cache", which should be better known as "post transform vertex cache" which tend to have a fixed number of vertices anyway (so halving your vertex format size won''t get you twice as much in the cache). Only better indexing makes better use of the post T&L cache.
However it WILL help with the memory cache (i.e. the cache between the T&L and the input data).
Much more important though is the fact that less data is being transferred over the AGP bus.

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

quote:Original post by d000hg
I wondered about this - so the vertex structure does not have to have any fixed structure - is that what you''re saying? Is that a new D3D9 feature or can it be done in D3D8?

If you''re using a vertex shader and the vertex buffer wasn''t created with an FVF, then yes - any order you like.

The predefined orders are there:

- for when you use multiple streams with the fixed function pipeline (i.e. in that case you must stream into the correct places in the correct order so that the complete vertex is available in the order it expects)

- as hints about what is mapped to where for things such as the hardware tesselators (for N patches, displacement mapping etc) - if you need those, then you may need to use the predefined order.


I''ve hung app and shader specific data in the middle of vertex formats and chosen my own register assignments without any problems...

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