Morten Vassvik

16 Nov 2024

Never to late for an introduction post, eh Hi I'm Morten. I work at JangaFX, where I primarily work on EmberGen, but I occasionally work on our other tools as well. I hope to eventually start posting more fluid sim and graphics content, hopefully even blogposts and some code too.

Finally got this in a good spot without a big performance penalty: Removing sparse grid artifacts that comes from a bad/no tile initialization, without resorting to excess padding. Left to right: - Full tile dilation, init - Half dilation, init - Full dilation, no init - Half dilation, no init

272M, 213M, 281M, and 248M active voxels, respectively. Preserves momentum better too

20 Aug

Rational photometric blackbody radiation approximations: www.shadertoy.com/view/ffcSRl

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

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

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

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

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

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

3 Mar

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.

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.

3 Mar

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

3 Mar

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.

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.

10 Feb

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.

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

github.comGitHub - vassvik/claude-thinking-experimentContribute to vassvik/claude-thinking-experiment development by creating an account on GitHub.

10 Feb

Some editorializing expected

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

Morten Vassvik reposted

Theo Sanderson

@theo.io

8 Feb

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.ioBluesky MapInteractive map of 3.4 million Bluesky users, visualised by their follower pattern.

youtube.comPushing Simulation to the Limit to Find Order in ChaosYouTube video by Drew's Campfire

3 Feb

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.

1 Feb

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

Morten Vassvik reposted

30 Jan

Replying to @vassvik.bsky.social

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.

30 Jan

Spent about a week with Claude Code (Opus 4.5) now. Still sort of skeptical of any tangible benefits to its coding capabilities for any of the production work I do, but I have found some things that seem to work really nicely: Exploration, testing and analysis.

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.

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.

30 Jan

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.

Short conclusion of this Weekend project using Claude Code: It currently feels like it's going to be more like this for the majority of people for at least the nearest future, butchering the lovely graphic from @mjwhansen.com:

Morten Vassvik@vassvik.bsky.social

Played around a bit more with it today. Most of yesterday's wow factor is gone, and it's been almost a uniquely frustrating experience. Almost everything I tell it gets done wrong, and it keeps fumbling, and the lack of visual debugging is really frustrating

I've had several instances where it feels like it's doing a really good job at "reasoning" itself to something novel (that I didn't explicitly feed it), where I give it maybe 10-20% of the puzzle and then let it go, continually guiding it if goes off course, or if it asks clarification questions.

In the end even the exploratory has a lot of fumbles and noisy parts, and it suffers from being largely messy and overall less structured despite the apparent structure. If you're not competent enough to evaluate everything it spews out I can definitely see how there are net-negative gains even here

Morten Vassvik@vassvik.bsky.social

I've successfully made it produce a pretty good 2D stable fluids implementation after a lot of frustrating back and forth to fix and remove all the fuckups that I did when I gave it too much freedom initially. Once I was able to do things iteratively it was more efficient, but very frustrating.

On the other hand I have had very good results on the experimentation and theoretical side of things, especially when it comes to explaining and deriving things that I'm actually competent to verify.

Morten Vassvik@vassvik.bsky.social

In short the LLMs themselves are very good at making you feel like the yellow bar is smaller than it is, and I think almost everyone are going to neglect the QA bar and basically pretend it's smaller because it's basically impossible to vet the massive "throughput" with a reasonable amount of effort

24 Jan

Morten Vassvik@vassvik.bsky.social

Spent some time today finally trying Claude Code (Opus 4.5). Tried to task it to make a simple 2D Stable Fluids implementation from scratch, which it truly fumbled no matter what suggestions I made to improve it. There should be lots of examples in its training data, so that was a but disappointing

25 Jan

Damn, got some really interesting stuff out of this (which is basically just a rederivation and verification of an idea I had in the past, but didn't fully go through with).