May 2018 Summary

HIGHLIGHTS:

Getting my domain registrations moved off of Register.com.
Texture finishing for Soyuz Launch Vehicle & Orbiter.
USB stick figurine model created by Keneisha Perry.
Shroud separation animation (First attempt – I think I’ll need to use a different method).

USB Figurine Design Render:

May 1, 2018 at 4:00 PM

Soyuz Launch Vehicle Texture Test

Test render of Soyuz-SF launch vehicle, with some textures and coloring fixed. Still tweaking!

Model by Chris Kuhn.

May 2, 2018 at 5:07 PM

Still Working on the Textures

I’m about through with the stages. Revising the adapter and shroud now.

Also this model doesn’t include the orbiter, so I’ll need to either link it or copy it for the launch sequence (the shroud ejects during the corestage burn, so it will be visible on top of the rocket for much of the launch sequence.

And yeah, this particular pose would never happen in a launch — it’s just so I can see the separate components.

Another issue are the red “remove before flight” components at the bottom — they’re still here, because this model will be used to create the ground model in the launchpad set. I will make some minor changes to the “flight” version, which will eliminate these parts.

I’m about through with the stages. Revising the adapter and shroud now.

And yeah, this particular pose would never happen in a launch — it’s just so I can see the separate components.

May 3, 2018 at 4:02 PM

Soyuz Launch Vehicle Materials / Texture

I think my work here is done.

Also, just for the sake of curiosity, I also rendered with and without Ambient Occlusion calculations, just to see how much time I was saving by baking the AO into the texture. Turns out it’s a lot: 18 MINUTES versus about 33 SECONDS, or about 36X speedup for baking. So yeah, that was a good plan.

Actually, there’s also the question of whether I really wanted AO or not — but I think it adds more definition to the model.

May 4, 2018 at 4:00 PM

Blender 2.78 Freestyle/Depsgraph Bug!

I encountered this bug today in Blender 2.78c, which is standard in Ubuntu Studio 17.10 (which we are currently using). Ouch!

This shows up when you run blender with the –enable-new-depsgraph switch: it renders the Freestyle lines in the wrong place (and only 1/4 of the frame).

The good news is, this apparently has already been fixed:

Using –enable-new-depsgraph causes the lines in freestyle rendering to not be in the correct location(From the Blender Foundation bug tracker).

Now I just have to get a version after the patch was applied. I think there’s a good chance it’ll be fixed in 2.79, which is what is in the next Ubuntu Studio (18.04), which is already out. So I’ll be looking into that.

May 5, 2018 at 2:36 PM

Consolidating Accounts

Quite awhile back, I created a separate account originally with the intent of having a monthly-support option instead of per-episode, thinking some people might prefer that.

Absolutely no one backed it. So, I guess not.

Since then, I used it as a personal account to back some other projects. But logging into two accounts on Patreon is kind of annoying. So today, I canceled the pledges to Morevna Project and David Revoy, and then added projects here including those two.Among the projects I’m now backing:

Timid Clover is our character animation lead, who has her own page with other projects she’s working on.
David Revoy is a comic artist making free-culture comics, and also working on Krita (open source digital painting tool).
Morevna Project is both an open movie and open source graphics/animation development project.
ZeMarmot is a Gimp-based open movie which also contributes to Gimp development (open source bitmap editor and painting tool).
Johnathon Thomas is the founder and main developer of OpenShot. I use Kdenlive for video editing, but OpenShot is another open source non-linear video editor with some nice features — maybe someday it will be a better alternative?

The others (Mc, Tavmjong Bah, Øyvind Kolås ) are software developers working on Inkscape and Gimp.

All worthy projects (obviously I thought so!), so check them out.

It’s also nice to get one integrated news feed.

May 5, 2018 at 10:10 PM

Spoof Logos

I’m honestly not 100% sure we need to do this, because I think most of what we’re doing with them falls under “fair use”, at least with an adequate “this is a work of fiction” disclaimer. We certainly do refer to some real governments, government agencies, and companies in “Lunatics!”, although we’re clearly talking about fictitious futures for them.

However, there is a long tradition of making logos that sort of look like the real company’s logo without actually infringing trademark, and there are certain legal battles with very rich people who can muster armies of lawyers which I’m not that interested in getting into.

Besides, it’s kind of fun.This is a spoof of the logo for “RKK Energia”:

It’s one of the main contractors involved in the Russian space program. It’s going onto one of the train cars bringing the launch vehicle to the pad. I might revise some of the artwork I’ve already created with the Energia logo, to use this instead.

The first one I made was for the rocket manufacturing center:

This one’s pretty small in the frame, so I was a little lazy with it — that label literally says “Rocket Factory” (I think). I looked up the original on Wikipedia, which looks like this:

(This labels says “RKT / PROGRESS”, which is the actual name of the site where the rockets are made).

Not sure how much more of this I need to do.

I’m getting pretty close to finishing the materials and textures on the support train for the launch pad, which I think is the last piece I need to work on in that file before re-integrating it with the landscape part of the set.

I’m pretty sure I’m going to have to do some fixing in the landscape model as well, though — I remember there being some alignment problems (in the distance, the railroad tracks switch from the modeled tracks from the “mech” model to drawn lines on the ground surface — which is touchy to line up and looks pretty funny if it’s not done right.

I’m eager to get to the point of making final renders for the “rollout” and “launch” scenes at the pad. I thought I was going to be there a little sooner, but I’ve spent a lot of time on UV unwrapping and drawing lately.

May 7, 2018 at 4:00 PM

UV Mapping Multiple Objects for Decals

The “Cosmotrain” is actually several different objects.

I’ll use separate auto-generated UV maps for the Ambient Occlusion baking. After doing those manually for the launch vehicle, I realized that they don’t really need much editing — and what I was doing was mostly correcting for bugs that arise because of bad UV mapping (the AO bake produces weird results for surfaces that overlap in UV space).This time, I thought it would be convenient to just use one “decals” image for all the cars, especially since I only need a partial UV map to do this with. So I exported each partial UV map to a file — the significant parts you can see easily here, but I also exported a small extra face, which I lined up with the edges of the UV mapping image to get them registered correctly in Inkscape, which is what we’re looking at here.

I’ve started on the decals, but still have several to add on the upper part (which is the “transporter-erector” car itself).

I’ve been going back to my reference photos a lot for this, although there’s actually quite a bit of leeway for creativity here, because they actually have used several different train engines and cars, and they replace them now and again. Still, the photos are the best guide I’ve got to what’s plausible.

May 8, 2018 at 4:01 PM

Tanker Car / Style & Testing

Eventually, I will have a more specific style / look sheet worked out, but I still find myself tweaking and working trial-and-error to get the balance between realism and toon-style that I want. This isn’t there yet, but I’m working on it.

May 9, 2018 at 4:00 PM

Test Render w/ Textures

Starting to see the results of applying baked ambient occlusion and decals to the full mech model for the Soyuz launchpad and launch vehicle.Applying the textures is a pretty tedious process: as far as I can tell, it’s necessary to make each material on the object use the same ambient occlusion and decal textures. But I’ve been working on it — here’s the Soyuz ground model and the Transporter-Erector, with updated materials and textures.

This is still the “mech” model, not the completed set.

Soyuz and related models by Chris Kuhn.

May 10, 2018 at 4:00 PM

Oops.

Not sure what I did wrong, but it looks kind of cool.

Probably, for some reason the set lighting isn’t illuminating my linked mech model.

But anyway, I’m trying to put the updated mech model back together with the set. Many things look like they need tweaking — the ground surface texture looks coarse and the scale needs to be checked. Maybe one or two more days on this set will get it where it needs to be, though.

Not sure what I did wrong, but it looks kind of cool.

Probably, for some reason the set lighting isn’t illuminating my linked mech model.

May 11, 2018 at 4:00 PM

Launchpad Mech in Set

I’m now getting the Launchpad mech properly linked into the Launchpad-Ext set. The lighting problem from yesterday appears to have been materials not having the “cast alpha shadows” option set (because of the “cloud” layer) A number of things could be detailed better in this render:

Concrete for the pad itself
Surface textures (roads, sidewalks, etc)
Buildings.

The control panel is also working, allowing me to set poses and animate the rollout and launch sequences.

Approximately one-minute to render as-is.

Model by Chris Kuhn.

May 12, 2018 at 4:00 PM

Scene-by-Scene Status of “No Children in Space” Pilot Story

Detailed breakdown of the first thee episodes, by components and scenes. Detailed explanation on our Production Blog and full-size image.

May 13, 2018 at 4:00 PM

Moondust is Dangerous Stuff

This isn’t quite as much news as the clickbaity headline suggests, but it is true that moondust is pretty harmful.

Another problem with it is that it’s in a completely unoxygenated environment, so when you mix it with air or water, it tends to react. And that will happen if it gets into lunar habitats.

With water, it can become pretty corrosive, which means that if water leaks from a habitat into its foundations, it can produce acids which may eat the metal, which could obviously be bad news for holding pressure.

It also needs to be thoroughly cleaned from equipment and suits to avoid bringing it into the habitat.

The smell is reportedly similar to the smell of black powder (a type of gun powder), although it’s not chemically similar.

May 17, 2018 at 4:00 PM

Docking Maneuvers

This is a quick test render I did of the Soyuz orbiter model, composited with the space station model. This is a mock-up of a shot I’ve been thinking about using in episode 2.

Today, I spent some time working on the UV unwrapping of this orbiter model for the decal / detailing textures. Tomorrow I will probably be drawing the decals. Then I’ll merge a copy of this model, posed in the launch configuration, with the flight launch vehicle model — that’s how we’ll get the parts of the launch sequence where the orbiter is exposed (after the shroud is ejected).This week has been mostly some (unplanned) administration work so far — we’ve had some trouble getting our domain registration transferred to a new registrar, which has involved many emails and a couple of phone calls. It’d obviously be really bad if we lost it, but I think we’ve done everything we can to prevent that at this point.

May 18, 2018 at 6:07 PM

Soyuz Orbiter Work-in-Progress

Not quite there yet. The Orbital Module (OM) and Descent Module (DM) segments (the green parts) are pretty much finished, but I haven’t really started on the Service Module (SM) and the solar wings need some revision (for one thing, it looks like the panels themselves are textured wrong-side-up).

So I’m a little behind where I hoped to be at the beginning of the week, but really only by a little bit.

I’ve UV-unwrapped all the components, creating a combined UV map like I did for the Cosmotrain:

Also, I realized there is a better way to get the UVs correctly aligned:

Export each UV map to an SVG file
Open each SVG file in Inkscape
Select the UV map in Inkscape, and “COPY”
In the combined file, “PASTE IN PLACE”

That makes sure the UV map is positioned correctly on the page (by which I mean the viewport defined by the pixel-size of the texture image). I had been manually aligning them on the Cosmotrain, because importing the SVG directly doesn’t put it in correct alignment, normally.

I defined both the “Decals” and “Bump” textures in this Inkscape drawing, and then exported them to PNG files.

I also created a procedural “fabric weave” texture for the (cloth) thermal blanket surface on the modules (the green part is the fabric). It’s basically just two crossed “Wood” textures (which is just a sinusoidal striped pattern).

This is a bit subtle to see in this picture, but will show up in some close-ups of the orbiter.

May 20, 2018 at 4:00 PM

Soyuz-SF Orbiter with Textures

Okay. I think I might be done with this now. Time to move on to the next steps.

This is the orbiter with decals and bump-map detailing completed.

The window material is actually my first use of “Mask transparency”. I’m planning to composite this exterior model with a match-moved shot of our interior set model for at least a few shots.

Also, you can see my valiant attempt at a thruster-pack entirely as a bump-map. Yes, I could have modeled it instead, but it’s really just a greeble.

I created the “cloth” look with two crossed “wood” procedural textures and a bit of random “voronoi” added to create variation. I also added some creasing to the bump map.

The solar panel textures are completely regenerated.

Next I think will be to freeze a copy of the folded version and combine it with the launch vehicle for the flight/staging sequence.

May 21, 2018 at 4:00 PM

Project Management Article in OpenSource.com

My second Lunatics-related article for OpenSource.com came out on Friday:
“Choosing the right open source tool for movie project management”The first article was about the DAMS problem:

“Digital asset management for an open movie project”

These were originally one long article, derived from a slide presentation I had developed for our “Virtual Studio” project. (Unfortunately, I don’t think the editor liked my slides. One of them is restored above. I think they’re kitschy but cute! So the article just has some screen-captures of the software I mention). I decided to go with TACTIC because it solves both of these problems together by structuring the project management around the digital assets, and by tying project management capabilities to each asset.

I’ve felt since the beginning of this project that management and collaboration is the main barrier we face in creating an open-source based animated series, so it’s worth putting our main development effort into that.

Future articles are planned to deal with much more specific technical challenges along the way to developing the KitCAT client package to provide tighter TACTIC integration with open source creative authoring packages.

To do that, I’ll be creating plugins for:

Blender
Inkscape
Krita
Ardour
Gimp

I plan to write an article for each, as a tutorial for scripting in these programs’ plugin environments, which are quite multifarious.

Blender’s python environment is very powerful and gives native control over the user interface;
Inkscape has a simple filter-based system that can run any kind of software;
Krita has a brand-new SIP-generated Python API in version 4.0, which requires mentally-translating the C++ documentation, but appears to give access to most features;
Ardour has Lua; and
Gimp has a wide range of scripting APIs for various languages, including Python and Scheme.

There are already tutorials for writing plugins in these programs, but not that many address systems-programming problems like interprocess communication. So these should be interesting problems in themselves.

May 24, 2018 at 6:01 PM

Ansible Test Targets

Today I finished creating virtual machines in VirtualBox for Ansible testing.

What I created is a little staging universe, with a machine running my web server (upper left), a machine running my standard studio client (lower right), our on-site server (upper right), the render cluster leader (left), and a render cluster blade (lower left). They are connected through internal networking in VirtualBox so that they see each other as the “real” computer which they are meant to mimic.This means I can use a web browser on the studio client to view the website on the server, and test website features, file-sharing, version control access and so on. All without risking our live servers.

I will set up installations for them all using Ansible playlists (scripts), and when they work as planned, I will (attempt to) deploy them on our live servers.

Still feels kind of risky, but it’s supposed to work. 🙂

I did this once before, but this time I’m taking the extra step of exporting each of the VMs as an “OVA” archive, so I can recover this system even if I have to move the development computer.

The hope of course is to reach a “DevOps” style management model, where I can continue work on the software installation and then deploy them repeatedly as well as recover from backup if anything goes wrong.