The Stack Overflow podcast is back! Listen to an interview with our new CEO.
11

The main purpose of tesselation is to increase the resolution of the mesh, while only transferring a small amount of triangle data around. In addition, tessellation allows you to dynamically change the LOD of the mesh, so you can optimize your shader calls. So, we can pass the GPU, say, 3000 triangles, and have it tesselate it to 300000 triangles. We are ...


10

As far as I know, this sort of thing is mainly about shader compilation. One of the main reasons why a game may experience hitches the first time something renders is that the shaders necessary to render it haven't finished compiling yet, and the driver has to finish that work before the frame can proceed. A little bit of background. When you write shaders ...


8

Jittering and dithering are both techniques of adding noise to reduce visible artefacts (such as banding) in an image. They solve different kinds of artefacts so they are used in different situations. Jittering moves sample positions in space to reduce artefacts caused by regular sampling. Dithering changes the way colours are rounded (when reducing ...


7

I believe a common solution is to split the camera transform used to project the grid from the camera transform that is used to render the grid. At perspectives close to top-down, the two cameras coincide, but as the viewing camera gets close to a horizontal perspective, the projection camera deviates and tries to keep a minimum inclination, i.e. it hovers ...


7

This effect is called light bloom. Its algorithm is usually a variation of the following: Render your scene (preferably in high dynamic range) to texture. Make a thresholding pass to another texture. I.e. pixels whose brightness is below a certain (configurable) threshold are are turned down to black. Downsample and blur the thresholded pixels. Usually, ...


6

When I implemented real-time area lighting, there were two documents I kept referring to: "Moving Frostbite to PBR" by Sebastien Lagarde and "Real Shading in Unreal Engine 4" by Brian Karis. Also "Lighting of Killzone Shadow Fall" by Michal Drobot is an interesting read on the topic. None of these documents deal with area shadows though but focus on energy ...


6

You can be both realistical and real-time. the secret is to change representation each time the information get under the Shannon-Nyquist (i.e. grid) scale: from geometry to normal maps to shading models. This paper is made for you: http://maverick.inria.fr/Publications/2010/BNH10/index.php (see also Yoube videos)


6

They represent the same operation, but Sample is what it's called in D3D10 and newer versions of HLSL, while tex2D is what it's called in D3D9 HLSL, and NVIDIA's (defunct) Cg language. By the way, the operation is also called texture in GLSL.


5

There seems to be some confusion of terminology here. In Direct3D, you have threads and thread groups. "work item" and "work group" are generally encountered in OpenCL terminology, where a "work item" would be what a thread is in Direct3D and a "work group" corresponds to a Direct3D thread group. groupshared memory is memory accessible to all threads that ...


5

For an introduction, you can give a look at: Ray Tracing from the Ground Up (Amazon link here). It starts really from the basics, and provides simple implementations for the concepts that are gradually introduced.


5

While this MSDN page does claim that SV_RenderTargetArrayIndex can be written in a pixel shader, I believe this is incorrect. Viewport array index and RT array index values are both intended to be output by the geometry shader stage. They can then be read by the pixel shader (and have a constant value per-primitive, based on the GS output). However, it is ...


5

As far as I'm aware there's no way in either DX or GL to re-use RT 0's alpha for all the blending operations. Unfortunately, it doesn't seem to be something that's supported by hardware. You can configure different blend modes for each render target, or enable blending for some and disable for others; however, if blending is enabled for a render target, it ...


4

I went looking for an answer, so I downloaded AMD's shader analyzer to view the assembly produced when compiled for GCN. In the assembly below vector registers are v# and scalar registers are s#. It would appear that the uniforms even vector uniforms are passed into the shader as separate scalars, so a vec3 would use 3 scalar registers. The bit I found ...


4

Found the solution, it turns out the lightVec is not the vector of light from the tube but rather the direction the tube will point. Therefore i will need to pass it a light rotation value to be used there. Results:


4

Why is this feature present in OpenGL/Vulkan and not Direct3D/Metal? It's present in OpenGL because someone thought it would be a good idea, wrote an OpenGL extension specification for it, released and supported the extension in their drivers, and the extension was eventually adopted into core profile. While it's usually pretty obvious why feature X is ...


3

It depends on your GPU. "Tiled renderers" do this for you so the benefit of doing it yourself is minimal (unless you have some more efficient way of knowing the order, e.g. sorting a fixed-viewpoint scene in advance). In this case, your best way of keeping efficiency is by ensuring they are allowed to draw the scene all in one go by avoiding glReadPixels and ...


3

Not a book, but here's an online write-up about the basics of Monte Carlo path tracing: Path Tracing – Getting Started With Diffuse and Emissive | The blog at the bottom of the sea I've also heard good things a out Peter Shirley's books. In particular "Ray Tracing in one Weekend" Ray Tracing in One Weekend (Ray Tracing Minibooks Book 1) Kindle Edition ...


3

Your ambient lighting contribution is missing from the second one (:


3

A very novice mistake, I was compiling with the old HLSL compiler. But why would that be the default? Very strange. For anybody wondering, just right click the HLSL file in the solution explorer and go to properties -> HLSL Compiler -> General, and switch Shader Model to the one you want which was newest one for me (5.0)


3

You have not set a viewport with RSSetViewports. You need to set this to the pixel dimensions of your render target. Without this the viewport will be set to 0,0,0,0 meaning no pixels will be touched. Additionally you have not set a raster state or blend state. It is good practice to set these and can be helpful early on to set the winding order in the ...


3

Some software like Maya, solve this by using a polar (or actually cartesian that turns polar at a distance) much in the same way as you grid centered on the camera position. This setup adds more detail where it counts most Then they rely on the shaders normal processing at further ranges. There is room for improvemenet offcourse. You cold modify this ...


2

The technic what Benedikt mentioned is explained in Section 2.4.1 of this thesis. http://fileadmin.cs.lth.se/graphics/theses/projects/projgrid/projgrid-lq.pdf Implementing this should solve your problem.


2

I can't believe it has taken me this long to find this... So the array I was giving the Index Buffer Desc that contains the data was the wrong one... It was a blank one that I forgot I didn't need, the vector if you look at the code. Look at that garbage. Those are supposed to be the indices... Well at least I know how to use the debugger now, thanks guys ...


2

It looks to me like you want a buffer containing a single array of integers (not a buffer containing multiple arrays, whatever that would mean). So, you should be able to just do this: RWBuffer<int> indices; then access it like this: indices[int(id.y)]


1

I found the problem. By zeroing the sampler description I implicitly set LOD bounds to 0. After adding descSampler.MinLOD = 0; descSampler.MaxLOD = D3D11_FLOAT32_MAX; the mipmap works as expected. Thank you for your attention :-)


1

I found out that simply removing minus sign in shader in converting coords to [0, 1] solved direction problem. But scale is still off - here is an example: void LightClass::GenerateViewMatrix() { XMVECTOR eyePos = { m_position.x, m_position.y, m_position.z }; XMVECTOR focusPos = { m_lookAt.x, m_lookAt.y, m_lookAt.z }; XMVECTOR upVec = { 0, 1, 0 }...


1

I've actually managed to find problem thanks to @PaulHK, thanks! I decided to pass which face I am currently working on and setting then coordinates manually per face. It is awful but it works rather good and since it is prefiltered and not done in runtime I found it good enough: [branch] if (g_upVectorVal.z == 1.0f) { input.position.z = -1.0f; } [...


1

Because I was using the CheckFormatSupport wrong. The second parameter is supposed to be an input. Here is what it should be like. bool Renderer::InitRenderer(HWND hwnd) { if (!InitD3D11App(hwnd)) return false; InitViewport(); UINT formatSupport; HRESULT hr = d3d11Device->CheckFormatSupport(DXGI_FORMAT_R16_FLOAT, &formatSupport); ...


1

Problem XMMATRIX and XMVECTOR (which use __m128 under the hood) require 16 byte alignment. The C++ compiler can automatically ensure this for XMMATRIX and XMVECTOR data allocated on the stack, but can't ensure this for XMMATRIX and XMVECTOR data allocated on the heap. In your specific situation (referring to the RasterTek tutorial), three member variables ...


1

float3 DirectDiffuseBRDF(float3 diffuseAlbedo, float nDotL) { return (diffuseAlbedo * nDotL); } float4 PS(VS_OUTPUT input) : SV_TARGET { input.normal = normalize(input.normal); float4 diffuseAlbedo = ObjTexture.Sample(ObjSamplerState, input.TexCoord); float nDotL = dot(input.normal, light.dir); float3 diffuseLighting = diffuseAlbedo * ...


Only top voted, non community-wiki answers of a minimum length are eligible