[ Jump to content ]

arne.xyz

delivered in beta

In the year of 2020

Lately I had a tough time to figure out how to serve a Unity3D WebGL export via AWS CloudFront from an AWS S3 origin after updating to Unity3D 2020.01 with it’s new WebGL loader. I don’t describe how to connect AWS CloudFront to serve files from AWS S3—Andrew Welch does this neatly in his tutorial (one can skip the last step about Craft CMS, though)—I focus on the special configuration the Unity3D files need.

The new WebGL loader

The new WebGL loader requires that certain files are served in a specific way, contrary to the default web-server configurations.
From the forums:

When hosting such a build on a server, the following http headers should be added to the server responses in order to make the build load correctly:

  • .gz files should be served with a Content-Encoding: gzip response header.
  • .br files should be served with a Content-Encoding: br response header.
  • .wasm, .wasm.gz or .wasm.br files should be served with a Content-Type: application/wasm response header.
  • .js, .js.gz or .js.br files should be served with a Content-Type: application/javascript response header.

The Apache configuration example makes it even clearer:

<IfModule mod_mime.c>
# The following lines are required for builds without decompression fallback, compressed with gzip
RemoveType .gz
AddEncoding gzip .gz
AddType application/octet-stream .data.gz
AddType application/wasm .wasm.gz
AddType application/javascript .js.gz
AddType application/octet-stream .symbols.json.gz

# The following lines are required for builds without decompression fallback, compressed with brotli
RemoveType .br
RemoveLanguage .br
AddEncoding br .br
AddType application/octet-stream .data.br
AddType application/wasm .wasm.br
AddType application/javascript .js.br
AddType application/octet-stream .symbols.json.br

# The following line improves loading performance for uncompressed builds
AddType application/wasm .wasm
</IfModule>

On AWS

The easiest way to serve the Unity3D WebGL files via AWS CloudFront from an AWS S3 origin with the correct configuration is to set the correct Content-Type and Content-Encoding in the S3 bucket. Then CloudFront serves them to the user with the correct configuration directly.

To achieve this, one can set the correct metadata of the files via the AWS S3 management console: Select the file, open the “Actions” menu, select “Change metadata”, set the metadata in the opening pop-over on the right-hand side.

Screenshot: AWS S3 console with opened edit view for file metadata

At one point I wrote a small helper script in Python, using boto3, to set the correct metadata after I uploaded the files manually:


Finally, the next step—that I didn’t took, because it worked for me at this point—would be to upload the files with this script and set the correct metadata directly.

Damien Newman versucht mit The Design Squiggle den unklaren, kreativen Prozess des Gestaltens hin zu einem konkreten Ergebnis zu beschreiben:

The Design Squiggle is a simple illustration of the design process. The journey of researching, uncovering insights, generating creative concepts, iteration of prototypes and eventually concluding in one single designed solution. It is intended to convey the feeling of the journey. Beginning on the left with mess and uncertainty and ending on the right in a single point of focus: the design.

…

So as I pursued my own career in design, I began to write proposals and pitch the process of design using the terms: Abstract, Research, Concepts and then Design.

2009 schrieb er zur Entstehung:

Years ago I dropped a simple illustration into a proposal to convey the design process to a client. It was meant to illustrate the characteristics of the process we were to embark on, making it clear to them that it might be uncertain in the beginning, but in the end we’d focus on a single point of clarity. It seemed to work. And from then on, I’ve used it since. Many many times.

(via Daring Fireball)