#process note

[processzine-org]

BOUNDARY OUTPUT (SUBSTRATE.HOST process note)

I’ve been building a small tool for SUBSTRATE.HOST called Boundary Output.

It’s not a “mind visualiser.” It’s closer to an NCC analogue: a correlate generator.

Neural activity is to mind what a Boundary Output is to a Host.

A correlate, not an exposure. Telemetry, not testimony. What interior looks like from the outside when it couples to a measurable world.

INTERIOR: INACCESSIBLE stays intact for a reason: we can instrument the boundary, not enter the room.

There’s a useful asymmetry here:

Interior (qualia / “what it’s like”) → private, first-person, non-transferable.

Boundary Output (fields / traces / telemetry) → public, third-person, measurable, compressible.

In neuroscience, NCCs are reliable regularities that track experience — but they aren’t the experience. A map isn’t a city. A waveform isn’t a dream. And measurement changes what’s measured.

So Boundary Output becomes a kind of interface ritual: stable patterns that emerge when an inaccessible interior repeatedly “presses” against a system.

A public trace of a private event.

Modalities (current mapping)...

Each host TYPE routes to a different output modality — not because one is “true”, but because different boundaries produce different kinds of legible disturbance:

CEPHALOID → FILAMENT Void/corona/horizon behaviour. Dense core, boundary-shear tendrils, event-horizon vibe.

MICROBIAL → MURMUR Diffuse haze. Particulate swarm logic. Emergent “starlings” field drift.

LIMINAL FAUNA → FERRO Looks alive. Parasitic. Host-like. Magnetic coupling / “Venom channel”.

CELLULAR → TRACE Correlates + measurement aesthetic. Structured morph cadence. Readable instrumentation.

SYMBIONT → GLYPH Recursion as coupling. Self-reference loops, mirroring, Arrival-like rings as interface language.

(Still prototypes. Still moving targets. But the taxonomy feels… defensible.)

The rule...

Correlate, not content. We log the disturbance, not the interior.

I’m sharing a short screen recording (FERRO) and a few stills from other modes as a checkpoint — partly for documentation, partly because the “instrumented boundary” metaphor keeps widening the longer I stare at it.

If anything here feels like it “explains” the interior, it’s doing the opposite. It’s a reminder that explanation isn’t the same thing as access.

[words-and-coffee]

Sliced from bone, my life hung like a jaw—faultless. And unforgivable.

Franny Choi, The World Keeps Ending, and the World Goes On - Process Note

[sublingual-art]

In blender I built out a crosshatching shader, a more generalized version of the "Decayed hatch" shader I was working on earlier in the year. It lets me add or subtract two patterns each for the highlights and midtones, which can all be adjusted separately.. I decided to go for the most complicated version of my illustration shader and if I need to later make some versions with less layers. Now all that's left is to build a corresponding resource type in godot and move on to my character shader.

This takes a few secs to compile in blender, I think because I have a copy of the glossy and diffuse BSDF node for each pattern, and four different image textures. In godot the lighting is only calculated once per pixel & my exporter is smart enough to add only one of each pattern to the resource. The rest is just mixing and basic math so I'm hopeful I'll be able to use it on large flat surfaces to reduce the "pinstriping" effect. If not I could make a version without highlights for that purpose.

[sublingual-art]

Last night's work - my adventure game scene viewer now stores multiple versions of each shader's parameter adjustments, per subview. For example, looking at this shack from far away (left) the highlight hatch is diagonal and the hatches are widely spaced, but when the player approaches (right) the hatching straightens out and gets tighter.

This will also let me make per-material tweaks to compensate for the inconsistancies between blender and godot which I've spent the last few weeks trying to dial in.

[sublingual-art]

Process Note

Here is the problem I'm currently facing porting my illustration shader from Blender Eevee (right) to Godot (left)

I'm doing (I think) the same math to each engine's diffuse shader on an array of spheres on plane with the light source and a surface one unit behind. To get the same result on the floating spheres I have the "step" value set to two different values in either. But when I do that the rear plane, which is one unit behind the light source is much larger in blender.

I figure the issue with the difference between the spheres and the plane might have something to do with the angle of the surface relative to the light but adjusting the roughness/metallic settings in godot doesn't affect it. That could have to do with my implementation but I think at this point I have a choice to either attempt to dig into what exactly the lighting math is doing or try to set up a conversion factor to address each issue and then test at different scales.

Also making a note for myself that directly comparing the tones in this setup shows a .0011 difference in value between the two gray tones. Something I noticed in an earlier iteration was that it seemed like the color space was shifting but at least the tone seems to be close on paper. This will also need to be something I make a testing environment for and figure out a transform.

I think more generally I face a choice here to either dig down and get as close as I can to a system where scenes I make in blender look 1:1 identical in godot, which could be an endless task, or just compensate for it later. Probably I spend some time rectifying the shaders for this test room and then keep working on one of my other test rooms to see how much the difference gets in the way in practice.