Shadow volumes are interesting things. For everything that casts a shadow, you need to have a fully enclosed solid. Because of the way our shader works, for every triangle we need to know what its 3 adjacent neighbors are. And when I say “need” I don’t mean “ought to” I mean it’s impossible to do otherwise. You can’t supply a triangle to the shader without neighbors for the same reason you can’t draw a triangle with less than three vertices. It wouldn’t make any sense. (And if there aren’t 3 neighbors? Then this isn’t an enclosed solid.)
Let me bring up this diagram again:
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
| /*-----------------------------------------------------------------------------
This shader takes a triangle of type GL_TRIANGLES_ADJACENCY. It takes the
following form:
1-----2-----3
\ / \ /
\ / \ /
0-----4
\ /
\ /
5
Points 0, 2, and 4 are the points of the triangle actually being drawn.
Points 1, 3, and 5 are corners of adjacent triangles, provided by OpenGL
for the purposes of being able to analyze the topology here in a geometry
shader.
-----------------------------------------------------------------------------*/ |
/*-----------------------------------------------------------------------------
This shader takes a triangle of type GL_TRIANGLES_ADJACENCY. It takes the
following form:
1-----2-----3
\ / \ /
\ / \ /
0-----4
\ /
\ /
5
Points 0, 2, and 4 are the points of the triangle actually being drawn.
Points 1, 3, and 5 are corners of adjacent triangles, provided by OpenGL
for the purposes of being able to analyze the topology here in a geometry
shader.
-----------------------------------------------------------------------------*/
This is no big deal when you’re using models made by artists. Maybe the artist has some kind of tool or conversion utility for identifying all the triangle relationships. But this becomes tricky when we’re building objects on the fly. When I’m building a particular cube, I can’t hook its triangles up to its neighbors, because at least half of them haven’t been built yet. I could peek at the next-door cube to see what I will eventually build there, but I won’t know what vertices it will use until I get there. So what you have to do is just build a bunch of triangles and then stitch them together when you’re done.
This is actually really time consuming. Like, 90% of the time spent waiting for chunks to appear is waiting for it to thrash through these huge lists of triangles and figure out which ones are neighborsThis is the major reason I’m not using larger chunk sizes. Larger chunks make this triangle-matching less efficient. There are ways to improve this, but I haven’t gotten around to it yet.. Eventually I’m going to have to fix that. Chunks take about a quarter second to form. A given scene with even a modest view distance will have hundreds and hundreds of chunks. Which means filling in a scene can take a few minutes. While this doesn’t matter from a gameplay standpoint (this isn’t a game, and nobody is ever going to play it, so who cares?) it does matter from a testing perspective because I do a lot of tests and I’m really impatient. But this is a challenge for a future post. In the meantime…
It turns out that we have a problem:
Continue reading ⟩⟩ “Project Unearth Part 6: Kissing Cubes”
Shamus Young is a programmer, an author, and nearly a composer. He works on this site full time. If you'd like to support him, you can do so via Patreon or PayPal.
T w e n t y S i d e d
