opensource/Apache2

SHOW:

TODOS # TaskGlDagStartupAndFPS_2026_9_14 Prepared 2026-09-14 06:40:53 PM EDT. This delivery adds instructions only. No startup, shader, physics, graphics, or editor optimization has been applied in this file. ## Codex/GPT handoff: diagnose startup, recover FPS, preserve the actual 3D game ACTIVE PRIORITY. This block supersedes conflicting older TODO instructions below it for this task. It does not authorize implementing every historical proposal in this HTML. Keep the previous TODOs as reference; do not execute an old broad .15/Apjs/Stak/multiplayer handoff instead of this one. Start from the supplied 534pET GlDag shard-continuity build, or the byte-identical runtime in this handoff HTML. Do not restart from .14, import .15 wholesale, or discard the subsequently working GlDag/spider/shard fixes. This is an investigation and a sequence of small patches, not another engine rewrite. ## 0. Completion rules and human checkpoint tracker Codex may open Chrome, execute the real game, inject controls, inspect Vars, capture the existing output tensor/canvas, export arbitrary diagnostic text, and conduct bounded experiments. It should reproduce problems and test hypotheses itself, not repeatedly hand basic debugging back to Ben. Preserve a runnable build after each useful change. Human play remains the acceptance test for feel and visibility. Only Ben checks the HUMAN boxes below. Codex may complete the technical boxes after collecting their stated evidence. A completed hypothesis box means investigated, not necessarily confirmed. Record CONFIRMED, REJECTED FOR THIS TEST, or UNRESOLVED with the measurement. Do not turn a passing parser test or a screenshot into a claim of measured Windows GPU performance. [ ] HUMAN H01: Baseline checkpoint. I can open the reference, fly in the normal mixed world, shoot balls, and drag at least a center and a hand. The recorded scene/settings match what I am testing. [ ] HUMAN H02: Diagnostic checkpoint. The same game still plays; diagnostic capture is explicit and does not continually read back the picture or flood my console. [ ] HUMAN H03: Sum/subtraction checkpoint. I can see and edit an overlapping positive Mandelbulb and negative torus, including changing the torus weight through positive, zero, and negative. The numeric witness agrees with the displayed cavity. [ ] HUMAN H04: First startup fix. A specifically identified startup cost is reduced, without hiding species, physics, or the delay in my first shot/drag. [ ] HUMAN H05: User-definition cold-start checkpoint. After an actual OS restart, the first test in each browser has recorded first-correct-frame and first-usable-game times. Repeated reloads are recorded separately. [ ] HUMAN H06: Warm baseline checkpoint. The reproducible camera route plays at the recorded resolution/quality, with ordinary shooting and moving physics; the benchmark does not omit parts of the field. [ ] HUMAN H07: CPU/editor optimization checkpoint. I can drag centers, elbows, R, hands, and individual lines, join/detach, and shoot as before; an identified CPU cost has measurably decreased. [ ] HUMAN H08: Graphics optimization checkpoint. Looking around and moving across the 85 BentCube boundaries does not bring back missing chunks, bad depth seams, or the old disappearing terrain, including at raymarchValMul=.6. [ ] HUMAN H09: Physics/readback optimization checkpoint. Balls still bounce on the visible summed terrain, move its Vars, and transmit effects through deliberately joined Eds. There are no stuck grabs or obvious invisible-wall regressions. [ ] HUMAN H10: State checkpoint. My new JSON/BellDag save reloads with species code and joints intact; an old q.Bell5 JSON imports into q.O2$cw without reviving deleted waves. [ ] HUMAN H11: Compatibility checkpoint. Loop A still works with canonical Bell5 storage; Loop B still shows all three species. Mouse remapping and the physical controller work. [ ] HUMAN H12: Final checkpoint. I can play the final normal mixed world, understand the measured startup/FPS improvement and tradeoffs, and identify which remaining hypotheses are still unproved. Do not block every diagnostic run on a human response. Run small experiments autonomously and package checkpoints for review. Do not cross a failed human gate by silently changing architecture, reducing quality, or accumulating a large unreviewed patch. If awaiting play feedback, preserve the candidate and investigate independently on a separate branch, not on top of an assumed approval. ## 1. What is actually known ### User observations, not controlled benchmarks [U] - In the earlier GlDag step, Ben reported roughly five seconds for a first load in Chrome, roughly five seconds independently in Edge, and roughly one-third second on subsequent loads in each. The older build felt substantially faster on first load. - He was opening the normal game and shooting balls, not following the separate GlDag test-area/Drop-32 procedure. - His cold-start case is now explicitly: restart the OS, then open a browser to the game. Treat the first such test in each browser as a separately labelled sample. This report does not establish that every type of cache was empty. - After the spider changes, some dragging worked well enough to proceed. Crowded picking was not declared perfect. - After 534pET, the set of displayed objects improved: less appearing/disappearing during camera movement. A jagged-looking torus/fractal border remained. The screenshot alone did not establish its cause. - Current reported FPS is around 40. The exact world seed, options, resolution, browser, and camera pose associated with that number were not captured here. Forty FPS corresponds to about 25 ms per frame; this arithmetic is not a measurement of where those milliseconds go. - The requested normal world contains about one-third of each of Bell5, torus, and Mandelbulb, with signed positive/negative wave weights. Removing two species is not an acceptable production startup optimization. ### Source facts checked in the 534pET file [S1] - Baseline filename: Bellsack0575_2026_9_14_534pET-GlDag-shard-continuity.html - Baseline SHA-256: b2bbf37ad23debb3759b93391dfdda230baf55c28c987dd84b420051201fb467 - Baseline size: 1,685,734 bytes; 33,267 physical lines; 11 embedded script bodies. - buildWorld creates 800 terrain waves and 448 balls by default. WORLD_SIZE is 15. Each terrain slot independently selects one of the three species, rather than creating three overlapping copies of every slot. - The existing weight draw is Math.random()*2.0-1.0, assigned both to wave.p and its spring target pr. Its distribution is [-1,1), not positive-only. Do not add a redundant second randomization pass. - The three species' packed records have 5, 7, and 7 scalar Vars. Their average slot cost for equal species proportions is 19/3, versus 5 for Bell5-only. That is about 26.7% more scalar slots for the same wave count, not a prediction of 26.7% slower frames. - Loop B defaults to 448 near balls, grouped in 32s. That is 14 groups if all slots are used. Do not use the historical 320-ball/10-group performance note as an equal-work comparison. - Three GlDag density functions exist. Bell5 uses its compact bell falloff. Torus uses a bounded tube-distance bump. Mandelbulb uses up to six power-iteration steps with an escape break, trigonometric functions, powers, a distance-estimator-derived field, clamps, and a support window. localPoint is a shared vec3-returning dependency. - Loop B adds wave.p times each species function into one density scalar. It does not MAX the species densities. Four graphics passes represent forward-depth slices with 1+4+16+64=85 tile rows, not separate species images. - The active terrainZoo is the sorted set of active GlDag species in the room. Its current construction is room-wide, not a separate nearby-species compilation per tile. Wave data is spatially selected and packed separately. - The graphics fix removed the graphics global nearest-N truncation and grows each pass's scalar reserve to hold all candidate waves. BSx.graphicsShardCapacityVars retains a high-water mark; the shader VecSize is a literal derived from that reserve. The generic physics packer still has finite capacity and can omit candidates. Do not claim the graphics fix solved physics truncation too. - Graphics step cap is raytraceStep, normally .05. The default base step budget is 100. At multiplier .6 the computed limit is 334. MARCH_MAX_STEPS is already a shader UNIFORM. Actual samples depend on early exit and scene content; a 334 maximum is not 334 samples at every pixel. - By contrast, raymarchValMul and raytraceStep are interpolated into the generated graphics shader source. Changing them can change the shader string even though changing MARCH_MAX_STEPS alone need not. - The hit finder now uses the correct forward-depth-to-ray-distance conversion, samples the pass endpoint, and refines the actual sign-crossing interval with six bisections. Do not undo these fixes to recover misleading FPS. - Lamgl's cacheKeySuffix includes SV, SF, and SH. The vertexShader, fragmentShader, and program caches use this suffix. Different output shapes can therefore create multiple application-cache entries for the same source. This fact does not yet quantify redundant driver work. - Lamgl's normal path requests compile/link status synchronously. Its cacheStats is enabled by default. SpeedStats and several expensive debug/readback switches default off. Actual runtime values must still be recorded. - The alternate two-probe Ball.Phy.Surf path is present but defaults off. NumMultiprobesNearBallCenter and NumMultiprobesNearBallPhySurf are each one; the current optimized path rejects other values. Do not mistake presence of this path for proof it is active in the slow run. - The separate test area is created when its button is used, not unconditionally at current boot. All three normal species are intentionally active anyway. The earlier proposed removal of boot test objects is not the current performance solution. - GlDag CPU emulation/compiler work, arbitrary arrays/structs in the species adapter, and network continuity repair are incomplete. They are not prerequisites for this performance task. ### Historical verification is evidence to rerun, not a new benchmark [S2, S3] 503pET notes report 32 focused spider/storage tests and bounded software-WebGL frames. 534pET notes report nine focused shader/culling checks, including an explicit signed-sum test and 8,192 synthetic plane rays across the 85 rows. They also report short 800-wave/448-ball graphics-only frames with physics disabled. None of that is a controlled Windows/RTX FPS run, a physical-controller acceptance test, or an OS-restart load measurement. Ben normally opens the local HTML under J:\q\Q63x\w\bellsack\, as shown in his screenshots. Resolve the actual current workspace on the Codex machine; do not assume a historical output directory is still configured. The previous assistant's shader-cache explanation for the five-second delay is a hypothesis. No five-second Windows trace proving that attribution is attached. Do not promote it to a finding. Likewise, neither the torus cutoff nor the Mandelbulb clamps have been proven to explain the exact border in Ben's screenshot. ## 2. Design contract: optimize this game, not a substitute ### 2.1 File lineage and scope Continue the .14-derived recovery branch through these checkpoints: 1. Bellsack0575_2026-9-14-1050aET.html: Ben's earlier reference for reviewing changes. Locate the actual HTML in his repository/workspace; a screenshot with this name is not its source. 2. Bellsack0575_2026-9-14-241pET-GlDag-class.html: supplied recovery snapshot with GlDag class work. 3. Bellsack0575_2026-9-14-GlDag-step1.html: first generic Bell5/torus integration. 4. Bellsack0575_2026_9_14_344pET-GlDag-3species.html: normal mixed population. It has the known unsorted-Zoo error; it is not a runtime baseline until that isolated error is accounted for. 5. Bellsack0575_2026_9_14_405pET-GlDag-3species-fixZooSort.html: sorted species fix. 6. Bellsack0575_2026_9_14_503pET-GlDag-spider-drag.html: canonical storage and spider interaction. 7. Bellsack0575_2026_9_14_534pET-GlDag-shard-continuity.html: current runtime baseline. Keep .15 and its useful experiments as reference only. Its broad Apjs/editor/persistence redesign must not be merged wholesale. Newer explicit user decisions in this handoff supersede older .15 handoff defaults such as a separate Live child, separate layout-role systems, or required Apjs CPU/GPU compilation. A legacy symbol containing 'bell5' is not by itself a behavior bug; inspect what it does before renaming it across the file. Default to a minimal patch in the responsible function/caller. Add small independent helpers when they clarify the change. Avoid formatter churn, import changes, renamed hierarchies, or replacing the whole loop. New code uses tabs for indentation. No modules, workers, WASM, WebGPU conversion, new CDN dependencies, or OffscreenCanvas conversion for this task. Keep the existing file/HTTP deployment behavior; do not introduce a new secure-context requirement as a profiling shortcut. A measured Lamgl cache defect may justify a small separately tested Lamgl patch; preserving Lamgl does not mean refusing to fix a proven local error. ### 2.2 One canonical Varjs state space A terrain instance is: q.O2$cw.GlDag$functionName_hash.Wave5 q.O2$cw.GlDag$functionName_hash.Wave5.X.p For every terrain wave, species === wave.up. Bell5Species is an ordinary child of q.O2$cw. Both loops use this storage. Loop A remains Bell5-only computationally; Loop B handles all active species generically. Do not reintroduce q.Bell5, a forced Bell5 entry in every Zoo, terrainWaveRoots fallbacks, or a special Bell5 path in Loop B. Only an explicit load-migration boundary may recognize an old Room.Bell5 collection. It must move the original waves into that room's Bell5 species, update cached paths and pointer-key references, handle collisions without overwriting objects, remove the retired collection, and preserve .p==0 tombstones. Do not blanket-rewrite arbitrary embedded source strings. New saves use canonical storage. Keep the current migration and verify it after optimization. Each Var is one scalar degree of freedom. Its p, v, pr, ps, cv, accelMul, elbow fields, and hand fields are properties of that degree of freedom, not child Vars. Keep state in Varjs. Maps, packed tensors, shader caches, geometry arrays, and joint indexes are reconstructible derived state. Prefer frame-local let variables first and BSx derived caches second. Do not add live helper dimensions merely to store counters, render metadata, or compilation status. ### 2.3 GlDag is general pure GLSL, not a density-only language GlDag.of accepts GLSL function source with or without the GlDag$ prefix. It belongs in the Sak*.js tag. Objects are immutable, callable proxies when a JS counterpart exists, and have alternating string/GlDag/string children. Copying a hashed GLSL call name can define the dependency edge. Reachable dependencies are deduplicated and emitted before their callers. Helpers are sibling GlDag Vars under q.O2$cw; they do not become extra terrain waves merely by existing. Keep exact source/hash validation. The current naming scheme uses the chosen function name plus a 43-base62-character hash, with a zero-hash placeholder during construction. Do not shorten or randomize identifiers per frame, mutate .big under its existing hash, or change hash normalization to optimize compilation. Content changes create different content-addressed functions. Merely editing wave values must not change function identity. Zoo.toGlsl supplies a JS list of pure GLSL function definitions. Engine-owned code supplies shard state, typed arguments, weighted accumulation, and graphics/physics work. General functions can return vectors/matrices, such as complex multiplication or localPoint; density roots return float. Species functions are by-value pure functions, not readers of engine Vec, textures, uniforms, or other external mutable state. The adapter reconstructs and passes their arguments. Ordinary GLSL intrinsics do not require GlDag helper nodes. Sak$ Fn/JavaScript behavior remains separate. Preserve the reserved CPU counterpart convention: Gl contains operations such as Gl.Sin3 and Gl.Length3; one shared Float32Array(1024) named GlRet holds returned components, and a function returns GlRet[0] as its scalar JS result. Automatic translation remains deferred. Do not create a new compiler or per-operation heap-vector representation to address a cache-key problem. The broad desired API supports fixed-size by-value GLSL types. The current density adapter only supports scalar/vector/matrix signatures, not arbitrary arrays/structs. Preserve that working subset and report unsupported declarations clearly; do not silently claim the full planned type system is implemented. ### 2.4 Typed layout and signed density Special bindings: - Sxyz: sampled position, not another persistent Ed on each wave. - Cxyz: wave.X/Y/Z. - Cxyzr: wave.X/Y/Z/R together; reject Cxyzr combined with separate Cxyz or R. - R: optional parameter read from wave.R if requested. Every wave still owns X/Y/Z/R engine bounds. - Remaining declared parameters flatten in order into scalar Vars. Foo means component zero, Foo1 means component one, Foo2 means component two, etc. Do not append a displayed zero suffix or allow parameter names ending in digits to collide with flattening. - Xyz-prefixed parameters suggest X/Y/Z Ed roles cyclically. These are runtime-editable Var roles, not restrictions baked into pure GLSL. - wave.UI.Re/Gr/Bl are UI color state, not extra density parameters unless a future explicit API requests them. The packed base fields are X,Y,Z,R,weight. In the current layout, the empty string in fields denotes the wave itself, so its p is the signed weight. One Ed per packed scalar, including zero-valued parameters. Do not create wave.R.X/Y/Z, wave.W.X/Y/Z, a dummy C scalar, or metadata Eds as a shortcut. For a sample x, the requested field is: F(x)=background(x)+sum over relevant waves of [wave.p * speciesFunction(x,wave parameters)]. Apply the weight exactly once. Positive and negative waves contribute. Zero weight means no contribution/deleted wave under the existing model. No MAX/MIN boolean composition between species, no separately raytraced species surfaces overlaid as a replacement for this sum, no taking abs(weight), and no dropping negative waves from candidate lists. The current torus and Mandelbulb functions are bounded nonnegative bumps before applying weight. A negative torus can subtract from a positive Mandelbulb. Keep those functions unchanged during initial performance work. Their cutoffs/clamps and the sum's near-zero-gradient regions are possible sources of creases; a shape change is not a performance fix unless separately explained and approved. ### 2.5 Shards and the renderer Graphics keeps the 1/4/16/64 BentCube tile rows over four camera-forward depth intervals. The default cuts are 0,2,4,6,8. Each tile's wave list must cover every field sample its rays and normal stencil actually use. Adjacent tiles must evaluate the same mathematical field where their sample regions meet. Preserve the 534pET forwardRate conversion, R-based bounds, normal-stencil padding, complete graphics candidate packing, retained capacity buckets, actual sampled crossing bracket, and endpoint sampling. Capacity must never silently redefine the density sum. Overflow should be visible and handled correctly, not omitted for speed. Shader data layout includes an eight-float header, with one total-length entry and seven species counts; the payload starts with four sample slots and then grouped wave records. The current seven-species limit is explicit. Do not weaken Varset's strict ordering assertion or interpret a wave as a species. If future work raises the limit, that is a separate format/layout change. Packed xyzi.w carries shardRow*4096+varId. The density loader currently caches one row per shader invocation using VecLoaded. Do not fuse multiple rows/shards into one invocation while reusing that loader unchanged. Any such experiment must handle row switching and perturbation reset explicitly, or it will reuse the wrong field. Avoid this architectural change unless measurement makes it necessary. The four hit pictures are spatial slices of one field. Their nearest-depth merge is allowed; a per-species surface merge is not. Keep ball compositing distinct from terrain summation. Judge geometry using raw hit XYZ/depth and density residuals, not only the final colors or quantized normals. ### 2.6 Spider interaction and shared scalar physics Preserve the current useful interaction, even while improving its cost: - Center drag moves X/Y/Z, retaining grab offset. - Relative elbows live in eex/eey/eez. eeX()/eeY()/eeZ() derive their world position. An ordinary elbow drag changes routing, not the scalar or absolute hand. - The R elbow stores a unit direction and displays center+abs(R.p)*direction. Dragging it can resize and turn it; resizing from the mouse's projected ring need not rewrite the direction. - Hands live in absolute ehX/ehY/ehZ. At present, ordinary physics/center motion does not automatically move them to an elbow average. Do not implement that older proposal while optimizing. - ei|0 is the type: 0=Lone,1=X,2=Y,3=Z, with 4..15 reserved. The fractional part is a Float32-exact multiple of 2^-20 used only as a continuity hint. Zero fraction disables that hint. Identity is (ehX,ehY,ehZ,ei|0), never the random fraction. - Equal hand coordinates form a spatial bundle; its X/Y/Z/Lone groups remain different scalar dimensions. Dragging 15 coincident endpoints carries all 15. Pulling the interior of one C-E or E-H line separates only its owner Ed. - Target hand coordinates stay put during snap preview and release. Matching-type target scalar values/settings win on join. No grid snapping. No automatic type conversion. - Cursor3d grabs centers, elbows, hands, and spider segments, not arbitrary sphere surfaces. Mouse can additionally use the projected radius outline. Drawing and picking must agree. - Use the existing input/action system. Do not hijack remapped mouse buttons. While grabbing, the mapped shoot/disconnect action means no-snap and must not also fire balls. After release, normal shooting returns. - Clear ownership on mouse release outside the canvas, blur, cancellation, and load. Text entry must not trigger gameplay controls. Respect BODY-targeted background events caused by the existing canvas stacking arrangement. A joined scalar is not extra mass for every alias. In Loop B, sum derivative columns for each shared degree of freedom BEFORE squaring them in the impulse denominator. Cancellation (+1 plus -1) must remain cancellation. Integrate each shared group once, then update its aliases. Preserve spring targets and base damping so shapes do not vibrate out of control. Group caching must invalidate on actual topology/liveness changes, without rebuilding the entire world on every unrelated motion. Loop A still has its older Bell5 contact solver, not all Loop B joined-contact behavior. Keep A usable; do not claim complete A/B physical parity or expand this performance task into an A rewrite. ### 2.7 Persistence and deferred features Preserve JSON and current BellDog/BellDag full-field save routes for GlDag sources, scalar settings, and Ed fields. Preserve old p/v decoding. Do not add a second joint UUID, Live child, or new serialized letter without approval. Approved BellDag map, field-mask bit relative to 0x60: 0 ` reserved; 1 a accelMul; 2 b unassigned; 3 c cv; 4 d eex; 5 e eey; 6 f eez; 7 g gp; 8 h unassigned; 9 i ei; 10 j j; 11 k,12 l,13 m,14 n,15 o unassigned; 16 p p; 17 q unassigned; 18 r pr; 19 s ps; 20 t t; 21 u unassigned; 22 v v; 23 w unassigned; 24 x ehX; 25 y ehY; 26 z ehZ; 27 { reserved; 28 | bin; 29 } reserved; 30 ~ big; 31 DEL reserved. Keep the current save filters and Ball.Phy.Surf reconstruction. Clipboard internal joins must survive, but repeated zero-offset pastes must not join the originals accidentally. Network continuity-hint repair, full multiplayer, arrays/structs, automatic GLSL-to-JS compilation, and interactive source forking are deferred. No new feature rollout is needed to diagnose startup or FPS. The desired future visual GlDag building/composition and immutable source forks are still real design goals, not grounds to claim their UI is already finished. ## 3. Measurement contract: what 'first load' and '40 FPS' mean [ ] M01 Establish an immutable run manifest before performance changes. Record HTML hash, parent hash, browser/version/profile, OS, renderer/vendor string, hardware vs software rendering, command line, display refresh, canvas backing size, CSS size, device-pixel ratio, loop A/B, all relevant q.Opt and BSx.opt values, world snapshot identity, camera/quaternion, ball counts, active species and wave counts, and the cold/warm classification. Preserve the real user's profile; use a separate diagnostic profile when needed. [ ] M02 Separate these timing classes instead of calling all of them 'cold'. A: first chosen browser launch after a documented OS restart, as Ben requests. B: new browser process without OS restart. C: new page/tab/context in an already running browser. D: reload of the same document/profile after a completed run. E: isolated fresh diagnostic profile/cache experiment, explicitly not an OS-restart substitute. F: first encounter with a new species set, shader option, output shape, or capacity bucket during play. Do not assume reboot erases persistent caches. Browser-level and shared driver/system cache states are competing hypotheses. For a strict A/B cold comparison, assign baseline and candidate first-after-reboot positions in separate trials, not baseline first and candidate second after the same restart. Counterbalance which browser/build runs first across user-managed restarts. Do not automatically reboot, kill unrelated browsers, or clear personal caches/saves without explicit permission. [ ] M03 Mark a complete startup timeline. Measure document/navigation start, earliest script start where practical, each library initialization, Gl built-in generation, GlDag construction, buildWorld, DOMContentLoaded, startBellsack UI setup, WebGL context creation, shader-source generation, each source compile/status/link request, first draw submission, first complete visible frame, first ready physics state, and first successful move/shot/drag response. The existing bellsackStartLoadingTime begins well after the earlier library tags; bootDuration is not a complete navigation stopwatch. CPU return from display() is also not by itself proof the user saw a frame. Record application timestamps alongside browser presentation evidence. Do not report a blank canvas, stale picture, or loading label as 'the game loaded'. [ ] M04 Count programs, not only elapsed time. For every cache miss, record stable hashes of final SV and SF, lengths, stage/caller, SH, VecSize, species-set hash, actual compile/link requests, and completion/wait times. Save full source only once per unique hash. Record raw and post-transformation source identities separately. Use counters to detect new programs while moving/dragging/shooting after warmup. A same-source/different-SH miss is different from a genuinely new shader. Lamgl cache timing nodes are nested: program creation includes shader creation. Do not add parent program time to its included shader times as if they were independent delays. Browser/driver work may be deferred; a later status query, uniform lookup, first draw, or readback can pay earlier work. Label measured CPU blocked time, GPU work, and attribution uncertainty separately. [ ] M05 Use deterministic paired scene tests. Keep one frozen 800-wave, three-species signed world snapshot plus a fixed camera route. Restore the same snapshot/settings before each baseline/candidate run. Control or record randomized probe selection and contact order for numerical comparisons. Prefer a saved snapshot or a test-only seeded construction; do not globally replace Math.random in the shipped game. Preserve .pr with .p when setting fixture values so springs do not immediately undo the experiment. Use a pure Bell5 fixture for historical like-for-like comparison, and the real three-species fixture for the requested product. A new Loop A frame sees only its Bell5 subset, so comparing it directly to full Loop B as equal work is invalid. Normal production loads remain random. [ ] M06 Measure steady-state frame times and responsiveness. Proposed protocol: record the first 120 frames separately, then at least 60 seconds per repeatable route, with three paired repetitions for shortlisted fixes. These are test defaults, not a user-set performance target. Track median/p95/p99 frame interval, worst hitch, render/physics service times, input-to-visible-response latency, and any compile event. Use the existing smoothed FPS display as a convenience, not the sole benchmark. Keep the tab foreground and record DevTools/profiler/screenshot overhead. Run both raymarchValMul=2 and .6 at the same actual backing resolution. Keep the two results separate. Record whether the budget is 100 or 334 and how often rays terminate from hit, depth endpoint, or exhausted budget. Forty FPS can be CPU-bound, GPU-bound, readback-bound, or scheduler-limited; do not assume which. [ ] M07 Instrument without making the bottleneck. Prefer existing SpeedStats push/pop and compact counters. Capture call counts and self time for functions outside Loop B too, including input/picking and DOM updates. Use optional GPU timing only after verifying the available API/backend; reject invalid/disjoint samples. Do not force gl.finish or pixel readbacks after every call in the normal benchmark. Run a separate labelled serialization/profiling experiment if needed, then turn it off and remeasure. [ ] M08 Capture correct evidence without continuous full-picture readback. Use the existing shouldSaveNextRgbdAsBmp/export path or intercept the known RGBD tensor just before display/free. Respect Lamgl tensor ownership and fr/free semantics. Export raw hit XYZ/depth or signed-density samples when testing geometry, and a final canvas screenshot when testing appearance. Preserve packing conventions; not every intermediate vec4 is ordinary RGBA. Do not retain live tensors indefinitely or call .get after freeing them. Take screenshots at chosen milestones, outside the FPS measurement window. Record their frame number, state hash, camera, and options. GPU-to-CPU picture capture can itself add waiting, so never benchmark a build with per-frame screenshots against a baseline without them. A generated illustration is not runtime evidence. [ ] M09 Resolve automation/backend failures independently. First test a minimal DOM canvas WebGL2 context in the exact launched browser and record backend logs. An ordinary Canvas versus OffscreenCanvas choice is not a demonstrated cause of the earlier container failure. Do not rewrite Bellsack's canvas architecture to fix a bad test launch. Use actual workstation Chrome hardware rendering for performance claims when authorized. Software WebGL is useful for correctness only and must be labelled. A GPU process initialization failure is not a shader failure, and a syntax check is not a GPU test. ## 4. First-load hypotheses: test these, do not simply assert them Priorities below are starting order, not probabilities. For every hypothesis retain the evidence even when it is rejected. Do not change all suspects simultaneously. [ ] C01 HIGH: More expensive three-species shader compilation. Basis: the source now contains torus plus six-iteration Mandelbulb math in density functions used by graphics and physics, rather than only the bell falloff. Test one-species and three-species fixtures with fixed counts/layout/camera, collecting each final shader's compile/link/wait timeline. Include a test with the complex function present but zero wave count, distinguished from omitting it from the compiled Zoo. Confirm only if the added delay is localized to these sources. Production fix must still show all three species at startup; removing the fractal is only an ablation. [ ] C02 HIGH: Same shader source compiled/linked repeatedly because SH is in the program key. Basis: Lamgl uses SV+SF+SH for program and shader caches. The multiMode source is used with different nearest-surface and perturbation output shapes. Test actual same-SV/SF hashes across shapes; count application creation calls and waits. A targeted source/context-only compiled-program cache could help, but output allocation, viewport, framebuffers, and genuine dimension literals must remain correct. Do not blindly remove SH from all cache keys. Retest both loops, matrix/tensor smoke tests, and context recreation. [ ] C03 HIGH: Several large-Vec shader variants and capacity growth during startup. Basis: graphics reserve growth changes the literal VecSize and possibly tensor shapes. Test whether early frames compile multiple sizes before the world/camera settles, and whether one crowded row inflates a whole pass. Log per-pass configured/required/effective capacities and source hashes. Compare measured compile counts for a stable reserve policy. Do not replace the current complete field with silent truncation or preallocate an enormous Vec everywhere just to reduce variant count. [ ] C04 HIGH: Synchronous status checks serialize work or expose deferred compiler work. Basis: the normal Lamgl path checks shader compile and program link status before use. Time requests separately from queries and first use. Run a bounded schedule/readiness experiment only after measuring. An asynchronous path must wait for valid programs, report errors, retain tensor ownership, and measure time until the full requested scene and physics are usable. Merely deleting status checks, setting isSkipCompute forever, or moving the stall to the first click does not fix it. [ ] C05 MEDIUM: Cold GPU process/context/driver startup rather than Bellsack source size. Test first context creation and first trivial draw versus first complex scene in separately labelled cold/warm classes. Compare exact backend logs. A costly context before any game shader would contradict a compilation-only diagnosis. Check whether one browser's prior activity affects another's first run, without assuming shared caches or clearing them. Keep the application canvas path unchanged unless evidence identifies an application error. [ ] C06 MEDIUM: JavaScript parse/compile/initialization and large HTML payload. Basis: one large HTML embeds libraries, generated Gl built-ins, historical text, and media; buildWorld creates many Vars. Measure library initialization, Gl function generation, hashing, world creation, and DOM setup before the first GPU program. Compare CPU-only startup timing with the unmodified reference and a diagnostic suppression of GPU work. New Function/proxy/hash work might matter, but do not call it free or blame it for seconds without measurement. Moving work later must include its first-use cost. [ ] C07 MEDIUM: Repeated source generation/GLSL scanning/string allocation before cache hits. Basis: Zoo.toGlsl walks dependency roots; graphics/multiMode generators produce strings; Lamgl scans declarations and uses long string keys; optional constant-to-uniform/comment transformations run in callers. Count calls and source identities. Test a derived source cache keyed by immutable function set, layout, relevant code options, and VecSize. Keep uniform values/data out of that key. Reject stale-source behavior when any real code-generating option changes. [ ] C08 MEDIUM: UI construction, listeners, logging, or inspector hydration delays first play. Basis: startBellsack creates many field editors and listeners, and startup emits logs; the user's console showed listener source strings. Measure initialization with console closed/open and log volume controlled in a diagnostic build. Check that test suites are not accidentally auto-run. Do not remove required controls or intentional TODO warnings as cosmetic cleanup. Avoid large source dumps on the critical path unless explicitly diagnosing them. [ ] C09 MEDIUM: First-frame CPU work or resource allocation, not compiler time. Measure spatial selection, 85 candidate lists, packed arrays, textures, first spider index, first ray pass, first physics readback, and UI upload. Compare identical scene data before/after precomputed derived metadata in a diagnostic run. The first full-scene simulation may take longer than later settled frames. Do not measure only a shader timer and call every other first-frame cost negligible. [ ] C10 LOWER: File/profile/security/external-resource behavior. A file-origin console warning appeared in an earlier run but was not the sorted-Zoo exception. Record failed resource loads, initiators, filesystem reads, image decoding, navigation events, and any retries. Compare authorized file and local HTTP test routes without treating them as interchangeable product conditions. Investigate security/antivirus/file scanning only when traces point there; do not disable browser security or protection to claim a fix. [ ] C11 LOWER: Browser profile restoration, competing processes, power state, or misleading timer. Record foreground state, other tabs/tasks, renderer selection and system load. Check whether bootDuration excludes the observed slow interval. Repeat paired trials rather than fitting a story to one reboot. An operating-system or scheduler delay before application code cannot be removed by rearranging GlDag helpers; report it separately if measured. [ ] C12 CROSS-CHECK: Apparent warm-cache win comes from a different workload. The world is random on normal reload, and active rows, near-zero density regions, overlap, and first contacts vary. Repeat a controlled snapshot on multiple cold/warm runs. Verify saved or remembered quality/debug options do not differ between browsers. The ~5s versus ~.3s report strongly motivates cache investigation, but it does not rule out these confounders. ## 5. FPS hypotheses: separate necessary work from avoidable overhead [ ] F01 HIGH: 534pET now renders field terms the old build omitted. Measure candidate/packed counts by row, densities per ray, covered ray distance, and actual samples. Compare to a correctness reference, not merely the incomplete 503 picture. This is expected additional work, not automatically a regression defect. Find cheaper ways to produce the complete same field. Never restore dropping waves, the mismatched depth intervals, or invalid hit interpolation as an optimization. [ ] F02 HIGH: Conservative step cap and .6's larger budget increase density samples. Count steps and termination reasons per pass/pixel in a diagnostic shader or bounded sample. Test the same scene at the original and revised policies while recording misses/residuals against a denser reference. Density is not a proven distance bound; a larger step needs an error/coverage argument and regression tests. Tune only from measured quality/time curves. Do not relabel reduced horizon, larger tolerance, or lost fine surfaces as equal-quality speed. [ ] F03 HIGH: Mandelbulb evaluation dominates GPU time. Separate field cost using controlled occupancy at fixed sample counts. The original code uses variable Power and transcendental operations, with a bounded iteration/escape loop. Check escape/active-lane distributions, and distinguish graphics cost from repeated nearest-surface/gradient cost. Keep actual Mandelbulb behavior; do not replace it with sine noise or reduce its iterations without explicit visual-quality approval. Specializing constants or changing loop scheduling is only an experiment until same-field tests and total compile/runtime cost pass. [ ] F04 HIGH: The largest candidate row inflates VecSize/padding for many threads. Measure required versus reserved floats, bytes uploaded, work-item counts, and pass timing after visiting a dense region and returning to a sparse one. Current high-water buckets intentionally avoid shrink/recompile thrash. Verify whether large declared private arrays affect this backend; do not assume register spills from source alone. Consider bounded reuse policies only with valid overflow handling and a fresh compile-hitch test. A memory reset that makes the next movement freeze is not a free improvement. [ ] F05 HIGH: Repeated room/species scans, sorts, and wave-to-Var list creation. Profile terrainSpecies, terrainZoo, activeTerrainWavesForEditor, searchTerrainWavesZYXR, prepareDensityShardRow, and repeated Object.values/map/flatMap/indexOf work. Cache immutable layouts and stable membership separately from moving values. Reuse a derived per-frame species/list snapshot where valid. Invalidate on create/delete/load/species edit and relevant state transitions, not every unrelated .p motion. Spatial results must update when centers/radii move; never reuse stale culling as a speed hack. [ ] F06 HIGH: Spider geometry/picking/CPU overlay scales with the whole room every frame. Profile actual mouse/cursor paths as well as drawing. initSpiderWave currently returns fresh layout-based arrays and prepares center metadata even for initialized waves; spiderGeometry then makes more arrays/objects. Test editor-on/off as an attribution experiment only. Optimize repeated work and share geometry between picking/drawing within a coherent frame. Preserve offscreen joint membership and physical effects even when UI drawing is culled. The final game still has working visible spiders. [ ] F07 MEDIUM: Joint-index rebuilds, contact-binding rebuilds, and alias bookkeeping. spiderIndex is already cached; first count its invalidations before adding another cache. Determine whether contact bindings are rebuilt redundantly per ball instead of per stable shard/topology, and whether singleton groups allocate avoidable arrays. Cache only on exact binding/topology signatures, and invalidate after load/join/split/deletion. Retest opposing derivative cancellation, reinforcement, held values, and once-per-step integration before claiming a win. [ ] F08 HIGH: Physics nearest-surface and perturbation work dwarfs rendering. Measure physics off, compute-without-motion, and full physics as distinct modes using restored scenes. Record effective probe count, 32-ball groups, Newton iterations, perturbation columns, and contacts. More scalar Vars and fractal samples can increase work. The existing two-probe Ball.Phy.Surf experiment is a candidate ablation, not a default flip: test difficult contact recovery and moving terrain before adoption. Do not lower ball count, probe count, physics rate, or Newton work secretly. [ ] F09 HIGH: Synchronous signed-distance readback serializes CPU/GPU. Measure bytes, readback count, time waiting, packing pass time, and CPU contact processing separately. Current main physics retains one shard texture for two uses, so do not announce 'reuse the texture' as a new fix without finding a remaining duplicate. Deferred/fenced code exists but is off; re-enabling it requires state-version consistency, exact ball-row identity, no tensor use-after-free, and no extra input/physics latency. One-frame-late contact against the wrong world is not an acceptable optimization. [ ] F10 MEDIUM: CPU rasterized spiders plus GPU upload/composition cost. Measure CPU painting, packed overlay buffer creation, upload, expansion and merge separately from the terrain ray pass. Reuse suitable CPU buffers/derived projections where safe. Do not alter Lamgl immutable tensor ownership, skip current geometry, or retain a previously drawn canvas as fake live output. Hiding the overlay is an ablation, not the shipped solution. [ ] F11 MEDIUM: Allocation, garbage collection, and unbounded caches cause hitches. Record typed-array/Map/Set/string allocation rates, garbage-collection pauses, retained textures/programs, and source-cache size along a repeated route with dragging. Separate texture pool reuse from leaked live tensors. Use bounded derived buffers/indexes rather than persistent Var children. Cache stabilization should improve the route without causing ever-growing memory or a later multi-second collection. [ ] F12 MEDIUM: Diagnostic flags, forced synchronization, or screenshot capture remain enabled. Record actual values of AlwaysCopyGraphicsToCPUJustToTestSpeed, Lamgl.forceGlFinishAtEndOfEachLamglCall, one-pixel sync options, SpeedStats, IsLogLikeFromTests, graphics-debug modes, synthetic readback switches, skip-input and isSkipCompute toggles. Inspect counters to ensure physics/graphics really execute. Turn only diagnostic overhead off for the final equal-feature comparison; restore deliberate user options. A skipped GPU path may report high FPS while doing no useful work. [ ] F13 MEDIUM: Cache-key/source instability creates intermittent compiles while moving. Count new source hashes/programs on static frames, ordinary numeric drags, moving balls, capacity growth, and adding/removing the last wave of a species. Random wave identifiers, live coordinates and weights should remain data, not source. A genuine species-set or reserve change can be legitimate; repeated identical-state recompilation is not. Keep errors visible instead of silently reusing an incompatible program. [ ] F14 MEDIUM: Ball-ball processing, overlap recovery, or repeatedly colliding initial states dominate. Profile stages separately while keeping the same ball population and initial positions. The random initial world can put many balls inside terrain or each other, changing recovery workload and spatial groups. Compare steady play after settling with first seconds after generation and heavy shooting. Do not remove collision/recovery stages as a production 'optimization'; diagnose pathological repetition or unnecessary searches. [ ] F15 LOWER: Final display, DOM refresh, or frame scheduling is the bottleneck. Measure input handling, cursor message DOM updates, selected-field grids, live stats text, RGBD composition/display, and the interval between requestAnimationFrame callbacks. Check for double loops, accidental event storms, hidden-tab throttling, or frame limits before treating every 25ms as shader time. Reduce unnecessary DOM work without making controls stale. Measure input response, not only FPS. [ ] F16 CROSS-CHECK: Rendering and physics evaluate different truncated fields. The graphics packer retains all candidate terms, while the physics packer may still skip overflowing records. Log omitted physics memberships and verify a ball's actual contact field against the visible field. This can explain unreliable contacts or recovery cost, not just FPS. Any fix needs a separate bounded checkpoint; never 'match' them by reintroducing missing graphics terms. Preserve global contact behavior when optimizing shared variables across spatial shards. [ ] F17 CROSS-CHECK: Near-zero plateaus and support boundaries create expensive or misleading samples. Signed sums can cancel over broad regions. Current compact/clamped species can also have flat areas. Measure |F|, gradient magnitude, hit residual, starting-point acceptance, and support crossing near the reported seam. Repeating more steps is not always the cure. Distinguish field nonsmoothness, low-gradient ambiguity, quantized shading normals, unresolved fine geometry, and missing candidates. No formula smoothing or MAX blending without a separately approved design change. ## 6. Execution order and deliverables for each patch ### Stage A: preserve, reproduce, and establish the same game (H01-H03) [ ] A01 Make the file/hash manifest and a clean branch from S1. Record local user edits before changing anything. Verify all embedded scripts parse, then actually run Loop B. Do not confuse the notes-only handoff file's larger TODO payload with the untouched S1 navigation baseline. [ ] A02 Locate comparison versions in the workspace, including actual 1050aET/.14 HTML if available. Record missing source honestly instead of reconstructing it from screenshots. Use feature-isolation/bisection across the checkpoints to localize when a cost appeared. Do not run the known unsorted 344 build as if its crash were a performance result. [ ] A03 Export a deterministic representative scene and camera route from the normal world. Capture baseline image, raw hit samples, weights/species histogram, active capacities, and all options. Include a crowded region and a sparse region. Record default quality 2 and explicit quality .6 separately. [ ] A04 Build an explicit read-only/temporary diagnostic path using existing tools. One command/button should capture manifest, stage timings, cache counters, and one tensor/canvas frame. It must restore flags and references in finally/cleanup paths and leave normal play responsive. No permanent background screenshot loop, hidden warmup page, or automatic unit tests on every load. [ ] A05 Make sum/subtraction visually checkable, not merely asserted. Select or construct in a temporary fixture an overlapping positive Mandelbulb and negative torus, with known paths and camera. Keep other terms fixed. Show full-field F at identical sample points, with torus enabled/disabled and its sign reversed. For two chosen components A and B, verify F_AB-F_A-F_B+F_empty is near zero within a stated floating-point tolerance. F_empty includes the same background. Verify differences equal the expected signed wave contribution. Bounding-sphere overlap alone does not prove an actual cavity. Provide a way to jump to that pair and identify its .p/.pr values. Keep the wave reference/path before setting its weight to zero so the test can restore it without introducing a separate Live marker. Pause motion or hold the fixture values while comparing. Ben must be able to see the torus carve and fill as its weight changes. Restore the original world afterwards. Do not alter the three formulas or density combination to make the demonstration pass. [ ] A06 Rerun the prior density/culling tests before performance patches. Include off-axis forward-depth mapping, adjacent tile/depth boundaries, final endpoints, the old behind-camera interpolation case, negative weights, and capacity overflow. Sample the same frozen field across neighbor shards. Inspect raw geometry and final shading separately when investigating the screenshot's corner. ### Stage B: find and reduce the actual startup cost (H04-H05) [ ] B01 Implement the startup trace and source/program identity logging with known overhead. Establish whether the observed pause occurs before context creation, during JS/world/UI setup, during compilation/link/status, in first physics readback, or in first complete rendering. Allocate elapsed time rather than assuming the largest-looking function caused it. [ ] B02 Test C01-C04 first, then remaining startup hypotheses according to the trace. Keep one independent variable per experiment. Report a short table of evidence for and against each candidate, including unchanged/negative results. Do not promise a compile-time reduction from merely making the generated source shorter. [ ] B03 Ship only the smallest supported first fix. Examples, contingent on evidence: correct redundant compiled-program keys while preserving shape-dependent resources; cache identical generated sources; avoid duplicate initialization; schedule independent valid compilation work without shifting the stall to first interaction. Do not bundle all four. [ ] B04 Exercise first-use actions after the fix: ordinary flight, ten shots, start/end a mouse drag, cursor3d drag, open the field panel, toggle A/B once, and visit a dense region. Log any delayed program creation or blocking. A startup win that moves five seconds to these actions must be reported as relocation, not removal. [ ] B05 Prepare an exact first-after-reboot procedure for Ben: identify which file/browser/profile to open first, begin external/early timing before the page, avoid visiting the same candidate beforehand, record time to full three-species playable scene, then reload and compare. Do not require DevTools already attached if that prevents a genuine browser-first test; use a separately measured low-overhead early logger or external recording. Human H04 can accept a targeted fix before exhaustive cold trials. H05 requires the actual user-defined cold condition. Codex marks that test pending until it has that evidence, even after hundreds of warm automated launches. ### Stage C: recover CPU/editor time without changing behavior (H06-H07) [ ] D01 Run a cost matrix on the same scene: graphics only; physics compute without applying motion; full physics; editor drawing/picking toggled for attribution; final compositing enabled/disabled only in the diagnostic harness. These are diagnostic modes, not comparable finished-game scores. Return to full features after each ablation. [ ] D02 Select the largest measured CPU cost, not the most convenient code cleanup. Instrument calls, allocations, and inclusive/self time for species scans, layout/Var lists, shader strings, BentCube candidate collection, spider geometry, picking, joint bindings and DOM updates. [ ] D03 Apply one cache/reuse/change at a time. State its key and invalidation contract in the patch notes. Test direct .p edits, .R edits, zero/nonzero weight, join/split, create/delete, load, and clipboard operations. Hidden caches must reconstruct to the same game state when discarded. Do not introduce stale spatial data or cached scalar values masquerading as current Vars. [ ] D04 Complete a human spider exercise on the optimized build: center drag; ordinary elbow reroute; R elbow and mouse ring resize; Lone hand; complete/partial XYZ bundle; pull one line out; snap target-wins; no-snap modifier; release outside canvas; blur; resume shooting. For the 15-endpoint fixture, machine checks may verify all member identities while Ben checks the visible effect. Preserve bounded latency in crowded regions. ### Stage D: recover graphics time at the same field and accepted quality (H08) [ ] E01 Count actual ray work and candidate counts for each pass. Check whether the bottleneck is field evaluation, declared VecSize, active wave count, underfilled SIMD work, culling, source regeneration, or output composition. Keep four spatial passes and one summed field as the reference design. [ ] E02 Explore one measured improvement: less repeated CPU packing; legitimate source reuse; better bounded resource reuse; or a safe ray-step policy with explicit quality evidence. Report added state/options and estimated diff before a broader change. Do not change the GlDag functions, hide the fractal, reduce resolution, shorten the visible range, or lower the candidate set in a supposedly equal-quality result. [ ] E03 Run the route through dense/sparse regions repeatedly at 2 and .6. Capture where reserves grow; confirm no shrinking/recompilation oscillation. Rerun raw-hit and signed-sum tests after every generated-shader change. Record exhausted rays as exhausted rather than silently interpreting them as empty space. [ ] E04 Human inspect close surfaces, negative cutouts, tile edges, and depth-slice transitions while moving/rotating. Compare the same saved pose before and after. Leave the reported corner unresolved if the evidence cannot isolate it. Do not 'fix' a color crease by altering mathematical composition. ### Stage E: recover physics/readback time only after localization (H09) [ ] P01 Record the effective work: balls per group, probes per ball, solver iterations, terrain Vars, padding, samples, readback bytes, contacts, and recovery steps. Inspect physics truncation separately from graphics overflow. Reuse existing fixtures to check exact ball/row identity. [ ] P02 If nearest-surface work dominates, test the existing cached-surface/two-probe option on difficult geometry and moving waves. If readback dominates, investigate packing/redundancy first. If CPU impulse work dominates, investigate repeated binding/reduction construction. Choose based on data, not a preferred GPU-versus-CPU philosophy. [ ] P03 For any scheduling/readback change, prove it uses matching state snapshots and does not apply old contact gradients to unrelated new rows. Track versions and tensor lifetimes in diagnostics, without inventing a new persistent world-state system. Confirm no skipped contacts or permanent lag. Do not enable the old deferred experiment merely because its name suggests speed. [ ] P04 Rerun ball-terrain interaction with positive and negative fields, torus passages, Mandelbulb details, center/radius deformation, and a shared joint connecting shapes. Verify derivative cancellation before squaring, no double integration, damping/restoring behavior, and no nonfinite values. Check A separately, keeping its known scope limitations explicit. ### Stage F: persistence, complete play, and final report (H10-H12) [ ] R01 New JSON and BellDag roundtrips: shape parameters, signed weights, p/v/pr/ps/cv, new Ed fields, fractional hints, source .big, helper dependencies, zero settings, and intentional origin joints. Current format coverage is not all possible Var fields; list any unsupported path instead of marking it universally complete. [ ] R02 Old JSON migration: legacy Bell5 waves end under the actual room's canonical Bell5 species; no live q.Bell5 remains. Preserve deleted waves, original object/pointer identity where the migration promises it, and colliding names without data loss. Rebuild required Ball.Phy.Surf cache state. Do not revive placeholder nodes because XYZ exists. [ ] R03 Clipboard regression: copy joined waves, paste at nonzero and zero offsets, repeat zero-offset paste, verify internal joins preserved and originals separate. Ed culling/performance caches must not disconnect offscreen portions. [ ] R04 Run the normal full mixed world for a proposed ten-minute soak, with the ordinary camera route, shooting, repeated dragging/joining and save/load. Record memory, texture/program counts, long frames and context loss. This duration is a practical first test, not proof of indefinite stability. Distinguish controlled snapshot numerical tests from chaotic long-run trajectory identity. [ ] R05 Repeat warm tests on Chrome and Edge with actual renderer identity recorded. Check Firefox correctness when available without asserting identical performance. Hardware/browser results cannot be borrowed from the software-WebGL container. Physical-controller acceptance remains a human check. [ ] R06 Deliver one candidate per coherent checkpoint: runnable single HTML, .html.notes.md, exact .html.diff, relevant scene/diagnostic data, and a short 'do this in 3D' procedure. Preserve the prior working build and a rollback path. No source-code-only patch that Ben cannot play. [ ] R07 Final attribution report: for cold load and warm play separately, list confirmed causes, rejected hypotheses, unresolved ones, measured milliseconds before/after, changed work counts, quality differences, and remaining hitches. Count runtime additions/removals by script separately from TODO/test text. Keep human gates unchecked until Ben accepts them. ## 7. Minimum acceptance fixtures, reused rather than invented repeatedly Use small fixtures to diagnose, then the full normal world to accept performance. Keep them external/test-only or behind explicit controls; no automatic expensive suite during every game boot. [ ] T01 Same-field sum: explicit weighted GlDag evaluation versus packed evaluation for all three species, including mixed signs and a negative torus/positive Mandelbulb cavity. One background term only. [ ] T02 Same-source cache: two output shapes with identical final SV/SF; verify correct output, uniforms, resource allocation, and observed compile/link entry counts. Changing true source must still create/validate the right program. [ ] T03 Stable numeric editing: after needed programs are warm, moving a center or changing weight/shape Vars within the same reserve does not create new source. A new content hash/species set or reserve is separately labelled, not silently suppressed. [ ] T04 Correct shards: analytic plane, off-axis rays, final endpoint, actual bracket interpolation, adjacent tile/depth overlaps, and all candidates packed despite reserve overflow. [ ] T05 Correct contacts: finite field samples, ball X/Y/Z derivatives, moving terrain response, shared derivative cancellation/reinforcement, and one integration per typed group. [ ] T06 Correct editing: real mouse events plus mapped cursor3d actions, not direct setters alone; remapping, release/blur, no-snap, one-member detach, target-wins join, and visible/pickable geometry agreement. [ ] T07 Correct persistence: new saves and legacy import, tombstones, sources, pointers, fractional hints, internal versus external clipboard joins. [ ] T08 Correct lifecycle: no use-after-free, no extra live texture per frame, no source-cache growth on identical routes, valid context and programs after A/B switching or reported load errors. Do not claim identical images for moving physics unless the test restores the same state/time/random choices. For deterministic field tests, state a numerical tolerance and use residuals or hit-position/depth errors. Screenshots complement those checks; they do not replace them. ## 8. Evidence templates and stop conditions For every hypothesis: ID: Status: UNTESTED / CONFIRMED / REJECTED FOR THIS TEST / UNRESOLVED Source fact or reason it was considered: Exact build and scene hashes: Cold/warm class, browser/profile/backend: One variable changed: Measurement and repetitions: What improved or contradicted the hypothesis: Correctness/3D regression result: Next action or reason to stop: For every checkpoint: Parent build/hash: Candidate build/hash: Affected script tags/functions: Expected behavior change: Actual code +lines/-lines by script; TODO/test text counted separately: New fields/options: none, or exact list and justification: Startup: time to complete correct frame, physics ready, and first usable action: Warm route: median/p95/p99 ms, worst hitch, compile count, quality/settings: Candidates/steps/bytes: before and after: GPU/CPU evidence and instrumentation overhead: Human procedure, expected result, and limitations: Human acceptance: PENDING until Ben checks it: Rollback filename: Stop or roll back a candidate when it loses field terms, changes signs/composition, corrupts state, breaks a previously working basic grab, or makes memory grow without bound. Investigate repeated failures with a smaller fixture. Do not spend hours generating slight variants without recording what each test changed and learned. Conversely, one failed headless setup is not permission to stop after syntax checking when a real browser is available. Do not set an artificial line-count target by compressing unreadable code. Prefer fewer concepts and localized changes. Do not ship a quality reduction under the label 'optimization'. A consciously chosen quality option can be offered as a separate measured tradeoff, not silently enabled. All emitted files in one checkpoint use one actual Eastern Time timestamp, for example: Bellsack0575_YYYY_M_D_HMMpET-GlDag-performance-checkpoint.html Bellsack0575_YYYY_M_D_HMMpET-GlDag-performance-checkpoint.html.notes.md Bellsack0575_YYYY_M_D_HMMpET-GlDag-performance-checkpoint.html.diff Use aET for morning. This is a naming pattern, not a fixed timestamp to copy. Retain enough manifest data to match a screenshot, notes, and diff to the exact HTML. ## 9. Source ledger and implementation map This handoff's design instructions are from the supplied conversation and code. Hypotheses and proposed experimental procedures are explicitly proposals, not externally verified browser claims. No new performance measurements were performed while writing this handoff. [U] Current conversation, September 14: first-load and FPS reports; preference for small 3D-verifiable steps; normal three-species signed world; no q.Bell5 except import; sum, not MAX; timestamp naming; Codex permitted to perform real browser experiments. [S1] Bellsack0575_2026_9_14_534pET-GlDag-shard-continuity.html, SHA-256 above. Line anchors below refer to this original, before adding this block; use symbols in the handoff copy because lines below the inserted TODO move. - Lamgl.callGPU and cacheKeySuffix: approximately 517-1044; exact key at 562. Compilation/status/link section around 774-814. glvars scans shader declarations around 1134. Texture allocation/readback/lifetimes around 1215-1530. vm.cache/cacheStats around 1886-1918. - GlDag/Sak: search glDagState, class GlDag, static of, fromVar, toVar, toGlsl, Gl.UseUser, and Gl.testBasics. Varjs prefix/hash registration is separate; do not reimplement it. - Runtime defaults: raymarchValMul/raytraceStep and maxMarchStepsPerLamglCallB around 12602-12630; TOTAL_BELLS/TOTAL_BALLS around 12652/12675. - Zoo/layout/density: 12910-13140; terrainSpecies at 13005; terrainZoo at 13009; prepareDensityShardRow at 13020; glslDensityModule_lamglLoopBodyB at 13042. Sum at 13126; sparse payload load and VecLoaded in the same function. - Species GLSL: 13973-14025; initSpiderWave/spiderGeometry/spiderIndex and pick/drag functions follow from roughly 14040. - buildWorld: 14346 onward; signed weights at 14358; random species selection immediately after. Optional test world at 14720; normal boot invokes buildWorld at 14772. - Historical boot stopwatch starts at 13767 and is completed in A/B frame paths around 22684/27632. It is not document navigation timing. - Graphics packer/capacity growth: 22738 onward. Generic physics packer: packBell5ShardRowsExplicit_lamglLoopBodyB around 24580. Some historical names retain Bell5 even where the body is generic. - Shared multiMode shader generator: sfSourceMakerB_multiModePass around 24627. Nearest-surface invocation around 25029; signed-distance invocation around 25428, with different sh shapes. - CPU contacts: cpuTerrainImpulseUpdate_lamglLoopBodyB around 25776; main physics around 25880 onward. Verify the actual live call graph, not an old commented prototype. - Graphics budget/finder: graphicsRaymarchStepBudget_lamglLoopBodyB at 26146; sfSourceMakerB_graphicsRaymarchShardPass at 26151; findSurfaceB around 26219; raw-hit to RGBD/depth merge follows. - Main B pipeline: lamglLoopBodyB around 27092; full active terrain graphics selection around 27200; candidate packing around 27360; explicit picture-readback gate around 27601. - Constant-to-uniform source transform: Lamgl_makeSomeConstantsUniformsToPreventLoopUnrollingWhichSlowsCompiling around 28156. renderLoop around 28350; SpeedStats at 28566; startBellsack at 29045. - Effective UI/default options: 29184-29240 and 29387 onward. Check actual values, not only source defaults. The two-probe path defaults off at 29204. - Canonical migration and shared physics callbacks: migrateLoadedBell5, afterTerrainLoad, spiderContactBindings, spiderIntegrator around 30119-30205. [S2] Bellsack0575_2026_9_14_503pET-GlDag-spider-drag.html.notes.md. Records the spider/storage change, actual implemented limitations, and reported focused tests. Its runtime parent is 405pET. [S3] Bellsack0575_2026_9_14_534pET-GlDag-shard-continuity.html.notes.md. Records the three renderer corrections, capacity behavior, sample-count tradeoff, signed-sum/plane fixtures and software-WebGL limitations. Read alongside the .html.diff to isolate why complete rendering now does more work. [S4] 2026-9-14-259pET.GlDag.chatGPTJustBeforeConversationEndedCuzGptSayItGotTooLong.design-compound-et-controls_20260914_1457.md. Historical design export. Relevant sections include the .14/.15 read-only review; September 14 pure-GLSL parameter and storage decisions; elbow/hand fields; the approved BellDag letter map; final ei fractional-hint decision; target-wins and 15-hand/single-line semantics; and GlDag source composition. It contains contradictory older proposals and old broad handoffs. Do not treat all of them as simultaneous requirements. ## END TaskGlDagStartupAndFPS_2026_9_14 Older TODOs remain below as historical reference. The active scope is measured startup/FPS improvement while preserving the current canonical three-species summed-field game and useful spider editing. Now make the text and relevant pics to hand the task off to Codex/GPT to build it from this newest Bellsack*.html version. This I said earlier, add to that what you learned from me adjusting what the editor should look like, example scene, etc. communicate to Codex thru detailed text (including what to add to the "TODOS<" textarea (that pops up when u check the TODOS checkbox) at the top of that textarea put these few pages of detailed instructions. if you have more detail than that put it in a separate details section that ill only put in the codex chat window so the todos dont get cluttered. make them [ ] check off able. QUOTING MYSELF: "To summarize the change (i likely missed some parts that u remember): apjs will look like "(distance (+ a b) c)" and gains new nodeTypes/opcodes for vec3 (leave mat4 vec4 etc for later), in addition to it already has float32 and int32 ops, which transpile to something like "length((a+b)-c)" in glsl and transpile to that someJsFuncForAddTwoVec3s(SomeFunc(),Ret[1],Ret[2],OtherFunc(...),Ret[1],Ret[2]) which we can make exprs out of, each returning float. apjs only says (distance (+ a b) c) which becomes that glsl andOr js whichever u transpile to. ejW has 4 possible values: 0 for Lone, 1 for X, 2 for Y, 3 for Z. 2 or more eds are edjointed together if they all have the same vec4(ejX,ejY,ejZ,ejW). In lone edjointed to lone, ejj normally takes the average 3d position of the ejs whose ejjs are a member of that edjoint. ej is the elbow. ejj is the hand on the end of the elbow. Each wave is like a spider with n single eds, some of which overlapping look like fewer but can be separated. Some move as xyzEds (groups of 3 * number of xyzEds in the edjoint). Some move like lone eds that are just my var connected to your var. copy and paste stuff by selected set of waves fix the cursor3d drag and drop to work with the spiderlike model of waves and edjoints, considering that its very buggy and incomplete but does drag and drop some stuff already." shorter todos list by gpt6astraultra2026-9-8<<< **TaskSpiderWavesVec3Multispecies — 2026-09-08 — CURRENT BUILD PRIORITY** Build the real, playable Bellsack editor/game described here. Start from Bellsack0575_2026-9-8-427pET.html, not an older similarly named copy. The accompanying 02-CODEX-HANDOFF.md contains implementation details, source anchors, equations, migration rules and acceptance cases; keep those details out of this textarea. The pictures illustrate the intended editor experience, not completed engine functionality. This task supersedes conflicting older instructions about no EdJoints, ejW interpolation, mandatory R.X/Y/Z or W.X/Y/Z, one-line Eds, shape-selection menus and Bell5-only editing. Preserve unrelated fixes, user comments, existing saves, Lamgl behavior and the A/B audit below. Use [x] only after implementation and verification; record any unrun live test. GOAL AND STATE [ ] S01 Deliver a usable mixed-species world: balls roll and shoot, load bends terrain, shared Vars transfer motion, and players build with the actual 3D wireframe, field grids and Apjs source. Do not finish at a picture or fake UI. [ ] S02 Keep persistent state in Varjs. One Var is one scalar dimension. Add eeX/eeY/eeZ (elbow), ehX/ehY/ehZ (hand anchor), and ei (Ed integer type) as FIELDS, not child Vars. ei is exactly 0=Lone, 1=X, 2=Y, 3=Z; t stays time. Register defaults before Proxy use and cover copy, load, save and dirty events. [ ] S03 Keep wave.X/Y/Z.p as C and wave.R.p as the true bounding radius. Keep wave.p as Bell5 weight, including negative values. Separate deletion from zero weight so editing through zero cannot destroy the wave or its connections. Use the handoff's explicit migration/liveness policy. Do not create a second authoritative weight or mandatory XYZ parent dimensions. [ ] S04 A scalar joint is the exact finite float32 key (ehX,ehY,ehZ,ei). Each newly enabled loose Ed gets its own reserved key before indexing; all-zero is a valid intentional coordinate, not a universal disconnected sentinel. Names, owners, elbow placement and type remain individually addressable. [ ] S05 Use the documented engineering default: stored ehXYZ identifies the hand/join anchor; cache.handXYZ is its current drawn position. Draw coordinate hands from their shared X/Y/Z .p values and Lone hands from the mean of member elbows. This permits sparse topology updates while .p/.v change frequently. Do not rebuild joints by equality of moving screen positions. [ ] S06 Reserve distinct float32 anchors for unrelated hand clusters, including partial XYZ clusters. Use deterministic small representable offsets on a key collision. Moving display collisions may get a tiny derived displacement; never alter .p, average coordinate values, or merge because physics crossed. Topology joins, splits, type changes and rekeys commit atomically. APJS, VECTORS AND SPECIES [ ] S07 Add vec3 nodeTypes/opcodes and type propagation to existing float/int Apjs. Source can say (distance (+ a b) c), including nested vector-returning functions. Support construction, components, +, -, scalar scale/divide, dot, cross, length, distance and safe normalization. Defer vec4/matrices. [ ] S08 GLSL ES 300 output uses native vec3 expressions/functions. JS uses one const Ret=new Float32Array(16) per cached evaluator context. A vec3 helper writes Ret[0..2] then returns Ret[0]; flatten each vector argument as someFunc(),Ret[1],Ret[2] before evaluating the next argument. Scalar results return normally; scalar +/* stay direct. No per-vector allocations or stack pointers, and no Ret allocation inside the per-sample lambda. [ ] S09 Make nested calls, repeated helper names, live named vec3 locals and conditionals correct. Capture inputs before another call overwrites Ret. Emit helpers once with readable names. Fix the existing CPU-entry and gpucpu branch-selection defects. Compare JS/GPU with documented numerical tolerance; the earlier ~1.9x JS measurement is not a guaranteed runtime multiplier. [ ] S10 Preserve array naming: index0 -> ArrayName, index1 -> ArrayName1, index2 -> ArrayName2, index53 -> ArrayName53. Values come from .p. An arbitrary three scalar expressions may form a vec3 across arrays or waves. ei and joins are independent of array order. Do not create extra arrays/header ranges just for vector syntax. Reject ambiguous generated names such as Foo[1]/Foo1[0]. [ ] S11 Derive one binding/layout descriptor for CPU, GPU, derivatives, copying and source editing. Preserve overlapping named slots when arrays resize. Build genuine generic species dispatch and bounded records in BOTH graphical and physical shards; remove Bell5 stride/gradient assumptions from that path. Keep compact support and identical density semantics in render and collision. [ ] S12 Mount density species at the existing room O2$cw and per-wave potential rule instances under wave.O2$cw. Persist their code and scalar-reference bindings in Varjs. Nested rule instances are not extra terrain waves. Evaluate potential gradients sparsely over UNIQUE touched scalar joints. Preserve an optional diffeq entry point without making new diffeq/constraint solvers a gate. SHARED PHYSICS [ ] S13 Make joined Vars act as one solver dimension, not several coordinates averaged after independent physics. Explicit snap adopts target shared state and integration settings. Integrate once and scatter equal committed fields to aliases. Apply the built-in rest spring/damping/mass once per shared scalar; sum contributions from distinct rules/densities. Split inherits current state. [ ] S14 Perturb all aliases together or sum their partial derivatives before using the derivative. Terrain impulse uses Jgroup=sum(member partials), then inverseMass*Jgroup*Jgroup. Do not sum member squares or integrate duplicate packed slots. Explicitly obtain ball XYZ derivatives for generic species; the Bell5 inverse-center shortcut is not generally valid. [ ] S15 Preserve real ball/terrain impulse, sparse dirty batches, temporal controls, mass behavior, 32-ball physics shards, multiprobe/surface caching and Tensor ownership. Shared groups may span shards and invisible waves. Rendering LOD must not disconnect or stop a dependency that affects the active world. SPIDER WIREFRAME AND DRAG/DROP [ ] S16 Each ordinary Ed draws C -> its own E -> its H. Ordinary E=C+eeXYZ. Hands join hands only; elbows, crossing lines and overlapping spheres do not join. Draw one segment per identical unordered 3D endpoint pair, retaining its member list for selection. Shared XYZ routes are not three offset lines. [ ] S17 Draw every wave's true bounding-sphere outline and C at its true center. The R Ed is Lone. Its E=C+R*normalize(eeXYZ) is on the sphere; retain its direction through center/radius physics updates and at R=0. Add only the needed sphere surface arc from R.E to the visible outline. R.H is free to join another R; sharing radius does not share the centers or elbow directions. [ ] S18 Make the web obvious in editor mode: dense nearby bounds and legs, thicker contrasting strokes with dark edging, per-wave colors, clear C/E/H marks and selected-whole-wave highlighting. Distant waves show bounds only. Use the 96-bound/400-ball reference as visual guidance, not fixed engine counts. No invented decorative graph curves; optional ball trails are separate. [ ] S19 Enumerate actual scalar parameters generically, including zero-valued and nested rule parameters, with correct owning-wave metadata. Exclude runtime and infrastructure branches. C exposes the center axes; focused components remain reachable. Do not infer a triple from names or consecutive array slots. [ ] S20 Use one derived geometry/target description for rendering, labels, mouse picking, cursor3d picking and drop preview. Pick C, E, H, drawn legs and the R outline/arc only. No arbitrary sphere-surface or isosurface picking in ordinary graph-editing mode. Keep any experimental surface tool separate. [ ] S21 Implement one captured grab state machine for mouse and gamepad: lock source on press, preserve grab offset, update preview, release onto exactly that preview target. LB grabs/drops. While grabbing, RB chooses raw no-snap drop and does not shoot; RB alone shoots. Preserve actual movement bindings. Handle lost capture/focus and text-input focus without stuck grabs or shots. [ ] S22 Ordinary E drag reroutes that Ed only. R.E/outline drag resizes R. H drag on a whole XYZ handle drives present shared coordinate .p values; Lone H drag rewires, and Lone .p is edited with its field controls. Supply a nearby member/component chooser for individual H detach/type/rewire; do not silently detach everything on ordinary group grab. No new dummy Y/Z Vars. [ ] S23 Allow any X/Y/Z membership: e.g. 2X+2Y+2Z from three waves; adding an X-only Ed grows only X. A Lone may deliberately convert to X/Y/Z and join that one scalar without the other axes. Different coordinate types do not auto-convert. An explicit attach-axis drop can assemble complementary X/Y/Z groups at one anchor. Preserve missing-axis placement on split/deletion. CONTENT EDITING, SELECTION AND COPYING [ ] S24 Keep whole-wave selection distinct from focused Var/E/H editing. Show selected count and outline ALL selected waves' bounds, centers and Eds. Do not claim a patch of the summed isosurface belongs only to selected waves. [ ] S25 Copy only the explicitly selected set of WHOLE waves, of any species, plus a copy of camPos. Paste translation is pasteCamPos-copyCamPos. Preserve internal joins and nested rules, create fresh wave paths, remap internal references, detach joins to unselected originals, and reserve fresh keys even for repeated zero-offset pastes. Keep relative elbows/radius unchanged. [ ] S26 Translate declared world-position parameters and their rest positions once; do not add the offset to arbitrary Mana/radius/sine phase values or to velocity. Combine standard center/coordinate-hand roles with any extra declared spatial roles; a nonspatial alias follows its shared coordinate. Provide Copy/Paste, recent reusable slots and Varjs JSON import/export with code dependencies. Remove the Ramp/Bridge/Cup prefab selector; recent copied assemblies replace it. [ ] S27 Reuse real Var.fieldEditor('p'/'v'/'pr'/'ps'/'cv') grids with signed values and live updates. ei gets a discrete four-choice control. All edits use the shared-group mutation path; type/topology transactions update all caches. [ ] S28 Fork-edit Apjs for selected instances: edit draft, compile/validate both targets, create/reuse content-addressed species, migrate only selected waves, remap pointers and atomically switch. Failed compilation preserves the running world. Unselected instances stay on old code. Numeric edits never recompile. PERSISTENCE, LIVE ROOM AND DEMO [ ] S29 Wire the existing generic sparse BellDag field codecs into BellDog; its current p/v-only six-node writer cannot save this editor. Persist new Ed fields, shared scalar settings, species/rule Big/Bin dependencies, liveness, materials and layout/bindings. Keep old JSON/binary decoders. Sparse omission means unchanged; full snapshot omission means schema default. Explicit zero updates work. Keep existing UI/Phy save filters and surface-cache rebuilds. [ ] S30 Migrate old ejXYZW by evaluating the OLD blended world position before assigning new fields. Do not reinterpret old w=1 as new X. Preserve positions; old ordinary absolute matching endpoints may migrate to Lone joins with a deterministic documented shared-value winner. Do not autojoin all old zeros. [ ] S31 Finish live Tomcat play with one main ball per player, continuous inputs, shots, interpolation/prediction as appropriate, and host-authoritative world commits. Keep JSP a bounded transport/store, not a game-code executor. Enforce host plus three granted editors; play-only clients cannot replace world state. Grants, owners, latest chat and avatars must live in a replicated Varjs branch, not the currently excluded local q.User camera subtree. Handle join/leave. [ ] S32 Build a real sunny woodland demo with Bell5, torus, a bounded Mandelbulb, sine surfaces, bridges, elevator and linked puzzle rules. Use nonmetal muted colors and varied procedural shrubs; all playable surfaces use actual species. Aim for 400 visible balls total (20 main + 380 shots), readable avatars/trails, with 16 inactive masked lanes in 13x32 physics slots. Show four editors building live and contextual code/field popups. No staged comic panels or baked picture standing in for playable terrain. [ ] S33 Verify reduced-coordinate joint physics, cross-shard effects, collision nonjoining, R motion, arbitrary mixed-source XYZ, partial detach, both save formats into a fresh root, paste at zero/nonzero offsets, source forks and input capture. Keep existing A/B repair gates and avoid known freeze workloads. [ ] S34 Demonstrate actual GPU/CPU mixed-species agreement and loaded-ball bridge/elevator play. Measure frame/GPU/CPU/shader-compile and allocation costs honestly on the tested hardware. Test real Tomcat host/editor/play-only clients, then the 20-player target; offline mocks are not proof of network completion. [ ] S35 Deliver the working HTML, required hashed JSP/export, self-contained Varjs/BellDag demo world, controls/how-to-play notes and an evidence log. Continue through integration and fixes; leave any unavailable human/20-machine test explicitly pending rather than marking it done. Keep this checklist current. **END TaskSpiderWavesVec3Multispecies — earlier TODOs follow unchanged** >>> Hand the task off to codex. Make it so detailed i wont have to come back here until its done, and I'll be playing in my fun world made with my multi species level editor with these spiderlike skeletons/wireframe of waves of species. graphics. physics. drag and drop. game content. editor UI. varjs. apjs. lots of stuff. whatever changes are needed. Make the handoff. //START J:\q\Q63x\w\bellsack\codexReadOnly\gpt6AstraUltra_handoffToCodex2026-9-8-540pET # Bellsack: complete implementation handoff Prepared 2026-09-08 from `Bellsack0575_2026-9-8-427pET.html` and the user's final design corrections. This is the long detail for the Codex/GPT chat. The companion short checklist, already prepended to TODOS, is the task tracker. ## 1. Outcome, authority and scope - [ ] Build the real editor and game. The user should be able to enter a room, roll their main ball, shoot a swarm, construct a world from mixed species, connect scalar dimensions, edit code and values, copy assemblies, save them, and play while other permitted users edit. - [ ] Treat the source file as the baseline, not as proof every feature mentioned in its comments works. Existing source contains many historical proposals. The user explicitly requested this newer design; older instructions such as “Do NOT implement EdJoint” do not veto the present work. - [ ] Preserve working Lamgl, both render-loop repair sets, sparse physics/graphics, real ball/terrain impulse and data formats. Extend them. Do not replace the engine with the illustrative HTML, a sprite scene, a generic rigid-body engine, or a CPU-only terrain fallback. - [ ] All persistent state belongs to Varjs. Maps, lists, shaders, typed arrays, membership indexes, cached projections and derived representative objects may accelerate it; clearing them must not change the reconstructed world. - [ ] Complete density and potential-rule support now. Preserve an explicit optional diffeq route if already used. New diffeq semantics, general constraint solvers, matrices, vec4 and large-scale P2P are not prerequisites for this delivery. The desktop target is existing script-tag JS plus WebGL2 GLSL ES 300 in Chrome and Firefox. The user's reference machine is an i9-9900K/RTX 2080 Super. Performance measurements from another machine are useful but must identify that machine. Keep code indentation with tabs and use compact braces. ### Chosen requirements versus engineering defaults The user's final choices are the four `ei` types, separate elbow/hand fields, scalar Var identity, hand-to-hand joining, arbitrary cross-array/cross-wave coordinate members, shared physics, R elbow on the sphere, whole-wave copying, vec3 source with JS `Ret`, and a dense visible editor web. Some operational details were not completely specified in the conversation. This handoff supplies defaults so implementation can proceed: stable persistent hand anchors plus derived moving hands; target-wins shared scalar settings; partial-handle fallback coordinates; translation-role metadata independent of `ei`; explicit zero-weight liveness; and transactional networking. These are engineering resolutions, not claims that the user previously dictated their exact equations or field layout. Use them consistently rather than leaving competing representations active. ## 2. Source audit: where the work actually starts Search these symbols, not fixed line numbers; prepending the checklist shifts later locations. | Area | Useful source anchors | Actual baseline status | |---|---|---| | Var fields | `var Var`, `Var.prototype`, `copyLocalFrom`, `loadMap`, `toMap` | Old `ejX/Y/Z/W`; no `ee*`, `eh*`, `ei`. Constructor and prototype registration both matter for Proxy fallback. | | Scalar batching | `VarVM.nextState`, `Var.prototype.nextState`, `makeDirty`, `fireEvents` | Real dirty batching and integration exist. Preserve their event phase. | | Joint wrapper | `class EdJoint`, `getOrCreateVarset` | Membership wrapper only; it does not share physics. | | Ap language | `Ap.nextLanguage`, `toApeRecurse`, `parseMems`, `toCodeMap`, `evalsToInt`, `toTinyGlslCodeRecurse` | Primarily scalar result assumptions. V2 user `+` becomes internal `f+`; internal `+` is the block/do operator. | | Ap entry points | `evanCpuMain`, `evanCpuMainParloc`, `evalGpuMain`, `evalCpuDiffeq_parlocOrNot` | CPU main uses undefined `jsCode.code`; top-level `gpucpu` compilation unconditionally selects child0. Fix when activating these routes. | | Species | `BS.Zoo`, `getOrCreateZoo`, `varToSpeciesElseNull`, `ChuaBellApCode`, `MandelbulbApCode` | Zoo density remains Bell5-specific; other named density functions return0. Stored species prototypes are not complete runtime support. | | Packing | `graphicsRaytrace_packGraphicsRaymarchShardTexture`, `packBell5ShardRowsExplicit_lamglLoopBodyB`, `bell5RecordVar_lamglLoopBodyB` | Fixed five-field Bell5 records and headers need generic derived layouts. | | Collision | `cpuTerrainImpulseUpdate_lamglLoopBodyB`, `VarGradientGL_cleanShape` | Real impulse path; Bell5 derivative shortcuts and alias handling need correction for generic species. | | Sparse updates | `nextStatePhysicsDataVars_lamglLoopBodyB`, `makePhysicsDataVarsDirty_lamglLoopBodyB` | Major paths visit direct children; deep rule parameters need dependency-aware scheduling. | | Ed enumeration | `getUIEdVars`, `edVarXYZInWorld`, `isExplicitEdPosition` | Direct-child, nonzero and old-placement assumptions. | | Geometry/picking | `PickBellsackEditorTarget3d`, `EditorOtarget`, `camCursorSphereRing` | Cursor3d currently accepts arbitrary sphere-surface targets. | | Drag/join | `beginEditorGrab`, `moveEditorGrabToOtarget`, `finishEditorGrab`, `MouseEditorAction`, `joinEditorEdVarsAtCommonXYZ`, `editorEdjointMembers` | Join copies coordinates only; mouse drag actions often just select; drop re-search can differ from preview. | | Input | `BellsackDefaultControlBindings`, `Controls`, `ControlsPressed`, `ControlsChange`, `ApplyBellsackEditorActions`, `bootLamglDomEvents` | Existing Varjs action mapping should remain authoritative. | | Field/code UI | `UpdateSelectedVarFieldGrid`, `Var.prototype.fieldEditor`, `onMainTextareaTextBeforeAndAfter`, `moveO2cwInstanceToSpecies` | Real field controls exist; direct `.big` edits and current move helper are not a safe fork transaction. | | Copy/selection | `editorSelectionSetVar`, `selectedEditorVars`, `copySelectedEditorContent`, `pasteSelectedEditorContent` | Clipboard currently has a cursor position and live JS species references; selection can promote focused scalar Vars to owners. | | Binary state | `BellDag.BdVecKey`, `BdVecVal`, `BdSparseList`, `BellDog.snapshotVar`, `decodeSnapshot`, `restoreVar` | Generic sparse field codecs exist, but BellDog still writes/reads old p/v-only snapshots. | | Save routing | `quicksave`, `quickload`, `loadStateData`, `bellsackSaveOptions`, `bellsackDefaultSaveQuery` | Preserve separate JSON/BellDag slots and UI/Phy filters. | | Multiplayer | `BasicBdMultiplayer`, `handleNode`, `publishCurrentWorld`, `worldSelector` | Experimental master/client relay; no enforced edit-grant policy, no complete 20-owned-player-ball system. Current world broadcast is low frequency. | - [ ] Fix encountered active blockers as part of the affected vertical slice. Do not spend the entire task repairing unrelated dead experimental tests. - [ ] Preserve the recent `TaskKeepLamglLoopBodyAWorking` repairs and existing cached-surface/multiprobe tests. The known graphics-debug dependency on physics is not a new regression to “fix” by changing architecture. ## 3. Varjs schema and scalar identity ### 3.1 Concrete paths Use the room's existing collection: ```js const species=q.O2$cw['Ap$'+densitySource]; const wave=species.B501; ``` The existing content-addressing machinery decides the stored hashed name and `.big`; do not concatenate an assumed hash manually. An actual wave contains: ```text wave.p Bell5 weight / species influence contract wave.X.p, wave.Y.p, wave.Z.p bounding-sphere center C wave.R.p nonnegative bounding radius wave.ArrayName.p array slot 0 wave.ArrayName1.p array slot 1 wave.ArrayName53.p array slot 53 wave.ArrayName.eeX/.eeY/.eeZ that scalar Ed's elbow placement wave.ArrayName.ehX/.ehY/.ehZ that scalar Ed's persistent hand anchor wave.ArrayName.ei 0, 1, 2 or 3 wave.O2$cw[ruleCode].Spring01... a deeper potential-rule instance ``` These are illustrative names, not a requirement to add an `ArrayName` array to every species. A scalar such as `wave.R` is already a Var; its `.p/.v/.pr/.ps/.cv/.eeX/...` are fields of that one dimension. Creating `wave.R.X/Y/Z` would create three additional dimensions and is not this design. - [ ] Register `eeX`, `eeY`, `eeZ`, `ehX`, `ehY`, `ehZ`, `ei` in all built-in field registries before installing/using the fallback Proxy. Keep ordinary existing-child access fast. - [ ] Keep `ei` an integer enum. Reject invalid/nonfinite incoming types; do not silently interpolate or round an arbitrary float into a type. Do not rename it `et`, `ety` or repurpose `t`. - [ ] Extend full-copy, full-load, sparse-patch, field-editor, dirty-listener and binary field handling together. A field only added to the constructor is unfinished. | `ei` | Meaning | Shared degree of freedom | |---:|---|---| | 0 | Lone | one scalar; hand placement need not encode its numeric value | | 1 | X | one scalar used as the drawn hand's X coordinate | | 2 | Y | one scalar used as the drawn hand's Y coordinate | | 3 | Z | one scalar used as the drawn hand's Z coordinate | Type affects physics membership, not just color. `K(v)=(f32(v.ehX),f32(v.ehY),f32(v.ehZ),v.ei)`. Eligible Eds with equal keys are aliases of one scalar. X/Y/Z at the same anchor remain three different scalar groups. Lone remains a fourth independent group if deliberately colocated there. ### 3.2 Eligibility, ownership and zero values - [ ] Derive the set of shape/rule scalar parameters from compiled species bindings and explicit standard-wave roles. Resolve a nested rule parameter's owning terrain wave by collection membership, not by assuming `.up` is the wave. - [ ] Do not traverse every infrastructure node and turn it into terrain. Root `O2$cw` terrain instances and nested per-wave `O2$cw` rule instances have different roles. - [ ] Every participating scalar must remain inspectable at `.p=0`. Do not hide it because its value or seven Ed fields are zero. C provides a combined representation of the center's three scalar Vars, with individual center components reachable through the same focused-parameter UI. No synthetic scalar “C” replaces them. - [ ] Newly activated Eds must receive initialized placement and distinct keys before joining the index. Reconstruct eligibility from source/bindings and explicit migrated state; numeric zero alone cannot signal “not initialized.” Use a schema/initialization version in the existing Varjs metadata pattern, not a hidden JS-only Boolean required to load correctly. For a new coordinate endpoint, initialize missing-axis anchor coordinates near the intended hand and put its elbow near that `.p`-defined point; do not initialize every X-only endpoint with arbitrary Y/Z at the origin. A coordinate singleton can subsequently move away from its elbow under physics: “loose” means no other alias, not a permanently zero-length second segment. ### 3.3 Weight zero and deletion Engineering default: use a separate wave liveness marker, `wave.Live.p` with 1=live and 0=deleted tombstone, unless the actual collection already supplies an equivalent independent persisted membership bit. For a single clear implementation, make `wave.Live` the standardized wave metadata role; it is not a shape parameter or Ed. New waves initialize it to1. Old recognized active waves migrate to1. Do not revive every zero-valued Proxy-created child from an old save. - [ ] A live zero-weight wave remains selectable and can retain rule instances and joints. It contributes zero influence according to its species contract. Negative Bell5 weights stay negative. - [ ] Delete explicitly sets/removes membership through the liveness transaction, detaches affected endpoints, handles references, and invalidates shards. Preserve a tombstone/order record long enough for sparse replicas; do not resurrect an object from an old p/v patch. - [ ] Preserve the distinction between wave-level influence and unrelated `.p` membership values on rule/metadata containers. Do not automatically replace zero with1 during fork or paste. - [ ] Exclude Live and other metadata roles from density parameter lists, perturb columns and integration enumeration. The current direct-child loops cannot remain the authority for what is a physical coordinate. ## 4. Persistent anchors, moving hands and topology ### 4.1 Why this distinction is necessary Literal moving hand coordinates cannot simultaneously be equality-based identity, change only infrequently, and remain immune to collision-induced merging. The following implementation resolves that tension without adding a persistent joint UUID or a second state system: - `ehXYZ` is the persistent spatial **join anchor**. Equal anchor+type defines membership. It changes during explicit placement/topology operations. - `cache.handXYZ` is the current drawn world point. It is recomputed from shared `.p` or elbow positions. - Cached groups/representatives are indexes over the persistent keys. They are discardable. - A geometric hover/snap candidate uses the drawn point, then commits the target's persistent key. It does not equate unrelated groups merely because their current display points touch. The names remain `eh*` as requested. Explain this distinction in code comments and field tooltips, because the earlier conversational names `ej`/`ejj` reversed roles during discussion. No normal physics tick rewrites topology or emits fresh hand anchors merely to follow a moving handle. ### 4.2 Position equations For wave center `C=(wave.X.p,wave.Y.p,wave.Z.p)` and ordinary Ed v: ```text E(v)=C(owner(v))+(v.eeX,v.eeY,v.eeZ) ``` Ordinary `eeXYZ` uses world-unit offsets from C, without automatic scaling by R. Radius scaling is special to R's elbow. This prevents an unrelated radius edit from rearranging every routing point. For a Lone group G: ```text H0(G)=sum(E(v) for v in G)/|G| ``` Count each member scalar Ed once. Do not average group representatives, visible lines, only selected waves, or only currently rendered members. A singleton Lone's H is at E; a near-E drawn handle may be used for selection without changing joint identity. Its scalar `.p` is independent of this average. For coordinate groups sharing one anchor A, form a derived axis bundle B. Let `GX/GY/GZ` be whichever type groups exist there: ```text H0(B).x = sharedP(GX), if GX exists; otherwise A.x H0(B).y = sharedP(GY), if GY exists; otherwise A.y H0(B).z = sharedP(GZ), if GZ exists; otherwise A.z ``` - [ ] Use one representative only after the shared-state invariant holds; any representative then gives the same `.p`. Deterministic lexicographic Var path is sufficient for the derived lookup. - [ ] Two, three, seven or any other number of members per axis is legal. A bundle with only X or X+Z is legal. No extra Y/Z Vars are created to make it look complete. - [ ] An added X-only member cannot change where Y/Z are averaged, because there is no coordinate-elbow averaging. Its X joins GX; the common point still uses the three scalar coordinates above. - [ ] On split/removing the last member of an axis, preserve the prior drawn coordinate as the missing-axis fallback by atomically choosing/rekeying the remaining bundle's anchor. Otherwise removing the last X would jump the point to an obsolete anchor.x. ### 4.3 Collision-safe allocation - [ ] Index canonical float32 coordinates with normalized zero. Reject NaN/Infinity. Compare values as they will survive saving/transmission, not raw JS doubles. - [ ] Allocate keys against a complete room topology index, not just visible geometry. A new independent XYZ bundle reserves the spatial anchor across coordinate types, so an unrelated X-only bundle cannot accidentally combine with a Y/Z-only bundle there. Lone remains semantically separate by type; intentional user type/colocation operations are explicit. - [ ] If a desired anchor is reserved, search a deterministic nearby representable lattice/ULP sequence, ordered by distance and then fixed axis order, until an unused anchor is found. A hardcoded `1e-9` addition is not adequate at large coordinates. Keep the offset small relative to the existing snap radius and retain identical anchor bits for every member being joined. - [ ] For two independently moving displayed bundles reaching the same point, retain their keys. If separation is needed for picking, use a tiny derived screen/world display displacement assigned to the entire bundle and every arriving hand segment. Do not change the scalar `.p` or apply forces to avoid an editor-marker collision. Recompute the displacement deterministically from keys. The inspector reports true scalar values, not displaced marker coordinates. - [ ] Never join on every frame by clustering proximity. Exact key equality establishes existing membership; explicit hand snapping changes keys. E/line crossings and sphere overlap never change topology. ### 4.4 Transaction order Implement one shared topology-edit transaction used by all controls, load/migration, fork, paste, deletion and network edits: 1. Snapshot affected source/target memberships and current shared values; validate role/permissions and revisions. 2. Determine new memberships and compatible types from the requested operation. 3. Choose target-wins state or split inheritance as specified below; reserve all new float32 keys before changing any Var. 4. Commit all member fields, liveness/references and affected shared settings as one mutation batch. 5. Rebuild/invalidate affected membership, dependency, binding, shard and geometry caches. 6. Publish one revision/transaction and fire UI events after the coherent state exists. - [ ] An observer must never see half a triple rekeyed or interpret a transient collision as a merge. On error, leave the old state active. Undo stores the inverse/before-state transaction in Varjs if persistent; cache-only undo is not a saved-world authority. ## 5. Shared scalar physics ### 5.1 Alias semantics Joining means one effective scalar dimension, not an elastic relation between separately integrated positions. The member Vars retain names, owners, individual `eeXYZ` and `ei`; committed shared numeric state agrees at every observation boundary. Engineering default for an explicit merge: the target group wins `.p`, `.v`, `.pr`, `.ps`, `.cv`, `.accelMul`, `.epsilon`, `.gp`, and other persistent integration settings actually used by this baseline (including `.vv` where applicable). Mirror those settings to every alias. Source and target are determined by the captured drag, not incidental iteration order. A split inherits the shared settings and current p/v into each resulting group without injecting an impulse. - [ ] Integrate once per group and scatter committed shared fields before render, listeners, save or network publication. Direct slider edits to an alias, contact impulses, rule changes and incoming patches all route through this group mutation path. Detect/fix existing direct writes at the batch boundary; do not allow different aliases to silently diverge. - [ ] The built-in `pr/ps` rest spring, base damping and inverse mass apply once per shared scalar. Attaching another alias does not double its mass, damping or default rest-spring force. A species needing several different springs attaches several explicit potential-rule instances. - [ ] Sum contributions from distinct density functions/rule instances that depend on the shared scalar. Deduplicate duplicate traversal of the same rule; do not deduplicate genuinely different physical contributions merely because they touch the same Var. - [ ] Intersect pending min/max constraints for the group. Report an empty interval; do not choose a member's clamp silently. Clear transient fields and preserve dirty-batch/event ordering once per effective coordinate. - [ ] A load of inconsistent aliases must not average them silently. A valid full snapshot must satisfy equality. Legacy migration uses its explicitly documented deterministic winner; a modern conflicting patch is rejected/reconciled by the authoritative transaction rule. ### 5.2 Gradient and impulse equations If scalar q has alias occurrences `v1...vk` in functions, then: ```text dF/dq = sum_i(dF/dvi) ``` Either perturb q once and read that perturbed value at every occurrence, or independently obtain partial derivatives and reduce them into this sum. Do not perturb one occurrence and label it the complete derivative. For a contact signed-distance Jacobian, reduce aliases first: ```text Jg = sum(member partial derivatives for group g) D = sum_g(invMass_g*Jg*Jg) sdVelocity = sum_g(Jg*velocity_g) ``` Use the existing impulse/restitution/penetration logic with this unique-coordinate metric and apply each resulting group velocity change once. `sum(invMass_i*Ji*Ji)` over aliases is wrong: it omits cross terms and changes physics when a shared dimension appears in another packed slot. - [ ] Generalize perturb columns, packed-record references, and shader reads so aliases share a canonical DOF index. The same shared Var can occur twice in one species, in several species or across shards. - [ ] Existing B physics infers ball XYZ derivatives by negating sums of Bell5 center derivatives. That shortcut fails when a generic density depends on absolute endpoint Vars or other spatial parameters. Explicitly perturb sample/ball X/Y/Z in the same density expression unless a complete translation-covariant transform has actually been proved and tested. - [ ] Keep real ball/terrain reaction. A loaded bridge can move because the terrain Vars participate in collision, not because an animation is triggered by a ball entering a zone. - [ ] Topology spans all live eligible endpoints in the loaded room. Active dependency closure can extend beyond visible waves. Far-wire LOD cannot disconnect physics; large-room streaming must retain required boundary/shared state. ### 5.3 Potentials and optional diffeq Example mount using existing Varjs code/pointer patterns: ```text wave.O2$cw[Ap$<potential source>].Spring01 wave.O2$cw[q.Some.Pointer.To.Rule].Spring02 instance.X / .Y / .ManaRefillRate / ... instance.Bind.P1$A[<target scalar Var path>].p = 1 ``` Here `Ap$<...>` and the pointer are descriptions of literal/hash or reference keys, not instructions to store angle brackets literally. Reuse existing `.big` and pointer resolution. Bound scalar targets may be local, on another wave, or in another rule instance. Code and bindings persist; compiled closures and target arrays do not. - [ ] Give a potential entry one scalar loss result. Derive its unique touched-DOF set, evaluate the neutral loss plus one perturbation per unique coordinate, accumulate the gradient into the existing `.gr`/integration semantics and restore temporary values in `finally`/equivalent batch cleanup. - [ ] Apply `nextState` once after contributions, not inside each potential callback. Retain the baseline's sign convention: it accelerates by negative gradient using `accelMul`. - [ ] A spring may use `0.5*k*(distance(a,b)-restLength)^2`; a puzzle relation may use a weighted square such as `weight*(height-target(mana))^2`. Put rest/strength/rate parameters in actual Vars, so players can edit them and copy the rules. - [ ] Start with dependency-sparse CPU potential evaluation, which is much less frequent/smaller than density sampling. Cache code and layouts. Preserve room-wide reduced-coordinate correctness before optional GPU batching. - [ ] If diffeq is enabled, evaluate its dedicated branch once and accumulate the supported transient derivative outputs. Density, scalar potential and diffeq have distinct entry semantics. Do not run density in place of the ignored second `gpucpu` branch. ## 6. Apjs vec3 compilation ### 6.1 Surface language and types - [ ] Users write `(distance (+ a b) c)` and nested calls such as `(distance (+ (getA) (getB)) (getC))`. Add any needed named-call sugar on top of existing function declarations/call nodes. Keep existing explicit `?`/`@` function syntax working. - [ ] Add result shape/type to the existing nodeType/opcode system. Do not introduce runtime vector objects into source execution. Track float, int and vec3, plus existing control categories, through declarations, calls, conditionals and assignments. Existing `.apeSize` describes memory/computation dimensions and is not a substitute for result type. - [ ] Resolve V2 user arithmetic into the correct internal arithmetic nodes (`f+`, `f*`, etc.). Do not overload the unrelated internal `+` block operator accidentally. Required first operation set: | Source operation | Supported result/signature | |---|---| | `vec3` | three scalar float expressions -> vec3; explicit int-to-float conversions as required | | component access | vec3 + compile-time x/y/z component -> float | | `+`, `-`, unary minus | vec3 pairs / one vec3 -> vec3 | | `*` | vec3×float, float×vec3 and componentwise vec3×vec3 -> vec3; dot product uses dot | | `/` | vec3/float -> vec3 | | `dot` | vec3,vec3 -> float | | `cross` | vec3,vec3 -> vec3 | | `length`, `distance` | vec3 -> float; vec3,vec3 -> float | | safe normalization | vec3 -> vec3; zero-length input returns zero using the same documented threshold in JS and GLSL | - [ ] Reject unsupported signatures at compile time with source locations. Do not infer vec3 from an array length divisible by3 or from current `ei` values. Literal vec3 syntax is a calculation type; Ed typing is state/physics metadata. ### 6.2 Generated JS ABI Use exactly one reusable buffer per compiled evaluator context: ```js const Ret=new Float32Array(16); ``` It belongs outside the per-sample callback. The current generator inserts `beforeCode` inside that callback, so placing this declaration there would allocate on every sample. Refactor the cached evaluator wrapper/lifetime deliberately. No per-vector `new Float32Array(3)`, returned array/object, pushed stack pointer or hidden allocation is needed. All vec3 helpers linked into one synchronous evaluator call graph use that same Ret. Do not bind a function compiled against another context's private Ret and then read Y/Z from the caller's different buffer. Link the helper into the common closure, or provide an explicit context bridge that transfers the three components. There is never one Ret allocation per helper invocation. Asynchronous vector calls are outside this expression ABI. A complete schematic example, after the source's functions have been declared: ```text (distance (+ (getA) (getB)) (getC)) ``` Generated GLSL: ```glsl vec3 getA(){return vec3(1.0,2.0,3.0);} vec3 getB(){return vec3(4.0,5.0,6.0);} vec3 getC(){return vec3(7.0,8.0,9.0);} float evaluate(){ return distance(getA()+getB(),getC()); } ``` Generated JS: ```js const Ret=new Float32Array(16); function getA(){ Ret[0]=1; Ret[1]=2; Ret[2]=3; return Ret[0]; } function getB(){ Ret[0]=4; Ret[1]=5; Ret[2]=6; return Ret[0]; } function getC(){ Ret[0]=7; Ret[1]=8; Ret[2]=9; return Ret[0]; } function add3(ax,ay,az,bx,by,bz){ Ret[0]=ax+bx; Ret[1]=ay+by; Ret[2]=az+bz; return Ret[0]; } function distance3(ax,ay,az,bx,by,bz){ let dx=ax-bx,dy=ay-by,dz=az-bz; return Math.sqrt(dx*dx+dy*dy+dz*dz); } function evaluate(){ return distance3( add3(getA(),Ret[1],Ret[2],getB(),Ret[1],Ret[2]),Ret[1],Ret[2], getC(),Ret[1],Ret[2] ); } ``` This returns `sqrt(5)`. JS captures argument Numbers left to right, so each vector's Y/Z is read immediately after its returned X, before the next function changes Ret. Helper definitions occur once; the readable expression tree stays compact. - [ ] Only aggregate results use Ret. `distance3`/`dot3` return a normal scalar; ordinary scalar arithmetic remains direct. A scalar function is not required to write `Ret[0]`. - [ ] Publish a vector result only after any nested computations needed for its components are complete. A helper that writes X to Ret and then calls a vector helper while computing Y would corrupt X. Use scalar locals for such internal intermediate values. - [ ] Named vec3 variables that remain live across later calls need three scalar locals in JS. A saved pointer to Ret is not a saved vector. This limited scalar-local lowering is compatible with the desired compact helper-call output. - [ ] Evaluate each source child once, preserving lazy branches. Repeated calls to the same helper in nested expressions are legal. Recursive call cycles remain unsupported for GLSL; reject them explicitly. Replace return-emission heuristics based only on whether generated text ends in a parenthesis with type-aware expression/statement emission. - [ ] Keep generated GLSL native and side-effect-free where expression order could otherwise matter. It must not depend on JS's shared-return convention or assume matching GLSL argument evaluation order. ### 6.3 Float precision and cost Ret writes round all three output components to float32; return `Ret[0]`, not an unrounded local X. JS's internal Number operations are still binary64 unless the existing scalar opcode deliberately rounds. A vec3 helper return boundary is not identical to rounding after every primitive GLSL instruction, and GPU contraction/built-ins can also differ. - [ ] Preserve existing scalar semantics. Do not globally add `Math.fround` merely to support Ret. Document tolerances for parity tests and keep authoritative network state in the chosen numeric representation. - [ ] Accept the user's chosen cost tradeoff. The prior ~1.9× figure was a particular benchmark, not a guarantee for every expression/engine. No new benchmark is required before implementing the agreed ABI. Measure actual code when verifying performance. - [ ] If extending performance tables to aggregate widths later, use sizes1,2,3,4,9,16 as requested. This does not authorize implementing matrices now. Allocation count must remain constant across repeated evaluations. ## 7. Binding arrays to Vars without extra storage The baseline's actual Mandelbulb initialization demonstrates this naming: | Ap array index | Existing Var | |---:|---| | 0 | `wave.ArrayName` | | 1 | `wave.ArrayName1` | | 2 | `wave.ArrayName2` | | 53 | `wave.ArrayName53` | ```js function arraySlotVarName(name,index){ return name+(index===0?'':String(index)); } ``` - [ ] Derive the packed slot->Var->canonical DOF mapping once from the species declaration/layout and bindings. Use the same descriptor for JS input, GLSL input, gradient output, editor inspection and copied-state migration. - [ ] A vec3 can be constructed from array A slot0, array B slot7 and array C slot53. They need not be consecutive, in the same array, from the same owning wave after bindings, or a named group in the editor. - [ ] Maintain few large Ap arrays. Vec3 temporaries or helper calls do not allocate another GPU array or header pair. Per-species ranges remain ranges for declared arrays. Parameter slots may contain aliases of the same underlying scalar. - [ ] Reject naming collisions such as `Foo` slot1 and `Foo1` slot0 mapping to `wave.Foo1`, unless an explicit pre-existing binding mechanism intentionally resolves them. Do not silently create a new suffix scheme. - [ ] Growing an array preserves existing slots/names and creates newly declared parameters. Shrinking stops binding removed slots but retains their saved data for undo/migration until explicitly deleted. Inserting a new semantic meaning in the middle is a source migration, not something the compiler can infer. - [ ] Runtime `ei` changes never rename Vars or recompile the density expression. Layout/code changes may invalidate compilation; ordinary parameter edits update numeric buffers. ### Translation roles and Ed types Moving an assembly must translate its shape and its coordinate hands consistently. Build one per-DOF transform plan from standard center roles, coordinate-hand types and any additional declared world-position inputs. X/Y/Z hands supply the corresponding spatial translation requirement for their shared `.p`. Other species positions that deliberately remain Lone need an explicit spatial role; arbitrary names or array order cannot reveal it. - [ ] Represent additional roles in species/binding metadata in Varjs: worldX/worldY/worldZ, relative/direction, scalar/invariant. Standard wave.X/Y/Z already have known roles; radius is invariant. This is coordinate-frame metadata, not another grouping or suffix system. - [ ] Translate an effective DOF once even if several selected aliases refer to it. An ordinary scalar/invariant alias adds no spatial requirement: Mana wired to a Y hand changes along with that one shared Y scalar. Do not reject a valid coordinate-plus-Mana joint merely because its second binding is nonspatial. - [ ] Truly conflicting spatial requirements, such as one shared scalar requiring both deltaX and a different deltaY, cannot both be satisfied while preserving the joint. Diagnose that concrete transform conflict; do not silently detach, add two offsets or choose by iteration order. Let the user explicitly resolve such an unusual assembly's transform policy. - [ ] Existing species without extra metadata migrate standard roles and coordinate-hand roles; remaining scalars are unchanged. A custom absolute-position Lone binding needs its role declared before correct translated copying. Include this in species diagnostics without inventing a name-based rule. ## 8. Generic species, rendering and bounded physics - [ ] Generate/cache one density body per species content+layout revision, then a Zoo dispatcher for the needed species set. Use the same source semantics in raymarching, nearest-surface search and contact perturbation. The active number of instances is runtime data, not a reason to regenerate shaders every frame. - [ ] Generalize the current five-field Bell5 stride, header generation and record lookup. Preserve sparse graphics frustum shards and the established physics shard width; adding species must not secretly return to scanning the whole world per sample. - [ ] Maintain explicit parameter/DOF indexes when a species uses more than X/Y/Z/R/weight. Capacity checks must report the actual limiting uniforms/textures/header data. Vector syntax does not add metadata per scalar. - [ ] A wave has true finite support inside its bounding sphere. Preserve the current compact-support Bell5 edge subtraction. A naïve old unshifted Gaussian prototype would produce visible/physical seams when shard membership differs. Give every new density species an appropriate common support/window contract in CPU and GPU. - [ ] R is the conservative support bound, not necessarily Gaussian standard deviation or mesh radius. Density editing may change the shape inside that support. Updating R/camera invalidates relevant culling. Never cull a contribution in graphics while physics still includes a different one. - [ ] Preserve the positive-inside summed-isosurface convention and signed influence. Use signed-distance/gradient calculations consistently for sums; a torus's own distance function is not automatically the signed distance to a sum of many species. - [ ] Keep the existing randomized real contact impulse and multiprobe winner-cache paths. Protect Tensor lifetimes during asynchronous/deferred readback; reuse cached layouts and working arrays. Do not add object/Ret allocations inside hot density loops. - [ ] Support the requested exact400 live balls with the current32-lane physics shards. The current group builder requires multiples of32. Use13 padded groups/416 physical lanes with16 inactive, masked lanes, or equivalent count-aware packing. Inactive lanes are not extra live Vars/players/balls, do not collide and are not drawn. Test full and partial last shards; do not silently substitute384 or416 balls. - [ ] A valid last compiled program remains active if a new source draft fails. Swap complete compiled programs and their matching layout atomically; never execute a shader with old offsets and new arrays. The stored Chua/Mandelbulb code includes proposed `{Name var}`, `Boil` and `Diffeq` concepts that are not proven executing opcodes in this baseline. Implement or replace these prototypes using supported upgraded Apjs; do not claim them working merely because a Var contains their strings. ## 9. The spider wireframe and radius lasso ### 9.1 Draw only real geometry - [ ] One wave has C, a true bounding-sphere outline, and its scalar Ed legs. Each ordinary leg has exactly the straight segments C->E and E->H. Every E belongs to one Ed; only H can be a join. Draw no direct C->otherC edge or extra connector to make a picture look more connected. - [ ] The R leg additionally has the needed sphere-surface arc joining R.E to the visible sphere outline. There is no general decorative elbow-to-sphere arc on every Ed. The continuous C/legs/R/outline wireframe should read as one spider with a lasso. - [ ] Deduplicate identical unordered pairs of 3D endpoints before painting. A coincident XYZ route appears once, not three slightly offset lines. Keep its contributing owner/Var/type list for picking and focused editing. Do not deduplicate lines merely because their projections coincide if they occupy different 3D positions. - [ ] Use the same derived geometry for all active CPU/GPU drawing paths and hit tests. Cache entries contain owner wave, member Vars/keys, world endpoints, primitive kind and role. They do not become another persisted graph. - [ ] Keep C at the actual center of the 3D bound. Center the apparent circle around C in ordinary near-axis views. Correct off-axis perspective may shift a true silhouette ellipse's screen center; never move physical C or R to compensate for a 2D projection artifact. Rendering and picking must agree on the chosen visible lasso geometry. ### 9.2 Radius equations and editing Use `wave.R.eeXYZ` as a persisted direction vector for this special elbow: ```text u = normalize(R.eeXYZ), with deterministic initial fallback (1,0,0) E(R) = C + max(0,R.p)*u ``` The direction's magnitude is not another stored radius. Prefer normalized values on edits; do not repeatedly normalize and write them during rendering. For a grab that moves the radius elbow to world point P: ```text d = P-C newR = length(d) newDirection = d/newR, if newR>epsilon; otherwise keep prior direction ``` - [ ] Apply newR through the shared R group's scalar edit path, and change only this owner's R elbow direction. C stays fixed during this operation. The same R can be joined to another wave with a different center/direction; both physical bounds then share the new radius. - [ ] Enforce nonnegative radius through the standard parameter bounds/group clamp policy, with a deliberate near-zero computational epsilon where division needs it. At R=0 retain the direction for regrowth. Never turn negative numerical radius into a second signed-size representation. - [ ] When center or radius moves through physics or an incoming update, recompute R.E and the surface arc immediately from those values. R.H still follows its Lone-group elbow mean and can lie elsewhere, including inside/outside this particular sphere. - [ ] The R.E-to-outline arc must be a point-on-sphere path whose endpoints actually meet R.E and the rendered outline. Pick a deterministic great-circle route/visible endpoint with degenerate-case handling. It is display geometry, not another physical constraint or dimension. - [ ] The surface outline/arc is grabbable as the R resizing wire. Arbitrary invisible points on the bounding-sphere surface are not grab targets. There is no need to create `R.X/Y/Z` to support this. - [ ] The standard bounding-radius role stays `ei=0` (Lone). Exclude it from generic Lone-to-coordinate type conversion; a radius hand may join another compatible Lone scalar, including another R. A separate potential relation can connect radius to a coordinate without changing the standard R display contract. ### 9.3 Readability and selection - [ ] Editor mode makes the graph prominent: dense overlapping bounds, noticeably thick strokes, strong local contrast and dark stroke edging against light terrain. Use one recognizable color per wave with modest Ed variations. Show full nearby skeletons and far bounds only; expose the already requested brightness/wires/background controls in a suitable existing options area. - [ ] Show true whole-wave selection with all selected bounds, Cs, elbows/hands and corresponding line highlights, plus a count such as “2 waves selected.” A highlight around the terrain surface is not a substitute: the isosurface sums selected and unselected overlapping contributions. - [ ] Distinguish C, elbow, shared hand and loose endpoint by small shapes as well as color. Show type/name/membership on focus. A grouped XYZ hand has one combined marker with accessible X/Y/Z members; a Lone hand has its scalar marker. Components never need permanent fake offset graph edges. - [ ] At a crowded or coincident line/hand, provide a local membership chooser or existing selection cycling. It identifies owner, Var path, ei and shared member count. It can focus one scalar or one wave's contribution without changing the copy selection. - [ ] Code/field popups are contextual and movable/closable. Do not cover the grabbed hand. Keep code text and actual knobs readable; a large scene must not become twenty opaque modal dialogs. Latest chat can be compact/dismissible, with full text on player focus. - [ ] Curvy ball trails are optional recent trajectories, distinct from the straight wire graph and R surface arcs. They do not add joints or participate in wire picking. ## 10. Exact controls and grab/drop behavior ### 10.1 Preserve the actual baseline mappings The source currently maps gamepad LB to grab, RB to shoot, A to create, B to toggle selection, X to delete, Y to clear selection. Movement currently uses left-stick X for side motion, left-stick Y for vertical motion, LT backward, RT forward, and right-stick X/Y for turning. Preserve these actual mappings, even where older chat prose described a different axis convention. Keep the Varjs remapping system and visible controls help. L3/R3 currently copy/paste; preserve compatibility but provide visible actions and remappable bindings so frequent copying need not require stick clicks. Current keyboard F/G/C/J/M/R/N/Del/E actions and mouse selection/disconnect behavior should route through the same action system. Do not add a second competing raw-input listener. ### 10.2 One state machine - [ ] `idle`: compute hover/otarget from the current displayed geometry. Favor explicit handles over a nearby long line, then use geometric distance and a stable tie-break. Respect the existing snap distance option and camera units. - [ ] `press`: capture a source descriptor including target kind, owner path, member selection, original group keys/state, grab position and cursor-to-object offset. Do not change source when the cursor crosses another object. - [ ] `drag`: use current 3D cursor motion plus the saved offset, update only the operation's intended Vars/placement, and render its exact release preview. Avoid snapping during drag in a way that irreversibly merges topology before release. - [ ] `release`: commit the preview target and operation in one transaction. Do not perform a second “nearest” search with different rules. If there is no valid target, perform the operation's documented raw drop. - [ ] While a grab is held, RB means no-snap/raw-drop override and does not also fire a shot. RB when no grab is active continues to shoot. - [ ] Escape/cancel/lost pointer capture rolls back an uncommitted topology edit and releases locks; already previewed scalar drag changes use the documented undo/cancel snapshot. Blur/release outside canvas must never leave a permanent grab. Typing in code/number controls suppresses gameplay hotkeys for those keystrokes. The transient grab descriptor and hover geometry can be caches. Any state needed for save/undo/network completion belongs in Varjs or the authoritative edit transaction, not only in that descriptor. ### 10.3 Meaning of each target/action | Target/action | Mutation | |---|---| | C grab | Drives the wave's actual X/Y/Z center coordinates through their shared scalar paths. It does not write wave.p as if C were the weight scalar. | | Ordinary E or its C->E segment | Reroutes this Ed by changing relative eeXYZ. It never joins or changes ei/p just to chase another hand. | | R.E or R lasso/arc | Changes shared radius and this wave's retained elbow direction as in section9. | | Whole XYZ H/group grab | Drives each existing shared coordinate axis once; present axes follow cursor coordinates, missing axes use the placement fallback. It does not create absent axes. | | Whole Lone H/group grab | Moves a temporary placement/rewiring preview; p/v do not change merely because this hand's location has no scalar-position mapping. On empty drop it returns to the deterministic elbow mean. | | Focused individual H/member drag | Detaches only the chosen member/subset for rewiring at commit; inherits current scalar state. Other members and untouched coordinate axes remain joined. | | E->H segment grab | Selects its hand operation, retaining the segment's member/owner identity; crowded segments offer the membership chooser. | | Whole-wave Move action | Translates the explicit selected set with section11's per-DOF transform plan. A joint spanning selected and unselected waves remains shared; warn/preview which attached coordinates also move, rather than silently splitting it. | | Select-owner / B toggle | Changes only the whole-wave selection set. A focused Ed is not implicitly copied. | For editor position drags, default to setting the driven group's p and v=0; update its built-in pr to the final position when ps is active so an ordinary content-placement edit does not immediately spring back. Do not change rest targets of unrelated explicit potential rules. A separate existing interaction that intentionally plucks a spring can retain its rest target; keep the two action meanings visible instead of making every drag ambiguous. Raw dropping a focused detached Lone H leaves it loose at/near its elbow. An ordinary Lone scalar has no automatic “drag height equals p” behavior in this design; its real numeric value is edited in the field grid. R is the explicit scalar whose elbow has a spatial resize meaning. - [ ] A focused coordinate-member/subset detach uses a temporary preview without changing the original shared group's p/v. On raw release, allocate a fresh partial bundle near the raw drop, set only its present coordinate p components to that drop, set their v=0 and update active built-in pr under the editor drag policy. The remaining original aliases keep their state/key. A snapped release instead uses the target-wins join policy. This prevents the entire old group moving during a supposedly individual detach, or the detached hand jumping back after drop. ### 10.4 Snapping/type compatibility - [ ] Whole coordinate handle -> coordinate handle: join X->X, Y->Y, Z->Z for axes present in both. An axis present only in the source can explicitly attach its existing scalar group to the target bundle's anchor, initializing its p to the target's undisplaced drawn coordinate on that axis; this assembles complementary X/Y/Z groups without merging different types. Preserve axes present only in the target. Missing Vars are never fabricated. Show this attach-axis result in the preview, then commit one meeting point. - [ ] Single coordinate -> matching coordinate: join just that scalar group/member selection. X->Y or Y->Z is not an implicit conversion. An explicit type edit may change the selected endpoint after detaching it from its old type group. - [ ] An X-only control and a Y/Z-only control may deliberately form one spatial handle through the explicit attach-axis gesture above. Crossing under physics does not do this. A focused X->Y scalar snap still has no compatible same-type scalar target; expose the whole-handle attach option instead of claiming that X and Y became one dimension. - [ ] Lone -> Lone: join one scalar using target-wins state. The resulting displayed hand moves to the mean of the combined elbows; show that final mean in the release preview. - [ ] Selected Lone -> X/Y/Z: offer/label the exact type conversion in the snap preview and commit that chosen member as the destination type. It does not need to bring two new axes and does not join those other groups. If the Lone was already shared, convert only the explicitly chosen member/subset, unless the user deliberately selected the whole group. - [ ] Never use a C marker, E, ring crossing or empty sphere surface as an H target. The center's scalar parameters can expose their actual hands through focused Ed editing when a user really wants to join them. Do not create a confusing direct center-to-own-child joint by snapping the C glyph. - [ ] Exclude self members/source group from accidental self-snap. A no-op is harmless; an implicit union of several groups because their markers overlap is not. ## 11. Whole-wave copy/paste, recent slots and deletion ### 11.1 Selection and clipboard record - [ ] Keep an explicit whole-wave set, using the existing `Editor.Ps$Selected` pointer machinery or a clearly separated whole-wave sibling set. Keep focused Var/E/H editing independent. Copy does not promote a hovered/focused scalar into a new selected owner behind the user's back. - [ ] Copy the selected waves across any mixture of species, their scalar/settings/placement state, nested rule instances, internal bindings and content dependencies. Capture `copyCamPos` by value at copy time, using actual camera position, not `CamCursorPosition`, a cursor hit, screen coordinates or a reference to a live JS array. - [ ] Also capture each involved full source bundle's undisplaced H0 before restricting membership to the selected waves. Persist these numeric fallback hints in the Varjs clipboard record. A later paste must still know an omitted external axis's copy-time position after that external wave moves or is deleted; it must not read live original groups to reconstruct the copy. - [ ] Use a Varjs-backed clipboard/recent-slot tree for persistent records. It can live under the local user editor branch; do not put the only durable copy in `BSx.bellsackEditorClipboard`. The records contain serialized data/paths/code identities, not raw species Var object references or live EdJoint objects. - [ ] The source wave set is exactly what was selected. Traversing dependencies may include immutable code needed to load those waves; it must not silently copy neighboring unselected waves just because a joint or rule refers to them. ### 11.2 Paste algorithm ```text delta = currentCamPos - copiedCamPos ``` 1. Validate clipboard data/schema and obtain code/binding dependencies before mutating the world. 2. Allocate fresh instance paths under the corresponding content-addressed species. Reuse immutable species code by content; do not duplicate it per wave. 3. Build an old-path->new-path map for every copied wave/subtree and rule binding. Preserve data at overlapping parameter slots. 4. Capture each original group's/bundle's undisplaced current hand H0, then restrict membership to copied members. Prepare a fresh anchor candidate at H0+delta for that copied group/bundle, including singleton/partial remnants. If an axis exists only on unselected waves, its copied fallback uses that captured current coordinate, not an old key component. Never retain the original key simply because delta is zero. 5. Translate centers, coordinate-hand p values and additional declared world positions by the per-DOF plan; translate their position rest values pr consistently. Preserve v, cv, ps, radius, ordinary relative elbows, radius direction and nonspatial scalar groups. 6. Reserve collision-free keys near the prepared H0+delta candidates, preserving the translated missing-axis fallbacks within the small representable reservation displacement. Each copied bundle uses one common anchor across its coordinate types. Do not add delta again to these already translated candidates. 7. Rewrite internal pointers to the new paths. For external references, apply the policy below. Commit the complete pasted set, select the new whole waves, and add a usable undo record. - [ ] A shared spatial DOF is translated once, even when it appears in multiple selected waves/records. An invariant alias of that same scalar follows the shared result; it is not a second independent value. - [ ] Internal copied joins stay connected. Connections to unselected original waves are detached. A copied member retains its inherited p/v/settings and now belongs only to the new copied graph. - [ ] External non-joint rule references are retained as explicit references when still resolvable in the same room, visibly identified in clipboard/paste details. Cross-room paste with missing external dependencies must report and disable the affected rule or require rebinding; do not auto-create a false target Var by reading a missing path through Proxy. - [ ] Repeated pastes use the original copy record and original copied camPos, each with fresh paths/keys. They do not compound previous deltas or start sharing state with the previous paste. - [ ] Provide recent reusable copy slots with recognizable thumbnails/names and a Varjs JSON copy/export/import path. A text-editor round trip includes species/rule source dependencies and role/binding metadata, not only visible p/v values. - [ ] If a scalar has genuinely contradictory spatial roles, show the transform conflict before committing. Do not silently corrupt the copy. This is a product validation case, not a reason for Codex to stop the entire implementation and request a new design interview. The former Ramp/Bridge/Cup selector is removed. The creation flow uses existing create/delete/select actions, chosen species source where needed, and reusable copied assemblies. A bridge, gate, lift or puzzle mechanism can be a mixed-species copy slot, not a special built-in prefab menu item. ### 11.3 Deletion - [ ] Delete the explicit selected wave set, not whatever waveform happens to own a pixel of terrain. Remove/tombstone those instances and their owned rule instances; keep shared immutable species definitions while still used or referenced by copies. - [ ] Remove deleted endpoints from joints. Surviving aliases retain p/v/settings; preserve missing-axis fallback coordinates as described earlier. Invalidate all references, layouts and shard pointers without retaining deleted live Var objects in caches. - [ ] Unresolved external rules become explicit disabled/unbound instances with a useful diagnostic or are removed by the documented owned-rule policy. They must not evaluate stale pointers or silently recreate deleted waves. ## 12. Real field grids and source fork editing - [ ] Continue using `Var.fieldEditor` for `.p`, `.v`, `.pr`, `.ps`, `.cv`; use the actual listener-backed grid, not slider artwork. Ensure external physics/network updates refresh values even while another editor has that wave selected. - [ ] Remove inappropriate unsigned-coordinate assumptions for every Var named X/Y in the generic field-editor path. The baseline's range-handling quirks must not clamp negative game coordinates. Keep sensible scalable ranges and precise numeric entry. - [ ] `ei` is a four-choice integer editor. Type changes are topology transactions. `eeXYZ` and anchor coordinates can be inspected precisely; label anchor versus current drawn hand position to avoid duplicate-authority confusion. - [ ] A source draft is local editing state until validated/applied. Edit density source at species level and potential source/bindings at the deeper rule instance/definition level; the UI must show which is being edited. - [ ] Compile/validate JS and GLSL plus their layouts before altering live instances. Use the content-addressed new species/rule definition. On success migrate only the selected instances, retaining scalar fields, liveness, elbows/hands, nested rules and compatible bindings; rewrite incoming pointers/selection/clipboard references that are meant to follow the instance. - [ ] Unselected instances keep their old species. Do not edit a shared `.big` object in place and accidentally change every instance. Do not set a zero weight to1 during migration. - [ ] If the new layout changes the meaning or type of an existing parameter, give a clear migration diagnostic. Retain removed data for undo without leaving removed slots active in the old density dependency list. - [ ] Numeric edits update buffers and derived geometry, not shader source. Cache keys include code content, language, entry point, layout and relevant capacity options; swapping only one of these is invalid. - [ ] Keep the existing code inspector able to show source, generated GLSL and generated JS. The user wants to read the compact helper-call expressions; readable generated names matter. ## 13. Persistence, BellDag and migration ### 13.1 Implement the real save bridge The generic BellDag sparse-field codecs already exist, but the active BellDog snapshot writer still emits the old six-node p/v-only grammar. Hashed species names without their `.big` code do not reconstruct a runnable world in a fresh root. - [ ] Wire complete generic field-mask snapshots and sparse patches through BellDog and the existing JSON/BellDag save controls. Keep the old six-node decoder and old JSON format as input compatibility routes. Do not silently reinterpret an old type's binary grammar. - [ ] Persist p/v and all meaningful shared integration settings, the seven new Ed fields, per-wave liveness, materials, species/rule code dependencies, bindings, spatial roles and any other nonderived state needed by this feature. Ensure explicit values of zero round-trip. - [ ] Reserve/document new field identifiers without stealing old w/x/y/z or t. The generic mask accepts more numeric letters, but encoding still needs an unambiguous schema version. A concrete extension can use unused `e/f/h` for eeX/Y/Z, `k/l/m` for ehX/Y/Z, and `i` for ei, **only after verifying those codes are unused in this baseline's authoritative registry**. If occupied, choose other free entries and document them; old codes retain old meaning. - [ ] Treat full snapshots and sparse patches differently: absent snapshot fields take schema defaults; absent patch fields remain unchanged. Deleting/resetting a field is an explicit operation. Do not run `loadMap` full-reset semantics on a partial topology patch. - [ ] Preserve Big/Bin dependency closure and verify content hashes using existing BellDag rules. Loading into a fresh root with no cached code is the required test. Never execute a hash name as if it already supplied its source. - [ ] Preserve `bellsack.bd.<slot>` versus `bellsack.<slot>` routing, custom save-query override behavior, and existing omission of Ball/Wave UI and Phy branches. New persistent topology must not live in those excluded branches. Rebuild Ball.Phy.Surf from loaded ball positions and discard all stale joint/shard/projection caches. All-world export and local-editor/clipboard export may be separate save scopes, but each must be explicit. Local camera/selection should not overwrite other users' cameras when a shared world snapshot is applied. ### 13.2 Legacy Ed conversion Old `ejW` is a relative/absolute blend, not the new integer type. Its old transform is approximately: ```text oldWorld = (1-w)*(C + R*oldEjXYZ) + w*oldEjXYZ w = clamp(oldEjW,0,1) ``` Use the exact old `edVarXYZInWorld` semantics, including its existing automatic-anchor fallback, while reading the legacy state. - [ ] First evaluate old world endpoint positions; then initialize new relative elbows/anchors. Preserve where existing endpoints appear as far as the two-segment representation permits. Default old ordinary scalar endpoints to Lone. - [ ] Old explicitly absolute matching endpoints that were visibly connected may become Lone scalar joints. Exclude old root-center special cases and uninitialized/all-zero automatic placements from blanket grouping. The new migration makes those formerly visual joins physically real, so record the deterministic winner policy: a stable sorted member representative supplies initial shared fields where legacy values disagree. - [ ] Do not map old `w=1` to new `ei=1`. Do not treat old relative endpoints on different owners as shared merely because their stored offset components match. - [ ] Preserve standard X/Y/Z center roles and R semantics without adding mandatory children. If a recognized older prototype already contains extra R.X/Y/Z or W.X/Y/Z Vars, retain its data and offer a deliberate compatibility conversion; do not delete unknown user dimensions as “obsolete.” - [ ] Mark a migrated snapshot with the new schema once. Repeated loading must not apply the old transform or rekey again. Older source comments remain history, not executable migration specifications. ### 13.3 Sparse versions and atomicity - [ ] Do not rely on arbitrary float32 absolute `.t` timestamps to preserve fine event ordering; the current generic numeric encoding cannot do that. Keep `t` for its existing meaning. Use the existing protocol integer/sequence facilities or an exact encoded host sequence/session revision for authoritative state batches. - [ ] Slow code/topology/role/settings edits and frequent p/v changes need distinct revision treatment. An old p/v update cannot revert a newer join/type edit or revive a deleted wave. Include dependency/topology revision in state application and reject/buffer an update whose schema/key mapping is not ready. - [ ] Apply a join/rekey/split/fork/paste as one validated batch. A receiver does not group partially arrived fields. Explicitly distinguish complete-message commit from transport chunks. - [ ] Cache invalidation is deterministic on load, role/type change, radius/center movement, code/layout change and dependency updates. Clear caches in tests to prove they are derived. ## 14. Live editing and multiplayer The picture represents20 players: host plus19 others; host and3 granted users may edit,16 may only play. This is a desired real room, not a static counter. ### 14.1 Reuse and finish the existing transport - [ ] Keep the existing bounded BellDag streaming parser, hashed JSP export, separate upload and long-download channels, backpressure, newest-pending-state behavior and local camera preservation. JSP remains transport/store/connection policy; it does not evaluate Apjs, Lamgl or game physics. - [ ] Use one authoritative master browser for simulation and accepted world edits in this milestone. Clients may render/interpolate and predict local motion as justified, but must reconcile to committed state. Do not pretend different GPU evaluations yield bit-identical independent worlds. - [ ] Add continuous per-player controls, owned main-ball identity, shoot-event sequence/dedup, and separate input versus world-edit paths. Incoming play input cannot specify an arbitrary Var path to mutate or another player's ball. - [ ] Raise/adapt state/input rates and interpolation from the existing 2Hz world-broadcast prototype to an actually responsive game. Do not flood full source/metadata every frame. Fast p/v batches may encode one representative per shared DOF plus a topology revision, then expand to all aliases at receiver commit; full snapshots still reconstruct every alias. Bound upstream bandwidth on a home-hosted room using sparse updates/coalescing. Measure observed input-to-visible response and bandwidth; do not print invented “low lag” numbers. ### 14.2 Permissions and shared state - [ ] Host issues/revokes edit grants for specific connections/players. Enforce them at the authoritative edit-acceptance boundary, not only by hiding controls. A play-only client must not publish an entire replacement world through the current unrestricted `publishCurrentWorld` path. - [ ] Relay-provided connection identity/capability must be trustworthy enough for the room policy. The existing client-supplied string is only a correlation label. Add minimal server-issued connection tokens/origin association if needed and bind master acceptance to them; do not require a new account service or full future Ed25519 platform before ordinary hosted play works. - [ ] Keep shared roster, roles, avatar data and latest chat in a replicated Varjs branch such as `q.Players`/`q.EditorPolicy`. The current `worldSelector` excludes all q.User; placing shared state there without changing routing would silently hide it from peers. Keep local camera/cursor/focus/clipboard under the local user branch with the intended save scope. - [ ] Commit editor operations at a host revision. Grab ownership/leases or an equivalent transaction policy prevent two editors from interleaving incompatible writes to the same joint. Show who is holding a handle; expiry/disconnect/revocation releases the lock. Keep this policy narrow and visible. - [ ] Validate source/type/binding edits before activation. The remote input route accepts bounded data/Apjs definitions, not arbitrary JS from chat or arbitrary host commands. Existing trusted local code features remain explicit, separate actions. ### 14.3 Player-facing live room - [ ] Give each player one main ball, a chosen circular avatar marker and owned shot balls. The main ball is identifiable among shots; avatar artwork does not replace collision geometry. - [ ] Show only the latest chat blurb near each player by default, with sensible overlap/culling and focus expansion. Example conversation can concern cooperative building, routes, competition, banter and ordinary social talk. In the actual room this is real player input, not scripted claims that people are online. - [ ] Show an edit badge only for host/granted editors. Different editors can hold hands, tune field grids and fork selected species while others roll/shoot. Use colored cursors tied to player identity without making the whole terrain neon. - [ ] Handle join/leave, a new client obtaining complete code/topology/state, reconnect, input replay prevention and local camera preservation. Provide clear host-room URL/JSP instructions and a way to save/share a world so players can run their own servers. - [ ] First prove host/editor/play-only behavior with3 separately loaded browsers through real Tomcat. Then test20 clients/players. Loopback load tests are useful but do not establish remote-network latency; state what was actually tested. ## 15. The playable example world and art direction Build one continuous 3D scene. The supplied image shows a direction for how it feels: bright day, wooded terrain, organic mathematical shapes and a very visible editable graph. It is not a demand to reproduce every AI-painted bump. Use `refs/01-editor-world.png` for the overall density/contrast, balls and contextual editing; `refs/02-web-only.png` for the exact illustrative graph; and `refs/03-hand-semantics.png`/`.svg` for the R arc, typed membership and partial-axis snap. `refs/editor-concept.html` is inspectable visual reference with several real presentation controls, but its depicted species editing, copying, physics and room are mockups. The main source file in the package is the engine to modify. ### 15.1 Concrete reusable content - [ ] A Bell5-shaped starting bowl funnels swarms toward two alternative paths; center/weight/radius remain independently meaningful scalar roles. - [ ] A bridge species has editable endpoint coordinates, width/curvature/load behavior and potential rules. Connect its endpoint coordinates to nearby terrain controls through real typed hands; load from balls changes the actual shared/terrain state. - [ ] A torus path provides banking, an upper shortcut and a strategic entry/exit. Use a real bounded torus density in both render and physics. - [ ] A bounded Mandelbulb/fractal gate provides visually distinctive holes/obstacles, with conservative support and a feasible iteration budget. It is an actual species, not an arbitrary imported mesh in the background. - [ ] Sums-of-sines create a wavy route whose amplitude/phase parameters can be wired into a puzzle. Avoid unbounded contributions that violate shard support. - [ ] An elevator/lift species has a moving support surface, shared height/control parameters and potential relations to a bowl/load/Mana-like control. Its motion can come from ball work, gravity, springs and coupled state; do not substitute an unrelated scripted animation for the requested physics. - [ ] Include at least one relation that is easy to see and hard to trivialize: balls load a bowl, a shared variable changes bridge tilt, this opens access to a lift or gate, and splitting shot streams produces a strategic choice. Several Vars/rules cooperate in higher-dimensional configuration space while the user sees/edits the graph in3D. - [ ] Include mixed-species copied assemblies, partially connected X-only controls, a radius-to-radius Lone joint, unjoined endpoints, negative influence and a live zero-weight editable wave. These double as meaningful acceptance fixtures. ### 15.2 Visual treatment - [ ] Use muted but distinct jade/teal, earthy clay, dusty purple, moss green and warm stone colors, sunny ambient light and varied procedural shrubs/ferns/flowers. Avoid chrome/metal everywhere, rainbow bands or blown-out neon. - [ ] Terrain and any collidable vegetation use actual supported species. Decorative shading can be cheaper, but cannot conceal a mismatch between the visible surface and where balls collide. Do not use the concept PNG as a fixed backplate in the game. - [ ] Show many bounds covering the structures, with smaller bounds for local detail and distant bounds without Ed legs. The illustrated96 bounds/552 segments are a density/readability reference, not a required hardcoded partition of every level. - [ ] Aim for400 on-screen live balls total, including20 main balls and380 shots. This resolves the approximate “20 shots each” request without accidentally demanding420 total. Pool/retire old shots deterministically and expose actual counts, not a label reading400 over a smaller scene. - [ ] Make the balls large enough in the chosen camera/world scale to see individual paths and ownership. The drawn physical ball radius and collision radius must agree; a separately sized avatar badge is fine. Curved trails show recent rolling trajectories, not invented routes a ball never followed. - [ ] Popups appear at relevant work: one editor changes bridge source, another tunes p/v/pr/ps/cv, another drags a shared hand and another resizes/positions a wave. This is one world with local editing UI, not a multi-panel tutorial comic or a prefab shape-selector sidebar. - [ ] The graph is a continuous per-wave wireframe with clearly shared hands. About half the example scalar endpoints may be loose. Crowded regions retain a component chooser; they are not simplified by deleting real dependencies. The social/strategic appeal should emerge from actual play: a player sends a heavy swarm to power a path; another takes a shortcut; an editor adjusts a mechanism while others test it; someone copies a useful assembly and shares a save. Do not implement a numerical “viral score” or promise a player count. ## 16. Implementation sequence and reviewable milestones Each milestone should leave a runnable HTML and a small deterministic fixture, not a months-long unintegrated subsystem. Track S01–S35 in TODOS; the following order gives concrete dependency boundaries. 1. [ ] **Baseline and schema:** preserve the newest file, existing tests and demo. Add fields, metadata roles/liveness and complete save/load support with old-format migration. A saved small graph reloads with caches cleared. 2. [ ] **Joint core and geometry:** implement typed key index, atomic join/split, one shared DOF, hand-position derivation, R elbow/arc and one geometry source. Exercise a tiny three-wave graph before a large scene. 3. [ ] **Controls:** complete real mouse/gamepad grabbed-state behavior, exact preview/drop, component selection, wire-only picking, whole-wave selection and real field edits. Keep the existing movement/input mapping. 4. [ ] **Vec3 Apjs:** implement type propagation and the Ret ABI with actual cached evaluator lifetime; native GLSL compiles, JS executes, nested examples and scalar regressions pass. 5. [ ] **Generic density/physics:** complete species/layout dispatch and shaders for Bell5 plus one non-Bell5 species, canonical perturb mapping, proper ball XYZ derivatives and cross-shard impulse reduction. Prove balls roll on both. 6. [ ] **Potential rules and source forks:** run per-wave rule instances, dependency scheduling, compile-before-switch and selected-instance migration. Demonstrate a loaded spring bridge connected to terrain. 7. [ ] **Copy/paste and content:** mixed-species whole-wave copies, fresh anchors, internal pointer remap, recent slots, JSON/code dependency export; then build the fuller playable world. 8. [ ] **Live room:** permissions, owned inputs/balls, stable edit transactions, source/dependency sync and reconnection through Tomcat. Test real3-role room, then20-player target and performance. 9. [ ] **Polish and delivery:** adjust density of graph/ball readability, contextual UI, gamepad help, representative playable assemblies, saved example world and an honest evidence log. Fix regressions discovered in the full path. Do not stop merely because an individual milestone is technically complete. The user's requested endpoint is the integrated game. If the environment lacks a GPU/browser/Tomcat or enough peers, finish what can be implemented and state the precise unrun gate with reproducible steps; never replace the missing evidence with mock output. ## 17. Acceptance cases that decide completion Use meaningful fixtures/reference calculations, not tests that only repeat the implementation's formulas. Keep expensive workloads bounded. Record browser/hardware, settings and actual results. ### Data and topology - [ ] T01 Save/load a fresh-root mixed graph through JSON and BellDag: zero/nonzero p, nonzero v/pr/ps/cv, all4 ei values, liveness, materials, loose/connected hands and complete source/bindings survive. Clear every cache and reconstruct the same key partition. - [ ] T02 A sparse p/v patch leaves omitted Ed/type fields untouched; an explicit zero coordinate/type update applies. A partial topology transaction never becomes visible; reordered/stale patches cannot revert a newer join or resurrect a tombstone. - [ ] T03 Initialize many zero-valued new parameters without creating a giant origin joint. A deliberately joined Lone group at the exact origin remains valid. - [ ] T04 Create2X+2Y+2Z from three waves with arbitrary nonadjacent arrays. Attach one additional X-only member: only X gains an alias; the drawnXYZ still comes from shared p values. Detach that member and then the last remaining member of an axis; other groups survive without jumping to old fallback coordinates. - [ ] T05 Two unrelated full or partial XYZ handles cross under physics and save/reload at that moment. They remain separate; deliberate hand snapping joins the intended groups. Include large coordinates where a tiny JS-double offset would vanish in float32. ### Shared physics - [ ] T06 Compare a joined graph with an independent manually reduced one-coordinate model: force, spring, mass, damping, impulse and integration agree. Additional aliases do not multiply default spring/mass or create several integration steps. - [ ] T07 For `F(q)=f1(q)+f2(q)`, prove the shared derivative is the sum; test cancellation and reinforcing partials before squaring in the impulse denominator. Repeat when aliases occur twice in one record and across two shards. - [ ] T08 Generic absolute-anchor species has explicit ball/sample XYZ derivatives matching finite differences. It must not rely on the Bell5 center shortcut accidentally passing a translation-only fixture. - [ ] T09 A ball hit changes a connected nearby/temporarily invisible mechanism through actual shared state. Turning wire LOD off leaves the physics unchanged. The bridge and elevator react under real ball load. - [ ] T10 Join two R Eds from different centers. Radius edits/physics update both bounds; C and each R direction stay independent. Test R=0, regrowth, moving C and dragging R.E around the sphere. ### Compiler - [ ] T11 The provided nested getA/getB/getC expression evaluates to sqrt5; trace call order and force each call to overwrite all Ret components. Include repeated same helper names and nested branches. - [ ] T12 Named vec3 values reused after subsequent Ret calls remain correct. Vector conditionals execute only the chosen branch. Scalar-only generated arithmetic stays direct. Unsupported signatures and recursive call cycles have source errors. - [ ] T13 Ret allocation is once per compiled evaluator context across many samples. Return X has the same float32 boundary as Y/Z. JS/GLSL sampled values/gradients meet documented tolerances on Bell5, torus, sine and bridge code. - [ ] T14 Resize one array without renaming another; reject Foo/Foo1 collisions; removed slots retained for undo are no longer active bindings unless another explicit reference uses them. A runtime ei edit does not cause recompilation. ### Editor and copying - [ ] T15 Rendered/picked geometry agrees across rotated/translated cameras, near-plane clipping, viewport resize and occlusion. No arbitrary sphere/isosurface point is picked by the normal wire tool. C remains physically correct. - [ ] T16 Mouse and gamepad actually drag; grab source is locked; preview equals commit; RB during LB grab produces no-snap and no shot; release outside canvas/blur/cancel clears capture; typing does not trigger controls. - [ ] T17 E rerouting changes only placement; Lone H rewiring does not rewrite its p; XYZ dragging changes only the present shared axes; a Lone converts to X without creating Y/Z; type mismatches do not silently convert. - [ ] T18 Whole-wave set selection is visibly distinct from focused scalar/E/H. Copy a mixed-species assembly using copied camPos, paste at nonzero and zero offset repeatedly, and verify fresh paths, internal connections, preserved scalar/radius/velocity semantics, no links to originals and correct nested pointer remapping. - [ ] T19 Export a copy through text JSON and load in a room with no cached species code. Missing external references are explicit. Delete originals, paste from the saved slot and verify it remains usable. - [ ] T20 Fork source for two selected instances while leaving another on the old species. A bad shader/source preserves the live world. Array/layout migration, zero/negative weight, selections and incoming references remain coherent. ### Whole game and networking - [ ] T21 Both recent A/B repair gates still pass as applicable. Preserve the documented graphicsDebug limitation and avoid the known448-ball×81-probe freeze diagnostic. - [ ] T22 Count exactly400 live/rendered balls with32-lane padding masked. No placeholder-lane collisions, phantom players or out-of-bounds reads. Test fewer balls and zero/partial last shard. - [ ] T23 Run real Tomcat host, granted editor and play-only client. Verify authorized editing and source forks propagate; unauthorized world replacement is rejected; own ball/shots are distinct; local camera stays local; revoked/disconnected grabs release. - [ ] T24 A new client obtains code dependencies, topology and current shared state; reconnect does not duplicate shots or resurrect deleted waves. Observe real latency/bandwidth rather than relying on counters in concept art. - [ ] T25 Exercise the20-player target with20 main balls and a400-ball swarm. Record the actual topology, frame time, GPU/CPU time, shader compile count, memory/allocation behavior and network rates. Identify any test that used bots/loopback instead of remote humans. - [ ] T26 Play the linked bowl/bridge/torus/sine/lift/gate route, build/edit/copy it live, save it, restart, load it and play again. Deliver a short how-to-play/build guide and known limitations. The world must be usable after the original authoring session is gone. ## 18. Explicitly rejected shortcuts - [ ] Do not restore five ejW types or continuous relative/absolute interpolation as the new format. Four `ei` types plus the elbow/anchor design replace it. - [ ] Do not require `wave.Name.X/Y/Z`, three consecutive slots, three arrays or a new parent Var for vectors. Arbitrary scalar expressions and hand membership are supported. - [ ] Do not join elbows, crossing lines, overlapping spheres or current rendered-position coincidences. Do not fix marker collisions by moving physical p values. - [ ] Do not fake a shared Var by independently integrating aliases and averaging afterward. Do not duplicate mass/default springs or square alias partials before reduction. - [ ] Do not allocate a JS vector object/typed array per op, return integer stack pointers, or expand every expression into a huge forest of named temporaries. Use the agreed helpers/Ret ABI, with scalar locals only where their lifetimes require them. - [ ] Do not replace copy/paste with a hardcoded Ramp/Bridge/Cup palette or infer selection from terrain pixels. Copies are whole-wave sets with dependency-aware data. - [ ] Do not mutate shared species code in place, drop source on binary save, or treat a stale pointer as a valid rule target. - [ ] Do not put shared room roles/chat under a branch that the network excludes, or call a hidden Edit button sufficient permission enforcement. - [ ] Do not count illustrative UI, generated art, labels reading400, an offline stream test or unrun checkboxes as finished gameplay. ## 19. Expected final delivery from implementing Codex - [ ] Working updated Bellsack HTML and any required exported hashed JSP, preserving the project's organization and license. - [ ] Self-contained demo world in the supported Varjs JSON/BellDag formats, including complete species/rule source, plus useful recent-copy assemblies. - [ ] Updated top checklist with implementation/verification notes; earlier TODOs preserved. A brief implementation/change log and concise controls/build/play instructions. - [ ] Evidence for the gates actually run, with honest pending live/hardware tests and known limitations. Do not ask the user to restate this design or manually reconnect the entire example scene after delivery. No further design interview is required to begin. Ordinary choices are resolved here. An actual impossible transform, corrupt save, unavailable runtime or permission denial must be reported precisely, while all independent authorized work continues. //END J:\q\Q63x\w\bellsack\codexReadOnly\gpt6AstraUltra_handoffToCodex2026-9-8-540pET **TaskKeepLamglLoopBodyAWorking, audit 2026-9-8** [x] Document beside the GraphicsDebug checkbox that A graphics debug requires physics because it consumes the ball-cache Tensor generated by that physics cycle. This longstanding unsupported combination is not being changed. ((benscomment: its been that way always. just comment it near the graphics debug checkbox.)) [FIXED AND TESTED BY CODEX/GPT (2026-9-8-1041aET). For Human to test the fix, do this: inspect the comment immediately above graphicsDebug, leave DoPhysics checked, switch to loop A, enable graphicsDebug, and confirm its ball-cache display runs. Physics-off graphicsDebug remains intentionally unsupported.] [x] Remove the undefined bootMain() call from the raw separate-GPU-rings fragment shader. bootMain() exists only in GLSL generated by sfSourceMakerA. ((benscomment: what? i found this in code: "//no bootMain() cuz thats only for code made by sfSourceMakerA.")) [FIXED AND TESTED BY CODEX/GPT (2026-9-8-1041aET). For Human to test the fix, do this: switch to loop A, enable level-editor rings and separate rings as texture, disable CPU-painted rings, and confirm the rings appear without a bootMain shader error. The generated sfSourceMakerA shaders retain their required bootMain calls.] [x] Fix A's max-ball-speed limiter to measure ball.X/Y/Z.v instead of ball.X/Y/Z.p. Record that the same bug already exists in Bellsack430.html; its original human/GPT authorship is unknown. ((benscomment: check if that was true in bellsack430. i wanna know if that was done by codex/GPT cuz i wouldnt have done it.)) [FIXED AND TESTED BY CODEX/GPT (2026-9-8-1041aET). For Human to test the fix, do this: run BS.runLamglLoopBodyAFixAudit(['max-speed limiter unit cases']) in the browser console and confirm failed is 0. It tests a far-away slow Ball stays unchanged and an origin-centered 30/40/0 velocity is clamped to magnitude 10. The same position-based bug is present in Bellsack430.html; authorship cannot be determined from the file.] [x] Allow 0..NEAR_BELL5_TOTAL active Bell5 waves. Keep GLSL arrays at the fixed NEAR_BELL5_TOTAL capacity, pad unused CPU input slots with neutral values, and pass BS.nearBells.length as uBellCount in both affected shaders. ((benscomment: isnt there supposed to be a uniform int telling how many bell5s there are which can be less than the array size which should be size enuf for NEAR_BELL5_TOTAL exactly?)) [FIXED AND TESTED BY CODEX/GPT (2026-9-8-1041aET). For Human to test the fix, do this: QuickSave first, run BS.runLamglLoopBodyAFixAudit(['three active Bell5 waves','zero active Bell5 waves']), and confirm both pass. The GLSL capacities remain fixed; uBellCount is the active count and unused slots are neutral.] [x] Fix the CPU-uniform ball-cache path. Read the complete Tensor[numBalls,1,4] using .get(), then pass its Float32Array to GLSL's uniform vec4 ballCacheVec4[] without freeing the Tensor too early. ((benscomment: Is that a tensor of sh=[1,1,4]? u cant copy a vec4 to CPU. u can only copy tensors to CPU.)) [FIXED AND TESTED BY CODEX/GPT (2026-9-8-1041aET). For Human to test the fix, do this: QuickSave first, run BS.runLamglLoopBodyAFixAudit(['CPU ball-cache vec4 uniform']), and confirm it passes. The source Tensor shape is [numBalls,1,4]; Tensor.get() copies the whole Tensor to a Float32Array before that array is supplied to vec4[].] [x] Fix multiprobe graphics-debug GLSL: replace JavaScript let with GLSL int and define startFrom before using it. Test with a bounded workload. [FIXED AND TESTED BY CODEX/GPT (2026-9-8-1041aET). For Human to test the fix, do this: QuickSave first, run BS.runLamglLoopBodyAFixAudit(['multiprobe graphics debug bounded']), and confirm it passes, then enable the A multiprobe debug display normally and look for the Newton-search tentacles.] [x] Fix the multiprobe cache-cheat GLSL's missing equals sign, wrong cachedSurfaceXYZ argument where ballCenter is required, and multiprobeSortVal declaration order. Compile-test or run only with a deliberately tiny workload. ((benscomment: where? quote the code thats missing the =. Current code: vec3 foundPoint nearestPointOnIsosurfaceFromXYZ(cachedSurfaceXYZ,startFrom); The missing "=" is between foundPoint and nearestPointOnIsosurfaceFromXYZ.)) [FIXED AND TESTED BY CODEX/GPT (2026-9-8-1041aET). For Human to test the fix, do this only when an approximately 8-second GPU stall is acceptable: QuickSave first, run BS.runLamglLoopBodyAFixAudit(['multiprobe cache-estimate cheat bounded']), and confirm failed is 0. The one-Ball/one-wave/two-start test passed in 7.66 seconds. The repaired diagnostic uses the prior cache winner and one offset because repeating all 81 offsets inside every Ball-by-Var perturb locked Chrome.] [x] Decide whether the experimental balls-in-GL-uniforms option should enforce a lower A ball count, use packed storage, or be marked unsupported/wont-fix at 448 balls because it exceeds MAX_FRAGMENT_UNIFORM_VECTORS. [FIXED AND TESTED BY CODEX/GPT (2026-9-8-1041aET). For Human to test the fix, do this: QuickSave first, uncheck IsBallsGoInTensorElseGLUniform in loop A or run BS.runLamglLoopBodyAFixAudit(['balls in scalar GL uniforms with internal cap']); confirm it runs and BS.nearBallsTotal_lamglLoopBodyA() is 64. Tensor mode remains 448.] [x] Regression-test A baseline, repeated frames, multiple physics cycles, Newton tentacles, CPU cache uniforms, separate GPU rings, CPU rings, fewer than NEAR_BELL5_TOTAL waves, and every repaired experimental branch without running the known 448-ball times 81-probe freeze workload. [FIXED AND TESTED BY CODEX/GPT (2026-9-8-1041aET). For Human to test the fix, do this: QuickSave first, run BS.runLamglLoopBodyAFixAudit(), and confirm failed is 0; then separately run the explicitly named cache-cheat case only if an approximately 8-second stall is acceptable. Codex ran the cases in bounded batches: baseline/repeated frames/two physics cycles, Newton tentacles, CPU cache uniforms, separate GPU rings, 0 and 3 waves, scalar uniforms, multiprobe graphics, and the one-Ball cache-cheat case all passed.] list kinds of example game objects for early demo of a fun game level. there are up to 3 parts of each per wave: densFunc - densityAtXYZI, chooses the shape but no forces. potenFunc - runs numRelevantVars+1 times in parallel to make float[numRelevantVars] gradient of loss, like u can put in any algebra equation of any combo of Var's, and make that equation become more true by weighted squared error. it tries to reduce poten. diffeqFunc - like potenFunc but only runs 1 time not numRelevantVars+1 times, and chooses based on those high **TaskBallPhySurfAndRandomCenterProbes** [x] Replace `q.Opt.LamglLoopBodyB.Is2InsteadOf17ThreadsPerBall` with `q.Opt.LamglLoopBodyB.IsUseBallPhySurfAndRandomCenterProbes`. Add integer options `NumMultiprobesNearBallCenter` and `NumMultiprobesNearBallPhySurf`, both defaulting to 1. In this first implementation, throw unless both values are exactly 1, leaving the options and random-without-replacement selection code ready for future expansion. When enabled, ensure every simulated Ball has `ball.Phy.Surf.X/Y/Z`; initialize these from `ball.X/Y/Z` when the `Phy.Surf` branch does not yet exist. Build the probe-start tensor completely on CPU in the existing ordering. Upload one `vec4(ball.Phy.Surf.X.p,ball.Phy.Surf.Y.p,ball.Phy.Surf.Z.p,0)` and one `vec4(ball.X.p+offsetX,ball.Y.p+offsetY,ball.Z.p+offsetZ,0)` per Ball. Choose the center offset randomly from `multiprobe_vec3Offsets`; implement selection as `multiprobe_vec3Offsets.length choose n` without replacement so future values of n cannot duplicate an offset. After GPU merge, update each Ball's `Phy.Surf.X/Y/Z` from that Ball's exact winning `ballCacheVec4.xyz`, not from the later refined signed-distance surface. Do not change physics-shard handling. When the checkbox is unchecked, retain the existing full `multiprobe_vec3Offsets` path, currently 17 probes but without hardcoding that length. Do not modify lamglLoopBodyA. Test initialization, random selection, Var updates, output shapes, the unsupported-count errors, physics behavior, FPS, and GPU/CPU timing. DONE: 2026-9-2. B now has the optional CPU-packed cached-surface plus random-center path, exact merged-cache writeback to runtime-only `Ball.Phy.Surf.X/Y/Z`, random selection without replacement, and guarded 1+1 counts. The legacy path still derives its count from `multiprobe_vec3Offsets`. Browser tests passed with 192 Balls in six unchanged physics shards: input `[12,32,4]`, merge `[6,32,4]`, all finite, zero truncation, all probe-start `.w` values zero, and all 192 exact winning XYZ caches copied. The automation display reported 60-61 FPS. In short instrumented runs, B main physics averaged about 12.28 ms optimized versus 13.29 ms legacy; the exact-cache readback was about 1.14 ms of the optimized total. Test with `test Ball.Phy.Surf + save filtering` and the existing multiprobe/merge buttons. Relevant functions include `multiprobeStartPlan_lamglLoopBodyB`, `chooseMultiprobeOffsetIndexesWithoutReplacement_lamglLoopBodyB`, `getOrInitBallPhySurfVars_lamglLoopBodyB`, and `updateBallPhySurfFromBallCacheData_lamglLoopBodyB`. **TaskExcludeBallUiAndPhyFromSaves** [x] Treat each Ball or Wave `UI` and `Phy` branch as runtime-only. Normal JSON and BellDag save paths, including quicksave, text-box save, and file save, must omit those branch roots and every descendant without modifying the live Var tree. Apply this exclusion only by Ball/Wave ancestry, not to every Var named `UI` or `Phy`. A caller-supplied custom `options.query` replaces the normal save query. After loading, recreate `ball.Phy.Surf.X/Y/Z` from the loaded ball position before its first optimized physics cycle. DONE: 2026-9-2. Normal saves now use `stateOptions.query`/`bellsackDefaultSaveQuery` to omit runtime branches under `q.Ball.<ball>`, legacy `q.Bell5.<wave>`, and `q.O2$cw.<species>.<wave>`. BellDag stree traversal honors the same query before recording names. Explicit custom queries override the default. Every successful JSON/BellDag quickload, text load, or file load reconstructs Ball surface caches from loaded XYZ. The focused browser test passed normal omission, custom inclusion, nonmutation, and reconstruction checks. Relevant functions: `isInBellsackBallOrWaveRuntimeOnlyBranch`, `bellsackSaveOptions`, `loadStateData`, and `resetBallPhySurfFromBallPositions_lamglLoopBodyB`. **Task3dTextAndLineEditor** [ ] Make rings and edlines the core 3D level-editing interface. Display every Var returned by `getUIEdVars(wave)` on its wave ring, using `Var.UI.Ang.p` radians for ring position, and paint its `Var.name` beside the edline/ring intersection. [ ] Always display `cursor3d` as a circle outline. Gamepad LB grabs and moves the nearest displayed edline tip; RB alone shoots. [ ] Left-drag one projected ed tip onto another to copy its exact `.ejX/.ejY/.ejZ`. Right-click disconnects it. Middle-click moves its whole edjoint to a deterministic average nearby 3D position. [ ] Make selection and dragging visually distinct and update CODE plus the Var field editor. [ ] Finish `SHOW: CONTROLS` as a Varjs-backed mapping where `getUser().P2$Controls.<buttonOrAxisName>.best()` returns the active capitalized `Tool*` Var. Mouse buttons, keyboard keys, gamepad buttons, triggers, and axes use the same editor. Symbols identify physical controls, multiple inputs may use the same tool, and tool behavior remains independent of bindings. **2026-8-29: 20 CHECKPOINTS TO A REAL 20-PLAYER MULTI-SPECIES BELLSACK** This is the current execution order. Complete and mark each `[ ]` as `[x]` before starting the next numbered checkpoint. Older TODOs below remain useful reference material but do not override this order. Checkpoint 20 is not complete until I have actually played the game through my own Tomcat server with 20 simultaneous browser players. 1. [x] **Freeze and implement the BellDag v0 ID.** Specify and test the exact 36-byte layout: SHA-256 or Ed25519 public key in bytes 0..31, big-endian 24-bit total node size in bytes 32..34, and full BdType byte in byte 35. Ordinary IDs hash `payload || header`; reject wrong sizes, unknown framing, and every tampered header or payload. DONE: 2026-8-30. Frozen and tested the 36-byte BellDag v0 ID, 24-bit big-endian size, final-byte BdType, SHA-256 `payload || header`, and the reserved 32-byte future public-key ID layout. Ed25519 cryptography is not implemented here; that remains checkpoint 4. Click `BellDag.testBellDag()` in the orange Test cases row. Relevant functions: `encodeHeader`, `decodeHeader`, `decodeId`, `hashPayloadAndHeader`, `makeId`, `makeEd25519PubkeyId` (layout only), `verifyId`, `testId`, and `testBellDag`. NOTE: Checkpoint 2 superseded checkpoint 1's provisional header byte order and hash preimage while retaining the 36-byte ID size. 2. [x] **Finish the strict BellDag binary core.** Implement complete-node construction/parsing, full SHA-256 verification, canonical 48-character IDs, bounded batch parsing, unknown-type retention, and a bounded immutable in-memory node store. Pass deterministic round-trip, corruption, truncation, duplicate, collision-claim, and expansion-limit tests. DONE: 2026-8-30. The strict format is `[32-byte SHA-256][little-endian BdHdr: low type byte then 24-bit content size][content][zero alignment padding]`, hashing exact `BdHdr || BdContent`; IDs encode canonically as 48 custom-base64 chars. `BdNode`, `BdStore`, bounded batch parsing, unknown retention, collision defense, Stree/Pv/SubKeyset/Vec sparse Var snapshots, two-bit include/recurse selection, and in-place restore are implemented. Click `BellDag.testBellDag()`, `BellDog.testBellDog()`, and `testSaveLoadAsBelldag()` in the orange Test cases row. The routing test proves checked QuickSave/QuickLoad, text-box, and binary file paths decode as verified six-node BdVec batches while `State()`/`Load()` calls remain 0 and the Varjs JSON slot is unchanged. Actual browser saves `bellsack.bd.1` through `.4` verified as 308,588-byte BellDag batches containing 23,702 Vars; the older separate `bellsack.1` JSON save remained untouched. VERIFIED AGAIN: 2026-8-30. Added an independent Node-crypto SHA-256/canonical-ID vector, malformed-ID and mismatched-content rejection, byte-exact unknown-node/batch round trips, every proper truncation of a sample batch node, binary/string store lookup, unverified-node rejection, and a frozen append-only `BdStore` surface. `BdNode` and `parseBatch` remain intentionally zero-copy: supplying a buffer transfers read-only ownership to BellDag. The browser run passed all three test buttons with 22,903 Vars encoded in a verified 292,416-byte BellDag batch and zero `State()`/`Load()` calls. 2.5. [ ] **TaskBasicBdStreamJspWorks.** Add header-only `BdStartStream` and `BdEndStream` types. Every BellDag HTTP body begins with `BdStartStream`; graceful finite bodies end with `BdEndStream`. Stream markers nested inside a complete BdNode are ordinary content and do not affect outer framing. Implement a long-lived download channel plus independent upload POSTs in the tiny JSP. The first browser becomes `masterBrowser`. Demonstrate three local browser tabs controlling the existing Bellsack game together through Tomcat and BellDag, with bounded parsing, buffering, backpressure, disconnect handling, and no upload/download blocking. Wire grammar uses `[BdInlineWholeNode BdHdr][complete hash-first BdNode]` for every node, adding four framing bytes while preserving the existing BdId and complete-node layout. The outer stream parser therefore sees a BdHdr before every whole node. FOUNDATION: `BdSubnode` is an immutable zero-copy view at any BdHdr int index with bounded inline traversal and explicit pointer resolution. Every `BdNode` generically remembers loaded views in `cache.subnodesByIntIndex`, including their sibling limit and immutable `.up` traversal stack identity; `clearSubnodes()` forgets those view objects without changing bytes. `BdChain(BdStartStreamObject_or_lastBdChain,nextBdNode)` returns an ordinary immutable `BdTypeChain` BdNode containing exactly those two BdIds. It has no cached length or JavaScript linked-list fields; traversal follows its pointer-list content. Mutable retention/GC optimizations remain later work. IMPLEMENTED BUT NOT DONE: 2026-8-30. `BellDag.encodeStream` and incremental bounded `BdStreamParser` passed arbitrary one-byte/seven-byte chunk splits, nested marker bytes, finite/open endings, SHA-256 verification, and framing limits. The embedded 8,143-character experimental JSP bounds rooms, clients, uploads, per-client queues, leases, and request duration; it strips only outer start/end markers and uses independent long-download and finite-upload POSTs. `BasicBdMultiplayer` elects the first downloader as master, broadcasts newest BellDog q p/v snapshots, preserves each client's local User camera subtree, disables client physics, accepts client world publication, and relays existing shoot actions to the master. The real payload test passed with 22,893 Vars, a 292,280-byte BellDog batch, and a 292,328-byte framed world message below the 1 MiB JSP limit. Use the Play panel to save the `BellsackServer.sha256_<hash>.jsp` file, connect to that exact hashed URL, and inspect live counters. Do not mark this checkpoint done until three separately loaded browser tabs exchange state and shoot actions through a real Tomcat deployment without upload/download blocking. ((( add 2 bellbyte/types (int hdr only for these) for BdStartStream BdEndStream. BdStartStream BdNode(...) BdNode(...) ... may never end or may have a BdEndStream. BdStartStream and BdEndStream normally are outermost but if they occur inside such (inner) BdNodes, they dont count. I want the JSP to do a BdStartStream on every incoming http and on every outgoing http. 2 http connections per browser tab, one to continue downloading, and the other for uploads. unless u think 1 bidirectional stream (remember this is http in unsecure_context, no websocket etc) would be just as fast or faster and NOT delay downloads waiting on uploads, and not delay uploads waiting on downloads, and not waste much bandwidth. I want to set up multiplayer, 3 browsers on my own computer (1 is masterBrowser aka the first that connects to tomcat) playing the existing bellsack together thru bd. ))) 3. [ ] **Implement every immediate BdType codec.** Use switch statements over `id[35]` for Bytes, Utf8, ListOfId, BitArray, FloatArray, Varset-related references, URL, and BellsackHtml. Validate exact payload grammar and resolve dependencies iteratively with node/depth/byte limits. 4. [ ] **Add authenticated newest-head nodes.** Embed a tested permissively licensed synchronous pure-JavaScript Ed25519 implementation with its license, then implement Ed25519Pubkey, Signed, AtSortJ, MsgTo, and Want. Reject bad signatures, replayed `j`, equal-`j` equivocation, wrong referenced types, and missing dependencies. 5. [ ] **Make BellDog canonically snapshot and restore Varsets.** Preserve exact child-edge names, metadata, normalized `.big`, deterministic Var order, and existing Var object identity where possible. Equivalent trees under independent roots must produce identical bytes and IDs; caches must be root-aware. 6. [ ] **Make BellDog encode complete and skip-safe sparse `p,v` state.** Implement VarVec, VarSubset, and VarSubsetVec using exact float32 bits. A receiver with one full base and the newest sparse node must recover the exact current state after skipping every intermediate update, including values that returned to their base. 7. [ ] **Prove server-tree to client-tree operation through a fake relay.** Run two independent BellDag stores and Varjs roots in one browser, reorder/drop/duplicate complete nodes, request missing IDs, and reconstruct the server state in the client tree. Run existing Bellsack graphics from the client tree while keeping its camera and UI local. 8. [ ] **Finish and release Jsonumbin before using network compression.** Provide exact bytes-to-bytes number-string packing followed by synchronous GZIP, bounded decompression, hostile-input tests, benchmarks, and standalone `Jsonumbin.js`. Compress transport batches only when smaller; BellDag IDs always identify uncompressed canonical node bytes. UPDATE: BellDag is replacement for jsonumbin. its push pop child strings p v system is one of the types, dont need json. Varjs becomes a runtime system not a storage system. 9. [ ] **Define the authoritative room and player-input model.** The first browser is the server browser, runs the real mutable Varjs world, and assigns every client one existing main ball plus shooting direction. Clients send signed controls; disconnecting stops acceleration without moving the main ball, and shooting launches a random non-player ball. 10. [ ] **Hook BellDog into existing Bellsack loops without replacing Varjs.** The server runs existing physics at 60 Hz and publishes immutable state as fast as practical; clients apply verified state and render/interpolate at display rate. Networking-off behavior and FPS must remain unchanged, and obsolete pending broadcasts must be discarded. 11. [ ] **Make each release reproducibly hostable.** Create the BellsackHtml node for the exact one-file game version. Embed the tiny JSP source as a multiline JavaScript string and add Play-tab buttons that save the exact HTML and `index.jsp`; keep host-specific configuration outside the immutable HTML identity. 12. [ ] **Implement the tiny bounded Tomcat JSP relay.** It only elects/leases the first server browser and relays opaque binary client/server messages for a variable number of clients. It never parses BellDag, BellDog, Varjs, Jsonumbin, Sak, Apjs, or game rules; bound bodies, queues, polls, clients, rooms, leases, and memory. 13. [ ] **Connect browser transport end to end over raw HTTP.** Implement join, server poll, client send, server reply, reconnect, newest-state replacement, missing-node Want requests, and clean timeout handling using binary XHR. Test Chrome and Firefox on different computers through the real Tomcat JSP. 14. [ ] **Harden every public upload.** Strictly verify BellDag framing, hashes, signatures, sequence order, Jsonumbin limits, Var paths/fields, finite numbers, ownership, and total work before applying anything. Implement fresh challenge-bound proof of work over every exact compressed upload, with adjustable difficulty and nonblocking Lamgl mining. 15. [ ] **Play the existing Bell5 game online before changing species.** Run an internet session with at least 3 to 5 real browser players: the server player edits terrain, clients move assigned balls and shoot, all see the same 320-ball reshaping world, pause works, joins make a sound, and reconnects recover without restarting the room. 16. [ ] **Restore a real Species abstraction for both Sak and Apjs.** A Species identifies immutable source, required child Var names/order, CPU behavior, GPU behavior, wave size, and resource bounds. Receiving code does not execute it; only validated/selected Species enter a Zoo. 17. [ ] **Make one Apjs Bell5 species work end to end.** Verify pointer arithmetic, `i+`, `i-`, `i*`, `oo`, copy operations, loop bounds, memory bounds, and GPU work limits. Compile one Bell5 Species to CPU and Lamgl forms, compare it with existing Bell5 behavior, and make invalid code display a warning while doing nothing. 18. [ ] **Make a genuinely multi-species Zoo work in graphics and physics.** Run Bell5 and Torus, then optionally Mandelbulb, in the same ghost with variable runtime wave counts and canonical Var-backed parameter layouts. Balls must render, roll, collide, and reshape the combined terrain without returning to hardcoded Bell5-only density. 19. [ ] **Finish the editor, shared content, fun level, and 20-client rehearsal.** Mouse-selecting a RingResult puts its Var path in CODE and its source in the large box; editing recompiles the selected Species into the Zoo. Sync immutable Species/`.big` nodes through BellDag, build and tune one fun multi-species level, test 20 active browser clients, fix FPS/bandwidth/desync failures, publish the exact HTML ID, and schedule the play session. 20. [ ] **Play the completed 20-player game on my own server.** Deploy the generated `index.jsp` and exact Bellsack HTML to my Tomcat, connect 20 simultaneous browser players across real computers/browsers, and play the multi-species ball/terrain game together long enough to exercise movement, shooting, collisions, editing, reconnects, and state recovery. Save the final BellDag world root, measured FPS/bandwidth/errors, and session evidence; only then mark this complete and write the next expansion TODOs. 21. Look thru the yellow/right panel which is a text box. 2026-8-30 im moving a bunch of disorganized todos from here to there, tho Im not sure if alot of that still needs to be done if do the 20 above first.

PLAY:    Play online. Like IPFS, not responsible for P2P user content. single       player

Unlimited usernames. Password instant creates username (by ed25519) and is not uploaded. If lose password, cant recover cuz end-to-end. Hackers get unlimited tries, use long password. Same user/pass work at many URLs/Tomcats. Dont need to login to make "P2P user content". Some features may only be available logged in. TODO careful what source of randomness used if randomly generate a password, dont use the time only. PASSWORD:    USERNAME:

SAVE:

OPEN:

OPTION:

CONTROLS:

TOOL:    Play Game (FIXME) Select (FIXME) Hold Still While Coding (FIXME) Paint Walls/OpenArea (FIXME)

VarUI:    TODO put VarUI here

CODE:

Play BellSack: move with left joystick and triggers, turn with right joystick, add/shoot balls with LB/RB, Select toggles A/B, Start toggles pause, left-stick click toggles Bellsack (Esc), right-stick click toggles TOP/red, both stick-clicks reload page. Edit terrain by mouse dragging the 5 colored knobs per circle/bell.

---

(this does nothing 2026-8-2, use Lamgl.isDoExperimentY2026M8D2_loadGlExtension_KHR_parallel_shader_compile instead)

---

i need potential and kinetic energy computed both before and after the dt change. the steps are mixed up. Var.poten is not the only kind of potential energy. loss already includes that, so u shouldnt directly. There is 1 loss for whole world state (set of Var's), not per Var. One way to do it would be, tho i hope i dont have to complicate it with this, create .nextP and .nextV fields in Var, and have aVar.nextStateTemp(dt) set those in aVar.nextP and aVar.nextV which we will call nextStateEnd, and nextState(dt) would call nextStateTemp(dt) then this.p = this.nextP; this.v = this.nextV; so lamglLoopBody could call only nextStateTemp(dt) then adjust aVar.nextV to norm energy, then aVar.nextStateEnd(). is there another way to do it, or do we gotta do that?

---

WARNING: Lamgl_makeSomeConstantsUniformsToPreventLoopUnrollingWhichSlowsCompiling does not display its mods in that code, such as turning "((80))" into "((uniform80))" then putting {uniform80: 80} into the Lamgl param, cuz that happens after sfSourceMakerA, but expect it to be there if the Is_Lamgl_makeConstantsUniformsNoLoopUnroll checkbox is checked (q.Opt.Is_Lamgl_makeConstantsUniformsNoLoopUnroll.p is nonzero), and use browser debugger to see that.

---

(see IsBallBallRecovIfBounce farther below)

---

---

FIXME the 3 multiprobe checkboxes are not working yet 2025-12-4-9aET.







(TODO disable the other forces so this bounce can be tested alone.)

---

hypothesis_saddleringBugHappensCuzTheresLocalminOf(densityAtXYZ)NearCenter!!! Saddlering bug is back. So many terrain shapes can happen so fixing it in some breaks it in others. think I know why. Local-mins. The isosurface is densityAtXYZ(vec3)=0. Positive density is inside. Negative is open area. In mid air theres probably gradientAtXYZ(vec3)=vec3(0,0,0).














float extraExperimentalDensity(vec3 xyz){ //define this GLSL func return 0.; }

Bellsack 575.03 (and later) now has async compiling in Chromium but still sequentially delays in Firefox. This experiment uses the bell5Textarea text box at bottom of the top/red panel. If you edit it, you see the terrain change 1 second later but it keeps running smooth with previous compile until then. This will let you keep playing during loading as you move thru the 3d world, in future versions. Loading time sucks and Bellsack is not gonna have it during play. It will simply load stuff when you get near it before its needed. When editing, there will be about 0.2 seconds delay but for now 1 second delay, but either way that will happen async except in firefox which only has sync so in Firefox you can wait the 0.2-1 second as if a loading screen.
//EstimatePhysicsFlop: bells*25 float sumOfBellcurves(in vec3 p){ float val=0.; //float val=0.0001; //FIXME //for(int i=0; i<${BS.opt.NEAR_BELL5_TOTAL}; i++){ for(int i=0; i<uBellCount; ++i){ //for(int i=0; i<$ BS.opt.NEAR_BELL5_TOTAL ; ++i){ //if(bellX[i]>=NULLXYZ) continue; //FIXME do all loops, ignore later loops, cuz nonbranching //if(includeBell[i]){ //includeBell is an experiment 2026-6-29 to make densityAt* funcs run much faster by making it sparse by bounding spheres. FIXME make the bellcurve cut off hard at maybe 3 stdDevs, but for now just define it that way in includeBell. //vec3 d = p - bellPositions[i]; vec3 d = p - vec3(bellX[i],bellY[i],bellZ[i]); float dist2= dot(d,d); //dist2 += sin(dist2*33.); //FIXME this adds a sine wave outward from center of each bell5 //dist2 += sin(dist2*3.9); //FIXME this adds a sine wave outward from center of each bell5 //dist2 += 5.*sin(dist2*1.09); //FIXME this adds a sine wave outward from center of each bell5 //dist2 += 2.27*sin(dist2*1.09-p.x+sin(p.y)*cos(p.y*3.45)); //squiggles, like in Bellsack (433) float br = bellRadii[i]; //Bell5 bounding radius. if(dist2 > br*br) continue; float sd = max(br*Bell5StdDevIsWhatFractionOfBoundingRadius,1e-9); val += bellStrengths[i]* exp(-dist2/(2.0 * sd*sd)); //} } return val; } /*SIMD compatible, though it might go faster if i raise number of multiprobe offsets to exactly 32 instead of its now 17 as of 2026-6-29-1010a: actually, with multiprobe and signedDistance_ballId_numVarsPlusOne, if we key it by ballCenter, it will be the same for x as 0..16 cuz of 17 multiprobes and varId is around 500, so i dont think we need to change anything about ball indexing. im already using 17 GPU threads per ball in one and about 500 GPU threads per ball in the other. and raytracing has rays near eachother so that tends to help. So im good. use my code as it is UNLESS ITS BROKEN.DO NOT REWRITE IT UNLESS ITS BROKEN. GIVE ME THE MINIMUM LINES CHANGED TO MAKE THIS HAPPEN. tell me where to hook it in. If its graphics, use line from camPos toward horizon in that direction. If its physics then use ballCenter with a boundingRadius of 5*BS.opt.ballRadius. */

You can delete all this text if you want. Put anything here. Use it for copy/paste. Its erased each time the page reloads. bellsackHaveDecidedOnAtLeastSomeEdsAreGroupedIntoTriplesXYZSoCanSnapWavesTogetherLikeLegos Im back from chatgpt. Do it as wave.R.X wave.R.Y wave.R.Z are a point on the bounding sphere surface that wave.R gets synced to, around bounding sphere center wave.X wave.Y wave.Z, and wave.W.X wave.W.Y wave.W.Z are a 3d point that moves freely in X and Z but wave.W.Y.p-wave.Y.p is its weight which gets synced to wave.p. Primary storeage of weight is wave.p, as it is now, but we add 3 nodes to make it made of 3d nodes. Primary storage of boundingSphereRadius is wave.R.p, as it is now, but we add 3 nodes to make it made of 3d nodes. wave.p being 0 still means the wave doesnt exist, tho we dont have to sync it right away in that case, give it time to move wave.W up (in y dimension relative to wave center), or maybe wave.W is just how you fade it in/out/negative weight and loosely associates with wave.p, something like that. Think thru this by how bell5 works. ... Lets use the standard of 3 core 3d eds (9 vars) per wave: . - Cx Cy Cz for center. . - Rx Ry Rz for a point on its boundingSphere, distance R from C but R and C are not vars themself. . - Wx Wy Wz for weight. Wy-Cy is weight. Wx and Wz are ignored except as the position of the W 3d ed. . A wave can have more 3d eds (than those 3) and use them however it wants. We only have to care about Cx Cy Cz Rx Ry Rz Wx Wy Wz to define the boundingSphere and weight (so 9=>5). . For example, the bridge hanging between 2 mountain tops might define 2 extra 3d eds that you join to the 3d eds at each mountain top to hang the bridge between. So it would have 5 3d eds, total 15 vars. It might also have a few more 3d eds for bending the bridge various ways. . For example, want a spring to keep 2 chosen 3d eds a particular distance (or spring toward that distance) from eachother? Make a wave that is such a spring and drag those 2 eds to join others. ---------------------------------------------------------------- ---------------------------------------------------------------- ---------------------------------------------------------------- ---------------------------------------------------------------- ---------------------------------------------------------------- ---------------------------------------------------------------- ---------START BELLSACK RULES100+------------------------------- bellsackRule101: The state space of the Bellsack game engine is a Varjs vector. Varjs is a sparse map of string to number. Not all strings are allowed. These strings are usually 1-50 chars but can go as high as millions of chars such as to store any file of any content-type or Lamgl.Tensor objects etc. When they do, they are hashed to a smaller string that can not otherwise occur, which is SomePrefix$ (up to and including the first $) then 42 base64 chars of the first 252 bits of sha256 hash of the content SomePrefix$...content . Any string, or path part between "." in that string, that starts with capital A to capital Z is allowed. Strings whose last path part after the last "." start with lowercase or other chars are only allowed if they are among a few standard names including p v pr ps cv kv mn mx. Strings that start with "v." or are just "v" are from the root Var object. Starts with "q." or is just "q" is a specific var within v such as v.Bellsack.Room55 . p and v are the most important. They mean position and velocity of movement in the dimension named by the prefix of the string before the ".p" or ".v", such as in v.Bellsack.Room55.Thing.OtherThing.p is the position of v.Bellsack.Room55.Thing.OtherThing . v means the root of the varjs tree. q means the current namespace such as v.Bellsack.Room55 in that case. These strings are designed to return the number value when the string is typed on browser console or in js code, if they end with the .p .v .mn .mx .cv etc standard lowercase-starting suffixes. If it ends with something else, such as v.Bellsack.Room55.Thing.OtherThing, that returns a Var object. v is a Var object. v.Bellsack is a Var object. v.Bellsack.Room55 is a Var object. v.Bellsack.Room55.Thing is a Var object, and so on. v.Bellsack.p returns a number. The BellDag library is a binary data format similar to Varjs. The BellDog library connects BellDag to Varjs but is only a compressed data format of it so you can convert between Varjs <---> BellDag. Varjs has mutable numbers but the string keys are immutable. BellDag is immutable and should approach near 100% binary storage efficiency, maybe 95%. Varjs will only be about 70% binary storage efficient cuz it can do base64 but not binary directly. The base64 chars we use are $0123456789ABCDEFGHIJKLMNOPQRSTUVWXYZ_abcdefghijklmnopqrstuvwxyz cuz those are ascending order of utf8 and of ascii. Various softwares may use Varjs differently, but the data format should be copyable between them. Each game normally goes in v[gameName] such as v.Bellsack or v.QuadCraft, and then a room name like v.Bellsack.CrazyMonkeyRoom5 . anyVar[anyString] creates a child Var. Thats how player created content is added. Maps with Var keys can be made by using .p of 0 as not existing and .p of nonzero (default 1) as existing, such as you might use someVar.P2$theMap['v.Thing.OtherThing']['v.The.Value.Is.This'].p = 1; to mean someVar.P2$theMap is the map and the key v.Thing.OtherThing (which evals to a Var) maps to v.The.Value.Is.This (which evals to a Var). If you want it to map to just a string, use that string directly instead of 'v.' or 'q.' prefix. someVar.P2$theMap['v.Thing.OtherThing'].SimplerValueIsThis.p = 1; means the value is 'SimplerValueIsThis'. Strings that start with P1$ go 1 hop deep before interpreting the .p as exists/notExists. P2$ go 2 hops deep. P3$ goes 3 hops deep, and so on. P1s$ P2s$ P3s$ etc allow multiple values so is a bag instead of a map, set instead of a single value, etc. P means pointer. Ps means pointerS. O1 O2 O3... are used like P1s P2s P3s and likely should be merged cuz those are likely duplicate prefixes (TODO). Theres Sak$ for sak language. Json${"hello":"world"} for json content, Ap$ for Apjs language, and various other arbitrary prefixes. These patterns of strings exist at a higher level than Varjs simply being a map of string to number, and they depend on specific softwares being loaded that use Varjs, but hopefully we can all agree on the sync of the Varjs map of string to number in general which many systems might someday sync thru at gaming-low-lag and put arbitrary content in to expand open-endedly. This is the core of Bellsack, before we even get into 3d curves or balls rolling on them. There is nothing in Varjs specific to curves or balls. Its a general computing system. **Each Var object is exactly one dimension.** Creating a child Var creates another dimension. '.p', '.v', '.pr', '.ps', '.cv', etc. are properties of that dimension, not more dimensions. 'Var.big', 'Var.bin', and 'Var.bd' also do not create dimensions and are what Var.name (path part) are derived from deterministicly. Bellsack must not create a second independent state space beside Varjs. All further expansion must follow this rule. Varjs must be the primary storage of all Bellsack state. Caches, GPU buffers, packed arrays, indexes, BellDag/BellDog, and other representations may exist only as derived or compressed forms of that Varjs state. ---------END BELLSACK RULES100+--------------------------------- ---------------------------------------------------------------- ---------------------------------------------------------------- ---------------------------------------------------------------- ---------------------------------------------------------------- ---------------------------------------------------------------- ---------------------------------------------------------------- ---------------------------------------------------------------- ---------------------------------------------------------------- ---------------------------------------------------------------- ---------------------------------------------------------------- ---------------------------------------------------------------- ---------------------------------------------------------------- ---------------------------------------------------------------- ---------------------------------------------------------------- ---------------------------------------------------------------- ---------------------------------------------------------------- ---------------------------------------------------------------- ---------------------------------------------------------------- ---------------------------------------------------------------- ---------------------------------------------------------------- ---------------------------------------------------------------- ---------------------------------------------------------------- ---------------------------------------------------------------- ---------------------------------------------------------------- ---------------------------------------------------------------- ---------------------------------------------------------------- BELLSACK Bellsack is an opensource/Apache2 browser game and experimental programmable world by Ben F Rayfield. It runs from one HTML file. Lamgl uses the GPU for graphics and field calculations, while Varjs holds the live mutable state of the world. Most 3d games build their worlds mainly from fixed polygon surfaces. Bellsack terrain is made from overlapping mathematical scalar fields. The current Bell5 species can form smooth hills, bowls, tunnels, walls, ramps, and moving surfaces. Its waves have positions, sizes, strengths, velocities, and other dimensions, so the terrain is part of the simulation instead of being only scenery. The current game is a physics sandbox and puzzle prototype. You roll a main ball through a mathematical skatepark while hundreds of other balls move, collide, carry weight, react to gravity and g-forces, and interact with terrain. Balls can be aimed and shot through the world as moving tools and puzzle pieces. The result is part ball game, part level editor, and part live mathematical experiment. Future versions are intended to let multiple species of shape exist in the same world. Bell5 terrain can be combined with toruses, fractals, bumpers, and shapes that players write in Sak or sandboxed Apjs. A level editor will let a player select a shape in the world, inspect its place in the Varjs tree, edit its code and parameters, and immediately use the compiled species in the game. Bellsack is also being built for player-hosted multiplayer. BellDag stores world snapshots and shared content as compact immutable binary nodes identified by hashes. BellDog connects those nodes to the mutable Varjs runtime. A small Tomcat relay will move the bytes between browsers while a master browser runs the authoritative game. Players will be able to join a world, control and shoot balls, edit when permitted, share new shapes, and run their own servers instead of depending on one permanent central service. The reason to play future Bellsack versions is that the world itself is programmable, physical, shareable, and not limited to a fixed set of level geometry. Friends can explore a strange moving space together, solve or invent physics puzzles, reshape it while playing, publish new mathematical species, and carry an exact hashed world to another server. This build is active development software, but those pieces are being connected into that game. OLDER DEVELOPMENT NOTES TODO lamglLoopBodyB deferred GPU readback/fencing funcs exist but are disabled for timing research 2026-8-18. Keep lamglFenceAfterQueuedWork_lamglLoopBodyB, deleteLamglFence_lamglLoopBodyB, isLamglFenceReady_lamglLoopBodyB, queueMainPhysicsSignedDistanceReadback_lamglLoopBodyB, tryReadbackPendingMainPhysicsSignedDistance_lamglLoopBodyB, discardPendingMainPhysicsSignedDistanceReadback_lamglLoopBodyB for later. Do not call them from lamglLoopBodyB/main physics while measuring synchronous SpeedStats, except future explicit isSkipCompute/deferred-readback experiments. TODO using sfSourceMakerB make all terrain 1 ghost and 1 odo, despite it being many possible glsl codes aka species. Optimize this by compiling a new kind of densityAt* shader (which puts all .p / position in 1 gl float array. ...instead of this... TODO using addExampleWavyBells, q.O2$cw.Sak$123hashOfCode456.Wave1234 c being code/species (1 ghost per species), and balls stay as they are. Split later into multi species per 3 shaders, like 1-10 species per shader and 1-10 such groups compiled together, so can up to 100 species of terrain on screen at once. TODO q.O2$cw.Sak$435hash7343.Instance500.Ptrs$fn for diffeqfuncs andor potenfuncs, but shapefunc goes in q.O2$cw.Sak$435hash7343 ;       opensource/<a href=https://www.apache.org/licenses/LICENSE-2.0>Apache2</a><br> (TODO ed25519 with separate opensource license?)<br>  Like IPFS, not responsible for P2P user content. [[[[["21. Look thru the yellow/right panel which is a text box. 2026-8-30 im moving a bunch of disorganized todos from here to there, tho Im not sure if alot of that still needs to be done if do the 20 above first." **TODO: PATH TO FAST 20-PLAYER MULTI-SPECIES BELLSACK** 1. Specify **Jsonumbin** as a browser-only, exact bytes-to-bytes format for arbitrary JSON or JSON-like data. A `.jsonumbin` payload starts with `JsonWithNumberStringsBinaryPackedBeforeGz$`; `.jsonumbin.gz` is that payload inside ordinary GZIP. 2. Implement the reversible number-string packer. Scan raw bytes for canonical JavaScript-style numbers and encode profitable values as tiny prefixes plus raw `int32`, `float32`, or `float64` bytes, including `NaN`, infinities, and `-0`. 3. Guarantee byte-exact restoration. Escape token-prefix collisions, retain any spelling information required for exact recovery, and leave a number as text whenever packing it would not be smaller. 4. Bundle a synchronous, permissively licensed GZIP library inside the Jsonumbin script tag. Keep its original license and give the Jsonumbin wrapper the same Apache-2.0-style header used by Lamgl, Sak, and Var. 5. Expose `Jsonumbin.compress(bytes)`, `Jsonumbin.decompress(bytes, limits)`, and separate public number-pack/unpack functions. Compression has no tuning options and always does its best. 6. Harden only the bytes-to-bytes boundary: reject malformed tokens, truncation, invalid lengths, trailing data, and expansion bombs. Default decompression to at most `100x` its compressed input size unless the caller supplies different limits. 7. Build exhaustive round-trip, corruption, fuzz, and size tests. Add a browser benchmark comparing raw data, ordinary GZIP, and `.jsonumbin.gz` using real Bellsack, QuadCraft, numeric, random, and JSON-like inputs. 8. Publish the exact script-tag contents as standalone `Jsonumbin.js`, plus its binary-format specification and benchmark page. Then integrate that same code into Bellsack save/open and networking. 9. Build the first multiplayer experiment around one public room. The first browser is the authoritative server browser; everyone else is anonymous and receives only a temporary routing handle. Edit: The JSP relays what comes in as byte array from other computers to the master browser (one acting as server) and it answers back, other than the .big / theserver.com/Bellsack/big/Sak$345345hash345345345 returns content which hashed to Sak$345345hash345345345. and other than size limits. and we make them do 1 gigaflop of proofOfWork per 1kB uploaded, with options/BS.opt adjustable difficulty rate, to prevent DoSAttack/spam/etc. 10. Keep this first room intentionally temporary. It ends when the server browser leaves, has no automatic host migration, and gives every participant enough world state to save and later start a separate server manually. 11. Make the relay JSP handle bounded opaque binary messages and immutable `/Bellsack/big/<hash-id>` uploads. Verify the content hash, write only when absent, never modify an existing file, and serve those files through ordinary GETs. 12. Require fresh challenge-bound proof of work for every uploaded packet, continuously proportional to exact uploaded bytes at one gigaflop per KiB. Downloads and GET URLs cost no proof. 13. Use an exact 55-byte SHA-256 proof input and the flop-adjusted `sha256ProofOfWork` score. Implement real nonblocking Lamgl SHA-256 mining; keep CPU/Java verification deterministic and never let mining stall rendering or physics. 14. Stream all relevant non-`.big` Vars within one bounding sphere around the server player’s camera. Everyone initially stays nearby; missing `.big` content is fetched by hash from `/Bellsack/big/`. 15. Make the current built-in Bell5 game playable online before Apjs. Keep the roughly 320-ball count constant, let the server player edit terrain, and assign each client control of one existing ball plus one shooting direction. 16. On shooting, move and launch a random ball that is not any player’s main ball. On disconnect, release the assigned main ball without moving it and stop applying that player’s acceleration. 17. Send client controls at 60 Hz and world state at least 30 Hz, faster when practical. Keep only newest pending state, measure compressed bytes/second and RTT, and stop accepting joins whenever server-browser FPS falls below 30. 18. Deploy the basic game at one raw-IP URL and test it with a few real players until movement, shooting, reshaping terrain, ball weight/g-force puzzles, and playing together are fun. Auto-pause when alone, auto-unpause on joins, and alert the server player with sound. 19. After basic multiplayer works, finish Apjs locally: prove pointer arithmetic and memory bounds for `i+`, `i-`, `i*`, `oo`, `copy`, and related operations; bound every loop; account for total GPU work/memory; and turn invalid or over-budget code into a warning and no visible effect. 20. Hook verified Apjs into Lamgl for Bell5, then add Torus and the Ring-selected multi-species editor. Share Varjs trees containing `Ap$` or `Sak$ ap:` source, never GLSL; let all players upload hash-addressed species and compile them locally; then recruit through the GitHub release, a short gameplay video, and scheduled sessions until 20 internet clients across at least Chrome and Firefox on multiple computers can play the compressed multi-species world together. 2026-8-28 TODO: GET EXISTING BELLSACK MULTIPLAYER AND FUN FOR 20 PLAYERS ONLINE ASAP This is now the first priority. It comes before the older level-editor and multi-species work below. Do not redesign Bellsack physics, Lamgl, Varjs, Zoo, Species, Vset, Vdag, or EdJoint while getting the first multiplayer version working. Success for the first release: - Twenty browsers can join the same ?room=Room1 URL and play the existing Bellsack world. - ?room=Room55 is a separate world. - The first browser in each room acts as that room's server browser. - Tomcat runs only a tiny bounded opaque-binary relay JSP. - All live request and response bodies use synchronous JZP1 Jsonzip bytes. - One browser leaving does not permanently stop the room; another browser can become server. - Existing graphics and physics continue working without waiting for network requests. - The current 320-ball lamglLoopBodyB game remains the starting game. Do not wait for multi-species. PHASE 1: FINISH JSONZIP FIRST - Embed Jsonzip in its own script tag before Varjs and Bellsack depend on it. - Use exactly one format and magic: JZP1. - Required synchronous APIs: Jsonzip.jsonToJsonzipCompressedBytes(jsonString)=>Uint8Array Jsonzip.jsonzipCompressedbytesToJson(bytes)=>jsonString Jsonzip.jsonzipCompressedBytesToJson(bytes)=>jsonString - Jsonzip preserves JSON.parse(input) semantics, not whitespace, source number spelling, duplicate source keys, or formatting. correction: no its a general string compressor that is optimized/tuned for json and float32 float64 and int32 numbers in string form such as "2.332e-10". - Preserve null, booleans, zero, negative zero, safe integers, exact Float32 values, Float64 values, arrays, objects, Unicode, emoji, and lone UTF-16 surrogates. - Use one shared append-only string dictionary for keys and values. - Deduplicate ordered object-key shapes, especially repeated Varjs objects such as {p,v,t}. - Use typed binary number tokens before synchronous raw DEFLATE. - If raw DEFLATE does not reduce size, store the token stream uncompressed. - Do not use Base64 in Jsonzip files or live networking. - Do not use JSZip, CompressionStream, DecompressionStream, Chrome-specific compression APIs, npm, modules, CDN code, WebAssembly, or Web Workers. - Keep the codec independent of Varjs so it remains a general JSON compression format. - Keep editable limits for compressed bytes, expanded token bytes, output JSON characters, depth, strings, shapes, containers, and total nodes. - Reject wrong magic, unknown flags/compression/opcodes, malformed varints, invalid references, duplicate shape keys, invalid UTF-8, malformed UTF-16LE, nonfinite numbers, truncation, trailing bytes, oversized containers, excessive depth, and expansion bombs. - Decode strictly and fail closed. Never recover partial corrupted JSON. - Add Jsonzip.test() covering valid values, corruption at every byte boundary, malicious lengths, dictionary references, shapes, negative zero, and semantic round-trip. - Add local .jsonzip Save/Open support. Local user-opened saves retain the existing trusted local Load behavior. - Network Jsonzip is untrusted and must go through separate strict Var-map validation with isAutoEval:false. - Measure raw JSON UTF-8 bytes, ordinary raw-DEFLATE JSON bytes, token bytes, final Jsonzip bytes, encode time, decode time, and exact semantic round-trip. - Proof of work later covers the exact final compressed Jsonzip bytes, not decompressed or reserialized data. PHASE 2: SELECT ROOM AND PLAYER BEFORE BUILDING WORLD STATE - Read ?room= from URL before creating anything beneath q. - Default to Room1. - Strictly validate room names before using one as a Var child, relay identifier, or future filesystem-related value. - Set q = v.Bellsack[roomName]. - Set VarVM.rootV = v and VarVM.rootQ = q. - Put the default room into the URL with history.replaceState when absent. - Give every tab a separate Player$ identity using 16 crypto-random bytes and sessionStorage. - Allow a strictly validated ?player= override for testing. - Change getUser() from q.User.Boot to q.User[localPlayerName]. - Initialize a new player's camera quaternion once, but never overwrite camera state loaded from the server browser. PHASE 3: DO NOT LET EVERY CLIENT CREATE A DIFFERENT RANDOM WORLD - Remove the unconditional buildWorld() during script evaluation. - Do not touch timestamps or start normal networking before learning whether the room exists. - The first elected server browser initializes an empty room by calling buildWorld() once. - Other browsers load that server browser's canonical initial state and never call buildWorld() for that existing room. - Start renderLoop only after initial room selection and state initialization complete. - A failed initial network connection must retry and display status, not silently generate a separate world. - For fast first deployment, the elected server browser is authoritative for physics and accepted state changes. - Ordinary clients render received state and send controls/edits; do not let every client run conflicting authoritative physics. - Keep the design replaceable later. This first open server-browser authority is not cheat-proof. PHASE 4: EMBED THE TINY JSP SOURCE INSIDE THE HTML - Put the complete JSP source in the first script tag in the Bellsack HTML. - That first script tag only defines this multiline string and performs no action: window.BellsackAjaxJspCode_warningThisGetsExecutePermissionIfYouUseItItCanDoAnythingYourComputerCanDo = `...complete JSP source...`; - The JSP source should be approximately 200 lines and have only one purpose: bounded opaque binary message relay. - Put a button in the Play tab named: Save JSP for Tomcat/webapps/Bellsack dir - Clicking it downloads the embedded string as index.jsp using the existing saveFile() function. - Download with application/octet-stream so the browser saves the exact JSP source. - The HTML remains the one distributed source file even though Tomcat deployment produces index.jsp beside the HTML. - The warning variable name is intentionally long because running a JSP gives that code the Tomcat process's filesystem and computer permissions. PHASE 5: KEEP THE JSP AN OPAQUE BINARY RELAY - The JSP must not parse JSON, Jsonzip, Varjs, Sak, Apjs, .big content, world state, player controls, or game rules. - Require POST. - Body-bearing operations require Content-Type: application/x-jsonzip. - Read bytes through request.getInputStream(). - Write bytes through response.getOutputStream(). - Never use request.getReader(), out.print(), Base64, Java serialization, ObjectInputStream, eval, shell commands, or runtime compilation. - Use operations such as getChallenge, join, serverPoll, send, and serverReply. - join elects or reports the server browser for one room. - serverPoll lets the elected server browser receive one waiting client body. - send submits one client body and waits for its matching response. - serverReply supplies opaque response bytes for exactly one pending client request. - Put room, client, request, challenge, nonce, and routing information in strictly validated query parameters and response headers. - Do not prepend or append a JSP envelope to the Jsonzip body. - Use per-room queues and locks. Never serialize all rooms under one global message lock. - The first valid browser joining a room becomes server while its renewable lease remains alive. - If that lease expires, the next valid joining/polling browser becomes server. - Expire abandoned requests, late replies, dead leases, idle clients, and idle rooms. - Bound compressed body size, rooms, clients, queues, pending requests, poll duration, challenge count, and total relay memory. - Count bytes while reading even if Content-Length is absent or false. - Require one in-flight send per ordinary client so stale game frames cannot accumulate. - Reject cross-site browser requests and never send Access-Control-Allow-Origin:*. - Use Cache-Control:no-store and X-Content-Type-Options:nosniff. - Return only status codes and small bounded errors. Never reflect bodies, stack traces, filesystem paths, JSP source, Java exceptions, or secrets. PHASE 6: SERVER-BROWSER BYTE CALLBACKS AND DEFAULT BROADCAST - Add a small replaceable Bellsack callback shaped like: bytesFromTomcat=>bytesBackToTomcat - The elected server browser calls it for each opaque client message delivered by serverPoll. - Add a second small default implementation that returns a copy of the newest worldStateBroadcastBytes. - Default first behavior: bytesFromTomcat is accepted or ignored as appropriate; bytesBackToTomcat is the newest worldStateBroadcastBytes. - Keep only the newest worldStateBroadcastBytes. Never queue obsolete broadcasts. - Every client request therefore receives the newest state the server browser currently wants everyone to see. - Later the callback can decode controls, edits, acknowledgements, and state requests without changing the JSP. - Include a monotonically increasing broadcast sequence number inside the Jsonzip message. - A client detecting a skipped sequence can request a full state. - Send one canonical initial full state, then prefer small live-state broadcasts containing changed p/v/t and player-control state. - Periodically send a full refresh so a missed delta cannot corrupt a room forever. - Always exclude .big from live state broadcasts. PHASE 7: PROOF-OF-WORK NONCE TO SLOW UPLOAD SPAMMERS - Require proof of work before the JSP queues any uploaded binary body. - Tomcat generates an unpredictable challenge using Java SecureRandom. - Bind each challenge to protocol version, room, client ID, operation, exact expected upload length, issue time, expiration time, and difficulty. - The uploaded Jsonzip message also carries the challenge string so the server browser can verify it after decoding. - Request metadata carries the challenge ID and changing proof nonce so the JSP can verify proof without decoding Jsonzip. - Define the proof hash over a fixed domain/version string, exact challenge, room, client ID, operation, exact body length, SHA-256 of the exact uploaded bytes, and submitted nonce. - Require the first n bits of that final SHA-256 hash to be zero. - This makes a proof specific to one fresh challenge and one exact upload, preventing useful precomputation or reuse. - Consume a challenge atomically after one accepted upload. - Reject reused, expired, unknown, wrong-room, wrong-client, wrong-operation, wrong-length, and wrong-body challenges. - Hash the body incrementally while enforcing its byte limit. - Verify proof before queueing, forwarding, decompressing, or asking the server browser to process the body. - Rate-limit challenge creation before allocating challenge state. - Bound and expire outstanding challenges so challenge requests cannot become a memory attack. - Apply proof to client send and serverReply by default, with separate configurable switches. Proof-of-work options: - Put editable defaults under BS.opt.server: BS.opt.server.powExpectedHashAttemptsPerKiB BS.opt.server.powMinLeadingZeroBits BS.opt.server.powMaxLeadingZeroBits BS.opt.server.powChallengeBytes BS.opt.server.powChallengeTtlMillis BS.opt.server.powMaxOutstandingChallenges BS.opt.server.powRequiredForClientSend BS.opt.server.powRequiredForServerReply - Initial requested target is one billion expected SHA-256 attempts per KiB uploaded. - This is informally called 1 gigaflop per KiB, but SHA-256 uses integer/hash operations rather than literal floating-point operations. - Derive difficulty approximately as: n = ceil(log2(powExpectedHashAttemptsPerKiB * ceil(uploadBytes/1024))) - Thirty leading zero bits average about 1.07 billion SHA-256 attempts. - The JSP's configured requirement is authoritative. Never trust a client-supplied lower difficulty. - Copy bounded BS.opt.server deployment values into constants when producing index.jsp, and optionally permit explicit Tomcat system-property overrides. - Return the exact proof preimage format and n with each challenge. - Do not block graphics or physics while solving. Work in bounded yielding batches or through carefully budgeted Bellsack/Lamgl computation. - Benchmark real solving time before enabling the billion-attempt target for frequent gameplay packets. - Permit much lower work for frequent tiny game-control packets and higher work for large uploads if measurements require it. - Never reuse a completed proof, and retain unfinished work only for the current exact body and unexpired challenge. PHASE 8: STRICTLY VALIDATE REMOTE JSON AND VAR MAPS IN BROWSERS - The JSP is opaque, so both the elected server browser and receiving clients enforce application validation. - Decode Jsonzip under strict byte, expansion, depth, string, shape, container, and output limits. - Clone accepted network maps into null-prototype objects. - Reject __proto__, prototype, and constructor everywhere. - Reject big, tNet, ob, obs, cache, up, pu, listeners, dirtNext, tempNext, and unknown lowercase fields. - Permit only explicitly supported scalar Var fields such as p, v, t, gp, pr, ps, and cv. - Require every numeric field to be finite and within configured magnitude and timestamp bounds. - Validate every child name with existing Varjs name/path rules. - Bound total nodes, child count, path length, depth, and decoded characters. - Centralize the server-browser write policy in one function so later rules can restrict which player may modify which Vars. - Never call Load() for network data. - Use V.loadMap(cleanMap,{keepNewest:true,isAutoEval:false}). - Invalidate allBallsCache and other child-list caches after remote Vars are first created. - A valid proof of work does not make content trusted; it only makes spam more expensive. - A valid hash proves content identity, not safety. - A malicious elected server browser remains an acknowledged limitation of this first prototype. PHASE 9: STATIC CONTENT-ADDRESSED /big/ FILES - /Bellsack/big/Sak$HashName is served by Tomcat as an ordinary static file. - /big/ bytes do not travel through the relay JSP. - The relay JSP never uploads, stores, parses, executes, or returns .big content. - Build the URL with URL and encodeURIComponent APIs, never raw concatenation. - Fetch the exact raw content and SHA-256 its exact UTF-8 bytes. - Convert the expected first 252 hash bits to Bellsack's existing 42-character dvBase64 suffix. - Require the complete computed name to equal the requested Var name before assigning vr.big. - Deduplicate simultaneous fetches for the same name. - Serve immutable content with long cache lifetime, ETag equal to the Var name, text/plain charset=utf-8, and nosniff. - For the immediate multiplayer release, ship built-in required .big content with the HTML/static deployment and do not block room sync on a new upload system. - If browsers later need to publish new /big/ files, make that a separate hash-verifying immutable file-publication path, not part of the relay JSP. - Unknown remote Sak remains data unless locally approved. - Only validated sandboxed Apjs species may eventually be accepted automatically. PHASE 10: NETWORK BOOT, TIMING, BANDWIDTH, AND STATUS - Rendering stays at normal requestAnimationFrame speed. - Networking uses an independent completion-driven loop with one request at a time. - Start conservatively and measure before choosing 10 Hz. - On failure, back off toward two seconds; on success, return toward configured network delay. - Use bounded request timeouts and discard obsolete work. - Never queue old world broadcasts while a request is in flight. - Initial full state may be large; recurring worldStateBroadcastBytes must exclude static .big and preferably include only live/changed state. - For a 40 Mbit/s home upload and twenty clients, target comfortably below the full link. - At 10 Hz and twenty clients, average response size must be around tens of kilobytes, not hundreds of kilobytes. - If too large, first reduce update Hz, broadcast only live fields, and add acknowledgements/deltas before increasing server requirements. - Display room, player ID, server/client role, connection state, network Hz, sequence, RTT, request bytes, response bytes, Jsonzip times, proof time, queue status, and in-flight count. - Use textContent for URL-derived, server-derived, or remote status values. - Keep verbose body logging disabled. PHASE 11: MAKE THE EXISTING GAME FUN WITH MULTIPLE PLAYERS FIRST - Use the existing lamglLoopBodyB graphics and physics rather than waiting for new terrain species. - The elected server browser runs authoritative ball and terrain physics. - Clients send control/input state and render server snapshots with interpolation. - Give every player a separate q.User.Player$... subtree so cameras do not fight. - Assign each player a controllable ball, team, cursor, or shooting action using existing controls with the smallest change possible. - Keep the existing 320 balls, terrain bounce, ball-ball bounce, recovery, gravity, and graphics options working. - Make joining visible so players can tell which balls/users are remote. - Do not let network latency pause local camera movement, UI, rendering, or audio. - Prefer a simple playable shared room over a large protocol redesign. - Record observed cheating/trust limitations honestly instead of delaying the first open test. PHASE 12: TEST IN THIS ORDER 1. Jsonzip unit tests and a real Bellsack state round-trip. 2. Save/open a local .jsonzip file. 3. Download embedded index.jsp and inspect exact bytes. 4. Deploy HTML, index.jsp, and static /big/ files under Tomcat webapps/Bellsack. 5. One browser joins an empty Room1 and becomes server. 6. Reload it and verify the room does not regenerate. 7. Two tabs get different Player$ identities. 8. Second browser sends bytes; server browser receives them and returns newest worldStateBroadcastBytes. 9. Move/shoot/control something and see it update in both browsers. 10. Join Room55 and verify isolation. 11. Close the server browser and verify bounded lease expiry and failover. 12. Reject malformed routing, oversized bodies, bad Jsonzip, bad Var maps, bad proof, expired proof, reused challenge, and wrong-body proof. 13. Disconnect and reconnect without stopping rendering. 14. Run twenty lightweight clients and confirm at most one in-flight send per client. 15. Measure average and p95 RTT, bytes/sec, proof time, encode/decode time, queue depth, rejected requests, Tomcat heap, browser FPS, and server-browser load. 16. Run long enough to observe room cleanup, challenge cleanup, pending-request cleanup, and server-browser failover. PHASE 13: AFTER MULTIPLAYER WORKS, FINISH THE LEVEL EDITOR AND MULTI-SPECIES - Restore/finish a Species metadata object for both Sak and Apjs. - Use content-addressed species code under paths shaped like: q.O2$cw.Sak$SpeciesHash.Sak$InstanceHash.X.p q.O2$cw.Sak$SpeciesHash.Sak$InstanceHash.Y.p q.O2$cw.Sak$SpeciesHash.Sak$InstanceHash.Z.p - The first Sak child identifies one unique GPU species/code and memory layout. - The second Sak child identifies one wave/instance of that species. - Instance child Vars contain X, Y, Z, R, W and species-specific fields. - Clicking a Ring/RingResult selects its Var, puts vr.nath() in CODE, and puts its Sak/Apjs source in the large editor textarea. - Compile selected species into Zoo without replacing the last working Zoo until validation and compilation succeed. - Generate densityAtXYZ_species(vec3 xyz,int ptr), where ptr addresses that wave's packed fields in Vec. - Pack variable counts of multiple species into shared shader textures and shards without recompiling just because wave counts changed. - Start with Bell5, ChuaBell, and Mandelbulb, then torus and pinball-paddle/bumper shapes. - Sum nearby species densities into the terrain used by both graphics and physics. - Preserve q.O2$cw species dedup so many instances share one compiled species body. - Add GhostMask/editor preview behavior only after basic mixed-species graphics and physics work. Apjs malicious-input sandbox and budgets: - Apjs must statically count or tightly bound FLOPs, memory slots, texture reads, loop iterations, generated GLSL length, parameters, and output size before execution. - Reject unknown operations, recursion, unbounded loops, dynamic code generation, invalid memory access, excessive dimensions, excessive shader text, and anything outside the allowed Apjs subset. - Never turn uploaded Apjs into unrestricted JavaScript eval. - Enforce budgets in the elected server browser and independently in every receiving browser. - Put editable limits under BS.opt.server and local client safety options. - Limit species uploads per player per minute, total active species per room, compiled species per shard, compile queue length, and total memory/FLOPs per frame. - Deduplicate uploads by content hash so identical species compile once. - Compile player species off the active gameplay path, one bounded job at a time. - Keep the last successfully compiled Zoo active when uploaded code is rejected, missing, too expensive, or fails shader compilation. - A player may upload a new sandboxed Apjs species only occasionally and only if the room and local client budgets allow it. - Do not let many uploads, repeated recompiles, or pathological but valid shaders freeze the twenty-player game. - Once these limits work, let players create, upload, select, edit, and combine safe new species while the multiplayer game continues running. 2026-8-20-10aET[[ ok. the balls are bouncing correctly and its finding points on surface correctly. when i check IsAllowPhysicsMove checkbox. I want you to default that checkbox to checked. next bug: terrain isnt moving. its supposed to be impulse bounce like in lamglLoopBodyA (but in B). Just do the same impulse bounce, in random order of shards, and within each shard, in random order of balls that are colliding with terrain. U gotta get the signedDistances from bellsackShaderMode_signedDistancePerturbSample. Each ball will have numTerrainVarsInThatGroup floats. every one of them is a signedDistance. theres also a signedDistance for if you perturb ball.X ball.Y ball.Z but gpu doesnt compute those. gpu only computes it for terrain parts. CPU has been doing those ball parts, and i think u already have it doing that, based only on that i saw them bouncing on terrain. Tell me how ur gonna do this. Cuz theres a few ways to do it. The simplest is to copy the whole tensor to cpu, even tho it has padding cuz some groups are bigger than others ]] * Finish the upgrade to sparse physics for bigger parts of world simulated nearby at once. * upgrade to multi-species, each being a float[n]=>float function that you get 2 copies of, one that runs on GPU and one that runs on CPU, such as 3d bellcurves we already have, mandelbulb fractals, torus, tetrahedron, sums of sine waves, and other high dimensional shapes. Each ring (with lines outward to join to other rings) has a species. Its how you make different game content. * level editor for player created content, the ring shaped toolbars with lines between them and text box at bottom left to edit custom GPU code live. * make single player world thats fun to play. * Expand to 20 players on one server, the small kind of server most ppl can easily run. * Learn from how 20 ppl play together, to make bigger worlds and upgrade to a 500 player server. * Bellsack goes viral. Anyone can run their own server, copy/paste many-dimensional shapes (that reshapes based on ball weights and g_forces) between servers. Potentially millions of players, but rarely more than 500 players per game server. * AI research using some of the compute power ppl donate using a checkbox in the Bellsack options to operate my Lamgl GPU software. Anyone can give their compute power to anyone else thru the Internet, during a time the box is checked. Doing so will make the game more fun cuz it helps me build AIs for the game and other research. We might reach 1 exaflop/sec total compute power in 100k simultaneous computers, I dont know, its possible. Quote Bellsack Intelligence Lambda Rick 🏴‍☠️/acc @benrayfield · 31m Releasing Bellsack 575.08 (opensource/Apache2) 1.25mB html file. This is a proof-of-concept of both sharded graphics and sharded physics, but the physics is still too slow cuz of using too much CPU. The old version did both fast but wasnt sharded/sparse. https://github.com/benrayfield/jsutils/blob/master/src/bellsack/Bellsack0575.08_proofOfConceptOfShardedGraphics(fast)AndShardedPhysics(slow)In(lamglLoopBodyB)TheSlowPartIsPhysicsIsDoingTooMuchCPUTodoFix.html lamglLoopBodyB physics staged plan, do not do all at once: 1. Add B constants + select nearest 96 balls as NEAR_BALLS_TOTAL_LAMGLLOOPBODYB. 2. Cluster those balls into N groups of 32 by fast Morton/Z-order chunking, where N = NEAR_BALLS_TOTAL_LAMGLLOOPBODYB/32. 3. Build one terrain shard per ball group from the group bounding sphere/region. 4. Add B multiprobe nearestSurfaceSearch pass: shape [ballGroups*multiprobe_vec3Offsets.length,32,4]. 5. Add B merge-multiprobe shader: output [ballGroups,32,4] ballCacheVec4, one nearest isosurface point per ball. 6. Add B signedDistancePerturbSample mode only after ballCacheVec4 is verified. 7. Add CPU readback + bounce/update last, reusing the known lamglLoopBodyA signed-distance/impulse logic where possible. Reason: doing all B physics at once risks breaking graphics B and old A physics; prove SIMD grouping and terrain shard lookup first. TODO lamglLoopBodyB graphics upsample/remarch: - Keep main raytrace at 256x192. Add upsampleShift uniform: 0=same size, 1=2x2, 2=4x4, etc. - Reuse the 4 coarse pass tensors from the 1/4/16/64 shard passes as inputs to the upsample shader. - Also build/use one concatenated 85-row shardTex so global shardId works with shard pointer offset 0. - For each high-res pixel, map to its coarse neighborhood, decode each candidate hit's shardId and two uint6 normal angles. - Pick one candidate shard by ray-plane prediction from nearby hit XYZ + decoded normal, using nearest positive predicted depth as tie-breaker. - Load only that one shard, start slightly behind predicted/coarse hit, and short-remarch forward for final accuracy. - If the short remarch misses, fall back to the chosen coarse hit. With only 1 sample from 1 shard this cannot be correct at all edges, but should improve smooth surfaces and many low-res edges. we will make it multij species soon for(int i=0; i<LoopSize[1]; i++){ density += densityAtPtr_bell5(SpeciesStart[1] + i*${GRAPHICS_RAYMARCH_BELL5_RECORD_FLOATS}); } for now, fix why its so slow in packGraphicsRaymarchShardTexture which is in CPU. Bellsack is so fucking fast after sharding the graphics, the longest any GPU call took was 330 microseconds. Thats 3000 FPS if not for the slower CPU parts. I gotta speed up this packGraphicsRaymarchShardTexture call which generates GPU code. see Bellsack0575_2026-8-3-136pET_packGraphicsRaymarchShardTexture_isTakingMostOfTheSpeedAndItsInCPU.html and the 2 pics of similar name. TODO lamglLoopBodyB Zoo.toGlsl(m={}) experiment design: - Change Zoo.toGlsl() to Zoo.toGlsl(m={}) using destructured defaults inside the function, but keep m object available for extra experiment keys. - m defaults: isAlwaysLoadMaxShardSizeFromTensor=true isLoopSizesGoInUniformElseTensor=false isLoadShardVecFromUniformElseTensor=false maxShardVecSize=904 isAlways1Shard=true isVariableNumberOfShards=false isReloadShardOnEveryDensityCall=false isGenerateFromAndToInputs=false isGenerateShardIds=false isUseShardIdFromFirstGPUThreadInShardToHelpSimd=false isAllowBreakOutOfLoopWhichCouldInterfereWithSimd=true - Naming: Tsor means Lamgl.Tensor/sampler2D, Unar means uniform array, Arr means abstract array. Use names shardArr, loopSizesArr, fromArr, toArr, with comments saying Tsor or Unar. Do not use Store/Src/Ar/Unifarr. - Generate specialized GLSL per m option; changing m changes shader string and Lamgl cache key. Do not add generic readShardArr/readFromArr abstraction funcs unless needed. - LoopSize is private int array when loaded from Tsor header, or copied from loopSizesArr Unar. Vec is always private float Vec[maxShardVecSize] so perturbing always mutates Vec, whether source is Tsor or Unar. - getShardId_if_isGenerateShardIds(ivec3 xyd): xyd.xy is logical output texel coord, xyd.z is outer loop index/depth pass. If graphics 1/4/16/64 shards, z=0..3 and shardId comes from quadtree-like screen tile. If one shard, z=0. - For graphics generated shard IDs: use grid sizes 1,2,4,8 and shard bases 0,1,5,21. Width must be multiple of 256 and height multiple of 8. Current start resolution 512x384. - isUseShardIdFromFirstGPUThreadInShardToHelpSimd means generate shardId from first pixel/tile coordinate for the shard where useful, to keep SIMD groups coherent. - getFromTo(ivec2 xy, int d) returns 2 vec4s. If isGenerateFromAndToInputs, graphics uses cam uniforms to generate ray start/current state. Else read fromArr/toArr. Mode itself stays a small uniform, never a tensor. - Do not special-case balls in Zoo.toGlsl. Balls are represented through from/to work items. Current graphics ball drawing can remain temporarily in wrapper shader, but move it out later. - Support 4 modes in one multimode shader: nearestSurfaceSearch, signedDistancePerturbSample, raytraceDisplay, densityAtXYZI. Leave bellsackShaderMode_iso_iso_physics_by_secondHighest_todoRenameThis as TODO. - For graphics sparse raymarch, try one Lamgl call with outer fixed loop d=0..3 over 1/4/16/64 shard levels. Each pixel reads up to 4 shard rows and keeps best/nearest hit. - If isAllowBreakOutOfLoopWhichCouldInterfereWithSimd=false, do full fixed loop count and mask inactive work after closeEnuf/found instead of break, to test SIMD coherence. lamglLoopBodyB graphics: double loop. outer loop is size 4. we will need a way to compute the shard as each gpu thread will read from 4 shards Let's do bigger redesign. Move on to lamglLoopBodyB and replace its entire contents. There's a checkbox to do loop b vs a. See todos text area about the modes shader. We are doing the 3 mode shader. It specializes in densityAtXYZ. vec4(x,y,z,varIndexToPerturbByEpsilon)=>float. It calls that vec4=>float func in 1 of 3 kinds of loops depending on mode. Let's make vec4(x,y,z,shardId*4096+varIdToPerturbInThatShard) and have it auto load from tex if shard differs from last calls shard. Instead of signed distances I want the nearest point on isosurface. So return xyz instead of sd. In each of 3 modes u take 2 vec4s as input. And give 1 as output. Makeballcache takes ballcenter and lastsearchpoint. Returns another searchpoint. At end the search point is on surface Make signed distances... Same but much fewer steps. In both cases it uses perturbed. Remember that goes in vec4.w. Raytrace takes campos and searchpoint. In all 3, the first vec4 has .w of shard*4096+varIdToPerturbInThatShard. And second point is x y z sortval. We will use the nearest n species and waves of them. Only do 1 zoo per cycle. Try to scale up to 2000 bell5s and 5000 balls, or something like that, with sparsity, and then go multispecies: ... [simdWorkTex One texel per SIMD block: simdWorkTex[simdGroup] = vec4( groupId, localVarCode, aux0, aux1 )] Thats not really what I mean. The signedDistance jacobian thing only runs about 2 calls of densityAt* per gpu thread. It perturbs var by index. maybe theres 300 indexs. so it runs 32balls*300vars threads. ... lets redesign bellsack for alot more than 32 groups. lets go extremely sparse. The unit of work is 32 balls and whatever terrain is near them. Max 64 species. 64 bytes of loop sizes. 64 sizes 0..255. So maybe its 32 particular balls and 80 waves that happen to be of 37 species; 32 (or 32*17 or 32*2 for multiprobe) GPU threads load that. But basically it will do what its already doing, but much more sparse. We will organize balls into groups of 32 balls, in the existing texture/tensor that balls go in. We will save alot of compute power by only running ball-isosurface combos (in physics) that could possibly touch by their bounding spheres. Group of 32 balls, union that volume (and 4x their radius is balls bounding sphere cuz look outward past ball surface for nearest point on isosurface). Whatever waves (terrain parts) bounding spheres touch any of those balls bounding spheres, include it in that group. Thats 1 isolated lamgl subcall. If theres 1600 balls, thats 50 groups. for example. 50*32=1600. But a problem will come up, how to allocate a different number of threads (for the jacobian grid of signedDistances float[32balls][numVarsNearThoseBalls]. This is basically sparse compared to float[allBalls][allVars]. We dont need variable number of threads for the raytrace and the findNearestPointOnIsosurfaceToBallCenter modes/shaders, but the 1 where we get jacobian of matrix of signedDistances, we do. So how do we make threads sparse like that? are you saying i can put loop counters inside a texture and dont need uniforms for it? how much slower will it run if i do that but only load the loop sizes once per gpu thread? ... Yes. You can put loop counters in a texture/tensor and use them as dynamic loop bounds. ... Safe pattern: ... int n = int(texelFetch(loopSizeTex,ivec2(index,0),0).x+.5); ... for(int k=0;k<n;k++){ ... } This might be unnecessary cuz can runtime choose loop size, store it in texture: I want to verify the core idea works, that we can use pointer_arithmetic of vertexId>>5 to jump into uniform ints to choose loop size, which is not the way we said but is the effect of it, but instead the way we said is to loop over possibleVertexIdDividedBy32 and check if that equals vertexIdDividedBy32 and only do the loop body (inside the IF) on the one that happens at. I want you to message codex (ill copy it there) so i can know for sure this whole thing is going to work. Also, tell me before i message codex, that if it works on win10pro in chromium browsers will it also in linux in chromium browsers. This is not meant to make progress toward coding this game engine. This is meant to test the core concept. make it as small and easy a test as you can but still gotta know if its being slow cuz of that. {{{{ TODO MultiShard/Zoo sparse terrain redesign summary: Goal: densityAtXYZ should scale by packing nearby waves into sparse terrain shards. A shard = 1 ConvexPolytope volume + all waves whose bounding sphere intersects that volume. Graphics and physics may use different shard shapes, but start with 1 shared live Zoo per cycle. Certain: - WebGL2 GLSL 300 ES only. - One Zoo = up to 64 species compiled together, ordered by varComparator/species path. - No hardcoded species in engine. Species GLSL/layout comes from Sak/q.O2$cw. - One Lamgl call processes up to N shards, default 32. - Use uniform uint loopSizes[512] = 32 shards * 64 species byte counts. - Use uniform int floatsPerWave[64]. - Packet data comes from CPU-packed texture/tensor rows. - ConvexPolytope = AND of Plane4 halfspaces. - Sphere/polytope test must be exact: distance(center, polytope) <= radius. - Physics assigns each ball/probe to one shard with inflated search radius. - Graphics can use frustum-tile shards with horizon/cap distance. Uncertain, test before big rewrite: - Does possibleShard control flow work fast? for possibleShard 0..N: if(possibleShard == (gl_VertexID >> simdGroupShift)) doShard(possibleShard) It may help SIMD/controlflow, or it may cause huge compile/runtime cost. - Compare against direct shard indexing: shard = gl_VertexID >> simdGroupShift doShard(shard) - Test packetRow local preload: vec4 packetRow[64/128/256]. It may win from reuse, or spill/compile slowly. - Fix/test Lamgl.isSkipCompute as pending_unvalidated -> validated_good/bad before relying on many live Zoos. Do first: 1. Test Uint32Array uniform upload and byte unpack from uint loopSizes[512]. 2. Add/test BoundSphere, Plane4, ConvexPolytope exact sphere intersection. 3. Test packet texture upload/read checksum. 4. Benchmark direct shard vs possibleShard-loop for N=1,8,16,32 and simdGroupShift=5/6. 5. Benchmark packetRow preload sizes 64,128,256 versus repeated texelFetch. 6. Benchmark fake generated species counts 1,2,4,8,16,32,64 with Lamgl.isSkipCompute. 7. Measure CPU pack + CPU->GPU upload for 1,8,16,32 shards. If tests pass: - Add classes: BoundSphere, Plane4, ConvexPolytope, WaveRef, TerrainShard, MultiShardCallPlan, MultiShardPlanner, MultiShardGpuPacker, MultiShardExecutor. - Extend Zoo so sfSourceMakerA(shaderName,zoo) generates density code for up to 64 species from Sak/q.O2$cw. - Hook lamglLoopBodyA nearWaves -> choose liveZoo -> build MultiShardCallPlan -> pack texture + loopSizes. - First milestone: one graphics MultiShardCallPlan, one shard containing all nearWaves, behind checkbox. - Then add graphics frustum tiles. - Then add physics ballcache shards. - Then add signed-distance perturb mode: copy packet to packetRow, perturb one local float, run density loops. - Keep old terrain path until graphics + ballcache + perturb pass small correctness tests. }}}} TODO Zoo timestamp meaning: Look up this quote in the Zoo class: this.tLast = 0; //0 means this Zoo has not been compiled/used yet. I want a loss optimizer designed to choose what combo of zoos to do. It must compile at most 1 more zoo per physics cycle, but it could be any of the powerset of possible zoos, of whatever species are nearby. Of the set of zoos used together (such as 6 of them), normally each species will be used only in 1 zoo, tho some might occur in multiple zoos if they are in the same ghost. One idea i had is to make each ghost have n bell5s, m bell13s, and o mandelbulbs. or o of whatever species this ghost is about. i want it to be more general than that to any set of waves can be in the same ghost. and theres likely to be alot of individual species that dont ghost in with anything else, each their own zoo. Basically I want a loss based optimizer to choose how to divide the species into zoos (can overlap), considering compile time as a loss, especially the length of a single compile time since many small compiles are ok but 1 big compile is worse or 3 mid size compiles are mid worse/better. and considering the chance of having to compile again soon. if you dont include nearby species that arent even simulated yet, then when you move in 3d you'll need a zoo for those, so it would often be better to include them in nearby zoo anyways. One possible strategy is to just pick whatevers nearby and to some distance outward, and zoo all those together, and use that until it doesnt have some species you need, then do the same thing again. thats not the fastest strategy (has longer compile times) but its a start. Lets use that one for now. then get multi species editor working. build game content with it. then explore multiple zoos at once, especially that the newest goes in a zoo by itself so to compile faster, but we would need to separate the "3 or 4 mode shader" away from the other glsl code which is another upgrade mentioned in the TODOS textarea. TODO test shader compile/load while moving in 3d: - Measure how fast new WebGL2 GLSL 300 ES shaders can be generated, compiled, linked, and swapped in as camera moves across areas needing different Zoos. - Test whether two browser windows/tabs can act like a double buffer: keep playing in one while the other loads/compiles next content taking about .1-1.5 seconds, then switch/stream state between them. - Remember this file is not secure_context; design around plain browser/file WebGL2 limits, not SharedArrayBuffer/WebGPU assumptions. TODO CPU paint helper: Add paintXYZRGB(floats,x,y,z,red,green,blue). Use only sparingly for debug sample cubes/points. red/green/blue are GLSL-style 0..1 floats. Convert to r5/g5/b5 by round(channel*31). Project xyz through current CPU-paint camera context. Skip if behind camera or offscreen. Compute d9 from forward distance using BS.opt.r5g5b5d9_dScale. Pack r5g5b5d9. Write by floats[i] = Math.min(floats[i], packed). Use 16777215 as far white horizon/background, not no-paint. Planned Ap.js opcodes/sugar: - `var`: scalar float parameter declaration. Intended sugar: `{A var}` means one float slot, roughly `{A locparMem (1)}`. - `diffeq`: lowercase replacement for `Diffeq`; accumulates derivatives/physics effects, e.g. `(diffeq (dposPtr X) dxdt)`. - `den`: density accumulation op, likely `(den poten$ density)` or similar if we keep explicit target. - `haunt`: density-to-ghost/odo accumulation op, for later `GhostInts` handling. Single-sum mode can skip this initially. Not opcodes, but related compiler/preparse features: - `Boil`: macro token / boilerplate expansion, not an opcode. - Reserved names: `Sx Sy Sz X Y Z R W`, only defined by Boil. - `poten$`: external float target name, not an opcode. I said to codex [tell me something to write at the top of the TODOS textarea, remember to keep it as summary but detailed enuf that i can come back here and do it. These changes we are planning, all the way up to seeing them on screen (whatever buildWorld makes, not the editor textarea thats for later). To start with, we need the Ape object (or at least ParseApe?) made for combining multiple species, of variable waves of each, lets say 3 species in this case: bell5, chuabell, and mandelbulb. combine that all into 1 ape automaticvally, but they should be 3 separate apes as code strings, 2 are already in buildWorld, add 1 more for bell5. and we gotta change code from using separate bellX bellY bellZ bellRadii bellStrengths arrays, and from using vec3 xyz (ok to keep using it in "float densityAtXYZ(in vec3 xyz)" but it goes in the shared par/loc float arrays as in locparMem, just the first n floats of it as there could also be locMem and parMem which go after that which Apjs already does so dont worry about locMem and parMem after those n. etc. write the todos for that.] TODO multi-species Ape combiner to display buildWorld terrain waves on screen: - Keep each species as its own Ap/Ape source string: Bell5ApCode, ChuaBellApCode, MandelbulbApCode. ChuaBell/Mandelbulb already exist in buildWorld; add Bell5ApCode as the third prototype species. - Build a Bellsack combiner that parses those separate species strings to ParseApe/Ape trees, expands Boil, lowers `{Name var}` to scalar locparMem-style params, and merges the 3 species into 1 generated Ape for one shader. - Reserved Boil vars are shared ABI names only: Sx Sy Sz X Y Z R W. They must not appear in any species-local arrays. Sx/Sy/Sz are one shared sample point. X/Y/Z/R/W are per-wave common fields for every species. - Species-local vars/arrays get per-species prefixes like S0_, S1_, S2_, including duplicate names such as DupArr. Shared Boil vars do not get species prefixes. - Support variable runtime wave counts per species without recompiling. Compile-time code knows species set/max slots/layout; runtime uniforms give active counts/offsets. Unused Vec/par slots are padding. - Replace the old separate GLSL uniforms/arrays `bellX`, `bellY`, `bellZ`, `bellRadii`, `bellStrengths` with one shared `par/loc` float Vec ABI used by VarGradientGL. The first floats include Sx/Sy/Sz and wave fields; later locMem/parMem behavior stays Ap.js’s job. - `densityAtXYZ(in vec3 xyz)` can stay as the public GLSL function, but it must write xyz into Sx/Sy/Sz slots before calling the combined Ape density code. - Generated density loop: for each active Bell5 wave, ChuaBell wave, and Mandelbulb wave, set/read the correct waveId/indexed X/Y/Z/R/W and species-local params, compute species density, then add `W * density` into `poten$`. - First target is only seeing buildWorld-made Bell5 + ChuaBell + Mandelbulb terrain on screen through the combined shader. Editor textarea/species editing integration comes later. The following paragraph is about making Ap.js compile really fast when the quantity of each species changes, in for example 10 species per shader of 0 or more instances of each, thru the int op or maybe a new udim op, which will require returning not just a code string (sf) but something like {sf: codeString, lamglParams: {WaveN: 30}} which will be added to Lamgl and VarGradientGL params. TODO shared Vec layout for variable species counts without recompile: - Do not allocate separate fixed ChuaMax/MandelMax arrays. All species data packs into one fixed-size shared par/loc Vec range, e.g. 900 floats total. - Runtime uniforms give active counts and offsets: ChuaN, MandelN, X_O, Y_O, Z_O, R_O, W_O, ChuaVars_O, Mandelbulb_O, etc. - Generated GLSL string must not depend on ChuaN/MandelN or current layout choices; changing counts/offsets only changes uniform params and packed par/loc floats. - Ap.js needs concepts like runtime uniform dimensions/counts and uniform offsets/views into the shared Vec, because normal locparMem currently allocates fixed compile-time regions. - Species code still stays separate source strings in buildWorld; Bellsack combiner lowers them into shared-Vec pointer math for densityAtXYZ. {{{{2026-7-17-1030aET estimate number of lines changed before i see those 3 species on screen and physics as they are generated into densityAtXYZ? 10:30 AM Rough estimate: 300–800 changed lines before Bell5 + ChuaBell + Mandelbulb are visibly/physically driven by generated densityAtXYZ. Breakdown: Bell5 Ap prototype: 20–50 lines. Bellsack Ap preprocessing: 80–180 lines.Expand Boil. Lower {A var}. Enforce reserved names. Prefix species-local names. Multi-species combiner: 120–300 lines.Parse 3 Ap codes. Build shared Vec/par layout. Generate loops per species. Keep runtime counts/offsets uniform-driven. Lamgl/VarGradientGL caller rewiring: 80–180 lines.Replace bellX/bellY/bellZ/bellRadii/bellStrengths arrays with one Var list / Vec ABI. Pack nearWaves into shared layout. Feed generated densityAtXYZ. Debug/validation/logging: 20–90 lines. Main risk: if Ap.js assumes fixed numeric locparMem sizes everywhere, the change trends toward 600–1000 lines. If we initially hardcode a 3-species combiner around existing Ap.js behavior and delay the fully general compiler, 300–500 lines is plausible. I would not try to do it in one diff. Minimum safe sequence is: Add Bell5ApCode + preprocessing tests. Generate combined GLSL string but don’t use it. Pack shared Vec/par from nearWaves. Swap densityAtXYZ to combined code. Verify graphics, then physics. }}}} Multi-species ChuaBell and Mandelbulb, with ChuaBell having ChuasCircuit in its x$ y$ z$ and 10 more vars the usual 5 weight x y z center stdDev, and 5 more for chua "constants" but put those in public class ChuasCircuit{ //https://github.com/benrayfield/HumanAiNetNeural/blob/master/mutable/chuascircuit/ChuasCircuit.java public double x, y, z, m0, m1, c1, c2, c3; public void nextState(double dt){ double dxOverDt = c1*(y-x-(m1*x+(m0-m1)/2*(Math.abs(x+1)-Math.abs(x-1)))); double dyOverDt = c2*(x-y+z); double dzOverDt = -c3*y; x += dxOverDt*dt; y += dyOverDt*dt; z += dzOverDt*dt; } } [[[something like this goes in q.O2$cw.Ap$... and buildWorld for the 2 demos to start with: Ap$(gpucpu (do {BellPar locparMem (4)} <{Cx float} [BellPar 0%4]> <{Cy float} [BellPar 1%4]> <{Cz float} [BellPar 2%4]> <{Cr float} [BellPar 3%4]> <{dx float} (- x$ Cx)> <{dy float} (- y$ Cy)> <{dz float} (- z$ Cz)> <{dist2 float} (+ (+ (* dx dx) (* dy dy)) (* dz dz))> <{r2 float} (* Cr Cr)> <{bellDensity float} (exp (/ (- dist2) (* 2 r2)))> (Diffeq potenCirc$ bellDensity) ) (do {ChuaVars locparMem (5)} <{c1 float} [ChuaVars 0%5]> <{c2 float} [ChuaVars 1%5]> <{c3 float} [ChuaVars 2%5]> <{m0 float} [ChuaVars 3%5]> <{m1 float} [ChuaVars 4%5]> <{fx float} (+ (* m1 Cx) (* (/ (- m0 m1) 2) (- (abs (+ Cx 1)) (abs (- Cx 1))) ) ) > <{dxdt float} (* c1 (- (- Cy Cx) fx))> <{dydt float} (* c2 (+ (- Cx Cy) Cz))> <{dzdt float} (- 0 (* c3 Cy))> (Diffeq (dposPtr BellPar 0%4) dxdt) (Diffeq (dposPtr BellPar 1%4) dydt) (Diffeq (dposPtr BellPar 2%4) dzdt) ) ) ]]] dont mod any of this code, but write code to add to the end of buildWorld function that creates ChuaBell's and creates Mandelbulbs. The code must go in q.O2$cw.Ap$codeofchuabellspecies and q.O2$cw.Ap$codeofmandelbulbspecies, and past those instances are created, instances such as let ball = Ball[newBallName()]; Make a 'Diffeq' op in Ap.js to replace '+=' and solve that problem of not multiplying by Self$ cuz (Diffeq (dposPtr ...) val) does dpos[...] += Self$*val; Make pushing the 2 analog triggers at once (proportional to whichever of them is pushed the least, take that as a third trigger) rotate the view gradually toward down on screen being down as balls fall toward, but not change the tilt up/doown, just the tilt left/right, so now we have kind of 6 axis of move/turn, cuz otherwise you will get tilted in the axis you lack and its hard to get it back. dont rewrite the whole plan. i want ap.js editor working first for a single species, that species being bell5vssquiggleetc for now. cuz ap.js hs never worked in bellsack and isnt even hooked into lamgl. its a code generator and never will be but i disconnected it from tinyglsl.js for this upgrade. then i want the level editor working. no edjoints. but multi species. i want to create 2 species and have them in the same ghostId "mainGhost" and roll balls on them. their pr ps springs will hold them stable even while not edjointing to eachother. then I want the new shaders to come in (graphicsSplit* and the 3-4 mode shader etc). then i want to verify the compile times are as low as you said, that we get down to 0.15 for single species. then add edjoints and ed editor, so we can make them share vars and do longer farther chains of logic/movement of terrain, ball hits it here, it ahas affects farther away, thru the ed lines you can see visually in 3d. then make game content, just a little, and play with it single player. then add whatevers missing in the level/species/playerCreatedContent editor. then make bigger game world thats fun for me to play. tune gameplay. then go multiplayer on 1 tomcat server. test from 2+ computers i have. test with ppl across the internet. TODO redTerrainBlueTerrainGreenTerrain4Co lorsOfBallsVeryStrategicAndFunDoThis2026-6-12+.txt <b>Change 17 to 2 or do ~17 cheaper searches then 1 expensive search from the best of those, optimization TODO.</b> FIXME found bug in Bellsack0540 when if i push plus-pad-up to save, then move, then hold plus-pad-down to load, it shows what was loaded, but when i release it moves back to where camera was or moves camera somewhere. so UI bug. and that might be why it seems not to load what was saved even tho its pretty close. Add to the TODO list to change from 20 densityAtXYZ calls per newton-iteration, to 10. The 20 is 4*(4+1). The +1 will be replaced by averaging 4 perturbed samples. Its 4 perturbs of 4 perturbs, so we have duplicates. 4x4 reduces to 4+3+2+1, 1 triangle side of a square matrix with diagonal. So 20 reduces to 10. TODO do the following without giving up summing alot of species, by using "float[g] += (g&1)*density" (search below...), TODO for 0.2 second species editing Compile and 0.4 second merge and 100 species on screen at once in 10 shaders of 10 species of varying quantity each, plus bell5 and bell13 go with all of them, but they are 3-species ghosts, as in Odo/Ghost/Wave. Sparse 4-mode terrain shadergroups: 1 new species edit = 1 small GLSL compile. funcId: findTerrain/get4Samples/cache/signedDist. Only shadergroups have densityAtXYZ. graphicsSplit* and physicsSplit* are fixed reused. Hard max ghosts; each ghost=sum waves. Cache programs by sv+sf, never by sh. Solo edited species first; merge later when idle. i choose not tod o dynamic code, simulated code, etc. lets do just the new shaders as written. but generalize to each wave has a SET of odoIds (which is simply a number per odoId or a string and maybe the SET of each is a regex or js func that returns true/false is it part of that one. The multi-mode shader (that another one is compiled for each variant of terrain code) will have 1 uniform int per wave. as in odo ghost wave. That int has 1 bit of membership in up to 32 ghostIds. 32 bit int. Each bell5 and each bell13 might be in ALL the ghostIds, or most, cuz you might want a FAST shader that does just a single ghostId so it compiles fast, but want 12 ghostIds in a shader with 12 species that are each their own ghost. or 10 ghostIds if they each have bell5s and bell13s but are otherwise separate. float[numGhostIds] is summed with each next float density computed. It loops for g from 0 to numGhostIds-1, g >>= 1; float[g] += (g&1)*density; So you do a sum of densities for EACH ghost but only compute each density once. ghost memberships can be varied at runtime without recompiling. So this can do any in the powerset of ghostIds per wave. and will be at most 2x slower, hopefully about 1x-1.1x slower. TODO later, Make the merging of float[numGhostIds], but as odoIds, compute secondHighest for future expansion into isosurface-isosurface physics, but highest/max is for ghosts and graphics. secondHighest is of the highest/max of all ghosts in each odo. secondHIghest of each odoId. .. but for now just do: wave.GhostMask$.p is 24 or maybe 32 bits for which ghosts this wave is a member of. local namespace, just use 2 for main terrrain, 1 (wave.ghostMask$||1 in case 0) for lone, 4 and higher mask bits for other. Auto make the newest species 1 or 0 but merge as 2. so compile delay is low (see predicted delay of 0.15 to 0.4 seconds, instead of the 1.2 saconds it is 2026-6-28 tho thats 3 more complex shaders and this is 1 simpler shader). Write out the densityAtVec func with the 5 species bell5 bell13 mandelbulb torus pinballPaddle. give me an example of the glsl code. and explain do i still get the 0.2 compile delay for single species ghost? 0.2 was for 3 species ghost. if i drop to single species ghost (not including bell5 or bell13 in it) do i get 0.1? 0.15? My issue is Im not willing to give up summing densities of many species at once cuz its something i want to make gameplay more fun, cuz it helps me keep shapes smoother. Also I want one of the bits in such ints (make it the lowest bit, 2**0) to mean each wave is its own ghost, do this one entirely by itself. So if theres 100 waves you can have up to 100 ghosts, but only up to 31 ghosts that can have more than 1 wave in each. We will do this by right after summing into the float[numGhosts], we update maxSoFar = max(maxSoFar, theFloatArray[0]), but wait until all waves are summed to do the maxxing for the rest of theFloatArray. what if a wave has 17 ghostIds that it will display for, but its the only wave in 2 of those ghostIds thats being displayerd this physics cycle? seems that would only need to be computed if the others were here with it. Lets go with, we dedup ghosts by the set of waves used nearby, so if theres the same set of waves in 2 ghosts, only keep 1 of those ghosts. It wont affect the output of densityAtVec. GPT wrote this 2026-7-3 (tho i might modify it here and not change this prefix saying so)[[[ TODO Sak/O2$cw/O1$cw/Ap.js level editor/data redesign 2026-7 Goal: Get Bellsack to fun single-player game-content creation before multiplayer. A player should click one Ring/RingResult, or multiple selected rings, edit one combined Sak$ text in the left/green editor, hit apply, and immediately see/roll balls on the updated terrain. Internally it may split into q.O2$cw species+instance Vars for GPU dedup and compile speed, but the editor should feel like one selected Sak object. Core storage paths: q.O2$cw.Sak$SpeciesHash.Sak$InstanceHash.p O2$cw means existence/weight is 2 child levels deeper. First child deeper is the GPU species Sak. Second child deeper is the wave/instance Sak. The second Sak .p is the density weight/existence of that terrain piece. q.O1$cw.Sak$CpuThingHash.p O1$cw means existence/weight is 1 child deeper. Use O1$cw for CPU-only wiring/rules/tools/glue where species and instance are the same Sak and no separate GPU species dedup is needed. Do not use "Kind: GpuWaveInstance" or similar. There is no Kind field needed. The presence/location of ap: code is enough to know what parts go to GPU/Ap and what parts stay CPU/Sak. Sak format for this phase: Sak$ is the general text format. Sak defaults to JS/Sak CPU meaning. Inside Sak, ap: is a special Ap.js/apdotjs block. ap: is lowercase. ap: contains the Ap.js code/layout that becomes GPU species code. Sak outside ap: contains instance metadata, CPU wiring, defaults, comments, GhostMask$, ej lines, and editor hints. Do not modify Var.js hashing. Do not modify Ap.js hashing. Use existing Var.pU/nameOrBig hashing by storing .big strings. O2$cw GPU species/instance split: q.O2$cw.Sak$SpeciesHash.big contains the ap: code and anything that changes generated GPU code or Ap memory layout. q.O2$cw.Sak$SpeciesHash.Sak$InstanceHash.big contains per-instance metadata: GhostMask$ ej lines optional locked/default fields optional p/v/am/cv/pr/ps/etc depending on editor mode comments/UI hints q.O2$cw.Sak$SpeciesHash.Sak$InstanceHash.p is the actual terrain-piece existence/weight. The editor may show one combined Sak text, but saving may split it: species part -> q.O2$cw.Sak$SpeciesHash instance part -> q.O2$cw.Sak$SpeciesHash.Sak$InstanceHash O1$cw CPU-only format: q.O1$cw.Sak$CpuThingHash.big may contain both CPU code and any metadata/defaults in one Sak. q.O1$cw.Sak$CpuThingHash.p is the existence/weight/enable value. Use this for CPU wiring between GPU calls, level editor helpers, edjoint tools, scripted setup, non-GPU rules, and things that do not need GPU species dedup. prev: prev: may exist only inside a Sak. prev of a Sak can only be another Sak. Do not prev: to Ap or any non-Sak thing. If a Sak has prev:, parse prev first, then this Sak. For now, repeated/bag fields accumulate from prev to child. Do not rely on prev for the O2 species link; the O2 path already gives species -> instance. GhostMask$ temporary design: Use GhostMask$ for now even though it is a temporary compromise. Default newest edited/unmerged thing to GhostMask$ 1 so it compiles fast as its own/lone edit ghost. Default normal merged terrain to GhostMask$ 2. GhostMask$ 2 means main terrain. GhostMask$ 1 means newest solo edited thing / own temporary ghost / own odo-like edit preview. When idle or user accepts merge, merge GhostMask$ 1 edit into GhostMask$ 2 main terrain. Higher bits 4,8,16,... are experimental shared ghosts. Do not solve unlimited ghosts/powerset yet. Do not block the editor on the better future ghost-membership design. Maybe keep GhostMask$ forever as a fast/cache/common case, but the source can later be generated dynamically by Sak. Ap array flattening into Var tree: For every Ap memory array such as: {SineArray locparMem (5) (12)} create flat Var children on the wave instance: SineArray0 ... SineArray59 Ban Ap array names ending in digits in editor-created Ap code, so SineArray17 always means flat index 17 of SineArray. Map Ap memory order to Var child order exactly. Display/edit those Vars with existing Var.fieldEditor grids. The flat Vars are where p/v/am/cv/pr/ps/ej/etc live. Edjoints are required before the single-player game can be fun: Implement minimum edjoint support before serious game-content creation. Instance Sak can contain repeated ej lines. For now ej is a bag by Ap flat-var order unless keyed ej is needed later. When projecting Ap arrays into Var children, assign positive integer Var.ej values from the instance Sak. Vars with the same positive ej act as one joined dimension for p/v/force/gradient purposes. This is needed so a ball hitting terrain here can affect farther-away terrain through visible ed lines/chains. Minimum edjoint behavior: Vars with same ej should share effective p/v or be projected/merged as one dimension for physics. Forces/gradients into joined Vars should combine consistently. No Var may be in more than one ej at once. ej null/0 means no edjoint. ej positive integer means joined group. Copy/duplicate terrain should either preserve ej ids or generate fresh ej ids depending on editor option. The editor must make it obvious which mode happened. Minimum edjoint editor: Show edjoint lines visually in 3d between joined selected Vars/rings/knobs. Allow selecting two or more Vars and assigning them the same new positive ej integer. Allow breaking an ej back to null. Allow editing/replacing an ej id. Allow duplicating a terrain piece with fresh ej ids. Allow duplicating a terrain piece while preserving ej ids. Do not overbuild this, but it must work enough to make long terrain logic chains. Basic level editor flow: Click one Ring/RingResult -> left editor shows combined Sak text for that selected instance/species. Click multiple rings of same species -> editor shows shared ap: code plus selected instance metadata if needed. Click multiple rings of different species -> either show multiple Sak sections or require picking one species first. Apply edit: 1. parse combined Sak 2. split species ap: part vs instance part if O2$cw 3. create/find q.O2$cw.Sak$SpeciesHash 4. create/find q.O2$cw.Sak$SpeciesHash.Sak$InstanceHash 5. preserve compatible old live p/v/am/cv/pr/ps/ej values where names still match 6. set selected instance .p nonzero 7. set GhostMask$ to 1 for newest edited thing 8. compile only the edited species first 9. merge into GhostMask$ 2 later when idle or when user accepts merge 10. leave previous working terrain active if compile fails Basic editor mode: Use the text editor for Sak/ap: code and metadata. Use existing Var.fieldEditor('p'), fieldEditor('v'), fieldEditor('cv'), fieldEditor('pr'), fieldEditor('ps'), etc for numeric live state. Show selected instance Vars in a 2d grid of sliders like Blob Monsters Game. Do not require user to edit JSON. Do not require user to understand q.O2$cw path internals. Show enough path/hash info for debugging but keep the normal UI human-editable. Advanced editor mode later: Checkbox: include live floats in Sak text. Checkbox: include only code/metadata, not live floats. Checkbox: save as O1$cw CPU thing. Checkbox: save as O2$cw GPU species+instance. Checkbox: duplicate with same ej. Checkbox: duplicate with fresh ej. Checkbox: put newest edit in GhostMask$ 1. Checkbox: merge selected edit into GhostMask$ 2. Ap.js/Lamgl hookup: Make Ap.js actually work in Bellsack with Lamgl. Start with one species only. Use bell5-vs-squiggle/etc as the first test species. Do not redesign Ap.js hashing/name system yet. Do not redesign Var.js. Hook Ap generated GLSL into existing Bellsack density path. Then move it into the new multi-mode shader path. Multi-species first milestone: Create 2 GPU species under q.O2$cw. Create at least 1 instance of each. Put both in main terrain by GhostMask$ 2. Roll balls on the summed density. Verify p/v/cv/pr/ps springs stabilize terrain even without every possible edjoint feature. Verify species dedup: many instances of same species use one species shader/code chunk. Then add edjoints so the gameplay becomes interesting/far-reaching. Multi-mode shader TODO: Replace compiling 3 terrain shaders per new species with compiling 1 multi_mode_shader per new/edited terrain code. One shader should support modes: mode 0: find nearest point / get4samples / cache setup mode 1: signed distance / ball cache support mode 2: raytrace graphics mode 3: debug/extra if needed Keep graphicsSplit* and physicsSplit* mostly fixed/reused. Only shadergroups contain densityAtXYZ/densityAtVec. Cache compiled programs by sv+sf, never by sh. Compile only 1 shader per newly edited terrain species instead of 3. Compile-time target: Single newly edited species in GhostMask$ 1 should compile in about 0.15-0.25 sec if possible. Merging edited species into main terrain GhostMask$ 2 may take about 0.3-0.5 sec and should happen when idle. Do not block editing on full merge. Keep newest edit solo first, merged later. Verify real compile times in Chrome and Firefox. Measure single species, 2 species, 3 species, and merged many-species cases. Density shader species set: First support bell5. Then bell13. Then mandelbulb. Then torus. Then pinballPaddle. Do not add more until these 5 can coexist in main terrain and compile/run acceptably. Need at least bell5 + one non-bell species working before calling level editor usable. GhostMask density rule for now: Each wave computes density once. Shader uses wave GhostMask$ int to decide which ghost accumulators get that density. Bit/value 1 means lone/newly edited ghost. Bit/value 2 means main terrain. Higher bits are experimental. For now output main terrain density by summing GhostMask$ 2 waves. Later maybe use max/secondHighest per Odo/Ghost for isosurface-isosurface physics. Do not let GhostMask$ design block single-player editor. Selection/UI visual TODO: Selected rings should show: species Sak/hash instance Sak/hash GhostMask$ instance .p weight array flat Vars edjoint ids/lines compile status whether it is solo edit ghost or merged main terrain Show current path q.O2$cw.Sak$Species.Sak$Instance somewhere for debugging. Do not force normal users to edit the path manually. Save/load TODO: Save enough Var tree to reload created content. Make sure q.O2$cw species nodes keep .big. Make sure q.O2$cw instance nodes keep .big. Save live p/v/am/cv/pr/ps/ej/GhostMask$ where needed. Save O1$cw CPU tools/rules used by the level. Do not save generated shader code unless needed for debugging. Temporary Var.toJSON/loadMap is acceptable for this phase. Later replace/share through cleaner Sak/Var streaming format. Safety/sanity before game content: Reject Ap array names ending in digits. Reject unknown memory types at first. Limit max par/loc floats per species. Limit max loops / oo loop sizes in Ap code. Limit shader text size. Show compile errors in the editor without destroying current working terrain. Keep previous compiled species active if new edit fails. Add a revert-to-last-working button. Add a disable-selected-instance checkbox/slider by setting .p = 0. Do not let bad player code lose WebGL context. Minimum fun single-player milestone before multiplayer: 1. Ap.js/apdotjs hooked to Lamgl for one species. 2. q.O2$cw species+instance storage working. 3. q.O1$cw CPU-only Sak storage working enough for helper/wiring code. 4. GhostMask$ 1 edit preview and GhostMask$ 2 main terrain working. 5. Multi-mode shader compiles one shader per edited species, not 3. 6. At least 2 GPU species summed in main terrain. 7. Edjoints working enough to join Vars and show/edit ed lines. 8. Var fieldEditor grid working for selected instance p/v/am/cv/pr/ps and array flat Vars. 9. Save/load preserves Sak big strings, live Vars, GhostMask$, and ej. 10. Balls roll/bounce on edited multi-species terrain. 11. Make one small fun single-player level. 12. Include at least one editable pinballPaddle or bumper-like terrain piece. 13. Include at least one torus or mandelbulb obstacle. 14. Include at least one edjoint chain where a hit in one place affects terrain farther away. 15. Tune gameplay until it is fun for me to play. 16. Only after that, start multiplayer/tomcat. ]]] Ok I added that. Now make me a TODO for a Sak that lists everything that exists within a certain sphere bound. It lists their var names such as 'q.O2$cw.Sak$Species.Sak$Instance'. This way we dont have to keep searching for, what if there could be more instances/species nearby. Sparse storage has that problem unless we add this, especially in networked ]]]]] TODO put all checkboxes<br> numboxes etc as someVar.fieldEditor('p')<br> and use new event system both directions.<br> Use it to tune Bellsack so the balls<br> bounce and roll right.<br> <h2><font color=#3388ff>Adding Sak like Sak.trySakEval('Sak$2+3') cuz gonna have lambdas in V/Var tree code stored in .big, and you call them thru .ob (todo put that in Proxy to fill in ob from .getOb(), like: const poten = ns.Odos$hashXYZ.ob(ns.Odos$hashXYZ.Lone.Lone.B509); where ns means room such as v.Bellsack.Room5 and TODO rename V to v cuz its a built in so shouldnt start with capital. And get this text etc off the canvas u cant grab knobs on the rings to adjust shapes thru it. or Sak.trySakEval('Sak$x=>(x*x+1)')(10) evals to 101 and if u call it again it reuses that same js compiled x=>(x*x+1). </font></h2> Bellsack183 has moving balls by VarGradientGL physics, not doing the more<br> detailed collisions yet, not tuned well yet, but at least its moving.<br> Bellack is now running on Lamgl, an javascript function that calls GPU statelessly with immutable tensors.<br> TODO implement <a href=https://github.com/benrayfield/jsutils/blob/master/src/bellsack/BellsackDesignDocument.txt>https://github.com/benrayfield/jsutils/blob/master/src/bellsack/BellsackDesignDocument.txt</a><br> Terrain is randomly generated. Reload it if you dont see the game world.<br> TODO cache gradientAtXYZ(cachedSurfaceXYZ) in second output texture in bellCacheVec4 step, to make it<br> about 2x maybe 4x or 5x faster cuz of fewer calls of densityAtXYZ(vec3). 2025-11-26[[ Its been live on the website for months u can try it. Its a weird math thing. I defined a scalar-field f that depends on another scalar field g. g(vec3)=>float. f(vec3)=>float. normal scalar field stuff. But heres the weird part, I use both g and gradient of g. For g I just use abs(g(vec3)) so its lowest where g(vec3) is 0. But for gradient of g, I compare it to a certain direction of gradient I want, that being isosurface shapes that if it were a curvy mirror would reflect back to the center of a ball if a light was shined from there. Surface is perpendicular to the direction to ball center. And I made a loss term for the cosine distance of those angles. This guarantees the global-minimum of loss occurs at every closest point on the isosurface, BUT it also allows other points on the isosurface to be global mins. that i dont want to find. so im optimizing some combos of code experimentally. Things are appearing in mid air in 3d in my game engine that shouldnt be there. but they are cuz a gradient can be 0 when density is nonzero. gradient of density. its a local min. My way of estimating the closest point on the curvy surface, to any given vec3 point, works enuf to get by, is practically useful, but gamers gonna say my game sucks if i have balls bouncing off invisible things in mid air aka localmins of the 3d density field. ]] <br><br> TODO In theory I can do wavefunction-wavefunction collisions, 2 reshaping blobs, viewing a 3d cross-section of each similar to Miegakure is a 3d cross-section of a 4d world, that could act like hardbody game physics objects or reshape by many dimensional torque/position/velocity. Lambda Rick 🏴‍☠️/acc @benrayfield 1m Signed-distance between 2 isosurfaces is minimum signedDistance (to the other isosurface) from each point in its volume. Bellsack does ball-wavefunction physics, an isosurface where wavefunction(position)=0. Computes signedDistance between 3d point and nearest point on isosurface. Use harmonySeach of sparse points to choose where to place the n balls to run normal physics. like how i did it in dagball (theres a checkbox for it that makes Circ/terrain bounce on Circ/terrain) but a different way of choosing where the balls jump around. <br> TODO bellsackHeavyBallsVsLightBalls TODO use this data format and put the spring pr ps cv accelMul (var fields that arent .p and .v) into the big: string lists, but start with upgrading the existing ball and bell5 to this incomplete but pretty close to what i want format. Also make sure to use my 64 base64 digits (which are ascending order in ascii and utf8 and are all valid in js var names) $0123456789ABCDEFGHIJKLMNOPQRSTUVWXYZ_abcdefghijklmnopqrstuvwxyz. so the ids will be Prefix$fortyThreeChars instead of Prefix$64chars, so ids will be 21 chars shorter. and make sure to only use \n to join .big, but can put a bigJoin: '' if u want the .big to not put \n joining them. TODO make some Var's have mutid like in Dagball so it automaticly holds .p as sums max to 1 of all those with the same mutid, like if you make a new version of it, its hash id (path part) is new, but same mutid in that .big "mutid: jacksBall". TODO get rid of readFields, and derive that. Keep join and Jo$'s. Do NOT parse complete javascript/sak/glsl in the "func:" just to be able to do const ghost = ns.Odos$hash.Lone.Lone; then to make a list of [ghost.Thing, ghost.OtherThing, etc]. Just write it out all the way [ns.Odos$hash.Lone.Lone.Thing, ns.Odos$hash.Lone.Lone.OtherThing, etc] despite that it takes more code size. It makes it easier to automate. And u only gotta send the code once per edit of the code, not when you move Cx Cy ManaRefillRate etc cuz those dont send .big again. ... TODO figure out how to do the 3d circle thats a constraint on a set of balls that at lowest poten stays on the circle, any circle at any 3d center and 3d rotation and radius within some range, that the lets say 7 balls have that 3d positional relation to eachother, cuz thats what the PotenNearPairs$ as computed by SPARSE gradient each physics cycle. How does it know what vars to do on sparse gradient? By parsing it for ns... vars, and the func returns float poten. Try 3 lists one for Cx one list for Cy one list for Cz and maybe another for Cr. ... Or maybe it is ok, not too much extra code, to do the "ghost = ns.Odos$hash.Lone.Lone" thing. Just add a little more parsing above Sak.tokenize(big.join('\n')). Gotta know which vars are read. Write diffeq only by make some func dv(theVar,addToDv) dp(...) kv(...) mnx(...) which will do it by Only refer to dag vars by ns.[stuff....] so its easy to parse. Very important: when u edit an Odos$... while certain PotenNearPairs$ are recursiveEditSelected, it will auto edit those PotenNearPairs$ too, to replace the Odos$... with its new hash so the game rules about pairs of things still apply to the code you just edited. It doesnt break the game world if your new code still works. Others who did not take those edits or have that selected still have the old version and both versions can work together in any combos. TODO also add .pr .ps springs into .big "spring: Cy ..." "spring: ManaRefillRate ..." etc but could also do it by making more Var instances for Pr Ps, like .ManaRefillRate.Pr.p .ManaRefillRate.Ps.p . { p:1,v:0, Bellsack:{ p:1,v:0, Room1:{ p:1,v:0, Odos$0658b7aa936e77579e2e183d6af4f27131a22c4aef0c11aad97422ae4bf714e8:{ p:1,v:0, big:[ "Odos$", "comment: Example Odos$ bell5", "readFields: Cx Cy Cz Cr", "join: Cz Jo$exampleJoinMandelbulbAndBell5", "func: (wv,X,Y,Z)=>{", " float dx = X.p - wv.Cx.p;", " float dy = Y.p - wv.Cy.p;", " float dz = Z.p - wv.Cz.p;", " float dist2 = dx*dx + dy*dy + dz*dz;", " return wv.p * exp(-dist2/(2.*wv.Cr.p*wv.Cr.p));", "}" ], Lone:{p:1,v:0, Lone:{p:1,v:0, B500:{p:1,v:0,Cx:{p:0},Cy:{p:0},Cz:{p:0},Cr:{p:0.6}}, B501:{p:1,v:0,Cx:{p:2},Cy:{p:1},Cz:{p:-1},Cr:{p:0.7}}, B502:{p:1,v:0,Cx:{p:-2},Cy:{p:3},Cz:{p:1},Cr:{p:0.5}} } }, Terrain:{p:1,v:0, Terrain:{p:1,v:0, T900:{p:1,v:0,Cx:{p:1},Cy:{p:-1},Cz:{p:0},Cr:{p:5.0}}, T901:{p:1,v:0,Cx:{p:-3},Cy:{p:2},Cz:{p:1},Cr:{p:4.0}} } } }, Odos$mandelbulb1234567890abcdef:{ p:1,v:0, big:[ "Odos$", "comment: Example Odos$ mandelbulb", "readFields: Cx Cy Cz Iter Scale", "join: this Jo$exampleJoinMandelbulbAndBell5", "func: (wv,X,Y,Z)=>{", " // Mandelbulb density approx placeholder", " float r = sqrt(X.p*X.p+Y.p*Y.p+Z.p*Z.p);", " return wv.p * cos(r*wv.Scale.p);", "}" ], Shared:{p:1,v:0, Wave1:{p:1,v:0,Cx:{p:1},Cy:{p:2},Cz:{p:3},Iter:{p:8},Scale:{p:1.2}}, Wave2:{p:1,v:0,Cx:{p:-1},Cy:{p:-2},Cz:{p:-3},Iter:{p:6},Scale:{p:0.8}}, Wave3:{p:1,v:0,Cx:{p:0},Cy:{p:1},Cz:{p:2},Iter:{p:7},Scale:{p:1.0}} } }, PotenNearPairs$ffe2185ff8a79b2d17d5f8507b63e7e4b8ed22b2219cea9b2478bf239ad4c95b:{ p:1,v:0, big:[ "PotenNearPairs$", "comment: Example PotenNearPairs$ gravity", "aOdos: Odos$0658b7aa936e77579e2e183d6af4f27131a22c4aef0c11aad97422ae4bf714e8", "aNonzeroFields: Cr", "aReadFields: X Y Z Cr", "bOdos: Odos$0658b7aa936e77579e2e183d6af4f27131a22c4aef0c11aad97422ae4bf714e8", "bNonzeroFields: Cr", "bReadFields: X Y Z Cr", "func: (a,b,Cc)=>{", " float dx=a.Cx.p-b.Cx.p;", " float dy=a.Cy.p-b.Cy.p;", " float dz=a.Cz.p-b.Cz.p;", " float dist2=dx*dx+dy*dy+dz*dz;", " float r=sqrt(dist2);", " if(r<Cc) r=Cc;", " return -(a.p*b.p)/r;", "}" ], Gravity01:{p:1,v:0,Cx:{p:0},Cy:{p:0},Cz:{p:0},Cr:{p:64},Cc:{p:0.5}}, Gravity02:{p:1,v:0,Cx:{p:1},Cy:{p:1},Cz:{p:1},Cr:{p:48},Cc:{p:0.8}} }, PotenOnes$b14bc8aed218e5ff4a6a3c5333219789a05906cd242dc1cf53c972cf22a38354:{ p:1,v:0, big:[ "PotenOnes$", "comment: Example PotenOnes$ centering", "odos: Odos$0658b7aa936e77579e2e183d6af4f27131a22c4aef0c11aad97422ae4bf714e8", "nonzeroFields: Cr", "readFields: X Y Z", "join: Cx Jo$GripA", "func: (g)=>{", " float r2=g.Cx.p*g.Cx.p+g.Cy.p*g.Cy.p+g.Cz.p*g.Cz.p;", " return 0.01*r2;", "}" ], Centering01:{p:1,v:0,Cx:{p:0},Cy:{p:0},Cz:{p:0},Cr:{p:64}}, Centering02:{p:1,v:0,Cx:{p:2},Cy:{p:0},Cz:{p:2},Cr:{p:64}} }, DiffeqOnes$9ae455f3e0d0c527b7fdfd892a1e080006de40a4bd0dc146e8904de1c65ca410:{ p:1,v:0, big:[ "DiffeqOnes$", "comment: Example DiffeqOnes$ decay", "odos: Odos$0658b7aa936e77579e2e183d6af4f27131a22c4aef0c11aad97422ae4bf714e8", "nonzeroFields: Cr", "readFields: Cr", "func: (g)=>{", " g.Cr.dV(-0.1*g.Cr.p);", "}" ], Decay01:{p:1,v:0,Cx:{p:0},Cy:{p:0},Cz:{p:0},Cr:{p:32}}, Decay02:{p:1,v:0,Cx:{p:1},Cy:{p:0},Cz:{p:1},Cr:{p:24}} }, DiffeqNearPairs$312f8d32ad5db671cebf00f194d587340a07dd2bc13fe7000d8bcfc28e8e1184:{ p:1,v:0, big:[ "DiffeqNearPairs$", "comment: Example DiffeqNearPairs$ repulsion", "aOdos: Odos$0658b7aa936e77579e2e183d6af4f27131a22c4aef0c11aad97422ae4bf714e8", "aReadFields: Cx Cy Cz", "bOdos: Odos$0658b7aa936e77579e2e183d6af4f27131a22c4aef0c11aad97422ae4bf714e8", "bReadFields: Cx Cy Cz", "func: (a,b)=>{", " float dx=a.Cx.p-b.Cx.p;", " float dy=a.Cy.p-b.Cy.p;", " float dz=a.Cz.p-b.Cz.p;", " float dist2=dx*dx+dy*dy+dz*dz;", " if(dist2<1.0){", " a.Cx.dP(0.1*dx);", " b.Cx.dP(-0.1*dx);", " } ", "}" ], Repulse01:{p:1,v:0,Cx:{p:0},Cy:{p:0},Cz:{p:0},Cr:{p:64},Cc:{p:1}}, Repulse02:{p:1,v:0,Cx:{p:2},Cy:{p:0},Cz:{p:2},Cr:{p:48},Cc:{p:1}} }, PotenGlobal$8a68212192db797a9e1eb25633abdc59a7eb5cbd0b02aa2e71c41160e91c5b7b:{ p:1,v:0, big:[ "PotenGlobal$", "comment: Example PotenGlobal$ constant", "func: ()=>{", " return 1.0;", "}" ], Global01:{p:1,v:0}, Global02:{p:1,v:0} }, User$a0806124028e1699222a37c8d46b5ed7ca4f2f931fa3dbcdcaf6eaa0fed9e665:{ p:1,v:0, big:[ "User$", "comment: Example User$", "pubkey: ed25519:abcdef123456" ], Profile:{p:1,v:0}, Inventory:{p:1,v:0} }, Jo$exampleJoinMandelbulbAndBell5:{p:1,v:0}, Jo$GripA:{p:1,v:0} } } } ---------- "PotenNearPairs$", "comment: Example PotenNearPairs$ gravity", "dag: a ns.Odos$0658b7aa936e77579e2e183d6af4f27131a22c4aef0c11aad97422ae4bf714e8", "dag: b ns.Odos$0658b7aa936e77579e2e183d6af4f27131a22c4aef0c11aad97422ae4bf714e8", "aOdos: a", "aNonzeroFields: Cr", "aReadFields: Cx Cy Cz Cr", "bOdos: b", "bNonzeroFields: Cr", "bReadFields: Cx Cy Cz Cr", "func: (a,b,Cc)=>{", " float dx=a.Cx.p-b.Cx.p;", " float dy=a.Cy.p-b.Cy.p;", " float dz=a.Cz.p-b.Cz.p;", " float dist2=dx*dx+dy*dy+dz*dz;", " float r=sqrt(dist2);", " if(r<Cc) r=Cc;", " return -(a.p*b.p)/r;", "}" TODO remove dag: and aReadFields: and bReadFields cuz all those can be derived. make it just what person would type in textarea editing this code. "aOdos: ns.Odos$0658b7aa936e77579e2e183d6af4f27131a22c4aef0c11aad97422ae4bf714e8", and if ur gonna use Var instances in the func, give the whole path starting with ns, even if its long, cuz i dont want to have to do detailed parsing. i can get the js tokens from Sak.tokenize(string) and check for ns . Thing . OtherThing etc "PotenNearPairs$", "comment: Example PotenNearPairs$ gravity", "aOdos: ns.Odos$0658b7aa936e77579e2e183d6af4f27131a22c4aef0c11aad97422ae4bf714e8", "aNonzeroFields: Cr", "bOdos: ns.Odos$0658b7aa936e77579e2e183d6af4f27131a22c4aef0c11aad97422ae4bf714e8", "bNonzeroFields: Cr", "func: (a,b,Cc)=>{", " float dx=a.Cx.p-b.Cx.p;", " float dy=a.Cy.p-b.Cy.p;", " float dz=a.Cz.p-b.Cz.p;", " float dist2=dx*dx+dy*dy+dz*dz;", " float r=sqrt(dist2);", " if(r<Cc) r=Cc;", " return -(a.p*b.p)/r;", "}" ok. so the rule is we only take paths that start with ns dot "ns." "ns ." etc. also "v." to go from root. and maybe will be a few others but ns. and v. are the main 2. after tokenizing and removing whitespace it will be 'ns','.','Something....' </div>