Spherical Portals, Dark Energy, and the Dromed Brush Hierarchy

Source: Spherical portals explain dark energy? by optozorax (Ilya) · used as the primary text for this companion

optozorax's Spherical portals explain dark energy? is a physics simulation video about what happens when a portal is no longer a flat doorway but a closed surface — a sphere. The claim is that a spherical portal can only stay stable if you allow a specific distribution of negative energy around it, and that the self-force this produces looks suspiciously like dark energy. This companion does two things with that idea. First, it walks through the physics as carefully as a transcript-locked video allows. Second, and more usefully for us, it uses the spherical-portal mental model as a lens onto a very different kind of portal: the ones the Looking Glass Dark Engine generates every time you press Tools → Portalize in the Dromed editor for Thief II: The Metal Age. The mapping is not literal — one is curved spacetime, the other is constructive solid geometry — but the structural analogies are strong enough to seed a blueprint for a portalize/CSG/BSP level pipeline in CatGame, and to force a rethink of how the cat character controller should query the world.

What the video is actually about

optozorax (Ilya) is the author of Portal Explorer, an open-source web ray-tracer for "mind-blowing portals" — monoportals, Möbius portals, Hopf-link portals, and the recursive "portal in portal" case. His earlier videos establish the framework the spherical-portal video builds on, so they are worth stating before the spherical case:

• Space-bending axiom. A portal is not a scanner that disassembles and reassembles you; it bends space so that two distant regions become locally adjacent. The portal "surface" is just where you choose to cut the bending. Because of this, a portal's behavior does not depend on the shape of its teleporting surface — a flat cut and a semicircular cut produce identical physics. This is the load-bearing axiom for everything that follows.
• Moving portals change speed. If a portal moves onto a stationary object, the object exits the paired portal with the portal's relative velocity. Portals are not passive windows; they are velocity transformers.
• Gravity must be teleported too. Naive gravity breaks energy conservation through a portal. The fix is to solve Poisson's equation on the curved (portal-bent) space itself, so the gravitational field is defined patch-wise on the glued manifold rather than copied through the doorway.

The spherical-portal video extends this to a closed portal surface. Instead of two paired flat portals, you have a single sphere whose interior is glued to somewhere else (a pocket dimension, or back onto itself). The simulation shows that to keep such a sphere from gravitationally diverging — collapsing or exploding — you need a shell of negative energy (the video frames this as Zero Point Energy) distributed in polar coordinates around the surface. The residual self-force the configuration exerts on itself then mimics the cosmological constant: it looks like dark energy pushing things apart. The punchline is the analogy in the title — spherical portals "explain" dark energy because the stabilization cost of a closed portal and the observed accelerating expansion have the same sign and shape.

A Dromed primer, for people who never carved a void

The Dark Engine is the runtime Looking Glass built for Thief: The Dark Project (1998) and Thief II: The Metal Age (2000). Dromed is its level editor. The single most important thing to understand about Dromed is its inversion of the usual "add geometry" mental model:

This is constructive solid geometry (CSG) with a sign convention. A brush is a convex primitive (cube, cylinder, pyramid, corner-apex pyramid) tagged with an operation. The documented brush family includes: fill solid, fill air, fill water, flood, evaporate, solid→water, solid→air, air→solid, water→solid, and blockable. Fill-solid adds mass (a pillar); fill-air subtracts it (a room); the conversion brushes flip the medium at an existing boundary. Crucially, order matters:

If you swap steps 2 and 3 you get a different world. Dromed lets you reorder the brush list after the fact, because nobody authors in the perfect evaluation order. The command that does this evaluation is literally called portalize — "make a 3D world out of brushes" — and optimize is the production-quality variant that reduces poly count. After terrain comes a cascade of dependent build passes, each consuming the previous one's output:

That cascade is the part most modern editors hide from you. In Dromed the dependency is naked: change a brush, forget to re-portalize, and the 3D view lies; change a room, forget to rebuild rooms, and sound goes dead; change terrain, forget to recompute pathfinding, and AI freezes. The brush hierarchy is the source of truth; everything downstream is a derived cache that must be invalidated by hand.

The object hierarchy: how you paint entities into the carved terrain

Carving the void is only half the level. The other half is populating it, and Dromed does this with an object hierarchy that is philosophically explicit about being Platonic:

• Archetypes are the ideal forms. The Sword lives in the Object Hierarchy; every concrete sword in the level inherits from it. Edit the archetype and all descendants change — give the table archetype a fire stim and every table now burns.
• Concrete objects are the particular things Garrett can bump into, positioned in the carved terrain. You create one by picking an archetype and dragging it into the map.
• Metaproperties are bundles of properties you can attach/detach at will — e.g. M-PosedCorpse packages half a dozen properties so you apply one tag instead of six.
• Links are typed relationships between objects: AIPatrol from a patrol point to another, AIWatchObj to make a guard watch a region, Contains, Weapon, and so on. Scripts resolve link targets with selectors like *Chest (direct descendants) or @Chest (all descendants) or <5.3:Chest (within a radius).
• Stims & Receptrons are the event bus: a stim (Fire, Holy, Knockout) hits a receptron on an object and triggers a response. This is how the world reacts to the player without hard-coded switch statements.

So "painting entities into terrain" in Dromed is: carve the void with ordered CSG brushes, portalize into a cell graph, then drop concrete objects (descended from archetypes, decorated with metaproperties, wired with links) into the cells. The player character is just another concrete object descended from a player archetype, governed by the same property/link/stim machinery as a candle.

How mods actually work

Thief II modding survived because of NewDark, a community patch that became the de facto engine. Levels are .mis (or .cow) mission files; the gamesys.gam holds the archetype hierarchy. Original missions are OMs, fan missions are FMs. The elegant part is DML (Dark Mod Language) dbmods: instead of redistributing a patched mission, you ship a small miss20.mis.dml that is fingerprinted against eight object positions and applied as an overlay at load time. You can fix a broken FM without ever touching the original bytes. Tools like DarkDB read/write the mission tables directly; KCTools rebuilds lightmaps and exports .bin models. The whole ecosystem is built around treat the mission as a database, not a blob — which is exactly the stance a modern engine should take toward its level file.

The mapping: spherical portals ↔ Dromed portalize

Here is where the two threads meet. The mapping is analogical, not physical, but each row holds up structurally.

The deepest shared claim is the surface-shape axiom. In the physics video it says the portal cut's geometry is irrelevant to the physics; only the gluing matters. In a BSP/portal renderer it says the portal polygon's exact triangulation is irrelevant to visibility; only the leaf adjacency matter. Once you accept that, "spherical portal" stops being exotic. A spherical fill-air brush is just a cell whose boundary is a sphere instead of an axis-aligned box, and the portalize pass treats it identically: it becomes a node in the cell graph, connected to its neighbors by portal cuts wherever the sphere intersects other brushes. The rendering mesh is a detail; the graph is the truth.

A high-level blueprint for a CatGame portalize/CSG/BSP pipeline

Stated cleanly, the goal is a level pipeline where the source of truth is an ordered list of CSG brushes (signed convex primitives) plus an object hierarchy, and everything else — render mesh, vis graph, sound graph, lightmaps, AI nav, collision — is a derived cache produced by a portalize-style build pass and invalidated on edit. Concretely:

The payoff of treating the cell graph as the truth is that the spherical-portal video's two hardest problems become features rather than special cases. Gravity through a portal is "solve the field on the graph" — which is what Dromed already does for sound. Velocity through a moving portal is "transform velocity on cell transition" — which a graph-native controller does naturally where an AABB-sweep controller does not.

How this reshapes the cat character controller

A controller written for an axis-aligned, box-cell world asks three questions every frame: am I on the ground, am I hitting a wall, am I hitting a ceiling — answered by sweeping an AABB against brushes. That model breaks the moment a cell is spherical or a portal is non-trivial, because "ground," "wall," and "ceiling" are no longer aligned with the cell's boundary. The graph-native reframing:

• Cell-relative framing. The cat's pose is expressed relative to its current cell, with the cell's local "down" defined by the cell's medium and any gravity field solved on the graph — not by a global (0,-1,0). Walking on the inside of a spherical air cell is just "down points at the nearest boundary."
• Transition as a first-class event. Crossing a portal edge is not a collision to be resolved but a transition to be honored: apply the velocity transform (the moving-portal rule), swap the cell reference, recompute local gravity from the new cell's field. This is where the physics video's "portals change the speed of anything going through them" becomes a controller feature.
• Ground from the graph, not from raycasts. Ground detection asks the cell graph "which neighboring cell is below me and walkable," using the AI nav cells (the pathfinding database) as the authority — the same database Dromed's guards use. The cat and the AI share a locomotion substrate.
• Sound and perception ride the same graph. If the cat's footsteps and an AI's hearing both propagate on the room/sound graph, then sneaking past a guard through a portal-rich level behaves consistently: sound bends through portals exactly the way the physics video says gravity should. Stealth gameplay falls out of the geometry for free.
• Momentum and the "self-force." The emergent graph behavior (vis, sound, AI) is the system's self-force. A controller that is aware of it can lean on it — e.g. a "pounce" that is only valid along a cell edge the graph says is traversable, rather than a hardcoded arc.

The short version: the cat stops being a physics body loose in a box world and becomes a graph citizen whose locomotion, perception, and momentum are all defined against the portalized cell graph. That is the real lesson both optozorax and Dromed are teaching — the connectivity is the world; the surfaces are just where you chose to draw the cuts.

Companion glossary

1. CSG (Constructive Solid Geometry) — Building shapes by union/intersection/subtraction of solid primitives. Dromed's fill-air/fill-solid brushes are signed CSG operations.
2. BSP (Binary Space Partition) — A tree that recursively splits space by planes; gives fast point/segment queries and yields convex leaves. The leaves' shared faces are the portals.
3. Portalize — Dromed's command to evaluate the ordered brush list into a renderable 3D world plus its cell/portal structure. "Make a 3D world out of brushes."
4. Cell / visleaf — A maximal convex air region in the portalized world; the unit of visibility, sound, and AI navigation.
5. Room database — Dromed's secondary build that groups cells into rooms for sound propagation and AI perception.
6. Object hierarchy — Dromed's archetype tree; concrete objects inherit properties from archetypes, editable en masse.
7. Metaproperty — A reusable bundle of properties attachable to any object.
8. Link — A typed relationship between two objects (patrol, watch, contains), resolved by scripts via selectors.
9. Stim / Receptron — Dromed's event system: a stim hits an object's receptron and triggers a response.
10. NewDark — The community engine patch that became the standard Thief II runtime and enabled modern FM modding.
11. DML / dbmod — A fingerprinted overlay applied to a mission at load time, letting mods patch without redistributing the mission.
12. Monoportal — optozorax's term for a single portal surface that glues a region to itself or elsewhere, as opposed to a paired two-surface doorway.
13. Space-bending axiom — optozorax's claim that a portal's behavior is independent of its cut surface's shape; only the gluing matters.
14. Self-force — In the video, the residual force a stabilized spherical portal exerts on itself, argued to mimic dark energy. In CSG, the emergent behavior (vis/sound/AI) the cell graph produces without being authored.

Caveats and limitations

This companion sits on top of two layers of uncertainty. The first is the video itself; the second is the analogical mapping. Read both before treating any claim as settled.

Where this points next

The companion is deliberately high-level so it can spawn follow-ups rather than close them. A few directions worth keeping alive: a spec for the brush-list level format (mission-as-database, with DML-style overlay patching); a prototype portalize pass that emits a cell graph from ordered signed brushes, including spherical primitives; a graph-native locomotion experiment that re-expresses the cat controller against cells instead of AABB sweeps; and a sound-propagation pass solved on the cell graph as a direct nod to both Dromed's room database and optozorax's "solve Poisson on the glued space." The unifying bet is the one both sources make: get the connectivity right and the surfaces take care of themselves.

Related transmissions

If the "connectivity is the world" argument lands for you, the ECS-architecture post is the same idea at the component level, and the oscilloscope-renderer companion is a sibling case of "let one primitive generate everything." The Vulkan tile-rendering post is the rendering-side counterpart to the vis-graph story here.