Jump to content
  • Advertisement


  • Content Count

  • Joined

  • Last visited

Community Reputation

14 Neutral

1 Follower

About CortexDragon

  • Rank

Personal Information

  • Role
  • Interests

Recent Profile Visitors

The recent visitors block is disabled and is not being shown to other users.

  1. CortexDragon

    When do we need multiple FBOs?

    Are you talking about the "frame buffers" technique described in the "Hello Frame buffering" sample within the microsoft dx12 Hello world sample ? https://github.com/Microsoft/DirectX-Graphics-Samples/tree/master/Samples/Desktop/D3D12HelloWorld The same technique is also used in many later microsoft samples. A better example is the multithreaded sample, where they use a Frameobject class https://github.com/Microsoft/DirectX-Graphics-Samples/tree/master/Samples/Desktop/D3D12Multithreading The idea is you have 2 (or 3) frame objects that you rotate between, each one with its own render target, commandlists, and also its own cbchangeseveryframe cbuffer. A simple reason to do it is because commandlists can take a few frames from the time you called executecommandlists to the time they have been completed on the gpu and you want to feed it the next frames commandlist before the previous ones fence indicates it has finished. It also helps you make sure the gpu is getting the correct frames contents of cbuffers that you change every frame. If you had used the same cbchangeseveryframe cbuffer amoung all frames then you may end up updating it from the cpu before the gpu has finished doing a commandlist that is using it. This is what D3D12HelloFrameBuffering.h says " // In this sample we overload the meaning of FrameCount to mean both the maximum // number of frames that will be queued to the GPU at a time, as well as the number // of back buffers in the DXGI swap chain. For the majority of applications, this // is convenient and works well. However, there will be certain cases where an // application may want to queue up more frames than there are back buffers // available. // It should be noted that excessive buffering of frames dependent on user input // may result in noticeable latency in your app. "
  2. CortexDragon

    SampleLevel only returns 0s

    Instead of textures of float4's 1 pixel wide, you could use a structured buffer of float4's, or even an array of float4's inside a cbuffer. But that wouldn't explain why its not working. My dumb question - I dont see where you specify the register of those textures or of the sampler. I would have expected something like Texture2D StrRect : register(t0);
  3. CortexDragon

    SampleLevel only returns 0s

    Try reading a pixel from the texture without using a sampler to see if the resource is visible to the shader or has anything in it. float4 pixel = StrRect[uint2(x,y)]; or use the Load method of the Texture2d object where x and y are the integer pixel coordinates ranging from 0 to the number of pixels in the texture - 1 Also try filling your texture with a solid color in case you just happen to be reading a black spot.
  4. This wont be necessary for unity, however I would read the 7 tutorials linked from on this page - https://code.msdn.microsoft.com/windowsdesktop/Direct3D-Tutorial-Win32-829979ef (the links are under the pictures of the tutorials) Those 7 tutorials basically teach you the fundamentals of directx 11 programming in C++, with shaders written in hlsl, but they are also good for understanding how graphics works irrespective of your language, especially tutorials 1 and 2 which explain drawing with shaders, and tutorial 4 which describes 3d spaces. You can also download the source code near the top of that page which you can run in visual studio (visual studio is free from microsoft if you get the community edition)
  5. Here is how i would do it In the vertexshader output structure have a float variable called "i_am_the_correct_vertex" This float variable will be set to 1 in the VERTEXSHADER if it matches the vertexid that you want. This float variable will be set to 0 in the VERTEXSHADER if it doesnt match the vertexid that you want. In the pixel shader you read the intertopolated value of "i_am_the_correct_vertex" Its value will range from 0 to 1. The closer it is to 1, the closer you are in its triangle to the vertex point that you want.
  6. CortexDragon

    Depth shadow mapping question

    As PCMaster mentioned on the 1st page, for depth buffers (such as your shadow texture) you should be using R32, not R32B32G32A32 Depth doesnt need the green,blue.alpha components. It needs to be able to store one 32 bit float.
  7. This is just a guess - You only need 1 device, but in theory you can have multiple queues. This is a comment from some tutorial code - "Swap chain needs the queue so that it can force a flush on it."
  8. CortexDragon

    Capture constantbuffer in commandlist

    Instead of having one constant buffer that is changed every frame, can you rotate between 2 (or even 3) constant buffers, so you have your alternate frames commandlists be bound to different constant buffers. This allows a constant buffers value once set to remain at that value for a certain number of frames, long enough for the commandlist that uses it to finish executing Basically the same approach that the tutorial dx12 samples use (They use 3 frame objects) Also remember any changes you make to one buffer eventually have to be made to the other frames buffers if you want those other buffers to also have that value. (keeping a single cpu copy of the buffer, making your changes to that, then copying that into the current frames buffer is the easiest way)
  9. Instead of having the pixelshader write to a rendertarget, you could have the pixelshader write to a texture UAV. It would allow your pixel shader to both read and write pixels. You may have to use interlocked functions. So if you want to set a certain bit on a pixel, you could InterlockedOr with a number that just has that bit set.
  10. CortexDragon

    Depth buffer resource, mipmaps

    Rather than the 2 stage process of buffer copying to your target resource, then later generating the mips on that target with a compute shader, you could do it in a single step by using the depth texture as a srv input for the compute shader and have that compute shader be responsible for both copying of the input srv's pixels to the highest level of the target texture and also creating the mips and write those to the target texture.
  11. CortexDragon

    One DescriptorHeap per frame buffer ?

    You dont need multiple descriptor heaps to give each frameobject a contineous region in a descriptorheap You can simply have each frameobjects unique buffers use a different region of the same big cbv/srv/uav descriptorheap Example: If I have a framecount of 3 (2 backbuffers and 1 front buffer). This means I have 3 frameobjects. I have 10 constant buffers for each frameobject I have 20 textures which are shared by each frame object I have 5 slow changing constant buffers that are shared by each frame object. The cbv/srv/uav descriptor heap is arranged like this: slots 0 to 9 are the 10 constant buffers views of the first frameobject slots 10 to 19 are the 10 constant buffers views of the second frameobject slots 20 to 29 are the 10 constant buffers views of the third frameobject slots 30 to 49 are the 20 textures shader resource views shared by all frame objects. slots 50 to 54 are the 5 slow changing constant buffer cbvs shared by all frame objects. I use an enum for my descriptor heap slots to help avoiding mistakes.
  12. I do picking in the pixel shader that I use to draw my objects, without using an additional pass. My code is dx11 or dx12, but you might be able to employ a similar technique in your language. I pass an "object number" down from the vertex shader to the pixel shader when i draw my objects. I send the mouse coordinates to the pixelshader in a cbuffer (its in my cbeveryframe buffer that is updated each frame) In the pixel shader, if the pixel coodinates are equal to the mouse coordinates, I construct a uint where the high 16 bits are the pixel depth and the low 16 bits are the data to send back, in this case data is the "object number" I then write this number to a uav buffer using an interlockedmin function. This causes the closest object at the mouse coordinates to have its "object number" to be written to the uav Then in the cpu I read this uav buffer (well actually a cpu-map buffer that I copied the uav to), and take the low 16 bits of the uint to get the object number. I send back various pieces of information about the object under the mouse back to the cpu using this techique by using different uint variables in that uav.buffer. That pixel shader is also used to draw the object after the above piece of code. Performance tip when sending things from the gpu to the cpu - dont try to read the same buffer in the cpu imediately after the cpu draw command that causes that buffer to be written by the gpu. Allow it a few frames by for example having 3 uav buffers (and their corresponding cpu-map buffers that they are copied to) that you rotate between. This is because the draw in the gpu doesnt occur imediately it is issued in the cpu.
  13. CortexDragon

    Handling World Transformations

    DX11 - I would do it the first way as it minimizes the number of buffer writes from the cpu to the gpu each frame. Have an array in the constant buffer, with one element per object Each array element is of a struct that contains any "per object information" such as world matrix, color, texturenumber etc If you have a large number of objects, the object element struct would instead be elements of a structured buffer, rather than using an array inside a constant buffer. Nvidia dx12 do's and dont's recommends the array inside the constant buffer rather than as elements of a structured buffer if you are using it from the pixel shader. In an ideal world you would also draw all of them together using a single draw command, rather than one draw per object, but that depends on how you do your vertexbuffer so may not be practical. ----- Vulcan - I dont know Vulcan. ----- DX 12 - If you are using executeindirect there is another option - You can store your per object information in a structured buffer in elements of size 512 bytes (or increments of that). Then you draw all your objects with a single call to executeindirect, and each draw call within it sets a rootparameter to cause a constant buffer view start position to point to the correct position of your structured buffer. This allows the gpu to see the current object being drawn as a single constant buffer.
  14. CortexDragon

    Wormhole Effect

    A simple "fake" wormhole way which doesnt involve a moving camara could be: 1. have a straight length of tube in front of the camara 2. textures move towards the near end of the tube by using an offset in the pixelshader. 3. To make it look like there are twists and turns in the tube you could bend the far end of the tube left/right/up/down by making changes in the vertexshader similar to doing skeletal animation. Its not as "real" as actually flying the camera down a real twisting tube, but it might be slightly simpler if all you are doing is a cutscene rather than something that can be controlled by the player. My guess is your "real" tunnel will probably look better than this "fake" way however.
  15. CortexDragon

    Intel HD 620, 400 draw calls, 37FPS

    This is very old information, so it may not apply to your situation, but traditionally lots of small draws is slower than a few big draws, so definetly try the instancing mentioned above, (or even combine them into one big draw). https://stackoverflow.com/questions/4853856/why-are-draw-calls-expensive Nvidia wrote a paper about it :- http://www.nvidia.com/docs/IO/8228/BatchBatchBatch.pdf
  • Advertisement

Important Information

By using GameDev.net, you agree to our community Guidelines, Terms of Use, and Privacy Policy.

GameDev.net is your game development community. Create an account for your GameDev Portfolio and participate in the largest developer community in the games industry.

Sign me up!