View Full Version : Dominance War V - Animation - TheGrak - God of Force

03 March 2011, 09:52 PM
The God of Force - (force being the underlying forces in our universe (gravity, electromagnetic, weak & strong nuclear), not Lucas' "force", although for this animation there will be similarities.) My inspiration for this is Blur's The Force ( Unleashed ( 2 trailers ( Not looking to rip them, just looking to explore that world. I'm juggling quite a bit right now, so we'll see how this plays out...

I'm planning on using the model by ylscy, and rigging will be done with biped, using Hormis' scripts ( I'm planning on having lots of destruction in the 480 frames, using my unreleased Destruktor script ( There will be other scripts used in other ways as well - I'll document them as the animation progresses - but the focus is on the animation.
I'll post animatic/concepts/rigging soon. Good luck to everyone!

03 March 2011, 11:05 PM
Good luck Grak! Your skills and toolset seem to be making leaps and bounds with each new competition your a part of.

Looking forward to seeing what you come up with!

03 March 2011, 08:12 PM
Thanks Kiel - much respect! You're going to be joining in this competition too, right? I can't wait to see what you come up with. I'm also excited about Xmen: First Class. :)

Here are some sketches that show how I'm developing the animation.
First, I have to define the god's powers in a more concrete way, then use those definitions to drive the god's actions. Here's some ideas on how the god might use his powers:
(link to full res) (

Having total control over the 4 forces of our universe makes this god quite powerful.
After cementing the god's "scope" of powers, and riffing on possible animations, I consolidated a bunch of ideas into a set of thumbnails similar to a comic book:
(link to full res) (

So this is a graphic representation of the plot: the god travels from outer space to a planet's surface, crash lands, and then proceeds to destroy the planet using his powers.

A few thoughts:
1. Each object in the scene will not exceed 750 tris (375 quads), but there will be many copies of those objects, so the tris for the total scene will be quite large. In addition to that, each object will be destroyed into fragments. An individual fragment will not exceed 750 tris, so I'm still playing by the DW rules.
2. Due to the scales and number of polygons involved, I will have to composite some shots together. For example, zooming out from the god on the ground to a planetary view (last shot) will have to be broken into separate scenes. I plan to accomplish this by sharing a camera move between two or more scenes, then using masks and passes to create a seamless transition. Note that I'm not talking about any textures or glows or fancy compositing magic - cause the focus is still the animation. So - in order to create what I want, I'm going to have to do some basic compositing. I don't think this violates DW rules, but I have a feeling it's scraping the ceiling.

Here's the todo queue:
1. Rig mesh, post test animations.
2. Build simple buildings, aggregate into city.
3. Create 3d animatic.
4. Finish scripting on Destruktor.
5. Revise shots until the deadline.

I have no plans on using sound for this video, but I may use the Zoom ( to record some rocks and dirt breaking up. Too early to tell. More coming soon! :)

03 March 2011, 08:54 PM
Hey man, nah, it's because of x-men that I won't be able to jump on. I'm kickin six day weeks trying to get this show out the door, so not enough time to do the competition well.

I like the idea and toolset you have rolling for your entry. What I would recommend though, is toning back the story element pretty heavily and focus more on the deity and less on the build up. 20 seconds is not a long time, especially when you want to convey weight/scale (since objects typically move slower to get across those points).

To help illustrate your idea, I'd take what you have now (the boards) and cut a board-o-matic in after effects. To simply play with the timing. I think you'll realize that theres too much for the frame count.

For example, I'd try cutting it down to only the character, so:
-starting with 'hello!' sequence
-'from pov3' first 3 and last 2 panels

Again, focusing on the god, the action, and reaching a highly polished level on all visible assets.

My 2 cents. Looking forward to your updates.

03 March 2011, 10:55 PM
Kiel - good thoughts man! I've put together 3 board-o-matics (H.264 .mov <3mb):

1. All the shots (feels rushed) (
2. Trimmed a little (a lil rushed) (
3. Kiel's edit (feels good, but I might add 1 more shot to it) (

I like a mix of 2 and 3, but you were right about putting all the shots together - there just isn't enough frames to do them justice and convey the scale, so some must be removed. And in the end, I'd prefer a few medium to long shots (duration) versus many quick cuts. I would like to keep the panels 'from pov3' all the way to 'boom!'. I think I can pull that off if I do a really fast zoom out, then the planetary explosion. That also makes compositing the shots easier, as there would be less frames to show the transition. So it would play out as: 1. hello, 2. pov2, 3. pov3, 4. explosion. We'll see how the animatic turns out! :)

03 March 2011, 11:53 PM
Good times man, edits look nice. Always useful to see it in some timed form before starting any sort of 3d. Glad it helped out.

Heres some other notes that came to mind:
-the mountain crush reminds me of doc manhanttan in watchmen:
I think you'll really have to play up the focal length, cam angle and debris to make the mountain look big enough.

-the Ground pound at the end remind me of the blizzard blood elf: (2:12)

-To help with pacing, it could be useful to have the city on the mountainside, have the deity swipe away the buildings like leaves, then literally rip the mountain it was on right out of the ground:

-Lastly, remember, to show big, you gotta show small. Make sure you have a lot of small, fast and numerous elements moving/animated to contrast the large lumbering motions of the deity, of the mountain rip, and of the city debris.

Good luck!

03 March 2011, 01:26 AM
Kiel - thanks man! I'll use those notes as a guide throughout the animation. :)

Lastly, remember, to show big, you gotta show small.
That statement kinda blew my mind cause I never thought of it that way, but it makes sense.

03 March 2011, 03:17 AM
Here's some early shots of the rig. I decided I'm just going to add extra bones in where I need them and use the basic biped. So, actually, I'm not using Hormis' scripts - but they're really good and everyone working with biped in max should at least become familiar with them.

03 March 2011, 10:41 PM
Rig complete, skinning in process. Updates:

03 March 2011, 11:20 PM
You crazy kids and your Character Studio. Dunno how you guys make it work so well.

Careful about the red eyes, I think that breaks one of the rules for the competition.

03 March 2011, 08:58 PM
Kiel - good catch on that. The god character is now just a solid color material.

Here are results from city building and volcano makin':

And here is a test composite of one of the storyboarded shots (I'm also trying to establish scale and style for the video):
(link to 1280x720 composite) (

Here is a .gif showing the composite's layers:

I need to finish up the skinning on the character, and then begin laying out the first keys for the animatic. I'll be using Camerman ( for all the cameras. The buildings were 'projected' onto the volcano's surface using Projektor ( Stay tuned! :)

03 March 2011, 07:08 AM

Here is a preview of Destruktor ( More coming soon.

03 March 2011, 10:36 PM
Destruktor looks promising man, same with your initial scene layout.

Keep it up!

03 March 2011, 08:25 AM
This one looks very promising for sure!! Hoping to see further updates.

04 April 2011, 05:40 AM
And here are updates!

First, here's shot 1 with the first pass of keys applied:
Watch the video here. (
I'm also developing the composite to accept revisions easily, so I'll try to only post composited shots. This animation was first storyboarded (see above), then reference animation was shot, then the character was animated to the reference footage. There is still a lot to go.

Switching gears, here's the first screencaps of destruktor in action:

Here's a video to watch. (
So, now let me address what Destruktor is (and isn't), how it was built, and how it functions.

Destruktor is a tool for art directing destructions.
Destruktor does not do physics simulations, does not use reactor, or physx.
Destruktor does not keep fragments from intersecting with each other.

These are important limitations to keep in mind, as they essentially mean Destruktor does not do 'realistic' explosions or destruction. Instead, think of Destruktor as a way to 'paint/animate destruction'.

Paint? Animate? Read on... Destruktor will fracture any mesh into pieces, then plug those pieces into a particle system that comes pre-loaded with gravity, drag, and wind forces. The fragments are 'activated' by a spherical Udeflector, which acts as the 'paint brush' for the destruction. Where ever the paintbrush (Udeflector) goes, destruction occurs. Pretty simple.

Since Destruktor uses a particle system to control the fragments, it only seems natural to do some shape instancing to create additional debris. Destruktor adds 2 layers of debris automatically, with scaling of pieces being 50% with 25% variation, and 15% with 100% variation. This means for every original 'chunk' you create when you fracture a mesh, you're actually getting (1orig+2med+3small=) 6 chunks back from the particle system. This also betrays a 'realistic' simulation, as Destruktor generates extra fragments that shouldn't really exist. But it looks cool. ;)

Destruktor is a frankenstein script that combines parts of Garp's fracture voroni 1.1 script with a particle system birth script written by Laurent Renaud, then automated/glued together with some code I wrote to automagically build a custom particle system. But the best part is yet to come...

Next I plan to build batch processing into Destruktor, so Destrukor can accept a selection of objects, then fragment, save, and render each object in their own scene - while also writing a log. This means I can run large simulations over-nite, automatically rendering them for compositing in the morning. And because each object is saved as it's own scene, only that object's fragments take up memory. So I can fragment, save, and render as many objects as I'd like to, then composite the passes back together later on. That's the best part.

@ KielFiggins & Audin: thanks y'all! :)

04 April 2011, 03:49 PM
great stuff, keeping an eye here.

04 April 2011, 07:08 AM
Batching works.
Here's a 1920x1080 10 second video of 200k polys getting destroyed. (
Fracturing and saving out the files took around a minute.
Rendering to exrs @ 1920x1080 took around 15 minutes.
The scene contains somewhere around 33k polys, times 6 (5 layers of shape instanced debris).

I'm planning to work around the scanline's max poly ceiling by coding a process I've codenamed 'dynamic zdepth sorting'.
The process can be described like this (and it probably already has a real name, so pardon my ignorance):
(0. For a collection of objects, fracture each object into it's own file, save file)
1. For each file, for each frame, create arrays containing file objects that meet a certain zdepth criteria.
2. For all the arrays, merge all file objects that meet a certain zdepth criteria into a scene.
3. Render that scene as a zdepth 'slice'.
4. Repeat process starting with 2, until all zdepth slices are rendered.*
*zdepth 'slices' should be user set. 10 slices = 10 passes for compositing.
zdepth criteria would be max zdepth distance divided by number of slices, as array.

It need more development, but it's starting to shape up to be able to convey the scale I want, while still allowing me artistic control over the animation of the destruction.

@ brazz: thanks man!

04 April 2011, 07:15 PM
Release time!

Here is a link to Destruktor Version 1.0 .ms. ( (It still has some major bugs in it.)

I've been crazy busy wrapping up some projects, but now I think I have the time to come back and work on my entry. I also wanted to release this script to everyone, so I'm not working with proprietary tools.

I know, I know.. this is the animation category. I'll post some of that stuff soon! :)

04 April 2011, 07:34 PM
Awesome! Thanks for throwing this out there for us to try! Looks pretty cool so far after messing with it a bit :)


04 April 2011, 01:51 AM
@ jchristo - thanks for trying it out! It has some really strange bugs in it right now, but I hope you find it useful or at least interesting. I really like how your animation is progressing! :)

I rethought shot 1, worked out some bugs with destruktor, directed some destruction, and composited it all together...

Here's the animation. (
There's a lot of fragments in there, but not a single one of them is over 375 quads.
There are (500 fragment objs * 20 small * 10 medium) + (35k fragment crater debris objs).
If I change 35k to 40k, the scanline can't allocate enough ram for the scene and asks me to reduce the face count, so thats the 'ceiling' for the scanline on a 32 bit system. Everything is composited in passes, so the ceiling isn't really a problem. 'Dynamic zdepth sorting' is possible, but not within the time frame left from now till the deadline, so I won't be completing that idea any time soon. I've got a good idea for shot 2 that is brewing.

More coming soon.

04 April 2011, 05:43 AM
Looking fancy! Seems the time spent on your script will pay off, very exciting.

Heres some feedback if your interested:

-Your camera should lag behind the motion, not anticipate it. Ease back on the drift up and leave the camera catching up to the action on screen. Remember, no matter how well choreographed a sequence is, a real camera man is reacting to what he sees.
-Don't be afraid to crop what you see. Think of the majesty and scale it would give the viewer if you didn't see the top of the mountain when he rips it up and it required the camera to contiue arching up to see the full destruction.

Hand Anim:
-Reads a bit samey at the moment. You may want to vary you poses from collapsed to spread to help add impact and variety. Starting the fingers off much more clenched/J-ed with make the splaying open that much more intentional and really signify an event.
-When he brushes the mountain to the side, this is a good oppurtunity to get him to do a side step and shift his weight. This would active his whole posture and give you a reason to get into a new stance for his next 'feat'.
-I would really avoid the return pose, since its so simliar to lift up pose.

Other possible Hand poses:
Darth Vader hand pose: nice forearm twist in, unique finger silouette:

Tiger Claw: Shows good tension

Various Spell Casters:

Hope these help man, good luck, can't wait to see more!

04 April 2011, 09:00 PM
@Kiel: Thanks for the feedback man! I have to agree with you on all points. Your feedback always helps - you're pushing me to get better, and I really appreciate it! :)

05 May 2011, 03:17 AM
Here's an update! (

Revised shot 1 a bit. Still need to fix the return pose.
Began shot 2, setup the composite, determined the scale, setup the camera move, setup the first pass of keys on the character, determined the timing, began to fracture the planet meshes... and then the destruktor script started erroring out...
For some reason, garp's method of collecting an array of random positions was failing to collect on meshes that were of galactic size, and specific to my working scene. That was a major problem. I narrowed it down to a few statements:

pSys = pcloud emitter:obj formation:3 total_number:nbParts quantityMethod:1 viewPercent:100 seed:(random 0 100) isSelected:off
aCoords = for i = 1 to nbParts collect particlePos pSys i -- fill with random coordinates
delete pSys

aCoords was printing an empty array. I attempted a few fixes, but none worked. I wasn't sure how I was going to break apart these planets... until I realized that the array of random positions didn't have to be an array. I could just randomize the position everytime, then slice. This led me to create a simpleSlicer ( algorithm that operates (somewhat predictably) on all meshes, regardless of their size. Then I chopped the planets up into pieces small enough to input into garp's fracturing algorithm. I haven't got the destruktion passes ready to show just yet, but they are on schedule for the May 15th deadline. It is May 15th, right? :blush:

05 May 2011, 03:54 AM
Oh yeah - here's DestruktorV2 (
I'm really happy with this release, but it still has bugs. :(

I removed the batching because it wasn't working as I wanted it to.
I had to do an assessment of the remaining time and remaining items to be implemented and decided that batching would be cut in favor of a slicing method. The slicing method was fun to implement, and went through several revisions before being integrated into the destruktor script. It's also available as a standalone script (, but that script is really intended only as an example of migrating code from one layout to another - in other words, destruktor v2 has all of simpleSlicer's functionality and much more.

And here is a rant about programming bugs: We all hate them, they will always exist, we must fight them together. Way too much hatin' on autodesk lately. To all that hate: try writing a multithreaded app in C that manipulates and renders 3d objects - and then get you can talk/complain.

05 May 2011, 05:15 PM
Here the latest on the animation. (

Here's some images.

deadline extended to may 24th? ...must render... more.... destruction passes...

05 May 2011, 12:30 AM
Really nice animation my friend.

05 May 2011, 05:26 PM
Hey man, looks like it's coming together. I have a few suggestions, take them or leave 'em:

- Maybe leave a crater behind where the base of the mountain used to be.
- Have the pieces of the mountain move a different speeds when he 'wipes' them to the left. Right now everything appears to move at basically the same time, and at the same speed. Some variation here could help.
- The quick turn he does after the mountain wipe seems odd and unnecessary to me. Does it matter that he faces one way or the other if he's going to blow up the whole planet? I would nix that move as it looks a bit rushed in terms of timing.
- His big ground pound looks a bit too linear(?). It's almost a three pose, three count move - down, up, down - each with about the same amount of time. His pose at the apex of his jump has both arms back, both legs back - sort of a twinned pose. Maybe toy with this pose, adding some twist to the spine, or maybe offset the timing up his arms as he goes up (since one is much bigger/heavier than the other.) I dunno, I think you could get more out of this move. This is the big move of your entire piece, the planet killing ground pound, I'd push it here.
- Curious as to why the exploding ground from his ground pound originates from 50 feet behind him. I would think that the epicenter of the destruction would come from where his fists smashed the ground.
- As he speeds past the camera at the end I would consider slowing him down just a tad so he is more visible. I showed a friend of mine your latest youtube vid and he totally missed that your guy zipped past the screen. You can miss it if you blink at the wrong time. =)

Hope that's helpful.

05 May 2011, 10:46 PM
Here an update to the animation. (

-More destruction passes have been added, animation has been polished a bit more.
I added in the CGsociety logo (on the moons), and added some text overlays (name, challenge, etc...). Also added in some soundFX.

@arokz: thanks man! :)

@Gatecrasher: it's always nice to get solid feedback from talented animators, so thank you. Here's my responses to your feedback -
- there is a crater object left behind, but it's not too obvious. I should accentuate this 'crater-ness'.
- i agree with moving the pieces at different speeds. this is something i need to do.
- i added the turn to shot 2 to help glue it to shot 1. i added the turn to shot 1 based on kiel's feedback of 'you should change the return pose'. There is no reason for him to turn, you are correct. I may drop those keys to make room for the ground pound, but I feel kiel is correct with his assessment of the return pose, so that needs to stay and be reflected in shot 1. So, there's work to be done here. :)
- i completely agree with you on all points regarding the ground pound. his legs and arms are twinned, and it really is only 3 keyframes (up, down, up). if i make room for more keys by removing the turn pose, i think i can really push this animation further. it also feels rushed.
- ah, yes.. there are serious shortcomings with the manner in which the ground breaks apart. Now that we've got some extra time (May 24th?) I'm contemplating another approach to breaking the ground up. At first I wasn't sure I could even get this far when working at such scales (and some weird bugs manifested along the way), but now that I know it's possible - well, I better revisit the solution and try again. quality over quantity (pun intended here). :)
- i added an extra frame of the god flying by, let me know how it reads now.

feedback is always helpful! thanks Gatecrasher!

my personal critiques of the animation so far:
- the shadow solution implemented is very poor. currently I'm using a single 3072px shadow map to cover the entire moon and it's fragments. a 4096px map errors out the scanline (while rendering fragment heavy passes), rayTracing the shadows results in a 'not enough memory' error, advancedRayTracing does the same, and don't even get me started on the rendering times of softShadows. Switching over to mentalRay and setting the light's shadow to mr shadowMap provides a better shadow solution (when set to 3072px map), but the renderer requires between 1 - 3 minutes per frame with motionBlur. Which isn't bad until you compare it to the scanline with the shadowMap - each frame comes in under 10 seconds, with vector moBlur. So, I'm faced with "render it in less than 20 minutes", or "render it over the course of more than a day". When you constrain all this to a timeline - well... I may not change the shadows... but I'm aware of the massive mile-wide pixels on the planet's surface. :(
- the camera moves in shot 1 and 2 are not meant to be realistic or possible. i agree with kiel that the camera should lag behind the animation when realism is wanted. however, i purposely chose to time the camera move with the character's animation to emphasize the action. personally, i feel this emphasizes the action, but i know that's not an objective consensus.

05 May 2011, 06:50 AM
Hey man, i am digging the God Of Force and his ability to move mountains and break up the planet. The whole opening shot of your animation is well done. Very powerful.

When he pounds the ground, he seems to exit pretty quickly. Have you considered making him take a step or two, then take off? From 00:09, I am looking for him to have some reaction to the crumbling planet or maybe a camera change so we see him again. I think the extension you made of him flying by helps. Are you planning to keep the length of his final appearance about the same, and maybe add a 'whoosh' sound of some kind?

Keep it up. This is turning out great.

05 May 2011, 01:06 PM
Hey Garrick I thought I'd add a couple suggestions.
I really like the character animation. I think with the updates others have mentioned the character animation will turn out looking good.
- The destruction of the mountain looks pretty nice, and with some speed variation it will look even better.
- The planet destruction doesn't look that great IMO. It has a bunch of triangular pieces/particles which resemble the type of particles available since forever in the legacy particle generator PArray.
I really don't have a good suggestion for this unless you can reference 5-10 hand made pieces which are within the 750 triangle count that could be x-refed in place of the particles that are currently in the explosion.
- There seems to be a blurred transition or something going on at around 15 seconds. Is this a transition from close to the exploding planet to farther away?
- I barely caught the character flying by at the very end. I think it would look real cool to see the God of Force flying between and around all the pieces of the planet as it explodes, then do a type of "Superman" hover/floaty pose at the end looking back at his handy work.

Hope your able to finish in time. Good luck.

05 May 2011, 04:33 PM
@ishkur13: thanks man, I'm really happy with how shot 1 came together.
When he pounds the ground, he seems to exit pretty quickly. Have you considered making him take a step or two, then take off? From 00:09, I am looking for him to have some reaction to the crumbling planet or maybe a camera change so we see him again. I think the extension you made of him flying by helps. Are you planning to keep the length of his final appearance about the same, and maybe add a 'whoosh' sound of some kind?
You're right, I need to revise the timing and keyframes of the character during the ground pound. He exits too quickly, and it doesn't read very well. I'm thinking about adding one more frame to the flyby at the end. There is a very quiet audio 'whoosh' when he flys by - I'll be sure to turn that sound clip up in the next version! :)

@theANMATOR2B: thanks for the comments man! I like how your animation is coming together.
- The planet destruction doesn't look that great IMO. It has a bunch of triangular pieces/particles which resemble the type of particles available since forever in the legacy particle generator PArray...
- There seems to be a blurred transition or something going on at around 15 seconds. Is this a transition from close to the exploding planet to farther away?

I need to replan how shot 2's destruction occurs. Right now, the video fades between a medium and far destruction pass around 0:15 (this will be masked together and not faded in the final video). I'm planning on breaking these 2 passes into 3 passes - upClose, medium, farAway - for more detail and proper interaction. Then I'll update the shapeInstance operators in the pSys to not reference the simple triangular fragments - cause you're right - those fragments look very 'legacy'. :)

Here's some doodles showing my thoughts on the new destruction passes:
In the current video, only 'medium' and 'far' passes are being used. I think the addition of an 'upClose' pass (with many, many small fragments) will help sell the ground pound to planet destruction animation. I'll rush these passes together and see how it turns out. :)

05 May 2011, 05:05 PM
I've rethought the character animation for shot2. Instead of a ground pound, I'm going to change all the keys to be just a jump, with a build up. Here's a quick board:
This animation should play nicely with the method I'm using to frag the planet. It should also read better due to there being less movement in the same amount of time. I may scrap shot 2 and start from scratch... with 4 days left! :)

05 May 2011, 05:26 PM
With the image you supplied on post 31 I now understand what you are going for. The animation doesn't read as fluidly as your explanation and the image at the moment, but I'm sure you'll pull it together.
I still think showing the God fly through the debris fields as the planet explodes would really look cool.
You could keep the near-mid-far passes as you explained and have him flying through the debris in each shot until the final far pass where he turns and admires his destruction.

Just a thought.
Keep at it, 4 days is a pretty short time, but if you think about it in terms of hours (96) you have plenty of time!! :)
Good luck.

05 May 2011, 05:48 PM
I still think showing the God fly through the debris fields as the planet explodes would really look cool.You could keep the near-mid-far passes as you explained and have him flying through the debris in each shot until the final far pass where he turns and admires his destruction.
@theANMATOR2B: good idea - I'll try to get that animation in there too! :)

I just stumbled across a free, awesome plugin for max 2011 named dynamica, based on bullet physics ( Even includes the source code. So, I may develop destruktor to work in conjunction with bullet (and then destruktor would have collision detection!). I'm dreaming up ways of combining particle systems with bullet, so the sim is based in reality but accentuated with direct-able debris. It depends on the source code and if I can wrap my brain around it.. definitely not within 4 days. Bullet is exciting - though I'm sure I'll face down some mysterious bugs. C'est la vie.

05 May 2011, 07:06 PM
Update: I'm digging thru Winchester ( by James Haywood, thinking of extracting some concepts to integrate into destruktor, and then try to link destruktor to bullet. I'm sure that I can't get it up and running by the deadline, but winchester is a great reference and inspiration. It also inspires me to build another tool... closely related to Tyson's tutorial in a book that was published within the last few years... he discusses using particle flow to build a gun that shoots bullets, stamps on impact textures, and generates debris... somehow I'd like to combine all these concepts into a pair of scripts, then tie those together with bullet... I'm also refactoring the slicing algorithm I mentioned before... working on coding no arrays inside the slicing loop, and only one array to store the objects to slice. Then I can put every detached sub-element into the slicing array, then slice up the slices ad infinitum... I've also been studying algorithm complexity and orders of growth... I'd really like to code a slicing/fracturing algorithm that operates in log or linear time.. then bring back batching... slicing objects out to their own files... then merging them back into a master scene based on their zdepth... so much to do :)

05 May 2011, 08:20 PM
Sounds interesting, except for the code part! :)

How's your animation coming along? Hope your able to finish in time.

I spent most of last night becoming a mental ray expert (haha) and am now cussing at the render times per frame.

Good luck on the final push.

05 May 2011, 03:11 AM
How's your animation coming along?
Worked on the keys a bit this afternoon:
Here is a link to a .mov 500kb preview. (
Gonna get the ground cracking under him, add a little foreground 'lift debris', camera shake, sudden zoom, a couple dutch angles, revise the animation, start rendering passes.. will probably cut to a far away shot of the planet exploding and him flying up, stopping to check out the destruction. I think the concept will read better this way, as opposed to actually doing a ground to space zoom (which has a lot of fun problems).

05 May 2011, 04:23 PM
Got the camera move down. Polished the character animation a little more.
Here is 1mb .mov preview of animation. (
Now I'm moving into setting up the pSystem debris.
Everythings on schedule for a monday deadline. :)

05 May 2011, 04:56 PM
Here is shot 1 glued together with the new shot 2 @720p. (
Working on a new shot 3 today. Will post progress. I'm sure it can be finished before 12am today, its really just a question of "how good can i make it within that timeline?". Need to complete some small tasks like: fix the speed on the pieces of the mountain move, fix some self-intersecting geometry in shot 2, and add some houses to shot 1's foreground. The houses need to be introduced in shot 1, otherwise they feel out of place in shot 2. I introduced a shot0, which was a wide angle establishing shot of the city with the mountains in the bkg, watched it in context, then cut it. Here's a still from that (now cut) shot:
I cut it cause it didn't make any sense to follow this shot with a close up of the character's hand. It was quite a jarring cut.

05 May 2011, 07:50 PM
heres the first pass at shots 3 keys ( (establishing timing and root movement)
it already reads better :)

05 May 2011, 11:30 PM
well... here it is! (
^ Shots 1, 2, and 3 all together. I decided not to add any audio.

Here's some images from the animation: (here is a link to a bigger image (

It was a fun competition everyone! :) Good luck!

05 May 2011, 02:31 AM
Awesome! That shot sequence is working well. We get to see your God nicely as we fly away with him from the destruction. I like the changes.

05 May 2011, 12:34 PM
like it too bro, turned out nice. Great that you sticked to it and kept us updated.

CGTalk Moderation
05 May 2011, 12:34 PM
This thread has been automatically closed as it remained inactive for 12 months. If you wish to continue the discussion, please create a new thread in the appropriate forum.