Love a good graphics writeup - I've been working on similar things for my procedural space/planet generator. The cool thing with atmospheric scattering is you can combine it with volumetric cloud rendering and get amazing sunsets & sky scenes
I’ve since done a bunch more on planetary cloud rendering, need to do a proper write up, but it’s a combination of volumetric noise, flow fields & atmospheric scattering.
The author dismisses cubemaps pretty quickly, but imo it’s the simplest solution & it’s what I did when rendering dynamic gas giants on my own personal project a number of years back* . Using a cubemap doesn’t result in a 6x increase in memory usage, you’re just splitting the texture size from one large rectangular face into 6 smaller rectangular faces, but the total texture detail is the same. The nice part about a cubemap is you don’t have to worry about pole pinching at all + you can use a 3 or 4 dimensional noise function to easily create a seamless flow field for texture animation/distortion.
The story of how I rediscovered the first real project I built after teaching myself to program - an RPG written in QBasic and how I got it playable again 25 years later.
Great job explaning the whole process! I've been building some similar stuff recently for my procedural space-exploration side project (https://www.threads.net/@mrsharpoblunto/post/CufzeNxt9Ol). I was planning to do a dev blog post writing a lot of the details up, but yours covers most of the tricks :)
A couple of extra things I ended up doing were:
1) Using a lower-res texture to modulate the high-res raymarched density, this gives you control over the overall macro shape of the clouds and allows you to transition between LOD better (i.e. as you move from ground level up to space you can lerp between the raymarched renderer & just rendering the low-res 2D texture without any jarring transition.
2) Using some atmospheric simulation to colorize the clouds for sunrise/sunset. To make this performant I had to build some lookup tables for the atmospheric density at given angles of the sun.
3) Altering the step size of the raymarch based on density, I took this from the Horizon Zero Dawn developers where they have a coarse raymarch and as soon as they get a dense enough sample they step back and switch to a higher res step until the density hits zero again.
There’s also OpenC1, which is an almost complete open source remake of Carmageddon. Jeff also has posted a ton of content around the internal workings and file formats etc on his dev blog - http://1amstudios.com/projects/openc1/.
Hi bgirard! I support the FB team that works on this - it's on the roadmap to open source hopefully H1 next year :) It's continued to find significant leaks in other parts of our infra too, so hopefully it will be equally helpful to others. Great to see others looking at memory tools now too - I'll definitely be checking Fuite out
Makes me wonder if you could effectively apply Chernoff faces (https://en.wikipedia.org/wiki/Chernoff_face) to make different hashes easier for humans to recognize. TLDR map parts of the hash to modify aspects of a face (position, size, orientation of eyes, ears etc.) and you can take advantage of all the in-built circuitry in the human brain which can identify very small differences in facial appearance.
The idea is explored a bit in Peter Watts novel Blindsight - not for hashes, but visualizing high dimensional multivariate data via clouds of tormented faces :)
I used the 4000 for a number of years, but found that it was causing problems in my right shoulder. The reason is the inclusion of a full numpad makes the keyboard so wide that your mouse hand has to sit really far to your right, causing your shoulder to be in a position of constant rotation and eventual strain. I eventually took a hacksaw to it to remove the numpad, which improved things - but it was the main reason I preferred the successor (sculpt) as the numpad is a separate detachable piece. These days I'm a split keyboard ergodox weirdo because it lets me put a trackpad in between the keyboard segments which means my shoulders can stay in a neutral position the whole time
Thats why you should also track other metrics when AB testing performance changes. During my time at IG, even small perf improvements almost always corresponded to stat-sig improvements in engagement metrics. 100ms is a pretty significant performance win, definitely not noise - the other thing is that those wins often scale by the quality of device & connection. So a 100ms win for a high end desktop on fiber internet could be multiple seconds for a low end mobile on 3G.
Why do you think its in the margin of error? I never mentioned the error bars on the statistic - We did an extensive AB test and it was a 3% stat-sig improvement
I added support for ES2017 bundles for compatible browsers for Instagram.com a couple of years ago - we saw a 5.7% reduction in the size of our core consumer JavaScript bundles when we removed all ES2017 transpiling plugins from our build. In testing we found that the end-to-end load times for the feed page improved by 3% for users who were served the ES2017 bundle compared with those who were not (more info here https://instagram-engineering.com/making-instagram-com-faste...)
Can we please stop overcomplicating the terminology around frontend architecture? The whole Isomorphism craze was bad enough - lets not make this stuff more complex than it needs to be and create confusion by over-loading existing terms like containers.
Whats being proposed here are dynamically linked shared libraries, they expose some functionality & also consume dependencies (that may be shared). Theres no need to be talking about containers, federation, orchestration etc...
Well you're loading the main feed page of instagram, you expect your feed photos to show right? We don't push random junk - its the content that the page needs to render something useful
Can't reveal the exact numbers, but yeah - a lot of people use IG on web :) Mobile web was always the big focus for us though - most people assume its just a desktop only web version, but actually the mobile web version is much more fully featured than the desktop version.
You're probably talking about the desktop web version I assume. If you check out the mobile web version its actually pretty close features wise, theres direct messaging, stories, creation with webgl filters,etc. The desktop version of these is admittedly lagging behind though - but I'm optimistic that desktop will get some more love in future :)
Yeah, without constant focus on perf, things regress extremely quickly. We're building tight integration with perf budgets into our infra & dev workflows across both Instagram and Facebook, so that any perf regressions will be intentional tradeoffs with product experience rather than unfortunate accidents :)
https://www.threads.com/@mrsharpoblunto/post/DVS4wfYiG8f?xmt... https://www.threads.com/@mrsharpoblunto/post/C6Vc-S1O9mX?xmt... https://www.threads.com/@mrsharpoblunto/post/C6apksDRa8q?xmt...