Meshes & Breps

Brep stands for boundary representation - a way of describing a solid by its boundary: the surfaces (faces) that enclose it, the edges where they meet, and the vertices at the corners, all stitched into a watertight topological whole. In Rhino/Grasshopper a Brep can be a single trimmed surface, an open polysurface, or a closed solid. The faces are NURBS surfaces, so a Brep is smooth and exact: a cylinder is a true cylinder at any zoom, a curved wall has real, continuous curvature, and dimensions are precise. This is what you want for design intent, precision modelling, and documentation - the shapes you draw, loft, extrude and boolean are Breps.

The strengths come with costs. Breps are computationally heavy: trimmed NURBS with their curve boundaries carry a lot of maths, and operations like boolean unions, intersections and offsets can be slow or occasionally fail on messy input. They're also the wrong currency for many downstream tools. When you need to run a structural or environmental analysis, drive a 3D print or CNC path, or push geometry into a game engine or renderer, the smooth exactness becomes a liability - those tools want something simpler and more uniform. That's where meshes come in - not as a downgrade, but as a different currency built for a different set of jobs.

A mesh describes a shape as a polygon net: a list of vertices (points in space) and a list of faces, where each face is a flat triangle or quad referencing three or four of those vertices by index. There's no curvature inside a face - a mesh approximates a curved form with many small flat facets, the way a geodesic dome approximates a sphere. More faces means a closer approximation and a heavier file; fewer means coarser but lighter. Meshes usually also carry vertex normals (used to fake smooth shading) and can hold colours or texture coordinates per vertex.

The deep reason meshes matter is that their data is brutally simple: just points and integer face lists. There's no trimming, no NURBS evaluation, no curved-edge bookkeeping - a face is three or four numbers. That simplicity is exactly what makes meshes fast to process, easy to slice, and universally interchangeable. It's also why the same shape is a small, nimble object as a mesh and a heavy one as a Brep. In Grasshopper you'll build meshes with components like Mesh Sphere/Box, Mesh Surface (mesh a surface into a UV net), and Construct Mesh (assemble one from your own vertices and faces), and read them apart with Deconstruct Mesh (out come vertices, faces, colours, normals) and Face Normals or Mesh Explode. Plug-ins like Weaverbird and LunchBox add smoothing, subdivision and clean mesh operations.

Two whole worlds run on meshes, and understanding why makes the whole distinction click. Analysis first. Finite-element structural tools, daylight and energy engines (Ladybug/Honeybee route geometry to Radiance and EnergyPlus), CFD, acoustic solvers - they discretise the world into small elements and compute over them. A mesh is that discretisation: each face is a ready-made element with a clear area and normal. Feeding smooth Breps to these tools just forces them to mesh it first anyway, so you may as well control the mesh yourself - a well-made mesh (even face sizes, clean triangulation) gives better, faster, more trustworthy analysis. (As always, real structural and environmental sign-off belongs to qualified engineers; the mesh just feeds the tool.)

Fabrication second. A 3D printer slices your model into layers and needs a closed, watertight mesh (STL/OBJ are mesh formats) - it cannot read a NURBS Brep. CNC and laser paths, robotic toolpaths, unrolled panel nets - all of it either is a mesh or is computed from one. Real-time rendering and game engines are mesh-only too, because GPUs draw triangles. So the pattern across the back half of this course is: design in Breps for control and precision, then convert to a mesh at the moment you hand off to analysis, fabrication or rendering. The mesh is the lingua franca of everything downstream of pure design.

Going from Brep to mesh is easy and routine; the reverse is hard and lossy - know both directions. Brep -> mesh: the Mesh Brep / Mesh component (or Rhino's meshing settings) tessellates a smooth Brep into facets. The critical control is resolution: too coarse and curves look chunky and analysis is inaccurate; too fine and everything crawls. You tune this with mesh settings (density, edge length, max angle) - it's a genuine design decision, balancing fidelity against weight, not a button you ignore. For panelization and fabrication you often want a quad mesh aligned to the form (LunchBox and Weaverbird help) rather than the default triangulation.

Mesh -> Brep is the awkward direction. Because a mesh is only an approximation with no true curvature, you can't perfectly recover the smooth original. You can wrap each mesh face in a flat surface (Mesh Faces to surfaces) - fine when the facets are the design, like a folded-plate or crystalline form - or attempt a NURBS surface reconstruction, which is fiddly and approximate. The honest rule: don't rely on round-tripping. Keep your smooth Brep as the master model and treat meshes as a derived, downstream product you regenerate when needed, rather than converting back and forth. Decide early which type is your source of truth for each part of the definition, and you avoid the most common geometry headaches in this whole module.

There's a third character worth knowing so the picture is complete: SubD (subdivision surfaces). SubD is a newer Rhino geometry type that behaves like a smooth mesh you can sculpt - you push and pull a coarse control cage and the surface stays smooth and organic, blending the editability of a mesh with a smoothness closer to NURBS. It's superb for free-form, sculptural work (furniture, flowing canopies, product-like forms) where a Brep would be tedious to build and a raw mesh too crude. You can convert SubD to a Brep for documentation or to a mesh for fabrication, so it slots naturally between the two - think of it as a smooth modelling tool that still resolves to the two currencies you deliver in.

So how do you actually choose, day to day? Ask what the geometry is for at this moment. If you're designing, dimensioning or documenting something with precise curves - a wall, a curved glazing line, anything going on a drawing - work in Breps. If you're handing off to analysis, a 3D printer, a CNC machine, or a renderer/engine, you need a mesh, made deliberately at a resolution that suits the job. If you're sculpting an organic form, reach for SubD and convert on the way out. And keep one principle above all: decide which type is the source of truth for each part of your model, and let the others be derived from it. Don't scatter conversions through a definition or bounce back and forth; keep a clean master (usually the Brep, sometimes the SubD) and regenerate meshes as disposable, downstream products. That single discipline - matching the type to the task and naming one master - prevents the great majority of geometry headaches, keeps files fast, and makes your definitions legible to anyone who opens them after you.