|
|
 |
WebGPU..
Games, Tutorials, Demos, Projects, and Code..... |
|
|
|
 | Vertex Arrays (Data, Types, Topologies)... |  |
Array of vertices - each element in the array corresponds to a single vertex. We can assume the vertices are in a specific order (e.g., list of triangles). But often vertices share the same data! This is where `indices` come into play.
Instead of the vertices begin constructed using the order in the array - a second array of indexes is used to construct the geometry.
When we have an array of vertices for a cube (triangle-list topology) - that would be 12 triangles (36 vertices) - every 3 vertices is a triangle.
For an vertex-index array pair - we only have `8 vertices` - as the corners of the cube share the same positions! The index array contains 36 integers (which index into the 8 vertices to construct the cube).
You might be thinking, how is this any better? 36 vertices or 8 vertices+36indices! Well each vertex position uses 3 floating point values (36x3x4=432 bytes). For the vertex-index configuration (assume a 32bit unsigned integer for the indices array numbers) - we can calcuate the memory usage as: 8 vertices+36 indices (8x3x4=96, 36*4=144) = 240 bytes.
So you can see - even for a simple cube - you're using nearly half the amount of memory - for larger more complex models it can be even a greater saving.
The five types of WebGPU topology are:
enum GPUPrimitiveTopology {
"point-list",
"line-list",
"line-strip",
"triangle-list",
"triangle-strip",
};
You can also have a single large block of memory with all the vertex data - or you can split everythign up - into memory blocks for positions, colors, texture data, normals, etc.
The format/alignment can help the hardware - help reduce cache misses while accessing vertex data on the GPU - it can also be helpful if you're changing vertex data reguarly during rendering (e.g., render positions and normals for some geometry but others you need to include extra deta such as texture and color information - having it split makes it easier to exclude/include).
No one size fits all - usually depends on needs/costs/complexity and so on.
|
|
