Meshes, Textures & Formats

A point cloud has no surface - only points with gaps between them. Meshing (surface reconstruction) is the process of building a continuous surface over those points, almost always as a polygon mesh: a web of small flat triangles whose corners (vertices) sit on or near the measured points, their shared edges knitting into a skin that approximates the real surface. Where the cloud was a fog of dots, the mesh is a solid-looking, renderable object - the thing most people picture when they imagine a '3D scan' of a statue or a facade.

Turning scattered points into a good mesh is a real computational problem, because the algorithm must decide which points to connect and how to bridge gaps. Different methods make different trade-offs: some wrap the points tightly, faithfully following every bump and also every bit of noise; others (a well-known family fits a smooth implicit surface to the points) produce smoother, watertight results that fill small holes gracefully but can round off genuine sharp detail. The honest tension runs right through meshing: follow the data too faithfully and you mesh the noise; smooth too much and you erase real features. Holes are a particular challenge - wherever occlusion left no points (behind objects, above ceilings), the mesh must either leave a gap or invent a surface that was never measured, and an invented surface is no longer evidence. Good practice keeps meshed-over holes honest and flagged, because a watertight model can hide exactly where the data was missing.

It is worth being clear about when you even want a mesh. For pure measurement, sectioning and scan-to-BIM modelling, many professionals work directly from the point cloud and never mesh at all - the points are the truest record, and meshing only adds interpretation and error. You reach for a mesh when you need a continuous surface for a specific purpose: photorealistic visualisation, rendering and VR; a watertight model for 3D printing or fabrication; measuring surface area or volume of an irregular object; heritage artefact documentation; or simply a lighter, friendlier object to share than a billion raw points. So meshing is not an automatic next step after cleaning - it is a deliberate choice, made when the job needs a surface rather than a set of measured points. Decide what the representation is *for*, then decide whether to mesh.

A mesh built straight from a dense cloud is enormous - potentially hundreds of millions of tiny triangles, one region of a scan enough to choke a laptop. Two further steps make a mesh genuinely usable: decimation to tame its size, and texturing to make it look real.

Decimation (mesh simplification) reduces the triangle count while preserving the overall shape as closely as possible. A good decimation algorithm is clever about where to remove detail: it keeps many small triangles where the surface is curved or intricate, and collapses large flat areas - a plain wall - into a few big triangles, because a flat plane needs no more. Done well, a mesh can often be reduced dramatically with little visible change, turning an unusable model into one that renders smoothly and shares easily. The trade-off is the obvious one and it is a judgement call: every triangle removed is a little shape lost, so you decimate to the lightest mesh that still carries the detail the job needs - aggressive for a quick visualisation, gentle for a heritage record. More triangles is not better; the right count is the one the purpose requires, and the maximum is almost never it.

Texturing is what makes a mesh look like the real thing rather than a grey clay model. The photographs taken during capture are projected onto the mesh and baked into texture maps - images wrapped onto the surface so that the colour, the grain of stone, the lettering on a sign, the patina of age all appear in place. Texturing is the difference between a shape and a convincing likeness, and it is why photogrammetry and neural methods, which are photo-rich, produce such compelling textured models. But a crucial honesty: texture is appearance, not geometry. A beautifully textured mesh can make a rough, low-detail surface look highly detailed - the eye reads the photo, not the shape beneath - so you must never confuse visual richness with measured accuracy. A convincing texture on a coarse mesh is still a coarse mesh. For anything dimensional, trust the geometry and the underlying points, and treat the texture as what it is: a photograph draped over a surface, superb for communication and documentation, and no substitute for the measurement underneath.

Whatever representation you choose, it lives in a file format, and the format decides what information is carried, how big the file is, and which software can open it. You do not need to memorise every format, but you do need a working map, because choosing one is a practical decision with consequences.

Think of the landscape in families. For point clouds, the key names are E57, an open, vendor-neutral format that stores points with colour and also preserves scan structure and imagery, making it the workhorse for exchanging clouds between different software; and LAS, with its compressed sibling LAZ, long standard in surveying, aerial LiDAR and GIS, efficient at storing huge point sets with classification. PLY is a flexible open format that can hold either points or a mesh, common in research and also used for Gaussian-splat data. For meshes, OBJ is a widely supported format that stores a mesh together with references to its texture images, the common currency for visualisation and general 3D work; PLY again appears here for meshes. Then there are software-specific formats - Autodesk's RCP/RCS indexed point-cloud formats, for instance, which plug a cloud efficiently into Revit and Civil 3D workflows - fast and convenient inside their ecosystem but not open exchange formats. And finally, the BIM-bound end: once you model from the cloud, the deliverable is a BIM model, exchanged through IFC, the open standard for building models - note that IFC carries the *model*, the authored objects, not the point cloud itself.

The unifying idea is interoperability: captured data has value only if it can move to wherever it is needed, and formats are where that succeeds or fails. A file in a format the recipient cannot open is worthless to them; a file converted carelessly can silently lose colour, intensity, classification or scan structure. So the sensible discipline is to archive and exchange in an open, well-supported format - E57 or LAS/LAZ for clouds - keeping a clean master that any tool can read, and then deliver to each destination in whatever it reads best (an RCP for a Revit team, an OBJ for a visualiser, an IFC for the model handover). Choosing a format is really choosing what you keep and who you can work with - a genuine design decision, not an afterthought. And because format support, versions and BIM-exchange requirements change, confirm the current needs with the receiving team rather than assuming; the names here are illustrative of the landscape, not a fixed specification.

Pull the threads together and a single practical principle emerges: there is no one 'best' representation of captured reality - there is only the right one for a given purpose, and a fluent professional chooses deliberately rather than defaulting.

Match the representation to the job. Need to measure, section or model to BIM? Work from the point cloud directly - it is the truest record, and meshing would only add interpretation and error; keep it in E57 or, indexed, in RCP for your BIM tool. Need a photorealistic visualisation, a render, a VR walk-through, or a light model to share? A textured mesh (OBJ) is right - decimated to a sensible weight, textured from the photos. Need a watertight object to 3D-print a component or a heritage artefact? A carefully meshed, hole-filled model. Need to hand a model to the design and construction team as a coordinated, intelligent basis? That is the BIM model (IFC), authored from the cloud. Often a single project produces several of these from the same capture: the master cloud for measurement and modelling, a decimated textured mesh for presentation, and a BIM model for coordination - all legitimate, all derived from the one reality, each fit for its own use.

Two honest cautions to carry. First, every transformation is lossy and interpretive: points to mesh adds assumptions and smooths or invents surface; decimation sheds shape; texturing dresses appearance over geometry; format conversion can drop attributes. So keep the cleaned master cloud as your source of truth, derive the other representations from it, and never treat a downstream product - a pretty mesh, a light web model - as the authoritative measurement. Second, the more convincing a representation looks, the more careful you must be: a gorgeous textured mesh invites people to trust it dimensionally, and it may not deserve that trust. Anything genuinely binding - accurate quantities, survey-grade measurement, anything with legal or structural weight - comes back to the verified geometry, the spec, and a licensed surveyor, not to whichever representation looks most real. Choose the representation for what it is *for*; keep the master honest; and let the purpose, not the prettiness, drive the decision.