Tag Info

New answers tagged

1

By design, DirectXMath returns for XMQuaternionSlerp the same result as you'd get from the following (inefficient used only for testing) scalar code: XMVECTOR ScalarQuatSlerp(XMVECTOR q1, XMVECTOR q2, float t) { // Extract the components float q1x = XMVectorGetX(q1); float q1y = XMVectorGetY(q1); float q1z = XMVectorGetZ(q1); float q1w = ...


1

COLOR0 is DX9. Since you're dealing with DX11 (ps_5_0) you need to replace COLOR0 with SV_Target.


0

I think I have fixed it. I am using DirectX Tool Kit as well, and now that I got the graphics debugger to work, I noticed that the depth testing was being disabled. I can only assume it is a result of using SpriteBatch to render text and other 2D components. So simply setting the depthStencilState at the begining of my render function, it fixed it.


0

I'm not sure what you mean 'these equations'. I think you mean the inputs into equations. I would store rotations as quaternions (x,y,z,w) as mentioned. Interpolating from a key-A to key-B would use a slerp or nlerp function (http://keithmaggio.wordpress.com/2011/02/15/math-magician-lerp-slerp-and-nlerp/). Translation is stored as x,y,z and uses a simple ...


0

You could define your "look at" point to be the same as current position. In this case, this line: XMVECTOR w = XMVector3Normalize(XMVectorSubtract(L, P)); will give you zero vector as forward direction, then you'll use it and of course there will be no movement Simple example: you're at (0, 0, 0) and your look at point is (0, 0, 0) Another possibility ...


0

False alarm, my apologies. I was passing the number of texels to the initial data struct's row-stride field, rather than the number of bytes. By pure unlucky coincedence, the other unit tests I had on this area were using single-element 8-bit texel formats, which meant I was getting really lucky (as the texel count and the byte count were the same). ...


0

this looks like a depth encoding precision issue. check your near and far. this is just causing some steps because the quantization is bad, your AO is evaluating corners where there are none. I doubt the problem is caused by ddx and ddy where I first (and I guess you too) suspected, because the patterns are rotating ! this is impossible with ddx, you would ...


4

Ok, given the wireframe view, it is clear that your problem is T-junctions. Remove them and the artifacts will go away. If you provide information on how you get/generate the meshes, you could get help on how to remove them as well :)


1

You don't specify what rendering method you want to use. Standard rasterisation of a 3D mesh? Or do you have a volume representation of the model and your renderer uses that directly? If you render a volume, check this: http://http.developer.nvidia.com/GPUGems/gpugems_ch39.html especially 39.2. The effect in the picture you provide is mainly subsurface ...


0

Technically, that's a gap, not an overlap. An overlap would not result in the background colour. So, two of the vertices that are supposed to be in an identical position, are not. If you can't combine the meshes, then make sure that the values are exactly the same (all bits equal). That means being very careful of what values you store in you vertex ...



Top 50 recent answers are included