https://bharadwajraju.com/Bharadwaj Raju2026-08-20T15:10:33.847750+00:00Bharadwaj Rajupython-feedgenhttps://bharadwajraju.com/posts/btrfs-snapshots-in-kdeBtrfs Snapshot Integration in KDE2026-08-20T00:00:00+05:30I have been working on integrating Btrfs snapshots into KDE software. The central part of this work has
been realized in the form of KIO Snapshot, which has just been released. Here I want to discuss what it is, how it works, how it was developed, and the surrounding work across KDE.
Background
Among the key features of Btrfs is the ability to take efficient snapshots of subvolumes. They are efficient because Btrfs makes snapshots share file extents with the originals, so snapshots only take up additional space where they differ from the original. Thus it is cheap to take snapshots frequently without worrying about disk space.
This can be used to build very handy universal “undo” or “time travel” functionality for the user. Yet, though there are graphical tools to work with Btrfs snapshots such as Btrfs Assistant, these are separate from normal file browsing, and are rather technical tools concerned with the orchestration of snapshots. Direct integration of snapshots into the file browser itself for mundane end-user purposes, like Windows has with Previous Versions or macOS with the famous Time Machine, has been lacking in the Linux world. The aim of KIO Snapshot is to build that kind of direct integration for KDE.
What it is
KIO Snapshot lets Dolphin (indeed any KDE software) list and access
Btrfs snapshots of a file or subvolume.
You can right-click on a file and go to a folder view showing you all the distinct past versions of it as saved in your snapshots. (At first, I wrote the snapshots-for-file case as a dialog with buttons to open or restore (like Windows’ Previous Versions feature), but I changed it to be a full virtual folder, since that would be much more flexible — now a user could select multiple previous versions and open them in a comparison tool, or copy them somewhere, or check their metadata easily, or whatever else they wished.)
You also have views into entire directory trees of subvolumes at their various snapshots.
Note that it does not take snapshots, it only allows access to them. To take snapshots, you
would have to do it manually, or through an orchestrator like Snapper.
How it works
Mainly it uses libbtrfsutil from btrfs-progs to talk to the filesystem, and KDE Frameworks’ Solid to query filesystems and mounts on a more meta level.
Now, the Btrfs API is quite conservative in what it allows non-superusers to do with it. Even a question as seemingly innocuous as “what subvolume is this path in?” cannot be answered for a non-superuser directly. The consequence of this is that on my first
attempt at building this integration, I had one component running as a system-level DBus service which would let users query stuff like this for files they owned.
Luckily, a nudge from Méven Car made me realize that with some working-around, I could build out all the features without anything running as root. For example,
while Btrfs is loath to let you get the subvolume ID for a path or vice versa, it will happily give you a listing of the subvolumes (that you can access) under a path. From there you can derive all the information needed.
Using this, KIO Snapshot implements a KIO worker that provides the snapshot:// protocol, which will be understood by all programs which use KDE Frameworks.
This protocol provides a virtual view into the snapshots in a filesystem along two dimensions: the snapshots for a given subvolume, each of which is a browsable directory tree in itself;
and the snapshots for a given file across all snapshots of its containing subvolume.
Allied work
Aside from KIO Snapshot itself, I also worked on some small things in other parts of KDE to support it.
Fixed a bug in KIO which caused inconsistent behavior in Dolphin’s location bar: KIO MR #2305
Fixed how Solid handled Btrfs layouts like the one used in KDE Linux: Solid MR #261
Special default view settings for KIO Snapshot’s views in Dolphin: Dolphin MR #1347
Experimented with adding support for Btrfs subvolumes into Solid itself — this is just a rough proof-of-concept, and maybe this work is more appropriate further upstream in UDisks — but here it is anyway: Solid branch btrfs-subvolumes
KDE Linux
KDE Linux will soon ship with Snapper and KIO Snapshot out-of-the-box.
This is part of a broader initiative in KDE Linux to improve data backup and restore systems, which has also overseen improvements elsewhere, such as in the Kup backup system.
Release
The first stable release of it was made today (thanks to Bhushan Shah for helping with the release process). I imagine it should be getting packaged into distros fairly soon, thanks to the infrastructure that comes with being a KDE project, but even then it should be easy enough to compile from source. Please use it and report bugs and requests, thank you!
]]>2026-08-20T00:00:00+05:30https://bharadwajraju.com/posts/kernel-mentorshipBeing in the Linux Kernel Mentorship2025-09-10T00:00:00+05:30From March to August of this year, I have been a mentee in the Linux Foundation’s Linux Kernel Mentorship Program alongside my university studies.
I’ve always kind of idolized kernel development, so this was a great opportunity to see what it is really like.
I stumbled upon it quite by accident. I was browsing LinkedIn looking at alumni from my university, when I saw that one of them, who was working as a kernel engineer at Google, had reposted an announcement for the LKMP. I clicked through and that was that.
Application & Acceptance
I had to create an account on the LFX Mentorship portal, fill out my profile and a small statement-of-purpose, and then I was given a list of tasks on the basis of which I would be accepted (or not). These tasks ranged from completing a beginner’s course in kernel development from LFX, to writing a cover letter, to building and experimenting with writing simple kernel modules, and even making patches for small mistakes we could find. I managed to get 5 minor patches into the kernel as part of these preliminary tasks.
I finished my tasks and spent around a week or so awaiting the result. On the 26th of February, I got my acceptance email.
Starting to Work
I was invited to a Discord server for the mentees, and each Wednesday we had online meetings with our mentor Shuah Khan, where we covered various useful tools, discussed contribution opportunities, and got non-public (and less harsh) reviews and feedback on our patch attempts.
I decided to focus on fixing bugs, and to that end I tried to fix bugs from syzkaller. It’s a hosted public dashboard for bugs found via the syz fuzzing system. These are mostly kernel warnings, and reports from KASAN (Kernel Address Sanitizer), KMSAN (Memory), and UBSAN (Undefined Behavior).
This was hard. Not all bugs had working reproducers, or were comprehensible to someone new to the subsystem — to say nothing of the false positives. Most of the viable ones would be solved by an actual kernel engineer faster than I could reproduce and investigate it.
Despite this, I managed to get some bugfixes in bcachefs, from syzkaller. I’ll try to recount the process of investigating and fixing each bug in detail, in the hopes that it might be useful to others looking to fix kernel bugs.
Fixes in bcachefs
I picked bcachefs mostly by chance; it happened to have several syzkaller reports when
I looked at the dashboard, and they seemed approachable.
Now, where do we look for the bug? The first thing to look for is the last bcachefs function in the call trace, because it is a reasonable assumption that the bug is in bcachefs code and not in core kernel memory management code. That is bch2_printbuf_make_room.
Right, but what is an “invalid context” anyway? Researching the error message will tell us that “invalid” here is “atomic”. You can't call a function which may sleep from an atomic context.
Although we don’t need this to solve the bug, we might as well ask ourselves why we’re in an atomic context here. The reason can be seen in the locks held part of the report, which lists an rcu_read_lock held by bch2_bkey_pick_read_device. It is illegal to block while in an RCU read-side critical section.
What are the offending functions? Let’s look at what bch2_printbuf_make_room is doing, exactly.
intbch2_printbuf_make_room(structprintbuf*out,unsignedextra){…
/* * Note: output buffer must be freeable with kfree(), it's not required * that the user use printbuf_exit(). */char*buf=krealloc(out->buf,new_size,!out->atomic?GFP_KERNEL:GFP_NOWAIT);if(!buf){out->allocation_failure=true;out->overflow=true;return-ENOMEM;}out->buf=buf;out->size=new_size;return0;}
That krealloc call is what the crash report is complaining about as well. It’s interesting that the call does seem to think about atomicity, from the !out->atomic?GFP_KERNEL:GFP_NOWAIT. Then, out->atomic must not be correctly maintained? Let’s step back in the call trace and look at how the caller is using this structprintbuf.
First we would look at bch2_prt_printf, but that’s not where the structprintbuf is constructed. Neither is it one more step back, in bch2_log_msg_start. Finally we see it being constructed in bch2_fs_trans_inconsistent:
/* Initializer for a heap allocated printbuf: */#define PRINTBUF ((struct printbuf) { .heap_allocated = true })
So buf.atomic is 0. Hence the krealloc call is made with GFP_KERNEL, which is potentially blocking. How do we correctly handle this .atomic field? Let’s look for examples in fs/bcachefs.
Alright. So we’re supposed to increment the .atomic field before working with the buffer, and decrement it when done. Let’s do that. It should be fixed now, right?
Nope, we get a similar crash. What gives? Turns out there’s one more blocking function left in this codepath. It’s bch2_print_string_as_lines, due to it calling console_lock. Luckily for us, there is a direct replacement function already there, called… bch2_print_string_as_lines_nonblocking. We just replace the call, and we’re finally done.
(Kent Overstreet is really nice, by the way. He even suggested possible further work in that thread for me. Namely, trying to replace print_string_as_lines entirely by calling something lower-level which didn't have the 1k chars limitation of printk. Unfortunately I did not find a straightforward lower function to printk that would’ve done what we wanted, but still.)
Now, having done this, I submitted my patch to the bcachefs mailing list, only to be told by Kent Overstreet that he had beat me to it. But! He hadn't replaced the bch2_print_string_as_lines call, which meant the issue wasn’t fully fixed, and I still had a contribution to make. I made another patch doing only that, and it was accepted.
__always_inlinestaticu64get_inc_field(structunpack_state*state,unsignedfield){unsignedbits=state->format->bits_per_field[field];u64v=0,offset=le64_to_cpu(state->format->field_offset[field]);if(bits>=state->bits){v=state->w>>(64-bits);bits-=state->bits;state->p=next_word(state->p);state->w=*state->p;state->bits=64;}/* avoid shift by 64 if bits is 0 - bits is never 64 here: */v|=(state->w>>1)>>(63-bits);state->w<<=bits;state->bits-=bits;returnv+offset;}
(64-bits) became 4294967127. Shift exponents are unsigned, so bits must have been greater than 64 to cause a huge value when cast. We can calculate (or printk) to see that bits==233.
So state->format has invalid values. Where does it come from? If we follow it up the call stack, we see that it comes from structbtree itself and is passed here:
There’s a lot of validation functions in the surrounding code, which is interesting. If validate_bset_keys fails on an invalid format, then maybe it expects a previous validation step to have caught it? There’s some reference to btree_node_set_format immediately after validate_bset, so let’s see if there's anything relevant to us there. Turns out there isn’t any validation in btree_node_set_format itself, so maybe it’s happening before. Let’s read validate_bset instead. It’s a huge function, nevertheless a careful reading rewards us:
So there is a function to validate the format after all! So, the question becomes: why did it not catch the invalid format? Adding a printk to log its result tells us that it does return -BCH_ERR_invalid. What gives?
The answer is in btree_err_on, and how it deals with btree_node_bad_format errors.
And that’s it (confirmed by a bit of logging). If the current recovery pass is “scan for btree nodes”, then all kinds of errors will be turned into -BCH_ERR_fsck_fix.
This offending line was added in cd3cdb1ef706. Previously it would have returned __bch2_topology_error(c,&out).
Based on that I made my first patch, but based on feedback I sent a simpler second patch, which was accepted. The function now checks if it is -BCH_ERR_btree_node_read_err_fixable before returning fsck_fix.
BIT_ULL(nr) expands to 1ULL<<nr. So b->c.btree_id is too large at 251.
But… what are the valid values for btree_id? Where does it come from, and where is it validated, if anywhere?
There are many ways you could try to research these questions. What I did was just search for btree_id in the codebase and scan through for interesting instances.
(With some more forethought, you could save time by assuming that a validation check, if it existed, would probably be in the form of btree_id\s+(>|<) and search for that.)
staticintjournal_replay_entry_early(structbch_fs*c,structjset_entry*entry){intret=0;switch(entry->type){caseBCH_JSET_ENTRY_btree_root:{if(unlikely(!entry->u64s))return0;if(fsck_err_on(entry->btree_id>=BTREE_ID_NR_MAX,c,invalid_btree_id,"invalid btree id %u (max %u)",entry->btree_id,BTREE_ID_NR_MAX))return0;…
}
Examining the functions in the call trace will show that this function is indeed called before the failure point.
This seems familiar to the previous case, doesn’t it? There’s a validation check in place, but it doesn't actually stop the code from proceeding, for whatever reason. Let’s find out.
This check was introduced in 9e7cfb35e266. A later commit, 141526548052, introduced this bug. It is worthwhile to see what exactly these two commits do.
The first introduces a new error type called invalid_btree_id in sb-errors_format.h. (sb stands for superblock.) The second marks the error types btree_root_bkey_invalid and btree_root_read_error as FSCK_AUTOFIX. Why did that make the bug happen? Look at these lines from the crash report, just before UBSAN blows up:
node offset 0/16 bset u64s 0: incorrect max key U64_MAX:18374686479671623680:50331647, btree topology error:
bcachefs (loop0): flagging btree xattrs lost data
bcachefs (loop0): running explicit recovery pass check_backpointers_to_extents (16), currently at recovery_pass_empty (0)
bcachefs (loop0): running explicit recovery pass scan_for_btree_nodes (1), currently at recovery_pass_empty (0)bcachefs (loop0): error reading btree root btree=xattrs level=0: btree_node_read_error, fixing
It looks as if marking btree_root_read_error as autofix caused us to attempt to fix it (as expected), and that codepath ran into this issue.
Back to why the validation check didn’t work. Once again, let’s look at how fsck_err_on actually works. Long story short, it expands into a bunch of macros:
We only gotofsck_err if what __bch2_fsck_err returns is neither fsck_fix nor fsck_ignore.
My first patch thus proposed that we use mustfix_fsck_err_on instead of fsck_err_on, which doesn’t pass FSCK_CAN_IGNORE as part of the _flags. However, it was pointed out that we can just mark invalid_btree_id autofix as well, and then __bch2_fsck_err would (auto)fix it. So that's what my second patch did, and was accepted.
Until shortly after, when this patch series was posted to the linux-bcachefs mailing list which showed that most of the KMSAN bugs recorded against bcachefs were spurious: [PATCH 0/5] kmsan splat fixes.
KMSAN doesn’t understand memcpys implemented using inline assembly, and it apparently has trouble when a struct's fields are initialized via stores to bitfields.
I learned that I could stand to take a little more seriously my suspicions of sanitizers when their reports didn’t seem to match up to what I saw. I had it in the back of my mind, but my inexperience made me apprehensive of just dismissing a report from an established tool. All in all, educational despite me not getting a bugfix out of this one.
Sensor Driver
I spent the rest of my time developing an IIO kernel driver for the InvenSense ICM-20948 sensor, which combines an accelerometer, gyrometer, and magnetometer. This post is long enough as it is, so I’ll talk about that another time. Maybe when it’s actually merged.
Reflections
I split my time during this program between bugfixes and driver development. I semi-intentionally eschewed those contribution opportunities which were in the shape of “find and update uses of this old API to the new one” firstly because I did not find them that interesting to work on, and also because as I observed with my peers, a lot of such patches were seen as churn and rejected by maintainers.
Being in the LKMP was as rewarding as it was challenging. If you’re interested in becoming a kernel developer, I recommend it wholeheartedly. The program structure is extremely flexible, so you can do it alongside other obligations. Contributing to the Linux kernel can be rather daunting and even discouraging, so having a mentor to guide you through the initial troubles is really valuable.
Finally… thank you to Shuah Khan, Ricardo B. Marlière, and Javier Carrasco!
]]>2025-09-10T00:00:00+05:30https://bharadwajraju.com/posts/nothing-ear-2-on-linuxCreating a Linux controller for the Nothing Ear (2)2024-01-06T00:00:00+05:30I bought a Nothing Ear (2), and I’m mostly happy with it. It comes
with a neat-looking Android app to let you set the noise cancellation level and equalization and such.
That’s fine, but it would be cool to be able to control it from my Linux computer as well. So here we are.
We’re going to reverse-engineer the Bluetooth protocol that it speaks, and from there
develop a Linux controller. In the spirit of Nothing Chats, I’m sure Carl Pei would be appreciative.
If you don’t want to read the technical details of how this was achieved, skip to the Finished Product.
All the things that didn’t work
This was the first time I had reverse engineered anything. I ran down a lot of dead ends:
Decompiling the actual Android app.
The generated assembly (Smali) and decompiled Java code are hard to decipher.
Monitoring Bluetooth traffic from my Android.
Doing this live would need root, or specialized hardware like the Ubertooth One.
Finally I thought of running Android-x86 in a VM, giving it Bluetooth, and analyzing traffic from there. (At this point I should thank Michal Jirků. While searching about snooping on
Android-x86 traffic from the host, I found their series of posts on doing a very similar thing for their Yamaha YAS-207. That confirmed that I had indeed stumbled on a productive approach.)
Snooping on Bluetooth from Android-x86
So I set up an Android-x86 VM on VirtualBox and passed through Bluetooth.
After a lot of fiddling with the Android Bluetooth settings, restarting, and so on, finally:
Look at the pixelation on those images. This app wasn’t built with this DPI in mind.
After setting up developer options to enable Bluetooth HCI sniffing and USB debugging, we can connect via ADB.
Once we’ve connected ADB, we can simply select the Android device in Wireshark running on the host, and get our first look at the Bluetooth traffic.
The whole thing appears to be very chatty; there are nearly 300 events when I do something as simple as changing the ANC mode. Presumably only some of them are actually relevant, but that is a lot to sift through.
Protocol Analysis
One neat trick: if you disconnect and reconnect the earphones while a Wireshark capture is running, the capture logs get a lot more detailed! Compare this to the previous screenshot:
All the “Connection oriented channel” packets get turned into actual commands and responses with the correct protocol! Great.
From this we can sift through the packets better. The first thing I tested was switching between having the ANC off and on transparency mode. If we leave the huge PT=Unknown packets of ~592 bytes alone for a minute, we’ll observe (This observation didn’t come directly. I wasted a lot of time chasing even more dead ends like trying to connect to the Audio Sink service.) that every time the ANC is set to transparency, a lot of commands are sent over RFCOMM to channel 15:
Let’s try manually constructing and sending these packets to the device, back on desktop Linux. I used Wireshark to filter all packets of channel 15 and saved it as JSON,
then wrote a quick Python script to read all the packets and send them out, with a 1 second gap to let me observe the effects. When I ran it, I finally heard that sigh in my ear that signalled transparency mode. This is the packet that does it:
55:60:01:0f:f0:03:00:cb:01:07:00:c5:af
This is clearly the right track. After trying more captured packets, here is the table of commands to do various operations:
Command
Packet
ANC Transparency
55:60:01:0f:f0:03:00:cb:01:07:00:c5:af
ANC Off
55:60:01:0f:f0:03:00:cd:01:05:00:c4:47
ANC High
55:60:01:0f:f0:03:00:cf:01:01:00:e6:6f
ANC Mid
55:60:01:0f:f0:03:00:d5:01:02:00:e6:9f
ANC Low
55:60:01:0f:f0:03:00:d7:01:03:00:e7:0f
ANC Adaptive
55:60:01:0f:f0:03:00:dd:01:04:00:e5:3f
In-ear detection Off
55:60:01:04:f0:03:00:25:01:01:00:b2:94
In-ear detection On
55:60:01:04:f0:03:00:26:01:01:01:73:10
Low-latency mode Off
55:60:01:40:f0:02:00:28:02:00:a7:04
Low-latency mode On
55:60:01:40:f0:02:00:27:01:00:97:f7
Ear Tip Fit Test
The packet to start an ear tip fit test is 55:60:01:14:f0:01:00:2a:01:43:16. We get back some results indicating if the left and right earbuds fit well.
If the left earbud doesn’t fit, but the right does, we get this packet:
0000 55 00 01 0d e0 02 00 00 01 00
If both earbuds fit:
0000 55 00 01 0d e0 02 00 00 00 00
We can make a good guess that the last two bytes represent 0 = good fit, 1 = bad fit, for L/R respectively (further testing confirms this).
Device Info
If we look at the first few packets exchanged when a connection is made on the Android app, and experiment with sending them, we notice that sending 55:60:01:42:c0:00:00:03:e0:d1 gives us this reply, which contains the firmware version (1.0.1.101):
0000 55 60 01 42 40 09 00 03 31 2e 30 2e 31 2e 31 30 U`.B@...1.0.1.10
0010 31 fa 36 1.6
The version number is 9 characters, so it’s possible the 6th byte 09 encodes this length information. I guess we’ll test this theory if we ever get a firmware update that changes the number of digits.
And if we send 55:60:01:06:c0:00:00:05:90:dc, we get this:
That string starting with SH101 is the serial number.
If you open an RFCOMM channel 15 and listen for every incoming packet, you’ll notice that a packet is sent for every “change” to the device. For example, if I change the ANC, I get a packet starting with 55:00:01:03:e0. Now, can I get the ANC status on demand, without there being a change? For this I looked at more packets sent during early communication, to see which got different responses when I changed the ANC. I found that when I sent 55:60:01:1e:c0:01:00:0c:03:98:19, I get:
The 10th byte appears to correspond to the ANC. (Which, we can notice, is the same as the 10th byte in the command to set ANC. Turns out we can simplify those seemingly-different ANC commands to just one with the 10th byte alone differing. The other variations were unrelated.)
Byte
ANC Mode
7
Transparency
5
Off
4
Adaptive
3
Low
2
Mid
1
High
Shortcuts
The Ear (2) has a number of different pinch/hold controls.
Whenever we click on the controls for the left earbud, the app sends out 55:60:01:18:c0:00:00:51:39:21 and receives, for example, this in response:
This time the 21st byte is changed. If I set triple pinch to voice assistant, that 21st byte changes to 0b.
This is the table of shortcuts and byte positions:
Shortcut
Byte index (from 0)
Left double-pinch
12
Left triple-pinch
20
Left pinch-hold
28
Left double-pinch-hold
36
Right double-pinch
16
Right triple-pinch
24
Right pinch-hold
32
Right double-pinch-hold
40
And of shortcut actions and their encodings:
Action
Encoding
Skip Back
0x08
Skip Forward
0x09
Voice Assistant
0x0b
Volume Up
0x12
Volume Down
0x13
Noise Control (Active/Off)
0x14
Noise Control (Transparency/Active)
0x16
Noise Control (Transparency/Active/Off)
0xa
Noise Control (Transparency/Off)
0x15
No Action
0x01
Looking at the commands to change shortcuts now (this is to set left triple-pinch to skip forward):
0000 55 60 01 03 f0 05 00 59 01 02 01 03 09 de 71
I noticed that the 13th byte encodes the shortcut action, and the previous two bytes match the previous two bytes before the index of that shortcut in the shortcut-info response as we figured out earlier. Now we can set the shortcut for any action.
And what’s really cool is that like this we can use configurations that the official Nothing X app doesn’t allow, yet are possible on the device. For example, the app restricts double-pinch to skip forward/back and voice assistant. But now I can make double-pinch do noise control or volume up/down as well.
$ ear2ctlinfo
Address: 2C:BE:EB:69:20:5AFirmware version: 1.0.1.101Serial number: SH10182307002807$ ear2ctlanc
ANC: off$ ear2ctlanctransparency
$ ear2ctlanc
ANC: transparency$ ear2ctlshortcuts
left: double-pinch: skip-forward triple-pinch: skip-back pinch-hold: noise-control-transparency-active-off double-pinch-hold: voice-assistantright: double-pinch: skip-forward triple-pinch: skip-back pinch-hold: voice-assistant double-pinch-hold: noise-control-transparency-off$ ear2ctlshortcutsrightdouble-pinch-holdno-action
$ ear2ctl--help
Controls for the Nothing Ear (2)Usage: ear2ctl Commands: info Device information shortcuts View and set pinch gestures anc Control active noise cancellation ear-tip-fit-test Start or stop the ear tip fit test in-ear-detection Turn in-ear detection on or off low-latency-mode Turn low latency mode on or off help Print this message or the help of the given subcommand(s)Options: -h, --help Print help -V, --version Print version
]]>2024-01-06T00:00:00+05:30https://bharadwajraju.com/posts/stacked-sinesStacked Sines2025-09-13T00:00:00+05:30"You are not a robot"
Sterk Hvalros creates a lot of art around the ideas of ripples and waves, and documents his process of making these pieces.
Watching them, I wanted to experiment with some procedural generation along those lines.
I thought about and tried some ways of representing and propagating perturbations like in the video, and my eventual idea was to generate pieces of sine waves for each horizontal line, and to “dampen” them to generate their ripple effects on all other lines.
Sine waves make this pretty nice, mathematically. If you have a function of:
y(x) = amplitude * sin((x - start) / width)
you can vary the amplitude and width parameters to control the size.
Sorry, this live demo cannot be displayed here. Please visit the original site.
Then, the idea is that you generate a set of such sine perturbations at random lines and at random starting positions, and add their effect (y(x)) to each line, dampened by how far the line being rendered is from the origin line of that perturbation.
For each stage of dampening, reduce the amplitude by a constant, increase the width by 2 units, and decrease the start position by π units. (The choice to increase width by 2 units is arbitrary.) (Still, whatever our choice for the increase in width, we can calculate the corresponding decrease in starting coordinate which will keep the peaks aligned by equating (x-s)/w and (x-s')/w' both to π/2.) That lets it spread out while still being on-center.
Sorry, this live demo cannot be displayed here. Please visit the original site.
Thus far this looks simplistic, but when adding multiple randomly-generated sines to one image, the effect is cool.
Sorry, this live demo cannot be displayed here. Please visit the original site.
]]>2025-09-13T00:00:00+05:30https://bharadwajraju.com/posts/angled-random-walk-mountainsAngled Random Walks for DLA-like Terrain Generation2024-08-03T00:00:00+05:30I watched this excellent video, Better Mountain Generators That Aren’t Perlin Noise or Erosion] by Josh’s Channel. It discusses generating mountain heightmaps
using a technique called Diffusion-Limited Aggregation. The structures produced by this process are known as Brownian trees.
In DLA, we start with a seed typically placed at the center. At each step, we randomly place points on the grid and then random-walk them until they hit an existing particle, at which point they are frozen there. This is, of course, very inefficient. The video describes a good technique to get it to be faster, by starting with a small grid and doing a crisp upscale after the grid is filled to a certain degree, and repeating the process until we get to the desired size.
But my immediate thoughts after the video were that surely this would be faster the other way round — by generating outwards from the initial seed. After experimenting with a lot of approaches, I found a way that yields fairly DLA-like results with much less computational cost.
Approach
We have a number of random walkers on the grid. Each of them has these properties:
Age: How many pixels it travelled since it was spawned.
Generation: How many parent walkers it has.
Angle: What angle the walker aims towards.
Type: Is it a long or short walker. Short walkers don’t split into more walkers when they end.
The algorithm for generation is:
Start with a grid of zeros.
Place a number of walkers at the centre, all aimed at different angles.
While there are any walkers:
If it is a long walker and its age module some frequency parameter is zero, spawn a short walker at that position.
If its age is greater than some maximum age, it dies, and…
If its generation is less than some maximum generation, and it is a long walker, spawn some number of long walkers where it stopped, each aimed slightly offset from the parent's angle.
Else, the walker moves in a random direction, chosen via weighted sampling where the weights are smaller the larger the angular distance between that direction and the target angle, and the most opposite direction is removed by subtracting its weight from every weight. The point it moves to is filled in on the grid.
Implementation
I've written a Rust implementation of this algorithm.
By filling each walked pixel with the cumulative age of its walker, and blurring the result, we get a simple heightmap. But this just gives you mountain-like smooth blobs.
To get more interesting terrain, I superimpose a clamped and lightly-blurred version. This preserves the smaller and sharper details generated in the process. The effect is — in my estimation — close to the sought-after erosion look.
Demonstration
Sorry, this live demo cannot be displayed here. Please visit the original site.
Similar Stuff
Planet Eleven Games posted about Using drunken walk for height maps. They were inspired by the exact same video, but the approach they use is different, involving an unbiased random expansion with each new pixel having a chance of dropping in height. Check out their demo.
