~neon/thoughts A blog about games, programming, and computers in general. tag:blog.neon.moe,2019-07-06:/feed https://blog.neon.moe/favicon.ico Jens Pitkänen blog.author@neon.moe 2024-11-15T15:00:00+03:00 Standalone hypertext documents tag:blog.neon.moe,2024-09-27:/2024/09/27/inlined-html 2024-09-27T01:44:56+03:00 2024-11-15T15:00:00+03:00 HTML with all the resources inlined is a standalone document format, like PDF! And it's much nicer to read than PDF.

Standalone hypertext documents

Posted on 2024-09-27 by Jens Pitkänen

Let’s go back to 1991 and assume the world wide web is a collection of documents, a vast world-wide library, where documents can link to each other, and form a grand web of information. A vast library of hypertext, as the name of the protocol would suggest. What a nice vision.

Now, a bit closer to our current reality, note that the web is not just text. CSS and JS were slapped onto HTML to make it more widely useful, and to allow more self-expression and creativity. Both can be included in HTML, but are often stored in separate resources that get loaded after the initial HTML, or pushed alongside the initial HTML if the server is modern and cool and supports the newest protocols.

But note: the moment a page requires other resources to look how it’s supposed to look, it’s no longer a singular document! This is evident if you try to right-click and “Save page as…” on pretty much any web page — it will download the HTML to your computer, and try its best to also download every resource it refers to, maybe into a directory next to the HTML file. Now, if you wanted to share this page like a document, with someone over a different protocol, or archive it for yourself, you might zip it up with the resources to keep them together. What a mess. My own article archive directory does not look nice, largely due to this.

Consider the otherwise very annoying format, PDF. Download a PDF file, just the one, open it, and it probably looks as it was intended! Of course, they’re otherwise very annoying, defining the layout so strictly that it’s incredibly hard to read most PDFs on any screen smaller than 13 inches diagonally. But focusing on how the PDF has everything needed to display the contents as intended, I think it does a good job! I think many pages on the world wide web — at least pages that still pretend to be “documents” — should have this feature as well.

Standalone/inlined/resources-embedded HTML

HTML does allow for self-contained documents! There’s <style> tags, and there’s <script> tags that don’t include the src attribute. It’s just that, for probably good caching related purposes, we tend to link to resources rather than including them straight in the HTML. Well, a few bytes of CSS or JS probably won’t hurt your internet bill too much, given all the JS being hauled on Modern Websites™ in any case. Not to mention videos or livestreams. I think any non-moving media will be just fine, bandwidth-wise. And you can cache the resulting HTML, we’re talking about documents here, not dynamic websites that show different content on every load.

Alright, we’ve included our CSS and JS resources in the HTML, what about fonts and images? Data URLs! Yes, really. I don’t really like linking to Google Fonts anyway, so anyone visiting my pages would be pulling in the font files in any case — not much of a difference whether they come as their own files, or with the main HTML file. Same applies for the images, but even more, since those wouldn’t be cached even in the Google Fonts case. Of course, it’s unfortunate that you’ll have to increase the size of the resources to 133% of the original due to base64 encoding, but maybe we can save space in other ways…

Fonts

There are ways to pick out just the glyphs used on a particular page! That way, even though you’ll be serving the fonts on each page, it’ll be a small part of the entire font. And you never need to serve the entire font files! At least on my pages, the biggest files I serve, by a good margin, are fonts. Fonts are big for an understandable reason, they need to encode drawing instructions for a large amount of different looking glyphs — that’s a lot of information! However, any one particular page probably doesn’t contain that many different characters, at least in my experience writing English (which admittedly might be skewing the numbers a bit).

Additionally, thanks to the web being a wild west of odd HTML, browsers have to accept all kinds unorthodox patterns: you can actually include stylesheets at the bottom of your <body>! This is actually the main reason I ended up attempting this whole operation — the main content of my pages, the text, does still load on very slow connections without much issue: the fonts are at the end of the document. This way, you get the important part very fast, can start reading it, and leave the fonts loading for however long it takes.

fonttools

The easiest way I found to make subsets of fonts is the fonttools python library. It’s also available as a command line tool — kind of evident from the API — but I had already started writing a python script for the inlining logic anyway, for parsing the HTML and going through the relevant files. Here’s some code to showcase the basic TTF font subsetting API, and how I use it:

import fontTools.subset
from fontTools.ttLib import TTFont
import html
import re
import tempfile
import unicodedata

def compress_font(resource_bytes, charset):
    with tempfile.NamedTemporaryFile() as tmp:
        tmp.write(resource_bytes)
        with tempfile.NamedTemporaryFile(suffix=".woff2") as tmp_subsetted:
            fontTools.subset.main([tmp.name, f'--unicodes={charset}', f'--output-file={tmp_subsetted.name}', '--no-ignore-missing-unicodes', '--with-zopfli'])
            return tmp_subsetted.read()

charset = set()
char_source = some_html + maybe_some_css_if_you_have_content_text_in_there
# Add html entities as the char they represent
for entity in re.finditer(r'&[A-Za-z]*;', char_source):
    charset.add("U+%04x" % ord(html.unescape(entity[0])))
# Add all non-control chars to the charset
for c in char_source:
    if unicodedata.category(c).startswith("C"):
        continue # control characters
    charset.add("U+%04x" % ord(c))
charset = ','.join(sorted(charset))

my_ttf_font_bytes = ...
subsetted_font_bytes = compress_font(my_ttf_font_bytes, charset)

Note: I’ve spliced this together from my longer resource-inlining script, so this is more like pseudocode, to use as a reference. No license. (Or maybe any license?) Use however you like.

Ideally, there’d be an option in the popular static site generators that you could turn on to have the generator do this for you — I don’t know, maybe there is! But hey, if you also have your own generator, there you go.

Images

Images are a bit more problematic than fonts, mostly due to how they’re included in HTML. For images, the source (= in this case, the entire image file) has to be in the <img> tag. This means that on a very slow connection, you can only read up to the first image, then wait for it to download in its entirety, and only then get the rest of the text — until the next image, where it happens again. Ideally you’d place the image where you want it, and provide the source later, at the end of the file. But alas, I didn’t come up with a way to do that with HTML.

I had a limit of 10000 bytes for image inlining for a while, but ended up removing that limit. Even with all the images included, the biggest page on this blog — my entire undergraduate thesis, about 20 pages of text and diagrams in PDF form — is only a bit over one megabyte. That’s not too bad! On a slow connection, it might take a while to load, but there’s certainly enough text that you’d have something to read and ponder while waiting for the images to arrive. On a really slow connection, it might be annoying, but you could just always download the page and let it download while doing other things. I assume that’s how you all dealt with files on the internet in 1995. In any case, using the DSL simulator in Firefox, which I think is an appropriate “worst thing to expect in a situation where the user isn’t browsing on their phone in the woods”, the thesis loads fast enough that the images are already loaded when you scroll to them, even if you’re only skimming.

Results

Well, my HTML files sure used to be smaller. However, instead of serving a megabyte of fonts to every visitor, and half a megabyte of images, I’m just serving a single, one megabyte HTML file — in the worst case. My blog’s front page is 234kB. Most of the posts are very similarly sized, due to most of the bytes going to images, videos, and fonts, and many of my posts do not have images or videos. The Quake post is almost 600kB due to the video, and as previously stated, the worst case is my undergrad thesis, at 1.14MB.

My sites’ PageSpeed Insights score improved! Not that it matters too much, but they do provide fun little numbers to try and optimize. Since my HTTP server is not configured to use HTTP 2 and push the relevant resources, previously browsers had to get the HTML, see that there’s CSS to download, then download that, then find out that there’s fonts to download, and finally start downloading all the resources required. Very bad for latency, especially given that the server is a Raspberry Pi 2B, and even if it’s trying its best, every request does have a bit of unavoidable lag. Now, browsers can simply request /index.html and they get a stream of bytes that will eventually result in the entire page loading. I like this on just the theory level as well, in that all the required downloads (in this case, just the 1 file) can be started as soon as the browser has done the TLS handshake and sent the initial GET. Fewer round trips! And no server-side special configuration needed.

But most importantly, the pages are standalone documents now, downloadable as HTML files, viewable as is! No extra files! You don’t even need system fonts, since all the fonts required to display the page are included. Maybe I’ll need to post some 4K video some day, but even in that case, I think it’ll be better to include a low-res version or just a thumbnail inline, and link to the high-res version.

Update, 2024-11-15: As I’m writing this addition, my internet is down! A novel experience in the well-connected city of Helsinki, Finland. Thanks to RSS, while I’m off the internet, I can still read articles fetched before — great! However, many RSS feeds I follow are somewhat hard to read, as they use images, and those images link to resources on the internet. Moral of the story: inline (even low resolution versions of) your images so that your RSS feed is readable without fetching additional resources. Though alternatively, I suppose RSS readers could prefetch all the resources needed.


Comments? Email! The email is blog dot hello at the same domain this blog is hosted at, minus the subdomain. Sorry about the subterfuge, gotta try and avoid the robots somehow. Also on the fediverse, @neon@fedi.neon.moe
Blogroll: Cohost Edition tag:blog.neon.moe,2024-09-20:/2024/09/20/cophoenix 2024-09-20T17:59:59+03:00 2024-09-27T04:20:12+03:00 R.I.P. Cohost, the vibes were exquisite. Cool blogs below the fold.

Blogroll: Cohost Edition

Posted on 2024-09-20 by Jens Pitkänen

In the grand tradition of (I’m sure) everyone who has written a master’s thesis, I am currently not writing it, even though it is a writing day. But do not worry, I have not yet fallen behind my planned page count. Cohost news and a bunch of blogs to follow below.

R.I.P. Cohost

Cohost is shutting down :(

I never posted anything, but I lurked there for most of its lifetime (at least from early on enough that I got @neon). The vibes were excellent, and much to my surprise, many of the chosters I followed have started up blogs! Great news for all serial feed collectors out there. It only took me 4 years of Twitter, 7 years of the fediverse, and cohost rising and falling for me to realize that the humble blog is really my favorite format of posting.

Here’s the list of blogs from the people I happen to follow on cohost. When I drafted this post, this list had like four links, but now that I started going through my follows, wow, almost everyone on cohost has a blog. Unfortunately, a few don’t have Atom nor RSS feeds as I’m writing this, but maybe they will soon.

And Joe Wintergreen started up a forum, which fits web 1.0 vibes, but sadly does not fit in my Feed Collection: Impromptu Dot Zone.

More blogs

Since I haven’t linked any other blogs on this blog before, here’s a list of some of my favorites with some keywords that match at least some of their posts:


Comments? Email! The email is blog dot hello at the same domain this blog is hosted at, minus the subdomain. Sorry about the subterfuge, gotta try and avoid the robots somehow. Also on the fediverse, @neon@fedi.neon.moe
Renderer Mk. II Retrospective tag:blog.neon.moe,2024-04-12:/2024/04/18/prelude 2024-04-18T01:50:10+03:00 2024-09-18T02:56:00+03:00 What is a Vulkan renderer made of? Eight thousand lines of setup. I'm a fan.

Renderer Mk. II Retrospective

Posted on 2024-04-18 by Jens Pitkänen

I’ve been working on a Vulkan renderer for a while, on and off. It’s now at the point where I think I’ve explored enough of the API to be comfortable with Vulkan, and I think the next step would be to start a new renderer, since I’ve come to understand why you’d want some of the abstractions I’ve seen elsewhere, which I purposefully avoided including in this one. Given that the renderer is done, in some sense of the word, I thought I’d write a retrospective on it. Kinda like a post-mortem code review for the whole thing. Ideally it would help me organize my thoughts on what I learned, what I should do differently in the future, and generally, what it is that I have made.

I’m inspired to write the series in a literate programming kind of way, like the PBR book. Of course, this one’s not intended to be an example to follow along, but rather, I want to paste all the code into the blog posts to make sure I cover all of it, and explain myself. I won’t end up doing a proper code review if I don’t have to comment on all of the code. We’ll see how much I stick to that.

Renderer Mk. II history

This is my second proper rendering project, by which I mean something that I’ve come back to work on after the initial phase of excitement, and actually used in a game I’ve made. My first renderer was fae, a 2D sprite renderer targeting OpenGL 2.1 / 3.3. There’s actually just one backend, but systems with 3.3+ get instanced rendering (one instance per sprite) instead of two triangles per sprite with each vertex written out into the vertex buffer. The DPI scaling factors post on this blog was about this one! I used fae in one roguelike, and later decided that I’d rather just use SDL’s in-built renderer for 2D sprite games.

Now, Mark II is a bigger project with loftier goals. I started playing with OpenXR in 2021, which got put on hold (to this day) while I write a 3D renderer using Vulkan. I’ll get back to the OpenXR stuff one day. The core idea when starting out was to write a very minimal renderer, focusing on making the Vulkan calls required to render the scene, not on designing abstractions to make the renderer cool to use, or anything else like that. That’s not to say there’s no abstraction, there is a relatively self-contained memory allocation module, and an uploader which manages command buffers and fences, allowing for straightforward uploads to VRAM and detecting when that’s done. At its current state, I’d say there’s not much unnecessary abstraction. The renderer is split into modules, and there is some data wrangling that takes CPU time not necessarily required by Vulkan, but the main design goal is still minimalism.

Due to said minimalism, there’s no render graph, no support for shaderly varying materials, no interesting content-specific optimization, and so on. That said, I did use this renderer in a 3D archery boomer shooter game I made for a uni course, though I had to fork it and quickly add in lights, which are still not implemented in the main branch. On one hand, the renderer is minimal :), but on the other hand, it’s minimal :(. All that said, when it comes to learning Vulkan, the project has been a great success. If nothing else, I’ve gained confidence using the API, and I feel like I would be relatively comfortable working on a Vulkan renderer, or writing a new one.

Renderer Mk. II overview

What is there, then? It’s a forward renderer, has support for alpha-to-coverage and skinning, and it technically has a pass for rendering transparent materials, but I never got around to sorting, so it requires some very careful scene composition to not have rendering issues. Everything is rendered using indirect instanced draw commands, into an HDR (R11G11B10) framebuffer and then tonemapped, and MSAA is supported (remember the VR origins?).

Memory is managed using simple arenas (creation-time-sized bump allocators), with manually created separate arenas based on content (i.e. textures or buffers) and lifetime (e.g. cleared never, once per level, once per frame, etc.). Meshes are loaded from mostly floats into various kinds of packed values: vertex positions are 16-bit floats, tangent and normal attributes are packed into 10 bits per channel, and joint weights are one byte (4 bytes per vertex). The gltf mesh loading is quite quick too, reading the values from a memory-mapped file, packing them, and writing into a memory-mapped Vulkan buffer. The buffer is also used for rendering, depending on if the user has ReBAR, otherwise it’s a staging one.

The descriptors are a bit more interesting/convoluted. Each draw indexes into an array of material indices based on BaseInstance, and the material indices point to a SoA-layout struct with the material parameters. Those parameters consist of constants, and indices to a global texture array, where the various PBR textures are sampled from. Notably, I haven’t gotten around to implementing any real shading in the main branch renderer, so most of the PBR textures are unused currently. The SoA material arrays and texture array (and other misc descriptors) are managed using a centralized descriptors-module, and they’re all just simple uniforms, not storage buffers. I’ve tried to keep the GPU requirements modest, though I do use dynamic rendering, so new drivers are needed to run the renderer.

Pipelines don’t have as much management, which I’m quite happy about, as there’s only eight pipelines, and they’re all specified in constant structs! They consist of the dear imgui pass, the tonemapping pass, and the non-skinned and skinned variants of opaque, alpha-to-coverage, and blended passes. Rust really shines here, with inferred types and const-time evaluation carrying the whole thing. The pipelines are created at startup based on these parameters.

The scene is constructed by queueing up “draws” (material + mesh + transform), which get sorted by mesh and material, repeat renders are combined into instanced draws. Those are then written as indirect draw structs, which are rendered using the seven scene rendering pipelines, after which there’s another render pass for tonemapping “and other post-processing” (which I never added). There’s no culling and no lod system, unfortunately.

I think that covers about all of the renderer, as a little summary, but I’ll delve deeper into all of that in the following chapters.

What’s next?

More posts on this blog, with lots of rendering code! And hopefully, explanations of what said code does, what problems it has, how I may want to do it better in the future, and so on. I have no clue how much work it’ll be to review all of that code, but I do like writing about things I’ve made and what I think of them, so it’ll probably get done. If not, I hope this has been a useful little article about the renderer, which should serve as a reference for the future, when the renderer is long buried, and I want to know what it was like.

Update, 2024-09-17: Instead of continuing with this, I started doing some summer courses, and now I’m writing my master’s thesis. The thesis is about game engines! Might post it on this blog.


Comments? Email! The email is blog dot hello at the same domain this blog is hosted at, minus the subdomain. Sorry about the subterfuge, gotta try and avoid the robots somehow. Also on the fediverse, @neon@fedi.neon.moe
Sävytyksen ja rasteroinnin erottaminen reaaliaikaisessa kolmiohahmontamisessa tag:blog.neon.moe,2024-04-11:/2024/04/11/kandi 2024-04-11T21:09:00+03:00 2024-04-11T21:09:00+03:00 My undergrad thesis written in Finnish: a literature review on separating shading and rasterization in real-time rendering.

Sävytyksen ja rasteroinnin erottaminen reaaliaikaisessa kolmiohahmontamisessa

Posted on 2024-04-11 by Jens Pitkänen

This post is my undergrad thesis written in Finnish: a literature review on shading, rasterization, and how they may or may not be intertwined in real-time rendering. I wrote it between September and December 2021. The thesis contains an introduction to how real-time renderers tend to work, and brief overviews of the differences between regular old forward rendering, deferred and visibility-buffer-based rendering, as well as texture-space shading.

Notably missing is any mention of clustered approaches to either forward or deferred rendering, which I was vaguely aware of, but didn’t end up mentioning or studying further. That said, it’s not particularly tightly related to the rasterization-shading connection this thesis focuses on, more just a recent way to render stuff more efficiently, so I’m not too bothered. Just a little.

I originally intended to translate the whole thing into English (and I still might, one day), but now that I’ve not done it for two years, I thought I’d just post it in Finnish. One of the main things I like about the thesis are the translated terms anyway, so at least they’ll be on the internet now.

Finally, just as a little disclaimer, there may be typos or errors, I’m blind to the text after reading it so many times. Some might have been in the published thesis, other may have been introduced in the LaTeX to Markdown translation. In any case, I’d be glad to hear of any issues, and maintain some kind of errata here.

Tiivistelmä

Reaaliaikainen kolmiulotteisen grafiikan piirtäminen on 1970–luvulta asti tutkittu ongelma, jolle on keksitty tehostusratkaisuja sekä laitteiston että ohjelmiston kannalta. Suurin osa reaaliaikaisesta kolmiulotteisesta grafiikasta nykyään piirretään kolmiohahmontamisella, jossa kaksi merkittävää osaa ovat rasterisaatio, eli prosessi jolla kolmiot muutetaan pikseleiksi, ja sävytys, eli pikseleiden värien laskeminen.

Tässä tutkielmassa selvitetään kirjallisuuskatsauksen menetelmällä mitä kolmiohahmontaminen, sävytys ja rasterisaatio tarkalleen ovat, miksi sävytys ja rasterisaatio haluttaisiin erottaa ja miten menetelmät tämän toteuttamiseksi ovat kehittyneet ajan kanssa. Kirjallisuutena käytetään pääosin kirjoja, jotka kertovat reaaliaikaisesta kolmiohahmontamisesta yleisesti, sekä artikkeleita ja esitelmiä joissa aiheeseen liittyviä löytöjä on esitelty, erityisesti SIGGRAPH- ja Eurographics-konferensseissa.

Katsauksen tuloksena selviää, että rasterisaatio on ollut historiallisesti hyvin tehokas menetelmä kolmiohahmontamiseen, mutta sen hyödyt ovat ajan kanssa pienentyneet kolmiomäärien sekä näytönohjaimien tehojen noustessa. Rasterisaation ja sävytyksen erottaminen vaikuttaa olevan tehokas metodi rasterisaation ongelmien minimoimiseksi, säästäen kuitenkin sen hyviä puolia, kuten sen laskennallisen tehokkuuden laitteistokiihdytyksen seurauksena. Huomataan myös säteenseurantaprosessorien mahdollinen vaikutus rasterisaatiolaitteiston tarpeen vähentymiselle tulevaisuudessa.

1 Johdanto

Reaaliaikainen kolmiulotteinen grafiikka on nykyään jokapäiväinen näky. Kolmiulotteisia pelejä on saatavilla puhelimille, konsoleille ja tietokoneille. Useimmilla älypuhelimilla pystyy suorittamaan lisätyn todellisuuden sovelluksia, jotka voivat piirtää reaaliajassa esimerkiksi huonekaluja kameralla kuvattuun oikeaan ympäristöön. Viime vuosina yleistyneet virtuaalikonsertit ovat usein myös luotu reaaliaikaisella kolmiulotteisella grafiikalla, jossain tapauksissa jopa esiintyjää myöten. Elokuvissa tunnetusti käytetään tietokoneilla luotuja kuvia, mutta ne ovat historiallisesti laskettu kuvauksien jälkeen käyttäen huomattavasti aikaa. Viime vuosina reaaliaikainen grafiikka on kuitenkin kehittynyt tarpeeksi, että Mandalorian-sarjan [11] kuvauksissa käytettiin reaaliaikaista kolmiulotteista grafiikkaa sci-fi ympäristöjen valaistuksen simuloimiseksi.

Kolmiulotteinen grafiikka on laskennallisesti hyvin raskasta piirtää. Tietokoneiden ja puhelimien näytöille tyypillinen 1920 × 1080 resoluutio antaa jo suuntaa: jos pikselin värin laskemiseksi olisi jokin ohjelma, sitä pitäisi suorittaa noin kaksi miljoonaa kertaa yhden kuvan luomiseksi. Näyttöjen virkistystaajuudet vaihtelevat 30–240 Hz välillä, joten edellä mainittu kaksi miljoonaa kertautuukin mahdollisesti sadoiksi miljooniksi suorituksiksi sekunnissa. Nykyiset suorittimet suorittavat muutamia miljardeja syklejä sekunnissa, mutta noin sata sykliä pikseliä kohden riittää vain hyvin yksinkertaisen kuvan luomiseen, kymmenen ei siihenkään.

Pikselien laskenta on kuitenkin hyvin rinnakkaisesti laskettavissa. Tästä syystä kolmiulotteisen grafiikan laskentaan käytetään usein näytönohjaimia, apusuorittimia jotka sisältävät nykyään jopa tuhansia samanaikaisesti käytettävissä olevia laskentayksikköjä. Näytönohjaimet erityisesti sisältävät prosessoreita rasterointia varten, jonka avulla voidaan piirtää kolmiopohjaista grafiikkaa hyvin tehokkaasti.

Tässä tutkielmassa selvitetään kirjallisuuskatsauksen menetelmällä, mitä rasterisaatio ja sävytys tarkoittavat reaaliaikaisessa kolmiohahmontamisessa, miksi ne halutaan erottaa toisistaan hahmontamisprosessissa, millä menetelmillä ne on erotettu ja miten nämä menetelmät ovat muuttuneet ajan kanssa. Luvussa 2 esitellään reaaliaikaisen kolmiohahmontamisen rasterisaatiopohjainen arkkitehtuuri ja alustetaan syitä rasterisaation sekä sävytyksen erottamiselle. Luvuissa 3–5 esitellään menetelmiä joilla erottaminen voidaan tehdä, ja vertaillaan niiden vaikutuksia hahmontamisprosessiin.

2 Reaaliaikaisen kolmiohahmontamisen perusteet

Kolmiohahmontaminen (eng. triangle rendering) viittaa prosessiin, jossa muunnetaan kolmioista koostuva ympäristö pikseleiden väreistä koostuvaksi puskuriksi, joka voidaan näyttää kuvana esimerkiksi tietokoneen tai puhelimen ruudulla. Tässä luvussa kuvaillaan reaaliaikaisen kolmiohahmontamisen eri vaiheet pohjautuen Akenine-Möller et al. kirjaan Real-Time Rendering [1, s. 11–23, 103–148].

2.1 Kolmioihin pohjautuvat kolmiulotteiset ympäristöt ja rasterointi

Kuvan hahmontamista varten tarvitaan vähintään itse ympäristön koostavat kolmiot, sekä kamera. Kolmiohahmontamisessa kameralla viitataan sen ominaisuuksiin kolmiulotteisessa avaruudessa: missä se on, mihin se osoittaa, ja kuinka suuri kuvakulma sillä on. Kuvakulma vastaa oikeassa kamerassa linssin polttoväliä. Kuvassa 2.1 näkyy kolmiot, valo ja kamera jotka muodostavat ympäristön, jonka hahmontamista tarkastellaan tässä luvussa.

Kuva 2.1: Esimerkkiympäristön koostavat kolmiot, valo ja kamera.

Jokainen kolmio koostuu kolmesta verteksistä. Verteksi viittaa yhteen kolmion kulmaan liittyviin tietoihin, ja niihin sisältyy ainakin koordinaatti kolmiulotteisessa avaruudessa, ja yleensä jonkin verran kolmiokohtaisia ominaisuuksia joita käsitellään alempana. Kolmion sisäiset koordinaatit ja muut luvut voidaan laskea myöhemmin interpoloimalla arvot näiden kolmen verteksin luvuista.

Hahmontamisprosessi alkaa lähettämällä kameran ja kolmioiden tiedot näytönohjaimelle. Näytönohjaimella ensimmäisenä ajetaan verteksiohjelma (eng. vertex shader), joka ottaa sisääntulona yhden verteksin, tekee jonkinlaista laskentaa ja lopulta palauttaa mahdollisesti muunnetun verteksin. Verteksiohjelma voi myös käyttää verteksistä riippumattomia yhtenäismuuttujia (eng. uniform variables), jotka lähetetään näytönohjaimelle kolmioiden kanssa samaan aikaan. Verteksiohjelma ajetaan kaikkien kolmioiden vertekseille.

Verteksiohjelmalle annetaan yhtenäismuuttujana projektiomatriisi, joka voidaan laskea edellämainituista kameran ominaisuuksista. Projektiomatriisin avulla verteksiohjelmassa käännetään kolmiulotteiset kolmioiden koordinaatit kaksiulotteisiksi ruudulla oleviksi koordinaateiksi, vastaamaan virtuaalimaailmassa olevan kameran näkymää. Kuvassa 2.2 näkee esimerkkiympäristön projektion jälkeen.

Kuva 2.2: Projektion jälkeinen näkymä esimerkkiympäristöstä.
Kuva 2.3: Rasterisaation löytämät pikselit yhden kolmion osalta, ja sävytyksen jälkeen. Kolmannessa kuvassa näkyy, miten kuva alkaa täyttyä kun kolmioita käsitellään lisää.

Kun kolmiot ovat muunnettu kaksiulotteiseen koordinaatistoon, ne muutetaan pikseleiksi rasteroimalla. Rasteroinnissa selvitetään, mitä pikseleitä kukin kolmio koskee, ja tallennetaan kolmiota vastaava väri ruutupuskuriin (eng. framebuffer) näiden pikselien kohdalle. Näytönohjaimissa on rasterointia varten erityinen prosessori, ja sen toimintaan voi yleensä vaikuttaa vain hyvin rajatusti. Värin valinta tapahtuu erikseen ohjelmoitavassa sävytysohjelmassa (eng. fragment shader tai pixel shader). Kuvassa 2.3 esitellään, miten tämä prosessi alkaa projektion jälkeisistä kolmioista, ja piirtää kolmio kerrallaan lopullista kuvaa.

Kolmiot Verteksiohjelma Kolmioiden rasterointi Sävytysohjelma Pikselit ruudulle
Kuva 2.4: Hahmontamisen eri vaiheet.

Sävytysohjelma laskee värin perustuen esimerkiksi sävytettävän kolmion alkuperäisiin kolmiulotteisiin koordinaatteihin ja sen kuvaaman pinnan ominaisuuksiin, kuten väriin, heijastuvuuteen ja normaalivektoreihin. Näihin pinnan ominaisuuksiin viitataan usein termillä materiaali. Yleensä sävytyksessä otetaan huomioon myös joitain yksityiskohtia kolmion ympäriltä, kuten ympäristössä olevien valojen koordinaatit ja kirkkaudet. Nämä tiedot voidaan antaa yhtenäismuuttujina sävytysohjelmalle, samoin kuin kameran tiedot annetaan verteksiohjelmalle. Kolmion tietoihin ja ympäristöä kuvaaviin yhtenäismuuttujiin perustuen voidaan lopulta laskea, minkä väristä ja kuinka kirkasta valoa pinta heijastaa kohti kameraa, josta saadaan pikselin lopullinen väri.

Tässä luvussa käytetyn esimerkkiympäristön sävytyksen lopullinen tulos näkyy kuvassa 2.5. Vaikka tämän luvun aikana on esitelty kuvia eri vaiheista, on tärkeää muistaa, että vastaavia kuvia ei ole varsinaisesti olemassa näytönohjaimen muistissa missään vaiheessa. Kaikki yllämainittu laskenta tapahtuu rinnakkain, joten ainoat näytönohjaimen päämuistissa olevat tiedot ovat kolmiot joista lähdetään, ja näytölle lähetettävä ruutupuskuri.

Kuva 2.5: Hahmontamisen lopputulos esimerkkiympäristölle. Luotu Blender-mallinnusohjelmiston Eevee-hahmontajalla.

2.2 Reunojen aliasointi

Edellisen osion lopussa esitellyssä kuvassa on kuitenkin vielä yksi merkittävä ominaisuus, jota ei ole käsitelty. Rasterisaatiolla ei aina onnistuta luomaan aivan tarkkaa kuvaa annetuista kolmioista, koska kolmioiden reunat usein kulkevat pikselin sisällä. Ongelman näkee kun vertailee kolmioiden pysty- ja vaakasuuntaisia reunoja viistottaisiin reunoihin: pysty- ja vaakasuuntaiset reunat menevät pikseleiden kanssa yhdensuuntaisesti, jolloin kolmion muoto pysyy, mutta viistottaiset reunat jakavat jokaisen pikselin kahteen, jolloin pikselit muodostavat silmään pistävän ‘‘portaikon,’’ joka ei vastaa kolmion suoraa reunaa, kuten kuvassa 2.6 näkyy.

Kuva 2.6: Kuvassa näkyy aliasointia erityisesti kuution kirkkaasti valaistun kolmion ja varjossa olevan kolmion reunalla.

Tätä ongelmaa kutsutaan aliasoinniksi (eng. aliasing), ja sen estämistä antialiasoinniksi (eng. anti-aliasing), josta on esimerkki kuvassa 2.7. Edellisen osan päättänyt kuva 2.5 on myös antialiasoitu, joskin siinä on niin suuri resoluutio, että aliasointia ei välttämättä huomaisikaan. Crow’n artikkelissa [7] aliasoinnista ja sen estämisestä on esitelty kolme ehdotusta ongelman välttämiseksi:

  1. Resoluution nostaminen. Tämä on kuitenkin laskennallisesti hyvin kuormittavaa, koska sävytettävien pikselien määrä nousee. Tämä ei myöskään auta tilanteessa, jossa aliasointia ilmentyy suurimmalla resoluutiolla jota näyttö voi esittää.
  2. Kuvan pehmentäminen (eng. blurring) kokonaisuudessaan, ja reunoihin keskittyvät pehmennysalgoritmit. Nämä metodit kuitenkin saattavat peittää yksityiskohtia, ja yleisesti vähentää kuvan terävyyttä. Tälle alueelle sijoittuu ns. hahmontamisen jälkeiset antialiasointimenetelmät, kuten FXAA, fast approximate anti-aliasing [15], ja SMAA, subpixel morphological anti-aliasing [12]. Nämä ovat usein käytännöllisiä ottaa käyttöön riippumatta muun hahmontamisprosessin ominaisuuksista, koska algoritmi muokkaa lopullista kuvaa, joten kummatkin ovat yleisessä käytössä.
  3. Pikseleiden käsittely neliön muotoisina alueina, eikä yksittäisinä pisteinä. Pikselin väriksi siis määritellään sen sisältämien kolmioiden värien keskiarvo. Analyyttista lähestymistapaa on tutkittu esimerkiksi Catmullin artikkelissa [6], mutta se hidastuu nopeasti kolmioiden määrän noustessa. Numeerinen ratkaisu on usein käytännöllisempi, ja jo muutamalla näytteellä eri kohdista pikselin alueelta saadaan usein hyvä approksimaatio. Korkeammilla resoluutioilla ylimääräisten näytteiden ottaminen jokaiselle pikselille tulee kuitenkin nopeasti liian laskennallisesti raskaaksi. Käytännössä tähän antialiasointikategoriaan kuuluvat metodit ovat siis keskittyneet ottamaan mahdollisimman vähän näytteitä pikseliä kohti, mutta kuitenkin tarpeeksi että aliasoinnilta vältyttäisiin. Kaksi merkittävää lähestymistapaa tähän ovat MSAA [14], jossa otetaan useampia näytteitä vain kolmioiden reunoilta, ja TAA [19], jossa kierrätetään historiallisia näytteitä.
Kuva 2.7: Blender-mallinnusohjelmiston Eevee-hahmontajalla piirretyt kuvat, oikealla antialiasointi on päällä oletusarvojen mukaisesti. Kuvilla on yhtä suuri resoluutio.

MSAA, multi-sample anti-aliasing, on antialiasointimenetelmä joka vaatii pienen muutoksen rasterointiprosessiin: sävytettävä kolmio tarkistetaan useammasta pikselin sisäisestä pisteestä, jonka jälkeen voidaan suorittaa sävytysohjelma jokaiselle pikselin koskemalle kolmiolle erikseen, ja tämän jälkeen laskea sävytettyjen värien painotettu keskiarvo. Jos kaikki näytteet osuvat samaan kolmioon, sävytysohjelma tarvitsee suorittaa vain kerran.

MSAA siis ottaa enemmän näytteitä tarkkuuden vuoksi, mutta vain kolmioiden reunoilla, jotka ovat usein selkeiten aliasoiva kohta. Koska MSAA vaatii muutoksen rasterointiprosessiin, se on määritelty grafiikkaohjelmointirajapinnoille, ja näytönohjaimet on rakennettu vastaamaan sitä. Esimerkiksi OpenGL:n tapauksessa MSAA otetaan käyttöön ARB_multisample-laajennuksella [14].

TAA, temporal anti-aliasing, perustuu samaan konseptiin useammasta pikselin sisäisestä näyttestä kuin MSAA, mutta siinä näytteitä otetaan vain yksi jokaista hahmonnettua pikseliä kohden. Yang, Liu ja Salvi vertailevat erilaisia toteutuksia artikkelissaan [19], mutta ne kaikki pohjaavat samaan perusideaan. Algoritmi pohjautuu siihen, että jokaisessa kuvassa otetaan näyte hieman eri kohdasta jokaisen pikselin kohdalla, yhdistetään piirrettävän kuvan sekä edellisen kuvan painotettu näyte, ja tallennetaan tulos seuraavaa kuvaa varten. Kun näytteitä otetaan aina hieman eri kohdasta pikselin sisällä, ja yhdistetään edellisten painotettuun keskiarvoon, väri lähestyy ajan kanssa haluttua väriä.

TAA:in huono puoli tulee liikkuvista elementeistä, sillä mikäli kuvattu objekti liikkuu, sen alueella olevat pikselit eivät enää sovi algoritmille lisä-näytteiksi niiden pikselien osalta. Verrattuna MSAA:han, TAA parantaa myös kolmioiden sisäistä aliasointia, koska useampia näytteitä otetaan jokaiselle pikselille, ei vain sellaisille joihin vaikuttaa useampi kolmio.

2.3 Takaperin hahmontaminen ja ylipiirtäminen

Edellä kuvailtua prosessia kutsutaan etusuuntaiseksi hahmontamiseksi (eng. forward rendering), koska siinä aloitetaan ympäristön tiedoista, niiden pohjalta lasketaan pikselit jotka halutaan sävyttää, ja värit lasketaan kolmioiden määrittämässä järjestyksessä riippumatta siitä, missä osassa ruutua väritettävä pikseli on. Prosessissa siis siirrytään tunnetuista parametreista haluttuun tulokseen, eli kolmioista pikseleihin, ‘‘etusuuntaisesti.’’

Takaperin hahmontaminen toimii päinvastoin: lähdetään pikseleistä, ja lasketaan ympäristön tietojen pohjalta siihen pikseliin kuuluva väri, eli kuljetaan pikseleistä kolmioihin, ‘‘takaperin.’’ Esimerkki tästä olisi kokonaan säteenseurantaan (eng. raytracing) pohjautuva hahmontaja, joka ‘‘seuraisi sädettä’’ jokaisen pikselin kohdalta kamerasta ympäristöön, ja laskisi sen pohjalta pikselin värin.

Etusuuntainen hahmontaminen on kuitenkin huomattavasti suoraviivaisempi ongelma ratkaista yksinkertaisella aritmetiikalla. Tämä laskennallinen tehokkuus on todennäköinen syy reaaliaikaisen kolmiulotteisen grafiikan pysymiseen rasterisaatiopohjaisena tähän päivään asti.

Etusuuntaisella hahmontamisella on kuitenkin huonot puolensa: kun sävytysohjelmat monimutkaistuvat, hahmontamisen laskennallinen taakka nousee nopeasti. Otetaan esimerkiksi sävytysohjelma, joka on ohjelmoitu ottamaan huomioon paljon valoja ympäristössä. Jos sävytysohjelma laskee kaikkien valojen vaikutuksen pikselin väriin, sävytysohjelman aikavaativuus on suoraan verrannollinen valojen määrään.

Tästä päästään etusuuntaisen hahmontamisen ensimmäiseen heikkouteen: ylipiirtämiseen (eng. overdraw), jota Akenine-Möller et al. käsittelevät kirjassaan [1, s. 801–802]. Ylipiirtäminen viittaa tuhlattuun laskentaan, joka tapahtuu kun sävytysohjelmaa ajetaan kolmioille, joiden päälle myöhemmin sävytetään toinen kolmio. Jos sävytysohjelma on jo valmiiksi laskennallisesti raskas ajaa, sen ajaminen mahdollisesti moninkertaiselle määrälle pikseleitä — jotka eivät edes vaikuta lopputulokseen — tulee olemaan vielä raskaampaa. Hahmontamisen taakka tulee siis lopulta kasvamaan suhteessa valojen määrään, kerrottuna ylipiirtämisen aiheuttamalla kertoimella. Tämä on erityisen vaikea yhdistelmä, kun sekä valojen että kolmioiden määrät ovat tekijöitä, joiden rajoittaminen vaikuttaa suoraan hahmonnettavien ympäristöjen visuaaliseen ilmeeseen.

Ylipiirtämisen hintaa voi kuitenkin keventää jakamalla hahmontamisen useampiin hahmontamiskierroksiin, joista ensimmäisellä kerralla luotua syvyyspuskuria (eng. depth buffer) kierrätetään seuraavien kierroksien aikana, kuten Akenine-Möller et al. kuvailevat kirjassaan [1, s. 881–882]. Syvyyspuskuri sisältää jokaisen pikselin etäisyyden kamerasta, jonka avulla seuraavat hahmontamiskierrokset voivat hypätä taakse jäävien pikselien sävytyksen yli vertaamalla käsiteltävän pikselin syvyyttä syvyyspuskurissa olevaan. Useammissa hahmontamiskierroksissa kuitenkin nousee ongelmaksi ylimääräinen kolmioiden prosessointi: kolmiot on rasteroitava monta kertaa, jotta pystytään toistamaan sävytys-askel erilaisilla sävytysohjelmalla tai perustuen aiemmin hahmonnettuihin puskureihin.

Ylipiirtäminen ja ylimääräinen kolmioiden prosessointi ovat siis merkittäviä ongelmia, jotka nousevat rasterisaation ja sävytyksen yhteydestä toisiinsa. Huomataan kuitenkin, että rasterisaation tulos on usein sama: ympäristön kolmiot ja kamera eivät muutu kesken hahmontamisen. Olisi siis huomattavasti tehokkaampaa, jos voitaisiin jotenkin jakaa rasterisaation tulos useamman sävytyskierroksen välillä. Jotta rasterisaation tulos voitaisiin jakaa useamman sävytyksen välillä, rasterisaatio pitäisi pystyä tekemään erikseen, ja sävytys pitäisi pystyä tekemään ilman rasterisaatiota. Seuraavissa luvuissa tutkitaan erilaisia lähestymistapoja, joilla tämä voidaan toteuttaa.

3 Viivästetty hahmontaminen

Viivästetty hahmontaminen (eng. deferred rendering) on hahmontamismenetelmä, joka nousi suosioon 2010–luvun alussa, ja on pysynyt laajassa käytössä aina nykypäivään asti. Viivästetyssä hahmontamisessa hahmontamisprosessi jaetaan kahteen vaiheeseen: ensimmäisessä vaiheessa laskennallinen kuorma keskittyy rasterisaatioon, toisessa sävytykseen. Menetelmän on esitellyt mm. Akenine-Möller et al. kirjassaan Real-Time Rendering [1, s. 883–888], ja Sellers, Wright ja Haemel kirjassaan OpenGL SuperBible [17, s. 548–558].

Viivästetyssä hahmontamisessa piirretään aluksi ympäristö muuten samaan tapaan kuin etusuuntaisessa, paitsi että siinä ei oteta valoja vielä huomioon, ja ruutupuskurin sijaan sävytysohjelma tallentaa G-puskuriin (eng. GBuffer). Puskuriin tallennetaan tietoja sävytettävästä kohdasta, kuten sen kolmiulotteinen paikkakoordinaatti, normaalivektorit ja materiaalitiedot. Kuvassa 3.1 nähdään, miten puskureiden sisältö vastaa lopullista ruutupuskuria: jokaisessa koordinaatissa olevan pikselin takana oleva kolmio on sama, tallennetun tiedon merkitys eri.

G-puskurin hahmontamisen jälkeen hahmontamisprosessi toistetaan jokaiselle valolle niin, että sävytysohjelma ajetaan vain kerran jokaiselle pikselille, ja se muokataan käyttämään G-puskurin tietoja alkuperäisten kolmioiden sijaan. Koska G-puskuriin on tallennettu kaikki tarvittu kolmiokohtainen tieto jokaiselle pikselille, valon vaikutus jokaiseen pikseliin voidaan nyt laskea suoraan sen perusteella, ilman että alkuperäisiä kolmioita tarvitsee rasterisoida uudelleen.

Kuva 3.1: Pintojen perusvärit ja normaalivektorit tallennetaan yleisesti G-puskureihin. Normaalivektorit eivät kuvaa minkään tietyn asian väriä, vaan punaisen, sinisen ja vihreän värin arvoihin sijoitetaan normaalivektoreiden x-, y- ja z-komponentit.

Viivästetty hahmontaminen on laskennallisesti tehokkaampaa kuin etusuuntainen hahmontaminen, koska ympäristön koostavat kolmiot täytyy rasteroida vain kerran, riippumatta siitä kuinka monta sävytyskierrosta tehdään valojen laskemiseksi. Ylipiirtäminen ei myöskään haittaa yhtä paljon, koska suurin osa sävytysohjelmien laskennasta tapahtuu jälkimmäisillä sävytyskierroksilla, joilla ylipiirtämistä ei tapahdu ollenkaan. Viivästetty hahmontaminen on siis suhteellisen suoraviivainen tapa välttää edellisessä luvussa esitellyt tehokkuusongelmat, ja sen keskeinen idea on jakaa ympäristön kolmioiden rasterointi ja valojen sävytys eri hahmontamisaskeliin, jolloin ne eivät hidasta toisiaan.

Kolmiot Verteksiohjelma Kolmioiden rasterointi Sävytysohjelma G-puskuri G-puskuri Sävytysohjelma Pikselit ruudulle
Kuva 3.2: Viivästetyn hahmontamisen kaksi vaihetta ja tiedon kulku niiden välillä. Ensimmäinen sävytysohjelma oikealla on muistiliikennepainotteinen, toinen on laskentapainotteinen. Teknisesti myös toista sävytysohjelmaa edeltää verteksiohjelma ja rasterointi, mutta niiden aikavaativuus on vakio: tarkoituksena on vain päästä sävyttämään jokainen pikseli yhden kerran.

Viivästetyssä hahmontamisessa on kuitenkin myös huonot puolensa. Ympäristön kolmioille ajettavan sävytysohjelman tallentamat tiedot pitää tallentaa jokaiselle pikselille, joten muistia tarvitaan paljon. Esimerkiksi Garawanyn esitelmässä [9] Uncharted 4:n valaisumenetelmistä esitellään 64-bittisiä G-puskureita, joita kolmion ominaisuuksista riippuen tarvitaan 2 tai 3, eli 128–196 bittiä pikseliä kohti. Tämä on merkittävä määrä, esimerkiksi verrattuna ruutupuskurille yleiseen 24 bittiin pikseliä kohti. Tämä johtaa suureen määrään varattua muistia sekä tiedonsiirtoa, jota ei nähdä ollenkaan etusuuntaisessa hahmontamisessa.

Lisäksi, koska lopullisen värin sävytyksessä käytetään kuvatusta ympäristöstä riippumattomia kolmioita, viivästetty hahmontaminen ei yleisesti voi hyödyntää MSAA:ta suoraviivaisesti. Aikaisissa versioissa menetelmästä — kuten Engelin [8] esittelemässä — tehtiin vielä viimeinen sävytyskierros varsinaisilla ympäristön kolmioilla, jolloin valojen vaikutus saatiin laskettua tehokkaammin, ja lopullista kuvaa varten saatiin MSAA käyttöön. Viivästetyssä hahmontamisessa kuitenkin jokainen ylimääräinen rasterisaatiokierros on merkittävä hidaste: kaksi rasterisaatiokierrosta verrattuna yhteen johtaa maksimaalisen kolmiomäärän puolittumiseen.

Kuten Lei Yang, Shiqiu Liu ja Marco Salvi kertovat artikkelissaan [19], TAA:ista onkin tullut tyypillisempi valinta viivästetyn hahmontamisen yhteydessä. TAA sopii hyvin viivästetylle hahmontamiselle, koska se on periaatteeltaan samankaltainen kuin MSAA, mutta se ei tarvitse erillistä tukea rasterisaation yhteydessä, joten sen kanssa riittää tehdä yksi rasterisaatiopainotteinen hahmontamiskierros. Myös edellämainittu Uncharted 4 [18] käyttää TAA-menetelmää antialiasointiin.

Lopulta, viivästetty hahmontaminen ei käsittele läpinäkyviä kolmioita ollenkaan: lopullisen värin sävytysvaiheessa tiedetään vain kaikkein lähimpänä olevasta kolmiosta, jonka tiedot tallennettiin G-puskuriin. Läpinäkyvät kolmiot pitää siis hahmontaa kaiken muun jälkeen etusuuntaisesti.

4 Näkyvyys-pohjainen hahmontaminen

Vuonna 2013 Burns ja Hunt esittelivät näkyvyyspuskurin (eng. visibility buffer) artikkelissaan The Visibility Buffer: A Cache-Friendly Approach to Deferred Shading [5]. Näkyvyyspuskuri on variaatio viivästetyn hahmontamisen G-puskurista, joka käyttää huomattavasti vähemmän muistia, mutta maksaa siitä suuremman laskentakuorman muodossa.

Näkyvyyspuskuri ei sisällä kolmioiden tietoja kuten G-puskuri, vaan siihen tallennetaan sävytettävään kolmioon viittaava indeksi, kuten kuvassa 4.1 on visualisoitu. Tämän jälkeen luodaan erillinen lista kolmioista joihin näkyvyyspuskurissa viitataan, joka annetaan yhtenäismuuttujana seuraaville sävytysohjelmille. Lopullisen värin laskevissa sävytysohjelmissa haetaan kolmion tiedot yhtenäismuuttujana annetusta kolmiopuskurista, perustuen näkyvyyspuskurissa olevaan indeksiin.

Perinteisesti sävytysohjelma saa kolmion tiedot valmiiksi interpoloituna näytönohjaimelta: esimerkiksi pikselin koordinaatti kolmiulotteisessa avaruudessa perustuu verteksiohjelman määrittämiin kärkipisteisiin. Näkyvyyspuskurin kanssa tämä pitää tehdä manuaalisesti sävytysohjelmassa, joka nostaa hieman laskennallista taakkaa, mutta Burnsin ja Huntin [5] mukaan tämä ei ole merkittävä hidaste.

Kuva 4.1: Esimerkki näkyvyyspuskurista. Kuten normaalivektoreita tallentavien G-puskurien tapauksessa, pikseliin tallennettava tieto ei kuvaa mitään varsinaista väriä. Näkyvyyspuskurin keskeinen ominaisuus on, että pikseliin tallennettu arvo on — tai siitä on selvitettävissä — pikselin kohdalla näkyvän kolmion indeksi yhtenäismuuttujana annettavaan kolmiopuskuriin.
Valmiiksi muunnetut ympäristön kolmiot Verteksiohjelma Kolmioiden rasterointi Sävytysohjelma Näkyvyyspuskuri Sävytysohjelma Pikselit ruudulle
Kuva 4.2: Näkyvyys-pohjaisen hahmontamisen kaksi vaihetta. Työnjako on samankaltainen kuin viivästetyssä hahmontamisessa, mutta muistiliikenne jakautuu enemmän ensimmäisen ja toisen sävytysohjelman välille.

Näkyvyyspuskurin vaatima yhtenäismuuttujana annettava lista lopullisista kolmioista aiheuttaa kuitenkin jonkin verran ongelmia, jotka voivat selittää sen suhteellisen vähäisen suosion viime vuosiin asti. Normaalisti verteksiohjelmassa muunnetaan kolmioita sävytystä varten ilman, että niitä tarvitsee tallentaa mihinkään puskuriin. Esimerkkinä tästä on projektiomatriisilla tehty projektio-operaatio, mutta myös kolmiomallien animaatiot toteutetaan usein tässä vaiheessa. Koska näkyvyyspuskuri vaatii listan kolmioista lopullisessa muodossaan, nämä muunnokset pitää tehdä erikseen ja tallentaa jonkinlaiseen puskuriin, johon lopulliset sävytysohjelmat voivat viitata. Toinen vaihtoehto on muuntaa verteksit sävytysohjelmassa, mutta vierekkäiset pikselit viittaavat usein samaan kolmioon, joten sävytysohjelmassa toistettaisiin paljon laskentaa turhaan.

On myös huomioitava, että alkuperäisessä artikkelissa [5] esitellyt hyödyt ilmenivät erityisesti alustoilla, joilla on erityisen rajattu kaistanleveys suhteessa laskennalliseen tehokkuuteen. On siis täysin mahdollista, että näkyvyyspuskuri ei yksinkertaisesti parantanut laskentatehokkuutta artikkelin julkaisun jälkeen yleistyneillä alustoilla.

Brian Karis, Rune Stubbe ja Graham Wihlidal käsittelevät näkyvyyspuskurin hyötyjä uudemmasta perspektiivistä esitelmässään Nanite-hahmontajasta [13], jonka motivaationa on mahdollistaa erittäin suurien kolmiomäärien hahmontaminen reaaliajassa. Esitelmässä kerrotaan, että näkyvyyden erottaminen materiaaleihin liittyvästä laskennasta on tärkeä osa Naniten arkkitehtuuria, koska halutaan minimoida ylipiirtämisen ja pikselineliöiden (eng. pixel quad) aiheuttama turha laskenta.

Pikselineliö viittaa neljästä vierekkäisestä pikselistä koostuvaan ryhmään, jonka sisältämät pikselit lasketaan usein samanaikaisesti. Kun kolmioita on useampi kuin yksi pikselineliötä kohti, jokaiselle kolmiolle lasketaan joka tapauksessa kaikki pikselineliön sisältämät neljä pikseliä, vaikka kolmiot olisivat vain yhden pikselin kokoisia. Kun kolmioita on saman verran näkyvillä kuin pikseleitä, pikselineliöt käytännössä nelinkertaistavat laskentakuorman ilman minkäänlaista hyötyä.

Nanite-hahmontaja kuitenkin käyttää näkyvyyspuskuria vain rasterisaation tehostamiseksi: näkyvyyspuskurin pohjalta luodaan toisessa sävytyskierroksessa G-puskuri, ja itse värin laskevat sävytyskierrokset toimivat samoin kuin viivästetyssä hahmontamisessa tämän jälkeen. Esitelmässä mainitaan, että G-puskurilla on vielä hyötynsä näkyvyyspuskurin kanssa, mutta sen tehokkuudesta suhteessa pelkkään näkyvyyspuskuriin ei oteta kantaa.

5 Tekstuuriavarudessa hahmontaminen

Tekstuuriavaruudessa hahmontaminen (eng. texture-space rendering) ja tekselisävyttäminen (eng. texel shading), viittaavat hahmontamismenetelmään, jossa sävytys tehdään ennen rasterisaatiota. Tämä saadaan aikaan sävyttämällä kaikki ympäristössä olevat pinnat valmiiksi tekstuureihin, joista haetaan valmiiksi sävytetty väri varsinaisen rasterisaation yhteydessä. Menetelmä ei ole laajassa käytössä, mutta se on esimerkki hyvin erilaisesta lähestymistavasta sävytyksen ja rasterisaation erotteluun. Variaatioita tekstuuriavaruudessa hahmontamisesta esittelevät Akenine-Möller et al. kirjassaan [1, s. 908–913], Hillesland ja Yang paperissaan [10] ja Baker esitelmässään [3].

Tekstuurilla (eng. texture) viitataan näytönohjaimen muistissa olevaan kuvaan, josta voidaan hakea pikseleiden värejä sävytysohjelman aikana. Yleisesti tekstuureja käytetään pintojen materiaalien määrittelyyn tarkemmin kuin mitä kolmioilla voidaan järkevästi esittää. Esimerkiksi kuvassa 2.5 olevan laatikon sivut koostuvat vain kahdesta kolmiosta, mutta sen pinnassa on silti yksityiskohtainen kuvio. Tämä on saatu aikaan tekstuureilla: kolmioiden vertekseihin on tallennettu UV-koordinaatit, jotka kertovat, mikä osa tekstuurista pitäisi näkyä kolmion alueella. Sävytysohjelmassa voidaan hakea tekstuurin väri UV-koordinaattien määrittämästä kohdasta, ja käyttää sitä pinnan värinä, kuten kuvassa 5.1 esitellään. Tekstuurit ovat tehokas tapa lisätä helposti muokattavia yksityiskohtia kolmioihin, jotka olisivat muuten yksivärisiä tai kokonaan algoritmisesti väritettyjä.

Kuva 5.1: Vasemmalla on kolmio, jonka pikseleitä sävytetään. Keskellä näkyy, mihin tämän kolmion vertekseihin tallennetut UV-koordinaatit viittaavat tekstuurissa. Oikealla olevassa kuvassa kolmio on sävytetty, ja nähdään miten UV-koordinaattien määrittelemä osa tekstuurista päätyy sävytettävän kolmion alueelle.
Valojen tiedot Kolmioiden tiedot Sävytysohjelma Sävytystekstuuri Ympäristön kolmiot Verteksiohjelma Kolmioiden rasterointi Sävytysohjelma Pikselit ruudulle
Kuva 5.2: Tekstuuriavaruudessa hahmontamisen eri vaiheet. Vasemmalla on itse pintojen värit laskeva osa, ja sen sävytysohjelmaan kuluu suurin osa laskennasta. Oikealla oleva sävytysohjelma vain hakee värin sävytystekstuurista. Valojen tiedot annetaan edellisten menetelmien tapaan yhtenäismuuttujana. Kolmioiden tiedot annetaan erillisessä puskurissa G-puskurin ja näkyvyyspuskurin tapaan.

Tekstuuriavaruudessa hahmontamisessa sävytys tehdään omana vaiheenaan, ennen rasterointia kameran perspektiivistä. Sävytysohjelma ajetaan suurelle tekstuurille, jossa on omat alueet kaikille ympäristössä näkyville kolmioille, johon tullaan seuraavaksi viittaamaan sävytystekstuurina. Tekstuurin jakamismenetelmä vaihtelee, ja siinä voidaan laskentatehon säästämiseksi ottaa huomioon esimerkiksi kolmion näkyvyys ja etäisyys kamerasta.

Samaan tapaan kuin viivästetyn hahmontamisen valotusaskeleessa, kolmioiden tiedot eivät ole saatavilla suoraan verteksiohjelmasta, koska tässä yhteydessä ei rasteroida ympäristön kolmioita. Kolmioiden tiedot siis haetaan G-puskurin ja näkyvyyspuskurin kaltaisesta erillisestä puskurista, johon ne on laskettu etukäteen. Tekstuuriavaruudessa hahmontamisessa kolmioiden tiedot tai indeksit sisältävä puskuri ei kuitenkaan vastaa ruutupuskuria, vaan sävytystekstuuria, eli kolmioiden tiedot sisältävässä puskurissa on yksi alkio jokaista sävytystekstuurin pikseliä kohden.

Sävytysohjelma toimii kuten viivästetyn hahmontamisen valottamisvaiheen sävytysohjelma, eli kolmion tiedot haetaan suoraan puskurista, ja väri lasketaan perustuen kolmion ja ympäristön tietoihin. Toisin kuin viivästetyssä hahmontamisessa, väri tallennetaan ruutupuskurin sijaan sävytystekstuuriin. Sävytystekstuuriin siis värittyy jokaiselle kolmiolle valmiiksi sävytetyt pikselit niiden UV-koordinaattien määrittelemille alueille.

Tämän jälkeen kuva hahmonnetaan normaalisti, rasteroiden ympäristön kolmiot kameran perspektiivistä. Tämän jälkimmäisen vaiheen sävytysohjelmassa haetaan valmis väri sävytystekstuurista UV-koordinaattien määrittämästä kohdasta. Varsinainen sävytys siis tapahtuu ennen rasterisaatiota, ja rasterisaatiovaiheessa vain haetaan esiaskeleessa laskettu väri, kuten kuvassa 5.2 nähdään.

Koska rasterisaatiovaihe on merkittävän nopea, korkeat resoluutiot ja MSAA monilla näytteillä sopivat hyvin tähän menetelmään. Baker huomioi myös esitelmässään [3], että sävytysaskeleen voi suorittaa harvemmin kuin rasterisaatioaskeleen, koska sävytyksen tulos ei merkittävästi muutu muutaman peräkkäisen kuvan välillä. Tekstuuriavaruudessa hahmontamisen laskennallista kuormaa on siis helppo keventää sävyttämällä harvemmin, ja sävytystekstuurin resoluutiota voidaan jossain määrin pienentää, säilyttäen silti lopullisen rasteroidun kuvan resoluution. Sävytystekstuurin resoluution pienentäminen toki vaikuttaa kuvan laatuun, ja harvemmin sävyttäminen voi heikentää liikkuvan kuvan illuusiota, kun kamera liikkuu merkittävästi.

Verrattuna muihin tässä tutkielmassa käsiteltyihin menetelmiin, tekstuuriavaruudessa hahmontaminen jakaa sävyttämisen ja rasterisaation eniten erilleen, mutta vaatii myös kaikkein eniten ylimääräistä laskentaa menetelmän mahdollistamiseksi. Tätä erillisyyttä alleviivaa edellä mainitut mahdollisuudet sävyttää eri tahdissa ja vaihtelevilla resoluutioilla, vaikuttamatta varsinaisen ruudulle rasteroitavan kuvan virkistystaajuuteen tai resoluutioon.

Esimerkiksi virtuaalitodellisuudessa on tärkeää, että ruudulle saadaan uusi kuva tasaisesti ja pienellä latenssilla, joten jonkinlainen variaatio tekstuuriavaruudessa hahmontamisesta voisi sopia tähän käyttötapaukseen. Baker toisaalta mainitsee esitelmässään [3], että erityisesti virtuaalitodellisuuden tapauksessa sävytysaskel kannattaa suorittaa mahdollisimman usein, koska liikkuvan kuvan illuusion säilyttäminen on erityisen tärkeää virtuaalitodellisuudessa. Virtuaalitodellisuuden tapauksessa tehostus siis rajoittuu sävytystekstuurin resoluution pienentämiseen.

Tekstuuriavaruudessa hahmontamisessa pintojen värien sävytyksen vaatima laskentateho kuitenkin yleisesti nousee verrattuna muihin hahmontamismenetelmiin, johtuen rasterisaation hyötyjen puutteesta. Rasterisaatio säästää kameran ulkopuolelle jäävien, kamerasta pois päin osoittavien ja joissain määrin myös muiden kolmioiden taakse jäävien pintojen sävyttämisen. Koska tekstuuriavaruudessa hahmontamisessa ei tehdä kameraan pohjautuvaa rasterisaatioaskelta sävytyksen yhteydessä, joudutaan sävyttämään myös nämä piilossa olevat pikselit. Eri toteutukset keventävät taakkaa eri tavoin, mutta tämä tehokkuusongelma on todennäköisesti merkittävä syy tekstuuriavaruudessa hahmontamisen vähäiselle käytölle reaaliaikaisessa kolmiohahmontamisessa.

6 Yhteenveto

Tässä tutkielmassa on esitelty reaaliaikaisen kolmiohahmontamisen eri vaiheet, ja kolme eri menetelmää erottaa rasterisaatio ja sävytys toisistaan. On myös vertailtu niiden hyötyjä ja haittoja, liittyen niiden suhteellisiin tehokkuuksiin erilaisissa tilanteissa.

Joissain määrin viivästynyt hahmontaminen on korvannut perinteisen etusuuntaisen hahmontamisen, ja näkyvyyspuskuri — mahdollisesti G-puskurin kanssa — saattaa tulla korvaamaan pelkän G-puskurin, kun kolmiomalleja aletaan luomaan yksityiskohtaisemmiksi ja kolmiotiheydet suhteessa resoluutioon nousevat. Näitä eri hahmontamismenetelmiä voisi siis kuvailla eri vaiheina reaaliaikaisen kolmiohahmontamisen kehityksessä. Tehostamisen ehdot ovat kuitenkin muuttuneet erilaisten teknologioiden noustessa suosioon: esimerkiksi virtuaalitodellisuutta varten tehdyissä ohjelmissa on siirrytty laajalti pois minkään muotoisesta viivästetystä hahmontamisesta, koska korkeat resoluutiot ja MSAA ovat erityisen tärkeitä virtuaalilasien näyttämän kuvan laatuun, ja nämä kaksi ominaisuutta eivät toimi hyvin viivästetyn hahmontamisen kanssa. Vastaavasti tekstuuriavaruudessa hahmontamisen voisi nähdä näin yleiskatsauksen pohjalta sopivan virtuaalitodellisuuteen, mutta menetelmä ei ole nähnyt laajaa käyttöä tästä huolimatta.

Toisaalta esimerkiksi viimeaikaiset kehitykset näytönohjaimien kiihdyttämässä säteenseurannassa — kuten NVIDIA:n RTX-näytönohjaimissa [4] — ovat tuoneet säteenseurannan muotiin, mutta rajatuilla resoluutioilla. Mahdollisesti säteenseurannan innottamana, viime vuosina on kehitetty hahmontamisen jälkeisiä kuvansuurennusalgoritmeja kuten DLSS [16] ja FSR [2]. Pienempien resoluutioiden mukana myös erilaiset viivästetyt hahmontamismenetelmät muuttuvat jälleen hyvin tehokkaaksi vaihtoehdoksi, kun G-puskurin muistivaatimukset pienenevät. Säteenseuranta on myös vahvasti riippuvainen rasterisaation ja sävytyksen erottamisesta: kun laskentateho juuri riittää muutaman säteen laskemiseksi jokaista pikseliä kohti, ylipiirtämiseen ei kannata tuhlata yhtään säteenseurantalaskentaa.

Yksi perspektiivi reaaliaikaisen kolmiohahmontamisen kehityksessä on myös siirtymä etusuuntaisesta takaperin hahmontamiseen: vanhemmat menetelmät toimivat etusuuntaisesti sen yksinkertaisuuden ja kiihdyttämismahdollisuuksien vuoksi, mutta ajan kanssa on lähestytty takaperin hahmontamista. Rasterisaation ja sävytyksen erottamisen voi nähdä tietynlaisena kompromissina, jossa rasteroimalla haetaan valmiiksi tiedot, joita takaperin toimiva sävytysohjelma voi hyödyntää. Säteenseurantaprosessorien yleistyminen taas suoraan vie tarvetta rasteroinnille, ja tästä näkyykin jo esimerkki varjojen tapauksessa: säteenseurantaan pohjautuvat varjot ovat uusimmissa hahmontajissa korvaamassa perinteisemmät rasteroituihin varjokarttoihin pohjautuvat varjot.

Tässä kirjallisuuskatsauksessa on siis selvitetty, että rasterisaatio ja sävytys ovat kaksi merkittävää osaa reaaliaikaisen kolmiohahmontamisen arkkitehtuurissa, joiden liitännäisyys toisiinsa on keskeinen osa tätä arkkitehtuuria. Niiden erottamiseen on kuvailtu kolme erilaista lähestymistapaa, jotka tekevät vaihtelevia kompromisseja muistin käytön ja sävytyslaskennan tehostamisen välillä. On myös huomattu, että jotkut näistä kompromisseista sopivat eri käyttötapauksiin paremmin kuin toiset, joten perusteltua yleistä paremmuusjärjestystä ei pystytä luomaan.

Lähteet

  1. T. Akenine-Möller, E. Haines, N. Hoffman, A. Pesce, M. Iwanicki ja S. Hillaire. Real-Time Rendering 4th Edition. Boca Raton, FL, USA: A K Peters/CRC Press, 2018. ISBN: 978-1-13862-700-0.
  2. AMD. AMD FidelityFX Super Resolution. 2021. URL: https://gpuopen.com/fidelityfx-superresolution/ (viitattu 24.10.2021).
  3. D. Baker. ”Object Space Lighting”. Game Developers Conference (2016). URL: https://oxidegames.com/wp-content/uploads/2016/03/Object-Space-Lighting-Rev-21.pdf (viitattu 13.12.2021).
  4. J. Burgess. ”RTX on—The NVIDIA Turing GPU”. IEEE Micro 40.2 (2020), s. 36–44. DOI: 10.1109/MM.2020.2971677.
  5. C. A. Burns ja W. A. Hunt. ”The Visibility Buffer: A Cache-Friendly Approach to Deferred Shading”. Journal of Computer Graphics Techniques (JCGT) 2.2 (2013), s. 55–69. ISSN: 2331-7418. URL: http://jcgt.org/published/0002/02/04/ (viitattu 24.10.2021).
  6. E. Catmull. ”A hidden-surface algorithm with anti-aliasing”. Teoksessa: Proceedings of the 5th Annual Conference on Computer Graphics and Interactive Techniques. SIGGRAPH ’78. ACM, 1978, s. 6–11. DOI: 10.1145/800248.807360.
  7. F. C. Crow. ”The Aliasing Problem in Computer-Generated Shaded Images”. Communications of the ACM 20.11 (1977), s. 799–805. ISSN: 0001-0782. DOI: 10.1145/359863.359869.
  8. W. Engel. ”The Light Pre-Pass Renderer: Renderer Design for Efficient Support of Multiple Lights”. Teoksessa: Advances in Real-Time Rendering in 3D Graphics and Games. SIGGRAPH ’09. ACM, 2009. DOI: 10.1145/1667239.1667243.
  9. R. E. Garawany. ”Deferred Lighting in Uncharted 4”. Teoksessa: Advances in Real-Time Rendering in Games. SIGGRAPH ’16. ACM, 2016. DOI: 10.1145/2897826.2940291.
  10. K. E. Hillesland ja J. C. Yang. ”Texel Shading”. Teoksessa: EG 2016 - Short Papers. The Eurographics Association, 2016. DOI: 10.2312/egsh.20161018.
  11. J. Holben. ”The Mandalorian: This Is the Way”. American Cinematographer (2020). URL: https://ascmag.com/articles/the-mandalorian (viitattu 24.10.2021).
  12. J. Jimenez, J. I. Echevarria, T. Sousa ja D. Gutierrez. ”SMAA: Enhanced Morphological Antialiasing”. Computer Graphics Forum 31.2 (2012). ISSN: 1467-8659. DOI: 10.1111/j.1467-8659.2012.03014.x.
  13. B. Karis, R. Stubbe ja G. Wihlidal. ”A Deep Dive into Nanite Virtualized Geometry”. Teoksessa: Advances in Real-Time Rendering in Games. SIGGRAPH ’21. ACM, 2021. URL: https://advances.realtimerendering.com/s2021/index.html (viitattu 24.10.2021).
  14. D. Kirkland, B. Armstrong, M. Gold, J. Leech ja P. Womack. ARB_multisample. Khronos Group, OpenGL ARB Extension #5. 2002. URL: https://www.khronos.org/registry/OpenGL/extensions/ARB/ARB_multisample.txt (viitattu 24.10.2021).
  15. T. Lottes. FXAA. Tekninen raportti. NVIDIA, 2011. URL: http://developer.download.nvidia.com/assets/gamedev/files/sdk/11/FXAA_WhitePaper.pdf (viitattu 24.10.2021).
  16. NVIDIA. NVIDIA DLSS 2.0: A Big Leap In AI Rendering. 2020. url: https://www.nvidia.com/en-us/geforce/news/nvidia-dlss-2-0-a-big-leap-in-ai-rendering/ (viitattu 24.10.2021).
  17. G. Sellers, Richard S. Wright, Jr. ja N. Haemel. OpenGL SuperBible Sixth Edition. Addison-Wesley, 2013. ISBN: 978-0-321-90294-8.
  18. K. Xu. ”Temporal Antialiasing in Uncharted 4”. Teoksessa: Advances in Real-Time Rendering in Games. SIGGRAPH ’16. ACM, 2016. DOI: 10.1145/2897826.2940291.
  19. L. Yang, S. Liu ja M. Salvi. ”A Survey of Temporal Antialiasing Techniques”. Computer Graphics Forum 39.2 (2020). ISSN: 1467-8659. DOI: 10.1111/cgf.14018.

Comments? Email! The email is blog dot hello at the same domain this blog is hosted at, minus the subdomain. Sorry about the subterfuge, gotta try and avoid the robots somehow. Also on the fediverse, @neon@fedi.neon.moe
Running the SteamOS Devkit Service on a regular Steam Deck tag:blog.neon.moe,2022-08-13:/2022/08/13/steam-deck-devification 2022-08-13T14:30:00+03:00 2022-08-13T14:30:00+03:00 Instructions for getting the SteamOS Devkit Service running on a non-devkit Steam Deck.

Running the SteamOS Devkit Service on a regular Steam Deck

Posted on 2022-08-13 by Jens Pitkänen

I got a Q1 Steam Deck, mostly for testing my own games on it, and making them work well. Finally, a stable target for Linux gaming!

Much to my surprise, the regular Steam Deck does not seem to have all the devkit services set up right away: I set my Deck to Developer Mode, installed the SteamOS Devkit Client on my main computer (as per the official instructions), but my Deck is nowhere to be seen! Now, I may have just missed something — and I’d definitely like to know if there was an easier way to do this — but I ended up installing the needed service manually, and set it up like I would a ‘‘hackendeck’’ Manjaro system. Since I didn’t find any guides for doing this with the Steam Deck specifically, I decided to write my own.

Installing the service

First, open Desktop Mode (press the Steam button, select Power, then Switch to Desktop) and then Firefox. Open this blog (or the Steamworks article, I found it by googling “How to load and run games on Steam Deck”), and open the direct install link, and it’ll install it via Steam.

Configuring it

Now the SteamOS Devkit Service can be found in your Steam Library, but it probably doesn’t launch yet. This is because the setup script checks if you’re running Manjaro, which the Steam Deck is not, and stops there. Now, let’s set it up so that it works:

  1. Open Desktop Mode, then Konsole via the start menu. Press Steam + X to open the keyboard.
  2. Move to the service directory: cd .steam/root/steamapps/common/SteamOSDevkitService
  3. Open the configure script in KWrite: kwrite configure-hackendeck.py.
  4. Comment out line 20 (the sys.exit(1) in the if not hackendeck: block) by adding a # at the start of the line.
  5. Save the file and close KWrite.
  6. Run ./steam-devkit-tool. It should print “Only supported by Manjaro - please check documentation” but continue running after that.

Now the service should run as expected, you can launch the service from Gaming Mode, and see your Deck on your main PC. However, this is not ideal, as the game is running in the foreground, which means that it’ll often get cut off, and it isn’t very automatic.

Setting up a systemd user unit for autostart

  1. Open Konsole and run:
    kwrite /home/deck/.config/systemd/user/steam-devkit-service.service.
  2. Write or copy the following into the file (note: the ExecStart line does not have a line break, it’s just very long): 
    [Unit]
Description=Manually created SteamOS Devkit Service
Wants=network.target
After=network-online.target

[Service]
Restart=always
WorkingDirectory=/home/deck/.steam/root/steamapps/common/SteamOSDevkitService
ExecStart=/home/deck/.steam/root/steamapps/common/SteamOSDevkitService/steamos-devkit-service.py --hooks hooks

[Install]
WantedBy=default.target
  3. Save the file and close KWrite.
  4. Enable and start (the --now part) the service:
    systemctl --user enable --now steam-devkit-service

Now, pretty much whenever your Steam Deck is powered on, it should be accessible to other computers on the same network which are running the SteamOS Devkit Client. You can install it for your main computer with this direct install link in case you still need it.


Comments? Email! The email is blog dot hello at the same domain this blog is hosted at, minus the subdomain. Sorry about the subterfuge, gotta try and avoid the robots somehow. Also on the fediverse, @neon@fedi.neon.moe
Writing a Gemini client tag:blog.neon.moe,2020-11-11:/2020/11/11/gemini 2020-11-11T00:06:00+02:00 2020-11-11T00:06:00+02:00 Recreational C programming.

Writing a Gemini client

Posted on 2020-11-11 by Jens Pitkänen

I have officially gone off the deep end. I am writing a C program just for fun. And it has been fun! I will admit, the experience of writing and debugging the code is much more frustrating than Rust, but the results are very rewarding. My client is currently clocking at 99KB, dynamically linking against libssl, libcrypto, and SDL2. And it’s a fully visual Gemini client! It’s always pleasant to write dense software.

Find it here, though at the time of writing, it’s not usable yet:

=> https://git.sr.ht/~neon/nemini

Here’s a bag of assorted thoughts I came across development.

Oops, apparently I’m not the only one who thought this is a great idea

About a week into development, I learned of Lagrange.

=> https://gmi.skyjake.fi/lagrange/

It uses SDL and OpenSSL, is written in C, and made by a finnish person as well. It’s one thing to make “yet another program to do X”, and another thing to make “yet another program to do X based on Y written in Z”. Oh well. Good thing I’m writing this client for fun, then ;)

TCC scripting

Here’s a trick I learned many moons ago, which I finally got to use during this project:

#!/usr/bin/tcc -run

You know, if you want to write a quick little script, but want to do it in style, with C. I wrote a short script to encode a binary file into a C source file with this:

#!/usr/bin/tcc -run
/* Reads bytes from stdin and prints them out as C source code to stdout. */

#include <stdio.h>
#include <unistd.h>

int main(void) {
    int bytes_read;
    unsigned char buf[75 / 5]; /* 5 chars per byte: 0xFF, */
    printf("const unsigned char data[] = {");
    do {
        printf("\n");
        bytes_read = read(STDIN_FILENO, buf, sizeof(buf));
        for (int i = 0; i < bytes_read; i++) {
            unsigned char byte = buf[i];
            printf("0x%02X,", byte);
        }
    } while (bytes_read != 0);
    printf("};\n");
    return 0;
}

Usage:

clangifyer.c <binaryfile.bin >cfilewiththedata.c

There might be bugs, but it seemed to work for me. I included the Atkinson Hyperlegible Font into my client with it!

=> https://www.brailleinstitute.org/freefont

You might ask: is this really the first time you had the opportunity to use C for scripting, after having learned of this “trick” “many” “moons” ago? No, not really, but I had C on my mind this time.

OpenSSL isn’t that bad

It’s actually quite a simple library to use. I based my code completely on gmni’s TLS code, and I’m not sure I know how the whole thing works yet, so I won’t write a tutorial here. But it wasn’t that much code! Don’t be intimidated by the fact that it’s a big scary system library like I was initially.

=> https://git.sr.ht/~sircmpwn/gmni

C woes

Writing C sure has been an adventure. Here’s some highlights:

  • malloc/freeing things has been surprisingly easy to remember. I say, having not checked my program for memory leaks.
  • Reading the manpages carefully is important. They always contain neat little tidbits, such as “you absolutely must free() this yourself” or “do not free() this, or everything will break”. Rust is pretty neat in how it encodes this stuff as types, in the language, so they can be checked, at compile time. >:[
  • Did you know, you can do “man <pretty much any function from OpenSSL>” and it opens up the documentation for that function, with explanations, possible return values, and everything else relevant? It’s pretty neat, though I never learnt this in programming school(tm). I came across it accidentally by calling “man getaddrinfo” during the dark hours of the morning.
  • The “char” type is not defined as signed or unsigned. Madness! I guess it doesn’t come up often, since you generally don’t do arithmetic on letters. But considering that there isn’t another “number type” for 8-bit values, this really salted my fields. The “i32/u32” convention is a lot easier to program with.
  • Use-after-frees are painful to debug, t. spent-like-six-hours-trying-to-figure-out-why-libssl-crashed-and-then-found-out-I-wasn’t-supposed-to-free-the-cert-myself.

This will be on my gemlog as well

Do you have a Gemini client handy? Are you from the future? You could read this blog post on my gemlog too:

=> gemini://gemlog.neon.moe

If there’s nothing there, I haven’t set it up yet. Likely because I’m still hacking away at Nemini instead. I’ll probably make another post when I set that up, so sign up to my Atom feed if you’re interested.

=> /feed.xml


Comments? Email! The email is blog dot hello at the same domain this blog is hosted at, minus the subdomain. Sorry about the subterfuge, gotta try and avoid the robots somehow. Also on the fediverse, @neon@fedi.neon.moe
Quake studies tag:blog.neon.moe,2020-04-03:/2020/04/03/fps-movement 2020-04-03T07:29:00+03:00 2020-04-03T07:51:00+03:00 Or: I like Quake's movement, let's figure out how it works.

Quake studies

Posted on 2020-04-03 by Jens Pitkänen

To start this off, I would like to make the disclaimer that I am not a professional Quake player. In fact, I have only played Quake 1 and Quake Live, and my combined playtime is in the magnitude of hours, not tens or thousands.

That said, every now and then, I get the feeling to play Quake. One should play the classics, right? The feeling never seems to last, but I do always enjoy Quake’s movement. Delightful to zoom around that starting chamber. Since I am currently working on a first-person puzzle game, I figure I should find out what makes Quake feel so good, to replicate that feeling in my game.

Observation: leaning

The most visually distinct “effect” in Quake is the way the camera leans when strafing. This might also be happening when you move forward and turn—which could imply that this lean is actually based on the player’s velocity on the right/left axis, and that turning has a bit of inertia—but the effect is hard to detect by just eyeballing. It should also be noted, that this lean does not apply to the gun in the middle: it actually accentuates the lean by staying upright.

Observation: bobbing

The camera bobs slightly on the up/down axis, while the gun has a more pronounced bob, down and towards the player. The gun doesn’t seem to bob in a sine wave either, like the camera: it seems to stay relatively still, until it dips noticeably whenever the camera dips. Modern gun bobs are more elaborate, but I do think there is a certain charm to Quake’s bob.

Observation: acceleration

When releasing the movement keys, the player will slow to a stop over a short period of time. I can not tell if there is acceleration when you start moving, but if there is, it is very sharp. Still, moving forward does feel very smooth, so maybe it does accelerate over a few frames. This effect is even more pronounced in Quake Live: the movement feels really smooth. I hope the source will enlighten me further on this.

Source

If you would like to check out the source for yourself, it is on id’s GitHub.

/* About the code: It is delightfully readable. There is something about games made by big companies that makes them seem intimidating to me, so it is always suprising to find that they have been made by humans much like you and me. */

Leaning

Lucky me, the leaning code is the first function of view.c. The lean is based on the player’s velocity on the right axis, as I suspected, and it seems linear. Simple to implement, for a nice effect.

Bobbing

Head bobbing is implemented in the very next function of view.c. The code is pretty much what you’d expect, with a bobbing period of 0.6 seconds. The bobbing intensity is based on the player’s velocity on the XY plane. This is good for fading out the effect, taking into account how quickly the player accelerates / brakes.

Turns out, the gun does not actually bob up and down with varying speed: it bobs in sync with the camera, forwards and backwards. Because of how perspective projection works, the effect is more pronounced as it gets closer to the camera, which led me to believe the bob is not a sine wave, assuming the motion was up/down. This is why it is great to have the source available!

/* Something I thought was interesting: there is a commented bit of code that would make the gun sway horizontally as well. */

Friction

Next up, from sv_user.c: SV_UserFriction.

The friction function is probably the spiciest code I have reviewed for this post, it’s easiest to demonstrate by just showing the code (edited for readability):

float speed = length(velocity.xz);

float control = speed < sv_stopspeed.value ? sv_stopspeed.value : speed;
float newspeed = (speed - host_frametime * control * friction) / speed;

if (newspeed < 0) newspeed = 0;

velocity *= newspeed;

Is that not wild? Maybe not. It is basically just like, friction, but what gets me is the control variable. The amount of friction applied goes down as your velocity decreases, until you pass the “stop speed” threshold, after which the friction stays constant. This causes this sort of braking effect in game, which I really enjoy.

Acceleration

The acceleration function is what you would expect, like the friction was, but has no extra spices: SV_Accelerate calculates an acceleration value based on the target speed, then applies that acceleration to the player’s velocity. The acceleration is 10 * frametime * wishspeed, so wishspeed is reached in about a tenth of a second, according to my napkin calculations. 100 milliseconds is many frames! I am not sure how I was fooled into thinking the movement was so sharp I could not tell if there was acceleration, but testing it out now, the acceleration is quite clear. Never trust eyeballed observations!

Demo

I originally intended on putting the demo right here, but I thought it’d be better to warn you before loading up a game in your browser. So be warned, the demo link will open a web game written in JavaScript, with three.js. Controls: WASD to move, arrow keys to look around, space to jump. Mind the non-axis-aligned walls, they are not quite solid. Demo.

Final thoughts

What did I learn? That I should never trust my own judgement on movement. Also, that a good acceleration function combined with a good friction function make for some good movement! With a little bobbing and leaning sprinkled on top, you get some excellent movement out of a few lines of code.


Comments? Email! The email is blog dot hello at the same domain this blog is hosted at, minus the subdomain. Sorry about the subterfuge, gotta try and avoid the robots somehow. Also on the fediverse, @neon@fedi.neon.moe
DPI scaling factors tag:blog.neon.moe,2019-10-27:/2019/10/27/hidpi 2019-10-27T20:32:59+02:00 2019-10-27T20:32:59+02:00 High-DPI scaling results in weird artifacts, who knew!

DPI scaling factors

Posted on 2019-10-27 by Jens Pitkänen

So screens today are quite high resolution. For example, I have a 2560x1440 resolution screen as my main viewport to the digital world. While lots of pixels can be used to make very sharp graphics, they also present a problem: old applications are still drawing letters that are 16 pixels high, which are very small on these screens! There are at least two solutions to this:

  • Stop working in pixels, and start working in physical units instead when making graphics, and let the underlying graphics systems handle the conversion into pixels. This way, one string of text is the same size on every screen, but might not be what we want: desktop screens are viewed from a further distance than phones, which would make text either too big on phones, or too small on desktops.

  • Keep working in pixels, and keep thinking in terms of “this text should be printed at a font size of 16 pixels,” but secretly multiply all values by some factor depending on how high resolution your screen is, and how far people are generally going to look at the screen. So, you might use a multiplier of 2x for a 4K desktop screen, or even 3x for a 2K phone screen. I’ll be calling this multiplier the “DPI scaling factor” from now on.

It should seem relatively obvious that we have gone the second route. People are doing everything on phones nowadays, so whatever system we come up with has to fit that need with minimal developer effort. I kind of wish we had gone the first route, as it would’ve annihilated any hopes of even trying to think in pixels, which might’ve led us to some vector-graphics-based paradise where every graphic is smooth and well antialiased. Sadly, this is not the case, and everyone is still rendering bitmaps that may or may not be the same resolution as the picture that ends up on the screen of the user.

Based on my experience, it seems that the current way to get nice looking sprites on screens of differing DPIs, is by having manually scaled versions of every asset for every possible DPI scaling factor. This is a bit bothersome, but it looks great! The artists can make sure every pixel is just right, and they’ll end up rendered on the user’s screen exactly how they intended. It would be really bothersome to write all graphics layouts for each DPI scaling factor however, but that can thankfully be generalized (sort of): just work in some “logical” pixel coordinate space, which gets converted into physical pixels later on.

Dun dun dunn.

The rock in my shoe that inspired this blog

Turns out, logical pixels aren’t the savior they’re made up to be. Well, they are, to a point. As long as your DPI scaling factor is an integer, you’ll be fine. Every logical pixel will correspond to some specific physical pixel, and no shenanigans will happen that could ruin your artist’s pixel-perfect asset. But! Some systems can set the DPI scaling to a fractional number, like Windows. I have set my Windows to scale everything by 1.25x, because that makes text comfortable to read on my 1440p screen, while still giving me the working space I want on a desktop screen. But this presents a problem, which I will demonstrate via three examples.

Sprite with no scaling at (2, 2)

This is the normal, easy situation. The artist has drawn a 8x8 sprite, which I then render at the logical coordinate (2, 2), at a logical resolution of 8x8. Because there is no scaling, this results in a nice, crisp sprite rendered at (2, 2), with a resolution of 8x8, displaying every pixel of the sprite in all their glory.

1.25x scaled sprite at (0, 0)

The artist has now drawn me a 1.25x version of a sprite for my game. The unscaled version of the sprite is 8x8, and so the 1.25x version is 10x10. I render it at the logical coordinates (0, 0) with the logical size 8x8 to test out that it looks good on my 1.25x scaled screen, and voilà: I get a 10x10 (which is 8x8 scaled by 1.25x) sprite rendered at (0, 0) (which is (0, 0) scaled by 1.25x), which looks great, pixel-perfect!

1.25x scaled sprite at (10, 10)

Now that I have the 1.25x sprite, I decide to playtest my game a bit. The player ends up at the logical coordinates (10, 10), but wait! The resolution of the sprite is still correct, just as it was in the previous example, but what about the coordinates? Well, (10, 10) scaled by 1.25x is (12.5, 12.5).

Well.

What happens now depends on how you handle fractional physical pixels. In my case, rendering with OpenGL and using floats to describe the pixel coordinates, you end up with a mushed sprite that’s sampling the texture in all the wrong spots, resulting in a sprite with a bad 1px blur. But is that okay? Is that what Microsoft intended to have be displayed when the coordinates don’t match up? Or should I round the coordinates, and occasionally end up getting weird 1px gaps between objects that are really just 0.01 pixels apart, enough to make them round to the different side? I don’t really know, and as such I ended up adding this as a parameter to my quad-drawing function in the library I’m writing. On one hand, the blur could be fine, you’re on a high DPI screen anyways, so you probably won’t mind a very slight blur. But on the other hand, if you’re working with very fine details, that blur might cause havoc! I’d be interested to hear if you have come up with a rigorous solution to this, heard of one, or just have opinions about this.


Comments? Email! The email is blog dot hello at the same domain this blog is hosted at, minus the subdomain. Sorry about the subterfuge, gotta try and avoid the robots somehow. Also on the fediverse, @neon@fedi.neon.moe
Putting my Mastodon to sleep tag:blog.neon.moe,2019-07-15:/2019/07/15/mastodown 2019-07-15T19:41:35+03:00 2019-07-15T19:41:35+03:00 How I shut my single-user Mastodon instance down after moving to another server.

Putting my Mastodon to sleep

Posted on 2019-07-15 by Jens Pitkänen

Not my pet of the genus Mammut, no. Just my old fediverse instance. Sometimes you want to move domains, sometimes software. Of course, you could migrate your old instance over to the new software, but what if there is no migration path, or you’d like to start anew? This is the situation that inspired this post: I moved to Pleroma when they finally released 1.0, and started a new instance on another subdomain, on my own hardware. I would like to avoid paying for my Mastodon instance’s server costs now that I am not using it anymore.

Disclaimer: I have not contributed to any fediverse software, and I have no idea about how they really work. My fedi experience consists of hosting an instance for two years. So, consume this document with much salt.

You may ask, how do you put an extinct proboscidean to sleep? I do not know either, so I asked on the fedi, but nobody came up with a solid battle-plan. After some searching, I found the tootctl self-destruct command, which seems like a good way to make everyone forget your server ever existed (it sends account delete activities to everyone). That is not quite the magnitude I want, I would prefer to leave a gravestone, not absolutely annihilate my old persona. But hey, that might be what you want, so there you go.

Imagine a few hours of system administration before reading onwards, that’s what I did at this point in the blog. I do so enjoy writing an article as I do the stuff I write about.

Based on the previous information, I had a plan to cache the /users/neon endpoint, and respond with error 410 everywhere else. I did that, and then realized that it probably is not good to pretend to be an active instance (through providing a cached response on one endpoint), and ended up just serving 410 on the whole domain.

So, how do you put a big furry creature to sleep? Make it respond to everything with error 410. That’s what I did in any case, I hope it’s asleep now.


Comments? Email! The email is blog dot hello at the same domain this blog is hosted at, minus the subdomain. Sorry about the subterfuge, gotta try and avoid the robots somehow. Also on the fediverse, @neon@fedi.neon.moe
My experience learning make tag:blog.neon.moe,2019-07-06:/2019/07/06/make 2019-07-06T01:23:38+03:00 2019-08-17T18:54:50+03:00 A journal of my journey from a casual cargo fan to a make evangelist.

My experience learning make

Posted on 2019-07-06 by Jens Pitkänen

When I have been looking for a new language to learn, or gauging the usefulness of a language, I tend to appreciate build systems as part of the language. I think an important property of a tool is its simplicity of use, and for a long time I avoided C because it did not have a mvn, cargo, or npm. I thought the lack of an in-built build tool made C unnecessarily complicated to get started with. After reading bits and pieces of the K&R, making an almost whole game in C, and still not having touched makefiles, I have come to the conclusion that I was wrong. I have been happily writing C and building it with shell-scripts that build the program for each specific system. For example, I have a batch script for Windows that builds the program with cl.exe, providing the correct flags, one for Linux, and so on.

The reason I wrote the shell scripts instead of makefiles is because I already knew how shell scripts work, and learning to use cc and cl.exe was quite similar to learning to use the aforementioned build tools. If the compilers did not do something I needed from a build tool, I would just write that part in the script myself. In addition to this, I have heard a lot about makefiles not being super portable, and the existence of qmake and cmake seem to prove that idea. And in my own experience, when I have had to call make manually, it has stumbled on my system being misconfigured somehow, which makes it seem prone to breakage.

That said, I definitely feel like I should learn how to write a Makefile, if for no other reason than to make my negative opinion of them more valid. Or invalid, as the case may be ;)

Learning make

A few days ago, I got a copy of The Unix Programming Environment by Brian W. Kernighan and Rob Pike from the library. Why? The main reason was because I wanted to explore the Unix philosophy a bit further than what I had learned from hearing it repeatedly in tech articles and social media (not much). The other reason was because I imagined it would have a bit on make.

It does, sort-of. The eighth chapter is about writing a big program, and has three digressions on make. Based on that, I got the following impression of it: makefiles define dependencies between generated and manually edited files, and how those dependencies manifest (that is, how you get from the manually written files to the generated ones). The connection to C becomes obvious once you think about C programming in those terms: first you manually edit the C source code, then you generate object files out of that, and then you generate a final executable from those.

In this light, make seems like an obvious fit for C, but very general as well. I did not realize what the specific role of make was before, probably because other programming languages have built similar functionality into their build tools, but after this realization, it is obvious.

On one hand, I appreciate how cc and make split the job of making lots of source code into an executable (something something Unix philosophy), but on the other hand, I can not help but feel like it is pointlessly complicated for the end-user. Almost every program follows a similar build-pipeline, or could at least be refactored to fit, so why not combine the functionalities to a singular build tool? Why do I need to learn yet another syntax just to build my C? I imagine that is what a lot of people thought, since at least a few trillion different tools have been written to build a C program. I think. Ninja just sounds so out-there, that all the good names must have been taken already, which would infer many such tools. I do not actually know if ninja is a build tool. But I digress.

Conclusion

Make(1) is neat. I wrote a Makefile for this blog to test it out, and I enjoyed the experience after ironing out a few misunderstandings. It is a shame that make is the most universal tool to build C programs, I would much prefer a more cargo/go build-like experience, but it is not that bad either. If you are of a similar mindset to mine at the beginning of this post, just go ahead and use make. It is not evil. At the very least, it can not be as bad as picking one of the million other C build tools, because you do not get anywhere by making yet another standard, and you learn a new tool you can use for many other things as well. And make sure to be POSIX-compatible, just to be a good citizen :)

As a final note, The Unix Programming Environment has been a pretty fun read, if a bit obsolete. At least the C is, did you know functions looked like this in the 1970s?

main(argc, argv)
        char *argv[];
{
    // ...
}

Comments? Email! The email is blog dot hello at the same domain this blog is hosted at, minus the subdomain. Sorry about the subterfuge, gotta try and avoid the robots somehow. Also on the fediverse, @neon@fedi.neon.moe