Anything special need to be done to use D3DFVF_XYZRHW?
Author
I''ve added a hud to my game and the actual polygon creation, etc... is easy (two triangles to make a rectangle). My Vertex type is (D3DFVF_XYZRHW | D3DFVF_TEX1) and I don''t do much else than set the VertexShader:
m_pd3dDevice->SetVertexShader( D3DFVF_XYZRHW_VERTEX );
I am setting my texture coordinates as I would for an object (between 0 and 1), but for some reason, my textures display completely skewed (as if the texture coordinates were wrong).
My render loop first dones a bunch of "normal" rendering with world transforms and untransformed vertices prior to rendering the HUD. Do I need to set anything else (other than setting the VertexShader) to make sure D3DFVF_XYZRHW vertices are rendered correctly?
Onnel
Make sure the .rhw member of the vertices you pass is set to 1.0
Also follow the "directly mapping texels to pixels" topic in the docs to the letter.
Finally:
- make sure the projection matrix is valid if you need any clipping. Though for HUD sprites you should really turn off the clipper (D3DRS_CLIPPING=FALSE) to prevent any unnecessary back transformation.
- make sure the viewport is valid.
- try with the reference rasteriser - it could be a card/driver issue. Some S3 chips for example umm "curve" TL vertex vertices.
- another one to _try_ on older bugged chips is passing the texture coordinates in screen space. That''s only really old chips though.
My guess would be a screwy RHW value. What''s the chip ?
--
Simon O''Connor
Creative Asylum Ltd
www.creative-asylum.com
Also follow the "directly mapping texels to pixels" topic in the docs to the letter.
Finally:
- make sure the projection matrix is valid if you need any clipping. Though for HUD sprites you should really turn off the clipper (D3DRS_CLIPPING=FALSE) to prevent any unnecessary back transformation.
- make sure the viewport is valid.
- try with the reference rasteriser - it could be a card/driver issue. Some S3 chips for example umm "curve" TL vertex vertices.
- another one to _try_ on older bugged chips is passing the texture coordinates in screen space. That''s only really old chips though.
My guess would be a screwy RHW value. What''s the chip ?
--
Simon O''Connor
Creative Asylum Ltd
www.creative-asylum.com
Author
z is always 0.5 and rhw is 1.0. It's a G4 4600, so I don't think it's likely to be an "old" chipset problem.
Clipping shouldn't be an issue (will turning it off speed up the rendering? I'm trying to minimized device state changes), as the rectangle itself displays correctly and at the right coordinates.
What do you mean when you say "make sure the viewpoint is valid"? I have a D3DTS_VIEW matrix that is updated every frame, but I thought the XYZRHW vertices would ignore it.
I don't think my vertice/index/tu/tv are incorrect, but here's how I have them set:
So triangles are 0-1-2 and 2-1-3.
Thanks as always for your help Simon!
Onnel
[edited by - onnel on October 18, 2002 10:07:33 AM]
Clipping shouldn't be an issue (will turning it off speed up the rendering? I'm trying to minimized device state changes), as the rectangle itself displays correctly and at the right coordinates.
What do you mean when you say "make sure the viewpoint is valid"? I have a D3DTS_VIEW matrix that is updated every frame, but I thought the XYZRHW vertices would ignore it.
I don't think my vertice/index/tu/tv are incorrect, but here's how I have them set:
0-------1| /|| / || / || / || / || / |2-------3Texture coords are as follows:0 = 0,01 = 1,02 = 0,13 = 1,1// Generate the ground indicesint ind = 0;m_Indices[ind++] = 0;m_Indices[ind++] = 1;m_Indices[ind++] = 2;m_Indices[ind++] = 2;m_Indices[ind++] = 1;m_Indices[ind++] = 3; So triangles are 0-1-2 and 2-1-3.
Thanks as always for your help Simon!
Onnel
[edited by - onnel on October 18, 2002 10:07:33 AM]
Author
Never mind, I figured it out (and boy was it dumb).
My vertex definition is:
#define D3DFVF_XYZRHW_VERTEX (D3DFVF_XYZRHW | D3DFVF_TEX1)
But my structure for a vertex was:
struct HUDVERTEX
{
D3DXVECTOR3 p;
FLOAT tu;
FLOAT tv;
FLOAT rhw;
}
So it was reading my tu in as the rhw!
I''ve since gone to using a D3DXVECTOR4 for the XYZW.
Thanks and hopefully this will help someone else learn the importance of making sure your define and your struct declaration match up!
Onnel
My vertex definition is:
#define D3DFVF_XYZRHW_VERTEX (D3DFVF_XYZRHW | D3DFVF_TEX1)
But my structure for a vertex was:
struct HUDVERTEX
{
D3DXVECTOR3 p;
FLOAT tu;
FLOAT tv;
FLOAT rhw;
}
So it was reading my tu in as the rhw!
I''ve since gone to using a D3DXVECTOR4 for the XYZW.
Thanks and hopefully this will help someone else learn the importance of making sure your define and your struct declaration match up!
Onnel
quote:Clipping .... (will turning it off speed up the rendering? I''m trying to minimized device state changes),
If you always know that your XYZRHW are _always_ going to be within the viewport (or better the guardband), then yes it can.
The reason is that XYZRHW vertices aren''t just for sprites, you can also pass fully transformed 3D with them.
So if you ask D3D (and possibly the graphics chip on T&L boards) to clip transformed stuff, it **doesn''t know** that what you''ve passed actually really 2D and can simply do if (x<0 || x>640) clip() so it actually back transforms from screen space into clip space (i.e. what you get just after the projection transform before the homogeneous divide).
Some chips can do this in hardware, they''ll expose the D3DPMISCCAPS_CLIPTLVERTS cap. But if you have a chip which can''t, you force ALL the XYZRHW vertices (**even if they''re visible** ) to go through a nasty reverse part of the D3D software T&L pipe.
As an example GeForce2 doesn''t report the D3DPMISCCAPS_CLIPTLVERTS cap. So any work you do forcing XYZRHW vertex buffers into nice dynamic VBs will also be thrown away on those (and other) chips.
Moral of the story: don''t clip unless you need to.
--
Simon O''Connor
Creative Asylum Ltd
www.creative-asylum.com
This topic is closed to new replies.
Advertisement
Popular Topics
Advertisement
