Catflier: May 2013

Wednesday 29 May 2013

Graph Collector

After releasing new DirectX11 pack for vvvv and beta 30 : http://vvvv.org/contribution/directx11-nodes-alpha, Time to go back into dev.

I added new Segment Node, which allows Z extrusion. It's pretty nice playing with Phase/Cycles/Resolution you can do some nice designs, here are couple of shots below (no fancy shading yet).

So now issue with designing it, i have heap lot of shader nodes, layers and groups, so it's a big patch to maintain.

Exporting it as file would be handy, so I could just design my bits and use a file loader, fast switch, clean patch, mmmmhhh :)

So first thought was collada, but it's such a crap format, way too big for what it does.

I'd have to store vertices for every bit + transform, projected file size: 10 megs at least, bleh...

So second thought was to create module for every node, and have it output relevant data as string as well as render it, so cumbersome, bleh again...

Then last thought, oh I got dx11 source code (since I wrote it), so i should be able to traverse the graph and store data instead of render (and then serialize as any format like json, no xml please ;)

Issues:

I don't want to store vertices/indices, takes too much space. I already know what geometry I use, so it would be better to just tell how to generate it again.
Most 3d formats suck for batching, in my case I can have the same geometry sent 10 times to shader, most 3d software would replicate geometry (come on, please start to do proper format one day), Instead it would be much easier to tell geometry-> transform list.

So for the moment once geometry is created I got no way to know how it was built.

So I simply added this in geometry provider

Code Snippet

string PrimitiveType { get; set; }
 
object Tag { get; set; }

Then for each type of geometry I create a descriptor, here is the base;

Code Snippet

public abstract class AbstractPrimitiveDescriptor
{
    public abstract string PrimitiveType { get; }
    public abstract void Initialize(Dictionary<string, object> properties);
    public abstract IDX11Geometry GetGeometry(DX11RenderContext context);
}

Then here is sphere:

Code Snippet

public class Sphere : AbstractPrimitiveDescriptor
{
    public float Radius { get; set; }
    public int ResX { get; set; }
    public int ResY { get; set; }
    public float CyclesX { get; set; }
    public float CyclesY { get; set; }
 
    public override string PrimitiveType { get { return "Sphere"; } }
 
    public override void Initialize(Dictionary<string, object> properties)
    {
        this.Radius = (float)properties["Radius"];
        this.ResX = (int)properties["ResX"];
        this.ResY = (int)properties["ResY"];
        this.CyclesX = (float)properties["CyclesX"];
        this.CyclesY = (float)properties["CyclesY"];
    }
 
    public override IDX11Geometry GetGeometry(DX11RenderContext context)
    {
        return context.Primitives.Sphere(this);
    }
}

That's it, instead of storing 1000 vertices i can just store 5 parameters instead, how cool is that?

When I create geometry, I just assign the descriptor to the geometry, so I can know at any time how things were created.

Now that's cool, but I need to grab geometry, so here is how it works.
Layer have RenderSettings which carry some info on how to render, so I simply added collector as render hint.

Code Snippet

public enum eRenderHint { Forward, MRT, Shadow, Overlay, Collector }

Then settings carry:

Code Snippet

 
public class DX11ObjectGroup
{
    public DX11ObjectGroup()
    {
        this.RenderObjects = new List<DX11RenderObject>();
    }
 
    public string ShaderName { get; set; }
 
    public List<DX11RenderObject> RenderObjects { get; set; }
}
 
public class DX11RenderObject
{
    public string ObjectType { get; set; }
 
    public object Descriptor { get; set; }
 
    public Matrix[] Transforms { get; set; }
}

So renderer only has to set it's flag to collector (tells shader that we don't want to render but collect information).

Shader then can just retrieve descriptor, and push it with list of associated transforms (huhu, batch friendly ;)

Little snippet for shader node, if render hint is set to collect it just appends object/transform instead of render.

Code Snippet

IDX11Geometry g = this.FGeometry[0][context];
if (g.Tag != null)
{
    DX11RenderObject o = new DX11RenderObject();
    o.ObjectType = g.PrimitiveType;
    o.Descriptor = g.Tag;
 
    o.Transforms = new Matrix[spmax];
    for (int i = 0; i < this.spmax; i++)
    {
        o.Transforms[i] = this.mworld[i % this.mworldcount];
    }
    group.RenderObjects.Add(o);
 
    settings.ObjectCollector.Add(group);
}

Object list is then serialized as Json Object, here is one part of it:

Code Snippet

{
  "ObjectType": "SegmentZ",
  "Descriptor": {
    "Phase": 0.0,
    "Cycles": 0.25,
    "InnerRadius": 0.94,
    "Z": 0.03,
    "Resolution": 100
  },
  "Transforms": [
    "-1.43, 1.751187E-16, 0, 0, -1.751187E-16, -1.43, 0, 0, 0, 0, 1, 0, 0, 0, 0, 1",
    "1.43, 0, 0, 0, 0, 1.43, 0, 0, 0, 0, 1, 0, 0, 0, 0, 1"
  ]
},

Now I can simply reload the whole scene from the file, (for example above, whole scene fits in 33kb indented, 22kb compressed, pretty nice ;)

So next was just doing a Loader node for testing, pretty simple, retrieve descriptor, create geom, associate with transform and render. Please note that could do an importer for anything, it's not only 4v related (technically I got a use case for it, top secret ;)

The obvious great thing is it's totally transparent, I only need to enable collect, and I can retrieve whole scene, no need for any fancy stuff, and works for any part I have already done as well, no mod needed.

Here are few example of it:

That's it, now of course will need improvements, but pretty excited about possibilities. Having source code for render system is quite invaluable, without it would have done the dirty module way, brrr....scary!!

Sunday 26 May 2013

Deffered Lights

As many know I use deffered rendering a lot.

Most of post processing in DirectX11 can now be done in Forward (HBAO / Depth Of Field use depth only), but of course as soon as you include shading into the mix, you need Normals and a bit of Extra Data.

So you need some MRT setup, for my lights i use only 2 targets:

Code Snippet

struct PS_OUT
{
    float4 albedo :SV_Target0;
    float4 ns : SV_Target1;
};

albedo.xyz is color, and alpha channel is used for roughness
ns.xyz is normals (view space), ns.a is reflectivity

I could add a 3rd target for specular albedo, but never had the use for it, maybe I'll add it one day (could use the 4th target for some shadow bits as well)

Ok so now we our shiny normal target filled up with fancy geometry, we need to add some shading into it.

Directional light is full screen, not many ways to cull that (except using some stencil culling if possible)

Point lights you have plenty of techniques, I remember doing Light volumes in DX9 a few years ago, it's pretty easy.

Of course now you have shiny new technique, using compute tile lights (I based my implementation from Andrew Lauritzen, which also have some nice techniques using Geometry Shader if your device is not SM5.0 capable)

So on the list of techniques:

Compute Tiles : Send a structured buffer, cull lights against tiles with mini frustrum and only process lights that pass the test
Clip Quad : Send a structured buffer, and draw n points (single call), in Vertex Shader convert the point light (sphere) into a screen space quad, expand your point into quad in GS, process light in PS (use additive blending).
Clip Quad (low) : Some devices don't support raw/structured buffers, so instead you copy your lights into a Vertex Buffer and do more or less the same (you change structure input instead of doing lookup)

Here is how VS input looks for Clip Quad:

Code Snippet

StructuredBuffer<PointLight> LightBuffer : LIGHTBUFFER;
 
struct vsInput
{
    uint iv : SV_VertexID;
};

And the Vertex Buffer Version

Code Snippet

struct vsInput
{
    float3 lightpos : LIGHTPOSITION;
    float attenuationBegin : LIGHTATTENUATIONBEGIN;    
    float3 color : LIGHTCOLOR;
    float attenuationEnd : LIGHTATTENUATIONEND;    
};

So both techniques are mostly equivalent, but the Structured Buffer one is quite nice in case you have 10.1 feature set (since you can use Compute Shader to move you lights for example)

In Case of VertexBuffer, you can still use Stream Output to animate lights in GPU, which is also fine, but adds a bit of extra coding around.

Please of course note that Stencil Test can also be used for GS techniques.

Now we have a decently efficient way to draw multiple lights, there's still one part missing, light equations ))

So now using a few brdf (depending on my scene):

Phong (never using it)
Oren Nayar (I really like it for splines)
Cook Torrance (for more or less all the rest)
Ward (used it before, but now i mostly use the 2 above)

So one option is to use Techniques, but in that cases it implies a lot of code duplication eg: not too nice.

That leaves 2 other options:

Shader Linkage
Shader Macros

Unless you have Feature Level 11, you stuck with macros, since you can use dynamic link.

It's pretty simple, you use defines and #ifdef / #if , then you specify defines when you compile shader, so basically you compile one shader instance per brdf.

Code Snippet

#define LIGHT_PHONG 0
#define LIGHT_WARD 1
#define LIGHT_COOKTORRANCE 2
#define LIGHT_OREN_SIMPLE 3
#define LIGHT_OREN_COMPLEX 4
 
//Override macros on compile
#ifndef LIGHT_TYPE
#define LIGHT_TYPE LIGHT_COOKTORRANCE
#endif
 
/* Here we can't use interfaces in case we haven't got sm5 support, so default to 0 */
#ifndef USE_INTERFACE
#define USE_INTERFACE 0
#endif
 
#if USE_INTERFACE == 1
#include "Brdf.fxh"
#else
#include "Brdf_Funcs.fxh"
#endif

So when you compile shader you also send the define LIGHT_TYPE, and then you switch shader depending on equation.

It's of course handy since you have a single code base, any improvement impacts on all brdf at once.

Now with shader model 5 you also have a nitfy feature called Shader Linkage, so now our code looks like:

Code Snippet

interface iBRDF
{
    void Accumulate
    (
        in float3 n,
        in float3 l,
        in float3 v,
        in float3 lightContrib,
        in float fRoughness,
        in float fSpec,
        in float atten,
        inout float3 result
    );
};

Next we declare Brdfs (one class per equation)

Code Snippet

class cWard : iBRDF
{
    void Accumulate
    (
        in float3 n,
        in float3 l,
        in float3 v,
        in float3 lightContrib,
        in float fRoughness,
        in float fSpec,
        in float atten,
        inout float3 result
    )
    {
        //Do you light cooking here
    }
};

And to finish we instantiate all that lot:

Code Snippet

 
cPhong phong;
cWard ward;
cCookTorrance cooktorrance;
cOrenSimple orensimple;
cOrenComplex orencomplex;
 
iBRDF brdf <string linkclass="phong,ward,cooktorrance,orensimple,orencomplex";>;

Annotation is just used for reflection in my case, so it builds an Enum automatically

What is nice with this technique is that you only need one shader instance, and can switch light equation on the fly very easily:

Code Snippet

public void BindClass(string classname, string interfacename)
        {
            this.Effect.GetVariableByName(interfacename).AsInterface().ClassInstance = this.Effect.GetVariableByName(classname).AsClassInstance();
        }

Pretty cool no? And with shader reflection there's even no need to change any code, all is done automatically ))

Now of course one important part is : what are performances?

So please note that using shader linkage in that case implies a performance hit, which is quite non negligible if you not on high end hardware (I noticed it was quite significant on laptop, not as bad on desktop).

So shader linkage adds flexibility (very easy to avoid lot of permutation, or compile of shaders to handle all possibilities, but that comes as a cost). It's then up to you to abuse timestamp queries and decide if the hit is worth taking ;)

That's it for now, next post... I don't know ;)

Wednesday 8 May 2013

Geometry Generation (Fast)

Ok so first post here, let's start by something fun :)

One common thing needed in computer graphics is some form of geometry.

Some can come from 3d software and you use an importer (like Assimp, or your own), some geometries can be generated on the fly (Grid/Spheres/Box/Torus...)

Geometry generation is generally done as follow:

Build a bulk of vertices in CPU (some for loop)
Build an IndexBuffer in CPU (some for loop)
Copy your buffers in GPU
Use it !

Pretty simple uh?

Only issue is now it you want to modify your geometry parameters in real time (and you have decently high resolution geometry), you need to:

Rebuild the bulk of vertices
Copy again
Eventually do the same for index buffer

That can get pretty slow, so let's look how to pimp that a tad.

Our friend DirectX 10 brings a feature called Stream Output, which allows you to render to buffers. This buffer can be either an Index Buffer or a Vertex Buffer, oh, that sounds quite convenient.

So let's say we want to build a grid (pretty simple example, but grids are decently used around as bezier/surfaces/heightfields...), resolution being 512*512

Here is our vertex shader input:

Code Snippet

struct vsInput
{
    uint iv : SV_VertexID;
};

And our desired output:

Code Snippet

struct vsOutput
{
    float3 pos  : POSITION; 
    float3 norm  : NORMAL; 
    float2 uv : TEXCOORD0;
};

Since we don't provide input geometry, we set IA stage to null (we don't send any geometry as input), and Assign the VertexBuffer as StreamOutput target.

Then the following lines of code generate vertices:

Code Snippet

vsOutput VS_Vertices(vsInput input)
{
    vsOutput o;
    int colindex = input.iv % colcount;
    int rowindex = input.iv / colcount;    
    float2 uv = float2(input.iv % colcount,input.iv / colcount) * invgridsize;
    float2 pos = uv;
    
    uv.y = 1.0f - uv.y;
    pos.xy = (pos.xy - 0.5f) * size;
    o.pos = float3(pos,0.0f);
    o.norm = float3(0,0,-1);
    o.uv = uv;
    return o;
}

Pretty simple:

From the vertex id (simple GPU counter), we retrieve the cell position.
To normalize it (eg: fit in 0/1), we simply multiply by inverse resolution
We flip Y axis (for uv only)
Recenter positition (so our grid center is in 0,0 not in 0.5,0.5)
Done, that was so hard... :)

Now we need to generate our indices (since some vertices are shared).

We have few options here:

Set our Stream Output as triangle: This is not convenient at all, since grid geometry is quad based, so we'll need to replicate a lot of calculations, and flip triangle depending on vertex id, which is not very friendly.
Set our Stream Output as Quad: Instead of generating one triangle at a time in Vertex Shader, we will generate 2, which fits perfectly a cell expansion, and reuse calculations.

So obvious choice, quads

Here is our Vertex Shader output:

Code Snippet

struct vsOutputIndices
{
    int3 t1 : TRIANGLE0;
    int3 t2 : TRIANGLE1;
};

And the (extremely) hardcore Vertex Shader:

Code Snippet

vsOutputIndices VS_Indices(vsInput input)
{
    vsOutputIndices o;
    int j = input.iv / (colcount-1);
    int i = input.iv % (colcount-1);    
    int rowlow = j * (colcount);
    int rowup = (j+1) * (colcount);
    
    o.t1 = int3(rowlow + i, rowup + i, rowlow + i + 1);
    o.t2 = int3(rowlow + i + 1, rowup + i, rowup + i + 1);
    return o;
}

Here we do more or less the same as generating positions, excluding we need to take care or row/column indices stride.

Here we are, generating a Grid without CPU.

Nice thing about it is since other geometries can also be interpreted as a parametric surface, we can easily modify shader to generate them (only shader to generate vertices needs modifications, index buffer builder is the same).

Here is how to build a sphere:

Code Snippet

float3 sphere(float u, float v)
{
    float3 p;
    u = (u + 0.5) * PI * 2.0f;
    v = (v + 0.5) * PI * 2.0f;
    float su = sin(u); float sv = sin(v); float cu = cos(u); float cv = cos(v);
    p.x = su*sv;
    p.y = cu*sv;
    p.z = cv;    
    return p;
}
 
vsOutput VS_Vertices(vsInput input)
{
    vsOutput o;
    int colindex = input.iv % colcount;
    int rowindex = input.iv / colcount;    
    float2 uv = float2(input.iv % colcount,input.iv / colcount) * invgridsize;
    float2 pos = uv;    
    uv.y = 1.0f - uv.y;
    o.pos = sphere(uv.x * CyclesU,uv.y*CyclesV)*radius;
    o.norm = normalize(o.pos);
    o.uv = uv;
    return o;
}

Many other surfaces can be built same style (ideally if you can have partial derivatives for normals that helps)

Grid deformation was quite decently used in vvvv (deforming in vertex shader and then shading it), obvious win by using StreamOut is geometry is also reusable (shadow/forward...)

That's it for now, stay tuned.

First Post

Hello, here we are again, after blogging privately about DirectX 11 development for vvvv, I felt I would open a new blog, since now I can speak openly about it.

Mostly (as usual), I'll speak about real time graphics and shader coding (really?), but also commenting on other activities on the front (vuo/realtime studio/vvvv....).

So here is a taste of what to come:

Shader Techniques
VVVV Stuff
Realtime Studio (Outracks) beta overview
Vuo presentation overview
DirectX 11.1 for High End machines (UAV at every stage !!!)
DirectX 11/11.1 for Low feature sets (tablets with no buffer support, phones with 9.3 feature level)
OpengGL
Cuda
Random mumbling :)
Flare (you'll hear about it)