Bellsack

opensource/Apache2

SHOW: PLAY TOP RIGHT DOWN
LOGIN TOOL FILE OPTION
VarUI CODE TODOS

TODOS:

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 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
Change 17 to 2 or do ~17 cheaper searches then 1 expensive search from the best of those, optimization TODO.

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

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: pause

species editor

TOOL:

VarUI:

TODO put VarUI here

CODE:

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

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.

physics. Most of the options below are for lamglLoopBodyA which is the old code. The new code 2026-7 is lamglLoopBodyB which makes it sparse so you can have more stuff on screen and doing physics at once. But its too slow cuz its using too much CPU. Its fast enuf on GPU. Will fix it soon. Use this checkbox to change between the 2 modes A/B: lamglLoopBodyBElseA
IsDo1PixelReadsToSyncGpuCpuTimingForBrowserPerformanceTabDiv WARNING: makes it slower but makes GPU measurable in Performance tab
Do1AtEndOfLamglLoopBodyB_IsDo1PixelReadsToSyncGpuCpuTimingForBrowserPerformanceTabDiv WARNING: makes it slower but makes GPU measurable in Performance tab

B multimode skip experiments
IsSkipCompute_bellsackShaderMode_nearestSurfaceSearchDiv IsSkipInputTensors_bellsackShaderMode_nearestSurfaceSearchDiv
IsSkipCompute_bellsackShaderMode_signedDistancePerturbSampleDiv IsSkipInputTensors_bellsackShaderMode_signedDistancePerturbSampleDiv
IsSkipCompute_packPerturbedSignedDistancesDiv
IsSkipCopy_xyz_or_packedSignedDistancesDiv
IsSkipCompute_bellsackShaderMode_raytraceDisplayDiv IsSkipInputTensors_bellsackShaderMode_raytraceDisplayDiv
DoStepBallBallBounceDiv DoStepBallRecovDiv
IsDisplayGraphicsShardTextLabelsDiv
IsShowVoxelOfNearestPointOnIsosurfaceToEachBallDiv
IsAllowPhysicsMove_lamglLoopBodyBDiv
DoTerrainImpulsePhysicsElseOnlyBalls_causesGPUCopyToCPUOf_signedDistancePerturbSampleDiv
DoSpeedStats_lamglLoopBodyBDiv

lamglLoopBodyB staged physics auto CPU bounce/update repeat (if chkDoPhysics) lamglLoopBodyB_mainPhysics
todo multispecies
todo edjoints and level editor
===ALOT OF THE STUFF BELOW THIS APPLIES ONLY TO lamglLoopBodyA. lamglLoopBodyB is going to replace it but is experimental 2026-8-8+. See lamglLoopBodyBElseA checkbox.===

IsAllowAPIsThatRequireBrowserSecureContextDiv

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

IsAsyncCompileIfCan_lamglLoopBodyA_bell5Textarea_experimentDiv

IsAsyncCompileIfCan_lamglLoopBodyB_zooDiv

IsAsyncCompileIfCan_lamglLoopBodyB_otherThanZooDiv

IsLamglLoopBodyBMoveBallsDownByGravityHackDiv

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?

IsCpuToGpuRgbdTestDiv

IsCpuToGpuRgbdTest_ReuseLastTsorAsSpeedTestDiv

IsCpuToGpuRgbdTest_CpuFillFloatArrayOnly1stDiv

IsCpuPaintRings_ifLevelEditorDiv

IsCpuDisplayEdjoints_ejX_ejY_ejZDiv

IsRemoveGlslCommentsDiv

IsRemoveUnreachableGlslFuncsAndStructsDiv

sfSourceMakerAToolsDiv

Is_Lamgl_makeConstantsUniformsNoLoopUnroll_Div

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.

IsBallsGoInTensorElseGLUniformDiv

IsBalTerImpBouncByGpuSignDistThenCpuBo

IsBalTerImpBouncByGpuSignDistThenCpuBoRecov

IsDoBugFixFor_GroundSometimesAccelsOppositeDirectionB_Y2026M7D29ButLIkelyHasBeenBuggyForLongTime

(see IsBallBallRecovIfBounce farther below)

AlwaysCopyGraphicsToCPUJustToTestSpeed

EnableStrongRecoveryOnBalls

StartStrongRecovWhenBallPenetrTerMoreThan

SeeThruBackSideOfTerrain (FIXME not working 2026-5-20-709pET)
is2dFloorAtZ0

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

debugGraphicsOnBallThatUsesSignedDistancePerPixel
multiprobe_debugGraphicsOnBallThatUsesSignedDistancePerPixel

cheatTheOptimizationIn_nearestPointOnIsosurfaceFromXYZ_estimateUsingBallCache multiprobe_cheatTheOptimizationIn
physicsCacheNearestVec4PerBall_seeInsideAllNewtonIters physicsCacheNearestVec4PerBall_seeInsideAllNewtonIters_cheaperFasterUse1PerBallForBasicDisplayTest
instantMirrorBounceBalls (TODO "bellsack disable the other forces so can see instantMirrorBounceBalls checkbox alone, and get physics working.") ignoreOutputOf_VarGradientGL (normally used with instantMirrorBounceBalls to turn off other forces so u see just that bouncing)

IsBallBallRecovIfBounce (used with instantMirrorBounceBalls)

ignoreOutputOf_VarGradientGL_removeTheCallIfSo cpuBouncesBallsOnEachotherPartlyRandomly gravityYByCpu instantMirrorBounceBallAndTerrain (disabled cuz the terrain part of impulse/instantMirrorBounce was
not coded as of 2026-5-22 and then I decided to go back to non-impulse physics but instantMirrorBounceBalls works for balls) keepOldBugForTesting_signedDistanceToIsosurfaceAtXYZ_p_vs_p0

BackFaceTransparencyDiv

chkBallCacheOptimizationIgnoresBallBallCollisions 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).

graphicsDebugDiv

newtonIterationsDiv

SignedDistanceSpeedDiv

DensityOfSlightAttractToVec3_mul

DisplayErrsOnSurfInBrightGreenIfAbsMoreThanDiv

AddToDensityForTestingDiv

Display3dLocalMinsOfGradientMagLessThanDiv

MultiprobeSortDensityMul

testDisplayIsSparseXY continueTestDisplay testDisplayLogsBigTensor
chkSeparateRingsAsTexture only ball physics (2025-11-13 this checkbox has no effect if IsNewEventSystemY2025M11 is checked)
ballCacheOptimizationUsesFastGradientAlongLineElse4Samples
testIfFirstoutgetIsBottleneckByUsingEmptyFloatArrayInsteadOfReadingFromGpu
addExtraStepCopyingBallCacheFromTextureToCpuToGlUniform
nearestPointOnIsosurfaceFromXYZ_does_ gradientAtXYZ_including_densityOfSlightAttractToVec3 holdBallsOnIsosurface displayBallCacheVec3AsSecondBall whenFindingNearestPointOnIsosurfaceGraduallyIncreaseInfluenceOfNormalVector IsNewEventSystemY2025M11 findSurfaceByGradientsAlongRay holdABallInFrontOfCamera 2_api_free_emblem_b.jpg.dataurl

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<${opt.NEAR_BELL5_TOTAL}; i++){
	for(int i=0; i<uBellCount; ++i){
	//for(int i=0; i<$ 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*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.

;       opensource/<a href=https://www.apache.org/licenses/LICENSE-2.0>Apache2</a> 
(TODO ed25519 with separate opensource license?) 
 Like IPFS, not responsible for P2P user content.

TODO put all checkboxes 
numboxes etc as someVar.fieldEditor('p') 
and use new event system both directions. 
Use it to tune Bellsack so the balls 
bounce and roll right. 
						 
						 
						 
<h2>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).
	</h2>
	Bellsack183 has moving balls by VarGradientGL physics, not doing the more detailed collisions yet, not tuned well yet, but at least its moving. 
	Bellack is now running on Lamgl, an javascript function that calls GPU statelessly with immutable tensors. 
	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> 
	Terrain is randomly generated. Reload it if you dont see the game world. 
	TODO cache gradientAtXYZ(cachedSurfaceXYZ) in second output texture in bellCacheVec4 step, to make it 
	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.
	]]
	 
	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.
	 
	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>

🎮+🖱️