french_hustler

Hello all,

 

I have come into a road block with my current project which goal is to test my rendering engine.  The problem occurs when attempting to draw a multitude of small models (less than 50 triangles).  Since each of those model have their own VB and IB, they are each drawn individually.  Of course this higher the draw calls and each of them have very little vertices to output, leaving me bounded by CPU speed.

 

The solution is to batch these suckers up, but I have some doubts about how to proceed.

Note that all the models are static.

 

 

My concerns:

- Since each model have their own transformation matrix, do I have to pre-transform each vertex before adding it to my batch vertex buffer? 

- How do I still take advantage of per-model frustum culling?

- How efficient is it to re-create the batch every frame post frustum cull checks?

 

The way I am currently thinking about doing this is like so:

- On startup, allocate enough memory for a static geometry batch VB & IB.

- Do the frustum cull checks on each model...

- Static models that can be batched (share same textures, materials, etc...) have each of their vertex transformed and added to the batch.

- Draw

- Flush batch, rebuild it for other models that share common textures, materials...

- Draw

and so on....

 

How efficient would it be do transform vertices and recreate the batches (multiple times) per frame?  Does anyone have any insights?

 

Thank you.

Hello,
I am going over Hummus' deferred shading code.  I'm a bit confused about the geometry shader during his deferred lighting pass.

So he basically calculates the lights' bounds in the geometry shader and passes constants ex, ey, and zw to do his calculations.  I don't really understand the purpose of these values, more specifically the ratio he ends up sending over to the shader.

[source lang="cpp"]float ex = tanf(fov * 0.5f); float ey = ex * height / width; renderer->setShaderConstant1f("ex", 0.5f / ex); renderer->setShaderConstant1f("ey", 0.5f / ey); renderer->setShaderConstant2f("zw", projection.rows[2].zw());[/source]

Here is the box calculation function in the geometry shader:
[EDIT]: I have attached the shader file instead since for some reason a lot of the code was getting cut out using the code tags.

float ex = tanf(fov * 0.5f);
float ey = ex * height / width;

At this point ex is 1/2 the near plane's width and ey 1/2 the near plane's height right?

But why does he do:
renderer->setShaderConstant1f("ex", 0.5f / ex);
renderer->setShaderConstant1f("ey", 0.5f / ey);
Wouldn't that be 1/w and 1/h?

Also what does a, b, f represent exactly in this section:
// Compute extents in X
float Lxz = dot(lightPos.xz, lightPos.xz);  // This gives me the quare of the magnitude
float iLxz = 1.0 / Lxz;
float a = radius * lightPos.x * iLxz;
float b = (radiusSqr - lightPos.z * lightPos.z) * iLxz;
float f = -b + a * a;

In the geometry shader, how does this work exactly?
zn = saturate(zw.x + zw.y / z0);
zf = saturate(zw.x + zw.y / z1);
zw.x and zw.y represent proj[2][2] and proj[2][3].  How do those elements of the matrix help figure out zn and zf?  The 3rd row isn't part of the translation....

This is a proj mat in dx:
2*zn/w  0    0   0
0    2*zn/h  0   0
0    0    zf/(zf-zn) 1
0    0    zn*zf/(zn-zf)  0
So isn't proj[2][3] always 1?

And how does the whole ex, ey make sense?
float x0 = saturate(0.5 - N0 * ex);
float x1 = saturate(0.5 - N1 * ex);
&
float y0 = saturate(0.5 - N0 * ey);
float y1 = saturate(0.5 - N1 * ey);


Also, is there a reason for which he insists on using multiplications for his divisions?  Is it more efficient to do x*0.5 than x/2.0?

Thank you for your help.