What the Atlas Actually Represents
Human Atlas is not a neutral window onto an anatomical file. This chapter follows the current release from its BodyParts3D source through the transformations that make it usable in a browser. The goal is practical: by the end, you should be able to tell which identities and relationships the atlas preserves, which properties it changes for delivery and rendering, and why an optimized adult-male reference must still be read as a bounded educational model.
The release begins with a reference, not a blank canvas
The current Human Atlas release starts with BodyParts3D 4.0, attributed to The Database Center for Life Science. The repository records the source archive, English names and relationships, the CC BY 4.0 license, and the publication associated with the dataset. That provenance establishes what the application is adapting. The application itself adds a browser-facing layer: it reorganizes coordinates for its scene, prepares compact geometry, assigns display systems and colors, supplies search and inspection behavior, and writes the source and scope into its credits.
This distinction is easy to miss because a reader encounters the finished interface rather than the upstream files. The atlas looks like one coherent product, but its authority is layered. BodyParts3D supplies the reference anatomy and its named relationships. Human Atlas supplies the particular way that reference is packaged, displayed, and explored. The application can make a source easier to navigate without becoming the source or silently expanding its coverage.
That layered authority also clarifies what a successful release has to preserve. The upstream material is not only a collection of surfaces. It includes names, element relationships, and the association between a named concept and the elements that can represent it. The application adds a display system and a reader-facing explanation, but those additions should not be confused with new upstream anatomical evidence. A color assigned to a system can improve orientation; it cannot settle a disputed boundary in anatomy. A short explanation can make a major organ easier to approach; it cannot turn a visual reference into a clinical knowledge base.
The release is consequently best understood as a translation with a declared purpose. It translates a source into units that a browser can load, draw, hide, move, and search. Every useful translation risks losing something, so the important question is not whether the application is identical to the source in every detail. It is whether the properties needed for its stated purpose remain traceable, and whether the changed properties are disclosed well enough that readers do not assign them more authority than they deserve.
The current manifest makes the release's scope unusually concrete. It describes an adult-male reference anatomy, 2,234 source meshes, and 3,432 named concepts. The meshes are the individually represented geometric elements that the viewer can render and select. The concepts are the named FMA records that can point to one or many of those elements. These counts belong to different layers. A concept count is not a count of separate visible objects, and a mesh count is not a count of complete organs or independent explanations.
That difference matters for provenance as well as for interaction. The repository says that all 2,234 source meshes remain represented, while the combined hierarchy contains concepts that may reference multiple meshes. A later optimization step can reduce the number of triangles in a mesh without removing the mesh's place in the manifest or its relationship to a named concept. In other words, the release preserves the units needed for selection and semantic navigation even while it changes the geometric representation used to draw them.
The application also divides the visible anatomy into 15 display systems. Those systems are useful for turning a large body into manageable views: a reader can focus on a group rather than search through every visible surface. But they are application-level groupings with curated colors and descriptions. They should not be mistaken for a claim that the source has been reduced to 15 exhaustive or mutually sufficient explanations of human anatomy.
Scope is a data property
The reference is explicitly adult male. The attribution describes BodyParts3D as a reference anatomy based on TARO MRI and anatomical illustration refinements, not a complete model of every human structure or variation. The interface calls itself educational and not a diagnostic or surgical tool. Those words constrain interpretation of the data, not just the marketing of the page.
For example, it is supported to say that the viewer lets a reader search for a named structure represented in this atlas and inspect the meshes associated with it. It is not supported to infer that an unrepresented structure does not exist, that the displayed geometry covers every normal variation, or that an isolated mesh is suitable for clinical decision-making. The application can answer questions about how this reference is organized and made visible. It cannot answer questions that require evidence absent from the reference.
The repository mentions historical female reference assets in its attribution, but also states that those assets are not included in the current release. That is an important provenance boundary. A retained note about an earlier revision is not current coverage. The subject here is the present BodyParts3D adult-male release and the interface built around it.
Licensing is part of the same boundary. The repository records CC BY 4.0 and asks that attribution be preserved when the anatomy data is redistributed or adapted. The viewer's source-and-credits panel makes the upstream identity visible rather than presenting the geometry as an unowned visual resource. For a data-rich educational tool, that is more than legal housekeeping. It tells the reader where the represented material came from and which claims belong to the application rather than to the upstream dataset.
From source mesh to checked browser payload
Human Atlas's data lifecycle changes the representation in several deliberate steps. Each step has a different owner and a different failure surface: source files provide geometry and relationships; conversion makes them uniform enough for the scene; optimization reduces geometric cost; packaging makes delivery manageable; runtime checks prevent incomplete bytes from being treated as anatomy.
The source stage begins with an element record and its corresponding OBJ mesh. The converter reads the mesh, uses an English-name comment when one is present, collects vertices and normals, triangulates polygon faces, and records the byte ranges needed to find that part later. It also records bounds, vertex counts, index counts, a concept relationship, and a display system. The result is not a single undifferentiated model. It is a manifest that keeps each element addressable.
The first changes are spatial and numerical. The converter changes positions from millimeters with a Z-up convention into meters with a Y-up convention, and applies a stage translation so the anatomy rests in the viewer's scene. Normals are converted into signed 16-bit values. Polygon faces are expanded into triangles. None of these operations changes the intended identity of a named part, but they do change how the browser stores and interprets its geometry. A coordinate conversion is therefore not merely a cosmetic adjustment: it is a contract between the data pipeline and the camera, lighting, bounds, and picking code that will consume the result.
The converter also groups binary data into intermediate chunks when its working blob grows beyond roughly 7 MB. The later optimization stage reads each part's position, normal, and index ranges, simplifies the part with meshoptimizer, compacts unused vertices, and repacks the result into chunks of roughly 4 MB. The source and optimized stages use different chunk boundaries, but the manifest updates the offsets and counts so the viewer can still locate each part. The chunk is a delivery container; it is not the semantic identity of the anatomy.
Each transition has a condition under which it should stop rather than quietly produce a misleading release. A missing mesh, mismatched normal data, or invalid index would make conversion unsafe. An already optimized manifest is rejected by the optimization step rather than simplified a second time. At runtime, a failed response or an incomplete decoded buffer becomes an explicit loading error. These conditions matter because a data pipeline can fail in two ways: it can fail loudly and prevent a bad artifact from being used, or it can produce something that looks plausible while its relationships are wrong. Human Atlas's manifest and checks are designed around the first kind of failure for the cases the repository tests.
The byte offsets recorded for each part are another reason the manifest is central. The browser does not need to search a large binary blob by name. It uses the part's chunk, position offsets, and counts to create the appropriate typed views over the received bytes. That arrangement lets one delivery file carry many parts while the semantic record still points to one specific element. The source mesh remains an addressable unit even though the browser receives it inside a shared container.
Optimization changes density, not the atlas's basic units
The repository configures a 0.2% relative-error setting for per-structure simplification. The current manifest records 6,681,030 source triangles and 2,288,268 final triangles, while preserving 2,234 meshes. Those numbers show the scale of the compromise: the released geometry carries substantially fewer triangles than the source conversion, but the release does not collapse every structure into a single coarse object or discard the concept-to-mesh graph.
“Relative-error setting” needs careful interpretation. It is a parameter in the geometry simplifier, not a medical statement that every anatomical or visual difference is negligible. The repository does not provide a perceptual study or clinical validation of the optimized surfaces. What the setting establishes is the intended engineering constraint for the simplification process. It tells us how the project tried to reduce geometry; it does not prove that every reader, device, or use case will experience the same fidelity.
This distinction also explains why the source triangle count and the final triangle count can coexist without contradiction. The first describes the geometry before the optimization stage. The second describes the current browser-ready payload. The manifest keeps both values so the release can expose what changed. That is stronger than reporting only the smaller number, because it makes the reduction visible instead of allowing “compact” to sound like an unexplained property of the source itself.
The same reasoning applies to a small structure and a large one. The optimizer works per part, and the manifest continues to give each part its own vertex and index ranges after repacking. A small mesh does not disappear merely because a larger neighboring structure shares its chunk, and a large concept does not become one mesh merely because its pieces can be loaded together. Storage proximity and anatomical meaning are separate relationships. This separation is what allows later scene code to batch geometry for efficiency while still selecting a particular element or selecting all elements of a concept.
It also gives the reader a better way to interpret visual differences. If a surface appears less detailed than an upstream OBJ, that may reflect simplification. If its orientation differs from a source coordinate convention, that may reflect the viewer's scene basis. If its position changes during an exploded view, that is a scene-state transformation. These differences are not interchangeable errors. The release's claim is narrower and more useful: it preserves the relationships required by this explorer while adapting the geometry for its browser workload.
Packaging is a runtime integrity boundary
The optimized pieces are packed into 15 model chunks. The manifest records the uncompressed byte length for each chunk and, where available, a gzip path and compressed length. Summed across the release, the gzip payload is 32,956,129 bytes, which is why the README describes the download as approximately 33 MB compressed. The manifest is therefore doing more than naming files: it tells the runtime which representation to request and how large the decoded result should be.
The browser loader treats compression as transport rather than as a new kind of geometry. If gzip delivery is available, it requests the compressed path. It inspects the returned bytes so it does not decompress a payload that the browser has already decoded through content encoding. When decompression is needed, it performs that step and then compares the decoded byte length with the expected uncompressed length in the manifest. A failed response or a length mismatch stops the load with an error instead of allowing a partial binary buffer to enter the scene.
That check cannot prove that every vertex is anatomically correct. It addresses a narrower but essential question: did the browser receive the complete binary object that the manifest describes? Later validation checks index ranges, finite positions, concept membership, and triangle totals. The data lifecycle therefore has two different kinds of trust. Provenance and metadata tell us what the release claims to represent; transport checks help ensure that the browser has actually received the declared representation.
What persists, and what changes
Across the lifecycle, several properties are intended to persist: the source-part unit, its identifier and concept relationship, its display name, its system assignment, its bounds, and the ability to locate its indexed geometry. Those are the properties needed for later selection, search, visibility, and inspection. The browser does not need the original OBJ text to preserve those relationships, but it does need enough structured metadata to reconstruct them.
Other properties intentionally change. Coordinates are reoriented and rescaled. Normals are quantized. Faces become indexed triangles. Geometry is simplified. Binary offsets move as parts are repacked. Compression changes the transport bytes again. Finally, the interface can change a part's on-screen position during separation without changing the stored anatomy. These are different transitions, and conflating them would make it difficult to say what a view or a number actually means.
The key idea is that browser readiness is not the same as source equivalence. Human Atlas creates a representation that is faithful to the relationships it chooses to preserve and optimized for the interaction it intends to support. It does not claim that every byte, triangle, coordinate convention, or visual placement is unchanged. That is a healthier contract than calling the result simply “the anatomy.”
For readers, the practical test is to ask which layer a statement belongs to. “This concept contains many selected pieces” is a semantic statement. “This payload has a declared decoded length” is a delivery statement. “This surface is rendered with fewer triangles than the source conversion” is a geometric statement. “This piece moves away from the body when the slider changes” is a scene-state statement. Each can be true at once, but none should be used as evidence for the others. Keeping those boundaries clear is how an interactive reference can be both technically efficient and intellectually honest.
The next question follows directly from this contract. Once the manifest contains thousands of preserved, searchable parts and the chunks can arrive intact, how can the browser render and manipulate them without treating every part as a separate visible object? The answer lies in the runtime's division between semantic identity, batched geometry, and per-part scene state.