September 2018 Summary
- Marketing Research
- Contact from Maurice Thomas, who wanted to do some voice acting for us. I got him to replace a couple of parts I had filled in for, including the ep. 2 news anchor and one of the military astronauts.
- Article on barcode printing completed on commission.
- Web/Social Media art
- Animation tests for PC-PressConference sequence.
Today I’ve been testing deployment of our site onto a Digital Ocean “droplet” VPS and using Amazon “S3” storage for backups and repository data. This is a diagram of where I’m heading with this, although it’s not quite all working yet:
- My Ansible playbooks work as well on this server as on the old one.
- S3FS does indeed work on the Droplet (not allowed on our old VPS).
- “Site” and “Repo” operations are still entangled, but I have a plan for separating them better.
- Our office upload speeds are really slow for this kind of work, at 0.5mbps (residential ADSL, way out in the country).
- I’m rewriting the backup and restore scripts to store data in S3 rather than here at the office, so the transfer speeds are faster.
- This will increase our total capacity for a repository from about 30GB to as much as a terabyte.
- It’ll save money — costing about $10/month initially, compared to the $40/month we’re paying now.
- We will lose personal sys-admin support, as Digital Ocean is basically “self-serve”.
- With Droplets, it’s practical to rollover the site for upgrades or migration by creating and destroying VPS ourselves, which will reduce downtime and allow for trivial rollback if something goes wrong.
- We’ll probably need special servers for high-volume download traffic when we release, not pictured here. Current traffic is not demanding.
S3, DAMS, and Subversion
Just a quick update on the IT prototyping work. This is kind of technical, but might be handy information if you are thinking about implementing something similar.
As I’ve mentioned, I’m planning to use S3 storage to store digital assets in TACTIC and ResourceSpace. However, we are going to still be using Subversion for awhile longer, while we test out the Digital Asset Management System (DAMS).Since I was planning on this already, and restoring from backups at our office site was unreasonably slow due to our internet service, I decided to use S3 as an intermediate for backups and restores. This has worked well so far: deploying the site, restoring the repo, and restoring the site from backup each take about 30 minutes to run, using S3 for backup storage. That’s a big improvement over the three or four days it took to restore from a computer at our office.
I also thought that it might be worth trying to use this storage for the Subversion repository we are currently using. Doing so would reduce the size of Droplet server we need to run the website, and thus save costs.
Sticking to the packages that are already available in the Debian archive, there are three ways to make S3 storage available as a filesystem:
S3fs simply mirrors the limited semantics of S3. It will fail if you try to append to a file, as I proved by trying to install Subversion there (I kind of expected that to fail, but I tried it anyway, and indeed it does). The great thing about s3fs, though, is that it maintains a simple mapping from files to S3 objects, so the data could still be read even if the software platform becomes unavailable for some reason.
S3ql implements a complete POSIX-compliant filesystem, but the cost is that the data represented on the S3 server is much less intuitive.
S3backer implements a single file represented in blocks — essentially a block device. You can then deploy a filesystem which uses that file as a driver (or “container file”), and this will also implement a POSIX compliant storage.
Notably, there is a bug or conflict between the current s3ql package in Debian 9.5 (version 2.21-dfsg-3) and the current Amazon S3 implementation, which fails like this:
s3ql.backends.s3c.S3Error: AllAccessDisabled: All access to this object has been disabled
This is apparently fixed in version 2.26-dfsg-4, because that version is what I get on my Ubuntu Studio 18.04 workstation, and it works. I was able to get this working by using the 2.30 version from stretch-backports.
I’m testing this out to prove it’s possible, but I don’t know if I actually want to use an s3ql filesystem with Subversion in production. There is a small, but real risk of data loss with s3ql, which would have the potential to be very disruptive to the project (not a complete loss, obviously — we have backups), and the alternative of just using a larger Droplet for the server is not too expensive for as long as we’re likely to continue using Subversion (and we shouldn’t need to worry for TACTIC or ResourceSpace).
Defining the NPR Look for Lunatics
It’s not strictly a 2D cartoon style, since the transparency and reflections do make use of physics-based simulation (ray tracing) features in Blender. The style combines Blender Internal’s “toon” shader with Freestyle inking and ray-traced reflections. The transparency with ink lines requires some compositing as I explained in an earlier production log post.
The result is a mostly-flat look, but pushed just a little bit beyond it. And it’s bright, colorful, and shiny – befitting the optimistic vision of the future that “Lunatics!” embodies.
For the glare in some of the space shots, I decided to use a hex star filter – an effect that hasn’t seen much use since the disco era, but I really like it, so I’m going to use it!
And of course, there’s the harsh lighting in space that will dominate a lot of the rest of the series for exteriors – I wanted to get close to the reality of space lighting, although also to evoke some of the feel of early “artist’s concept” drawings of spacecraft as I remember them from the early “space age”.
If you’ve been following this project for the last few years, you’ve probably seen all of these images (maybe not that last one), along with others in a less-developed state. But I thought it was effective to put these together to define what the look is that I’m trying to achieve.