After admiring the graphics of my Tunnel I wanted to mirror the aesthetics in a ‘real’ world, instead of an abstract visual.
I used GL.Lines in the Tunnel, manually positioning them on the CPU; seeing as I had the positional data already from the Tunnel itself, I wasn’t worried about this. But for a large scene this is infeasible. Luckily Unity has different mesh topologies I can use to hold this information.
A normal mesh doesn’t purely preserve a silhouette in its geometry; there’s edges of quads and triangles that aren’t what I would like to see.
A method to generate silhouette edges that I use for a simpler game I’m making (one who’s only geometry is cubes and tetrahedrons) is to extrude the edges I want to draw towards the origin. Then in script I can just ask which edges don’t share a vertex on the origin, and add them to the indices array.
But having to frequently revisit a modelling tool to make edits to wireframes seemed daunting, so I spent a day making a quick tool to bake the right edges to be created before or after runtime.
I can now manually allocate edges where a line will be created. Once a line is created it can be treated entirely separately from the original mesh, enabling you to use only the new wireframe, or keep it as a wireframe-shaded option.
I’m left with a pleasing result, albeit the restrictions and limitations of GL.lines are still present and without some depth-fudging in the shader the lines visibly clip into the parent meshes. But if I end up pursuing the aesthetic further I would further speed up the workflow with better selection tools, automatic silhouette detection, and perhaps a modifiable generated tri-based alternative.