Jump to content

  • Log In with Google      Sign In   
  • Create Account


Member Since 05 Nov 2011
Offline Last Active Jan 11 2013 02:46 AM

Posts I've Made

In Topic: HLSL Vertex Shader input types and their alignment

25 November 2012 - 05:35 AM

Thanks for the answers, so I guess this blog post is totally wrong?

EDIT: Just remembered this was about constant buffers. Carry on.

In Topic: HLSL Vertex Shader input types and their alignment

24 November 2012 - 09:54 PM

Which versions of Direct3D and HLSL are you using?
For D3D11, the formats that can be used for vertex data are listed here.
For D3D9, they're listed here, but you also have to check the device caps to make sure at runtime. Also, the vertex-declaration types and the HLSL types don't have to match; they'll be cast.

Hm... I had someting else in mind - what HLSL types are allowed in the Shader code. So - can I have 'float4' in the input struct? Yes as far as I know. Can I have a 'sampler'? Probably not. Some specification that can answer this questions is what I'm looking for.

I wasn't aware of any alignment requirements, but the fact that D3D11's element-offset variable is called "AlignedByteOffset" implies there are Posted Image
Also, it allows you to use D3D11_APPEND_ALIGNED_ELEMENT to specify that you want D3D to figure out the correct offset including padding, but there seems no way to query the automatically configured value of "AlignedByteOffset" after creating your input layout, which means you wouldn't know how to lay out your vertex buffer!?
That is interesting... As a guess, I would assume alignment requirements might be the per-component size of the element, e.g. for DXGI_FORMAT_R32G32_FLOAT alignment would be 4 bytes.

Hmm... This helps a bit. I know that if the VS input is for example:
struct VSInput {
  float a : A,
  float b : B,
  float4 pos : POSITION

Then I need 8 bytes of padding after the 'B' data in vertex buffer, which means that position must be 16 bytes aligned I guess?

In Topic: Packing DXGI_FORMAT_R11G11B10_FLOAT

14 October 2012 - 01:31 PM

Wow! Thank you Erik for the code and MJP for reference.
Microsoft should work a bit on their documentation - I did a bunch of searching on MSDN and did not come over this article at all :/

In Topic: Packing DXGI_FORMAT_R11G11B10_FLOAT

14 October 2012 - 10:12 AM

What exactly do you want to do?
Get your normal with as high precision as possible to your shader using only 32 bits total for the vector?

I want to try out different formats for storing normals at vertices and compare quality to pick the one that suits me the best. Most formats are either simple to pack to have functions that do that for you (for example - D3DX_FLOAT4_to_R10G10B10A2_UNORM). With this one I do not know how to do it correctly.

store in the shader:

stored_normal = normal * 0.5f + 0.5f;

restore in the shader:

restored_normal = stored_normal * 2.0f - 1.0f;

Nothing more complicated than that. However, I'm not sure if DXGI_FORMAT_R11G11B10_FLOAT has good precision for normals.


I was hoping on a description how to do it on application side (in C++ for example) - so I can store this in a binary file for fast loading later.

In Topic: Why use Uber Shaders? Why not one giant shader with some ifs.

29 April 2012 - 05:33 AM

This remibds me of an blog post that I read a while ago about simulating closures in HLSL. As far as I rember it works on SM 3.0 and up.