Jump to content
  • Advertisement

Archived

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

L_dot_N

VFV with more than 2 Colors

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

Is in dx9 a way for the use of more than 2 Colors in a Vertex Shader. I am tying to use min 4 Colors,up to 6 Colors, because they are great to switch to 16 Bit data. But in the VFV are only Diffuse and Specular, is there a trick to get more ??

Share this post


Link to post
Share on other sites
Advertisement
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

Share this post


Link to post
Share on other sites
I want to use the colors as Vertex format input so i can have Pos,Normal,Texure,Tangent in 16 Bytes to optimise vertex cache.
in the Vertex shader
Pos.x = r+(g/256) usw
But in the dcl are only 2 colors

Share this post


Link to post
Share on other sites
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

Share this post


Link to post
Share on other sites
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?



Read about my game, project #1
NEW (18th December)2 new screenshots, one from the engine and one from the level editor



John 3:16

Share this post


Link to post
Share on other sites
In DX9 are in the D3DDECLUSAGE type by D3DDECLUSAGE_COLOR are only the UsageIndex 0 and 1 shown as valid(not like in Texcoord UsageIndex = n)
I don´t know if it is allowed to use the D3DDECLTYPE_D3DCOLOR as Pos,Normal,etc..

I think I have to test it well on some Hardware, bevor I can use it.

But thanks for the great help

Share this post


Link to post
Share on other sites
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

Share this post


Link to post
Share on other sites

  • Advertisement
×

Important Information

By using GameDev.net, you agree to our community Guidelines, Terms of Use, and Privacy Policy.

We are the game development community.

Whether you are an indie, hobbyist, AAA developer, or just trying to learn, GameDev.net is the place for you to learn, share, and connect with the games industry. Learn more About Us or sign up!

Sign me up!