Optimizing VRAM usage
The amount of vram used by the prototype was a major issue and it still is. Granted, we have more optimization to do engine wise but it still was and will be a problem for us. Planets easily gobbled up a few hundred MB. Add all the deferred rendering buffers and 4k+ textures you will easily hit the vram limit of most of the video cards currently on the market.
To add more content we need to lower the used vram. Engine upgrades will help but we need to look at the art assets and see how we can lower the amount of used vram. One point of attack is to no longer use unique per asset normal maps.
To get good detail out of a normal map you need it to be at a sufficiently large resolution and capture all the fine detail. Ideally you’d want it to be at 16 bits per channel as well to alleviate artifacts. Looking at our normal maps there are small bits of high frequency detail, but most of it is just a large “flat” area. Essentially useless data. Data that still eats up valuable vram.
Our prototype assets didn’t look to good from up close. So we need to raise the quality level, lower vram usage and do it without normal maps… Getting vram usage under control will be an ongoing process but there are some ways to make ships look sexier that we haven’t used for the prototype.
On to the first make stuff look better methods.
##Face weighted vertex normals (FWVN)
Without normal maps it will be hard to smooth hard edges, this is where manually edited vertex normals come in.
Left is a cube. To smooth the edges you can’t just add all faces to the same smoothing group (right). The mesh needs to be altered to create a cube that has flat looking faces but smoothed edges.
One solution is to add edge loops while keeping all faces in the same smoothing group. The extra geometry will make the automatic vertex normal generation give the edges a smooth look, while keeping the sides flat. There is an issue with the silhouette, but still good looking.
Another option is to chamfer the edges and manually edit the vertex normals so that they aren’t used averages of connected face normals. Weighting the face normal averages by face surface area gives you a much better smoothing solution:
That looks neat! Much less added geometry and while the silhouette still has issues its less off putting than with the added edge loops. A few more verts and faces and no normal map required. Great! If you look closely you will notice that the sides have a gradient. There is some very slight shading going on and this is to be expected. The normals are a weighted average. Lets take a close look at the vertex normals now. Here are some profiles of corners:
- Default smoothing
- FWVN
- FWVN with longer edges
- FWVN with a large chamfer
- Tool assisted normal generation
While 2 and 3 look the same there is a slight difference due to one corner having longer edges. This difference becomes very noticible in 4 where the chamfer is very large. It starts resembling default smoothing much more, as to be expected since the face surface area ratios come closer to 1:1. Only in 5, the tool assisted example, you can see that the normals are perpendicular to the side faces.
Lets take a look at FWVN and tool assisted FWVN with a more complex example.
On the left is the FWVN example and on the right the tool assisted one. Notice that the flat surfaces on the right are flat while on the left you can see some shading going on. A minor hit to vert/face count but it looks great, whether its tool assisted or not.
The FWVN tool
This is the tool I wrote. It contains a few handy shortcut buttons and a way to assign material ids to selected faces. It can apply a developer material to visualize the generation. Applying the correct material ids as you model always gets you good looking normals with the push of a button.
Left mesh has all faces assigned to the edge layer. Right mesh has the flat faces assigned to layer 1, while all the edges are assigned to the edge layer.
