Tumblelog by Soup.io
Newer posts are loading.
You are at the newest post.
Click here to check if anything new just came in.

February 19 2012

October 18 2010

October 16 2010

July 21 2010

June 23 2010

Braindump: Live-Action Animation?

Wow, it’s been quiet around here.

Anyway…

There are some absolutely stunning realtime 3D engines available these days, primarily intended for games.  A few groups also use these game engines to make short films, or machinima.

While perhaps not quite up to cinematic standards, some of the engines meet or exceed the graphical standards of what you’ll see on TV animation.  It’s interesting that no-one seems to have attempted using machinima techniques for television shows. Admittedly, machinima relies on the game engine handle the minutiae of animation, and uses pre-written scripts for the character keyframes, so as it stands it’s quite limiting from a creative point of view. But does it need to be?

Motion Capture

Motion capture can be done pretty cheaply these days with a couple of cameras and some ping pong balls; and some more advanced software might not even need the markers. Given a 3D character that has been properly rigged, it should be possible to map the motion data directly onto the model, without need for prescripted animation sequences. Most of the latest engines support facial animation as well; with a cheap knockoff of James Cameron’s face capture technique from Avatar, it should also be possible to automatically reproduce an actor’s expression on the model as well.

Usually the camera is controlled by another player in the game engine, but when appropriate, even this could be done via motion capture, as Steve Jackson did with Lord of the Rings. This would allow for vastly improved camera interaction with characters and scenery. Imagine “filming” a motion capture performance with an iPad, and seeing the final result right there on the screen!

Modelling and Set Building

Character and scene modelling are fairly time consuming tasks, but probably comparable to costume design & set building for traditional filming; perhaps even faster, and certainly cheaper due to the absence of material costs. The model rigging process for animation is still needed, which can be performed by a competent modeller; but for most purposes there shouldn’t be a need for the more specialised animator skills, as the roles will be played out by actors directly. This would bypass another major time sink from the animation process.

Filming and Production

By working with realtime rendering, production times could be cut down considerably. There wouldn’t be a wait to see if each scene had rendered correctly, with associated turnaround times if changes were needed — just reshoot the scene with the actors as you would normally. All the setup and motion data for a scene could be stored, so if the performances were good but the camerawork was not, the digitised performance could be reshot using the existing data. The camera operator could be shown a first-person realtime feed of the performance in the game engine as he “films” it again. This could allow for some innovative camerawork, too — there’s no reason why you’d need to operate on the scale as the original performance. The entire scene could be scaled down relative to the camera operator; he could walk around the scene doing a sweeping overhead shot that would normally require an expensive crane (or even a helicopter), and do it all by hand.

Typically the production would be edited as normal, then rendered out as a finished video. The final rendering could run slower than realtime and add extra effects and beauty passes if necessary. However, that’s not the only way this process could work…

Realtime Performance

This setup would allow for truly realtime animation, such that a show could even be broadcast live.

And it wouldn’t need to be broadcast to television, either. Using the game engine’s network code, the performance itself could be broadcast straight to a rendering client, and the viewer could watch a live stream in ultra-high definition with minimal network traffic. If desired for the production, this would even allow the viewer to have control over the camera themselves, and view the performance from wherever they liked in the scene.

This would allow for the first truly 3D performances; the entire scene information is available to the viewer, so given the appropriate hardware (for example, head tracking stereo glasses), they could be immersed directly in the scene itself rather than looking through a window with current 3D TV approaches.

Share/Bookmark

July 26 2009

Moon landing equations

Solving the equations needed to land on the moon.

Solving the equations needed to land on the moon.

Share/Bookmark

July 22 2009

Calculating trajectories for Apollo program

Apollo mission near moon with weird looking blue planet in background

Apollo mission near moon with weird looking blue planet in background

This is a great article by the guy who calculated the trajectories for the Apollo missions.

Share/Bookmark

May 26 2009

Braindump: Risk MMO

I frequently get odd little ideas into my head that I know full well I’ll never follow though. Rather than let them fade away, I feel I should start writing them down in case someone else might be interested.

A Risk-Like MMO

At one point there was a version of Risk written for the Google Maps API (which has since been shut down by Hasbro). I wasn’t a Risk player when it was around, but now that I am, it got me thinking about multiplayer Risk over the internet — and then about a massively multiplayer extension of the game rules…

Obviously it wouldn’t extend to thousands of players like WoW; more like 50 or so per game. And it couldn’t follow the original rules too closely, or it would be unmanageable. (Imagine waiting for your turn in a 50 player game!)

Here’s some rough ideas I’ve come up with so far:

  • First off, call it something other than Risk, or Hasbro will string you up!
  • The map is subdivided into real, contemporary territories. Larger countries are divided into their states or provinces. (Instead of 9 territories for North America, it consists of the 50 states of the USA and the 13 provinces & territories of Canada.)
  • Where this gets unwieldy (eg. USA), the states could be grouped into regions which roughly approximate the original territories. Controlling a region earns a small benefit (say +1 reinforcement), and the whole nation earns some additional benefit. At this point, controlling the entire continent may not need additional bonuses because of cumulative effects.
  • Players are assigned a rank each round, calculated first by territories, then regions, then units, and finally by a random number assigned each round. (All else being equal in the first round, rank is random.) Players can see each others’ ranks for the round, so they know where their biggest threats lie.
  • Each player takes their turn simultaneously. They have a fixed period in which to enter all their movements, then all battles get resolved in one batch. Battles are processed in rank order. The players are shown the results of the battles, then the next round begins.
  • Turn order is as follows:
  1. Fortify (except first turn) — this happens first instead of last, because you only find out the results of your battles at the start of your next turn.
  2. Reinforce — place units as normal
  3. Attack — you can only attack from territories you control in the current turn. For a territory with X units, you can allocate up to X-1 units to the attack. This many units are committed to the battle; all surviving units will move to the target territory. If all X are killed without a victory, the attack ends. One territory can attack multiple targets by splitting the unit count. (eg, for a 6-unit territory, 3 could attack one target, and 2 could attack another in a single turn.) Battles are processed in the order they are entered.
  4. The turn ends when the player is satisfied, or time runs out.
  • There will probably need to be more interconnections between territories. Perhaps certain key territories could hold airports, with permanent connections to other airports. If you control any 2 airports, you can also reinforce between them (even if they don’t otherwise share a connection).

I’m sure there’s a lot more to take into consideration too.

If you’ve got any thoughts, feel free to leave them in the comments!

    Share/Bookmark

    May 19 2009

    DataBeans in Groovy

    Okay, not many will be interested in this perhaps, but I thought I might put it up. I use a data objects framework called DataBeans which you can find as part of the sticker.jar file in the Sticker instant messaging tool (http://tickertape.org/projects/sticker). DataBeans gives you a JavaBeans style interface to nested hashmaps, but it has an event mechanism, so you can listen at the root bean and hear changes inside (including path info to the change). Neat huh.

    Anyway, my supervisor said he’d be impressed if I could do some Groovy (http://groovy.codehaus.org) meta-programming to allow access to DataBean properties without having to use the typical getValue(String name) and setValue(String name, Object value).

    After a little looking around I wrote this program which adds a couple of methods to the DataBean’s meta-class (what supports most of Groovy’s dynamic behaviour). All you need is sticker.jar on the classpath and this will work without issue (oh, I’m using groovy 1.6.0 but I think it’s available in 1.5.x).

    import dsto.dfc.databeans.DataBean
    
    DataBean jdb = new DataBean()
    jdb.setValue("a", 1)
    jdb.setValue("b", true)
    
    DataBean jdb2 = new DataBean()
    jdb2.setValue("aa", 42.0)
    
    jdb.setValue("c", jdb2)
    
    println jdb
    
    DataBean.metaClass.propertyMissing = { String name ->
      value = delegate.getValue(name)
    // the commented code will allow statements like db.a.b = 'c' when a is undefined
    //  if (!value) {
    //    value = new DataBean()
    //    delegate.setValue(name, value)
    //  }
      return value
    }
    DataBean.metaClass.propertyMissing = { String name, value ->
      delegate.setValue(name, value)
    }
    
    println jdb.c.aa
    jdb.c.bb = 'hello'
    println jdb.c
    
    try {
      println jdb.d.dd = 3
    } catch (NullPointerException ex) {
      println "NPE on 'jdb.d.dd = 3': ${ex.getMessage()}"
    }
    println jdb

    Even if it’s of no use to you, hopefully it may intrigue you to look at Groovy or DataBeans (when there’s a link for that I’ll post it).

    April 21 2009

    Welcome to LabF

    Hey guys,

    This site needs a bit more work but I think this is a great starting point.

    Enjoy.

    Share/Bookmark

    Older posts are this way If this message doesn't go away, click anywhere on the page to continue loading posts.
    Could not load more posts
    Maybe Soup is currently being updated? I'll try again automatically in a few seconds...
    Just a second, loading more posts...
    You've reached the end.

    Don't be the product, buy the product!

    Schweinderl