How Thousands of Structures Become a Responsive Scene
Human Atlas has to preserve the identity of thousands of anatomical pieces while presenting them as one responsive scene. This chapter focuses on the runtime boundary between what the manifest knows, what the GPU draws, and what the interaction system must still pick accurately. Understanding that division explains why the viewer can change visibility, separation, and selection without creating one independently rendered object for every source mesh—and why the design still carries memory and device limits.
Three jobs that should not be confused
The atlas enters the runtime as a manifest plus binary chunks. The manifest knows the semantic and geometric description of each part: its element ID, name, concept ID, display system, chunk location, byte offsets, vertex and index counts, and bounds. The binary chunks carry the positions, normals, and indices. Those two forms of knowledge are related, but they serve different jobs. The manifest answers “what is this and where is its geometry?” The buffer answers “which vertices and triangles can be drawn?”
A third job begins once the scene is interactive: the browser must decide which part is visible, where it should be translated during separation, and whether it is selected. Those decisions change often. The source geometry and the semantic relationships should not have to be rebuilt every time a reader hides a system or moves the explosion slider. Human Atlas therefore separates three concerns: data identity, visible rendering, and changing scene state.
The distinction is easiest to see with a selected multi-piece concept. The manifest can say that one named concept contains many part IDs. The renderer can place those parts into a shared system batch. The interaction layer can still respond to a hit on one particular part and highlight the selected elements. “The concept,” “the rendered batch,” and “the picked part” refer to overlapping but non-identical sets. A system that collapsed them into one object would make at least one of the atlas's main actions less precise.
The scene keeps individual picker meshes for this reason. A picker is not an extra visible copy intended for the reader; it is interaction geometry that lets a ray from the camera test a particular part. At the same time, loaded geometries are merged by display system for visible rendering. The result is a deliberate split: the scene draws grouped geometry, but it preserves per-part identity for selection.
That split also clarifies ownership. The manifest owns stable descriptions and byte ranges. The scene owns the current visibility, translation, and selection state. The render group owns the efficient visible geometry for a system. The picker path owns the question “which source part did this pointer reach?” No one component has to pretend that all four questions are the same.
The diagram is not a catalogue of internal files. It is a model of the interfaces that make the scene work. A concept selects parts, a chunk stores their indexed geometry, a render group batches them, a picker retains their hit identity, and scene state coordinates what the reader currently sees.
How one part reaches a batched render
When a model chunk loads, the scene reads each part's position, normal, and index ranges from the received buffer. It creates a geometry view over those ranges and records the part's bounds. The geometry is also given a part index so that the later render path can recover which state belongs to which vertices. The part index is the bridge between a large merged buffer and a small per-part state table.
The scene then collects geometries by display system and merges the geometries in each group. A merged group can be rendered as one visible mesh for that system rather than as thousands of separate draw objects. This is the performance-oriented half of the design. Batching reduces the number of visible objects the renderer must manage, while the part index prevents the merge from erasing the identity needed for visibility and selection.
The state table lives on the GPU as a texture. In this context, a texture is not a picture. It is a compact indexed table that shader code can read. For each part, the float state stores a three-dimensional translation and a visibility value. A separate byte texture stores whether the part is selected. During rendering, the shader uses the part index to look up the row for the current vertex, adds the row's translation, and discards fragments whose visibility is off. It can also mix a selection color into the visible fragment.
This arrangement changes the cost of an interaction. Hiding a system or moving a selected piece does not require rebuilding the merged geometry. The scene updates the per-part state texture and lets the same render group interpret the new values. That is why the application can treat translation, visibility, and selection as changing state rather than as new geometry for every user gesture.
The approach is not magic and does not eliminate all work. The scene still creates individual picker geometry for each part, keeps bounds for hit testing and camera fitting, and maintains render materials for the systems. Batching reduces visible draw-object overhead; it does not mean that per-part metadata is free. The architecture trades one kind of cost for another in order to keep the visible render path compact while preserving accurate selection.
The system grouping also connects technical organization to anatomy exploration. A display system supplies a common material and color, and the page can turn systems on or off through the scene state. When a reader hides most systems, the renderer does not need a new semantic model. It changes the visibility value for the affected parts. When a reader selects a concept that spans several systems, selected parts can remain visible even if their systems are not currently in the visible set. Selection therefore acts as a focused exception to ordinary system visibility rather than as a second, unrelated scene.
Why picking cannot use the render batch alone
A merged render group is efficient for drawing, but it is not the most convenient identity boundary for interaction. If a pointer ray intersects the merged mesh, the scene still needs to determine which source part owns the hit. Human Atlas keeps per-part picker meshes and uses their stored bounds to narrow the test before running the more detailed intersection. It filters out invisible parts, and when solid structures are present it can avoid picking the transparent body surface first. This lets a reader reach deeper structures instead of selecting an outer layer merely because it is visually in front.
The distinction between visible and selectable is subtle. A part that is hidden should not respond to a normal pointer selection. A selected part may remain visible even when its system has been hidden, because selection would otherwise disappear as soon as the reader narrowed the view. In isolation mode, the scene sets visibility from the selected set rather than from ordinary systems. The same source part can therefore pass through several visibility rules while retaining one identity.
The body surface is a particularly useful case. The application assigns the integumentary system transparency and does not write depth for it in the same way as solid structures. When solid anatomy is available, the picking path can skip that surface so that it does not block structures behind it. This is not a claim that the surface has been removed from the model. It is a reader-oriented choice about which layer should win when the question is inspection of internal anatomy.
The shader state and the picker state must therefore agree about the current scene. The render path uses the visibility texture to discard hidden fragments. The picker path checks the same logical visibility before accepting a hit. If those paths diverged, a reader could tap something that was not visible or see a structure that the interaction layer could not identify. Keeping them connected is part of the architecture's correctness, not just an implementation convenience.
Loading is part of the scene's first state
The model is divided into chunks so the browser does not need to treat the entire binary payload as one indivisible request. The scene starts up to three asynchronous loading workers, each taking the next available chunk, decoding it, assembling its parts into system groups, and reporting progress as chunks finish. The visible page can show a preparation state while the manifest is present but the geometry is not yet fully ready.
This produces a useful distinction between catalogue readiness and scene readiness. The page can know the names, concepts, and counts after loading the atlas manifest, while the 3D scene may still be waiting for binary chunks. Search and interface state are therefore not identical to complete render readiness. The scene only accepts a pointer selection after its geometry is ready, and a failed chunk load is surfaced as an error rather than silently producing a partial body.
The loader also carries forward the transport boundary from the previous chapter. It can request compressed chunks, decode them when necessary, and verify the resulting byte length against the manifest before creating geometry views. The check does not validate anatomy, but it prevents a truncated buffer from being interpreted through offsets that assume bytes are missing only in someone else's file. If a response fails or the decoded length is wrong, the scene reports that the anatomy file could not be loaded or was incomplete.
Progress is consequently more than a progress bar. It communicates which state the scene owns at a given moment: the application shell may be active, the catalogue may be known, some chunks may be assembled, and the full interactive body may still be unavailable. The repository's architecture keeps those transitions explicit enough for the user to see a loading or error state instead of receiving an apparently complete but internally partial model.
The trade-off: fewer visible objects, more coordinated state
The runtime design solves a specific tension. One independently rendered object per source mesh would make part-level identity intuitive, but it would burden the visible scene with thousands of objects and repeated material work. One undifferentiated mesh would be cheaper to draw, but would make systems, pieces, and selection difficult to control. Human Atlas chooses a middle path: batch visible geometry by system, carry part identity through an index and per-part state, and preserve individual picker geometry for interaction.
That middle path has conditions. It assumes the browser can handle the merged buffers, state textures, picker data, and WebGL resources for the intended atlas. It assumes the manifest's ranges and counts stay synchronized with the binary chunks. It assumes the shader's part-index lookup and the picker path refer to the same part ordering. It also leaves open the device question. The repository documents interaction coverage and browser tests, but it does not provide an independent performance benchmark across phones or a physical-device study that would establish universal responsiveness.
The architecture also does not improve anatomical fidelity by itself. Batching can make a simplified mesh responsive; it cannot restore detail removed during optimization. A state texture can move a piece cleanly; it cannot make an exploded location anatomically meaningful after spatial relationships have been replaced by layout offsets. Rendering efficiency and source authority are separate properties.
That separation is the most important conclusion of the runtime. Human Atlas remains interactive because it gives each concern a precise boundary: semantic records identify what a part means, binary ranges provide what can be drawn, render groups make the visible workload manageable, per-part state changes the scene, and picker geometry preserves the answer to “what did the reader select?” The next step is to test those layers together, asking how one named concept can persist across assembled, layered, exploded, and isolated views without becoming a different atlas.