• Advertisement
Sign in to follow this  

D3DXVec3Normalize

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

The D3DXVec3Normalize function isn't working for me. I put in vectors like this: D3DXVECTOR3(0.0f, 10000.0f, -2000.0f); and it gives me (0.0f, 0.0f, 0.0f). Not always, though. Every once in a while, one of the numbers will be 1. Did I set it so it rounds the floats to integers? Are the numbers too big or something? Please help!

Share this post


Link to post
Share on other sites
Advertisement
Some vectors are meant to be normalized (for instance, surface normals) and some vectors are NOT meant to be normalized (for instance, camera position in world space coordinates). That vector doesn't look like the type you should be normalizing in the first place. What are you using that vector for?

Share this post


Link to post
Share on other sites
D3DXVec3Normalize will handle your example vector correctly, so the problem must be somewhere in your code. Show us the code that returns the incorrect value and show us what the input values are that result in an incorrect value.

Share this post


Link to post
Share on other sites
I'm using the normal for terrain generation. Each quad of the terrain has a normal, which is generated from two vectors on the quad. The vectors are pretty big, so when I do a cross product, the normal is even bigger.

// build two vectors on the quad
D3DXVECTOR3 u = getUEntry(x, z);
D3DXVECTOR3 v = getVEntry(x, z);

// find the normal by taking the cross product of two
// vectors on the quad.
D3DXVECTOR3 n;
D3DXVec3Cross(&n, &u, &v);
D3DXVec3Normalize(&n, &n);
return n;

"getUEntry" returns one of the vectors on the quad, and "getVEntry" returns the other. "x" and "y" are the indices to the quad in the terrain. "n" looks fine all the way up to the point where it gets normalized.

Share this post


Link to post
Share on other sites
What values does n have when it enters D3DXVec3Normalize? Because your functions might make the crossproduct yeild a 0, 0, 0 vector and normalizing that would certainly result in a 0, 0, 0 =)

Share this post


Link to post
Share on other sites
Well, just try to make tiny console app and see what happens if you use d3dxvec3normalize... if everything's still 0 i'd suggest reinstalling the sdk :S

i just wrote 3 lines of code and well, no problems here

D3DXVECTOR3 vec(100000.f, -200000.f, 100000.f);
D3DXVec3Normalize(&vec, &vec);
printf("x:%f, y:%f, z:%f\n", vec.x, vec.y, vec.z);

Maybe someone haxxored your code and made a #define D3DXVec3Normalize Awww

D3DXVECTOR3 Awww(D3DXVECTOR3* out, D3DXVECTOR3* in) { return D3DXVECTOR3(0.f, 0.f, 0.f); }

You never know ^_~

Share this post


Link to post
Share on other sites
No, no one redefined D3DXVec3Normalize. I know because I also tried this:

n /= D3DXVec3Length(&n);

And it gave me the same thing. Maybe I'll try finding the length of the normal myself and see what happens.

[edit:] I also reinstalled the sdk =) didn't work.

Share this post


Link to post
Share on other sites
What do u and v look like just before the cross product is calculated? I'm not sure how it would handle that if they were the same vector.

EDIT: Nevermind, I just read that you said the normal looked fine going into the Normalize function.

Chris

Share this post


Link to post
Share on other sites
Just try writing a small app like i did and see if the functions work or not...

Share this post


Link to post
Share on other sites
Check for stack corruption around the code. This can be caused by incorrect pointer arithmetic, causing usage of wrong memory addresses (thus zeroing incorrect variables, maybe?).

Share this post


Link to post
Share on other sites
Quote:
Original post by evanofsky
I tried putting the code from the test app into the code in my game, and it just returned {0, 0, 0}. So there's some kind of setting... maybe D3DRS_NORMALIZENORMALS? I'll try messing with that a bit.
The D3DX vector and math library of functions don't access the device at all. So setting renderstates shouldn't affect anything.

As for the stack corruption, try declaring a large array (try 100,000 chars) before your vector, that should put the vector into stack space that hasn't been modified yet (in theory).
Also, try writing a function that normalises a vector and returns it, something like this:

D3DXVECTOR3 myNormalise(const D3DXVECTOR3& v)
{
D3DXVECTOR3 vRet;
D3DXVec3Normalize(&vRet,&v);
return vret;
}


See if that works.

Of course if either of those do work, then you'll obviously have to find out *why* they work, since it's going to be some kind of stack corruption. Don't assume "Oh, it works now, thats ok then", otherwise you're likely to get problems like this popping up in the future.

Share this post


Link to post
Share on other sites
Quote:
Original post by Evil Steve
Don't assume "Oh, it works now, thats ok then", otherwise you're likely to get problems like this popping up in the future.


Agreed 100%. Memory corruption errors are among the most evil errors available, because they can be random and seemingly consequence-free - yet able to bring a machine to a full stop unexpectedly (common when dealing incorrectly with device address spaces like locked hardware textures and such).

Share this post


Link to post
Share on other sites
Alright, I fixed it. This is gonna kill you all. I have a function that converts numbers to strings. I was using it to convert the x,y, and z components of the normal so I could make a MessageBox with the coordinates. Well, apparently the function didn't work, and it was giving 0s and 1s to me the whole time. The real problem was actually in my vertex shader!! I'M SO SORRY I TOOK ALL YOUR TIME!! Thank you for helping me, though!

Share this post


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

  • Advertisement