Creator, system designer and cross-renderer implementer.
Mathematical visualization & product systems
Fractilate
Equations become a visual medium.
A public platform in active development for generating and exploring visual structures built from fractals, equations, landscapes and encoded signals across web, desktop and browser-studio implementations.
Live product · Public gallery · Cross-renderer work



Public creation, gallery and decoding surfaces backed by shared rendering and scoring ideas.
Separate rendering experiments became a usable public creation and decoding platform.
The live product, approved public renders and a recoverable-message decrypt tool.
01 / The difficult question
Can mathematical structure become something people shape, not only solve?
Fractilate begins with equations, fractals, attractors, landscapes and encoded signals, then treats them as material for composition. The public product frames mathematical rigor and visual creativity as complementary rather than opposed.
The engineering challenge is equally important: different runtimes must produce compatible visual structure, allow fast exploration and preserve enough provenance for an output to be reproduced or decoded.
02 / Brian's contribution
Build the medium and the feedback loop.
Brian developed web, Python desktop and browser-studio implementations of a custom rendering core, with parity tests used to compare implementations. He built composition scoring and preference-learning workflows around generated outputs.
He also developed recoverable message encoding using a variant of the Correspondence Matrix representation. The public decrypt surface accepts an encrypted message file, a key and an optional key manifest; compatible Node and .NET encoding connects the mathematical work to another application.
03 / How the system works
Equations, fractals, landscapes or encoded signals.
→Generate compatible visual forms across runtimes.
→Layer elements and explore ranked variations.
→Keep, share or decode the chosen result.
The public product exposes creation, a gallery of generated work and a decrypt tool; deeper implementation details remain an engineering account rather than a public benchmark claim.
04 / Cross-runtime discipline
Creative variation still needs reproducible structure.
Parity tests compare rendering behavior across the web, desktop and browser-studio implementations. That test surface matters because visual differences can come from the equation, the renderer or the runtime.
Preference learning does not replace artistic choice. It narrows exploration and records selection signals while the person remains the final judge of which composition is worth keeping.
Parity & preference
Verify structure. Learn taste separately.
From renderer experiments to a public product
Separate experiments became public creation, gallery and decrypt paths supported by shared rendering and scoring ideas.
Separate structural verification from taste
Parity protects shared rendering intent, while preference signals help a person navigate a large creative space without claiming an objective definition of beauty.
Scope & limitations
A platform in development, not a claim of mathematical novelty.
The public gallery demonstrates outputs and the current product direction. It does not by itself validate cross-runtime parity, scoring quality or the uniqueness of every generated composition.
The encoded-message feature is described as recoverable application functionality, not as a claim of audited cryptographic security. Product surfaces, available tools and generated work may continue to evolve.
Inspect the evidence
Use the public product, inspect the gallery and test the decrypt path.
Useful when
Your experimental product team is turning mathematical models into visual systems that must be generated, compared and refined across runtimes.
Explore fractional R&D direction →