Since early 2024 I have been partially working on a new project at Epic Games: a “proper” camera system¹ for the Unreal Engine, so that anybody can make cool-looking cameras for their games! It came out with UE 5.5 a couple of months ago, albeit in a firmly “Experimental” role, and is somewhat unimaginatively named “Gameplay Cameras”. As I’m working on many improvements and additions for UE 5.6, I figured I would start a developer diary to let anybody interested in cameras know what’s up!

But first, here’s a little trailer video I made, using the Game Animation Sample Project, to hopefully whet your appetite:

About two-thirds of what you see in the video is available in UE 5.5, although the UI and workflow may look different as I improve, fix, and polish things up for UE 5.6. You can find it all under the “Gameplay Cameras” plugin, and there’s even a little bit of documentation on it, even though we usually don’t provide documentation for “Experimental” plugins. Of course, I’ll go into more details into future articles. Just be aware that the version in UE 5.5 is an early look with non-final workflows, missing features, and various limitations that make it, well, “Experimental”, and therefore unsuitable for production.

So far I’ve been working for about a year on this, but as I’m still also working on Sequencer, what you can see in Github at the time I’m writing this article represents maybe six months of that, minus holidays and the like. I’ll continue working part-time between cameras and cinematics for the foreseeable future. If you have questions or feedback about Gameplay Cameras, I’d love to hear it, and my contact information isn’t hard to find… I just won’t guarantee a timely reply! That’s what UDN is for.

If you want to follow along with the next articles in this developer diary, but you don’t want to read any of the other nonsense from my blog, you can limit yourself to the Unreal Engine category of posts.

My new year’s resolution, so to speak, is to try and post developer diary updates for Gameplay Cameras here about once a week. But as someone cleverly said: “this isn’t a promise to you… this is a promise to me“. See you next week! Maybe!

1. Of course there are “proper” camera systems out there, but the Unreal Engine never shipped with one out of the box. ↩︎

Cryptocurrency critic, technology researcher, and software engineer Molly White recently published this great primer on the “POSSE” philosophy in her “Citation Needed” newsletter:

A simple technique offers the best of both worlds: total control over your own work, while still maintaining a presence on third-party platforms.

POSSE is a pretty bad acronym (standing for “Publish (on your) Own Site, Syndicate Elsewhere”) describing a pretty good approach where you publish your writings, status updates and cute pet photos on your own website before some sort of (preferably automated) system posts a copy to various 3rd party proprietary services (aka “cross-posting”).

The next time a new social media site comes along, you can plug it in to your existing system. And the next time a social media site dies or becomes untenable, you just disconnect it. With this model, even when a platform goes under, you lose relatively little: your posts still remain live and under your control on your site, even if the copies of them on the disconnected website are abandoned or deleted.

There are many advantages and inconveniences about the POSSE philosophy, and Molly outlines the main ones very well. For what it’s worth, I’m with her when it comes to engaging in conversations originating from the 3rd party services: I don’t “backfeed” replies from Mastodon or Bluesky or whatever into comments on my website, and instead I just check those services every now and then and reply there. Anyway, check out the original article if you’re new to that sort of thing, and share it if you’re not!

I’ve been following the POSSE approach for about 8 years. Like most people, I’ve written my own ad-hoc tools to implement it, and for a bit more than 6 years this tool has been SiloRider, available on Sourcehut (using Mercurial) and Github (using Git).

The interesting thing (to me) about SiloRider is that it works independently of your website. It fetches and parses your blog’s HTML markup, looking for microformat information, which most blogging engines implement, at least partially. SiloRider extracts your latest updates from that, and can cross-post any new ones to a variety of services. It currently supports Mastodon, Bluesky, Twitter, and Facebook Pages. When I moved away from PieCrust and returned to WordPress, SiloRider kept chugging along.

Of course, SiloRider isn’t super user-friendly: it’s a command-line tool written in Python, and is therefore meant for tech-people. Sure, I have a super barebones WordPress plugin that invokes it after I’ve published an article, but that plugin is so rough I hesitated a bit before making it public just now (as usual, it’s available on Sourcehut and Github). But if someone is motivated enough, it should be feasible to make it user-friendly enough for a vanilla WordPress user.

Anyway, if you want to give POSSE a try, SiloRider might do the job! I may even reply to questions and bug reports…

I’m always impressed by people who treat their online presence as easily discarded stuff. They abandon their Twitter accounts with the same shrug as when they abandoned Yahoo Mail or Live Journal or whatever, leaving all their emails and posts to rot. I suppose that life is too short to care about emails from 2004 or DMs from 2011, but I so often find myself grateful to be able to refer to some of those old archives that I can’t see myself ever discarding anything. Does that make me a digital hoarder?

There haven’t been any blog posts about some of my open-source projects in a while and the reason for this is two-fold. First, I’ve been lazy about that side of my hobbies while I’ve been re-allocating my free time to writing and illustrating roleplaying game books. Second, I’ve actually discontinued a couple of my main projects: PieCrust and Wikked.

My team at Epic Games is looking for a software engineer! We are the Cinematics team inside the Unreal Engine team, and we develop, among other things, the Sequencer tool.

This inaugural article by Sarup Banskota for the OSS History newsletter sent me down a little nostalgic trauma trip:

Unless you’ve been writing code for decades, you’ve likely never used a VCS besides Git. However Git is far from being the first important VCS. 

The World Before Git

What follows is a short history lesson about source control, from the early days of RCS to the modern day of Git. I remember being confronted to CVS in the late 1990s during an internship, and I was completely confused. I don’t think our software development professors ever taught us about source control, so the very concept of it was fairly alien to me at the time.

Later, in one of my first corporate jobs, I started using Rational ClearCase, which was anything but. That’s probably when I learned about branching, and when I got really interested in source control. At home, I got on board with Subversion (SVN) and that was the first VCS I ever truly enjoyed using. For solo projects, it just worked, kept out of your way, and early software like TortoiseSVN made it super user friendly. I was quite surprised by this bit, though:

A key idea SVN introduced was that of atomic commits. With CVS, when a commit operation failed halfway, it would lead to data getting corrupted. Part of the files would get saved, and part of them would be lost. SVN’s commits took an all or nothing approach, ensuring reliability.

The World Before Git

It’s amazing to think that atomic commits weren’t a thing before the early 2000s.

Sarup glosses over a few things about how Linus Torvalds came to write Git, though. As far as I know, it wasn’t so much about the controversy around an open-source project like Linux using a proprietary system like BitKeeper. It probably played a role, but I think the main impetus came from BitKeeper terminating their free license.

Of note, around the same time, Olivia Mackall (known back then under the name Matt Mackall, or mpm) also started working on Mercurial, with the same goal of replacing BitKeeper. However, Linus came out with Git a few days earlier, and Git was adopted over Mercurial for obvious reasons. Still, Mercurial is the only other VCS, besides SVN, that ever truly liked. It just makes sense to me, and when I use it I rarely have to scream into a pillow afterwards the way that all other VCSes make me.

I actually like Mercurial enough that I wrote a few things for it: a plugin to push/pull from multiple remote repositories (now maintained by Marcin Kasperski), a Vim plugin (ironically also available on Github), and, oh yeah, the Mercurial hosting implementation for Sourcehut, among a few other things.

Meanwhile, over here in the game development industry, Perforce reigns supreme. The main reason is that source code is a rounding error in our repositories: binary assets (3D objects, textures, audio, animation, etc.) take up dozens and dozens of gigabytes, up to a couple hundred gigabytes for big AAA games¹. Add to that many branches for different releases or GDC demos and so on, plus hundreds of commits per day, and the Git/Mercurial model of cloning and merging utterly fails.

Some game developers argue about storing code in Git and binary assets “somewhere else”, but with tight dependencies between code and data, the act of keeping the two in sync becomes tricky (although I’ve seen some game studio attempt it). Other game developers argue about investing in Git LFS in the way that, say, Microsoft did to make Git work with their massive codebases. But of course nobody has that sort of money to throw at problem that isn’t their core business.

At some point, Plastic SCM looked like an interesting competitor to Perforce, but that didn’t go anywhere, and then Unity acquired them and squandered them away. Meanwhile, the Git hype is so strong that Perforce has spent years trying to chase it, instead of, you know, taking care of their customers who need something different from Git in the first place. I think there’s a great opportunity for someone out there to write a VCS that properly addresses the needs of the video game industry and be the, well, maybe not the hero we deserve, but the hero we need.

1. My peers on Mastodon remind me that, as a programmer, I don’t see all the raw assets, also often stored in Perforce, that can easily triple these numbers! ↩︎

Although it’s somewhat ironic that this article was written on Medium, this is a very good rant on obsolescence of files:

I love files. I love renaming them, moving them, sorting them, changing how they’re displayed in a folder, backing them up, uploading them to the internet, restoring them, copying them, and hey, even defragging them. As a metaphor for a way of storing a piece of information, I think they’re great. I like the file as a unit of work. If I need to write an article, it goes in a file. If I need to produce an image, it’s in a file.

I also love files. That’s why I put them in a NAS. And then I have another NAS to backup the first NAS. That’s why my blog is essentially generated from a bunch of files, and why my notes are in a wiki that’s also generated from a bunch of files. Files are easy to edit, store, version, backup, recover. Sure, they don’t scale very well to giant online services, but for personal use, they’re the absolute best in my opinion. Of course, they’re also the worst for companies who want to lock you in and profit from your data under cover of “convenience”.

But Apple doesn’t make it that easy to get to your files. Images are dumped into a big stream, sorted by date. Audio is somewhere in iTunes. Notes are… in a list? Apps are scattered around the desktop. Some of my files are in iCloud. You can email photos to liberate them from the iPhone, and through a convoluted method via iTunes, you can access some files within certain apps. But those files are transitory — cached, and may be deleted without warning. These aren’t like the carefully crafted files and folders on my computer.

This one of the reasons I have a love/hate relationship with my iOS devices. And if you look at the number of apps that support some Dropbox or Box integration or similar, I don’t think I’m the only one. I’m actually not even sure Dropbox would have been as popular if Apple had initially released iOS with friendly support for moving files in and out of the device. Most of the apps I use on a regular basis on my iPad are ones that can interact with the files in my home network, like Plex or GoodReader. I refuse to store stuff on iCloud (except as a form of extra backup), regardless of how many times Apple insists on running advertisements on my phone in the form of notifications you can’t disable¹.

Anyway, read the whole article, as it’s making several other interesting points on the subject.

Bottom-line: I also miss files. We eventually got the big companies to sell music as DRM-free files, but it looks like it’s never going to happen for video. Everything is a cloud subscription service, now. Everything is streaming. Everything is a timeline. It’s not just about files going extinct, it’s about the very concept of “ownership” going obsolete.

I recently published version 0.8 of Wikked, my plain-text-files/SCM-backed
wiki engine, followed immediately by a quick little patch release. Grab it as
usual with a pip install wikked -U!

Although there are a few interesting new things in this release, the more
important announcement here is the launch of the official website
running itself on Wikked! Head over there now and tell me if anything
looks broken!

Keep reading if you want more information about all this.

New and Improved

There is now a simple way to upload files to your wiki – both as global files
(uploaded to the _files directory) or as page-local files (uploaded next to
the current page’s file). It looks like this and yes there is room for
improvement 🙂

The permission system has been re-written to use a more standard ACL-type model. You can check out the help section on permissions for more information…

…which leads me to the new help pages. You can see them on the official
website, but they come bundled with any Wikked wiki, since they’re part
of the source code. As such, they’re read-only (although you can edit them and
submit a pull request if you spot a mistake!). You can access them from the
“Help” link at the bottom of any wiki page.

Another thing you might have noticed with that link to the help section on
permissions is that Wikked now generates links for each heading on a page.

Last but not least, I re-did the UX of the navigation menu so that it finally
works correctly on both desktop and mobile browsers.

The Official Wiki

The other big new thing is the official Wikked wiki, which runs on
Wikked (unlike the previous official project page which was just a static page
generated with my other big web project, PieCrust).

Right now it looks a bit like this:

There’s not much to say about this besides “it’s about time”. There’s not even
much on that wiki yet – most of the content comes from the aforementioned new
help pages.

I wonder how long it will take until somebody finds a security hole in Wikked
and adds a dick pic to the home page. Oh well, I’ll worry about that if Wikked
actually gets popular… and even then, if you really want to post dick pics,
you can already do that on the Wikked sandbox wiki or, well, anywhere
on the internet, really.

And that’s it! If you haven’t checked out Wikked yet, give it a go:

1. pip install wikked
2. wk init mywiki
3. cd mywiki && wk runserver

Enjoy!

Lately, I’ve been spending my free time making PieCrust (the static website generator powering this blog) support Indieweb things like Micropub and (incoming) Webmentions. But while being on the receiving end of things requires intimate knowledge of a CMS’ storage format, other Indieweb concepts put your website on the sending end, and that generally doesn’t rely on anything else than the final HTML markup… it’s therefore CMS-agnostic.

To implement that side of the Indieweb coin, I decided to write a new tool, independent of PieCrust: it’s called SiloRider¹!

What it does right now is let you adopt the POSSE model with your website. After you’ve published a new article or post, you run SiloRider and it will syndicate (or “cross-post”) that out to “silo” services – right now it supports Twitter and Mastodon.

For instance, this recent update from my blog was syndicated like this on Twitter and like this on Mastodon:

In the future, it will probably send Webmentions out to websites you’re replying to, and other such things that can be done by parsing the just-published pages on your website.

In PieCrust, I integrate SiloRider simply by making my default publisher run a script that bakes the website, rsyncs it to the publicly served folder, and invokes SiloRider – this way, it works whether I post from a client app like Micro.blog’s iOS app, from the PieCrust admin panel, or after pushing my blog repo to my server (since I have a hook that runs that same publisher). You can similarly run it after your Hugo deployment, or whatever it is you use to make your website.

As with all my other projects, the documentation is up on BOLT80, and the code is available on GitHub and Bitbucket, depending on whether you prefer Git or Mercurial.

Last year I announced PieCrust 2.0 without much fanfare and, guess what, here comes PieCrust 3.0 now!

The funny thing is that I didn’t post much about PieCrust during that whole time… the joke about blog engines is that the more you work on them, the less you actually use them.

So as is tradition, I released the new version of PieCrust on the Python package server and immediately found a bunch of new bugs, which I proceeded to fix (we’re now at PieCrust 3.1.1)… I’m not very good at this whole thing, even after several years.

But either way, it’s out! You can run pip install piecrust -U and read the rest of this post if you want to know what’s new.

This release has breaking changes so make sure you read the upgrade notes this time around.

The highlights in this release include:

• Simplified content model: there are now just content sources and URL routes. The previous “page generator” concept (which was used for taxonomies and blog archives) is now just a content source that happens to not return pages on disk, and instead comes up with pages on the fly. This makes things a bit simpler for the site configuration.

  There is a new concept however, which is the concept of a “content pipeline”, which is the thing that knows how to render a source’s contents. It’s a lot less user facing though – in most cases users don’t need to bother with it.

• Better administration panel: the administration panel now supports talking to client apps (via the Micropub standard) to create new posts. This means you can post to your static website from your phone with apps like Micro.blog! This requires some server-side setup however, so you have some work to do.

  In the PieCrust 3.0 cycle I’ll actually be mostly looking at adding more IndieWeb technologies like Micropub – Webmention is next, which will let your site display comments.

• Watchdog-enabled chef server: when you run chef serve, you can have PieCrust monitor your assets (like CSS/JS files) and re-process them when you edit them (unless you’re using another more sophisticated asset pipeline like Gulp or Webpack or whatever). In PieCrust 2.0 it was using a very basic polling system, but now it’s using Watchdog, which means it works with your OS to get notified of file changes. The main upside is a more efficient file monitoring that’s a lot more battery friendly for laptop users.

As always, if you see any bug, report it on the GitHub issue tracker.

As is tradition, PieCrust 2.0 was released without much fanfare a few weeks ago. Just like with the previous version, it just happened because, well, nothing happened: I was using PieCrust for a couple other websites without any problem or need for new features, so I figured it might be as good a time as any to make it official.

Time to run pip install -U piecrust.

Since then of course I found a few bugs, so a 2.0.1 release is just around the corner, but that’s just business as usual.

What’s more interesting, first, is that I’ve been a bit quiet over here for the past couple months, and that’s because I was busy with my second hacking project from the holiday break (the first one of which was the recently announced Jouvence). Sadly it didn’t really pan out like I expected, so after working on it for a while I’ve now shelved it for the time being. These things happen.

The second thing is that I started work on PieCrust 3.0. It’s a mess right now but the goal there is to get rid of a bunch of cruft that accumulated over the years. As such, it will break backwards compatibility quite a lot (hence the major version bump) but I’m hopeful the result will be easier to use, easier to
maintain, and maybe even hopefully a bit faster.