X4 Pop-in?

[DaMuncha]

(For those wanting to know what 'Greeble' is.)

So all that crap on the side of a BORG cube

[Fedora01]

(For those wanting to know what 'Greeble' is.)

So all that crap on the side of a BORG cube

Or 50% of most Star Wars ships

[JSDD]

It's never necessary, that's what distance LOD models are for. Providing lower poly renders of the same entities for viewing at a distance so that it doesn't impact frame rate so much. But still you want to be able to see small dots moving in space from a distance, where there are ships fighting or a trade fleet moving etc.

Stupid artist attempt at an explaination of why things are not that simple:

Reducing the polycount of a simple object (for example a single drawcall object - a ship which only has a single material and no textures) only makes it faster to render. The amount of calculating if its on screen and pushing that information through the CPU stays the same.

The polyount is not our main problem,its the amount of drawcalls - things to render (the ship hull, the landinggear, the cockpit, the positional lights+....... ).
Therefore we also reduce the amount of drawcalls in the LODs down to a simple object (one gemetry - one material) to get rid of all of this small stuff being pushed through the system.

as far as i know, you can reduce the number of drawcalls to 1 per renderstate. i`m only a bit familiar with opengl, never did anything with vulkan, but the restrictions on what is possible are less in vulkan (but it comes with more work).

the usual 1 drawcall per mesh (that uses 1 material)
glDrawElementsBaseVertex(...)
--> uses vertex + index buffer in which all the meshes are layed down

then there is instanced rendering, all the meshes of the same type (for example: ship hull LOD 0, again with the same material)
glDrawElementsInstancedBaseVertex(...)
--> uses vertex + index + instance buffer

now you can render as much as you want, drawcall count can be reduced to "materialcount" x "meshcount" ... just fill a buffer with all the "data per instance" (for example: mat4x4 transformation) for ALL instances of a certain mesh, apply its material to the shader, issue drawcall

a recent feature, "indirect" rendering (GL version 4.2) can give you another advantage: buffering drawcalls themself (!) into the indirect buffer. now you`ve got 4 buffers, vertex + index buffer for mesh data, instance buffer for all instances of ALL mesh types together, and an indirect buffer filled with drawcall infos. with that you can reduce the number of drawcalls to "materialcount" (i think)
glMultiDrawElementsIndirect(...);

The parameters addressed by indirect are packed into a structure that takes the form (in C):

Code: Select all

typedef  struct {
        uint  count;
        uint  primCount;
        uint  firstIndex;
        uint  baseVertex;
        uint  baseInstance;
    } DrawElementsIndirectCommand;

If a buffer is bound to the GL_DRAW_INDIRECT_BUFFER binding at the time of a call to glDrawElementsIndirect, indirect is interpreted as an offset, in basic machine units, into that buffer and the parameter data is read from the buffer rather than from client memory.

Code: Select all

first fill buffers ...
for each (material)
{
    apply material;
    glMultiDrawElementsIndirect(XYZ);
}

in XYZ, there is the information:
--> mode = GL_TRIANGLES for triangularized meshes
--> type = GL_UNSIGNED_SHORT for up to 32K vertices per mesh
--> indirect = byte offset to the next "internal" drawcall
--> drawcount = number of drawcalls in the indirect buffer
--> stride = sizeof(DrawElementsIndirectCommand)

the each buffered drawcall in the indirect buffer does the following: (see "struct DrawElementsIndirectCommand" above)
--> count = index count in the index buffer for mesh J
--> instancecount = 1 or 0 (draw it or skipp it)
--> firstindex = offset into index buffer for mesh J
--> basevertex = offset into vertex buffer for mesh J
--> baseinstance = offset into instance buffer for instance K of mesh J

tip of the iceberg, most graphics cards support "bindless textures" feature, with means you dont have to change the "renderstate" per material. just create a fifth buffer, but ALL the materials that you have in there, and put an additional "per-instance-data" called "uint materinlindex" in it. now, you can access the material from a materialarray in your fragment shader.

what about textures?
--> create all textures that you want to have
--> make them "residend", get a handle (which means they are on the GPU memory)
--> create an uint array, put all textures in there, bind it as "uniform buffer"
--> for each material that needs textures, get the index in that texture in the array, and set it as "per-material data"
--> all those materials without texture just access an Xtra 1x1 white texture
--> diffuse = diffusecolor x diffusetexture, so that you dont need to distinguish between "hastexture" and "hasnotexture"

Code: Select all

struct material {
vec4 diffusecolor;
vec4 specularcolor;
float shininess;
uint diffusetexture;
//...etc
};

another advantage is that you can do instance culling on the gpu, and directly use the buffer as "instance + indirect buffer".


RESULT:
1 drawcall per renderstate