• Advertisement
Sign in to follow this  

Why does my cube look like this

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

/* WHY DOES MY CUBE LOOK LIKE THIS WITH THE LIGHT*/ /* It has been rotated a bit to show the extermity */ /* LIGHT STRUCT*/ m_Light.Diffuse.r = 1.0f; m_Light.Diffuse.g = 1.0f; m_Light.Diffuse.b = 1.0f; m_Light.Diffuse.a = 1.0f; m_Light.Type = D3DLIGHT_POINT; m_Light.Position = D3DXVECTOR3( 0.0f, 0.0f, 10.0f ); m_Light.Attenuation0 = 0.0f; m_Light.Attenuation1 = 0.05f; m_Light.Attenuation2 = 0.0f; m_Light.Range = 100.0f; /* CUBE STRUCT */ struct VERTEX_SINGLE { float x,y,z; D3DXVECTOR3 vNormal; float tu,tv; DWORD diffuse; enum FVF { FVF_Flags = D3DFVF_XYZ | D3DFVF_NORMAL | D3DFVF_TEX1 | D3DFVF_DIFFUSE }; }; POS, NORMAL, TEXU, TEXV, DIFFUSE VERTEX_SINGLE g_cubeVertices[] = { {-1.0f, 1.0f,-1.0f , D3DXVECTOR3(0,0,-1), 0, 0, D3DCOLOR_COLORVALUE(1.0f,1.0f,1.0f,1.0f)}, { 1.0f, 1.0f,-1.0f , D3DXVECTOR3(0,0,-1), 1, 0, D3DCOLOR_COLORVALUE(1.0f,1.0f,1.0f,1.0f)}, {-1.0f,-1.0f,-1.0f , D3DXVECTOR3(0,0,-1), 0, 1, D3DCOLOR_COLORVALUE(1.0f,1.0f,1.0f,1.0f)}, { 1.0f,-1.0f,-1.0f , D3DXVECTOR3(0,0,-1), 1, 1, D3DCOLOR_COLORVALUE(1.0f,1.0f,1.0f,1.0f)}, {-1.0f, 1.0f, 1.0f , D3DXVECTOR3(0,0,1), 1, 0, D3DCOLOR_COLORVALUE(1.0f,1.0f,1.0f,1.0f)}, {-1.0f,-1.0f, 1.0f , D3DXVECTOR3(0,0,1), 1, 1, D3DCOLOR_COLORVALUE(1.0f,1.0f,1.0f,1.0f)}, { 1.0f, 1.0f, 1.0f , D3DXVECTOR3(0,0,1), 0, 0, D3DCOLOR_COLORVALUE(1.0f,1.0f,1.0f,1.0f)}, { 1.0f,-1.0f, 1.0f , D3DXVECTOR3(0,0,1), 0, 1, D3DCOLOR_COLORVALUE(1.0f,1.0f,1.0f,1.0f)}, {-1.0f, 1.0f, 1.0f , D3DXVECTOR3(0,1,0), 0, 0, D3DCOLOR_COLORVALUE(1.0f,1.0f,1.0f,1.0f)}, { 1.0f, 1.0f, 1.0f , D3DXVECTOR3(0,1,0), 1, 0, D3DCOLOR_COLORVALUE(1.0f,1.0f,1.0f,1.0f)}, {-1.0f, 1.0f,-1.0f , D3DXVECTOR3(0,1,0), 0, 1, D3DCOLOR_COLORVALUE(1.0f,1.0f,1.0f,1.0f)}, { 1.0f, 1.0f,-1.0f , D3DXVECTOR3(0,1,0), 1, 1, D3DCOLOR_COLORVALUE(1.0f,1.0f,1.0f,1.0f)}, {-1.0f,-1.0f, 1.0f , D3DXVECTOR3(0,-1,0), 0, 0, D3DCOLOR_COLORVALUE(1.0f,1.0f,1.0f,1.0f)}, {-1.0f,-1.0f,-1.0f , D3DXVECTOR3(0,-1,0), 1, 0, D3DCOLOR_COLORVALUE(1.0f,1.0f,1.0f,1.0f)}, { 1.0f,-1.0f, 1.0f , D3DXVECTOR3(0,-1,0), 0, 1, D3DCOLOR_COLORVALUE(1.0f,1.0f,1.0f,1.0f)}, { 1.0f,-1.0f,-1.0f , D3DXVECTOR3(0,-1,0), 1, 1, D3DCOLOR_COLORVALUE(1.0f,1.0f,1.0f,1.0f)}, { 1.0f, 1.0f,-1.0f , D3DXVECTOR3(1,0,0), 0, 0, D3DCOLOR_COLORVALUE(1.0f,1.0f,1.0f,1.0f)}, { 1.0f, 1.0f, 1.0f , D3DXVECTOR3(1,0,0), 1, 0, D3DCOLOR_COLORVALUE(1.0f,1.0f,1.0f,1.0f)}, { 1.0f,-1.0f,-1.0f , D3DXVECTOR3(1,0,0), 0, 1, D3DCOLOR_COLORVALUE(1.0f,1.0f,1.0f,1.0f)}, { 1.0f,-1.0f, 1.0f , D3DXVECTOR3(1,0,0), 1, 1, D3DCOLOR_COLORVALUE(1.0f,1.0f,1.0f,1.0f)}, {-1.0f, 1.0f,-1.0f , D3DXVECTOR3(-1,0,0), 1, 0, D3DCOLOR_COLORVALUE(1.0f,1.0f,1.0f,1.0f)}, {-1.0f,-1.0f,-1.0f , D3DXVECTOR3(-1,0,0), 1, 1, D3DCOLOR_COLORVALUE(1.0f,1.0f,1.0f,1.0f)}, {-1.0f, 1.0f, 1.0f , D3DXVECTOR3(-1,0,0), 0, 0, D3DCOLOR_COLORVALUE(1.0f,1.0f,1.0f,1.0f)}, {-1.0f,-1.0f, 1.0f , D3DXVECTOR3(-1,0,0), 0, 1, D3DCOLOR_COLORVALUE(1.0f,1.0f,1.0f,1.0f)} };

Share this post


Link to post
Share on other sites
Advertisement
Are you using an index buffer? Might you have filled the wrong indices in? It looks like the normals are wrong but your vertices look ok hence my question.

Share this post


Link to post
Share on other sites
I must say, it makes quite an interesting lighting effect. Maybe that can be put to good use in a special effect.

Share this post


Link to post
Share on other sites
I'd definitely go with the idea that the normals are incorrect.

Just by looking at the image you have you can tell which verticies are wrong if you know where the light is (I know you gave code, but the cube is rotated!), areas approaching/including corners that are BLACK are those that have normals facing away from the light, those that are bright RED are facing towards the light. Obvious, I know, but if you look at it analytically you can probably work out which bits of data to check...

Alternatively...

It's not a huge amount of extra work to visually display the normals for a mesh (or VB/IB pair), a D3DPT_LINELIST where, for each pair, the first vertex is that from your mesh, and the second vertex is the first + normal. If you can sort that out you might be able to visually work out which ones are wrong and how you need to change them [smile]

hth
Jack

Share this post


Link to post
Share on other sites
Wzup Halsafar. You remember me from VBForums. Yeah I believe your normals are wrong too. Especially that polygon on top since it looks very dark where it's supposed to be lit.

Share this post


Link to post
Share on other sites
As I do have to agree completly, the lighting effect was very far out, you should have seen what attentuation changes did and moving...weird stuff...weirder answer. Ironically some people on VBForums also agreed that the lighting effect was "Unique".

I do not know why this a problem, but it fixed it all.
It was all in the order I was defining my VERTEX structure. I had no idea the D3D Pipeline was picky about which comes first.


struct VERTEX_SINGLE {
float x,y,z;
D3DXVECTOR3 vNormal;
float tu,tv;
DWORD diffuse;

enum FVF
{
FVF_Flags = D3DFVF_XYZ | D3DFVF_NORMAL | D3DFVF_TEX1 | D3DFVF_DIFFUSE
};
};
Cause's massive errors within texturing and lighting.


struct VERTEX_SINGLE {
float x,y,z;
D3DXVECTOR3 vNormal;
DWORD diffuse;
float tu,tv;

enum FVF
{
FVF_Flags = D3DFVF_XYZ | D3DFVF_NORMAL | D3DFVF_DIFFUSE | D3DFVF_TEX1
};
};
This works just fine.


Do not ask me why but I made NO other changes except to the order of the cube vertices I posted above.

Now, it all looks great, 100% great.
So if anyone could be so kind, inform me of how these normals could be off?
Someone wish to correct them for me?

In QUADS -- FRONT, BACK, TOP, BOTTOM, LEFT, RIGHT -- is I believe the order I posted above. What should the correct normals be.

Share this post


Link to post
Share on other sites
Yeah, there is a very specific way to define a custom vertex. You can see the order here

Share this post


Link to post
Share on other sites
Guest Anonymous Poster


TEX1 valuses are supposed to be floats ???????

0.0f 1.0f

Share this post


Link to post
Share on other sites
Yeah, they're on a scale of 0.0f to 1.0f. Top left of the texture is (0.0f,0.0f) and bottom right is (1.0f,1.0f). Increasing these beyond 1.0 tiles the textures I believe. For example, if you had a quad with 4 vertices where the top left had texture coordinates of 0.0,0.0 and the bottom left had 0.0,2.0 and the top right was 2.0,0.0 and the bottom right was 2.0,2.0 you would see your texture tiled 4 times on the quad. At least I remember that being what happens, but its been a while. Someone correct me if I'm wrong.

Share this post


Link to post
Share on other sites
I´d say that´s right.... and I couldn´t imagine any other USEFUL variable type for the UV-coordinates?

Share this post


Link to post
Share on other sites
Quote:
Original post by njpaul
For example, if you had a quad with 4 vertices where the top left had texture coordinates of 0.0,0.0 and the bottom left had 0.0,2.0 and the top right was 2.0,0.0 and the bottom right was 2.0,2.0 you would see your texture tiled 4 times on the quad. At least I remember that being what happens, but its been a while. Someone correct me if I'm wrong.

You're correct about the tiling.

It's a little bit more involved as you can set the type of mirroring (wrap/mirror etc..) and it is limited by the hardware - which specifies the number of times it can wrap/tile a texture (I forget the exact caps for determining this).

Quote:
I couldn´t imagine any other USEFUL variable type for the UV-coordinates?

As of current floating point texture coordinates are, as you say, the only useful data type. However, it might be interesting to see what happens with the next shader model (presumably SM4) as there is talk of having native integer arithmetic, which could well make use of (or simply allow) integer texture coordinates. Pure speculation mind [smile] - I'm not sure there are many applications for integer coordinates.

Jack

Share this post


Link to post
Share on other sites
Quote:
Original post by jollyjeffers
It's a little bit more involved as you can set the type of mirroring (wrap/mirror etc..) and it is limited by the hardware - which specifies the number of times it can wrap/tile a texture (I forget the exact caps for determining this).


check out MaxTextureRepeat, but it is also determined by if the hardware scales the floating point value to a texel position before or after interpolating the coordinates across the polygon. This is determined by the cap D3DCAPS9.TextureCaps & D3DPTEXTURECAPS_TEXREPEATNOTSCALEDBYSIZE

Quote:
I couldn't imagine any other USEFUL variable type for the UV-coordinates?


vertex and pixel shaders can decompress or otherwise reconstruct a packed real value, for example. if bandwidth (or memory) is a problem, but you have lots of vertex/pixel processor power - turn your 8 byte U,V coords into 4 byte packed fixed point, or something similar. check out D3DDECLTYPE for a list of the many, many supported variable formats that you could use in your app.

Share this post


Link to post
Share on other sites
All very interesting stuff, mostly stuff I examined in my last progression from Dx7 to Dx9 which was the differences in textures.

Anyway, if anyone is curious this is how my cube looks now, the normals are still as I set above so I don't see why they could be wrong.




Thanks for everyones help and the nice discussion at the end was very interesting. I must say tho, floating point texU and texV coords are there for many reasons, one being it is super SIMPLE, so I hope that doesn't change for awhile.

Share this post


Link to post
Share on other sites
Sign in to follow this  

  • Advertisement