- Sylvan came on to help with system administration.
- Re-rigging Soyuz Launchpad Mech.
- Announced plans to release a 2nd edition of the artbook.
- Tried to resolve the Render Cluster power problem using
capacitors. Didn’t work.
- Discovered “Hiromi Lerner” searches lead mostly to
- Production accounting and revisiting the pie chart.
- Reviewing KitCAT mockup (was created in 2017). Testing
how to get metadata from a Blender file, using python
- Created a “Lunatics!” SketchFab account.
- Marketing analysis and segmentation presentation started.
- “Colonial Tanker” art design commissioned by Chris Kuhn.
- “Lunatics!” S1E01-PC-PressConference review of animation
and four-camera direction.
- SUPPLEMENT: Press Conference Animatic with sound.
Happy New Year 2018!
I’ve heard it from a lot of projects before, and I’m feeling it now: if I had known how long this was going to take, I probably wouldn’t have stuck with it!
But I think we are finally going to release an episode this Spring, after over six years of pre-production and production work, and so I’m awfully glad I did stick with it. I’m also very happy that Keneisha Perry and Chris Kuhn have stuck with the project for so long, as well as grateful for all the contributions from others over the last six years.
I think it’s all about to come together. I don’t want to jinx it by announcing a date, but I’m thinking of a month that begins with “A” and ends with “pril”. Maybe.
To stay on that schedule, we’ll need to finish principle animation and sets by the end of this month (January), then February will involve a lot of work on rendering, compositing, and video editing. March will mostly be about audio mixing, and after that, it’s just a matter of publishing.
We’ll be making some announcements about the technical side of the publishing soon.
So it promises to be a very exciting year for us! Thank you very much to all of you who have stuck with us to this point!
Set Modeler: Johnathon Wilson
After we got the credentials to host internships from California State University at Chico in 2015, we took on two interns in a pilot program that Summer. The second to arrive on the project was Johnathon Wilson.
By then, we’d already been doing so well, we were slightly ahead of where we’d planned to be!
So most of the work Wilson has done for the project will be seen near the beginning of “No Children in Space, Part 2”, our 2nd episode, which includes a variety of sets in a “media montage” sequence addressing the public reaction to sending a child on her way to the Moon. In fact, Wilson is at least partly responsible for all of those sets (although they do incorporate a lot of BlendSwap elements).
This was a pretty significant challenge for a new modeler fresh out of college and newly-learning the open-source Blender package (most schools teach proprietary packages like Maya, and Chico is no exception). But Johnathon did an excellent job!
Even so, we decided to wait on taking on any more interns after the Summer 2015 experiment. Management and coordination were tricky, and we found that it was hard to scale our production up to a faster pace with more people. This was a primary motivator in the decision to setup a new project management and pipeline system — we spent quite a bit of time researching that, and hope to implement the new system in 2018. After that, we’ll have to see if we can renew our status with CSU Chico.
Extras – Train Porters
Posing train porters for a brief cutaway used in the opening scene. The script says they’re playing cards, but I’m thinking about changing it to playing chess on a travel chessboard.
This is test render. Obviously there are lighting problems and the passing scenery through the window will be composited.
And More Animation Testing
Getting animated scenes right takes a lot of pre-viz test animations. We use the “GL” rendering engine for those, which is much faster than full rendering.
In this still, Georgiana is drawing a picture of one of the sights she saw earlier in the sequence, as the adults go over the details in a pre-flight press-conference.
System Administration Work This Week
We’ve just been joined by my son Sylvan Hancock for a couple of months. He is helping us to get some necessary system administration work done. We’re going to be building some computer hardware, setting up file and web services, and similar stuff.
This is sort of an “internship”, as I’m teaching him how to do some of the stuff I’ve been doing on my own on this project, and it’ll give us a necessary boost right now, when we’re trying to get multiple machines built and setup new services for our website migration.
Although the authoring software, like Blender, Inkscape, and Audacity, tends to be the sexy part of our project’s software, a lot of the more mundane communications and management software is really critical, and that’s where we’re currently weak. I hope we can resolve some of that this month and next with Sylvan’s help!
I am both a proud and a very grateful parent for this. I hope it’s a good deal for him too — he’s been managing his own Linux system for years, but this will give us a chance to go over some details I’ve never really formally taught him until now.
Re-rigging the Launchpad
Here I’m adding a control-panel armature based on the constraints system. The original panel objects will be used as “bone shape” objects for the armature (you can see the default octahedral bones on the left in the screencap above).
One will be the armature main bone, which will be represented by the “Control Panel” frame. Then there loose bones which will be represented as the sliders. When I’m finished, the result will look practically identical to the original, unless I decide to add something new to it.
It’s not really correct to say that I’m replacing the constraints rig — mostly I’m leaving it in place. All I’m doing is converting the actual control panel from a set of individual objects to a single armature with individual bones.
Bones can generally act just like regular objects for driving a constraints-based rig (there may be a few exceptions, but I’ll deal with those as I get to them).
The advantage to this comes when link the rigged mechanical model into a set or scene: the armature is a single object as far as Blender is concerned. So it only requires a single “Proxy” operation to bring the entire control panel into the scene for animation.
Without this step, each slider would have to be proxied separately in order to get the controls into my scene (in previous shots, I simply used the work-around of appending the model rather than linking it — which works, but destroys the advantage of linked elements, which allows them to carry over updates to the model when they are made.
The other thing is that this version of the launchpad has been modified to fix an interference problem with the gantry that is visible in some of our early renders.– Terry Hancock
New Edition of the Artbook & Writer’s Guide Coming
We’re going to be launching our storefront on Gum Road next week. Our first item for sale will be this updated version of the “Artbook & Writer’s Guide”. We haven’t offered this since our Pre-Production Kickstarter, and this will be an updated edition, available in both PDF and paper format.
The new edition will incorporate the many changes that have been made to the production, including new 3D artwork from project contributors who’ve joined the project since then.
We’ll also be making the 1st Edition available as a PDF (only).It’s called “Volume 1”, because we intend to release additional volumes as the series progresses and we do more design artwork or expand the universe. However, we decided we needed a 2nd Edition of the first volume before starting a second one, because there have been so many changes.
[EDIT 2023: The 2nd Edition Artbook / Writer’s Guide project was canceled before publication. If we pick this up, it’ll probably be as separate “Writer’s Guide” and “Artbook” projects]
Render Cluster PSU Hacking
I don’t know if I documented this before, but I stopped work on my Render Cluster build because I was having problems with the power supplies. The motherboards just wouldn’t boot.
Running a PSU tester on the output showed that the most likely problem was that the 3.3 V and 5 V supplies were oscillating. And it’s true that these small DC-to-DC regulators don’t have very large caps on them.
I can’t really fix the boards themselves, but it occurred to me that I could solder large capacitors across these two circuits on the wiring harness. I am finally revisiting this with some capacitors I was able to buy locally (though it’s a real shame that Radio Shack closed down! I had to drive an hour to buy these locally. It was that or order online).
I’m going to try this out with one of the PSUs and see if I can get it to work. If so, then hurray, I have a fix.
If it doesn’t, I’ll have to abandon my existing power supply system and redesign using standard PC PSUs.
I have to say, I’m not sure my approach to the Render Cluster is really going to be much cheaper than just buying a cheap server rack, but at least it’ll still look cooler.
Sometimes I wonder how visible we are. Most search engines these days track you and provide customized results, so it’s easy to get confused by the bubble.
Using a private window to search Google gives a somewhat more objective view (I suppose they could be tracking my IP address still). Searches for “Lunatics” turn up a lot of different things.
But I always seem to be able to find us by searching for “Hiromi Lerner”. Here’s what the first page of Google image search results looks like.
So… “yay!” We exist!
As we are getting closer to a release, I’m giving more thought to the production management side of the project. Obviously, as a free-culture project, we need to do things a little differently. In fact, figuring out a good way to do that was a major development driver for starting this project.
This pie was generated from LibreOffice Calc’s chart tool, based on a spreadsheet, which is my attempt to match the production pie that I still have posted on our website ( http://wp.lunatics.tv/?page_id=2857 ). Ostensibly, that’s for distributing Patreon funds among contributors.
The idea is then to break that down further into individual people’s contributions to each “department” (e.g. to the individual cast members under “Voice Cast” or to collect “Character Animation”, “Character Rigging”, and “Character Modeling” some of each of which was done by Keneisha Perry, although others have contributed to “Character Modeling”, including Bela Szabo (original models for principal cast) and Andrew Pray (spacesuits).
Sadly, I cannot recommend LibreOffice’s chart tools — it was insanely difficult to generate this plot, and the program crashed frequently while trying. I think it’s just not ready. We may have to generate the charts with a python script.
Last Summer, Katrina Niolet worked with us for a bit, creating this mockup of the “KitCAT” we hope to build for our production asset management.The idea is to create a unified front end that can be accessed from a variety of creative tools, including Blender, which will interface with a TACTIC server being used as the DAMS. That is, we propose to build a client that will provide rapid access to TACTIC features from creative applications, like Blender, Inkscape, Gimp, Ardour, Krita, etc. — at least as much as those apps will let us integrate the package through scripting interfaces.
It’s a just a mock-up of the front-end interface for the app. We’re a long way from working code, and we’re needing to set up a server to test against.
More info is available from the KitCAT Wiki on GitHub.
Getting Info from Blender for KitCAT
The reason I’ve been thinking about KitCAT recently is that I’m learning how to get metadata information in and out of Blender, which is the core functionality we’ll need from the Blender-KitCAT plugin.
Eventually, we’ll have a script that can talk to the local KitCAT client, giving it the context information it needs to be helpful.
Right now, I’m just trying to see if I can store some metadata inside a text block in Blender and get access to it from a separate Python program running on the command line.
Well… You Can’t Say I Didn’t Try…
So, I think it’s about time to admit that my Render Cluster power supply concept is a failure.
I discovered that the DC-to-DC converter stages that I purchased to support the motherboards did not work to boot the motherboards, nor did they quite pass an ATX power-supply tester, which reported the 3.3V and 5V circuits slowly oscillating out of range. I thought perhaps adding some large capacitors across the circuit would help, and did an experiment.
When that didn’t work, I tried adding more, and well: here is the amusing result.
Oddly, it doesn’t seem to have made any difference at all, which surprised me a little, though I thought it was kind of a long shot to work properly. I guess I don’t understand power supplies as well as I thought I did.
I am currently revising my render cluster design to accommodate a more-conventional power-supply solution. Even if my original PSU design could somehow be made to work, I think I’ve invested enough time on this dead end. I’m pretty certain the conventional approach will definitely work, though it will cost another $200-$300 and at least several days of re-work.
Ah well. Plans of mice and men…
Umm… I can suggest that you can rent remote computing resources. There is a really good offer by Scaleway – you can rent a 6-core cloud machine and pay only 10EUR for MONTH of its work. Or, if you are not happy with cloud machine, you can get a bare-metal 8-core machine fro less than 20EUR per month. You get charged by hour, so you can scale your infrastructure anytime on demand. You can check full prices here – https://www.scaleway.com/pricing/ P.S. I am not affiliated with Scaleway. This is just the most affordable (and flexible) solution that I found and we are going to use it for our projects as well. ^__^
Yes. And we may do both, but I want to have some in-house rendering capacity, which is what this cluster building project is about. I did some math to conclude that was the right way to go for us, but it’s also partly because it’s a fun project. This is a relatively minor setback. One way or another, this is going to be working in February, which is when I actually need it.
Ansible and Server Deployments
Sylvan Hancock will be training on using Ansible and VirtualBox for server management. We’re moving the scripts into a local Bazaar repo and bootstrapping our testing and deployment environment this week.
Our first live tests will be on our LAN server. If all goes well, we’ll probably start migrating our public web server, which needs updating, perhaps in February.
“Moon Truck” Wheel Concept
With almost all of the mech models for Parts 1 & 2 of “No Children in Space” completed, we’re going to be starting work on the models for Part 3 in February. These models are also going to see a lot of use in later episodes.
This is one of the adjustable wheel struts on the “Moon Truck” — a large, pressurized rover which belongs to the colonists, and will be their main way of getting around on the Moon’s surface (although in episode 6, we’ll also see the “Exploration Rover” or XR, which is a smaller, unpressurized rover that Dr. Allison uses for her geology survey work.
These are original designs, although they draw on NASA design concepts and experimental rovers, like this wheel with a robotic axle / strut that allows the wheelbase to be adjusted and for the vehicle to adapt to rough terrain, while also allowing it to lock into position for faster traverses over well-established and cleared paths.
Ceci N’Est Pas La Lune!
The treachery of images, “Lunatics!” edition… this is a test render of our 3D model Moon, approximating its appearance from the Earth (i.e. the “Near Side” of the Moon).
So “This is Not the Moon”, but rather a nice Blender model of the Moon.
Pre-Orders Available for Artbook & Writer’s Guide
We are revising the “Artbook & Writer’s Guide” book: our production guide and story bible. This is a heavily illustrated guide to the “Lunatics!” story universe, along with some production information.We are just beginning to revise the book, so the specs are subject to change, but it will be over 170 pages, with more than 50 illustrations, and more than a dozen color illustration pages.
The official release is set for Friday, May 4th, which gives us enough time for revisions in Scribus and then turnaround time from the printer.
There’s a lot more art to go into this book, from the last six years of series development and production work.
The motivation for this is both that we need an updated story bible for internal use, and that we want a first product to launch our Gum Road store.
We’re not sure what to expect, and we have not figured out international fulfillment yet (for the physical, paperback version), so there may be some changes before release — we’ll keep the product page updated accordingly.
Server Deployment Goals
Our 2018 goals in putting up a server (slideshow):
- Upgrade to latest Debian server release.
- Restore the existing WordPress and Mediawiki servers, so that backups and restores can be managed automatically.
- Deploy the legacy Subversion / Trac site, even though we’re migrating away from that.
- Deploy the Resource Space site (although this is a legacy for the “Lunatics!” project, we may be using it for Film Freedom, which is on the same server). (GOAL: Feb 28)
- Initial deployment of TACTIC. This is probably going to take awhile, as we’ve never run it before — many details to work out. (GOAL: Mar 28)
- Install Mumble for rehearsals and team-meetings. We haven’t needed this so-far, but with the planned ramp-up in production, it seems like we’re likely to need it soon. (GOAL: Jun 1)
- Install experimental Odoo and Big Blue Button sites for testing. (GOAL: Oct 1)
Now that I have some help on this, I’m hoping to get through the first few steps in the next month. After that, it’ll be back to just me, but we may also have gotten over the hump, if our Ansible set up works well.
Ubuntu Studio Packages
I made this chart a few months ago when adopting Ubuntu Studio as a “standard client”. This shows the versions of the creative software packages available on the platform.This version has just expired, apparently, so I’m going to have to investigate what’s new in “Artful Aardvark” — hopefully no serious changes.
I was a little taken aback by the Zesty Zapus distribution suddenly deleting the “Release” file, which seems to make it impossible to install packages from it. I haven’t had to worry about that as a Debian user, as older distributions hang around for quite awhile in the archive. This seems to be a difference in how the Ubuntu repositories are managed. I can see I’m going to have to decide how to cope with this behavior in the future.
The only really frustrating thing is that it seems to be interfering with doing the upgrade. It doesn’t look like much has changed in the new version, though. Possibly the next LTS will be for us, the last one is a little too far back. 🙂
Worst case, though, is to just reinstall it, which isn’t that bad.
Testing Overlay FS
You might recall my production log post about setting up storage for a replicated TACTIC digital asset management system:TACTIC Replication & Backup
The goal was to create an archive that can easily be backed up chronologically for long term shelf storage, while simultaneously being easily and logically accessed by TACTIC and other tools.
A key part of this plan was the relatively new “Overlay FS” feature in the Linux kernel, which creates a native filesystem which can stack multiple filesystems (or strictly speaking, directory trees) into a single combined tree.
When I wrote that, I had read about Overlay FS, but not tested it.
I did some quick tests on our local library server (where the local TACTIC implementation will live), just to see how it works. It turns out to be really simple, although I admit that that mount command is kind of scary to look at.
I’ll just need to write scripts to actually handle the changeover over volumes and set up the linked overlayfs mounts for it.
Linked articles for January 2018.
Moon vs Mars
Although our characters in Lunatics! clearly favor a Moon-first approach (well, except maybe for Tim, with his “Mars or Bust!” T-shirts), I’ve generally stayed out of the Moon/Mars debate: my personal opinion has always been “both”. My main opinion in favor of the Moon, though, is that it is much more feasible. The hardware to get there and to develop it is much closer to hand than what we need for Mars.
The “Lifeboat” argument mentioned here in Robert Walker’s article is pretty significant. While this won’t save you from a lot of problems, it is a viable way to deal with post-injury care, pregnancy, chronic disorders, etc — a large range of “stuff too complicated for us to deal with here on the frontier” that we can opt out of by just sending people back to Earth.
That’s not possible with Mars. A pregnant woman sent to Earth from Mars is going to have her baby on the way back — probably worse than having it on Mars, even if you haven’t got any facilities. Likewise, a broken leg will set (correctly or incorrectly) on the flight back as well. On Mars, you’re just going to have to solve those problems on-site.
Of course, in the long run, that’s a good thing. We need to develop the technology and techniques for living without Earth as a backup. But it’s a bit more advanced. (And of course, even on the Moon you can still choose to deal with these things on site, but it’s nice to have a backup only a few days away). Mars colonization definitely should happen, in my opinion.
And I think that a pretty good argument can be made that government programs should focus on Mars, leaving the Moon largely to private development — which is increasingly feasible with existing technology (and of course, our story focuses on a private organization, rather than the government programs, although they are present). That’s because the government programs can afford to throw lots of resources at the R&D projects that might be necessary to make it happen.
We’ve lost a lot of space probes exploring Mars over the years, and a lot of the losses have come from underestimating the difficulties it presents. I hope we’ll be cautious about putting humans in the same situation. The Moon is also not quite as dry as once thought and Mars is nowhere near as hospitable as it looks in the pictures (what passes for atmosphere on Mars is thinner than a workshop vacuum on Earth — you need a laboratory pump to get a thinner one). And of course, the average temperature is a lot lower. Getting caught out on Mars will kill you just about as fast as on the Moon.
Still, considered in terms of planetary resources, Mars has more volatiles and a higher gravity, so it’ll probably be home to a much larger civilization in the future than the Moon will be. In the long run, there’s a lot to like about it.
So my answer is still “both”.
Open Source Creative Authoring Software
Let’s see. Of these 22, we have used ten on Lunatics project: Blender, Inkscape, Gimp, Krita, Audacity, VLC, Scribus, Sigil, MyPaint, and Kdenlive; and we have plans or are considering three others: Trelby, Ardour, and Natron.Blender is obviously what most of our 3D animation is done in. We also use it a little in compositing the animation output.
Inkscape is my go-to tool for drawings. It’s used for a lot of the concept art, logos, and even many of the textures.
We started out using Gimp for creating a lot of textures, although we’re gradually doing more with Krita.
MyPaint is a simple tool for digital painting, which we’ve used for various backdrops and graphic elements, including most of the grass and weeds in the railroad sets. This also overlaps with the functionality of Krita, which is very good for painting and drawing.
VLC is the primary player I use for viewing shots, although there are others.
Audacity is the tool we’ve used for all audio mixing up to this point. It’s a primarily waveform editor, rather than mixer, so it’s very good for highly-processed sounds, like effects and ambient sound. It’s also excellent for recording.
Kdenlive has been our choice for video editing. It’s very flexible and has a fairly complete and intuitive user interface. It’s far from perfect, but it does enough.
The artbook was laid out in Scribus, and the e-book format newsletters were created with Sigil.
We have not yet made much use of Ardour, but we think it will provide a more robust way to handle final soundtrack mixing, using elements created with Audacity.
Up until now, we’ve just written screenplays in a text editor or in LibreOffice Writer, but Trelby offers some useful features I’m curious to test out, like collecting assets required to shoot scenes.
I’m frankly unsure whether Natron will be much use to us, as both Blender and Kdenlive overlap its role as a dedicated compositor, but it may be useful to have a separate 2D compositing step in between.
We don’t mostly produce our own music, instead relying on found free-culture music for the most part. However, if we do more of it, we’ll likely rely on some of the other software listed here.
I just launched a SketchFab account for “Lunatics!”.
This is a way you can view 3D models interactively online. So far I’m just learning how it works.
Electromagnetic Tether Propulsion
This is a neat trick I’ve heard about in principle, but it’s the first time I’ve heard of an actual working system being developed.
This kind of tether exploits a satellite’s orbital motion through the magnetic field of the planet it is orbiting. It can pump the orbit up by picking up motion from the rotating magnetic field (using electricity), or it can dump orbital energy by dragging against the field (generating electricity).
Obviously very useful technology to have!