Friday 18 December 2009

Happy Christmas, everyone, see you in 2010!

Woah, what a totally crazy week that was! We shipped you:
And we managed to squeeze in a Christmas party! We've got one more little thing we're aiming to get out of the door before everyone takes their winter holiday, but otherwise, that's us pretty much done until 2010.

Thanks for all your support during the year. It's been busy as hell, but the difference between what we have now and what we had at the start of 2009 with is amazing. There's always more we would have liked to do, and there's already plenty on the schedule for 2010. And thanks most of all for all your feedback, here and in the forums - it's really good to know how you feel about what we do.

Happy holidays, everyone - make something cool so we can see it when we get back!

Wednesday 16 December 2009

Christmas mayhem - update

Now we're going to have our Christmas party, then we'll try and get some more stuff out to you by the end of the week.

Tuesday 15 December 2009

Pre-Christmas Moviestorm mayhem

With just a few more working days before we all take a Christmas break, we're aiming to ship a whole bunch of stuff out to you very soon indeed.
  • Moviestorm - mostly a patch release, addressing a few bugs. It's mainly little things, but the main issue is that text to speech should now work properly. You should get that any time now.
  • GreetingStorm - along the same lines as Photostorm. This'll be free, for now, and includes the Christmas outfits - just in time for the Christmas competition!
  • Female Monsters - this will be a real squeeze, but we're going to try and get this out to you if we possibly can.
  • Content rental - we're aiming to get a first version of this running by the end of the week. It may be a little unpolished, but it would be good to get some early feedback from you.
And we're still working on the PayPal / Amex / Visa issues. Sadly, they're not proving at all straightforward to fix.

Tuesday 8 December 2009

It's Christmas - let's party!

OK, Santa baby, time to shake it!

A few shots from the 2009 Christmas Party at the Moviestorm Mansion.

Thursday 3 December 2009

The wicked ladies

A few weeks ago, we gave you a bunch of Halloween monsters created by the Marvellous Mister Ollis. Quite rightly, a number of you observed that they were all male. This is because we are all - apart from Lisa, of course - well brought-up English gentlemen who would never, ever think of a lady as monstrous, evil, or anything less than entirely beautiful, wonderful, and charming. Even when they're dead.

However, we recognise that for dramatic purposes, it may sometimes be necessary to depict ladies in an unflattering light. So Chris went home and locked himself in the cupboard under the stairs for a month with nothing but old Hammer movies and absinthe, and here's what he came up with: a vampiress, a zombie, a witch, and Mrs Frankenstein.

These are renders of the original 3DS Max models, not the actual Moviestorm heads we'll be shipping, but you get the idea. They're all morphable, just like the guys. And they'll be available soon.

Payment systems - update

When we rolled out the new marketplace last week, we had a couple of problems with the payment systems.
  1. We can't take American Express. This is due to some issue between PayPal and Amex. To be honest, we don't entirely understand it, and suspect it's as much a corporate issue as a technical one. We use PayPal Pro to handle the actual money transfer, and until they sort it out, we're completely in their hands. The latest prognosis is that we won't be able to accept Amex until 2010.
  2. We can't take PayPal at the moment. We're still working on it with PayPal and our billing provider, we think we have a working system, and we'll know in the next day or so whether it's all fixed now. If it is, we'll get it out to you right away. If not, it's back to plan B. Or is it Plan C by now? (And yes, we do see the irony in using PayPal Pro and not being able to accept PayPal...)
We'll keep you updated - thanks for your patience.

Friday 27 November 2009

What would we do without Jeff?

In previous posts, we've alluded to Jeff's design skills. Turns out, he's even more talented than that.

Over on the Photostorm page, under Scene, you'll see he gets a credit for music as well.

He's not just a guy in a suit, you know!

Wednesday 25 November 2009

Last-minute launch hiccups

Well, we've just done our biggest, most complicated launch yet, and we're bloody pleased that it nearly all went to plan.

However, there are, of course, a few outstanding problems that we'll address as soon as we can. F'rinstance...
  1. We can't accept PayPal just at the moment. Credit cards work fine, but PayPal's not going through. We're sorting this out with them, and we expect to have it up and running in a few days.
  2. We're having issues with taking American Express cards. Again, we're taking it up with them, and that should be fixed soon.
  3. If you've got unpurchased items in your shopping basket from a previous trip, you'll need to clear those out manually, otherwise it'll try to sell you those as well as a subscription.
  4. A few people are having problems logging in with Moviestorm 1.2, and we can't quite figure out why. If this happens to you, change your password and you should be able to log in.
  5. There's no message of the day on Moviestorm 1.2. It works fine on the development service, but it doesn't work when we make it live. It seems to be something to do with Amazon s3, and if we were a little more awake, we'd probably be able to figure out what. That should be sorted tomorrow. If it was there, it would look like this, but bigger. And you could click on it and get yourself a sub.

  6. There are some visual inconsistencies in the site. We've moved stuff to new servers, implemented new CSS, and changed the back end systems, and guess what? We missed a few bits. We'll find 'em and fix 'em as we go.
There's more, of course, and we'll get to it all in due course. And doubtless, you'll find a whole bunch of other things we missed and tell us about them in the website forum and the feedback forum.

Anyway, thanks for your patience. We're off to put our feet up and perhaps sip a small glass of sherry. Just the one. Between us. We reckon we earned it. Especially Yolise, who shouldered the burden of the Web site work.

Oh - and to our American friends - happy Thanksgiving!

Monday 23 November 2009

Quiet before the storm

It's all been a bit quiet on the blog for a while. The office, on the other hand, has been a hive of activity, as we gear up for a big release Any Time Now. This will include Moviestorm 1.2 and major changes to the marketplace, so it's slightly more complicated than usual.

We also officially changed the company name from Short Fuze Limited to Moviestorm Limited this week, so we're in the process of going through the Web site and everything else with a fine tooth comb and updating everything to reflect the new name.

Normal blogging will be resumed shortly.

Friday 13 November 2009

Thursday 12 November 2009

Take thirty-seven... action!

Over in the forums, there have been some discussions about performance issues, particularly why things sometimes run slowly with relatively simple sets, no mods, few characters, etc. Julian posted this detailed reply, which we figured was worth reposting in its entirety.

As you may know, it's my job to keep tabs on Moviestorm performance. My tests this week have been on what we call "retakes" - this is the process by which we turn the commands that you give our objects into actual chains of animations, and it is quite a time-consuming process. For example, consider a walk - it consists of many different snippets of animations stitched together in as seamless a fashion as possible. When you move a target point, the walk gets recalculated. In fact during a retake everything is recalculated, and this may seem like overkill; if you only change something near the end, why do you have to process the entire scene? Well the answer is that determining which bits of the scene are (un)affected by which operations can be a more time-consuming process than recalculating the lot anyway! It can also be more error-prone, and more complex (hence bug-prone too). So for now, when we retake (and we retake a lot), we do the entire scene, from time = 0 to the end of the scene.

In order to mitigate the cost of the retake, we've put some effort into making sure we are reducing the amount of recalculation done. This is done "locally" to each activity (rather than globally as above). One of the areas this is harder to optimise is when the activity depends on some resource - which could be eg a texture or a data file lurking on your hard drive. In order to be robust, we have to put checks in to see if these resources have changed - so if you change an animation (directly or indirectly), that change propagates into your scene. Large (ie long) scenes result in lots of resources, and hence Moviestorm spends a lot of time in the retake gathering info about resources. At the moment, for reasons I won't bore you with the details of, this is more costly than we'd like. In essence there are multiple file systems in place, and they all have their costs. We intend to fix the inefficiencies as soon as we can; but they are actually quite insidious because we do a lot of file-related activity and so the changes need to be made in lots of places. But the good news is that we are on the case, and with v1.2 due out soon, we'll have time to take stock of these issues, hopefully to come in a subsequent release asap.

Tuesday 10 November 2009

Sky light

One of the things that's been a long-standing issue is that when you change the ambient lighting, the sky changes colour too. Sometimes, that can create a cool effect, but more often than not, it's not what you wanted. We've finally fixed that, and now the sky is, as they say in the business, self-illuminating (in other words, it takes its own light colour, not the colour from other sources).

Screenshot by Amos

So? Well, it means you can get shots like this. The blue-grey lighting on the streets doesn't wash out the dramatic sky colour, and gives you a strong skyline. Neat, huh? Combined with additional lighting from on-set sources such as street lights or special effects, you can build up some really atmospheric sets.

That'll be available in Moviestorm 1.2, coming soon.

(Apologies to anyone who came here looking for little windows to put in their roofs. The wonders of Web search!)

Friday 6 November 2009

The miracle of birth: where Moviestorm characters come from

Sometimes we wonder about Chris. There he sits at his desk, surrounded by pictures of Bjork, Ne-Yo, Rihanna, and Lily Allen, listening to My Chemical Romance, Green Day, and Bat for Lashes, while browsing Etsy, Hot Topic, Yukka and Vintage Vixen. He tells us it's research.

Then he sits in the coffee room, doodling and mumbling to himself, with that strange look in his eyes that all artists get. You know, the one that says, "I'm being creative, don't talk to me, just bring me doughnuts and drinks heavily laden with caffeine."

After a while, stuff like this gets mysteriously plastered on the walls of the office, usually half-way up the stairs. or left lying on people's desks in plain brown envelopes.

And a while later, new Moviestorm characters appear.

(More screenshots soon, but here's one of those guys in action.)

Wednesday 28 October 2009

Halloween Morphing Heads

A few of the heads in Chris's Halloween Morphing heads pack are proving a little elusive. Here's how to get to the Cutter, Piggy, Frank, Mouldy and Vampyre characters.

  1. Select the Halloween '09 Monster Morph head - you'll need a male character.
  2. Click the arrow next to the morph slider, and choose your monster.
  3. You can now morph between the basic human face and the monster face, so you can make him as monstrous as you like!

Tuesday 27 October 2009 released

Apologies for the slightly delayed notice: did indeed ship on Friday.

Release notes can be found here.

Modders, please read this if you're having a problem starting the Modders' Workshop.

Thursday 22 October 2009

Best laid plans... hiccup

The office net connection has been down for the last three hours, just as we were in the final stages of making the release.

British Telecom are looking into the problem now, but we can't do the release until the net's back, and it's completely out of our hands. It may well be a problem at the exchange, in which case they probably won't fix it until 2am when there's less phone traffic. As a result, there's a good chance the release will be delayed until tomorrow. We'll keep you informed: if the worst comes to the worst, we'll take our kit and the QA team to Dave's house tomorrow, set up a temporary office there, and do everything from his spare room.

It'll be like the old days, back when there were just three of us... except with more of us.

Wednesday 21 October 2009 set for launch

We're currently putting the patch through its final tests, and it's all looking good. Barring fire, tempest, flood, or Eagle-Eye Holloway spotting something horrific, we'll upload it to our servers tonight when we leave the office, and you'll be able to get it tomorrow after we've verified that it uploaded properly.

Eagle-Eye Holloway is watching YOU!


  • SNOW LEOPARD (MacOSX 10.6) USERS are strongly recommended to reinstall Moviestorm in order to benefit from significant performance improvements. Please note also that the NVIDIA Cg Toolkit has a different installation process under Snow Leopard.
  • Please note that some modders' content will need to be republished before being used in Moviestorm.

Resolved issues

  • Old movies with character "Place Here" commands outside of the floor mesh now load and playback correctly.
  • Facial expressions now work correctly.
  • Placing doors on the set will no longer be disabled if content packs are missing from the user's library.
  • Character library stays on screen after closing the shortcut key help panel.
  • The Weather special effect now works in the Camerawork & Cutting Room Views without distorting the camera view.
  • Deleting a "Place Here" command now updates subsequent waypoints correctly.
  • Walking on rugs works again.
  • Updated preview thumbnails for various costume and heads.
  • Finally added Tari Akpodiete to the credits (sorry Tari!)

Tuesday 20 October 2009

Another of those changes that's so small you probably didn't notice it: the Moviestorm icon on your Windows task bar is the MS logo, not the camera.So when you glance down, look for the little orange blob amongst your open apps, not the little black blob. Why? Because it shows up better, and is more in line with the current user interface.

(Mind you, I'm still getting used to the little blue square for Photoshop Cs4 instead of the feather I'm used to from earlier versions!)

Moviestorm mods

During the 1.1.7 upgrade, we found that quite a few user-created mods (and, by extension, movies that use those mods) stopped working. In some cases, Moviestorm wouldn't even start with those mods enabled. That was a little unexpected, but in retrospect, perfectly understandable. As part of the 1.1.7 development work, we changed a number of things about the way our assets are constructed, so they now run faster, look better, etc, and we republished almost all of our content packs to work in the new way. Our experience so far is that if you republish the mods you've made, they mostly start working again.

Obviously we want mods to work, and we don't want to break your movies. The best Moviestorm movies couldn't have been made without mods: Cloud Angels, Chanel Untold, Death in Venice, and many more. That's why we gave you the modder's workshop in the first place, and why we're working on opening up a modder's marketplace.

However, we need to be very clear about one thing.

The bottom line is that we don't provide support for mods. As we've said before, the modder's workshop is still very much a beta tool, and you're using it at your own risk. If you install mods made by someone else, that's at your own risk too. If that comes across as harsh, that's the exact same risk we take: you're using the very same tools we are: the only difference is we get several weeks of testing against a new release before it goes out, which gives us time to find and fix problems in the background, while you guys only get to test the new code when it's already shipped.

If all you're doing is changing a few textures, or importing simple static models from Sketchup, you shouldn't normally have any problems at all. However, as soon as you start doing more complex things, and particularly if you're hacking into the code or the mscope file, you're right on the edge of the modding capabilities, and there's always the risk that the underlying code will change between versions and break your mod. What it comes down to is that if you're running with mods, you've got a Moviestorm installation that isn't what we supplied, and very probably isn't something we can test against. We certainly can't test private mods we don't have access to.

We'll do what we can to help you, but here's what you need to do to help us.
  • When you upgrade Moviestorm, switch off all your mods first. Try loading it up without any mods on. That way, at least you'll know whether Moviestorm works at all.

  • Once you know Moviestorm is working as supplied, re-enable your mods. If Moviestorm stops working, or your movie doesn't load, then it's almost certainly a problem with one or more of your mods. Switch them off one by one (or switch them all off and switch them on one by one) until you can find out which mod is causing the problem. We do know that some people have experienced problems simply by having a lot of mods installed, so it's worth disabling any mods you're not actually using, and see if that makes any difference. We've also had reports of some mods being incompatible with each other, so there's something else to check out.

  • If you're a modder, republish your mod and try again. (If you're using someone else's mod, go back to them and find out if there's a new version available.) We'd strongly recommend that when you publish a mod and put it on a 3rd party site, indicate which version of Moviestorm it was made with - that way if you're using a mod made for 1.1.6 and you're running 1.1.7, you know that's a possible source of the problem.

  • When you report a bug to us, let us know which mods you're using. If you know the problem is related to a specific mod, send us the actual mod file (or tell us where we can get it). If you can tell us who made it, and where and when you got it, so much the better.
Armed with that information, we can probably tell whether the problem you're experiencing actually means "Moviestorm doesn't work at all on my machine," or "this mod completely breaks Moviestorm" or simply "this mod doesn't work any more". That's a big, big difference from our point of view, and it helps our QA team enormously. It tells us exactly what you guys are doing, and will also help us make a better, more reliable, and more robust modder's workshop in the future.

We can't and won't guarantee you that we'll fix your specific mod or make Moviestorm work with it. We'll help if we can, but if there's nothing we can do, then our final position will be to recommend that you disable the offending mod and work around it.

What would be enormously useful, for us and for you, would be to compile a list of mods on the wiki and note against each which version of MS it was made for, and any known issues. Any volunteers?

Windows 7

We're wondering if any intrepid users have tried Moviestorm on Windows 7. We've recently had some preliminary results back from our hardware testing people, and they reported no problems with it, but they didn't test it by using it in the same way you do. They certainly didn't make movies with it.

We'll be testing Windows 7 as soon as we can - in the meantime, any feedback you have would be useful. If nothing else, it'll tell our QA crew where to start looking.


Thursday 15 October 2009

Moviestorm Light - and Dark

A friend of mine who teaches film-making in Bristol, Phil South, tells his first-year students every year that making movies is about painting with light. When you strip it down to its fundamentals, what film-makers do is capture reflected light with a camera, and project that onto a screen. The first exercise he gives them is simply to take a stationary person on an empty stage, a single camera, and a single light, and see what happens on a monitor when you move that light and camera around. By lighting the person differently and picking different camera angles, you can create powerful images on the screen which have an innate story in the viewer's mind.

Of course, another way to look at this is to say that you're painting with shadows. It's as important to decide what doesn't get lit as to decide what you show. Moviestorm's had shadows in since the very early days, but it's still a long way from the sort of shadows you see in real life, and we know it.

Moviestorm pioneer Phil "Overman" Rice sent us an impassioned email a week or so ago on this subject. With his permission, here's the correspondence between him and Dave. You may find it illuminating.


We're starting to get to the point where we can make top of the line cinema with Moviestorm when we pay attention and edit properly. Screw pre-vis, I say. This thing officially has strong legs of its own, as films like [NAME REMOVED] prove.

There's really only one thing about this film that screams a jarring reminder that this is low budget animation: those goddamn flickering shadows. I've found the only reliable way to avoid them is to just turn directional lighting off, or at least so far down that shadows are barely visible. But look at what these guys did with shadows in this piece! Can you imagine this film being nearly as good without shadows?

No, we've got to have them, they are a crucial device.

What is the outlook on getting this bug fixed? Honestly, when it first came to notice, there were so many other bugs in Moviestorm that at the time it didn't particularly stick out (though I confess it's always bugged me). But now, esp. with 1.1.7, you guys are continuing to obliterate the imperfections of this movie-making tool, such that this 1.0 remnant shadow problem is really
really standing out. And it's a bug that puts off regular viewers as much as (if not more so) than machinimator viewers, who tend to be much more forgiving of these kind of things. If we want to reach an audience beyond the pool of our fellow creators, we're going to have to stop implicitly asking them to lower their expecations when they sit down to watch our movies. The audience doesn't want to read "sorry about..." in the description before they watch, and the directors don't want to feel obliged to say it.

This film is, in every other regard, a hands-down jury candidate for this year's Machinima Expo. But we're really stuck in contemplation of whether to bother sending it up, solely because that godawful recurring visual glitch is almost certainly going to nix its chances with viewers who are just watching films and aren't educated on the day-to-day handicaps of this or that machinima platform. We aren't sending up anything else with that kind of visual bug, it almost doesn't seem fair to put it up there and hope a jury who we've asked to pick out the best of the best will just ignore such an obvious flaw.

We've got to stop doing this to Moviestorm films. What is causing the blocky and flickering shadows? What needs to happen to fix it?

I know you've got ten thousand things on your plate, things you want to do with the program. But this very old issue really has to become a renewed priority, if it isn't already. It's the kind of flaw that cannot be edited around, and turning off the feature that causes it has potentially dire consequences to the light and shadow vocabulary of film language. And the number of otherwise really stupendously great films it infects and spoils is only growing.

Please help us with this. Help us make the kinds of films that are going to have storytellers - even those with an image quality fetish - running to your software in droves. We are SO CLOSE to being able to snag the attention of beauty buffs, so very very close. This wart-on-the-nose-of-Angelina-Jolie is really the only thing standing in our way.

Your concerned user, friend, and advocate,
Phil Rice

Hi Phil,

I could not agree more with your sentiments. For all of its flaws I'm much more interested in machinima as the final product than as pre-vis. Right from the start I've wanted movies made in Moviestorm to be watchable for their own sake carried by the quality of the storytelling and without the visual quality spoiling the experience. Now I know we've got a long way to go but machinima has Moore's law in its favour: the hardware keeps getting more powerful and the software is slowly catching up. I've just played through Batman Arkham Asylum so I know we're behind the bar right now. I have to plead poverty for the moment but we have the virtuous circle on our side with good movies attracting new movie makers to Moviestorm who then go on to produce further good movies and slowly our community (and revenues) grows allowing us to build a better tool for making better looking movies.

We've made many improvements to the visual quality of movies but you're right about the quality of our shadows letting the show down. They've been bugging me also. Moviestorm's renderer has supported shadows from the start precisely because they are so essential to painting a good scene. I also want a whole lot more of course: HDR, global lighting, ambient occlusion, et al, but those are still for the future.

So, what can we do about them?

Firstly we use a shadow mapping technique to create our shadows. Effectively we take a shot of the scene from the point of view of the light This is pretty standard in state of the art game engines and our shadow quality actually compares quite well with most such engines. The difference though is that most games keep the cameras mostly in long shot but the good cinematic shots are close ups. The limited resolution of the shadow map is what causes the pixellated shadows. The shadow maps are anchored to the scene and so we get flicker as characters move through them (and even tiny movements are enough to move by a shadow pixel or two).

The other main shadow technique we could have used is to build geometric shadow volumes and use a stencil mask. However these have some major disadvantages for our use: they don't self shadow and the art has to be carefully constructed to make correct silhouettes. Generally shadow volumes have been rejected by games engines in favour of shadow maps for some time now.

Fortunately there are a lot of new tricks to be applied to shadow maps that could deliver most of the visual quality that we want for our movies - though in all honesty they'll still fall short of what you can get from an offline renderer.

Currently we use one shadow map for the whole scene. We take a lot of care to match the shadow map to the intersection of the camera and light view volumes and bias the pixel density to be higher closer to the camera but this is never enough for large scenes particularly when the light direction and the camera direction is opposed (shadows towards the camera tend to be the worst). This tracking happens frame by frame which is why you often see the shadow quality pop.

However a better tactic is to use multiple shadow maps - cascaded shadow maps are best current practice. Each shadow map might be relatively small but a smaller shadow map confined close to the camera can give a far better result than a large shadow map covering the whole scene. For example if we had a shadow map for each character close to the camera and a shadow map for the near scene and a shadow map for the far scene we should get much better results. This is quite a significant change to our renderer but one I'm actively pursueing in the rare moments I get to do some R&D.

In the shorter term there might be some ways to make our single shadow map more effective. One quick fix is to use a higher density shadow map (a decent card will support up to 4096x4096 but we've held back to 1024x1024 so far). This will help some (and I've tested it) but nothing like enough.

One trick used in game engines with static levels is to place the shadow casters manually to cover the area as effectively as possible. I don't really like this approach as it would require some complex tracking movements to get the best effects for close ups and this conflicts with the ease of use requirements for Moviestorm.

Another quick fix (but with its own drawbacks) is to soften the shadows further with a larger sampling mask. Effectively this puts a depth based blur on the shadows. This can look quite good on large scenes, the blurring hides much of the flicker, but it also loses any crispness in the shadows just where you might want them. Again it is a technique for higher end cards as it needs a lot of shader instructions to implement. But it could provide a worthwhile improvement in the right places.

So, let me end with a question for you as a movie maker: if you have to compromise on shadows, what are the most important characteristics you're looking for? Are soft shadows better/worse than hard shadows? Is the flicker the most annoying aspect or the coarse pixellation? Finally, is it enough to have high quality shadows in the final render even if the real time shadows are pretty rubbish?

Thanks for taking the time to raise this - sorry it's taken a little while to get back to you. I can't promise when you'll see improvements to the shadows, but know that I'll be doing what I can.


By way of explanation, I added illustrations to Dave's reply. As you can see, with a tiny set, the shadow on the wall looks just fine. As soon as we add in a large building, though, the shadows on the wall and on the character's neck become pixelated.

Thank you so much, Dave, for your detailed reply. This is a challenging issue, and one that I've seen games with multi-million dollar budgets and gigantic dev teams grapple with. Mass Effect has flickering shadows on some cards; GTA IV is plagued by the pixellated shadow edges even on a monster rig. So I can appreciate this is no trivial fix. And I am really grateful to learn that it bothers you guys too, that it's not an issue you've given up on. I can't tell you what a relief that is, just knowing that.

To answer your questions:
"So, let me end with a question for you as a movie maker: if you have to compromise on shadows, what are the most important characteristics you're looking for? Are soft shadows better/worse than hard shadows? Is the flicker the most annoying aspect or the coarse pixellation? Finally, is it enough to have high quality shadows in the final render even if the real time shadows are pretty rubbish?"

Soft vs. hard is a tough decision to make. It sounds like softening could be a way of reducing artifacts, but when the hard shadows are done right, boy oh boy, are they effective. Ideal world? I'd wish for an advanced user setting to switch between the two based on the situation. Forced to choose, hard shadows are better... but soft shadows without pixellated edges trump that for me. I'd wager no one but 3d graphics buffs are going to be distracted by a soft shadow when the scene's lighting might call for hard... but a jagged edge shadow can potentially distract everyone.

Flicker vs. Pixellation - Hands down, the flicker is the most distracting element... perhaps because it's so "foreground" in nature. The jagged edges can often be cropped out with clever framing... but the flicker often affects faces, which more often than not are essential to the shot.

Final Render vs. Real Time - One of Moviestorm's strengths right now is that affinity of the image at real time with what gets rendered. No surprises. HOWEVER, if the changes were in a positive direction such as with regard to shadow quality, yeah I'd be crazy not to love that. Would that mean a significant increase in final render time? (Honestly, that part doesn't matter much to me, I'm completely comfortable with a bit more wait for a tastier "bake".) In short, yes, I'd be fine with that and think most users would be as well.

Cheers, and thanks again,


What do you think? What do you want to see? How important is lighting to you, and how would it change your film-making if we gave you better shadows? Would you make different films? The same films but in a different style?

Wednesday 14 October 2009

Here Come The Girls!

You wanted a version of the crowd scene with the ladies? Here you go.

The sweet thing about machinima is that this only took a couple of hours to put together. All I did was start up my movie, save it as a new movie, and go through the cast list one by one, converting each of the 60-odd characters into their nearest female equivalent. Then, just for the hell of it, I made some small changes to the set and the lighting, adjusted the colour of the intro text, and hit render. Lovely.

I also did some quick calculations as to how long it would take me to get those shots in real life. Say, a few hours booking the hall, and sorting out the people to do the shoot, making sure they knew when to arrive. Another hour or so making sure the more outlandish costumes were ready. A crew of three or four would spend a couple of hours putting out chairs and getting the room ready before the cast arrive. That's about 13 or 14 man-hours already. Then the cast arrive, we get them changed, run them through what's needed, and shoot it a few times. Say, if we're really lucky, an hour each for the male and female versions. That's another 125 man-hours for the cast, and another 10 or so for the crew. All in all, about 140 man-hours to get those two shots filmed, then we take the footage home and edit it. I'd have to put in, say, about 16 hours.

And that, of course, assumes everything went swimmingly. I didn't even think about insurance costs, actor releases or other legal stuff. And what's the likelihood of getting 60 people to perform flawlessly in an hour, even if all they have to do is walk onto a stage?

Doing it in machinima took me about 12 hours for the first one, and another 2 for the second one. That's about the same effort on my side as doing it for real, but only 10% of the total number of man-hours and a fraction of the hassle.

Changing Moviestorm memory allocation in 1.1.7

If your computer is above the minimum spec (and you have at least 2GB of memory), you may want to increase the memory available to Moviestorm, so that it's less likely to run out of memory. You may hit memory problems if you're making big movies or if you have a lot of content packs.

Possible symptoms of Moviestorm running out of memory:
- Significant slowdown after using Moviestorm for a while, or when going to the Cutting Room.
- 'Error switching scene' messages when loading or changing scenes.

Please note: If you've already changed in version 1.1.6, that won't help you with 1.1.7. You now need to do this instead.

First, ensure your Moviestorm install is updated to 1.1.7 or later.

Find the install directory for Moviestorm (C:/Program Files/Moviestorm General Release, if you went with the default).
From that folder, open the file Moviestorm.l4j.ini in a text editor (such as Notepad).
Edit the following line:
Using much more than 1024M will probably cause problems with Moviestorm, so it is a sensible maximum.

Use Finder to find Applications/Moviestorm 1.1
Right click (or control click) the application and select 'Browse Contents', and look in the Contents folder
Open info.plist in the Properties List Editor
Expand the java tab
In the VMOptions property, find the bit that says -Xmx512M or -Xmx256M
Change the default to -Xmx1024M

What's in Moviestorm 1.1.7

Here's the release notes for 1.1.7 in full. Please note that the pack names are the ones used internally by Moviestorm, not the ones in the marketplace.

Moviestorm 1.1.7

New features

  • New UI, new Look'n'feel.
  • New loading code - faster startup and faster asset loading.
  • Better performance all round.
  • Better framerate for a lot of hardware combinations.
  • Walk curves are now implemented with waypoints. This enables you to change a character's gait mid-walk.
  • New asset structure and catalog functionality.
  • New UI for selecting and placing set objects.
  • New UI for easy access to list of objects already in the scene.
  • Modders Workshop updated to reflect new asset structure.
  • New look and improvements to Script.
  • New functionality in Director's View to show or hide set objects (keyframeable).
  • Movies no longer need a character in the cast list in order to progress to the Director's View, Camerawork View or Cutting Room View.
  • Many set objects and props have new, clearer thumbnails.
  • The Moviestorm End-User Licence agreement has been updated. You can read the EULA by clicking the '?' Help button in Moviestorm. A copy of the EULA in HTML format can also be found in the directory to which Moviestorm was installed.
  • Improvements to the Moviestorm Launcher
  • Modders workshop can now be started directly from the Launcher. This button will only appear when signed in as a user with a Publisher's Licence.
  • Content Packs screen now shows thumbnails, and lists Content Packs which have not yet been purchased.
  • Install button to install 3rd-party content packs now appears in the launcher rather than the Moviestorm settings menu.
  • New Preview versions of Content Packs allow users to see unpurchased set objects, props and costumes.
  • Overwriting an existing set with a Stock set will now delete all activites and camera cuts from your scene.

Resolved issues

  • Moviestorm will no longer use excessive amounts of memory when switching to the Dressing Room.
  • The default camera is now named Main camera rather than <<MAIN>>
  • Animation blending improvements should eliminate jumps between animations.
  • Cel-shading on floor textures now works correctly after saving and reloading a movie.
  • Ambient shadows will no longer occasionally inherit a character's mark colour.
  • Use Prop animations will no longer display incorrectly when the character is the subject of a Look At command.
  • The Create A Wall button now correctly toggles the tool on and off.
  • Layering many multiple Say commands will no longer cause Moviestorm to run out of resources.
  • Issuing a Point At command for a character who is already using a gun will no longer cause the character's torso to distort.
  • Playback of audio under Windows XP is now more reliable.
  • Moviestorm should no longer require a force-quit under certain Mac architecture.
  • Re-ordering camera keyframes which include Dutch Tilt will no longer cause Moviestorm to crash.
  • Activities no longer sometimes play back in the wrong order during first playback of a scene.
  • Uploading to YouTube directly from Moviestorm is now working again.
  • Moviestorm will no longer sometimes crash to desktop when an in-progress render is cancelled.

Known issues

  • Shift-dragging a character in Director's View no longer creates Move commands.
  • Character walks will not work correctly if the character is moving through a door and the walk contains a waypoint.
  • Shift-dragging a character causes problems when clicking near to the character's head.
  • Shift-dragging a character no longer creates Move here commands.
  • Line of flashing pixels at the top of the Characters View.
  • Enabling a previously disabled Content Pack will not correctly load the data for that pack.
  • Moviestorm's internal Help text is out-of-date.
  • Normal maps display incorrectly on faces with morph targets.
  • The double-sided material property does not react correctly to light on the back face of the material.
  • Filters on the Script View are not working correctly.
  • Frames are skipped in output files when rendering to WMV when certain codecs are installed.
  • Radeon X-1950 and some HD cards can experience rendering artifacts. These can sometimes be resolved by altering the Graphics Settings within Moviestorm.
  • Recently, two NVIDIA driver releases were tested to be incompatible with Movistorm. The driver version numbers were 190.38 and 190.62. With these drivers, you could expect to see the following graphical artifacts:
    - Character models deforming and warping during scene playback
    - Particle emitters (fireplaces, special effects, etc) not working at all
    - Terrain bowl around the set displaying as black
    These issues are resolved with later NVIDIA drivers (ver. 191.07 onwards) and we we recommend against using the previous drivers in conjunction with Moviestorm.
  • Certain third-party codecs may cause instability when moving to the Publisher's View. We recommend saving your work before moving to the Publisher's View, and re-starting Moviestorm before continuing.

Special Effects

New features

  • Republished for faster loading.

Resolved issues

  • Explosions no longer appears incorrectly in Camerawork View.
  • Animations using the Torch prop will no longer include the lighter in the wrong place.


New features

  • Republished for faster loading.

Resolved issues

  • Updated thumbnails.


New features

  • Republished for faster loading.

Resolved issues

  • Updated thumbnail.


New features

  • Republished for faster loading.

Resolved issues

  • Updated thumbnails.


New features

  • Republished for faster loading.

Resolved issues

  • Renamed Plant_Potplanet to Plant_Potplant.
  • Updated thumbnails.


New features

  • Republished for faster loading.


New features

  • Republished for faster loading.

Resolved issues

  • Updated thumbnails.


New features

  • Republished for faster loading.


New features

  • Republished for faster loading.

Resolved issues

  • Updated thumbnails.


New features

  • Republished for faster loading.

Resolved issues

  • Updated thumbnails.


New features

  • Republished for faster loading.

Resolved issues

  • Reduced normals on the Parquet floor.
  • Added the ambient shadow for the Family Saloon Car.
  • Updated thumbnails.


New features

  • Republished for faster loading.

Resolved issues

  • Updated thumbnails.


New features

  • Republished for faster loading.


New features

  • Republished for faster loading.

Resolved issues

  • Updated thumbnails.


New features

  • Republished for faster loading.


New features

  • Republished for faster loading.


New features

  • Republished for faster loading.

Resolved issues

  • Updated thumbnails.


New features

  • Republished for faster loading.


New features

  • Republished for faster loading.


New features

  • Republished for faster loading.


New features

  • Republished for faster loading.

Resolved issues

  • Updated thumbnails.


New features

  • Republished for faster loading.

Resolved issues

  • Updated thumbnails.


New features

  • Republished for faster loading.


New features

  • Republished for faster loading.

Resolved issues

  • Updated thumbnails.
  • The Female devil horns are no longer inside-out.


New features

  • Republished for faster loading.

Resolved issues

  • Updated thumbnails.


New features

  • Republished for faster loading.


New features

  • Republished for faster loading.

Resolved issues

  • Updated thumbnails.


New features

  • Republished for faster loading.

Resolved issues

  • Updated thumbnails.


New features

  • Republished for faster loading.


New features

  • Republished for faster loading.

Resolved issues

  • Updated thumbnails.


New features

  • Republished for faster loading.

Resolved issues

  • Updated thumbnails.


New features

  • Republished for faster loading.

Tuesday 13 October 2009

C'mon, everybody!

We've gone on and on about the performance improvements in Moviestorm 1.1.7 for the last few months, and we've quoted all sorts of numbers to show you how clever we are. What you really want to know, though, is what this means in terms of the movies you can make and how easy it is to use Moviestorm. So, in my usual destructive manner, I decided to push Moviestorm to its limits and see what it could do. It was a simple test plan. Put as many characters as possible on the set, all different (in order to maximise the number of textures being used), animate them all at once, and see how big a crowd I could create before Moviestorm exploded. For reference, in the previous version, I had difficulty with more than ten characters, and twenty was out of the question.

Try this, then...

And, just for extra sweetness, that movie loads from the desktop into the Director's View in about 35 seconds.

To be fair, some disclaimers. It wasn't all fun'n'games. I did have to save frequently with this number of characters on set. Once I had over 50 characters in there, it ran out of memory after about 10-15 minutes of work, especially if it involved scrubbing around in Director's View, changing the duration of animations, or dragging things on the timeline. After 60, it did get quite painful, and was certainly more work than fun - though maybe that was just because I'd been repeatedly adding a character, choreographing them, and rendering the result for more hours than I could count. I also did resort to the trick of switching shaders off while I worked, and then back on again for rendering. I could probably have put a few more on, but by this point, I decided I'd reached Moviestorm's practical limitations.

However, dealing with ten or twenty characters at a time now seems trivial. I don't have to worry about whether putting an extra character or two in the background will cause Moviestorm to choke on its breakfast. I can do a small crowd if I need to - maybe not an entire stadium, but certainly a pub crowd.

It also came as quite a revelation to see just how many costumes we have now. There are over 60 unique outfits on the screen, and that wasn't all of them. Many of them are customisable, which means there are even more possibilities than you can see on screen. And that's just the guys!

It'll certainly be interesting to see what possibilities 1.1.7 opens up for you - we're looking forward to seeing your next crop of movies!

Three axes at once? Why not!

Occasionally I get some nice surprises playing round with pre-release code. I stumble over odd little things that someone fixed in an idle moment and then completely forgot about by the time we assemble the final version.

Like this, which I found earlier today.
That little link symbol, which has magically appeared on the smoke customiser*, means you can now resize width, height and depth simultaneously. Click it to link the three axes, and click it again to unlink them. You get the same on the flame boxes too.

That made me smile. It's little tiny details like this which are making Moviestorm ever easier to use.

*Requires special effects pack.

Monday 12 October 2009

No such thing as a free launch

The launcher is one of the least exciting and most unloved parts of Moviestorm. It's the bit that gets in between you and starting to make movies. However, it's something we need to pay attention to, because otherwise Moviestorm doesn't start up properly. We've made some small but significant changes to it for 1.1.7.

For a start, there's a lovely new logo in the style of the new user interface. More importantly, though, you now access the Modder's Workshop from the launcher, not from the main menu of Moviestorm.

We've also added a new screen, the Content Packs screen. This shows you which content packs you currently have installed, and also which content packs you don't yet own. There's a link to the online Marketplace so you can get more packs, and there are easy links to install or download addons.

So there you have it. Not very exciting, but useful.

Launch countdown to 1.1.7 continues...

Oh, if you're interested, that's my desktop background. It's a lovely 1920x1080 display, and that's a photo of sunset over Cambridge taken in August 2008 with my ancient Nikon E2100. Reminds me of home.

Friday 9 October 2009

Better crowd control with Moviestorm 1.1.7

One of the subtler changes coming in Moviestorm 1.1.7 - so subtle that I have to confess I've only just noticed it - is a complete rebuild of the script view, bringing in some really useful new functionality. This will make it much easier to do a whole bunch of things, but you'll definitely feel the difference if you're creating movies with a large cast.

You've probably never used the script view for anything other than flipping between different scenes or turning cel shading on or off. Let's face it, you've probably never used the script view at all, have you? That's OK. Neither have I.

This is it. A garish, colour-coded thing that you get to by clicking on the book-like icon at the top right of the control bar. It tells you the sequence of activities in your scene, but isn't really very user-friendly.

That's gone. Here's the new one.

You reach it in the same way, but the new icon looks like a speech bubble. Much easier on the eye, isn't it? More importantly, there's now a timecode against each activity, so you can tell exactly where in the scene you are.

Against each activity, there's the option to customise or delete it. This isn't new, but now that I've started using the script view, I'm finding it quite useful. It's much easier than dragging through the timeline trying to find an activity, and remembering who to select in order to get it to show up. If I want the bit where one of the aliens scratches his butt and get him to scratch his nose instead, I don't have to try and recall whether it was Alien01, Alien02 or Alien03, select him, and pick out the gesture from the timeline. I can see everything at a glance and pick it out from there.

But that's not the best bit.

There's a new tab on the script now, which gives you a full timeline for all the characters, plus dialogue, cameras and prop activities. This is something we've been wanting to do for a while, but never figured out where to put it. When you have a lot of characters - there are 17 in this movie - showing them all on the main timeline would take up half the screen, and not leave enough room for directing the action. If we put them all in the main timeline and you could scroll them, only being able to see a few at a time would be a pain.

As a result, co-ordinating several characters has been hard work. If you want them all to salute in unison, you have to set up one character, note the time the activity starts, pick the next one, drag the activity to the right start point, and repeat as many times as it takes. And, inevitably, by the time you've done six or seven of them, you're a quarter of a second out and you have to go back and do them all over again.

Now, that problem goes away. Drag the timeline to where you want them to salute, and then you can quickly and easily line up everyone's gesture activities against it. If you zoom the timeline all the way in (see the little -/+ controls at the top right?), you can get accuracy to within a single frame. The script view is resizeable too, so you can show a lot of characters at once - just drag the bottom right-hand corner out.

And, of course, if what you're going for is a slightly more natural feel, it's just as easy to make sure that they're slightly staggered - there's always one guy who's out of time, unless you're trying to create a drill display team! Here I have a moment where a musician comes on stage, and the crowd stop talking and turn to look at him, not all at once, but fairly close. Each of the green triangles is a "look at" activity, and you can see that he gestures (waves at them) in response. If I wanted him to come in a little later, it would be easy to drag the walk and all the associated "look at" commands, and I could be sure I hadn't accidentally forgotten someone.

And, of course, all the rest of the timeline functionality is available too, so you can customise and delete from the script view just like you can with any other view.

But hold it, there's more...

You can get to the script view from the camera view as well, which means that you can do something very powerful indeed. You can direct while looking through the camera. One of the most important thing a film-maker has to learn is that it doesn't matter what happens on the set. What matters is what the camera sees, and what it looks like in the edit.

The script view timeline brings those two together. If you want to ensure that something happens right on a cut, you can look through the lens, bring up the timeline, and adjust any activity, for any character or any prop, until it's right where you want it. The main timeline only shows the character the current camera is targeted on: the script timeline shows everything.

Here, for example, I can see exactly what's happening just as I cut to this shot of the band from a close-up on the drummer: the four main pyros have already gone off, so I will have a good cloud of sparks across the back of the set, the next pyro has just ignited, so we'll see that explode in the foreground as the shot happens, and the guitarist is just going into his rockstar pose. From here, I can easily open up the guitar sequence and replace the "gun" pose with a windmill pose, or else drag the entire sequence by a fraction of a second so he's in a slightly more dramatic pose as the shot starts.

It's hard to explain just how much difference this single change makes to the way I use Moviestorm. It gives me a level of directorial control and choreographic precision that has been lacking until now, and means I can make adjustments as they occur to me without having to change mode or mess around selecting people or props on set. The whole experience is more immediate and hands-on.

Try it for yourself when 1.1.7 ships, and find out whether it affects you in the same way!

Thursday 8 October 2009

Moviestorm 1.1.7 progress

It's all going to plan. We should be ready to build the final binary tomorrow, then next week we'll be onto the fun and games of installers & uploading.

As long as nobody says "what could possibly go wrong now," we'll be good to go mid-week. Just. Don't. Say it.

Tuesday 6 October 2009

Moviestorm 1.1.7 for release next week

We're down to just one last critical bug with 1.1.7, a nasty issue with sound under Windows (which has actually forced Dave, wailing and sobbing, to abandon his trusty Mac and use a PC). Once that's fixed (and right now it looks like we've cracked it), we'll be starting the final wrap-up, packaging, proof-reading, and building & testing the installers, and all the other necessary bits and pieces that go into making a release.

All being well, Moviestorm 1.1.7 will be ready for shipping some time next week.

Shiny new user interface and new help text.

Monday 5 October 2009

What are the best Flash video frame dimensions?

As part of the changes we've been making to the video encoding on our Web site, we've been looking at a bunch of movies that people have uploaded, and wondering why some come out better than others.

One thing that makes a huge difference is the resolution of the source video. There's one really simple rule to remember: video codecs perform best when the frame width and height use multiples of 16. So 768x432 will actually look better than 896x504, even though it has fewer pixels.

Tuesday 29 September 2009

Moviestorm 1.1.7 - Wooosh! It's damn fast!

One of the first things I do each morning, after I've set a pot of thick black coffee brewing in the Short Fuze kitchen, is to check the Moviestorm forums to see what's been said while I was asleep. Recently, I've been able to get daily feedback from the members of our Pioneers Club, who've been given early access to Moviestorm 1.1.7.

I've been delighted by the amount of feedback we've received, but not as delighted as the members of Moviestorm's QA department, who spend each day eagerly aggregating the responses from our Pioneers, and diligently recording them in our issues database.

The guys in QA are very, very good, but we know we won't be able to catch every single bug: there's only a few of us, and Moviestorm is huge. So, the abundant feedback from the Pioneers has been incredibly useful to us. The comments and bug reports have come in all shapes and sizes. Overman kicked things off with a short movie demonstrating some of the new features of 1.1.7. He sneakily hid a bug report at the end of the movie - not the first time he's done that, the little scamp.

Other pieces of feedback ranged from the mundane to the bizarre. In general, the Pioneers seem to be very pleased with 1.1.7, and excited by the new features. forgeuk made a post with a title which simply read "Whooosh! It's damn fast!"

There's no denying that it was a beta release, though. Some of the errors have been very strange. czechboysonic found a bug with a custom addon that didn't seem to load in 1.1.7.

Ben eventually tracked it down to a case-sensitivity error - just the sort of thing we might never have spotted without help from the Pioneers.

A release as big as this one inevitably contains new code and fixes which we haven't explicitly talked about. Sometimes, though, things get fixed that even we didn't know about. act3scene24 has never been able to quit Moviestorm properly on his Mac, and always has to force-quit the application in order to exit. Not any more:

We'd look terribly unprofessional if we admitted that we have absolutely no blasted clue how we fixed that bug (since we have no blasted clue what was causing it in the first place) so in order to save our blushes I'm happy to lie and say that I fixed it. Yup, that was all me. Thousands of lines of late-night coding have paid off.


Monday 28 September 2009

Fun with post-processing

I've been spending time making a music video for glam metal punk goth rockers SPiT LiKE THiS, and a few weeks ago I published a few screenshots of work in progress. It's proving to be quite an enjoyable challenge, for all sorts of reasons, and I'll post a few more things as I go. One of the things we decided we wanted was to have a studio sequence as well as on stage sequence. I wanted to get quite a different visual look for the two parts, so we could really emphasise the pyros and stage lights when we bring them in. Normally I just go for raw Moviestorm, but in the circumstances, I figured that some post-processing in Premiere was allowed.

This is what comes out of Moviestorm. Not a bad image of Lord Zion (even though he's missing his tattoos in this shot), but it looks pretty ordinary.

First things first, let's turn it into black and white. We could just leave it at that, and it would look more "artistic", but that's a lazy and boring approach. I don't care who else is doing it, it's just lame.

So now let's posterize it. Hmm. Still not very interesting using the default settings of 8 levels, is it?

So now we knock it down to just two colours. Pure black and white. That's better. Light and dark. That's starting to look better.

Now we can start messing about properly. We overlay this version of the footage on top of the original, and we feather the edges, so the colour bleeds through around the edge of the image. You can't really see it on the black sections, but it works well on the white sections.

And we finish by setting the upper image to 68% opacity. This allows a small amount of the colour to bleed through all the white sections, but heavily faded and desaturated, so what we end up with is an image that is both coloured and black and white. Effectively, we're drawing on 1890s hand-tinted animation styling as well 1960s poster art and modern computer techniques. It also has some elements of cel shading and rotoscoping, but doesn't use the Moviestorm cel shader.

And yes, that'll do nicely... and here's a short (silent) clip showing how Lord Zion looks in motion.

One of the techniques I had to learn was how to shoot footage for this. When everything's reduced to black and not-black, it's critical to be conscious of what's in the background, or else it'll create weird splotches, where a piece of furniture is turned into an odd-shaped object. Lighting and shadows are also crucial - what looks great in the original footage often looks dreadful when it's been post-processed, and I've had to go back and reshoot each take many times until it looks the way I want it.

And before you ask, no, we won't be able to do all this in Moviestorm, at least, not any time soon.