Orsvärn

Sphere shader

Sat, 31 May 2025 00:00:00 +0000

This is how I can use a shader to make a quad look like a sphere. This is cheaper to render in many cases, and can be indistinguishable from a real sphere.

The left side is shaded, and the right side is a wireframe view of the same scene. One of the spheres is actually a plane!

The shader calculates tangent space normals on the plane which make it look similar to a real 3D sphere.

Drawbacks

I like seeing where a technique fails, which can help explain how it works as well, so let’s break it! 😁

While the plane’s normals are correct thanks to the shader, the 3D positions are not. This makes the shape of the received light look weird when the light source is close. Only the sphere on the right is fake.

It doesn’t handle intersections well. Real sphere on the left, fake sphere on the right.

It doesn’t receive shadows properly. Real sphere on the left, fake on the right.

It also can’t have a regular texture on it because the texture follows the camera when it rotates around the sphere. Solutions include generating UV coordinates, or using a cubemap.

Benefits

So what are the positive aspects of the technique?

It’s cheaper to render than a sphere of similar roundness built using more geometry.
It looks perfectly round.

Use cases

With real-time graphics, I need to balance several factors against each other to find a good use case. To do that, I’ll list some issues and potential solutions:

Being too close to lights looks weird.
- Keep point lights away.
Intersecting with other objects looks weird.
- Ensure it doesn’t intersect with anything.
Receiving shadows looks weird.
- Disable receiving shadows on the object?

A potential solution to all these issues is also to keep the object small or moving, this makes the drawbacks harder to notice. Maybe it’s useful for water droplets in a particle effect, for instance.

Another potential solution is to develop the technique further to make the 3D position of the fragments correct. I have a link to a technique that does this at the end of the post.

It could also work well for distant objects where it covers a small space on the screen, or I can control the lighting conditions and what geometry it intersects with. Maybe it could be used as the last level of detail for some object?

It could work better if the game has certain properties. For instance, if the game doesn’t use point lights, or if the game is 2D, or it doesn’t use shadow maps.

Implementation

This shader is made to work with the default quad in Godot. If I’m using something else, I may need to make some changes. For the effect to work, the quad must always face the camera. I’ll include code for this in the shader as well.

Theory

The amount that the normal faces to the right or up increases linearly with the x and y coordinates. This means I already have my x and y components in the UVs!

That leaves me two things to figure out:

The Z component.
- This can be calculated from the UV coordinates.
Discarding fragments in a circle.
- I get what I need for this when calculating the Z component.

Let’s look at an implementation.

Implementation

This implementation is written in Godot’s shading language, which is very similar to GLSL, which is fairly similar to HLSL. The shader is made to be applied to a standard Godot quad, which I get by creating a MeshInstance3D, and setting its Mesh to be a New QuadMesh.

shader_type spatial;

// We use the vertex shader to make the quad face the camera.
// This doesn't have very detailed comments because it isn't the focus.
void vertex() {
	// Prepare our directions.
	vec3 plane_to_cam = normalize(CAMERA_POSITION_WORLD - NODE_POSITION_WORLD);
	const vec3 WORLD_UP = vec3(0, 1, 0);
	vec3 plane_right = normalize(cross(WORLD_UP, plane_to_cam));
	vec3 plane_up = cross(plane_to_cam, plane_right);

	// Build the rotation matrix.
	mat4 billboard = mat4(
		vec4(plane_right, 0.0),
		vec4(plane_up, 0.0),
		vec4(plane_to_cam, 0.0),
		MODEL_MATRIX[3]
	);

	// Apply the matrix.
	MODELVIEW_MATRIX = VIEW_MATRIX * billboard;
}

// This is where the sphere illusion is created.
void fragment() {
	// Bring input UVs into the -1 to 1 range.
	vec2 uv = UV * 2.0 - 1.0;

	// Do the dot product separately so I can branch on the result
	// and reuse it later.
	float uv_dot = dot(uv, uv);
	
	// If the dot product is over 1, it's outside of the circle.
	if(uv_dot > 1.0) {
		discard;
	}
	
	// Calculate the Z value from the dot product.
	float z = sqrt(1.0 - uv_dot);
	
	// Flip UV.y because that's what Godot wants for tangent space normals.
	uv.y *= -1.0;
	
	// Set the normal.
	NORMAL.rgb = vec3(uv, z);
}

If the original plane is entirely outside the view, it will be frustum-culled even though our rotated plane is still inside the view, causing it to pop in and out of existence in some cases. We can solve this by setting GeometryInstance3D -> Geometry -> Custom AABB to these values:

Set x, y, and z to -0.5.
Set w, h, and d to 1.

These values will only work for uniformly scaled planes. If I want non-uniform scaling, more work needs to be done, but I’m not covering that in this post.

More spheres

This post showed the basics of using shaders to make a plane look like a sphere. If I want to go deeper, check out these posts:

Diablo 3 — Resource Bubbles by Simon Trümpler is a treasure trove for sphere rendering.
Rendering a Sphere on a Quad by Ben Golus uses more advanced techniques to create a sphere that doesn’t suffer from the drawbacks of the technique in this post.

Fix Bouncing Emails

Sun, 30 Jun 2024 13:20:00 +0200

An email I sent to a gmail address recently bounced, this is how I solved it.

I have my own domain that I use for email, so I need to set up certain DNS records to avoid my emails bouncing on for instance Google’s email servers.

The relevant acronyms are:

SPF (Sender Policy Framework)
DKIM (DomainKeys Identified Mail)
DMARC (Domain-based Message Authentication, Reporting and Conformance)

I need to set up SPF and DKIM to avoid bouncing. DMARC is only necessary for sending email in bulk, so I don’t need that.

The purpose of SPF and DKIM is to stop people from “spoofing” my domain, which is when someone sends an email that looks like it came from my domain when it actually didn’t.

SPF and DKIM are set up as DNS records on the domain.

SPF

This DNS record lists which mail servers are allowed to send email on behalf of this domain.

This is the SPF entry for my domain:

Type: TXT
Subdomain: @
Data: "v=spf1 include:hover.com -all"

For some reason I need to put " around the data. Not sure if that’s specific to my DNS provider.

hover.com hosts my email, so that’s the domain I include. I don’t write the entire domain which is mail.hover.com, because it doesn’t care about subdomains.

To check that it’s working I use an online SPF checker. I give it orsvarn.com and it verifies if my SPF record is valid.

DKIM

This entry contains a public key that my email server provider created. When I send an email, the email server signs the email with a private key on the mail server. The receiver uses the public key on this DNS record to verify the signature.

My email client doesn’t need to do anything, the signing happens on the mail server.

I had to contact my email provider’s support to have them generate a key pair for me, and they gave me the public key. It seems like some providers allow you to generate your own key pair.

This is the DKIM entry for my domain:

Type: TXT
Subdomain: dkim1._domainkey
Data: v=DKIM1;t=s;p=MIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQC3D3MoSCbPojBxQpXA0B5nKWi33uE+QmDlvtqfqBgFLVPj3hMQGMBTLKG9+VjZ60zy7waZZxHkpIGnqiP0q6kVRTE7oKTZyjSWjogaYp0Mxt9m21gjLbVqSE2gU+wJ1iGbunkNWU9ng0LLZJ6hT8j3DvAKoq0wlWGb5DuX/2ybYQIDAQAB

At first I didn’t understand that I needed to create a new subdomain for this entry. I tried to put it under @ like with the SPF entry, but that didn’t work.

The t=s does this according to the specification:

Any DKIM-Signature header fields using the "i=" tag MUST have the same domain value on the right-hand side of the "@" in the "i=" tag and the value of the "d=" tag. That is, the "i=" domain MUST NOT be a subdomain of "d=". Use of this flag is RECOMMENDED unless subdomaining is required.

I don’t understand what that means, but it’s recommended and seems to work so that’s what I’m doing.

To check that it’s working I use an online DKIM checker. I give the checker orsvarn.com:dkim1 and it tells me if it’s valid.

DMARC

Since I don’t send bulk email, I don’t have this set up. I read somewhere that having a “low level” DMARC entry can make it easier to spoof emails from my address than if I had no entry at all.

It isn’t necessary to set this up to be able to send emails to Google’s mail servers. Though some sellers of DMARC online say otherwise.

The final test

To check that it’s working in practice:

Wait for the DNS to propagate.
- I use online SPF and DKIM checkers to check if it has propagated. The way my DNS is set up, this takes up to an hour.
Send an email to a gmail address.
If I don’t get an email telling me it bounced, it works!

Questions or comments? Contact me via email.

Smooth low poly style

Sat, 15 Jun 2024 00:00:00 +0000

Unable to play video

Creating a smooth low poly style is all about controlling the normals. This video shows the basic techniques for doing that.

Self Hosting Video

Fri, 07 Jun 2024 00:00:00 +0000

I recently set up a low tech system for hosting videos on my website. Here is the first video I uploaded to test it!

Unable to play video

Street Smoke

Download

Why?

I used to make videos on YouTube. But I dislike someone earning money from my videos. I have no intention of earning money from them, and almost nobody watches them anyway, so it just gives me a bad feeling.

But I do want to be able to put videos online. I want to be able to present them to people without ads other distractions. I want people to be able to watch them through their RSS readers! I want to offer a direct download link, and original quality Torrent download next to the video.

I want my visitors to feel like fellow humans, rather than a way to make money.

Goals

These are the goals for my setup:

Low maintenance, I don’t want to be forced to fix my server.
Portable, I don’t want to be stuck on a specific server.
Easy to use, both to set it up, and using the final system.

These goals align with a slippy mindset.

All I want to have to do is upload a video somewhere over ssh. When the video is uploaded it should automatically create a page for the video in my website repo, as well as transcode the video to a lighter format, and upload that to the website repo as well.

Then I can add a title and description to it and publish it manually.

How I did it

I combined several smaller pieces into something that does exactly what I need, and nothing I don’t need. There’s low maintenance, because each program has been around forever, and won’t change with updates, and they are likely to keep being maintained for a long time. And if something breaks, everything is at a level where I can go in there and fix it myself, or swap out one of the components.

Here are the key parts in this project:

scp to send videos to a directory on a server.
entr for reacting to a file being sent to that directory.
ffmpeg for transcoding videos.
git to push transcoded videos to the website repository.
bash for putting everything together into a script.

I put all these pieces together into this ~100 line bash script:

#!/usr/bin/env bash

transcode_video() {
	# Transcodes the input files to the $OUT directory.
	#
	# Transcodes to one modern mainstream format.
	#
	# I'm using https://developer.mozilla.org/en-US/docs/Web/Media/Formats/Video_codecs to decide which formats
	# have good enough support.
	#
	# As of May 2024
	# Modern format: VP9 & Opus
	# Legacy format: H.265 & Vorbis

	local IN=$1
	local OUT=$2

	# 960 is half of 1920,
	# so this is half of 1080p.
	# The long side is decided instead of the short side,
	# because this ensures the resolution doesn't go above half of 1080p.
	local RES=960

	local SCALING="scale=w='min($RES,iw)':h='min($RES,ih)':force_original_aspect_ratio=decrease"

	# X265 constant rate factor (CRF) encoding
	ffmpeg \
	-n \
	-i $IN \
	-vf $SCALING \
	-c:v libx264 \
	-b:v 0 \
	-crf 30 \
	-c:a aac \
	-b:a 128k \
	"${OUT}.mp4"

	# Create thumbnail
	ffmpeg -n -i "$IN" -vf "$SCALING" -frames:v 1 -q:v 5 "${OUT}.jpg"
}

push_to_git () {
	# Adds and pushes all files in the repository.
	# Assumes the GIT_WORK_TREE and GIT_DIR environment variables are set.

	git fetch
	git merge
	git add --all
	git commit -m "push_to_git from $(hostname)"
	git push
}

folder_transcode () {
	# This script transcodes all files from one folder
	# and puts them into another folder.

	local DIR_IN="$1"
	local HUGO_DIR="$2"
	
	local DIR_OUT=$HUGO_DIR/assets/video

	for f in "$DIR_IN/*"; do
		# Continue if it isn't a file.
		if ! test -f "$f"; then
			continue
		fi

		filename=$(basename -- "$f")

		out_filename_no_ext=${filename%.*}
		out_filename_ext="$out_filename_no_ext.mp4"

		if ! test -f "$DIR_OUT/$out_filename_ext"; then
			# If the output file does not exist..

			# Create and push a new draft page for the video,
			# so that can be edited while the video gets uploaded.
			$HUGO_DIR/hugo -s $HUGO_DIR new "video/$out_filename_no_ext.md"
			push_to_git
			echo "Pushed video info file"

			# transcode and push the video.
			out_file_path="$DIR_OUT/$out_filename_no_ext"
			transcode_video $f $out_file_path
			push_to_git
		fi
	done
}

# This script watches a folder,
# and transcodes all videos to the output folder when it changes.

# Print everything.
set -x

declare DIR_IN=$1
declare HUGO_DIR=$2

# Set the git repo we're using.
export GIT_WORK_TREE=$HUGO_DIR
export GIT_DIR=$HUGO_DIR/.git

# Ensure the out dir is up to date first.
git fetch
git merge

while sleep 1; do
	# Transcode all files in the directory.
	folder_transcode $DIR_IN $HUGO_DIR

	# Wait until there is a change in the directory.
	ls -d $DIR_IN | entr -npd -s 'kill $PPID'
done

Feel free to copy and do whatever you want with this script!

I’ve added the script as a systemd service that starts when the computer starts. The script runs forever in a loop once it has started. systemd is configured with NixOS, and the configuration there looks like this.

systemd.services.folder-watch-transcode = {
  description = "Auto-transcode and upload videos";
  wantedBy = [ "multi-user.target" ];
  path = with pkgs; [
    bash
    openssh
    entr
    ffmpeg_7-headless
    gitMinimal
    hostname
    lsof
  ];
  serviceConfig = {
    User = "video";
    Group = "users";
    Type = "simple";
    ExecStart  = ''${pkgs.bash}/bin/bash /home/video/bin/folder-watch-transcode /home/video/upload /home/video/orsvarn'';
  };
}

There is much more than this to the NixOS configuration, but that’s for another blog post. I also had to modify my website to display the videos, that is also not covered in this post.

NixOS

NixOS enables me to have the setup for an entire system in no more than a few configuration files.

If I want to have the same setup on another computer, I can copy the configuration files there, run nixos-rebuild switch --flake . and I’ve got all the programs, users, systemd services, etc. all up and running within a few minutes.

Some things still need to be done manually, like adding private SSH keys, and adding git repos where they’re supposed to be, but it reduces the amount of work by at least 80%!

NixOS improves the “low maintenance” and “portability” goals. This comes at the cost of the “easy to use” goal though, because it’s hard!

Next steps

I want to add a torrent download for the videos. I’m investigating if I need to run a tracker to not rely on a third party, and command line programs for creating torrent files.

Why don’t I use PeerTube?

PeerTube has all the features I want. It transcodes videos, allows embedding them, and uses the Torrent protocol to alleviate server load.

I didn’t go with PeerTube though, because it doesn’t satisfy my goals.

It’s potentially high maintenance, because I don’t know what is going to happen with it in the future. If it stops develoment I’d be forced to move to something else at some point. Since it’s a relatively new and complex project, the risk of it being left unmaintained increases. And when updates do arrive, that comes with an unknown amount of work for me.
It’s less portable because it’s a bigger thing. What sort of hardware does it need to run? Can it run on a Raspberry Pi 4? What sort of database setup do I need? Once I’ve set up a system, I don’t want to feel like it would be a huge task to migrate it to another server.
It’s hard to use, because it’s a big project that requires databases and certain power of hardware and other requirements to set up. If something goes wrong I don’t know how to fix it. If I want to upload something to it I need to have access to a web browser.

So even though PeerTube has the features I need, and I really like the project, it doesn’t satisfy my needs.

Small web!!

I hope that someday all this stuff can be available for less technical people too. It isn’t fair that only a few technologically capable people with free time can be truly free on the web.

Have you built something similar? Do you have suggestions for how it can be improved? Contact me via email.

Street Smoke

Wed, 05 Jun 2024 00:00:00 +0000

Unable to play video

This is a test for my small web video setup!

The setup allows me to upload a high quality video to my server, and it automatically transcodes it to a lower quality and uploads it to my website. Then I add a description and publish it. I’ll make a blog post about this soon.

As for the video: I think they are relining pipes under the street. Looks pretty cool with all that steam!

Making a custom weather system

Thu, 02 May 2024 00:00:00 +0000

The “Book of Beasts” has a weather system for The tabletop RPG “Forbidden Lands”. It didn’t fill my needs, so I made my own.

Forbidden Lands, Book of Beasts.

This post goes through my journey of creating this weather system. If you want to learn how it works and use it, download the system.

What do I want to change?

These are the things I want to change about the official weather system.

It feels too random

You roll a six sided dice for the sky at the beginning of every day. A 1 means clear skies, a 5 means light rain, and a 6 means heavy rain. Numbers 2 to 4 has “none”, which I guess means it’s partially cloudy or cloudy.

With a 1/3 chance of rainfall, the weather often changes between sunshine and rain and cloudy and rain, etc. It feels random.

It feels too predictable

In the official system you roll new weather every morning. This means the weather is the same for an entire day. It couldn’t start clear and end with rain for instance. It’s too predictable.

It rains too much

There is a 1/3 probability of rain, and half of that is probability of heavy rain. That means on average more than one day of heavy rain every week. I feel this makes the game too punishing, and less believable.

Unbelievable weather conditions

It is possible to get heavy rain + storm winds + hot weather. That doesn’t make sense to me because I have never experienced it, and I wouldn’t know how to describe it as a GM.

Gathering data

Before thinking about how the system should work, I set out to gather weather data to base it on. I felt like having the data would help me build the system.

Växjö’s location. Copyright OpenStreetMap contributors.

I interpret the “Ravenland” setting as Scandinavian. So I used historical weather data for the city of Växjö, made available for download by the Swedish Meteorological and Hydrological Institute (SMHI).

I chose Växjö because it’s..

Far from the coast, coastal weather is different from inland weather.
Located in Scandinavia, which is where I interpret the “Ravenland” setting to be.
Fun to use data from a place close to where I live.

This is the data I used:

Amount of clouds measured in percent several times per day from 1939 to 1996, to learn how much clear and cloudy weather there is.
Rain amount measured in millimeters per hour from 1995 to 2024 to learn how much it rains.
Average and maximum wind speeds measured from 1995 to 2024 to get an idea of how often the wind blows at different speeds.

I downloaded these from SMHI as .csv files which I opened in LibreOffice Calc. There I made calculations to learn how often different kinds of weather happens.

Interpreting the data

I used the same three categories as the official system.

Sky
Wind
Temperature

I looked up what words SMHI themselves use to describe different amounts of rainfall and wind. Coming up with my own threshold values would be an entire project on its own.

Sky

The sky represents what you see when looking up: How many clouds are there? How much is it raining? In the game this affects LEAD THE WAY rolls. These are the probabilities I found:

Real cloud cover probabilities.

The rain data says that there is some rain 13% of the time. If I subtract that from the probability of “cloudy”, I can combine it to the previous probabilities, giving me this:

Real sky probabilities.

The official system does not have “partly cloudy” and “cloudy”. Instead it’s simply “none”. I prefer having more information to go on when describing the weather, so I included these two states, even though they don’t have any gameplay impact.

Wind

This is how fast the wind blows. In the game this affects MAKE CAMP rolls.

This is the data I ended up with:

Real wind probabilities.

It seems like very strong and very weak winds happen less than 5% of the time, and otherwise the wind is weak or moderate about half the time, depending on if you’re looking at the maximum or average wind.

I find this data pretty hard to use. Wind changes speed often, and I’m not sure if the maximum speed or the average speed matters more. In the final system I based my probabilities on the average wind speed because I liked that it made moderate winds less common.

Temperature

I couldn’t come up with how to use the data for anything useful. So instead I made up a temperature distribution, and paired them with the combinations of sky and wind that makes sense.

So a clear day without wind has a high temperature, and a rainstorm has a low temperature.

In the game, a high or low temperature gives the COLD or THIRSTY status effects in certain situations.

How do I randomize it?

The official system uses one six-sided dice (D6) per weather aspect: wind, sky, and temperature. This is fast and easy.

I want my system to be fast and easy too, but I also want it to feel believable. These two requirements go against each other. If it’s too easy, there isn’t enough input into the system to create something believable, and if it’s too complex it becomes annoying to use.

First I tried tweaking the official system by adding another dice roll if you ended up on rain. My tweaks made it more believable, but it also added some complexity. I want a solution with the same or lower complexity, and more believability. I wanted a win-win, not a win-loss.

So I tried using a deck of cards instead. I think this would be a good solution if I had cards with the weather printed on each card. I didn’t like the idea of requiring making or ordering a deck of cards however, and I couldn’t make a weather table that was easy to read. So I abandoned this idea because it was too complex to use.

The solution I ended up with was rolling a “D66”. This means rolling two D6, but keeping track of which is which, for instance having one white and one red dice. This gives 36 different possible outcomes. 36 is enough outcomes to give a lot of variety, while keeping the table small.

So I make a table with 36 rows, and each row has a set of sky, wind, and temperature. This gives us:

Roll two D6
Look in one D66 table

I think this is at least as easy as the official system which goes like this:

Roll three D6
Look in three D6 tables

Since each weather condition is predefined, I can avoid unbelievable weather such as a warm rainstorm. This makes it more believable than the official system. I found the win-win I was looking for!

The big drawback of this solution is that it has fewer possible combinations. For instance, since there’s a less than 1% chance of deluge in real life, I’ll map this to one of the outcomes, giving it a 1/36 chance, or 3%. However, this means the table can’t have a deluge with no wind, and a deluge with lots of wind, because I only have one deluge in the table.

I make this tradeoff to keep the system simple. I don’t think it’ll be noticeable by the players in the game, and the game master can always spice things up if they get repetitive.

Creating the table

This is a matter of mapping each aspect of the weather data to 36 possibilities.

Comparing real probabilities and dice probabilities for the sky.

Then I put the mappings into a table, and compress duplicate entries to make it easier to read.

The final table.

That’s it, I now have an easy to use system that produces believable weather.

I wanted to take it further, so I added two more aspects to the system.

Removing the daily schedule

In the official system, weather changes each morning. I want it to be less predictable.

Forbidden Lands splits days up into Quarter Days. I found the sweet spot to be rolling a D6, and the result is the number of Quarter Days the weather stays.

I keep track of this by keeping the rolled dice, and each Quarter Day I reduce it by one. When it hits zero, I roll for new weather.

Believable temperature

I made a temperature scale going from one to five. When temperature is at 1 or 5, players risk getting COLD or THIRSTY according to the same rules as in the official system.

The month of the year determines the base temperature.
The “high” and “low” temperature in the current weather adjusts this up or down by one.
If it’s dark outside, temperature is reduced by one. The official game has a simple system that determines which Quarter Days are dark depending on the month.

Left: What temperature each grade roughly feels like. Right: Temperature grade per season.

To give a better understanding of the temperature scale, each point in the scale is roughly mapped to a real world temperature.

This temperature scale doesn’t make sense on a technical level. For instance, a cold summer night won’t reach freezing temperatures. But my thought process is that if the weather is “cold”, that’s because it’s windy or rainy. And at night it can get quite cold, maybe so cold that it almost feels like zero degrees with enough rain and/or wind?

Maybe not, but I’m fine with this bit of weirdness, because the system only needs to make the time of year and time of day impact the temperatures in a believable way. I think it does.

This simple temperature system is the final puzzle piece that brings it all together.

Conclusion

Roll three dice to determine these aspects of the weather:

How cloudy and rainy it is
How windy it is
How warm it feels
How long it is until the weather changes

The temperature is decided by the weather table, the time of day, and time of year.

Download the system

Believable Weather for Forbidden Lands

Thu, 18 Apr 2024 00:00:00 +0000

Download PDF Download ODS

This is a weather system for the tabletop roleplaying game Forbidden Lands. It’s based on meteorological data from southern Sweden. The goal of the system is to feel believable and be easy to use. It decides three aspects in one roll of three D6:

How cloudy and rainy it is.
How warm or cold it is.
For how long the weather lasts.

Preview of the PDF.

Using the System

Roll a D66 (explained below).
Pick the row in the table with that number, that’s your weather.
Calculate TEMPERATURE.
- Start with the base TEMPERATURE for the current month of the year, from the Seasonal TEMPERATURE table.
- Add the Temp difference from your row in the weather table.
- Subtract one TEMPERATURE if it’s dark according to the “Light & Darkness” table on page 147 in the player’s handbook.
Roll another D6 to determine how many Quarter Days the weather lasts.

A “D66” is when you roll two D6 with one being the ones place, and the other being the tens place. So if you roll a 2 and a 4, you have 24. This works best with two different colored dice to make it easier to distinguish between them.

Gameplay Effects

Sky affects LEAD THE WAY
- Clear: +1
- Rain: -1
- Deluge: -2
Wind affects MAKE CAMP
- Calm: +1
- Gale: -1
- Storm: -2

If TEMPERATURE is 5, each HIKING player character must succeed with an ENDURANCE roll every Quarter Day or become THIRSTY.

If TEMPERATURE is 1, all player characters who are not in a camp must succeed with an ENDURANCE roll every Quarter Day or become COLD.

On 65 & 66: For each Quarter Day, all player characters must succeed with an ENDURANCE roll to keep moving. On 66: modify the roll by -2.

Tips

In the instructions above I split the duration roll into a separate roll to make it easier to explain. Roll all three D6 at once to make it faster.
Keep the rolled dice for future reference.
Roll for the next weather early and save those dice too, then you can hint to the players what’s coming next.
Make it feel more natural by letting the weather sometimes change while the players are active, not just between quarter days.
When you end a session, note down the numbers on the three D6 for the next session.

Thank You For Reading

If you want to learn how I made the system, read this blog post.

Really Simple Syndication

Tue, 02 Jan 2024 00:00:00 +0000

RSS feed

With RSS you can get updated when I make a new blog post.

To use it, install an RSS reader on your computer or phone, and add this link to your reader: https://orsvarn.com/index.xml

The RSS reader I use on my phone is NetNewsWire. Unfortunately it’s only for Apple devices, but there are plenty of alternatives.

What Websites Use This?

It feels like almost every website on the Internet has an RSS feed. Try adding some to your reader! Most readers automatically finds the feed for you if you give it the website’s address.

These are some of the feeds I subscribe to:

People’s blogs.
- Todepond, Lu Wilson’s daily personal blog.
- The blog at the bottom of the sea, Programming, Graphics, Gamedev, Exotic Computation, Audio Synthesis.
- Jendrik Illner - 3D Programmer, posts “Graphics Programming weekly”.
Blog feeds for game engines and other software, and game news sites.
YouTube channels, this is how I follow YouTube channels without having a YouTube account!

Happy reading!

Simple Website CI

Sun, 12 Nov 2023 00:00:00 +0000

This is how running git push deploy automatically builds my website on the server and deploys it.

I build my website with the static site generator Hugo.
I host my website anywhere, currently renting from Hetzner for €5 per month.
I have the website Git repository on the server, and I use that repo as a Git remote on my computer.
The server has a Git hook that runs a script when I push to the repo.
The script builds the website with Hugo, and copies it to the public html folder, making it go live.

When I want to deploy the latest version of the website I just do git push deploy to push to the server’s Git. My changes go live after a few seconds thanks to the hook and the script.

Since the server builds the website, the website can be updated from any device with Git, even phones.

Details About My Setup

Here are some details about my setup.

Pushing to the Server

This is how I set up so I can push to the server.

On the server:
1. Add my public SSH key to the ~/.ssh/authorized\_keys file. This gives me the ability to push to the repos on this user.
2. Set up a bare Git respository for the website source files with git init --bare website.git.
On my computer:
1. Do git remote add deploy user@orsvarn.com:website.git to add the bare server repo as a remote.
2. The bare repository on the server doesn’t have anything in it, so I push the website to it with git push deploy.

Now the Git remote on the server is set up.

Git Hook to Build & Deploy

Let’s set up the Git hook and the script that builds and deploys the website. All these steps are done on the server.

Download Hugo.
Clone the Git repository with git clone website.git website.
1. Note: The bare repository holds all the Git stuff, but does not have a working copy. This step allows the server to actually access the files in its repository. After this step there are two folders, one called website.git containing the “bare” repo, and one called website containing the “client” repo that pulls files from the “bare” repo.
Create the file ~/website.git/.git/hooks/post-receive in the “bare” repo.
Write a script in the new hook file to pull the latest version, build it, and copy it to the public website folder.

This is the script I use:

#!/bin/bash

# Constants
declare REPO_DIR=/home/git/website
declare DEPLOY_DIR=/var/www/website

# Checkout files
git work-tree=$REPO_DIR --git-dir=“$REPO_DIR.git” checkout -f

# Build
cd $REPO_DIR
rm -rf public
./home/git/bin/hugo

# Deploy
rsync -a public/ $DEPLOY_DIR --delete-after

With this post-receive script, pushing to the server will automatically build and deploy the website.

Conclusion

This setup makes it easy to update my website. I don’t rely on any tools that can be taken from me, or services that can be shut down by someone else.

I’m confident the setup will keep working for tens of years, which gives me peace of mind.

Contact me via email.

Thanks

This post is a response to Lu’s post about hosting options.
Thanks to iliazeus for posting that there are Git clients and Markdown editors for phones.

Taped UV Seams

Sun, 28 May 2023 00:00:00 +0000

I was playing The Legend of Zelda: Tears of the Kingdom and was wondering how they managed to create seamless textures on organic models.

At first I thought they created two UV maps and blended between them. But then I found this Twitter thread where Keegan Keene describes how materials are blended in Skyward Sword. They don’t name the technique, so I’ll call them “Taped UV Seams” based on their tweets.

The idea is to create a mesh that covers the seam, and apply a material to it that fades in over the seam to hide it. This simple and lightweight technique has apparently been used in many games. I’m surprised that I haven’t stumbled across this before!

Unable to play video

A variation on the technique is to instead of covering the seam entirely, place a tape on one side of the seam that continues and fades out the UV unwrap from the other side. I think this is the technique they use in the new Zelda game.

Benefits For Height Maps

If you use a height map for the terrain you only have to store the height of each point. This is possible because the location of each height point can be inferred by its location in the list of data. This takes up only a third of the data that true 3D data would, but it means you can’t create overhangs and caves.

But wait a second, Tears of the Kingdom uses a height map, but also has caves that blend together with the terrain, so how do they do it?

I believe they use taped UV seams to allow them to use the same materials for the terrain and their cave meshes, making everything blend really well together.

So if they want to have an overhanging cliff, which is impossible with a height map, they can use the same tiling grass and rock textures they use on the terrain on the cliff.

They’ve managed to create the feeling that they’re using a voxel-based terrain solution that some games use, but with simpler technology, a smaller memory cost, and while giving more control to artists than a voxel-based solution can.

This is a very nice solution from a technology standpoint.

Triplanar Mapping Comparison

Triplanar mapping is when you project a texture from the three axis directions and blend between them based on the direction the surface is facing (the normal of the surface).

It’s worth comparing these techniques, because they solve some of the same problems.

Here is a comparison of the similarities and differences between UV blending and triplanar mapping.

Similarities
- The seams are faded so it looks more or less seamless.
- It works with tiling textures.
- Assets can be scaled up and down without affecting texel density since UVs can be scaled with it to compensate.
- UVs can be automatically offset for each instance to create variety.
Advantages of taped seams
- There are fewer seams than with triplanar.
- You get to pick where the fading seams go.
- You can have sharp seams if you want to.
- You can have larger continuous areas without seams.
- You can have more directionality in the unwrap, which works well for things like trees, where you might want the grain of the wood to follow a certain direction.
- You don’t have to use tiling textures, it can be used as a general unwrap technique as well.
Advantages of triplanar
- It requires less work, as you don’t have to UV unwrap or create tape meshes.
- It needs less data in the shader since UVs aren’t used.
- It can be used in entirely dynamic scenarios where geometry is created and destroyed on the fly.

Conclusion

Taped UV Seams is a cheap way to get seamless textures. It looks better than triplanar mapping, but requires more work.

Vismut 0.6

Wed, 12 Oct 2022 00:00:00 +0000

Vismut is the open source procedural texturing tool for everyone. Read the introduction to learn more.

Version 0.6 comes with a few important features, and marks two milestones for the project:

We received our first contributions, from @theorr!
We now have a CONTRIBUTING.md and a CODE_OF_CONDUCT.md.

CONTRIBUTING.md

The project is still starting up, and as the founder of the project I’m still learning a lot. With our first contributions, I learned that the common “merge request” process can be cumbersome for both contributors and maintainers. This made me think about if it could be done differently.

I found a development process called C4, which was partly created to solve this problem. C4 was not entirely compatible with my project, and I thought it was a bit too complicated, so I wrote a new process based on it: The Vismut Contribution Process (VCP).

If you’re interested you can read the entire process document. Here is a short summary:

The VCP tries to make it easy to contribute to the project. Making it easy to contribute makes it’s more fun to contrinute, less work for maintainers, and the project can develop faster. The tradeoff is that maintainers have less say in what gets merged. I don’t know how well the process will work, because I couldn’t find many projects that use a process like this. But there are some big potential benefits, so I think it’s worth trying it to see if it works.

CODE_OF_CONDUCT.md

The Vismut code of conduct is based on the Rust code of conduct, but with some changes:

It’s shorter: I think a shorter text is easier to understand, and people are more likely to read it.
It has simpler language: Simpler language is easier to understand and more accessible. Not everyone can easily understand written English.
It contains a list of encouraged behavior: Similarly to how it’s useful to have a list of rules to help reduce bad behavior, it’s also useful to have a list of encouraged behavior to help promote desired behavior. We don’t want to create a community that just “isn’t bad”, we want to create one that is good!

New Features

Save, Open & New: You can now save a node graph into a .json file, which can then be opened. These are of course foundational features, so I am very grateful to @theorr for implementing this!

The Grid: All nodes now live on a grid, and you can’t place a node on top of another node.

In node editors that don’t force a grid, some people spend time aligning their nodes to the grid. They maybe press a button in the user interface to align the nodes automatically, or they align them by hand. This takes time and makes it harder to get into a good flow when working.

By forcing everything to be on a grid we eliminate this unnecessary work, and make it easier and more predictable to automatically moves nodes around. The grid makes it easier to implement features like moving nodes out of the way when a node is placed somewhere, or to automatically formatting the node graph.

Other Improvements

Click connections and press X or delete to remove them. Thanks @theorr!
Redesigned nodes to get them to fit in the grid.
Reduced CPU usage when application is in the background.
Reduced latency between input and visuals.

What’s Next

Vismut still only supports shuffling channels, and now it’s time to do something about that. Vismut is missing four nodes that are foundational for procedural texturing:

Mix: perform math with images
Noise: generate images to build textures from
Offset: shift pixels around in an image
Graph: re-use node graphs

The addition of these four nodes will mark another major milestone for Vismut: The ability to generate many types of materials.

Check out the code on GitLab. Check out the release to download the latest binaries for Windows or Linux.

Vismut Core Rewritten

Sat, 23 Apr 2022 00:00:00 +0000

For version 0.5 of Vismut, I rewrote Vismut Core, the backend library which handles all the node processing. The rewrite made Vismut Core easier to use, less buggy, and easier to maintain.

Before getting started, let’s define some words. These definitions are specific to Vismut Core, and may mean slightly different things in other contexts:

DAG - Short for “directed acyclic graph”. It’s a collection of “nodes” and “edges”.
Node - An operation that is performed as part of generating a texture. For instance “generate a noise image”, or “multiply two images together”.
Edge - A connection between two nodes.

The Old Architecture

Here’s how the old architecture worked:

The library provided a struct called “Engine”, which spawned a thread where it ran an update loop to calculate nodes.
All the Engine’s data, like DAGs, edges, and nodes, were wrapped in Arcs and RwLocks so they could be read and written to without needing to own the data. Accessing data like this between threads is called shared memory.

In the old architecture, the Engine’s data was always accessible through shared memory.

Running the Engine and the GUI on separate threads like this resulted in a GUI that was always responsive. However, there were significant downsides to this approach.

It wasn’t flexible. The library user wants to choose when the library runs. Running Vismut Core in its own thread makes sense for Vismut, but it isn’t a good choice in every case, like for the future command-line interface.

The types were annoying to work with. For instance, to read a node you needed to do something like this: let my_node = engine.lock()?.node(node_id)?.node_type().lock()?;. That’s a lot of code for just getting a node, in the new architecture it’s more similar to this: let my_node = engine.node(node_id)?;.

I never managed to fix all timing bugs. Since changes could be made to the Engine at any point in the execution, changes could sneak in at unexpected moments, causing bugs. To avoid this, I tried to ensure I held locks in the Engine’s loop for longer, but these issues were very hard to debug. Holding locks for longer also meant the GUI had a harder time to get a lock, making the next issue worse.

Getting locks was unreliable. I never wanted to block when executing the user interface, so when getting a lock on the Engine, I just “tried” to get it and aborted if I couldn’t. However, the GUI only updates 60 times per second usually, so sometimes several frames would pass without being able to get a lock, leading to delays in the GUI.

So while the GUI was always responsive, sometimes you had to wait to see the results because it got unlucky with the locks. This didn’t play well with bevy_egui either, which is an immediate mode GUI library I’m using. If I couldn’t get a lock on the Engine to read data from it, I didn’t have any data to give to Egui, which caused parts of the GUI to flicker depending on if it could get a lock.

The New Architecture

Instead of spawning a thread in the library and running a loop there, the Engine is just a regular owned struct. We aren’t using any “shared memory” types like Arc and RwLock, except for a few Mutexes to ensure the Engine “is sync” so it can be sent between threads. The only time the Engine itself uses threads in the new architecture is when processing nodes.

Instead of forcing a constant loop, you get to manually call a “run” function to start calculating nodes. This gives the user control over when the Engine runs, and direct access to the Engine’s data. If you want to run it in a thread you can, and if you want to use shared memory you can, these choices are now left to the library user.

In Vismut, the Engine is sent back and forth between a thread every frame to achieve a responsive interface.

In the old architecture, the user was interacting directly with the same nodes and edges that the Engine used for processing. In the new architecture, there are three different “Worlds”. Each World is a different representation of all the nodes and edges in the Engine, each with its own purpose:

Public World - the library’s interface
Flat World - a world with only one DAG
Live World - for processing nodes

The user interacts with the Public World, and The Flat and Live Worlds are generated from that.

The Public World is the most straightforward representation. This is the public interface, so this is where you add and edit your DAGs. It’s meant to be easy to understand and work with, and can hold several DAGs as well as nodes with DAGs inside them. Before any changes can be processed you need to call engine.prepare(), doing so creates a Flat World from this Public World.

In the Flat World, all the different DAGs in the Public World have been combined into a single DAG. Dealing with things like connections between DAGs, and DAGs within nodes introduces a lot of complexity in the code. The purpose of the Flat World is to reduce that complexity by putting all nodes and edges into a single DAG. Instead of trying to solve the complex problem of nested and sibling DAGs, we’ve simply removed the problem!

After the Public World has been transformed into a Flat World, a Live World is immediately created from it.

The Live World is what actually gets processed in the end. Like the Flat World, this also has only one DAG, but unlike the Flat World, it has its own set of nodes. Each node in the Flat World can become several nodes in the Live World. Having a separate set of nodes for the Live World enables more reuse of logic and is more flexible.

When engine.prepare() is finished the Engine is ready to be processed. To do this, the user calls engine.run() repeatedly if they want to be able to pause processing, or engine.run_until_done() once if they want to wait until it’s done.

This post only describes the basic structure of the new architecture in broad strokes. There are many other interesting aspects, but those are posts for another day.

Conclusion

Here are the two biggest lessons I learned from this rewrite:

Think twice before using shared memory.
Instead of solving a complex problem, consider simplifying it.

I’m excited to have a much more promising architecture now, which will hopefully allow the project to proceed smoothly. The next update will focus on grid snapping!

Code and binaries are available. Do you have ideas for how the architecture could be improved further? Or maybe you have questions? If so, ping @**Lukas Orsvärn** in the Vismut Zulip. 😄

Introducing Vismut

Sun, 06 Mar 2022 09:44:59 +0100

Download Git Repository

Vismut is a procedural texturing tool I’ve been developing on and off since around 2017. After many hiatuses, much learning and several rewrites, it now finally supports its first use case: manual channel packing. 🎉

The only other free and open source tool you can do channel packing in as far as I know is Blender. But the complexity of Blender makes it complicated to use, while Vismut makes it really fast and easy!

Channel packing means taking the red, green, blue and alpha channels from one or more images, and creating one or more new images from them. Games often do this to reduce the number of images needed to represent a material, and thereby reduce memory consumption.

Channel packing is of course just the first small step towards a full procedural texturing tool.

Why Am I Making This?

My first ever procedural textures, created in 2009.

It’s been a long time since I first discovered procedural texturing, and I loved it right from the start. Since then, I’ve looked for an open source procedural texturing tool. I found a few, but none that align with my priorities.

A few years ago I was learning the programming language Rust, and wanted to build something in it, so I decided to build a procedural texturing tool. To my surprise it seemed like Rust would enable me to actually build something like this, which was amazing to me as I’m far from being a master programmer. As time went on I spent an increasing amount of time working on it. Now I’m confident I can turn this into a useful tool, so that’s what I’m doing! :)

Why Use Nodes?

Vismut 0.4’s graphical user interface

What makes nodes so powerful is that you can go back to any part of the node graph at any time and make changes that then propagate through the node tree to generate a new material.

Let’s say you’ve created a “bathroom tile” material. When you’re done with it, you decide to make the tiles half as big. You have a node that controls the pattern of the tiles, so you just change one or two values in that node to make all the tiles half as big, and that’s it, this takes seconds. In a traditional digitally painted workflow, a simple change like this would involve a significant amount of time and effort.

It also allows for a ton of reuse. Let’s say you have created a “painted wall” material, and you want something similar but with the paint more flaked off. You could use the existing material as a base and create the “flaked off paint” effect that adapts to the underlying surface. And that effect could itself be improved and reused in other materials.

This is made even more powerful by the ability to take an entire node graph and turn it into a single node that can be used in other graphs. The more time you invest into this type of software, the more you get out of it as you build up your personal library of nodes.

What Makes Vismut Special?

The interface for an application is crucial. A bad interface can make a program incredibly frustrating to use, or even cause work to be lost. A good interface enables the user to work as close to the speed of thought as possible. A lot of thought and effort is being put into Vismut’s interface, here are the main goals:

Easy to learn
Allow for mastery
Always give clear feedback
Always respond to input
Gets out of the way, so you can focus on the task

Vismut will use physical measurements rather than “percentage of image” values by default where possible. This allows you to zoom out of a material after creation. Physical measurements also give materials a common ground to stand on, making it effortless to combine them.

The backend library Vismut Core is separate from the frontend, so it can be integrated in a game for instance. This means you can take a saved graph—which is no larger than a few kilobytes—and generate textures from it on the user’s computer. This can be used to achieve reduced size of game downloads, greater customization possibilities, and more.

The Future

The plan is to iterate on Vismut towards a useful set of features while keeping the tool as stable and useful as possible along the way. Feedback from users will be an important factor, which is the reason I’m releasing it as early as possible. I’m not only making this for myself, but also for you!

The goal of the next release—version 0.5—is to rewrite the backend to use a new architecture that vastly simplifies the code, is more robust, and makes it easier to create a fluid interface.

After that comes “the grid”. Nodes are always locked to the grid, freeing the user from decisions that make no difference. It also allows for smarter automatic node positioning in the future.

Other upcoming features include saving and loading graphs, a ton of nodes, 2D and 3D previews, and support for variables in the graph. All work is done in the project’s GitLab repository, so look there for an up-to-date roadmap and task list.

Conclusion

I’ve just scratched the surface of a lot of the topics in this post, so look forward to more detailed thoughts in the future! If you’re looking for a program to pack channels with, or you’re just interested, download Vismut and try it out!

I love working on this project on my own, but I think working on projects together with others enables more fun, learning and productivity. So if you’re interested in working on Vismut, join the Vismut Zulip and introduce yourself! I would be delighted to get on a voice or video call to show you around the code, do pair programming, discuss implementations etc. Everyone is welcome, not just programmers! 😀

Receiver 2

Mon, 09 Mar 2020 12:00:00 +0200

Website Steam

Unable to play video

Receiver 2 simulates every internal part of each firearm based on manufacturer schematics and gunsmithing resources. Learn exactly how each sidearm works, including how to load and unload them, clear malfunctions, and operate their safety features.

My contributions

Optimization and other technical work on levels
Advised gun texturers on physically based rendering
Some level design, modeling, texturing
Some lighting

Overgrowth

Fri, 01 Dec 2017 16:38:03 +0200

Website Steam

Unable to play video

Overgrowth is a fast-paced action game created by Wolfire Games over 9 years. I joined the team two years before the game’s release.

My contributions

Gameplay design for some levels
Testing and polishing of levels
Created changelog videos
Many smaller tasks, for instance I put together the art for the Steam Trading Cards

Binding of Souls

Fri, 01 Jan 2016 16:38:03 +0200

Binding of Souls is a third person action game created by 13 students at The Game Assembly over 10 weeks of full-time work.

Unable to play video

My contributions

Helped create the level generator
Helped create the weapon generator
Created shaders for the character and more

Character shader

Since you spend a lot of time looking at the main character, we decided to put some extra work into his shader.

When you start out the game the character is covered in snow that slowly melts as time passes.
The more you roll around on the ground, the dirtier you get.
As you take damage you get bloodier and your clothes rip.

Level generator

Me and another student created the procedural level generator together. It took in any number of hand-made rooms with one or more possible doorways. The generator would find the doorways and attempt to place another room there so that it does not collide with any of the already placed rooms. It was a pretty simple system, but worked well for our purposes.

Weapon generator

To increase the number of weapons in the game I created a weapon generator. It took in several sword blades, hilts and handles, and put them together randomly. It also generated a name for the weapon as well as stats, based on which parts were used.

Cell

Thu, 01 Oct 2015 16:38:03 +0200

Cell is a first person shooter game created by 13 students at The Game Assembly over 10 weeks of half time work.

Unable to play video

My contributions

Updated the asset pipeline to accommodate for texture reuse (see below)
Helped updating the level editor for the project
Trained an artist in Substance Designer

Material editor

For this project we decided that using atlases for the textures would be a good idea to reduce vram usage and simplify texture edits. To make this possible I designed a material system and created a material editor. A material is made up of several textures (color, normal, roughness and so on).

Previously, each model had its own set of textures. With this new system several models can use the same material, making it easier to make changes to all objects sharing a material.

Our model exporting process had been really simple so far. The user would create a model, bring up a dialog that was used to associate a number of textures with the model, and then they would press one button to export the model together with its textures to the correct location in the game folder.

It is important that we do not make this process slower or more complicated since that might frustrate the artists. With that in mind the material editor was created to make it easier to work with materials. This also allowed us to keep the texture exporting process automated. I wrote the material editor in C++ and Qt.

In the end the model exporting process was made simpler since the user no longer need to assign textures before exporting, just click a button. The material editor lists all existing materials for easy editing, and it is really fast and easy to create new ones. Exporting a material to the game folders is only one click as well.

We decided to take this opportunity to pack our textures in the material exporting step. This makes it easier for artists as well as reduces memory usage, game size and the number of texture samples in shaders. This results in that our artists do not have to know where each texture should be packed, as this is fully automated (my Channel Shuffle tool is used for the packing). We save what textures were used to create each material, so if we wanted we could change the packing scheme at any point and batch export all materials.

I had planned to further improve the material editor to give the user more information regarding if a material was missing source files, if it was not exported, if the source textures had been changed since last export and so on. It would also be really cool to create an interface for associating models with materials as that part had to be done manually in an XML file. In the end there was not enough time to add these features.

PBR shader

Sat, 11 Apr 2015 16:38:03 +0200

View shader source code

I created this shader to get a deeper understanding for how physically based rendering works.

Character model created by Joachim Häggström.

Features

Written in HLSL
Directional lights utilizing GGX distribution
Image-based lighting
Metallic/roughness workflow
Allows for overlapping and mirrored normal maps

Problems Encountered

I used ShaderTool to pipe all the data into the shader. While this allowed me to create the shader in a short time span, it also came with a few drawbacks, such as no support for HDR cubemaps and the fact that mipmaps are recomputed for DDS textures when they are loaded. This stopped me from using HDR cubemaps and pre-convolved GGX cubemaps that are synced between the authoring program (Knald Lys) and the shader.

Channel Shuffle

Sat, 28 Feb 2015 16:38:03 +0200

Download ZIP Source on GitHub

Windows | Version 0.10 beta | 2015-01-30

The download comes with both the GUI version (16MB) and the command line version (200kB). The command line version can be used entirely on its own.

Introduction

Channel Shuffle can be used to create images from specified channels (red, green, blue and alpha) from two images. It is written with the goals of being lightweight, fast, easy to use and portable.

There are two parts to this application, first there is channel_shuffle, which is a command line application that can be used independently. Then there is channel_shuffle_gui, which is a graphical front end for channel_shuffle created in Qt.

The application and its source are in the public domain. Find the source on GitHub. Feel free to do whatever you want with the source code.

It’s written in C++, it uses the cross platform library SOIL to load and save images, and the GUI is made in Qt.

I have only compiled it for Windows, but since it was made with portability in mind it’s hopefully easy to get it to compile on other platforms.

Easy and fast to use

Drag and drop an image to one of the inputs on the left to import it.
Select your channels and if you want to invert any of them in the output image using the radio buttons in the middle and the buttons at the top.
Drag and drop the output image to either a folder on your hard drive to save out the final image, or to one of the inputs to keep shuffling.

Example use cases

Flip or invert channels in a normal map without having to open up something huge like Photoshop or Gimp.
Easily and quickly pack many separate textures into fewer ones to lower the number of texture samples in your game.
Execute the command line version somewhere in your pipeline to pack those textures automatically.
Turn four separate grayscale images into one channel each in a single image in just a few seconds.

Claiming Ymir

Sun, 11 Jan 2015 16:38:03 +0200

Claiming Ymir is a real time strategy game created by 13 students at The Game Assembly over 10 weeks of half time work.

Unable to play video

My contributions

Created the water shader
Created the terrain shader
Other shader work
Updated the pipeline to fit the project

Terrain shader

This shader was created and implemented by me during the project to make transitions between different ground textures look nice.

Support for up to 5 albedo + normal map pairs.
Uses a splat map where each texture is used based on the R, G, B and A channels, if all those channels are zero, the fifth texture is used.
The alpha channel in the albedo maps contain height data that is used to make the transitions, enabling grass to stick out of sand etc.
Persistent blood appears on the ground during battles.

Water shader

We decided to create this water shader to increase visual fidelity while also reducing the workload on artists and level designers, this allowed us to better focus our efforts.

Has foam at the edges.
Changes color based on water depth.
Vertex animation.

Galaxia

Sat, 11 Oct 2014 16:38:03 +0200

Galaxia is a space shooter created by 13 students at The Game Assembly over 10 weeks of half time work.

My contributions

Designed and implemented a pipeline for the technical artists (more info below)
Helped set up an art and level design pipeline from scratch
Minor shader work

Unable to play video

Technical artist pipeline for Maya scripts

During this first of our projects, I designed and created a framework for us technical artists to distribute Maya scripts to our artists and level designers. It allowed us to ensure that everyone was using the latest version of each tool, and was used throughout all of the rest of our projects.

The pipeline came with the following benifits:

Simple to set up for users, just set up a single environent variable and restart Maya.
Script updates take effect immediately, without having to restart Maya.
Safe and easy for script creators to release their scripts to users, a script was created to synchronize a release directory on our SVN with the location on the network where the users ran their scripts from.
New scripts could be very easily added to users shelves by updating a list in a script with an icon, a script to run and a tool tip.
Crash logging was automatically handled for all scripts. So if a user experienced a crash, we didn’t always need to hog their work station to figure out what went wrong, but could instead look at their crash report from our work station. We could also use this data to help identify and fix bugs that the user might not even have noticed.
We logged who used what script when. This data was useful to spot scripts that weren’t used for instance. This data was then used to improve tools further and help focus our efforts.

Kravall

Fri, 11 Apr 2014 16:38:03 +0200

Kravall is a real time strategy game created by 11 students at Blekinge Institute of Technology over five months.

My contributions

Created the level editor (more info below)
Lead technical artist
Various art tasks such as modeling and texturing
Level design

Unable to play video

Level editor

The level editor was written as a Python plugin for Blender and had the following features.

An asset handling system, allowing for quickly reloading the asset library
Manual nav mesh creation using a mesh
Editing the world lighting
Assigning functions to objects
Trigger creation
Quick iteration times due to fast exports, hotkey for exporting and camera view from the editor being retained in the game

I also wrote the level exporter and the nav mesh exporter for this level editor.

Unable to play video

Spotlights for global illumination

Thu, 30 Jan 2014 16:38:03 +0200

Download PDF More Information

This is the bachelor thesis I did as part of my technical artist education at Blekinge Institute of Technology. I created a simple OpenGL rendering engine for this project. In it I explore a technique using a reflective shadow map to place and configure spotlights in an environment to approximate global illumination.

The spotlight distribution technique is implemented in a delimited real time graphics engine, and the results are compared to a naive spotlight distribution method. The technique could be used in its current state for applications where the view can be controlled by the developer such as in 3D side scrolling games or as a tool to generate editable indirect illumination. Further research needs to be conducted to make it more broadly viable.

Semest

Mon, 30 Jan 2012 16:38:03 +0200

I wanted more game development in my education. So me and a friend worked on this project full time for two months over the summer. It was never finished, but we both learned a lot and had a lot of fun!

Unable to play video

It was supposed to be an action adventure game inspired by games like The Legend of Zelda: Ocarina of Time and Psychonauts.

My friend did the programming and I did the art.

My contributions

Level design
Modeling
Texturing
Rigging
Animation
Concept art
Game design

Rigging and animation

I learned rigging and animation for this project, and this is the result. It contains basic conveniences such as ik/fk switches, foot roll controls and controls for the eyes.

Unable to play video