May 2015 Newsletter – Lunatics Production Log

Tour of the Sets

Our biggest current challenge is finishing sets for the “Prolog” or “No Children in Space, Part 1” release. We’ve hardly started on the sets for Parts 2 & 3. But we are making progress on them all. So let’s do a quick tour of where we’re at with sets, and what we have left to finish for “Part 1”.

“Aquarium Room”

This is the setting for both the preflight press conference and the “suiting up” scenes. The name comes from the glass quarantine enclosure which is there to keep the astronauts from getting sick right before they leave on their trip into space. After the press conference is over, the same room is used for testing and putting on the spacesuits for the flight.

Terry Hancock collected many photographs of the real site and drew a floorplan based on those, then Sathish Kumar took over and created this 3D model of the set, based on those sources. It already looks very good, although there is quite a bit to do in finishing up materials and textures. There are also some missing props — the clock, some lighting strips on the walls, and so on. We’ll also need to see what it looks like with Freestyle lines turned on.

Aquarium Room Test 01 — View from the astronauts’ side — slightly earlier version, with fewer materials defined.

Aquarium Room Test 02 — A view from the table, showing a more realistic background for shots of Hiromi speaking.

The file has a high polygon count — over 200,000 vertices — and is really taking a bit too long to render (about 10 minutes on the Director’s workstation), which is pushing the limits for animation. We’ll probably be looking for some ways to optimize it. The most obvious culprit is probably the curtain behind the back window visible in the last two stills here. We’ll probably replace that with a textured billboard for most shots, since the perspective won’t be very obvious anyway.

Aquarium Room Test 03 — The gadgets on the back table are used for testing spacesuits.

Revised Soyuz Interior Set

Chris Kuhn, who has been responsible for almost all of our spacecraft exterior models has agreed to also do some of their interiors. The first task was to clean up the interior model of the Soyuz that we had been working on. He’s actually mostly re-modeled it, reducing the polygon count considerably in the process. This makes it into a more manageable, as well as more accurate set.

There’s still some tweaking to do on the relationship between the elements. The control panel is a little out of reach here, for example. The “childseat” looks a lot smaller when you have the adult couches to compare to, doesn’t it?

LTS Lander Interior

Chris also just completed work this week on a draft for the interior of the Lunar Transportation System Lander, which is featured on our cover this month. This is the setting for quite a bit of Part 1 and Part 2 of the pilot, “No Children in Space”, along with the “Transfer Module”, which we have not yet started on.

Central Room of Lander Interior Set — Wardroom of the LTS Lander’s interior set, modeled by Chris Kuhn. Here we can see the engine header (center, floor), the door into the crew cabin pocket (center), the cargo operations console (left), and the galley (right). The corridor to the right is the access to the cockpit.

The LTS Lander is meant for use in low gravity and no gravity, and the interior is laid out accordingly. The cockpit presents an interestingly challenging geometry. Since I decided to eliminate a separate “command module”, and simply run the Service Module from a console on the Lander, things get interesting.

It turns out that the most natural orientation for the pilot for flying the combined Lander + Service Module stack is not the same as the one you’d prefer for landing the Lander alone on the Moon. So I took advantage of this by orienting the two consoles 90 degrees from each other, facing the Z+ and Y+ directions, respectively. For landings, the pilot stands with feet in stirrups, just as the pilots for the Apollo LM did, putting them close to the windows for a better view. For flying the whole shuttle, though, the pilot works at a console facing the Z+ direction, out past the cargo area and “transfer module”. This is the best view for docking and other maneuvers the pilot needs to control, and it positions him for comfort during accelerations.

Cockpit of the LTS Lander — The LTS Lander also serves as the command module for the LTS Service Module, which is unmanned. The SM controls are on the panel shown above, facing the Z+ direction, while the lander control are off-camera to the right, allowing the pilot to look out in the Y+ direction, standing in stirrups in the Z- direction (the floor). In the back of the shot to the left, you can see the engine header in the wardroom.

The LTS is a space-transfer vehicle, and so is not designed for the high gee stresses of a launch vehicle. Instead, its maximum acceleration is much gentler — just around one gee at maximum (which occurs at full-thrust when the tanks are nearly empty), and usually less. For this kind of stress, a lightweight foldable “acceleration hammock” is fine for protecting both crew and passengers. The seats in the transfer module will be of the same type as this one.

Wireframe view of the Lander Interior set in Blender — >Overview of the Lander-Int set in wireframe in the Blender 3D view. Note that marker near the center of the wardroom that shows the orientation of the X, Y, and Z axes: blue=Z+, green=Y+, and red=X+.

Outdoor Sets (on Earth)

The outdoor sets are the ones that I (Terry Hancock) have been concentrating on personally. These are made challenging by a number of factors: the large true size and distant horizons in the background, producing realistic looking vegetation, and filling in background details, such as buildings. With so many variables, it’s challenging to get a consistent style for these shots, which is one reason I’m seeing to them personally.

In the Preview Trailer, you’ve already seen three of these. The “Kazakhstan Railway Ext” set:

Kazakhstan Railway Exterior set with painted billboard plants — The Kazakhstan Railway Exterior set, which showed the advantages of using painted 2D billboards for plants.

The “Gagarin Start Ext” Baikonur Cosmodrome launch pad set:

Soyuz Rollout — Still of the final set with particle-billboard plants and other features.

And the “Train Station Ext” set in the town of Baikonur:

Train Station Exterior set — Urban exteriors like the train station present less of a problem with the horizon, but then we have to fill in a lot of background detail, with low-poly buildings and trees. This shot includes work from Sathish Kumar (the industrial-sculpture sign for the train station, benches, and lamps); Terry Hancock (buildings, landscape, lawns, including the painted grass billboards, and the pots and fences); Chris Kuhn (the Steam Locomotive on display); Bela Szabo (base character meshes including the Hiromi model and Georgiana models); and Keneisha Perry (finished models of the boy from the train in the background, and the pinafore dress version of Georgiana in the front). The trees are from Yorik’s Blender Greenhouse, created using ngPlant by Yorik van Havre.

The set for the “Stele to Science and Space” monument used texture-based techniques for handling grass, which doesn’t work as well, and will need to be reworked:

Stele to Science and Space - experimental exterior — I created this experimental version of the set for the “Stele to Science and Space” monument, but clearly it is somewhat behind the techniques I’ve developed since, and it will need to be updated before we can use it. Also, this particular image is 2D-composited, since the monument and the park haven’t been combined into a single model yet. The stele itself was created by Sathish Kumar.

We’ve completed several elements for the “Glory to the Conquerors of Space” monument, including the color and relief maps for both sides of both walls (by Terry Hancock — the back side is included in our January newsletter), and the model of the monument (by Sathish Kumar). We have a map for the park and urban area around the monument, but none of that is modeled yet. It’s going to be a little challenging, because this is a terraced landscape (it’s on the slope looking towards the river that passes just east of the town of Baikonur).

Still incomplete monument — We have the texture elements for both sides of these walls at the ‘Glory to the Conquerors of Space’ monument, but there’s still quite a bit of work left to do on it. We haven’t assembled all the textures onto the monument itself, and we haven’t really started on the parklands around it.

What’s Left?

Quite a few sets are still missing for finishing the whole pilot story, so I’ll just focus on the ones still needed for Part 1 (not counting the started, but not finished sets mentioned above):

Building 254 Exterior – a fairly simple exterior of the building, for the scene where the astronauts are walking out to get on the bus to the pad.
Mission Control Room – Shots of the controllers will be intercut with the spacecraft shots during the launch.
Cosmonaut Hotel – Hallway area in the hotel, for the traditional door signing.
Cosmonaut Trees – Small outdoor set (backdrop of trees) for the tree-planting ceremony in the Baikonur montage.

Most of the other sets above need additional tweaks before final animation. Most of the work over the Summer will be on the additional sets for Parts 2 & 3, including the series regular sets for the colony which will debut in Part 3.

Creating Distant Horizons

Of course, in 3D animation, even the “outdoors” are really just virtual sets, and creating these presents some special challenges. This is the part that I (Terry Hancock) have been focusing on creating.

The most obvious problem is with sets with “distant horizons” in them. Obviously, it’s not too practical to make these to true scale, and we need to cheat the background in some way. This can be as simple as using a backdrop image, like this “candyfloss clouds” background I created to use for the sky behind the Soyuz gantry during some of the launch shots.

Candyfloss Clouds Backdrop — Pink and puffy morning sunlight on the clouds at the Soyuz launch gives a fairytale feeling to some of the shots of the launch sequence. This image was created by digitally tinting a photograph of real clouds (original credit: viZZZual.com@Flickr) and combining it with a gradient sky effect.

But sometimes, we need to see the actual ground going out to meet the horizon, especially if the camera is going to be moving, so that we can see the effects of parallax. This was particularly true for the “aerial shot” from above the top of the gantry. You can see a long way from up there, and so the model needed to show that.

Two-Minute Tutorial on creating the illusion of distant horizons in sets.

This tutorial doesn’t say much about the billboard plants. I’ll have to do another one on that topic, but I experimented with how to get decent looking plants extensively when I was working on the “Kazakhstan Railway” set. I originally thought I’d get the best results with low-poly 3D modeled plants, but these resulted in really slow renders and they generally looked terrible, anyway:

Railway set with low-poly 3D plants — Test of Railway with the low-poly 3D modeled plants — not so good.

I found that the best solution was to use hand-painted billboards (planes with images that are constrained to always point at the camera). These look really convincing, and the fact that they are really flat planes is really not noticeable at all. Using lots of them creates plenty of parallax effect which masks any oddity about the individual billboards. This would probably break down if the camera circled around the plants, but that’s actually a very rare case (we’ll solve it if it comes up).

Railway set with painted billboard plants — The 2D painted billboard plants are a lot more convincing.

Other News

Well, there’s usually some bad news in this section, and I’m afraid we’ve had a lot of extra or underestimated work this month. It now seems likely that even the “end of May” was overly optimistic for releasing “Part 1”. But I think there’s still a good chance we’ll have the modeling finished by then. And I don’t really regret the stuff we have been working on — solving these kinds of problems are a major reason for doing this project.

So here’s some of the infrastructure work we’ve been working on:

Website Transition Issues

The transition to the new website has been a lot rockier than I had anticipated, and much of my time this month has been focused on fixing problems with the site.

Switching to a more popular platform has made us more vulnerable to scripted attacks. We received over 17,000 login attempts in one day (in other words, someone was attacking our server with a brute-force password-cracking script). This has forced me to pay more attention to how our Apache configuration is set up, and I’ve been making an effort to make it more secure. I’ve installed “fail2ban”, which is intended to catch an attack like that and stop it or slow it down by blocking IPs with such suspiscious behavior. So, I’ve spent a lot of time learning to use new tools and deploying better site security.

There are still a lot of usability problems with the website.

The RSS feed button is wrong (still points to the old Plone site).
I haven’t checked the other social media buttons, but there might be other errors.
The “Episode” credits and download pages were terribly mangled by importing into WordPress, and I’m going to have to make a number of changes (I think that I will find a way to connect the downloads directly to the Resource Space instance, with a Theme or Collection or just a tag-based search).
The design of the “Production” tab is still pretty incomplete.
There’s also some added functionality that isn’t there yet: the progress bar widget for the Patreon page, and I had intended to try adding a Project Wonderful add on the sidebar (it’d be great if we could make enough ad revenue to offset the costs of hosting).

Getting Ready for Business

Honestly, this part is a little scary for me. I’m considering that we might need to get some consulting help on this step, but if we are to actually follow through on our commercialization and sustainability promises, we’re going to have to start handling accounting and money through the website.

With more than 50 artists to be included in profit-sharing calculations, it’s not going to be practical to manage them with paper or spreadsheets alone. I think we’re going to need some kind of accounts management system, so that people can simply log in, get their account status, and if there’s money in it, be able to transfer it to their PayPal or bank accounts. For me to do that via email and manual PayPal transfers would be very error-prone and time-consuming, especially when I’m supposed to be producing and directing an animated series!

So I think we’re going to need some automation there. But it’s a big step. There’s no shortage of open source applications for doing this kind of thing, but they also usually include a lot of other features, and it’s very easy to get into overkill. This is the territory of “Enterprise Resource Planning” (ERP) and lot of other “Three Initial Abbreviations” (TIA). I am “quaking in my stylish yet affordable boots.”

Some of the packages I’ve been looking at:

Odoo (until recently called “OpenERP”) is Python-based and very complete. It also has some project management features that I could use on other parts of the project.
LedgerSMB is Perl-based, and also very complete. But both of these packages are also very complex platforms to learn, which might mean a lot of down time for me while learning them.
FrontAccounting has a really dull name, but appears to be small and relatively simple. It’s positioned as a competitor for QuickBooks, and is a PHP/LAMP platform based on a fork of WebERP. It also uses a MySQL backend, which is convenient, since we use that already.

I haven’t quite decided if this is something we must do before our first release, or if it can wait until we have more accounting data to manage. I do feel a bit silly installing a large web application platform to manage accounts of a few pennies. On the other hand, I’m a little worried about getting blindsided by technical problems if things do grow as we hope they will.

If anyone reading this has experience with these packages and wants to give me some advice about which to choose and how to deploy it, I will definitely listen.

Resource Space Migration Continues

What can I say? It’s a lot of resources. I’ve moved over 200 items into the DAMS from the SVN. This is mostly reference material that is not directly needed to render shots for the show. Instead, you’ll be able to find and preview this content individually, through a system of metadata and keyword searches (as described in last month’s newsletter).

Migration of data is probably going to take weeks more work, although it generally doesn’t have to hold up production. There will also be some new data that I’ve had on my own computer, but not included in the sources at all. And there will be many items, such as Blend files for sets, which will appear in both the VCS and DAMS.

Basically, it’s one of the things I do during downtime, when I’m thinking or waiting on other things to happen.

You can see this work in our
DAMS:

DAMS Screencapture — Query returning 58 resources associated with the pilot episode of “Lunatics!”, from our Resource Space DAMS.

Reducing the Size of our Source Tree in the Subversion Version Control System

As we move content into the DAMS, of course, we’re also removing a lot of extraneous content from the VCS. This has reduced the “Library” directory of the VCS to under 2.5 GB, which is a big improvement.

Reducing the size of the “Episodes” tree is a lot harder, due mainly to the large number of sound recordings. Probably, I will be keeping the compressed “.aupz” Audacity project files in the VCS, while putting the original “.flac” voice takes into the DAMS. The final “.flac” mixed audio can be generated from Audacity, so we probably don’t need to keep that in the VCS. I expect that Ardour project files, like Kdenlive project files will be small, since the data is linked rather than copied.

The designers of Subversion really did not have large multimedia files, and the result is that in many ways, it’s a poor fit for multimedia projects.

This has resulted in the VCS being awkward for some contributors to use, which is why I think it’s important to optimize how we use it as much as possible.

Here are some particular problems we’ve run into:

Subversion doubles the disk space used for the local copy, because it keeps entire revisions in its “.svn” control directory for comparisons. This is a non-issue for small files like computer source code, but can be devastating with the many large files we use.
Likewise, Subversion is not as efficient about transmitting data (not as efficient as rsync, for example), and so a lot of bandwidth is needed to do updates and check-ins.
Since multimedia workflow often involves copying data into an editor and manipulating it directly, rather than simply keeping links, the original data isn’t strictly necessary. Do we keep it or not? Keeping it is redundant data which makes the source tree much larger, but losing it means we lose the transparency and openness of our process.
Multimedia applications can be finicky about their files. Audacity creates a project file, but it also creates a cache directory in which clips of audio are stored for each project. The files in this directory are not added by the artist, and would have to be manually added or deleted.
Subversion has to treat almost all of our files as “binaries”, which means that it can’t merge changes to a single file the way it can do with software (or other text documents). This throws away quite a bit of the functionality that makes Subversion valuble to programming projects.
Organization into a strict hierarchy can be problematic, since individual files may have multiple uses or associations. Finding things can be difficult.
The web-based interface for Subversion, Trac, does not have many tools for previewing the multimedia files, such as Blend files, which make up the most important part of our source data. This means you often have to download just to see what something is.
Attribution and other metadata is tracked only according to who actually checks files into the repository, which is not always the person who created the work. So we can’t use this as a basis for building our credits.
It’s not impossible, but it is harder to check out individual files or directories, versus updating the entire tree — which relates back to the assumption by the VCS developers that the entire source tree is relatively small, while ours contains a lot of large files.

If we had the resources to do it, I’d like to see the version control features we use in Subversion merged into our DAMS, but that would require a considerable amount of design and development work. It might become a future project goal, but for the present, we’re just having to define a workflow around using both types of systems.

Interviewing CSU Interns

Of course, Keneisha Perry will officially be working as an intern this Summer (although she’s already been working on the project for awhile now.

I’ve received additional internship applications, which I’ve followed up in email, and I will be making final decisions on that this week. We should have that all settled before the end of this month. We’re primarily expecting to get help in the sets modeling department — interns will mainly be working on sets for Parts 2 and 3 of the pilot story, “No Children in Space”, including some of the main sets for the series.

Recent Posts

Recent Comments