Tobias Alexander Franke

Agent OPML

Sat, 30 May 2026 00:00:00 +0200

Same procedure as last year

We do not need to debate the merits of AI; this has been discussed to death on the web and reminds me of one of the many programming language wars I was involved in in the early 2000s, where a single language was somehow the solution to world hunger and memory allocation bugs.

I wanted to talk about a part of my day to day work. I need to evaluate a lot of publications - blog posts, articles from various hardware vendors, Github releases, papers, conference programs … - to judge if they match our business use case or can be feasibly integrated into a prototype. Naturally, I have a lot of constraints around what I can and cannot do: Something must be open source and MIT or equivalently licensed, must meet certain hardware requirements, must be using a subset of GPU APIs, must be part of a certain graphics domain etc.

I read a lot of sources every day that publish new and interesting stuff, like Jendrik Illner’s most excellent Graphics Programming Weekly blog, individual bloggers, conference programs and more.

As an example, a single SIGGRAPH conference can sport around 100 publications that I need to review. Each publication comes with a session, title, an abstract and a full PDF. Naturally, there’s a progression how I get to the juicy parts: Discard sessions I don’t care for first, search for interesting sounding titles, review their abstract and eventually keep the most interesting matches to read later in full.

I am subscribed to several conferences, around 250 personal blogs and several newsletters of companies, all in the computer graphics domain, all of them crunching out several articles a day. This takes an insane amount of time off from my day, every day, and the process is almost completely monotonous. Clanker-like one might say.

So here’s my AI use-case, and how my obsession with RSS feeds directly into all of this.

Pipeline Overview

Agent OPML is a local LLM-based agent (NanoClaw, Pi, OpenCode, OpenClaw, whatever) that uses a tool to fetch publications from various sources and serializes all new entries into a fresh JSON file. Each entry looks like this:

{
    "url": "...",
    "title": "...",
    "authors": "...",
    "summary": "...",
}

Once the data is fetched, the agent’s task, described in a skill, is to analyze each entry. The agent first analyzes the summary (which in many cases is the entire publication pulled via RSS), and if this is unsatisfactory - because it is just a shortened RSS <description>, is metadata about the publication but linking to it or is a URL of a video - go to the original url and try to fetch more using extra tooling. For instance in case of Arxiv, there may be a HTML version of the paper, and if not there may be a PDF instead, in which case the agent proceeds to download the file and converts it to Markdown for processing.

The skill describes what is interesting, what sounds interesting, etc. Each entry is analyzed for its relevance and goals, and more importantly if it fits within certain constraints. If all of these criteria are met, create a mini-summary and rating why this was deemed useful. The report is produced as a Markdown document, with annotations into a JSON file. Both are combined and attached to a new feed file that is served on some httpd.

The outcome is this: A single feed I can subscribe to which updates me daily with those publications I truly want, and the pipeline/algorithm to judge all of it entirely under my control.

Routing data to the agent

The input for the agent is a stream or feed of new publications that is updated regularly.

To do this, we will use an OPML file. For the uninitated: An OPML is a XML file pointing to multiple URLs of feeds. A feed in turn is a structured file containing blog posts or any other updates from a webpage, and those come in three major formats: Atom, RSS 2.0 or JSON Feed. Most importantly however is that everything in those files is machine-readable. Usually OPML files and feeds are used with a feed-reader such as NetNewsWire and are a simple way to store all your subscriptions.

We are going to use the OPML instead to let the agent automatically fetch new content from webpages for automagic analysis. The OPML should capture every feed of information that you’d have to wade through manually, but want the agent to do it for you.

To use my interests as an example, the OPML contains the following types of feed subscriptions:

GPU Vendor: ARM, NVIDIA, Qualcomm, AMD, …
Graphics API: DirectX blog, Khronos blog, Apple Metal, SLANG, …
Game Engines: Godot, Unreal, Unity, O3DE, Unigine, OGRE, Stride, …
Tools: Renderoc, Pix, NSIGHT, …
Research Blogs: Activision, EA Seed
Paper Feeds: Arxiv CS section, The Journal of Graphics Techniques (JGCT), Siggraph Digital Library entries, …
Author Feeds: DBLP and Google Scholar, individual blogs
Github Commits: Microsoft hlsl-spec, Gigi, …
Conference Social Media: GPC, GDC, Siggraph, EGSR, EG, I3D, …
Extras: One feed set up using RSS-Librarian

The last two here are worth elaborating on:

Conference social media feed might sound odd at first: These are subscriptions from Mastodon, Bluesky and Twitter (through Nitter) that will have a special rule in the skill to catch announcements of a program URL for an upcoming conference. This way, the agent can grab more publications before they might appear anywhere else.
The Extras feed serves the outlier case: If some article source is not captured by the OPML, i.e. some interesting but completely random blog post that appears somewhere you cannot subscribe to or that is otherwise irrelevant, then this individual article can be added to the Extras feed manually.

The OPML is used when running a script called fetch_publications.py, which goes through every subscription one by one, fetches the feeds and then combines all new entries it has not seen since the last run into a JSON file that is then used by the agent for analysis.

Setting up Agent OPML

Prerequisites

This setup includes a bunch of things:

A spare Raspberry Pi (optional)
Python
OpenCode
Markitdown
Pandoc
Your OPML file
A bunch of scripts

Start by setting up a Raspberry Pi with Raspbian, and create a separate non-sudo account for the agent. If you want to run this on your local machine, you can skip this step. Then simply run the following steps.

On your sudo account:

$ sudo apt install pandoc cython3

On the agent account:

$ curl -fsSL https://opencode.ai/install | bash
$ pip -m venv ~/.venv
$ . ~/.venv/bin/activate
$ pip install markitdown feedparser

Code snippets

fetch_publications.py

This mini feed-aggregator fetch_publications.py is a simple Python script: Loop through a list of subscriptions from an OPML given via argument --opml and fetch the feeds, parse feed entries, reformat them into JSON dictionaries and use the URLs as IDs to remove duplicates. The outputs are written to a file given by --output that contains the extracted data. A temporary file called feed_state.json is kept in the same output directory to mark already visited articles.

#!/usr/bin/env python3

import json
import hashlib
import requests
import feedparser
import argparse
import xml.etree.ElementTree as ET

from fake_useragent import UserAgent
from typing import List, Dict, Any, Optional
from pathlib import Path

def load_opml(opml_path: str) -> List[str]:
    tree = ET.parse(opml_path)
    root = tree.getroot()
    urls = []
    for outline in root.findall(".//outline"):
        url = outline.attrib.get("xmlUrl") or outline.attrib.get("url")
        if url:
            urls.append(url)
    return urls

def load_state(path: str) -> Dict[str, List[str]]:
    if not Path(path).exists():
        return {}
    with open(path, "r", encoding="utf-8") as f:
        return json.load(f)

def save_state(path: str, state: Dict[str, List[str]]):
    with open(path, "w", encoding="utf-8") as f:
        json.dump(state, f, ensure_ascii=False, indent=2, default=st)

def entry_id(e: Dict[str, Any]) -> str:
    candidate = e.get("id") or e.get("guid") or e.get("link") or ""
    if not candidate:
        composite = (e.get("title","") + e.get("summary","") + e.get("published","")).encode("utf-8")
        return hashlib.sha256(composite).hexdigest()
    return candidate

def normalize_entry(e: Dict[str, Any], feed_url: str) -> Dict[str, Any]:
    return {
        "title": e.get("title"),
        "url": e.get("link"),
        "summary": e.get("summary"),
        "authors": [a.get("name") for a in e.get("authors", [])] if e.get("authors") else [],
    }

def fetch_feed(url: str, timeout=20) -> Dict[str, Any]:
    headers = { "User-Agent": UserAgent().random }
    resp = requests.get(url, headers=headers, timeout=timeout)
    
    try:
        resp.raise_for_status()
    except:
        # retry without user agent
        requests.get(url, headers={}, timeout=timeout)

    resp.raise_for_status()
    
    return feedparser.parse(resp.content)

def load_existing_entries(path: str) -> List[Dict[str, Any]]:
    if not Path(path).exists():
        return []
    with open(path, "r", encoding="utf-8") as f:
        return json.load(f)

def save_entries(path: str, entries: List[Dict[str, Any]]):
    with open(path, "w", encoding="utf-8") as f:
        json.dump(entries, f, ensure_ascii=False, indent=2, default=str)

def main():
    parser = argparse.ArgumentParser()
    parser.add_argument("-i", "--opml")
    parser.add_argument("-o", "--output")

    param = parser.parse_args()

    if (not param.opml or not param.output):
        print("Parameters missing")
        return

    feeds = load_opml(param.opml)
    if not feeds:
        print("No feeds found in OPML.")
        return

    state_file = Path(param.output).with_name("feed_state.json")
    state = load_state(state_file)

    new_entries: List[Dict[str, Any]] = []

    for feed_url in feeds:
        try:
            parsed = fetch_feed(feed_url)
        except Exception as ex:
            print(f"Failed to fetch {feed_url}: {ex}")
            continue

        seen_for_feed = set(state.get(feed_url, []))
        new_ids = []
        for e in parsed.entries:
            eid = entry_id(e)
            if eid in seen_for_feed:
                continue
            ne = normalize_entry(e, feed_url)
            new_entries.append(ne)
            new_ids.append(eid)
            seen_for_feed.add(eid)

        state.setdefault(feed_url, [])
        state[feed_url].extend(new_ids)

    if new_entries:
        save_entries(param.output, new_entries)
    else:
        print("No new entries found.")

    save_state(state_file, state)
    print(f"Collected {len(new_entries)} new entries")

if __name__ == "__main__":
    main()

Re-running the script should only produce a file if any new entries have been found since the last run.

convert-pdf-to-md.sh

OpenCode has a directory ~/.config/opencode/tools which contains small scripts the agent can use to do something without requiring it to go through the process manually, thus saving tokens.

This tool uses markitdown to convert a PDF to Markdown. This is helpful when the agent downloads a PDF and needs to process/read it. The easiest way to do that is to simply convert it to a structured text file.

#!/bin/sh

INPUT=$1
OUTPUT="${INPUT%.*}"

markitdown $INPUT > $OUTPUT.md

The Filter Skills

This is the heart of the analysis and filtering process. These files describe what the agent should do, structured into these three general steps:

Read the combined entries that fetch_publications.py spits out
Analyse each entry if it’s worth your time
Create a report of what passed the filter

First is the filter-publications skill, which generically describes how to parse through the JSON file with all the new entries and how to collect them together. Save it as ~/.config/opencode/skills/filter-publications/SKILL.md.

---
name: filter-publications
description: Given a list of new publications, find those relevant to our business use-case and produce a Markdown report on the agents findings.
---

# When to use this skill

Use this skill when the user wants the agent to evaluate and filter publications such as papers, blog posts, announcements, conference proceedings and so on.

Rank each publication by whether its idea, approximation, pipeline, or result could realistically transfer to the users specified use-case.

Be conservative and evidence-grounded. Clearly separate what the publication actually measured from what the agent infers as possible goals that can be reached with high relevance. Do not invent performance estimates, deployment claims, or results that are not supported by the inspected sources.

Use these three steps outlined below:
1. Read Input
2. Analyze Publications
3. Create Output

# Read Input

The agent is given one JSON file by the user (most often called `new_entries.json`). It contains a list of publications, where each entry has: a `title`, a `url`, a `summary`, and a list of `authors`. 

If the file the agent was given by the user is empty or does not exist, immediately halt and do not progress any further! Do not read any other json files or try to get data from somewhere else.

Each entry represents one new publication that was just discovered. The agent will need to analyze each one independently for its merits. Try to read the `summary` first. The summary may or may not contain the full publication. If it seems too short, try to open the URL and read the contents from there instead. If the `summary` is a short message from a social media page and contains a URL, follow that URL, especially if it contains a full program of a scientific conference.

Execute the [Analyze Publications](#analyze-publications) forstep described in the next section for all entries.

# Analyze Publications

## Required behavior

1. Read one publication entry source from the supplied JSON list.
2. Extract or read the best available information from the `summary` field.
3. Summarize the publication's core idea, evidence, and claimed results.
4. Evaluate the publication using the `review-publication` skill and produce an assessment with a clear verdict.

Report missing abstracts, inaccessible PDFs, broken links, paywalls, failed document extraction, low-quality extracted text, missing project pages, missing code, or insufficient evidence.

## Execution strategy

Do not treat a preliminary title/session-based inference as a confirmed analysis. If only title, session, program metadata, or DOI was inspected, label the evidence as **Limited** and make the score conservative.

Before finalizing top recommendations, do a detailed inspection of the strongest candidates. A publication should not appear as a final **Validated Top Recommendations** with a high score unless the agent has inspected substantive evidence such as an abstract, project page, PDF/text extraction, code repository, results, or limitations. If a publication cannot be analyzed in detail because the PDF is too large, paywalled, inaccessible, or time-limited, list it as a **Potential Top Candidates** rather than presenting it as fully validated.

These recommendations should not be homogeneous. Prefer a diverse shortlist that covers different topics that match the *Relevance* and *Goals* sections of the `review-publication` skill.

Prefer lightweight sources first: program page, DOI or publisher pages, abstracts, project pages, code repositories, videos, and supplemental descriptions. Do not download very large PDFs or supplemental files unless necessary. If a large file is skipped, report that limitation.

# Create Output

Create a subdirectory called `output`. All files the agent generates, even intermediate files, need to be written into this directory!

## Markdown report

Create a file called `report.md`. The file must start with a frontmatter. Use this exact style, with no blank line before the closing delimiter:

```yaml
---
title: Daily Report
author: Agent OPML
date: \today
documentclass: report
colorlinks: true
urlcolor: Maroon
linkcolor: Maroon
---
```

Do not modify this frontmatter. The report must only use Markdown headings, bullet points, and tables. Do not use `---` after the frontmatter, and no HTML tags. Structure the report into the following sections and no other headings:

1. **Overview**: A summary - as a list - of the overall statistics of the analysis, how many entries the agent processed, the themes the agent discovered and what the agent discarded. The list can be structured by source or category.
2. **Validated Top Recommendations**: Publications supported by substantive evidence. Use the the output of the `review-publication` skill for each publication.
3. **Potential Top Candidates**: Publications that look promising from title/session/metadata but lack enough evidence for a confident recommendation. Use the the output of the `review-publication` skill for each publication.
4. **Overall Verdict**: A summary of the agents findings and the papers that were recommended.

## JSON list

Create a file called `report.json` which follows the [Markdown report](#markdown-report), and use the JSON outputs from `review-publication` to populate the `validated_top_recommendations` and `potential_top_candidates` lists.

```json
{
  "overview": "{OVERVIEW}",
  "validated_top_recommendations": [],
  "potential_top_candidates": [],
  "overall_verdict": "{OVERALL_VERDICT}"
}
```

In this file you will need adjust and modify the # Analyze Publications section and/or provide a customized skill review-publication that judges and summarizes each individual entry the filtering process goes through.

Next is the review-publication skill that will guide the agent to judge an individual publication. Save it as ~/.config/opencode/skills/review-publication/SKILL.md.

---
name: review-publication
description: Judge a publication based on relevance, constraints and goals, and describes how to score the publication
---

# When to use this skill

The user asks the agent to produce a summary or judgement of a publication.

# Preprocessing

- If the publication is a social media post ...
- If the publication is a video, first ...
- ...

# Relevance

[Summarize here what is considered a relevant publication to you.]

# Constraints

[Describe all constraints you have and whether they can be circumvented.]

# Goals

[Describe the goals you want to achieve by using or implementing something described in a publication.]

# Final Scores

Use a 1 to 10 relevance score. The score should reflect the how well the publications fits the items in [Relevance](#relevance), [Constraints](#constraints) and [Goals](#goals).

...

Generate the following **Scores**:

- **Overall score**: 1 to 10.
- ...

# Output

- **Summary**: Title, authors, source, and core idea.
- **Evidence**: Abstract, PDF, project page, code, video, supplemental, or pasted metadata.
- **Measurements**: 
- ...

Note that some fields are being referenced in the filter-publications skill that drives it, most importantly the Goals, Constraints and Relevance sections. Filling these sections should already give you a working set to get a summary of the inputs.

create_feed.sh

This script reads the Markdown report from the agent, converts it into HTML and creates a feed file ready to deploy to a host where feed readers can subscribe to it. It only adds one entry. This could benefit from some polishing later.

#!/bin/sh

REPORT=$(pandoc -f markdown -t html $1)
DATE=$(date +%Y-%m-%d)
UPDATE=$(date -R)
GUID=$(echo $REPORT | sha256sum | awk '{print $1}')

cat > "$2" <<EOF
<?xml version="1.0" encoding="UTF-8" ?>
<rss version="2.0">
<channel>
  <title>Publication Filter Feed</title>
  <generator>Agent OPML</generator>
  <lastBuildDate>$UPDATE</lastBuildDate>
  <item>
    <author>Agent OPML</author>
    <title>Daily Report - $DATE</title>
    <description><![CDATA[ $REPORT ]]></description>
    <pubDate>$UPDATE</pubDate>
    <guid>$GUID</guid>
</item>
</channel>
</rss>
EOF

The Cronjob

A small script run.sh to implement the pipeline: Fetch new publications, run OpenCode to filter those and upload the resulting feed item.

#!/bin/sh

FEED_FILE="feeds.opml"
OUTPUT_DIR="./output"
JSON_FILE="$OUTPUT_DIR/new_entries.json"
ARCHIVE_DIR="$OUTPUT_DIR/$(date +%s)"

. ~/.venv/bin/activate

cd ~/ai-paper-filter

# create output dir
mkdir -p $OUTPUT_DIR

# fetch publications
python fetch_publications.py -i $FEED_FILE -o $JSON_FILE

# generate filtered report
if [ -f $JSON_FILE ]; then
    ~/.opencode/bin/opencode run "Use filter-publications on $JSON_FILE"

    # upload new feed file
    sh create_feed.sh $OUTPUT_DIR/report.md $OUTPUT_DIR/report.xml    
    curl -T $OUTPUT_DIR/report.xml "ftp://USER:PASS@MYFTP/PATH/report.xml"

    # archive everything
    mkdir -p $ARCHIVE_DIR
    mv $OUTPUT_DIR/report* $ARCHIVE_DIR

    rm $JSON_FILE
fi

Put this into a Cron job by running crontab -e on your target machine:

0 8 * * * ~/run.sh > log.txt

This will execute the pipeline every day at 8:00 in the morning and produce a new report. If fetch_publications.py does not produce any new entries, the pipeline will not run. If it does however, the findings will be uploaded as a feed file to some FTP after the agent finished execution.

Future ideas

More Extraction Tooling

The agent has to read or interpret content, and in some cases it boils down to the extraction mechanism behind it all: Scrape a URL and convert it to Markdown. Through my work on RSS-Librarian I’ve already found ways to deal with text extraction. For non-raw-text document formats Markitdown and Pandoc already do a great job. I want to find ways however to also address videos (maybe generate dubs automatically) and presentations (either XLSX or PDF), which are harder to parse because of missing structure tags.

Recommendation system for RSS categories

A second thing I plan to test is my own recommendation algorithm for video subscriptions from Youtube/Odysee/Vimeo/PeerTube/etc. A general complaint from those who never grew up on RSS is that subscribing to video channels can quickly drown out good videos in a lot of nonsense (shorts mostly, but also irrelevant videos from channels that veer off topic), whereas the Youtube recommendation algorithm can easily get sidetracked if you click on one wrong video and suddenly everything recommended is just funny slop videos.

I am testing a skill that ingests various video platform feeds (I continue to be amazed that these still exist on Youtube at all), sorts out feed items based on their description and the subtitles downloaded by Markitdown, and then repackages what is left into a new RSS feed that I subscribe to. This feed has one nice property: It is not a discovery feed, meaning the algorithm can never steer from its original goal of giving me only that what I subscribe to. It merely removes entries rather and recommends the highlights in the data stream.

Agentic RSS

Taking the same idea further I can imagine expanding this recommendation algorithm to the entire subscription library: One could subscribe - very liberally - to RSS feeds and end up with thousands of items per day, but the agent runs through them and instead of generating a report, decides whether to keep an item or not, then attaches the ones that were kept to a filtered feed. The agent can have arbitrary many input feeds, but you only ever subscribe to the output feed that has the sorted-out content based on custom rules.

I currently run several digests similar to the paper filter already, but I’d like them to act as pure filters on feed files by abstracting some of the scripting logic more.

Conclusion

This pipeline is not perfect, but has reduced the time I spend on reviewing new publications (especially around SIGGRAPH each year) significantly. Instead of mindlessly eyeballing loads of paper titles and spending hours discarding irrelevant stuff I can concentrate on the things that matter to me the most. Sure the agent might miss something, but so do I when I stare at thousands of unread items in my feed-reader. All I keep doing now is adding publications I find on random sources to a RSS-Librarian feed and adjust the OPML every now and then.

The setup is minimal, and the algorithm behind it all is not some opaque logic from a subscription service, but something I fully control end-to-end. This particular use-case might appeal to you as well: Wading through tons of items for sorting is a common task almost everyone will run into. You may write a paper and need to find new related publications to yours in a sea of articles. You may have too many RSS items in your feed reader. You may need to setup a more in-depth filtering mechanism than a simple keyword search.

Whatever it is, if your task boils down to a for loop with some slightly more complex word-bingo search inside a bunch of feeds, and you’ve set up this process as well, I’m interested in your story. Write a blog post about it perhaps?

The RSS Librarian

Sat, 08 Nov 2025 00:00:00 +0100

Knowledge is power

Many of you may know me as a huge Warhammer 40,000 nerd. I like the absurd and over-the-top nature of it, the grimdark setting and stagnant vision of the future where, what is left of humanity, slowly rots from within. Many small quotes encapsulate the universe very well, but the following one from Dawn of War is one of my favorites:

“Knowledge is power, hide it well.”

Astartes Librarian

Similar to a Black Mirror episode, this quote perfectly reflects our current strange reality of hiding most of the Internet’s articles worth reading behind walls of ads, paywalls or questionable design ideas. Knowledge has not become entirely inaccessible, but similar to what happened in the academic community there is a cost to accessing articles: Your privacy, your sanity, or both.

Saving articles for later-reading has turned into a small ecosystem: Safari has a built-in method to store pages. Mozilla, until recently, ran Pocket and then shut it down. Instapaper remains stable and clean commercial solution I really like, and on the open-source front Wallabag is a viable alternative. There are great offline apps such as Later. Saving articles can also take an archival character, which ArchiveBox supports nicely.

I already have my feed-reader where I read everything else. All of these services are extra layers and apps that are too heavy for someone who just wants to read articles, offline, in a clean layout, without ads, without intrusive layouts or pop-up videos or spyware. This particular problem has already been solved many years ago, so rather than re-inventing the wheel I can instead leverage existing, well-established web-standards to let me read arbitrary articles from the web in the comfy environment of my feed-reader, next to my subscriptions.

If you subscribe via RSS/Atom to blogs, podcasts or Youtube channels, then RSS-Librarian is one more way for you to tunnel the Internet through your feed-reader.

Version One

RSS-Librarian is a read-it-later service for RSS purists. You can store articles from the web in your own personal RSS/Atom feed and use your favorite feed-reader software to read your stored articles later. RSS-Librarian uses no database and works without accounts.

I am happy to announce that RSS-Librarian has now arrived at Version One and is ready for production. Since my first article a lot has happened.

The original RSS-Librarian was kept extremely simple at just 211 lines of code in a single file. RSS-Librarian is written in PHP to make it as easy as possible to drop it on a VPS (virtually zero hosters come without PHP support these days). The script receives a URL as input, runs it through a readability service to extract the raw content, and then attaches it to a randomly generated feed file, no database required. The random feed can be revisited to add more articles to it. Once subscribed to it via a feed-reader, the reader software does the rest. I personally am using readers like FeedMe which download the full content of a feed, images included, to my phone, making all stored articles available offline for later-reading during for instance flights.

Since then, I have addressed several things:

Bugs: The code structure was mixed up with HTML quite badly. After some iterations it got better and easier to maintain. Still not perfect, but much easier to read. Separating code from structure also got rid of a lot of state-tracking bugs.
External Configuration: RSS-Librarian now reads its configuration from a JSON file rather than needing source modifications. The Instance Info section at the footer of the webpage provides an overview of the current configuration.
Feed Validation: The original RSS 2.0 output created invalid feeds. This has been fixed.
Local Readability: Rather than relying on a centralized external readability service, one can now download an extra library and run the extraction of article content locally.
Disabling Content Extraction: Content extraction can now be turned off. Whilst this seems strange, some feed-readers like FeedFlow do not read RSS item content anymore and instead rely on a built-in reader-view similar to the ones in browsers to pull content from the URL directly. To save redundant space in these cases this option will skip adding any content to the feed.
Atom Support: The Atom feed format is slighlty more convenient when it comes to storing an author without an email address, and some other small things. I decided to leave the format RSS-Librarian uses up to the user. One can easily switch between both and RSS-Librarian will automatically convert between formats for existing feeds once a user adds a new article.
User Onboarding: On the original test-instance I noticed many feeds were repeatedly created with just one article in them, suggesting users forgot to bookmark their randomly created feed ID. Now users are onboarded with a warning before adding their first article.
Mobile CSS: RSS-Librarian now has a beautiful and easy to tap-on user interface for mobile.
iOS Share integration: With iOS Shortcuts I was able to create a share-integration that allows any app to share a URL with your bookmarked RSS-Librarian feed.
Stylization: Both custom CSS for RSS-Librarian and XSLT for the feeds can now be configured. When opening the feed’s XML file one now gets a full preview of all stored articles in a nicely formatted webpage rather than just raw XML. If no XSLT is present the code will default to feedreader.xyz for a quick preview of the feed. Both the logo and the FavIcon can be configured as well.
Administration: All users of an RSS-Librarian instance are pseudonymous, meaning they have an ID but no other identifier. To inform users of the instance about downtimes, changes or any other admin related notices, a special ID is pre-generated on first start up which lets an admin attach a message to all existing user feeds. Furthermore, the admin interface allows cleaning up abandoned feed files. The configuration also contains a field to add contact information for the instance administrator, which defaults to the Github issues of RSS-Librarian. The administrator ID has its own feed that keeps track of any administrator operations and URLs added by any feed managed on the instance.

There are also two contributions I want to mention:

Alex Faxå cleaned up the code and added more robust cURL parameters to make RSS-Librarian appear more like a regular browser.
Abe Ramseyer added the ability to see the list of stored items and optionally remove them again.

To summarize, the code is now much easier to deploy, much easier to modify, has less bugs and creates valid RSS and Atom feeds. The user interface is visually better and easier to use on a phone.

RSS-Librarian running via Fennec on a LineageOS phone

A full documentation on how to use RSS-Librarian, how to self-host and configure it and an FAQ is now availble on the Github Wiki of the project.

Store it well

Most importantly though, I want to announce the official RSS-Librarian instance hosted at

https://www.rsslibrarian.ch/librarian.php

The old test instance hosted on hstn.me had several issues that caused subscription errors, particularily with online readers like FreshRSS, since it’s HTTPS certificate did not work correctly and regularily rerouted linked XML files to error pages. Additionally hstn.me would often attach extra URL parameters that needed to be filtered out from that particular instance. W3C feed validation for the same reasons would regularily fail. For Version One therefore I wanted to unveil a stable main instance everyone can use for free. If you have any bugs to report, feature requests or PRs, do not hesitate to open a Github issue.

Join the great crusade against the enshitification of the web. We do not need to burn it all down and re-create it from the ashes, the foundational standards for a better web are already here.

Next-gen challenges for mobile game rendering

Mon, 09 Jun 2025 00:00:00 +0200

Authors: Tobias Alexander Franke
In: Machine Learning Meetup Dublin

Mobile hardware vendors are facing a growing number of game studios that seek to push AAA content on mobile platforms.

In this talk I present an overview of the requirements for next-gen games on mobile: AAA asset sizes, raytracing, volumetric lighting, transparency for foliage, global illumination, high-detail characters, elaborate postprocessing and supersampling, leveraging on-chip CPUs, GPUs and NPUs.

Each one of these categories needs to overcome certain hardware limitations before being feasible on mobile platforms. The goal is to focus on research of highly adaptive and scalable alternatives to algorithms currently in use in AAA games.

Links:

Traditional and Neural Order-Independent Transparency

Mon, 12 May 2025 00:00:00 +0200

Authors: Grigoris Tsopouridis et al. and Tobias Alexander Franke
In: Proceedings of Eurographics 2025

Order independent transparency (OIT) is a technique in computer graphics that allows for accurate rendering of transparent objects without the need to sort them in a specific order based on their depth. Traditional transparency methods often suffer from artifacts and inaccuracies due to this sorting process, especially in complex scenes with many overlapping transparent surfaces. OIT is important because it provides a more visually correct representation of transparent materials, ensuring that colors mix accurately and that all elements are rendered consistently, regardless of their draw order. This enhances realism in applications such as video games, simulations, and visual effects in films. The tutorial will provide an overview of traditional (exact, approximate and hybrid) and deep learning approaches to OIT and examine their scope, performance and accuracy.

Links:

A read-it-later service for RSS purists

Sun, 28 Apr 2024 00:00:00 +0200

Leave no stylesheet alive

I read a lot. I read a lot of papers for instance. They are easy to read, because they have a common format, by which I mean their appearance. This is achieved in the academic community largely by separating markup, the language that describes what - in an article - constitues a headline, a paragraph and so on, and the formatting of thosed marked up properties, through a common Latex template such as the SIGGRAPH acmtog or using common formatters for simpler markup languages such as Markdown. This has one tremendous benefit: Reading a lot of articles is easy, because they all look the same.

I have rambled about the terrible state of the web before, twice actually. Most webpages have become unreadable, which describes a state where it is hard or impossible to find the actual content of a webpage amongst ads, banners, popups or other annoyances. This is especially disappointing if one opened said webpage with the expecation to just read some piece of text matching a headline.

It is ironic that HTML - being the markup language to differntiate content from style - has been abused by designers so much that a bunch of tools emerged to extract the content and throw away the style. Over a decade ago, when this problem became apparent, it was addressed with a bookmarklet called Readability reformatting webpages to reduce clutter, followed by browser implementations which added so called reader views, for instance in Firefox and Brave.

Now Read-it-later services solve two problems at once and make articles offline-readable: Instapaper, Pocket and the FOSS self-hostable Wallabag download and store bookmarked articles after running them through a readability tool, so that eventually all articles have the same layout and same formatting.

Motivation

As someone who reads a lot for research (papers, blog posts, news articles etc.) I wanted to have the simplest possible version of such a read-it-later service: All my bookmarked articles look the same and are readable offline .

Failure 1

My first experiment was to manually store PDFs of the reader view in Firefox. That’s a lot of manual labor though, and syncing across devices requires to store all PDFs on some cloud service. It’s also not easy to use on the go.

Failure 2

My second experiment was trying out Archivebox, a neat FOSS project that streamlines archiving. Archivebox will not just download a copy of a webpage, but run it through several polishing tools. One of them is a readability library, which stores a PDF and HTML version alongside the original article. However, I found Archivebox hard to deploy on a webhost with just PHP on it (basically the things you get for free) and it produces quite bit of extra data I don’t need, but otherwise ticks almost all the boxes.

Failure 3

My third experiment ended in a personal frustration of mine: My workflow for reading anything I am interested in is by adding a star in my RSS reader to an article, which necessitates that anything I want to read is somehow a subscription or feed I can add to my RSS reader, and that isn’t true for individual articles I stumble across. Sometimes this isn’t even true for articles on blogs, where the blog is either too huge to subscribe to for just this one article, or (a sad occurunce these days) it doesn’t have RSS at all, even though that is trivial to add.

Before switching to the most excellent NetNewsWire reader, I was fond of Reeder, which includes the functionality to add read-it-later services like Instapaper as accounts, showing the same interface for both RSS and read-it-later subscriptions. This, essentially, made Reeder my one-stop reading application, indifferent to whether the article came from a single URL I wanted to read or from any of my RSS feeds. Whenever there was an article I wanted to read, I’d simply push it to an Instapaper or Pocket account and then fetch it via Reeder. However, this had one major downside: I’d use a centralized service that gradually became a huge data dump, as more and more articles ended up in those accounts.

Failure 4

My fourth experiment involved RSS itself. NetNewsWire, like most RSS readers, is a minimalist, pure RSS reader, which means anything you want to star inside the application has to come from an RSS feed you can subscribe to.

Both Pocket and Wallabag allow you to subscribe to your personal collection of articles via RSS, essentially treating your article collection as some kind of blog with new posts appearing whenever you add an article. However, this approach had the same downside as when I was using Reeder: The read-it-later accounts become a huge dump after a while, because I was not really interessted in either Pocket or Wallabag, only in redirecting saved articles to my RSS reader. This solution however was extremly close to optimal, with just the exception of me logging into my accounts in regular intervals to delete everything.

Requirements

From the four failures I learned that what I wanted was actually this:

Send a URL to a script, which runs it through readability and attaches the resulting content directly to an RSS feed. Ideally, I can create different feeds for different collections, for example one for work and for personal interests.

Specifically, I want to:

Store single articles in a RSS reader application
Avoid third-party read-it-later services such as Pocket, Instapaper or Wallabag
Minimize the amount of necessary apps for reading articles
Get rid of accounts and not sign up to anything
Read articles (offline) in a readable format, but not categorize or store them indefinitely
Synchronize stored articles to multiple devices
Optionally be able to self-host the whole architecture

The outcome of this is a project I call RSS-Librarian, a read-it-later service for RSS purists. RSS-Librarian solves all of these bullet points with a single, self-hostable PHP file that extracts content from URLs using a readability service and adds what remains as new entries into a personal RSS feed, without requiring special libraries, a database or user accounts.

How it works

You can drop librarian.php onto any host that supports PHP with no other requirements. RSS-Librarian has two parameters: librarian.php?id=HASH&url=SOMEPAGE.

id is a random ID for a personal feed. If this parameter is not supplied, RSS-Librarian will generate a new one and add a feed file corresponding to id into the subfolder feeds/.
url is a URL you submit to RSS-Librarian, whose content will be extracted and added to the feed coressponding to id.

For each url posted to RSS-Librarian, the extracted content will be added to a RSS file derived from id - if it exists in the feeds/ folder. If it does not exist, it will be generated and written. The RSS file will store a maximum of 100 entries before removing the oldest one and adding the new one.

An example use-case

I will be using the this demo instance of RSS-Librarian in combination with NetNewsWire on MacOS (MacOS App).

I can recommend NetNewsWire on iOS (App Store Link), FeedMe on Android (Play Store Link, APK) and FeedBro for various Browsers (Firefox Addon, Brave/Chromium Addon). They all download offline copies of RSS feeds to your device ready for access even when disconnected completely.

Step 1: Create your personal feed

Assume we have the following article we want to store for later reading. First go to the RSS-Librarian instance. You’ll be greeted by the follwing interface.

The view of RSS-Librarian on first visit

This instance is currently hosting 8 other feeds. Paste the article URL https://ohshitgit.com/ into the empty field and press Add to feed. Because you are a new user, RSS-Librarian will now generate a random, unique user ID for you.

RSS-Librarian after adding the first link

On the next page you will see two important things:

Your personal URL: Store this URL in your bookmarks! This allows you to add more articles to your personal RSS feed.
Your personal RSS feed: This is your feed that you can subscribe to with your RSS reader application. It is unique and can only be managed with the personal URL above.

It is important - after adding your first link - to bookmark your personal URL somewhere so you can keep adding links to your feed (instead of creating a new one accidentally)!

Step 2: Open your personal URL

For this demo, the personal URL now links to http://alternator.hstn.me/librarian.php?id=ff4d8b605c2cffacd19639af2a1d3ff8712021d66431de86f425e0279a1e768a. RSS-Librarian, on first use, will create a random hash (in our case ff4d...768a). This hash will be used to store new URLs to your personal RSS feed, which is derived from that hash. You can think of this as your user ID.

Open the personal URL with a browser again.

RSS-Librarian personal URL

With this page you can add more articles to your personal RSS feed. Let’s add another article to the feed we just created.

Adding another article to the personal RSS feed

You can now point your RSS reader to your personal RSS feed and check out the result. At the bottom of the page you can find additional tools:

Feed bookmarklet: A bookmarklet you can use instead of the personal URL. This will add the currently open page to your personal RSS feed.
Feed preview: If you have no RSS viewer at hand you can preview your personal RSS feed with this page.

Step 3: Add it to an RSS reader of your choice

Let’s try this out with NetNewsWire on MacOS. Copy the link personal RSS feed, press the + symbol in NetNewsWire and add the URL.

Adding the personal RSS feed to NetNewsWire

After adding the feed, your stored articles appear in your RSS reader. Most RSS readers will automatically download all articles in a feed, meaning you also have a stored copy offline on the go, for instance when reading on a plane without WiFi.

A view of the stored articles

If you click the title of the article, you will end up on the original URL (in the above sample our first article). If you open the feed itself - RSS-Librarian (ff4d) - you will jump back to your personal URL where you can add more articles to the feed.

If you do not have an RSS reader around, you can also click on Feed preview in the tools section of your personal URL to get a quick web-based view of the feed.

Viewing a feed preview using feedreader.xyz

And that is pretty much it. By visiting your personal URL on a RSS-Librarian instance, you can add more articles to your personal RSS feed and they will become easy to read and storable offline by your reader software. You can subscribe to your personal RSS feed with as many readers as you want and even share that feed with others (which however will let them add articles to it too).

Deploying your own instance

Simply get a copy of librarian.php from the Github repository and put it on any VPS, Raspberry Pi or other webserver that has PHP. There are no other requirements. Create a directory called feeds right next to the file and give the webserver write access to that folder.

In librarian.php you can configure some globals:

$g_max_items is the number of articles stored per feed. Adding a new article beyond that number will remove the last one in the feed. Reduce this number if you’re tight on space.
$g_dir_feeds is the directory where user feeds are stored. Rename this if you want to use a different directory on your instance.

Future work

There are a bunch of things I want to implement.

Protected shareable feeds

Currently the id given to RSS-Librarian is used to create a feed in the feeds/ directory that has the same name. This means that sharing this feed with others will allow them to access the personal URL as well and add articles. I’d like to change this behavior so that the feed’s file name is generated by hashing the id again. This way, the user id and the feed id are separated but correlated in one direction: The id can be used to generate the corresponding feed file name, but not vice versa. This comes at the cost of usability: The feed currently links back to it’s personal URL, which means you can quickly jump to the place where you can add more articles. This would need to be removed to not give away that page.

Remove FiveFilters dependency

RSS Librarian sends articles to FiveFilters, which extracts them into single RSS entries and then appends that entry to the locally hosted feed. This is not optimal, because the feed generation is essentially centralized and not independent. Instead, RSS-Librarian needs to do the extraction locally via the FiveFilters Readbility library for PHP.

Maintenance

Every user can add a new feed at any time and as many as they want. An instance can quickly create a huge dump inside the feeds folder full of garbage feeds that are abandoned because users forgot to bookmark their personal URL, or because they lost the link somehow later.

On every new article added RSS-Librarian could run through the feeds/ folder and simply delete feeds that are too old, for instance those that had no new items added to them for more than 6 months. This is not an issue if the id gets re-used again: RSS-Librarian recreates files for ids when another article URL is added.

App based read-it-later services tie into the OS and let you share an article with the app, which is the default way to add an article quickly to the read-it-later list. RSS-Librarian however has no app and uses a webpage instead, which makes quickly adding an article to a personal RSS feed tedious.

Currently, one can get to the personal URL by simply opening the personal RSS feed URL. Ideally however I’d like a simple share button that adds some URL being shared from any app.

Main instance

An RSS-Librarian demo instance for testing is currently hosted here. The instance has a self-signed certificate and therefore many RSS readers will run into issues. Using HTTP instead is a no-go though. I want to eventually host a reliable main instance.

The Great Crusade against Web-Enshitification

I’ve been using RSS-Librarian just for myself for about half a year now and it’s been a delight so far, given how compact the code is. I created two feeds for myself: One for articles I’m interested in personally, and one for stuff I need for work. I subscribe to my work feed using my personal devices and with FeedBro on my work machine, which means I can easily add and read articles I find for work everywhere, whereas the feed containing articles I’m just interested in personally is only in my feed readers on my own devices. It’s all neatly separated and easy to manage.

Of course I wrote this for myself initially, so if you find it weird, confusing, chaotic, or you’d like to see a feature, please open an issue or let me know otherwise.

Redirect everything

Sat, 13 Apr 2024 00:00:00 +0200

The web is terrible: Redux

The screams are getting louder, but the solutions keep getting dumber.

I know that my background as a graphics programmer is adding heavy bias to my point of view, but I really do not send data-oriented design lectures from Mike Acton to random Electron-app developers because I think their code is slow. Nevertheless, corporate web programmers have collectively given up on the notion that there is something called efficiency. (No time for a good rant? Go to the TL;DR!)

Case in point: Most news websites have tiny irrelevant content that hides between full-screen ads, newsletter popups, cookie warnings, autoplaying videos, and Javascript yanking mouse control away from you to add custom scrolling behavior. Look, for instance, at the following capture from Andrej Karpathy.

Your browser does not support the video tag. Browsing the web, 2021

Of course this browser-violation is just the tip of the iceberg, as there is more code that is running in the background, streaming ever more useless stuff to the machine. Here is a sample captured by Lunasorcery.

Your browser does not support the video tag. Imagine getting paid for writing software like this!

Think about just how much all of this, per tab, eats into your CPU time for no good reason, heats up the machine and drains battery of your mobile device, even if you do absolutely nothing on that page. Soon mobile 4G won’t provide adequate bandwidth to load a simple news article anymore. Part of the problem here is that modern web design is a lazy pieced together conglomerate of hilarious libraries such as the is-odd node module.

A modulo operation, web-style!

The pyramid-scheme continues with an even greater absurdity, also known as the is-even node module, which relies on - you guessed it - is-odd. To put that into perspective: is-even loads 254 bytes in addition to is-odd loading another 543 bytes for essentially this operation (n % 2) == 0 (12 bytes), or 6641% of the necessary bytes to load. You can imagine how the rest of your average page looks like. If you believe this is just an elaborate prank or a contrived example, I present to you a sample of this being used in a glob matcher/parser before someone had the decency to remove it, make a mistake in the process and summon the comment from hell.

So here we are, with your browser wading through mountains of garbage, to display a simple piece of text to you. One way to deal with this is to fully embrace Stockholm-syndrome and just pay the ransom some of these sites demand from you to make the pain go away. Then there are a variety of tools that have been introduced to combat these issues, ranging from reader-views built into browsers, using Readability services (just read that out loud) such as Wallabag, Pocket or Instapaper, or simply adding dozens of plugins into your browser to make pages look sane such as user scripts like GreaseMonkey and user stylesheets like Stylus to, and I quote:

Redesign your favorite websites

However, all of this trickery will still not get the major problem under control: Browsers need ever more powerful machinery to display the most mundane content to you.

Never fear, the age of cloud is here! So why not put the browser on a different machine that is 10x more powerful and STREAM what you see to your machine, that extra-layer will solve it!

Architecture Astronaut hard at work

Turns out that this idea is still a tad bit too ludicrous to be implemented these days, so lucky for us this project is dead.

RIP ... and may you stay dead forver

Let’s recap where we are right now:

Your browser is as complex as an operating system
Browser complexity is the source of many security issues
(Corporate) websites abuse browser complexity at every opportunity
Even if you counter the abuse with layers and layers of tools, the issue is getting worse over time
There is no incentive for cooperations to reverse course
New programmers are born into habits of being as inefficient as possible

The alternative

My number one suggestion is to leave most of the web entirely and pipe as much content as you can through RSS.

However, that doesn’t take care of individual URLs and sites that simply don’t have an RSS feed. Every day someone sends me a link to one of the various horrible social media sites that I need to then open in a browser.

This is where a new open-source trend comes to the rescue: The Alternative Frontend movement. Alternative frontends, as the name suggest, are websites that provide a different frontend to an existing webpage.

For instance, Invidious is a popular alternative frontend for Youtube. It provides access to anything on Youtube, however in a much cleaner interface with much less clutter, no ads, zero tracking and directly downloadable MP4s in place of the video streaming.

Right now there are many frontends to popular websites that extract their content and present it in a much saner way. These include Youtube, Twitter, Reddit, Tiktok, Imgur, Reuters, Quora, IMDB, Medium, Google, Stack Overflow, Fandom Wiki, Snopes… the list keeps growing, because most of the original pages are terrible.

A lot of these alternatives will use either public APIs or scraping to fetch the content of the original page and display it to you, but those details are not important.

This way please

One key question for me is how to use these frontends in a manner that is not intrusive, easy to use and allows me to open random links and get the best possible result.

The easiest way I have found is to use a redirector plugin for your browser. These plugins will detect a URL you enter into the browser, match it with a regular expression, and if a match has been found, replace it with another.

For instance, you might detect the pattern https://www.youtube.com/* and replace it with https://invidious.fdn.fr/$1.

A URL to https://www.youtube.com/channel/UCYO_jab_esuFRV4b17AJtAw (the 3Blue1Brown channel) will therefore be redirected to https://invidious.fdn.fr/channel/UCYO_jab_esuFRV4b17AJtAw.

These plugins allow you to add multiple patterns for multiple webpages. I have created a configuration you can simply import without the need to add all these patterns by hand, which is available here.

Redirector plugins for Firefox/Librewolf/Torbrowser

Redirector - General purpose redirector you can customize yourself
LibRedirect - Redirector to popular alterantive frontends, highly configurable
Privacy Redirect - Redirector to popular alternative frontends, but limited in scope

Redirector plugins for Safari

Redirect Web for Safari - General purpose redirector you can customize yourself (can load exported Firefox Redirector JSON)
Privacy Redirect - Redirector to popular alternative frontends, but limited in scope

Load-Balancing

Many of the alternatives are hosted privately by volunteers and are called instances, which means there isn’t one URL for one alternative, but many. This decentralization acts as a safety net: Banning one doesn’t bring down the service itself and distributes the load.

As an example, there are many Invidious instances available. However, using one of them exclusively has two downsides:

It might stop working, get banned, rate-limited or shut down
If many users pile on one instance, it will be overloaded and most likely rate-limited more quickly

To solve this issue, ideally recognizing a pattern should redirect to a random instance instead of a fixed one, so that the load distributes equally across all hosted instances and prevents cases of rate-limiting or banning of an instance. This would need two things: For each alternative frontend a list of all available instances that is up to date, and the ability to forward to randomly selected URLs. The forwarding though is the problem.

A solution to this comes in the form of redirecting-gateways such as Farside. It’s a simple page that lists frontends and their instances. For each frontend, there is one link at the top of each section which will forward you randomly to one of the instances. You can configure your redirector to forward your URL to use those as targets instead.

As an example, instead of redirecting https://www.youtube.com/* to https://invidious.fdn.fr/$1, you may want to redirect it to https://farside.link/invidious/$1, which will select a random Invidious instance and attach your $1 parameters to it.

I provide a simplified, self-hostable redirector-gateway called Tzeentch which is heavily inspired by Farside, but simpler to deploy. You can check out a demo instance here. It also adds a feature absent in Farside, which is to create a ready-made configuration for your redirector for all the frontends you select.

LibRedirect on the other hand maintains an internal list of instances where you can select one or more favorite ones that it chooses from randomly, but this is connected to a bit of manual labor every now and then.

Conclusion

The battle for a cleaner, saner and less intrusive web is lost.

Alternative frontends remove the need for a barrage of plugins to sanitize the web, are privacy-friendly and just generally provide a better experience. Redirector plugins using gateways which distribute the requests among frontend-instances will ensure decentralization and reduce the likelyhood of instances getting rate-limited or banned.

I highly encourage you to redirect everything and check out this way of browsing! Just take a look at LibReddit and compare it with Reddit itself, for instance on a phone. Ask yourself: Is this better than the original?

Engine Design as a Holistic Adventure

Tue, 18 Oct 2022 00:00:00 +0200

Authors: Tobias Alexander Franke and Royal O'Brien
In: Tales from the 3rd Dimension Podcast

Most listeners know that Huawei isn’t just a mobile phone company. But many might not realize that it runs a global network of research institutes that are working on optimizing engine development. Tobias Alexander Franke, principal game engine architect at Huawei, talks with Royal about why the company prefers working with open source 3D engines over commercial 3D engines. Highlighting the benefits of different perspectives, he believes open source collaboration results in a more well-rounded engine. Tobias and Royal reflect on other hot topics like the early days of the Open 3D Engine (O3DE) in GitHub, the need for standardization for greater interoperability and the development of the Metaverse.

Tobias Alexander Franke, principal game engine architect at Huawei, is an experienced graphics engineer with a background in both graphics research and the gaming industry. He holds a PhD from TU-Darmstadt focused on augmented reality, relighting and global illumination.

Links:

Life in the metaverse will be revolutionary

Thu, 21 Jul 2022 00:00:00 +0200

Authors: Tobias Alexander Franke and Sandra O'Connell
In: Irish Times

I have been interviewed by the Irish Times on the topic of the Metaverse, what it is, why one would be interested in it, the big problem it is supposed to solve and how it will affect our lives. In this interview, I give a sober analysis of the Metaverse, and my goal is to cut out the hype.

Links:

A New Gaming Eco-system for Huawei

Thu, 07 Jul 2022 00:00:00 +0200

Authors: Tobias Alexander Franke
In: Huawei GSTS 2022

Cloud-based gaming services have seen varying success in practice. Where-as multiplayer games feature a wide variety of aspects which are hosted remotely, most games today run exclusively on one device and require the customer to adapt to new hardware requirements in regular cycles, usually tied to the current console generation. Streaming-based gaming services have in contrast failed so far, underestimating technological challenges as well as selling to the wrong market. Edge computing architectures are designed to distribute computational tasks to other nodes in a network or cloud. Huawei’s involvement in the Open 3D Engine presents a unique opportunity to build a more resilient architecture for game engines that scale from one device to an arbitrary number. In doing so, a new gaming eco-system evolves as a business opportunity for Huawei.

Links:

Huawei GSTS 2022

Scalable Global Illumination for O3DE

Tue, 12 Oct 2021 00:00:00 +0200

Authors: Tobias Alexander Franke
In: O3DECon 2021

Implementing global illumination for games at scale (on mobile devices and up to high end PCs) is a hard problem. O3DE currently uses DDGI as a solution to provide both baked and real-time global illumination. However several key issues need to be addressed before this system is ready for production. In this talk I want to address those issues:

Scalability and streaming
Authoring with small or thin objects
Probe aliasing
Volume overlaps and blending
Baking large scenes
Strange mixtures of baked and real-time probe based volumes
Baked lighting variants for day-night cycles or similar setups
Re-using visibility buffers for other effects
Going beyond diffuse GI

The idea is to highlight each issue, present a small solution (not necessarily the solution) based off experience from developing similar volume based GI systems in other engines, and make more people from the community - both artists and programmers - aware of these issues so we can collectively come up with a proper system that has an easy workflow and provides great results when computing GI for a project. The talk will close with an outlook to some experiments, novel workflows and how the same system could be used to provide GI for large open worlds, maybe even on mobile devices.

Links:

Tobias Alexander Franke

Agent OPML

Same procedure as last year

Pipeline Overview

Routing data to the agent

Setting up Agent OPML

Prerequisites

Code snippets

fetch_publications.py

convert-pdf-to-md.sh

The Filter Skills

create_feed.sh

The Cronjob

Future ideas

More Extraction Tooling

Recommendation system for RSS categories

Agentic RSS

Conclusion

The RSS Librarian

Knowledge is power

Version One

Store it well

Next-gen challenges for mobile game rendering

Traditional and Neural Order-Independent Transparency

A read-it-later service for RSS purists

Leave no stylesheet alive

Motivation

Failure 1

Failure 2

Failure 3

Failure 4

Requirements

How it works

An example use-case

Step 1: Create your personal feed

Step 2: Open your personal URL

Step 3: Add it to an RSS reader of your choice

Deploying your own instance

Future work

Protected shareable feeds

Remove FiveFilters dependency

Maintenance

Share-feature for mobile

Main instance

The Great Crusade against Web-Enshitification

Redirect everything

The web is terrible: Redux

The alternative

This way please

Redirector plugins for Firefox/Librewolf/Torbrowser

Redirector plugins for Safari

Load-Balancing

Conclusion

Engine Design as a Holistic Adventure

Life in the metaverse will be revolutionary

A New Gaming Eco-system for Huawei

Scalable Global Illumination for O3DE