Questions about billboards

Can't show the code at this moment, but one of the reasons for geometry shader to exist is particle / quad expansion.

Cheers!

A low-tech way is to rotate the model coordinates in your vertex shader before applying the world matrix.

Easiest way is to multiply them with the transpose of your view matrix with the translations set to 0:

[source]
float4 RotateTowardsEye(float4 inModelPos){

float4x4 Q;
for(int i=0; i<4; i++){
for(int j=0; j<4; j++){
Q[j]=View[j];
}
}
Q[0][3]=0;
Q[1][3]=0;
Q[2][3]=0;

return mul(inModelPos,Q);
}

[/source]

This way you can use 3D models as particles/billboards as well, not just simple shapes like quads.

You can expand and align the quads using a vertex shader and instancing without having to resort to using the geometry shader stage.

Here is the vertex shader part of a DX11 example of rendering particles using billboards and vertex shader instancing taken from Chapter 8 of my book Direct3D Rendering Cookbook. This doesn't need the geometry shader stage at all and the full example uses append/consume buffers within a compute shader to perform the particle simulation.

By using instancing to determine the index into the particle buffer there is no need to provide any input vertex buffer(s) into the vertex shader stage.

// Represents a particle
struct Particle {
    float3 Position;
    float Radius;
    float3 OldPosition;
    float Energy;
};

// Access to the particle buffer
StructuredBuffer<Particle> particles : register(t0);

// Some common structures and constant buffers (e.g. PS_Input, projections and so on)
#include "Common.hlsl"

// Represents the vertex positions for our triangle strips
static const float4 vertexUVPos[4] =
{
    { 0.0, 1.0, -1.0, -1.0 },
    { 0.0, 0.0, -1.0, +1.0 },
    { 1.0, 1.0, +1.0, -1.0 },
    { 1.0, 0.0, +1.0, +1.0 },
};

float4 ComputePosition(in float3 pos, in float size, in float2 vPos)
{
    // Create billboard (quad always facing the camera)
    float3 toEye = normalize(CameraPosition.xyz - pos);
    float3 up    = float3(0.0f, 1.0f, 0.0f);
    float3 right = cross(toEye, up);
    up           = cross(toEye, right);
    pos += (right * size * vPos.x) + (up * size * vPos.y);
    return mul(float4(pos, 1), WorldViewProjection);
}

PS_Input VSMainInstance(in uint vertexID : SV_VertexID, in uint instanceID : SV_InstanceID)
{
    PS_Input result = (PS_Input)0;

    // Load particle using vertex instance Id
    Particle p = particles[instanceID];
    // Vertices in triangle strip
    // 0-1
    //  /
    // 2-3
    // Load vertex pos using the vertexID for the vertex in the strip (i.e. 0, 1, 2 or 3)
    result.UV = vertexUVPos[vertexID].xy;
    result.Position = ComputePosition(p.Position, p.Radius, vertexUVPos[vertexID].zw);
    result.Energy = p.Energy;
    return result;
}

To use this shader you set the input assembler primitive topology to a "triangle strip" and then use DrawInstancedIndirect - assuming that a compute shader determines the number of particles, otherwise DrawInstanced.

Awsome, thanks everyone. Also spazzarama that book looks awesome. C# forever!

Ok, I have a couple of questions regarding spazzarama's example. Let me see if I get this straight.

The vertex buffer is merely the numbers 0, 1, 2 ,3. That's the vertex buffer. spazzarama says its not needed, but then how do we know what vertex we are on?

The instance buffer is a list of indexes into the structured particle buffer, is this also not needed?

Yeah, I'm gonna have to buy the book.

That's the magic of those system value semantics. If e.g. you call DrawInstanced(4, n, 0, 0) that vertex shader will get these values:

vertexID| instanceID
--------+-----------
     0  |   0
     1  |   0
     2  |   0
     3  |   0
     0  |   1
     1  |   1
     2  |   1
     3  |   1
     0  |   2
     1  |   2
     2  |   2
     3  |   2
    ... |  ...
     0  |  n-1
     1  |  n-1
     2  |  n-1
     3  |  n-1

If you can generate geometry from these values alone (procedurally and/or with a lookup), you don't need to bind any buffer to the input assembler stage. Neither do you need an input layout.

In spazzarama's example he binds a shader resource view to the vertex shader stage.

(And as I hear: On hardware/driver level the input assembler is actually such a "shader")

What @unbird said, couldn't have said it any better.

Not billboard related, but I think you might be interested.

The canonical example for a buffer-less setup is the full-screen triangle (e.g. for post-processing shaders)... Hmmm, pity, that nice altdevblog entry seems to have gone. Here a alternative:
Full screen quad without vertex buffer?

What I only learned recently is to bind only a index buffer, and use any of the indexed draw calls. Read here (it also shows the above triangle thingy):
Vertex Shader Tricks.
Peculiar: This can actually improve over instanced draw calls (low vertex count seems to be bad for instancing).

Since I'm quite fascinated by procedural geometry: Here I wrote a shader producing a cube (could be improved with the above index buffer trick).

Back to billboards: In you OP you mention tesselation shader. Sure possible, but unless you have a special need (i.e. actual tesselation) for a simple quad this is overkill - and less efficient for sure.

You know, its funny but it almost seems like with these indices coming in, using traditional vertex and instance buffers is obsolete. With this you can access neighbor information with some index math.

With this you can access neighbor information with some index math.

Really? I always assumed the shader only had access to the current vertex.

Although, I guess if your generating all the vertex data within the shader, you could do it for any arbitrary vertex /instance index. Interesting, but I don't immediately see an application. My brain isn't over the post-Halloween fug.

Cephalo has a point. Don't see a application for the neighbour idea just now, but definitively read the Vertex Shader Tricks slide I linked above. They have a "soft instancing" example to instance different meshes with one draw call:

Obsolete ? With D3D12 probably, or let's say "optional"

Wow, that soft instancing is amazing. I'm just a dabbler but another possible use could be for calculating Phong vertex normals on a procedural heightfield that is genned in the shader. KIndof like a giant domain shader patch.