Tag Info

New answers tagged

0

You can't use SV_Position for this in hlsl, you should get the position from an other output slot without the SV_Position semantic instead. output.mPosition = float4(output.mTexcoord * float2(2.0f, -2.0f) + float2(-1.0f, 1.0f), 0.0f, 1.0f); output.mNewPos = output.mPosition; //use mNewPos in the pixel shader SV_Position is just for the rasterizer.


0

I don't think you can directly, but you might consider writing a simple preprocessor and creating a custom build step.


1

Mono should behave the same way as .Net and the MSDN has this to say on preprocessor instructions ... When the C# compiler encounters an #if directive, followed eventually by an #endif directive, it will compile the code between the directives only if the specified symbol is defined. Unlike C and C++, you cannot assign a numeric value to a symbol; the #if ...


0

You can create a polygon that captures everywhere the light can reach. Drawing a light (with shadows) then only requires one draw call and no render target switches. The basic set-up is: Draw everything than can be lit For each light Compute the polygon of where the light can reach Draw the polygon using additive blending I've wrote a small ...


1

So the short answer is to turn on the debug layer. Thanks to @Nathan Reed for pointing that out. I tested it out and verified that it does indeed detect when shader signatures are incompatible. I also verified that new SV inputs to a shader stage must come last in the list of inputs.


1

"Do as little work in the GS as is reasonable. The GS happens after the post-T&L cache, and you want to get as much out of that as possible. So do as much of your real transformation work as is reasonable in the vertex shader." (Source) In addition vertex shaders are always run on all vertices and if no vertex modification or transformation is required, ...


1

As per common practices, transformations from local object space to homogeneous clip space occur in the vertex shader while things which include manipulating the geometry data of an object as a whole happen in the geometry shader (like tesselation and particle effects). The vertex shader can handle only one vertex at a time. Thus it makes sense to do ...


2

The first formula you mentioned is not suitable for the result you want to achieve. I suggest the following formula instead: float3 n = abs(input.normal.xyz); float2 tileUV = float2(dot(n, input.pos3D.zxx), dot(-n, input.pos3D.yzy)); The n vector basically selects the side of the cube, as exactly one coordinate is 1, the others are ...


1

To do this, you must sample your alpha texture in the depth buffer creation fragment shader, which is ShadowCasterFP in your code. When you sampled the texture, you should discard pixels below a certain alpha level, or do a clip: if( color.a<0.1 ) discard; clip( color.a<0.1?-1:1 ); //where color is your sampled texture at the current fragment ...


0

Turns out, the depth values were correct the whole time. I was looking at a bad image for reference, where objects would get darker as they got further away from you. Of course, this is completely incorrect. After seeing how crazy normal depth precision is, I decided to use my own linear depth, which worked much better for shadow mapping.


2

Texture Coordinates are usually expressed in the range between [0,1]. Each (textured) vertex will have these coordinates. These coordinates are mapped to texels in the actual texture. [0,0] is the top left corner, [1,1] the bottom-right corner. When the coordinates are in a range that is multiple of 1, the texture will repeat itself. For example, for a ...



Top 50 recent answers are included