Simulating Jupiter (opens in new tab)

> performant

Huh. Opening this webpage on Firefox floored my laptop (8 core 16GB). The lag was several seconds, including for clicking "back" or opening a new tab.

The use of weird non-native scrolling really hurts navigation and full justification looks clumsy when screen is narrow. But otherwisr it's not terrible.

The article is incredibly interesting, but the choice of colors is so low-contrast that I can only read in it "reader mode", where the animations don't work. I have resorted to "select all" where the letters stand out a bit, but it's ugly and not very ergonomic...

> eminently readable on mobile

Sadly the font colour on non-mobile devices is way too dark, the whole site is way too low contrast: #666b67 (desktop) vs #B2B5B3 (mobile) on #222623.

Desktop colours: https://webaim.org/resources/contrastchecker/?fcolor=666B67&...

Mobile colours: https://webaim.org/resources/contrastchecker/?fcolor=B2B5B3&...

Fluid mechanics guy here. Let me first say this looks really nice overall!

The part that has probably highest potential for improvement is the sharpening, the artifacts there look a bit weird still.

Physically speaking, what you see on Jupiter (and on a river) is an interfacial flow. There is a divergence-free bulk flow underneath, but the interfacial flow itself has a lot of divergence. Upwellings have positive divergence and supply fresh stuff (colour!), downdrafts have negative divergence and consume stuff/colour.

But wait! You are using curl noise for your vector field! Of course the divergence is then zero everywhere!

If you take just the gradient of the scalar noise field you use for your curl noise, this will have lots of divergence and "compatible shape". Just scale this down a bit and mix with your curl noise.

And then finally take the value of your scalar noise field, scale it to be symmetric around zero, and use this to determine how much color to add/remove.

I think this will remove your need for sharpening entirely.

Disclaimer: this is just top-of-my-head while walking home.

Nice work. You briefly mentioned curl noise... About 10 years ago I wrote gaseous-giganticus[1] which uses curl noise to create gas-giant planet textures. They don't move, like yours, but don't look too bad (and looking at Jupiter, you can't really see that move over small time scales anyway.) Some animation is possible[2] with gaseous-giganticus, but not in real time, as it's all done on the CPU, and it doesn't really sustain over time, as it starts off looking very fuzzy, resolves into something pretty nice, then gets weird. Here is some more output from early days: https://imgur.com/a/9LipP

Here are some slides about the development of gaseous-giganticus (best viewed with a real computer, not on a phone, as it uses arrow keys to navigate the slides): http://smcameron.github.io/space-nerds-in-space/gaseous-giga...

[1] https://github.com/smcameron/gaseous-giganticus [2] https://imgur.com/mqCwMeI

UE translates shader graphs to HLSL - high level shading language, see:

https://dev.epicgames.com/community/learning/knowledge-base/...

Shadertoy needs GLSL - open gl shading language. Luckily, UE has a HLSL -> GLSL transpiler built in:

https://docs.unrealengine.com/4.27/en-US/ProgrammingAndScrip...

There are other HLSL transpilers: Microsoft's ShaderConductor, Unity's hlsl2glsl, Vulkan's vcc, etc.

To port your favorite Shadertoy examples back to UE, you can transpile GLSL to HLSL with ShaderTranspiler, glslcc, ShaderConductor, etc.

Disclaimer: I don't use UE or Shadertoy. In fact, this is my first exposure to GLSL/HLSL. My claims may be inaccurate.

Website acts as my portfolio - I'm a game developer, so that is why I use Unreal material graph. Shadertoy allows me to demonstrate ideas on live example that is animated and anybody can play with its code. For the most part HLSL(Unreal) can be translated to GLSL(Shadertoy), but that wasn't the case here. In Unreal I use my own custom flow textures, in Shadertoy it is not possible - everything has to be stored in code. Even though the basic idea behind Unreal and Shadertoy shaders was the same, the implementations were quite different. It was easier to just do everything twice, that to convert it. And yes - it took a lot of work :).

Looking at the final shadertoy example (https://www.shadertoy.com/view/4XSXz3) I would think he just recreated each effect in shadertoy (variable and function names dont seem exported to me).

Most of the effects on the page are only a couple of lines it seems so maybe he did just rewrite them all? I do wonder why he bothered with UE material graphs if he's this proficient at shaders anyway.