# Polygon Soup – For 3D Artists

I had originally began writing this as part of the Cross Product post, but realised it was enough of a topic to also break out onto it’s own short. The *Polygon Soup *is an interesting one, especially if you’d never considered how or why 3D meshes are stored *under the hood…*

Mesh data is commonly referred to as Polygon Soup because there’s no *explicit* information here about the structure of the mesh. Triangle `ABC`

might be near triangle `DEF`

in space, but in mesh data they can be *anywhere *in relationship to each other. This makes it all rather *soupy* and loosely connected. So how does our 3D software understand where to put everything, and how it’s connected?

Lets look at what a mesh data structure is in Unity. Meshes here are a collection of lists of data (specifically *arrays* in `c#`

). With the exception of* *Triangles, these lists all maintain the same order, so `vertex[20]`

would correspond to `color[20]`

. This data includes (but is not limited to);

**Vertices**– A list of positions in space, each representing the vertex position.**Normals**– A list of normalised vectors for each vertex. Unity’s documentation even notes that these are*not*face normals.**Colors**– The vertex colours of the mesh**UVs**– The`U`

and`V`

co-ordinates of each vertex in*texture space*, we’ll touch on this later. There can be more then one UV list (sometimes referred to as uv channel).**Triangles**– This is the outlier here…

It is our `triangles`

list which is what helps form more then just the idea of points in space. The triangle list in Unity is a multiple of 3 as every 3 entries forms one triangle, and every entry refers to a *vertex index.*

```
triangles[0] = 12 first vertex index of triangle
triangles[1] = 108 second vertex index ..
triangles[2] = 249 third vertex index ..
```

So in the above example, these first 3 entries in our `triangles`

array tells us our first triangle uses the vertex indices of `12`

, `108`

, and `249`

. These numbers are then used to find the appropriate points in our other arrays. `vertices[12]`

(the 13th entry in our Vertices list), `colors[12]`

would be that vert’s color etc.

Unity builds our triangles from our `triangles`

array, and uses the vertex IDs it contains to link all of our mesh data together for rendering. But if we want to perform any math like casting rays for collision or testing for intersection – ray tracing specifically being one key example – this *data structure *is not suited for the task.

If we wanted to ask our mesh about any aspect of it, we would need to run through our list (called looping) and look at *every triangle* to check if our mesh would be near what we care about.

So in the ray tracing example, if I wanted to use ray traced global illumination to work out bounced lighting in a scene, for each ray I draw out from the camera into the scene (lets just assume it’s only our mesh for now) I would need to test *every* triangle in our mesh to see if the ray would hit. Then our ray would then need to bounce in another direction, performing *the same check aga*in.

We’d keep performing this until we hit a maximum number of bounces we allowed, or the ray leaves our scene. We’d also then need to do this for enough rays to give us a clear enough idea of our bounce lighting. Our Polygon Soup doesn’t give us a fast way to perform these kinds of computations, which is why *spatial partitioning algorithms* like a OctTree, or more suitably for this example, a Bounding Volume Hierarchy (BVH) would be used.

This concludes my brief over view of the Polygon Soup, and Unity’s version of it. I’ve started looking at some more ways to solidify this “soup”, or at least better manipulate it dynamically. Check here on Twitter/X if you want a little preview.