Light Position in DX
Author
Regarding the lightposition in DX I am assuming it is like OpenGL where you move it around like vertices and it gets transformed if you don't position if first before you move anything else? As of now I am still learning DX and my light is following my cube, by that I mean my cube is moving around but the side of the cube is staying lit no matter what position its facing and its only that side... Thanks
Since you've not mentioned it, I'm assuming you're using the fixed function pipeline rather than shaders...
The positions and directions for D3D lights are always in world space, they don't get transformed.
<gazes into crystal ball>
What are your world (D3DTS_WORLD) and view (D3DTS_VIEW) matrices set to when you render the cube?
Could it be that the cube and light are staying still, and it's actually the camera that's moving?...
The MODELVIEW matrix in OpenGL is actually two separate matrices in Direct3D (D3DTS_WORLD and D3DTS_VIEW).
The WORLD matrix is only [usually] used for transforming from model [aka object] space (the space your cube vertices are defined in) into world space. The VIEW matrix is used for transforming from world space into view [aka camera] space.
If you'd passed in a ModelView type matrix as D3DTS_WORLD, and the View portion of that as D3DTS_VIEW, you'd see something a bit like you describe.
Actually, leaving D3DTS_WORLD at identity and setting D3DTS_VIEW to model*view may also give you the same problem (I forget which space the D3D fixed function pipeline performs diffuse lighting in, but if it's world space, then...)
The positions and directions for D3D lights are always in world space, they don't get transformed.
<gazes into crystal ball>
What are your world (D3DTS_WORLD) and view (D3DTS_VIEW) matrices set to when you render the cube?
Could it be that the cube and light are staying still, and it's actually the camera that's moving?...
The MODELVIEW matrix in OpenGL is actually two separate matrices in Direct3D (D3DTS_WORLD and D3DTS_VIEW).
The WORLD matrix is only [usually] used for transforming from model [aka object] space (the space your cube vertices are defined in) into world space. The VIEW matrix is used for transforming from world space into view [aka camera] space.
If you'd passed in a ModelView type matrix as D3DTS_WORLD, and the View portion of that as D3DTS_VIEW, you'd see something a bit like you describe.
Actually, leaving D3DTS_WORLD at identity and setting D3DTS_VIEW to model*view may also give you the same problem (I forget which space the D3D fixed function pipeline performs diffuse lighting in, but if it's world space, then...)
Author
Ok, I am still having a few issues with the way DX does its moving of objects around the scene... Does DX have to use the matrix method for translation, rotation, and scaling? or can I just call a function like in OpenGL to move my objects around? This form of manipulating objects seems like a lot of work vs. calling a function that takes care of it for you... Thanks BTW if anyone has a good tutorial on OpenGL to DX what I used to do for translations to how DX does them would be great...
If you're using shaders -- the way the shader works is likely to have a big impact on what you need to do to move objects around. Without the code - we can only guess what it is its doing...
It sounds like you're modifying the view matrix in order to move the cube. If that's the case, you need to be modifying the world matrix to move the cube, and the view matrix to move the camera, as Simon said.
You're also talking about lights, but they don't exist if you're using HLSL. Your code would really help sort things, I think.
It sounds like you're modifying the view matrix in order to move the cube. If that's the case, you need to be modifying the world matrix to move the cube, and the view matrix to move the camera, as Simon said.
You're also talking about lights, but they don't exist if you're using HLSL. Your code would really help sort things, I think.
Author
Quote:Original post by sirob
If you're using shaders -- the way the shader works is likely to have a big impact on what you need to do to move objects around. Without the code - we can only guess what it is its doing...
It sounds like you're modifying the view matrix in order to move the cube. If that's the case, you need to be modifying the world matrix to move the cube, and the view matrix to move the camera, as Simon said.
You're also talking about lights, but they don't exist if you're using HLSL. Your code would really help sort things, I think.
Well the code is here
OutputVS TerrainMultiTexVS(InputVS inputVS){ // Zero out our output. OutputVS outVS = (OutputVS)0; // Transform normal to world space. outVS.normal = mul(float4(inputVS.normal, 0.0f), matWorldInvTranpose).xyz; // Transform to homogeneous clip space. outVS.posHomogenous = mul(float4(inputVS.pos, 1.0f), matWorldViewProjection); // Transform to vertex to world space. float3 posWorld = mul(float4(inputVS.pos, 1.0f), matWorld).xyz; outVS.eyeWorld = eyePos - posWorld; // Pass on texture coordinates to be interpolated in rasterization. outVS.tiledTexC = inputVS.texCoord0 * 16.0f; outVS.nonTiledTexC = inputVS.texCoord0; return outVS;}float4 TerrainMultiTexPS(InputPS inputPS) : COLOR{ inputPS.normal = normalize(inputPS.normal); inputPS.eyeWorld = normalize(inputPS.eyeWorld); float4 terrainColor = tex2D(Tex0S, inputPS.nonTiledTexC).rgba; // Determine the diffuse light intensity that strikes the vertex. float s = max(dot(-lightVec, inputPS.normal), 0.0f); float3 diffuse = s*(diffuseMaterial*diffuseLight).rgb; float3 ambient = ambientMaterial*ambientLight; terrainColor *= float4(ambient + diffuse, 1.0); return terrainColor;}but the thing that is getting me is in OpenGL I needed to keep my matrix at the beginning of the frame set to Identity and then push pop matrices as need to move stuff around, now here it seems the identity is lost... I only set it once in the app and never again as I am doing this...
SetWorldXFormMatrixToIdentity();//this is for each object I set its world matrix to identity each frameswitch(order) { case 0://translation D3DXMatrixMultiply(&W, &T, &W); break; case 1://rotation D3DXMatrixMultiply(&W, &R, &W); break; case 2://scaling D3DXMatrixMultiply(&W, &S, &W); break; case 3://rotate and scale and translate D3DXMatrixMultiply(&W, &T, &S); D3DXMatrixMultiply(&W, &W, &R); break; default: break; } appFramework.matrixWorld = W; appFramework.shader->SetMatrix(appFramework.worldViewProjMatrixHandle, &appFramework.getWorldViewProjMatrix()); appFramework.shader->SetMatrix(appFramework.worldInvTranposeMatrixHandle, &appFramework.getWorldInverseTransposeMatrix()); appFramework.shader->SetMatrix(appFramework.worldMatrixHandle, &appFramework.matrixWorld); the thing that gets me is the appFramework.matrixWorld is never set to identity again after I setup my app I call D3DXMatrixIdentity() on matrixWorld and only once...
Author
I am also going to assume I don't need to call SetTransform() functions for projection, view, World anymore if I am using HLSL... Thanks
I don't understand. If you are using HLSL, you are basically doing everything yourself - DX doesn't do much with light position and such if you are using HLSL. Now if you were using the static pipeline, you'd do something like:
[pseudocode]
//Set light position and direction
LightPos = new Vector3(...);
LightDir = new Vector3(...);
// Draw a cube
device.World = CubeWorldPosition();
device.Begin();
DrawCube();
device.End();
[/pseudocode]
But if you are using the "programmable" pipeline, then YOU have to program it to do what you want, such as react to lighting as you want. Hope it helps.
[pseudocode]
//Set light position and direction
LightPos = new Vector3(...);
LightDir = new Vector3(...);
// Draw a cube
device.World = CubeWorldPosition();
device.Begin();
DrawCube();
device.End();
[/pseudocode]
But if you are using the "programmable" pipeline, then YOU have to program it to do what you want, such as react to lighting as you want. Hope it helps.
I can't see anything wrong with your code. Looks okay to me and I think it should work as long as the world matrix is what is being modified to rotate the object. If it's still not working, it might be something else.
As for setting the transformation matrices every frame, DX doesn't require that because it doesn't use a matrix stack (which I understand OGL uses).
In DX, you set a value to the matrix and override whatever was previously set. Since you should theoretically set the matrix before any draw call, setting it to identity and then setting it to a real value wouldn't make much sense.
Hope this helps.
As for setting the transformation matrices every frame, DX doesn't require that because it doesn't use a matrix stack (which I understand OGL uses).
In DX, you set a value to the matrix and override whatever was previously set. Since you should theoretically set the matrix before any draw call, setting it to identity and then setting it to a real value wouldn't make much sense.
Hope this helps.
This topic is closed to new replies.
Advertisement
Popular Topics
Advertisement
