Jump to content
  • Advertisement
  • entries
    707
  • comments
    1173
  • views
    435838

Untitled

Sign in to follow this  
Programmer16

73 views

Well, I was pretty unmotivated today. I pretty much just laid on the floor all day staring at the TV. I went to settle into my normal routine (switching back and forth between TLCoM and Project Asrion, but we seem to be having issues with the network or something (I got halfway through an update and had some conflicts. So I resolved them and then the network dropped or something.) So, I decided to just do a few things on Project Asrion and head to bed.

So, I implemented ray-picking for objects:

Selected Meshy



Selected MeshyJr


And since that only took a few minutes I decided to move onto lighting. That didn't turn out so well[sad]. I think the problem is in the mesh or something (screwed up normals; maybe not though.) Anyway, in the following screenshots, the light moves to the selected mesh:




Or, then again that may be how it should look. I haven't had much practice with lights.

My lack of 3D knowledge is really becoming a roadblock lol. For instance, when my camera moves into the negative Z, all of my meshes disappear and I have no clue why lol.

Edit: I'm thinking the above problem has to do with my camera code (duh, right?) Anyway, I do have something really wierd going on:

D3DXMATRIX ViewMatrix, RotX, RotY, RotZ;
D3DXMatrixRotationX(&RotX, D3DXToRadian(CameraYaw));
D3DXMatrixRotationY(&RotY, D3DXToRadian(CameraPitch));
D3DXMatrixRotationZ(&RotZ, D3DXToRadian(CameraRoll));

D3DXVECTOR3 Movement = D3DXVECTOR3(0.0f, 0.0f, 0.0f);

if(this->KeyStates[VK_LEFT] || this->KeyStates[VK_NUMPAD4])
Movement.x += (1.0f * (1.0f / DeltaTime));

if(this->KeyStates[VK_RIGHT] || this->KeyStates[VK_NUMPAD6])
Movement.x -= (1.0f * (1.0f / DeltaTime));

if((this->KeyStates[VK_UP] || this->KeyStates[VK_NUMPAD8]) && !this->KeyStates[VK_CONTROL])
Movement.y += (1.0f * (1.0f / DeltaTime));

if((this->KeyStates[VK_DOWN] || this->KeyStates[VK_NUMPAD2]) && !this->KeyStates[VK_CONTROL])
Movement.y -= (1.0f * (1.0f / DeltaTime));

if((this->KeyStates[VK_UP] || this->KeyStates[VK_NUMPAD8]) && this->KeyStates[VK_CONTROL])
Movement.z -= (1.0f * (1.0f / DeltaTime));

if((this->KeyStates[VK_DOWN] || this->KeyStates[VK_NUMPAD2]) && this->KeyStates[VK_CONTROL])
Movement.z += (1.0f * (1.0f / DeltaTime));

D3DXVec3TransformCoord(&Movement, &Movement, &(RotX * RotY * RotZ));
CameraX += Movement.x;
CameraY -= Movement.y; //<-- THIS LINE
CameraZ += Movement.z;


Okay, with that code, when I press up or down, it slides just how I want it to. It moves according to the angle of the terrain (it goes toward and away from the terrain, instead of up and down.) BUT, if I change it to +=, it does move up and down.
Sign in to follow this  


5 Comments


Recommended Comments

Welcome to 3D :). Might want to check what your near and far planes set at and make sure you're not just clipping out the meshes as you are moving away.

Share this comment


Link to comment
That lighting actually looks correct.

Here's what's happening. You are doing vertex lighting. You are calculating the light value at each vertex using the vertex normal. The vertex normal is an average of the surface normal of every face that shares that vertex. Therefore, those edges closer to the camera point towards it, and those farther away point away. If, instead of using the vertex normal, you used the surface normal, you should see correct results. Are you using OpenGL? If so, prototype it in immediate mode before you switch it back to vertex buffers.

All in all, I can tell you why it looks like that, but can't tell you anyway to fix it other than 'draw in immediate mode and calculate the vertex lighting yourself' because I never got anything 3d out of the experimentation stage, and I always used immediate mode stuff.

Share this comment


Link to comment
Quote:
Original post by Deyja
That lighting actually looks correct.

Here's what's happening. You are doing vertex lighting. You are calculating the light value at each vertex using the vertex normal. The vertex normal is an average of the surface normal of every face that shares that vertex. Therefore, those edges closer to the camera point towards it, and those farther away point away. If, instead of using the vertex normal, you used the surface normal, you should see correct results. Are you using OpenGL? If so, prototype it in immediate mode before you switch it back to vertex buffers.

All in all, I can tell you why it looks like that, but can't tell you anyway to fix it other than 'draw in immediate mode and calculate the vertex lighting yourself' because I never got anything 3d out of the experimentation stage, and I always used immediate mode stuff.


I figured it had something to do with the normals, but I was thinking that the tiles further back should be all black, not partially lit. I'm not really going to worry about it right now, once I implement my shader system I'll fix it since I'll probably do lighting via shaders.

I'm using Direct3D not OpenGL.

Thanks! And btw, I'm still working on your tiles. Sorry it's taking so long =/.

Share this comment


Link to comment
Quote:
Original post by MARS_999
Maybe you should move to GL! :) Join us and see what you have been missing!


I already know what I'm missing. Horrible C style syntax and a lack of OO design. No thanks, I'll stick with Direct3D[razz].

Seriously though, I had plans to learn OpenGL after I finish my projects.

Share this comment


Link to comment

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
  • 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!