DX11 Camera Rotation in DX11

Recommended Posts

moodiez    103

Hi People :>

So I recently got started with DX11 and graphics programming in general. I followed tutorials and a book on how to understand and set up the basic stuff. At this point I've managed putting a colored cube in a grey window. I also implemented my own input system (mouse and keyboard) based on window messages.

Now I have come to implementing camera controls, and when I tried to rotate it I came across a problem. I have made it so that when I hold down the right mousebutton I enable rotating, and moving the mouse then rotates the camera based on how far the mouse-cursor has traveled since the last frame (pixels). Moving the mouse in either the horizontal or vertical direction alone creates no problem, but as soon as I do a circle-movement with the mouse, the camera starts spinning. So for a reason I don't know I get kind of a "rolling" of the camera in that situation. Does anyone have an idea why this is happening ?

The viewmatrix is being bult like this:

View = XMMatrixLookAtLH( EyePos, Focus, UpDir );


Update function of the camera, is being called every frame.

void Camera::Update()
{
if( fwd )
Forward();

if( back )
Backwards();

if( left )
Left();

if( right )
Right();

if( rotate )
{
Rotate();
View *= RotationX;
View *= RotationY;
}

cb.mView = XMMatrixTranspose( View );
m_pImmediateContext->UpdateSubresource( pConstantBuffer, 0, NULL, &cb, 0, 0 );
}



function that does the rotating, GetMouseDelta() returns how far the mouse has traveled since the last frame

void Camera::Rotate()
{
RotationX = XMMatrixRotationAxis( XMVectorSet( 1.0f, 0.0f, 0.0f, 0.0f ), -(float)pInput->GetMouseDelta().y*0.001f );
RotationY = XMMatrixRotationAxis( XMVectorSet( 0.0f, 1.0f, 0.0f, 0.0f ), -(float)pInput->GetMouseDelta().x*0.001f );
}

Edited by moodiez

Share on other sites
haegarr    7372

Your problem is probably caused by the order of transformations. First of, do you want to yield in a look-around rotation, in an orbiting around the focused object, or else (least probable) a rotation around the global origin? When rotation is applied, should it be done w.r.t. to some local or some global axes (I mean is it really yaw/pitch or do you want to spin around the global up direction regardless of any pitch)?

You further have to clarify whether you use row or column vectors. AFAIK the XMMatrixLookAtLH returns a row vector matrix. Then you multiply View with the incremental rotations you do it in an order that seems me odd. Then you're applying a XMMatrixTranspose onto the view matrix before transporting it to the shader script. I'm not familiar with D3D so my question is w.r.t. the transpose: Is this needed for the CBuffer and/or the shader script, or what is the reason for this?

Share on other sites
moodiez    103

Hi haegarr.

To answer your questions, I want to rotate the camera around its local axes, not around any other object or global axes. I want to create a "camera" which I can rotate around itself and later on impement to manipulate its position in world space.

The way I rotate the view at the moment works fine, as long as I only rotate it around ONE axis.

The transposing is needed to update the data-structure thats being passed ot the shader (world,view,projection matrices)

Thanks in advance for further help :)

Share on other sites
haegarr    7372

You must be aware that rotating around the x axis followed by rotating around the y axis is different from rotating around the y axis followed by rotating around the x axis. Hence, if you push the mouse 10 units to the right and then 10 unit upwards, the result will differ from pushing the mouse 10 units upwards and then 10 units to the right. If you move the mouse more or less diagonally and do so with relatively high speed, the result will differ from a movement in the same direction but with significantly lower speed. This is because in the first case you do e.g.

Ry(45°) * Rx(45°)

while in the latter case you do (assuming 1/3 of speed with 3 samples in time)

Ry(15°) * Rx(15°) * Ry(15°) * Rx(15°) * Ry(15°) * Rx(15°)

Notice that the above shows what is called incremental rotation, especially if the angles get really small. The smaller the angles the more independent the rotation. However, you cannot process with arbitrarily high speed, and you will not enforce the user to move the mouse really slowly.

When you look at your current solution you'll see that the axis of rotation is orthogonal to the direction of mouse movement: horizontal movement = upwards directed axis of rotation; vertical movement = sidewards directed axis of rotation. Generalizing this means that however the mouse is moved, the axis of rotation is the perpDot of the movement direction. It is perhaps worth a try (I'm not 100% sure of the success, though).

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

• Similar Content

• By isu diss
I'm trying to code Rayleigh part of Nishita's model (Display Method of the Sky Color Taking into Account Multiple Scattering). I get black screen no colors. Can anyone find the issue for me?

• By Endurion
I have a gaming framework with an renderer interface. Those support DX8, DX9 and latest, DX11. Both DX8 and DX9 use fixed function pipeline, while DX11 obviously uses shaders. I've got most of the parts working fine, as in I can switch renderers and notice almost no difference. The most advanced features are 2 directional lights with a single texture
My last problem is lighting; albeit there's documentation on the D3D lighting model I still can't get the behaviour right. My mistake shows most prominently in the dark side opposite the lights. I'm pretty sure the ambient calculation is off, but that one's supposed to be the most simple one and should be hard to get wrong.
Interestingly I've been searching high and low, and have yet to find a resource that shows how to build a HLSL shader where diffuse, ambient and specular are used together with material properties. I've got various shaders for all the variations I'm supporting. I stepped through the shader with the graphics debugger, but the calculation seems to do what I want. I'm just not sure the formula is correct.
This one should suffice though, it's doing two directional lights, texture modulated with vertex color and a normal. Maybe someone can spot one (or more mistakes). And yes, this is in the vertex shader and I'm aware lighting will be as "bad" as in fixed function; that's my goal currently.
• By Mercesa
Hey folks. So I'm having this problem in which if my camera is close to a surface, the SSAO pass suddenly spikes up to around taking 16 milliseconds.
When still looking towards the same surface, but less close. The framerate resolves itself and becomes regular again.
This happens with ANY surface of my model, I am a bit clueless in regards to what could cause this. Any ideas?
In attached image: y axis is time in ms, x axis is current frame. The dips in SSAO milliseconds are when I moved away from the surface, the peaks happen when I am very close to the surface.

Edit: So I've done some more in-depth profiling with Nvidia nsight. So these are the facts from my results
Count of command buffers goes from 4 (far away from surface) to ~20(close to surface).
The command buffer duration in % goes from around ~30% to ~99%
Sometimes the CPU duration takes up to 0.03 to 0.016 milliseconds per frame while comparatively usually it takes around 0.002 milliseconds.
I am using a vertex shader which generates my full-screen quad and afterwards I do my SSAO calculations in my pixel shader, could this be a GPU driver bug? I'm a bit lost myself. It seems there could be a CPU/GPU resource stall. But why would the amount of command buffers be variable depending on distance from a surface?

Edit n2: Any resolution above 720p starts to have this issue, and I am fairly certain my SSAO is not that performance heavy it would crap itself at a bit higher resolutions.

• In DirectX 11 we have a 24 bit integer depth + 8bit stencil format for depth-stencil resources ( DXGI_FORMAT_D24_UNORM_S8_UINT ). However, in an AMD GPU documentation for consoles I have seen they mentioned, that internally this format is implemented as a 64 bit resource with 32 bits for depth (but just truncated for 24 bits) and 32 bits for stencil (truncated to 8 bits). AMD recommends using a 32 bit floating point depth buffer instead with 8 bit stencil which is this format: DXGI_FORMAT_D32_FLOAT_S8X24_UINT.
Does anyone know why this is? What is the usual way of doing this, just follow the recommendation and use a 64 bit depthstencil? Are there performance considerations or is it just recommended to not waste memory? What about Nvidia and Intel, is using a 24 bit depthbuffer relevant on their hardware?
Cheers!

• By gsc
Hi! I am trying to implement simple SSAO postprocess. The main source of my knowledge on this topic is that awesome tutorial.
But unfortunately something doesn't work... And after a few long hours I need some help. Here is my hlsl shader:
float3 randVec = _noise * 2.0f - 1.0f; // noise: vec: {[0;1], [0;1], 0} float3 tangent = normalize(randVec - normalVS * dot(randVec, normalVS)); float3 bitangent = cross(tangent, normalVS); float3x3 TBN = float3x3(tangent, bitangent, normalVS); float occlusion = 0.0; for (int i = 0; i < kernelSize; ++i) { float3 samplePos = samples[i].xyz; // samples: {[-1;1], [-1;1], [0;1]} samplePos = mul(samplePos, TBN); samplePos = positionVS.xyz + samplePos * ssaoRadius; float4 offset = float4(samplePos, 1.0f); offset = mul(offset, projectionMatrix); offset.xy /= offset.w; offset.y = -offset.y; offset.xy = offset.xy * 0.5f + 0.5f; float sampleDepth = tex_4.Sample(textureSampler, offset.xy).a; sampleDepth = vsPosFromDepth(sampleDepth, offset.xy).z; const float threshold = 0.025f; float rangeCheck = abs(positionVS.z - sampleDepth) < ssaoRadius ? 1.0 : 0.0; occlusion += (sampleDepth <= samplePos.z + threshold ? 1.0 : 0.0) * rangeCheck; } occlusion = saturate(1 - (occlusion / kernelSize)); And current result: http://imgur.com/UX2X1fc
I will really appreciate for any advice!

• 22
• 15
• 18
• 10
• 18