turanszkij

Members
  • Content count

    31
  • Joined

  • Last visited

Community Reputation

369 Neutral

1 Follower

About turanszkij

  • Rank
    Member

Personal Information

Social

  • Twitter
    turanszkij
  • Github
    turanszkij

Recent Profile Visitors

2067 profile views
  1. Sky Domes

    I don't like the zero init as well for some time now. Not for perf reasons, but this way the compiler can't warn you against uninitialized vars and you can easily miss them. Justhard to get down to refactoring it The maincamera stuff can be confusing. The small camera constant buffer is responsible of rendering the scene for multiple cameras, while the post processes are using the main camera buffer. The Prev and inverse camera properties only matter for the post processes, the other passes, like reflection and shadow pass can't generate velocity buffers for instance for which the prev camera is required. I expect that this maybe has some bugs and oddities which were not found yet by me. I haven't a clue about tbe scale factor, you should experiment with it a bit and share the results
  2. Sky Domes

    Oh yes, I see. You could just scale the sphere in the vertex shader by multiplying the vertices' y coord by something less than 1 before projection. This way the same icosphere can be reused in multiple shaders. I'm not doing the scaling though.
  3. Sky Domes

    Just a plain old icosphere, which I am also using for deferred lights and debug geometries as well. What do you mean by stretching?
  4. Sky Domes

    I tried the full screen quad approach but I found that with icosphere geometry, you have oportunity for more effects, like simulating weather effects depending on height of vertex, etc. I am using a simple array of vertices from inside the shader, see this file. It gets compiled into an "immediate costant buffer" in hlsl. You should just call Draw(240) with a triangle list topology without the need of a vertex or index buffers. You vertex id (SV_VERTEXID) semantic in the vertex shader directlz indexes into the arraz and you have your position. Just don't transform it with the world matrix, and leave the translation while transforming with the viewprojection by setting the position's w component to zero. You can see an example here. The GPU probably doesn't care anyway if you draw 240 vertices or 6 for full screen quad in the VS. Maybe the pixel shader does, but that would be heavier with the full screen quad for the same effect anyway.
  5. Normal mapping usually works like this: You have a normal map which is a texture containing tangent space normal vectors in the red and green components (XY). You have to transform it to world space (XYZ) and replace your vertex normal with this. All your following light calculations should use this new normal vector. That's it. The trickiest part is the basis transformation from tangent space to world space which you have to do in the pixel shader. Usually games provide tangent and binormal (also called bitangent) vectors in the vertex buffers for the mesh. Or just store the tangent and calculate the bitangent like this: bitangent = cross(normal, tangent) For calculating tangent vectors for the vertices, there is an open source library called mikktspace written in C++. You can derive a C# implementation if there is not one already available. An other option is that you can provide a quaternion representing the tangent space. And the final option is that you can calculate the tangent space inside the pixel shader from screen space derivatives, like this. When you have you normal, tangent and binormal vectors, which are unit vectors, you can assemble the tangent space transform matrix like so: tangentBasis = float3x3(tangent, binormal, normal) If you multiply your tangent space normal vectors which came from the normal map texture, you get the world space normal vector.
  6. TextureCube sampling

    No.
  7. Shadow Mapping

    Thank you guys, very interesting, now I have to try it!
  8. Shadow Mapping

    I mean that there will be edges that do not connect with an edge when the cube gets unwrapped to the 2D texture.
  9. Shadow Mapping

    Good idea, but what about unconnected faces? I imagine there would still be a bunch of branches to determine where we should sample in that case.
  10. Shadow Mapping

    This is interesting, I've seen other games do this. A few questions come to mind, like wouldn't sampling a cubemap texture be more efficient? I heard that AMD GCN already does the cubemap sampling as regular tex2d samples, but is that the same with NVidia? Is there some open-source implementation of that sampling? And what do you mean by advantages in caching, clearing, filling and filtering? I don't see any such trivial upsides to this (apart from the dynamic shadow resulotion you mentioned later), but the complexity of the implementation definetly increases.
  11. Fifth Engine

    I've heard about automatic science research paper generator, now it seems there is one for game engines, too.
  12. The upside is that you skip the IA->VS->RS->PS->OM pipeline with all the state setup involved and instead you have a simple CS pipeline. In the compute shader, it is you who assingns the workload, so there should be no confusion as to how the threads are dispatched. CS pipeline can sometimes be run in parallel with the graphics pipeline in newer APIs (I've no experience with that yet). The downside is that if you are running CS on the graphics pipe, you have to switch execution from the rasterizing pipeline to compute which involves flushing the graphics buffer, then executing your compute, waiting for it to finish and resuming your graphics processing after that
  13. On AMD hardware, it is a simultaneous dispatch of 64 threads if I am not mistaken. The number also add up for that: 1280*720/64 = 14400 On Nvidia, these are called warps and stands for a group of 32 threads.
  14. You will still need a correct topology, that is something you can't unbind. You are probably good with the input layout reflected from the shader, though I am not used to doing that. I have few layouts which I create by hand and shared across different shaders. A full screen triangle is also good for unpacking the deferred G-buffer, and even better than a quad because a quad has worse pixel occupancy along the intersection of triangles. This means that the pixel shader could be running on pixels which will be discarded later (these are called helper pixels because pixel shaders actually run in 2x2 pixel blocks so that derivatives can be obtained for instance). Though it probably is not a real problem.
  15. DX11 Resolve a Depth/Stencil buffer

    You can resolve it and keep using it as a depth buffer if you do the resolve in a pixel shader. Do a full screen pass, read your samples of the shader resource view of your MSAA depth buffer with Texture2DMS.Load(). The last argument of the Load is the sample index, as mentioned in the above answer. Now, you probably want to take either the max or the min of the loaded samples. Output the final value as a depth export instead of color write. For that, you should declare your pixel shader output with the SV_Depth semantic instead of SV_Target. On the C++ API side, you want to turn off your depth testing but depth writing should be ON. For that, you should create a depth stencil state object with a descriptor like this: D3D11_DEPTH_STENCIL_DESC dsd; dsd.DepthEnable = true; dsd.DepthWriteMask = D3D11_DEPTH_WRITE_MASK_ALL; dsd.DepthFunc = D3D11_COMPARISON_ALWAYS; dsd.StencilEnable = false;