Jump to content

  • Log In with Google      Sign In   
  • Create Account


Member Since 27 Jan 2014
Offline Last Active Yesterday, 02:29 PM

Posts I've Made

In Topic: Unordered access view woes with non-structured buffers

12 August 2014 - 05:04 PM

Ah yes, I eventually reached the conclusion that it will in fact only work for "real" primitive datatypes (and probably no 64-bit ones like doubles either for that matter). I was led astray by a passage in Practical Rendering with DirectX 11 that insinuated that things like float3 were in fact considered primitives in HLSL and then the fact that the DXGI_FORMAT enumeration contain lots of formats that are indeed vectors. However I suppose they should be treated like syntactic sugar and indeed require a structured buffer.


Thanks for your input :)

In Topic: Unordered access view woes with non-structured buffers

11 August 2014 - 04:51 PM

If I'm not mistaken the UAVs and Render Target Views use the same "registry" (Perhaps a different word is used).

Ah yes, that limitation has caused quite some issues since my engine initially allowed binding render targets to arbitrary registers so that there could be unused ones (reserved for possible future use) in-between. I suppose that wasn't the best solution anyway, so good riddance in a way.


I've had some progress whereby it seems that the DXGIFORMAT_R32_UINT works, but that kind of takes away the notion that buffers can be of "any primitive type" so there is most likely something wrong here still... I'll try to get to the bottom of it tomorrow.

In Topic: Unordered access view woes with non-structured buffers

11 August 2014 - 08:05 AM

RWBuffer<float3> RWBuf : register(u0);

But it fails at the call to ID3D11Device::CreateUnorderedAccessView so I don't think the shader declaration is of any relevance since they haven't been bound together yet by then.

In Topic: Rendering blended stuff before skybox?

10 August 2014 - 05:50 AM

I would draw the skybox first since it should always be furthest in the background anyway and you should sort your opaque objects from back-to-front.

If you draw the skybox last, your transparent objects will only blend with opaque and other, previously drawn transparent ones, but not the skybox. This means they will get an edge around the transparent parts of the colour it was blended with which will be the render target clear colour in areas where only the skybox would be behind these objects. Of course this won't look pretty once the sky gets filled in to the non-transparent pixels surrounding those blended areas ;)

In Topic: Geometry shader patchlist input?

08 August 2014 - 10:02 AM

Ah, I see...


I'm going to have to rethink my approach then, it is possible it could be solved using tessellation, however I had hoped for shader model 4 support. Maybe I can use a pre-processing step where a buffer resource is created to store the desired adjacency data that can then be made available to the GS in subsequent steps.