Category Archives: Year 2

Dynamics Week 15 (final) -Process Diary

Final UFO

I will treat this as a new and separate blog for the UFO dynamics process diary ‘after week 9 feedback’ so please see the week 9  entry for previous blog stuff.

Firstly, here is a summary of the teacher feedback from the week 9 blog itself –

Feedback – liked the movie documenting of experiments.
Action – cool, I will continue with these.
Feedback – good amount of reference gathered , more moving reference would be useful.
Action – Ok, will continue using this reference and address more specifically the movement of the particles.
Feedback – more detail in regard to problem solving and workflows/methods.
Action – sweet, I love talking about this stuff! Putting thought into the ‘how and why’ is one of my strong suits!

Now to the dynamics work.
First of all, here is a recap of what I submitted in week 9 –

As you will notice , I had separated the tractor beam into 3 segments to improve the communication of feedback.

I will talk about theses 3 segments, how they were initially created and the changes I have now made based on –
– the ‘client’ feedback
timing and distance changes made to brief (previz)
– other changes and embellishments based on my own improving skill-set.

Core Beam – 

At the week 9 review, I had created an outer cylindrical beam pulsing up and down rhythmically. I called it the ‘core beam’ as it was the main shape for the tractor.
The positive feedback was that it ‘turns on in a pleasing way’ and the color is ‘bang on’.
There was 2 points of negative feedback
1. The movement up and down looks weird and is not required.
2. It needs some variance in its makeup, it feels too consistent.

The essence of how the core was built was a poly cylinder –
I needed to modify the geo so that the tractor matched the new scene (the ship is now higher up in Y)
I had used a ramp mapped to the texture rate – ’emit from dark’.
Notice above that the ‘selected position’ is keyed – I needed to change the animation so that the particles just traveled downwards i.e no more ‘pulsing’ and then stop emitting just before the door closes –

Then for the ‘breakup/variance I used a similar but more advanced technique with a shading network introducing animated fractal textures and a simple expression –

which gave me this look of wispy splines creeping down the column – I find that this method of assessing the look of the particles at a texture level, before you generate particles is really helpful – you can see the changes on the fly and scrub the timeline to see how it animates. Then you have an idea of what will happen when you emit  – what kind of particle count you will need and how long they should live. With this kind of look, I knew that the lifespan should be very short, otherwise it would just be a mess.
I also decided to render this breakup separately from the main column so I can control the look in comp.

These 2 elements form the new and improved ‘Core Beam’ and it looks like this so far-

Fractal Circles

At the week 9 review, I had created a circular shaped disk that travels up and down the core beam to add another level of interest.
The positive feedback was that it looks ‘cool’. It ‘adds some movement to the beam which works.’
There was 2 points of ‘negative’ feedback (not that negative, just changes to work on) –
1. ‘It would work better if the fractal just went in one direction. So make it move from the top to the bottom and then die.’
2. A couple of creative suggestions –
a. It might be worth trying this, when the fractal particles hit the ground they turn into mist or some other cool effect. I suggest making it very subtle.

b. Also, it might be nice for the fractal particles to generate a fine layer of particles that sheer off from the core beam as it passes over the top. This could be used to create that dissipating/vapour look that appears in a lot of the reference.

This ‘fractal circle’ of particles will be comped over the existing core beam. It is created in a similar way, using a shading network that is animated to match the timing of the door opening/closing.
So firstly, I corrected the timing to match the new timing of the door. Then I changed the ramp keyframes so that the circles are never visible traveling in the upward direction. Instead they appear to die –


With regard to the creative suggestion of making them turn to mist as they disappear– I thought of a way to do this –
I decided to make the fractal circle particles emit their own secondary particles. I could control the emission rate to just emit at the death of the fractal circle – then these secondary particles sheer away driven by gravity and turbulence fields – they peel away from the main column and fall. I would need to give them just enough lifespan  and opacity PP to fade away as they fall.
This required lots of tweaking to get the right look, but in the end I think it works quite well.
In total, these ‘secondary fractal circles’ are formed 3 times at the base of the column and once more at the top of the column just before the door closes. If I have interpreted the feedback correctly then I think this is exactly what the ‘client’ is after –


I was pretty disappointed with what I had achieved with the tendrils in the week 9 submission. I knew what I wanted and what the client wanted but in all honesty I was a bit lost for how to make it happen.
The feedback was that “the tendril feels a too wavy. It feels like the movement is coming from the top, up in the hatch. The head of the tendril, which is the part that moves towards the mannequin, should be the part that leads and determines the movement. What lags behind is more like a trail. Basically the opposite of what you have now. I would like to see 2-3 tendrils that latch onto the mannequin”
This feedback actually made me realize why the movement was wrong – this is how it was created-
Above – original week 9 setup- I had created a spiral shaped nurbs curve. The emitter sat at the top, a sphere was connected to the curve via a motion path and the particles were goaled to the sphere.
You can actually see from this screen shot above what the problem was – the ‘fuzzy tail’ was leading the action which is wrong- the tail should more like a trail.
I tried swapping the action, i.e with the emmiter traveling down the curve. I parented the emitter to the sphere. I also tried adding more sweeps to the curve and deforming the curve with a lattice deformer to get some ‘tornado’ feel. While the theory of this was better, it didn’t really work well enough-
Above – failed solution to tendril issue.

I decided that it would be more manageable if I went with more of a geometry driven solution. This is the method I came up with. I was worried that I was over-complicating things but it actually didn’t take that long to set up-

The basis of this new set-up is
– a sculpted cylinder geo coming to a point at the tip.
– a joint system.
– spline IK added.
-smooth bind.
– clusters for manual animation.
– fixed position sine deformer to with animated wavelength, frequency and offset.
-emit from geo surface.

Once I had the first one setup, it was easy to dupe it and change the setting so that the 2 tendrils work in tandem.
This is what the revised ‘2 tendril’ component looks like in isolation –


Now that I have discussed a bit about how the tractor was created and the changes I made for the final, here is a bit about the workflow I adopted that worked well for me.

Using separate scenes for different simulations seemed to slow me down and I felt unorganized generally with this original method. So decided to have a crack at doing it all in one scene and that felt better for me. This here is the list of steps I used as I took each particular simulation from testing through to rendering-

build everything required for the test, playback in the timeline to get a feel for whether its working using very low particle counts.
group everything involved with that particle sim i.e curves, joints, deformers, emitters, particles, fields etc into a group with a specific name.
– nest  this group into another group one up in the heirarchy called ‘tractor FX’
– as things start to look right, increase the particle count until the movement is perfect
– start playing with render attributes, shaders and render settings, doing single frame renders improving the render look – colour, opacity, size of particles, motion blur etc.
– when things are looking perfect – cache the particle to disk and render a frame range of about 30-40 interesting frames
open the sequence in nuke, add it to the stack with an over merge node and see how it fits in
– go back to maya, change anything that needs tweaking and render all the frames for which this particle is involved.
– back to nuke – update the read node to include all the frames
– if happy, then delete the particle disk cache files (I have limited hard disk space), turn off ‘is dynamic’ and hit delete cache.
hide that group in the outliner so that it no longer gets in the way
move on to the next simulation and start from the top

This way of working was very productive for me, I am a control freak and like to be able to know exactly what is going on.
For safety, I did a lot of intermediate saves. I ended up at save number 23-
This snap shows how I organized the outliner

I thought it worth talking a bit about my render attributes and render settings for all the final renders.
I never thought I would end up using hardware instead of mental ray because I am a pretty big fan of MR usually.
What I liked about hardware is that it seemed to have a real ‘particly’ feel. In the testing I did with MR, everything looked just a little bit ‘cloudy’. Good for some things maybe but I preffered the look that hardware gave me. When I referenced it back to what I liked about Legend of the Guardians, it was this ‘hard’ look that suited what I was after.
I did a lot of testing for the final look but when I got it right, it meant that I could use virtually the same setting for all the particle sims. It was always multi-point and in fact, you could argue that I could have used one particle node and linked it to all of the emitters? The reason I didn’t was that I found myself tweaking things like ‘multi radius’ slightly differently for each one.

This was the ballpark setup for all of the particles –
– MultiPoint
– Depth Sort and Col Accum both on
-Multi-count of around 2
– point size – 1 or 2
– ramp for opacity PP – very low max values in the array mapper to keep the opacity really low overall. Somewhere between 0.3 and 0.05! This was crucial to the look – high opacities DESTROYED what I was trying to acheive!
– colour ramp on colour PP – from a light blue at birth to just slightly darker blue at death – again, darker death values really killed the effect!
Render settings
– for the actual render settings, number of samples at either 1 or 9 depending on the detail required versus speed that I needed.
– no motion blur – I would like to experiment with this more in the future. I don’t know if I was using the settings properly but when I used any motion blur it just looked too soft? Using slightly lower ‘mix’ settings in nuke and subtle nuke glows seemed to better help the look I was going for.

Other (non-tractor) FX –

Heat Plume – 

I made some poly planes to emit blobbies for use with the iDistort node in Nuke. I had them in three separate banks – lower, middle and top because the doors do not all open at the same time. This way I could stagger the emission of heat plumes to match up the timing. I just animated the emission rates to begin as each door opened.

Rag Doll

To the rag doll animated using dynamics, I applied a series of dynamic constraints to the separate pieces of geometry. My methodology basically went like this –
– for joints where a 90 degree rotation was required, i.e -the knee, apply a directional hinge constraint.
– for joints requiring a 360 rotation i.e the neck, apply a pin constraint.
– move the constraints pivot to the point of rotation.
– the key to not getting interpenetration problems was to skip the in-between joints- for instance – creating a constraint from the upper leg to the lower leg, skipping the knee.
– this caused the obvious problem that the knee would be ‘left behind’ when fields where applied.
– I solved this by parenting the knee to the upper leg in the heirarchy. Before doing this, I would move the geometries pivot point to the pivot of the parent so that they would rotate around the same axis point.
– same method for the rest of the ‘interconnecting’ joints like the neck, waist shoulder elbow and wrist.
– then to get the rag doll moving up towards the ship, I applied uniform fields in negative Y.
– to make the movement more ‘dynamic’. I only applied these uniform fields to the hands. One at magnitude 500 and the other at 1500. That way, the rest of the body would be ‘dragged’ with the arms leading the action.
– To add some more interest, I applied a vortex field to the chect to get a slight bit of oscilation.
– for the render, I created 4 directional lights all of varying intensities and shades of blue to create the reflecting light from the tractor.
– I had to scale down the blue saturation in the comp as it was too strong but at least it gave me something to work with for ‘integration’ into the scene.
– Since the camera was static rather than moving, I did not bother with holdout masks for disappearing into the ship, I chose to just make a roto shape in nuke. This would save me from re-rendering if the client changed the ships position –

Ground Fog –

I promised myself that as a last step, if I had time – I would try to create a ground fog effect using particle sprites smoke. I wanted to do this for a few reasons-
– it would give me a ‘canvas’ to bounce some blue light effects off in nuke when the tractor beam comes into play.
– I thought that the foreground of the shot looked a little dark and led the eye away from the ‘hero’ tractor beam. Blending/lightening/smoothing this area with some fog might help the composition.
– The first 300 frames are pretty boring with not that much to look at – some moving fog would add some action to this part of the shot.
– some fog might help to ‘unite’ all the elements in the scene – if the fog moves faster as the ship approaches then it could help feel the drag/displacement of air from the UFO?

How I did it?
I created one single cloud texture by painting a single stroke on a paint FX canvas with a cloud brush, saved this as an iff file.
Emit sprites from a poly plane just below the visible crop in the scene.
A variety of runtime and creation expressions to randomize the size, twist, opacity etc as follows –

runtime ex 

smokeParticleShape.spriteScaleYPP = smokeParticleShape.spriteScaleXPP = smokeParticleShape.spriteRampScalePP * smokeParticleShape.spriteRandScalePP;

smokeParticleShape.spriteTwistPP += smokeParticleShape.spriteRandTwistPP;

smokeParticleShape.opacityPP = smokeParticleShape.spriteOpacityRampPP * smokeParticleShape.spriteOpacityRandPP;

Creation ex –

smokeParticleShape.spriteRandScalePP = rand(4,16);

smokeParticleShape.spriteRandTwistPP = rand (-1,1);

smokeParticleShape.spriteOpacityRandPP = rand(.1,.4);

Then I found a point in the sim where there was a good amount of fog and set initial state so that they would already be in the scene at frame 1.
The the plane stops emitting and the fog gets shifted around with turbulance/ unifom fields as the UFO arrives/ leaves.
Here is a couple of seconds of what it looks like on its own-

I had to mix this way down in the comp as it was a bit distracting but I think it works. It also had some artifacts from the sprite shapes so I had to roto some blur nodes in to fix this –

Final Comp result –

Reflection –

I had fun on this project. It had so many elements that at some points it felt a little overwhelming. It forced me to adhere to my own naming conventions, think about workflow, testing and getting one thing right before moving on to the next.
As far as the end result, I still don’t think the tendrils match the vision I had in my mind but I am pretty happy with them. As far as everything else, I am wrapped. I was able to make the changes asked for and to work to someone else’s instruction/vision which is a good indicator of how the progress has come along.
Things I would do differently if I did it again?
– I would have persisted with mental ray further and see how I could change the look of the particles.
– I would investigate motion blur settings a bit more and see if they could have improved the feel.
– I would experiment more with ‘particles emitting’ particles a bit more to closer match my reference material with regard to ‘trail’ effects.
– I would try other solutions to integrate the tendrils with the rag-doll. To combine a solution that actually wraps the particles around the arm for instance.

Programming Assessment 2 – MEL Report

Script Overview –

My script is based around character animation, in particular to solve an annoying repetition issue I encountered in animation class.
When creating a walk cycle, it is vital that the movements are absolutely symmetrical i.e – any transformations made on the left hand side controllers are mirrored across to the right hand side and vise-versa.
To further complicate this process, the mirrored tranformations need to be ‘offset’ in time by the right amount of frames in the timeline. If the walk cycle 12 frames per step, then the corresponding position of the other foot would be 12 frames along in the timeline –
These snapshots explain what I mean –


I want the animator to use his/her time creatively, only roughing-in the movement of the controls to get the feel for the walk right. Then they would run the script which will make the sides match – to 3 decimal places.
They can then rest assured that everything is perfect. If they make further artistic tweaks, all they need to do is run the script again!

Top-down development  – Version 1

Here is the first draft list of the development steps before I had started building the script –

1. User input – how many frames is the walk cycle? Stored this number in a float variable.

2. Assign all the left controls to a string array.

3. Assign all the right controls to a string array.

4. User to decide which side is to be the master.

5. Copy the animation curve for each of the controllers attributes on the master side.

6. Paste the animation curves to the slave side, offset by the frame amount determined at step one. Ensure that the curve completely replaces what was there.

The reality of writing this script was that many problems were encountered along the way. So the final step list was vastly different this initial one and hopefully shows my greater understanding.

Top-down development  – Version 2

Here is a summary of the final steps required to produce the final working script-
This may not be the exact order that things were done, but it is a more intellectual way of ordering the tasks and is how it best makes sense to me – it is the way I would think about building my next complex script –

1. Decide what input need to comes from the user and design a ‘front End’ to manage the user input data.
2. Break all of the required commands into groups of function or ‘procs’ that will be executed according to this user input.
3. Proc 1 – ‘update attributes ‘ – assigns the user defined controls to a character set, searches the names of the controls to break them into two lists – right side and left side. Then deletes the character set once it has done its job.
4. Proc 2 – ‘enable master’ – activates the appropriate list according to the user’s selection of left or right side as the master side.
5. Proc 3 – ‘Offset anim’ – this is the heart and soul, the guts of the script. It needs to perform the following actions –
a/ Populate the offset variable – tell the script what time-frame the cycle is, based on the user input information.
b/ Copy all the animation curves from the master side.
c/ Pastes all the curves to the corresponding side.
d/ Slides the curve in time according the the offset value.
e/ If the attribute was selected as requiring ‘inverse value scaling’ – inverse scale the curve across the value axis so that the correct mirroring symmetry occurs.

Reflection of script development-

I won’t pretend that I am going to be the next lead developer at ILM but I think that my aim to be a great generalist will strongly benefit from the MEL skills I have gained from this subject.
Being a master of your tools defines the difference between a highly skilled CG artist and someone who just gets by on artistic ability alone.
It also help your skills in problem solving, encouraging the breaking down of complex problems into a series of smaller, less daunting tasks (2005).

I have achieved several things from this class –

– I have a great animation script that I will actually use
– I have the foundations to go on and explore not only MEL but also Python which will be extra helpful given my ambitions of learning NUKE to a high level.
– probably most important of all, it has removed the fear factor. As David Gould (2003)says in Complete maya programming (2003) – “For many, the mere mention of programming provokes fear and trepidation.”
This was definitely me, I used to avoid any tutorials/experiments that involved any degree of scripting- especially when it comes to rigging.
I now feel that I can go on and explore other peoples scripts, use them for my own workflows and learn from them.


Gould, D 2003, Complete Maya Programming, Morgan Kaufmann Publishers, San Francisco, CA

M Wilkins, C Kazmier 2005, MEL scripting for Maya Animators, Morgan Kaufmann Publishers, San Francisco, CA

Dynamics Week 9 -Process Diary


Quick Reference of do’s and don’ts – I like to summarize a written brief into my own shorthand. I know I will refer to it a million times so even if it saves a couple of minutes per read, it is worth it. Here is my ‘point form’ edit of the written brief –

UFO swoops into frame from behind the building
– Hovers above the grassed area
Tractor Beam lifts the Mannequin up off the ground into cargo bay.
Doors close- fly away
– may require the insertion of Leaves
– use other effects such as Heat Plume for realism
– Camera and animation approved – don’t change it!

Familiar enough to be recognized as a tractor.
Fresh concepts to build on this
Spirals – convey a sense of motion that is simply not a vertical one. Movement within movement, complexity of motion.
Variance -Variance in thickness of the main part of the beam. Not constant cone. I like the idea of a thicker outer/inner cone, but I will reserve judgment until I see it.
Grid  – Another concept that intrigues me is that of a grid that focuses its attention on the object that it is picking up.
Colour – Cool palette. Blues and greens are familiar, so that is the place to start. We may need to alter the colours as we go, depending on how the shot develops.


Now I have a quick reference, next is my more detailed notes from the verbal brief by the client (Chris) and how they relate to some of the reference imagery supplied –

ufo light
– its colour palatte,
– the ‘shards’ of light
– its volumetric nature
Dislikes –
– too light-foggy , wants more particle-look

– the ‘shadowing’
– the object is being pulled up
– the feeling of being lifted towards the light

Likes – the feeling of a ‘tendril’ like grip, (in fact ‘tendril’ is probably the most used word in the whole brief)

beam_525Likes – again, the tendril effect. This single tendril is good, but we would obviously need more of them. He seems to ‘kind of like’ the spirallish texture too – explore!

Screen shot_sm

Likes –
the disturbance/breakup on the streams.
Dislikes – the colour -too warm over to the left of shot.


Likes – the feeling that the tendrils are clinging on to the shoulders. The tendril motion should ‘undulate’ as it picks up the object.


Likes – this kind of motion trail effect. Kind of mix between ‘tendrils’ and ‘hairs’.


Likes – 
the wispy-ness of the tendrils


Likes – the particle-like tendrils and the light shaft


Likes – tendrils very close together- almost like hair


Likes – the spirals, but too geometrical. Would need to be more organic.

Other random notes from the brief
– Tendrils lift hands first, then the rest of the body follows. – tractor may have a ‘hot core of light’
– localized areas might be slightly warmer, then others more towards turquise
– likes the idea of spirals, but not mechanical or too geometrical – always more towards organic.
– this effect should not feel ‘whimsical’ it should always lean towards ‘manacing’.

Early thoughts –

I have some early thoughts about creation of the tractor beam. I am thinking that the particles should be built up in layers i.e – for each effect, I will use a separate particle node. This makes it easier to manipulate parts of the effect individually ‘locking things down’ when they look right and making it so that new fields introduced wont mess up parts that I am happy with. It will also make it more manageable to do any changes that come in after week 9.

Some early brainstorming notes about how to achieve the sorts of things that the client wants – don’t forget that spline curves can emit particles. Some twisty vertical curves might be useful to act as the tendrils.
Another idea is to use 2 torus’s top and bottom of the beam bouncing particles between each other, and using ‘blended weight’ goals to disturb the balance.
Texture emitters might also be helpful for emitting in clumping noisy patterns.


My own additional reference material

Too many tractor beams look the same and the shots Chris has supplied are hard to beat. One thing that sticks in my mind from the brief is to make it ‘particly’ – not like light beam effects. So many films that use particle effects seem to using rendering methods that hide the particles and end up looking more like light and smoke.

One film that comes to mind that shows particles in all their glory is ‘Rise of the Guardians’.

I begin to watch this movie very carefully to study just how they use particles with such magical effect.
I remember the extent to which particles are used in this film, even the point where the characters use particles as weapons! Here are some still I captured in my studies –

The opening sequence has Jack Frost interacting with ice and snow. I love the spirally patterns that are formed.
The client (Chris) wants to see the particles rather than just light fog. While this shot could have been done using just light effects, they back it up by using visible particle trails.


Most memorable of all the FX in ‘Guardians’ are the 3D sculptural elements formed from particle trails by the ‘Sandman’ character- like this one above.


I referenced this ‘ice crystals’ image above as an influence for traditional ‘light fog’ FX combined with particle ‘tendrils’.

jackFrost_crystalAlso the combination of effects and colours to acheive this silhouette of Jack.


Aside from the golden colour here, I like the way the tendrils interweave with the characters. This might be handy as reference when it comes to stage 2 and lifting the manaquin?

Now for the hero shots– in what would have to be a dream for any VFX artist, the good guys face off against the bad guys in what what could only be describes as a ‘Particle War!’

particleWar04Colours are used well – golden for the good particles and shades of blue to black for the bad particles!

particleWar01Menacing dark tendrils emitting purple glow sparks!

particleWar02Golden whip with glow spirals attached

particleWar05I like this reference for the motion blurred trails near the top

particleWar06Lightening like particle rods interact with puffy trails!toothFairy

The tooth fairy’s concoction. Too whimsical as far as the rainbow of colors but nice movement and shape.

More reference –

Heard on the grapevine that there was a new film to incorporate tractor beam effects so I tracked it down – the film is an offbeat comedy called ‘This is the end’.
Pretty uninspiring and mostly the typical light beam type effects but still some good reference for how the people are lifted up, especially their posture – heads tilted back and back arched- here are some screen shots –


Initial testing –

I started to play with various techniques with two specific things in mind-
– how do I make the particles move the way I want to
– how do I render the particles to look the way I way I want.
Lets just say over the course of a couple of days I ended up with about 30 different rendered image sequences. I put together a compilation video of a few of the initial results which will show the path my mind was following –


Refined results for week 9 submission

After much more testing I have arrived at point where I have 3 different particle renders that can be comped together for my first submission. They consist of –

‘core beam’ particles to form the outer shell of the beam. Made using a cylinder with ramp textures mapped to the surface. Then  the ramp points were animated and particles created using emit from texture.

‘fractal circles’ – to break up the main beam and create some more organic fractal patterns travelling up and down the beam.

a single tendril made by goaling particles to a sphere that has an attached motion path to a spiral curve.

Here is a video that shows each particle set on its own and the final with all 3 particle effects comped together


Reflection so far

I am happy with the initial look but want to get the clients opinion so far. I obviously need more tendrils and to refine the rendering style of the existing ones. I need to further explore some shading techniques and would like to incorporate some ‘cloudier’ materials.

Week 6 – Footprints using soft bodies


This week in dynamics we looked at soft bodies. The homework task is to use soft bodies to deform a ground plane, leaving different types of footprints in different surfaces i.e – rock, sand and mud.
Here are the steps I used along the way

– firstly, duplicate special on the figures geometry, keeping the input graph so that the animation is retained.
– I then isolated the faces for the feet, shift-dragged across all the faces to invert the selection, then delete so only the geo for the shoes remained.
– I ramped up the subdivisions on the ground plane to 50/150 (then I experimented with higher counts but I will talk about that later.)
– then select the ground plane and make it a soft body. I used the options to ‘make original soft‘ I prefer this option as it creates a less complicated name on the soft body you will be working with – the non-deformed plane is really just a spare and a potential goal target- I set it as weighted but kept the goal weight at 0 for now.
– now I make sure I am at frame 1 and add springs to the particle, selecting the wireframe creation method with wire length of 2.
– now I select the springs in the outliner and hide it as it can slow the display (the springs are still calculated),
– so that I don’t have to look at the particles (it is more the geo that is important in this kind of sim) I add a per object opacity and set it to 0.
– now I select the particle, then the feet geo and make a collision. The footprints are created as a result of this collision.
– I set the conserve to zero so that the forces are only applied as the geo collides with the particles – the energy then dissapates.

– This completes the draft version of the sim and there are many problems to fix.

Problems and resolutions –
The most obvious problem is that vertices from the ground plane are sticking to the feet in a pretty big way!
I start to experiment with settings to resolve this. It mostly comes down to the settings for the spring
For me, it became a battle between having the stiffness and damping settings high enough to break the ‘stickyness’ but not so high that the simulation explodes geo into your face!
I found that settings of 50 for stiffness and .7 for damping to be about as far as I could push things.
I also tried to increase the ‘oversampling‘ from 1 to 4 but this did not help and really slowed the playback rate. Reducing back to 2 did not help much either – it just seemed to make the spring settings more sensitive.
Nothing I tried would seem to resolve the fact that single vertices were ‘popping’ to follow the feet geo, so I decided to go back to scratch and make the ground plane geo more dense.
I changed the subdivisions from 50/150 up to 150/450 – then it seemed to die while adding the springs – the wheel spun longer than it took to make a cup of tea so I escaped out and retried it with divisions of 100/300.
Now (eventually) the springs calculated and I pressed on with steps from before…….
only to discover that it made NO DIFFERENCE (feel my caps lock rage!)
I reverted back to an attribute that seemed to help in a similar project we did in class – setting the ‘offset’ on the geoConnector up to 1. This again seemed to help but the biggest problem with this fix is that I don’t really know why?
Anyway, with the sim working reasonably (still not quite happy), I moved on to trying to replicate the 3 different surface materials.
The idea is to introduce some goal behavior back to the un-deformed flat plane duplicate.
I know that goalPP is a multiplier for the actual ‘per object’ goal weight so the first step is to set the goal weight to 1 – otherwise the PP would do exactly nothing.
Then in the top ortho view, I select the particles in the rock area, go to the component editor and set the goal weights to 1. This means there should be no footprint effect as it is goaled 100% to the non deformed plane.
I shift-drag select the particles to invert the selection, give those a goal weight of .1 – this is my target for the sand area as sand footprints tend to last a very long time (depending on the moisture content and fineness of the sand).
Then I select just the mud region and give those a value of .4 as I want those to pop back to non-def shape relatively quickly.
Results – my weight values actually worked really well first go– the sand and mud act exactly as I had hoped (aside from a few popping verts which I still cant seem to find a fix for) with the sand hardly springing back at all and the mud springing back to shape at just the right speed.
The only real problem I have is the rock section. Even though I have goaled them at 1 and there should be no effect, I can still see a hint of a footprint being created.
After spending way too long trying to find a legitimate fix for this, I decide to use the teachers analogy of ‘what happens if it is 11pm and it needs to be rendered for the morning?’-
-my ‘dodgy’ fix is to animate the translate Y on the locator that controls the character so he lifts ever so slightly up for the duration of the rock section then eases down for the start of the sand. I know…..
Anyway, here is the end result –

Week 4/5 – Dynamics using goals


We have been looking at the various uses for the ‘goal’ attributes in particle dynamics. The first in class example was to goal a particle to a sphere and using goal weights of less than 1 to create an ‘insect swarm’ like behavior-
We then experimented by using expressions to quickly and efficiently animate the sphere using mathematical algorhythms such as “pSphere1.translateX = sin (time)*5;”

The second example was to get a bunch of particle intanced cars to animate along a deformed ground plane
The cars were goaled to the ground plane and we used various expressions to control their behavior, eventually sending them off the edge into the abyss.
This gave me some clues when it came to the homework brief – to create a particle waterfall. After much experimenting, these are the steps I used to produce the end result –

make the waterSurface geo a surface emitter (it has already been animated using a wave deformer)

goal the resulting ‘waterParticle’ to the geometry with a value of 1 to make the particles stick. They now bob up and down with the deformed surface.

– the next step was to make the particles move forward in the U direction. I added the dynamic attributes for Goal U, Goal V, Parent U and Parent V,  then wrote the following creation expressions on the particle –

waterParticleShape.goalU = waterParticleShape.parentU;

waterParticleShape.goalV = waterParticleShape.parentV;

It was important at this stage to check the ‘need Parent UV’ tab on the emitter.

–  so the particles are now flowing forward and collecting at the end of the geo.
I wrote the following runtime before dynamics expression to ‘un-goal’ the particles as they approached the end of the geo, allowing them to be ‘released’ over the edge –

if (waterParticleShape.goalU > 0.99)


waterParticleShape.goalPP =0;


– at this point I added a gravity field to the particles that would carry them down in the Y direction.

This almost completed the simulation, I noticed that the water was falling in ‘strips’ because of the assignment to the UVs – I wanted to tweak the randomness of the U direction so
– I created a new custom attribute called randSpeed and assigned it some rand values –
waterParticle.randSpeed = rand (0.008,.015);
– then added this random value to the U goal using the expression –
waterParticleShape.goalU = waterParticleShape.goalU + waterParticle.randSpeed;

Now when the water falls, the height is more broken and natural.

– I used a similar method to create some slight ‘zigzag’ across the surface in the V direction using this –
waterParticleShape.goalV = waterParticleShape.goalV + rand (-.2,.2)*.003;
The output value for this needed to be very low – hence the *.003 at the end.

– Lastly, regarding the flow, I only wanted the water particles to be generated in the first half of the geo surface. Another simple creation expression accomplished this-

if (waterParticleShape.goalU > 0.5)


waterParticleShape.lifespanPP = 0;




waterParticleShape.lifespanPP =4;


Now the water is only being generated in the first half of the U grid. It also served the second purpose of giving the particles a lifespan of 4 seconds which was about the right amount of time to die level with the end of the ‘rock wall’. (Remember to set the lifespan mode to ‘lifespanPP only.)

With the movement of the water now just right, the final step was to assign the ‘look’ of the water.

– I set the render attributes to ‘streak’ and adjusted the tail size and fade.
– I assigned a black and white ramp to the per particle opacity to kill them a bit more gradually.
– I assigned an RGB ramp to the colour per particle to begin their life as a rich blue and finish with a lighter blue to mimic the look of whiter, more transparent colour as it is falling.
Here is a playblast of the final –

Week 3 – Particle Instancing

This weeks dynamics homework exercise
revolves around particle instancing. Building on the ‘rock explosion’ knowledge we gained in class, the direction was to take a supplied model of a bi-plane and build a shot to a very specific brief using particle instances.

The key requests in the brief are as follows –

– Create a squadron of planes flying through the air.
– Exactly 72 planes.
– moving towards the camera (supplied) over the course of 100 frames.
– Each to have a unique motion.

Firstly, I knew that for the instances to be facing the correct direction in the final simulation, that the ‘hero’ geometry must be facing in the positive X direction. So I rotated the plane to face positive X and froze the transforms. One complication of this is that I needed to re-do the propeller rotation as it was now rotating in X, not Z.
With the grouped instance ready to go, I created a cube volume particle emitter, then set up the bi-Plane group to be the instanced object in the instancer window.

Hitting the play button now creates plane instances mimicking the movement of the particles. Obviously many changes had to be tweaked in the settings

Emitter settings –
Key things to note for emitter settings-
– a rate of 100 i.e – not emitting too quickly so that they have a nice seperation between then, not too bunched.
Zero for ‘away from center’, we will use fields to control the action.
1 in the ‘along axis’ setting (which is like a speed control for volume emitters) – I was not too fussed by this as further speed control would by added with a uniform field.

Particle shape node attributesparticleShapeAtt

key things to note here –
max count to 72 to cap the number of instances
live forever, we don’t want planes disappearing
aim direction set to velocity so that the planes tilt in the direction of the momentum

For the additional motion, I created a uniform field to drive the planes forward and control the speed. I set the magnitude to 5 in the direction of X.

For the random bumpiness, I created a turbulence field. I set the magnitude to 20 and the frequency to 15 which created about the right kind of subtle movement.

Finishing touches-
I unlocked the render cam and tweaked the angle so that a plane would come really close to the camera right at the end of the sequence (whoops, not sure if we were supposed to do that?)
I mapped the image plane to a cylinder and positioned it where it cover the field of view from the render cam.
I assigned a simple blinn material to the original plane. I wanted to get carried away and set up a shading network but then I realized that the plane did not have correct UV’s so I decided against it.
Then I rendered with mental ray, my choice really came down to wanting to experiment with the motion blur settings. I had alot of problems with render settings as it was the first time I have used 2014 for rendering and did not quite have my head around the new unified sampling settings.
I rendered one sequence with motion blur and one without to see the difference. In the end I comped the two sequences together in nuke with a merge over node. This was a comp cheat to reduce the amount of ‘chattering’ from the motion blur – here is the final result

Week 2 – Rain using dynamics

This week we went through the process and methods of creating rain using particle dynamics – in particular to compare world scale and 1/10th scale and the effect this has on settings and final look.

I will list the steps for the rain creation at the bottom of this post but firstly here is the play blast to show the original simulation at real world scale on the left and the 1/10th scale version on the right –

I managed to get them looking the same (so far as I could detect) but these are the things I found that required different values at the small scale –
• Initially, I found that the lifespan for the particles could be significantly less as the distance falling is reduced. (I will come back to this)

• The magnitude of gravity will need a lower setting to get the same result. With the magnitude at the 980 as per the 1:1, the rain speed was quite violent. Reducing this to 98 seemed to feel about right. But, now with the lower gravity magnitude, I found that I needed to increase the lifespan so the rain would make it all the way down to the ground plane.

• The tail size on the streaks needs a lower setting.

• I seemed to need a greater resiliance setting on the geoConnector for the ground plane to stop the particles falling through it?

These were the main differences I noted.
Now, here is a summary of the steps required for this simulation –

Create particles using a plane as a surface emitter. Set the speed to zero so they stick  -then you can use a gravity field to control the fall.
Create a gravity field,  make sure the particles and the gravity field are have a dynamic relationship. Experiment with the magnitude for fall speed. Attenuation should generally be set to zero as gravity does not have a ‘falloff’ as such.
Change the lifespan of the particles to constant, then adjust the life until they fall just past the ground plane that they will eventually collide with.
Set the render type to streak to get a look closer to real rain, then adjust the tail fade and tail size to suit.
• To randomize the fall pattern, we use a noise node mapped to the texture rate the animate this noise texture using the expression noise1.time = time*10;
• Then we create a collision between the rain particles and the ground plane and adjust the resiliance and friction attributes on the geoConnector to get the interaction right.
• To get a secondary splash, we use the particle collision event editor, which emits new particles on collision –

then we add another event which kills particles –

To get to all the ‘frequently used’ controls more effectively, we build a rain controller using a simple locator, adding custom attributes for rate, gravity, turbulance, and the 3 scale axis for the emitting plane.
The connection editor was used to connect these custom attributes to applicable nodes on the emitter, gravity field and plane geometry.

Now we have quick and easy access to the most used controls.