On 30 August 2010 23:07, Misha Koshelev misha680@gmail.com wrote:
Looking forward to (constructive) comments.
Why are colors and normals special? What use is hasPosition? What happens when the source declaration has e.g. two color elements with usage index 0, or two position elements? Note that the booleans are redundant, you store that information in the FVF.
Henri Verbeet wrote:
On 30 August 2010 23:07, Misha Koshelev misha680@gmail.com wrote:
Looking forward to (constructive) comments.
Why are colors and normals special? What use is hasPosition? What happens when the source declaration has e.g. two color elements with usage index 0, or two position elements? Note that the booleans are redundant, you store that information in the FVF.
As you can see by the tests added, colors and normals have an ordering that is specifically constrained within the FVF.
To clarify, by saying that the booleans are redundant, do you mean to say that, say, if I have a normal element, I should iterate back through all declaration elements that have already been processed and check for a prior color element, and then return D3DERR_INVALIDCALL?
Again, for the case of two color elements or two normal elements, are you suggesting I do the same (iterate through all past elements)? Wouldn't, in this case, a boolean be more efficient?
hasPosition I apologize does not need to be there.
Just trying to clarify your points regarding your comments re booleans and specialty of colors and normals.
Thank you Misha
On 31 August 2010 14:47, misha680 misha680@gmail.com wrote:
As you can see by the tests added, colors and normals have an ordering that is specifically constrained within the FVF.
Well yes, but I'd say that ordering should apply to *any* FVF element, not just colors and normals. E.g., point size before position or texture before color should be just as untranslatable.
To clarify, by saying that the booleans are redundant, do you mean to say that, say, if I have a normal element, I should iterate back through all declaration elements that have already been processed and check for a prior color element, and then return D3DERR_INVALIDCALL?
No, but you can check "*fvf & D3DFVF_NORMAL" to see if you already have a normal.
On Tue, Aug 31, 2010 at 7:58 AM, Henri Verbeet hverbeet@gmail.com wrote:
On 31 August 2010 14:47, misha680 misha680@gmail.com wrote:
As you can see by the tests added, colors and normals have an ordering that is specifically constrained within the FVF.
Well yes, but I'd say that ordering should apply to *any* FVF element, not just colors and normals. E.g., point size before position or texture before color should be just as untranslatable.
Thank you. I was not aware of these constraints.
Is there, by any chance, a good place for this? I have been checking the MSDN docs so far: http://msdn.microsoft.com/en-us/library/bb147173%28VS.85%29.aspx but at least upon my initial reads did not notice any such guidelines.
To clarify, by saying that the booleans are redundant, do you mean to say that, say, if I have a normal element, I should iterate back through all declaration elements that have already been processed and check for a prior color element, and then return D3DERR_INVALIDCALL?
No, but you can check "*fvf & D3DFVF_NORMAL" to see if you already have a normal.
That is a great idea!
I honestly did not think of that at all. Thank you for the wonderful hint.
Misha
On 31 August 2010 18:16, Misha Koshelev misha680@gmail.com wrote:
Well yes, but I'd say that ordering should apply to *any* FVF element, not just colors and normals. E.g., point size before position or texture before color should be just as untranslatable.
Thank you. I was not aware of these constraints.
Is there, by any chance, a good place for this? I have been checking the MSDN docs so far: http://msdn.microsoft.com/en-us/library/bb147173%28VS.85%29.aspx but at least upon my initial reads did not notice any such guidelines.
It's implied by the way FVFs work. (Think about it, "D3DFVF_XYZ | D3DFVF_DIFFUSE | D3DFVF_PSIZE" for example describes a very specific vertex buffer layout, if you translate a declaration to that, it should better describe that exact same layout.)
Henri Verbeet wrote:
On 31 August 2010 18:16, Misha Koshelev misha680@gmail.com wrote:
Well yes, but I'd say that ordering should apply to *any* FVF element, not just colors and normals. E.g., point size before position or texture before color should be just as untranslatable.
Thank you. I was not aware of these constraints.
Is there, by any chance, a good place for this? I have been checking the MSDN docs so far: http://msdn.microsoft.com/en-us/library/bb147173%28VS.85%29.aspx but at least upon my initial reads did not notice any such guidelines.
It's implied by the way FVFs work. (Think about it, "D3DFVF_XYZ | D3DFVF_DIFFUSE | D3DFVF_PSIZE" for example describes a very specific vertex buffer layout, if you translate a declaration to that, it should better describe that exact same layout.)
Thank you. I had to check a reference but I think I understand now.
http://www.xmission.com/~legalize/book/download/05-Modeling.pdf
pg. 168
"The vertex components are laid out in memory in the same order as the vertex components listed in the table, starting with the position component. #define D3DFVF_XYZ 0x002 #define D3DFVF_XYZRHW 0x004 #define D3DFVF_XYZB1 0x006 #define D3DFVF_XYZB2 0x008 #define D3DFVF_XYZB3 0x00a #define D3DFVF_XYZB4 0x00c #define D3DFVF_XYZB5 0x00e #define D3DFVF_NORMAL 0x010 #define D3DFVF_PSIZE 0x020 #define D3DFVF_DIFFUSE 0x040 #define D3DFVF_SPECULAR 0x080 #define D3DFVF_TEX0 0x000 #define D3DFVF_TEX1 0x100 #define D3DFVF_TEX2 0x200 #define D3DFVF_TEX3 0x300 #define D3DFVF_TEX4 0x400 #define D3DFVF_TEX5 0x500 #define D3DFVF_TEX6 0x600 #define D3DFVF_TEX7 0x700 #define D3DFVF_TEX8 0x800 #define D3DFVF_LASTBETA_UBYTE4 0x1000 Every FVF must include a position with one of the D3DFVF XYZ, D3DFVF - XYZRHW, D3DFVF XYZB1, D3DFVF XYZB2, D3DFVF XYZB3, D3DFVF XYZB4, or D3D- FVF XYZB5. The remaining FVF flags are all optional."
D3DFVF_LASTBETA_D3DCOLOR is not present in the list above, but as, per include/d3d9types.h:#define D3DFVF_LASTBETA_D3DCOLOR 0x8000 it is last, I assume it would also come last?
Thank you Misha
On 31 August 2010 18:48, misha680 misha680@gmail.com wrote:
D3DFVF_LASTBETA_D3DCOLOR is not present in the list above, but as, per include/d3d9types.h:#define D3DFVF_LASTBETA_D3DCOLOR 0x8000 it is last, I assume it would also come last?
The LASTBETA FVF flags don't add elements themselves, they modify the D3DFVF_XYZBn ones. See also D3DXDeclaratorFromFVF() for reference.
-
Henri Verbeet -
Misha Koshelev -
misha680