iiinova — where your digital self keeps evolving

Very few flames ever get hotter than than 3000K, except for momentarily during detonation explosions and beyond

010

Soot formation in a candle flame sit between 1300K and 1900K, peaking in the 1600-1700K range, which the reference temperature sits in the middle of But that specific temperature is chosen so that the luminance at 5772K exactly fits in fp16. The above is simply a coincidence that happens to match

100

Neither end points are practically useful, but they carry huge semantical meaning. The lower end is the faintest possible glow The upper end is the brightest object in the solar system

100

Morten Vassvik @vassvik.bsky.social · 09/04/2026

Perfect blackbody color gradient temperature range: [798K, 5772K] Perfect blackbody luminance reference temperature (to declare Y = 1): 1640.2347K

130

tfw an idea you've been theorizing for years actually works

180

Morten Vassvik @vassvik.bsky.social · 13/03/2026

aka. "How many bits can your display display", seems like 🫠🤣

011

So all these rather crazy things are against a backdrop of having a pretty good sparse backing grid. That moves the needle quite a bit

100

Needs to be sparse, no way a dense frustum grid scales :)

100

In practice I think you'll find that 2-3 pixels per froxel cone is actually on the edge of what going to be visually sufficient with good resampling and interpolation anyway, but I think it's largely inputs dependent still. The more important direction to sample well is the depth direction.

100

As a result you end up with tons of artifacts that require a lot of fairly brute force trickery to overcome, including dithering and temporal accululation My motivation with this approach is to try and approach this from the opposite direction – capture as much detail first, then simplify/constrain

100

Traditional frustum grid renderers set the lateral and depth resolution first as a parameter, e.g. 3x3 pixels per froxel cone and 256 depth slices between and near and a far plane. While this can result in predictable performance it bears no direct connection to the properties of the volume.

100

Whether this actually resolve any meaningful detail in return depends a lot on the properties of the volume itself. For traditional smooth fog it almost certainly doesn't add much, but for crisp explosions and thick smoke? Seems much more likely.

100

The construct is currently precisely about going for pixel-sized froxel cones. And although the near-field construct do oversample the *voxels* laterally it does not oversample the *pixels* since each pixel ray take a different path through the volumetric field.

100

This part is actually still WIP, so not fully implemented yet, to be clear.

000

It's almost certainly possible to generate equivalent responses or better to almost any prompt by heavily curating the context and prompts that's sent to a LLM that cost less than the cached setup that was used to generate these responses in the first place, which bear some similarities to the above

There's a flipside to the awesomeness of what LLMs can do these days, and that's the clear level of waste there is almost every level if you look closely. In particular the way prefix-cached accumulated contexts are typically used leave a lot to be desired, they're literally O(N^2) for N tokens.

120

Conventional uses of LLMs these days can pretty much do anything in an almost literal sense, which doesn't really come as a surprised given that the number of parameters are in the trillions by now on top of various clever techniques to make those parameters go even further.

100

There's a related aphorism typically attributed to Einstein > Everything should be made as simple as possible, but not simpler. which simultaneously combines Occam's razor and the concept of entropy - broadly implying that there is a kind of irreducible complexity (unfortunately a hijacked term)

The expression is used in physics to criticize physical models that are overfit, and that with enough parameters you can basically make a model do anything, which is largely self-defeating for explanatory purposes.

100

Von Neumann's elephant: > With four parameters I can fit an elephant, and with five I can make him wiggle his trunk. Extrapolate to 2026 and with 1 trillion parameters you can effectively answer any question in the world and solve almost any problem.

Another way to put it is that the camera frustum exactly spans 2160 voxels vertically at 60 degrees vertical field of view at a distance 1/(2*tan(60/2 deg)/2160) = 1870.61487 voxels away from the camera the camera, and equivalently 3840 voxels horizontally.

100

So d*(2*tan(fov/2)/N)) is the lateral pixel size at depth d, and setting this equal to the voxel size dx gives d = dx / (2*tan(fov/2)/N)) = dx / kappa. So n = 1 / kappa is geometrically the number of voxels up to the crossover point, and for

100

The lateral span of the frustum is 2*tan(fov/2) times the distance from the camera, and that span is evenly divided across the pixels in that direction, so the lateral span of each pixel is 2*tan(fov/2)/N times the distance for N pixels Call it the lateral pixel size as a function of distance/depth

100

You got it right. The near field slice count to the crossover point is independent of the voxel size, it's purely dependent of the camera parameters (number of pixels and field of view). More precisely: The near field slice depth (which is constant) *is* the voxel size, by definition.

100

Some editorializing expected

000

Direct link to the "results": github.com/vassvik/clau...

100

GitHub - vassvik/claude-thinking-experiment

So I was "talking" to it about that, and ended up doing a bunch of experiments (although small sample size per test, I only have so much time doing this manually!). I put the result here github.com/vassvik/clau...

github.com

Contribute to vassvik/claude-thinking-experiment development by creating an account on GitHub.

100

Claude Opus 4.6 made a big change in how the "thinking" is configured and controlled, and a lot of people are seeing it being really greedy with tokens across the board, some times filling the entire context (and making it impossible to use on a Pro sub) with very few prompts.

100

Some kind of cluster or block selection aroudn a certain region to seed a list of potential people to follow (as an extension to the your follower network analyzer) would be very useful

010

Theo Sanderson @theo.io · 08/02/2026

would be nice to be able to do a cluster or block select to easily enumerate people to follow

010

Reposted by Morten Vassvik

I made a map of 3.4 million Bluesky users - see if you can find yourself! bluesky-map.theo.io I've seen some similar projects, but IMO this seems to better capture some of the fine-grained detail

bluesky-map.theo.io

Bluesky Map

Interactive map of 3.4 million Bluesky users, visualised by their follower pattern.

66472492153

Morten Vassvik @vassvik.bsky.social · 03/02/2026

A colleague sent me this: www.youtube.com/watch?v=8jVo... No further comments needed, it's **very** good. I've seen some of his videos in the past, but I missed this one. Glad I saw it.

youtube.com

Pushing Simulation to the Limit to Find Order in Chaos

YouTube video by Drew's Campfire

12510

Morten Vassvik @vassvik.bsky.social · 01/02/2026

Working on documenting frustum grids, rebuilding it piece by piece with Claude based on an earlier version that unfortunately got mangled by overly aggressive self-review: gist.github.com/vassvik/1ed6... Still quite a bit missing, but getting there

1151

Reposted by Morten Vassvik

One example that I explored today: Spherically distorted Frustum Grids gist.github.com/vassvik/6a14... In the end it requires a bit of effort to get the documents sufficiently fully fleshed, but you can ask it to review itself, to various degrees of thoroughness, which works quite nicely.

051

051

What I have actually used it more for is where I deliberately ignore any real coding aspects and just explore some topic theoretically. I ask about concepts, and we go back and forth exploring the details and what comes of it, and sync with Github to read. Promising for documentation/specification.

Usually this leaves a big mess around once you're done, but that's usually fine as you can take the results and have it distill it into something else. In the end you might end up with a nice document describing the journey and results you got.

E.g. write a small program that does something narrowly scoped, especially where the code itself is just a means to an end where what I actually want to do is use that code to study something else, e.g. convergence properties of numerical solvers.

120