Tag Info

New answers tagged

1

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


0

The problem is that L.Direction vector is not normalized, so the dot product "max(dot(v, toEye)" is calculating |v|*cos Θ instead of cos Θ, which is not what we want. So normalizing it on CPU side solves the problem. Thank you @snake5 for helping me on chat with it.


0

Fundamentally, if you want objects that are in a hierarchy relative to a parent, you need to do a concatenation of the local-to-parent transform with the parent. This is how it works. I see now way around it, and I wouldn't describe it as 'visual tricks' - that's how a transform hierarchy works. Objects have orientations and positions in world space, but if ...


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 ...


2

Your input layout defines POSITION as R32G32B32_FLOAT but Vertex's first member is an XMFloat4. This results in garbage in the TEX input. To fix the problem, switch to a XMFloat3 for the Vertex position member. Also, the offset for your NORMAL is set to zero - this should be D3D11_APPEND_ALIGNED_ELEMENT as well.


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). ...


2

The compiler won't always put the ".xyz" of a hlsl variable into ".xyz" of a register, if that's what you're referring to - sometimes it will move between .xyz, .xyw, .yzw, or even between components in separate registers, depending on if it's some intermediate calculation value or not and how much register pressure there is. As far as I'm aware there's no ...


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 ...


1

I do it like this, so no divide in the PS. Vertex Shader code follows: struct VertextoPixel { float4 pos : SV_POSITION; float2 tex : TEXCOORD0; }; VertextoPixel main(uint vI : SV_VERTEXID) { float2 inTex = float2(vI%2,vI%4/2); VertextoPixel Out = (VertextoPixel)0; ...


0

I did it! Well, kinda, at least I got it to draw a random line and not crash, which is a start :) m_pDeviceContext->PSSetShader(m_pPixelShader, 0, 0); m_pDeviceContext->VSSetShader(m_pVertexShader, 0, 0); Both of these lines might have been needed in my shader initialisation. I moved the mapping and unmapping into my gfx object and now the draw call ...


1

The key step that you're missing is the implicit slot assignment that occurs when you compile a shader. When you compile an HLSL shader that contains a bindable object (be it a Texture2D, RWStructuredBuffer, or cbuffer), each object must be assigned a slot number. This corresponds to the UINT StartSlot parameter to e.g. VSSetConstantBuffers. You can ...


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 :)


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