Archive for vfx
Since LK Fabric is out I dug up one of the early test scenes we used on Nike “Evolution” at Royale in which we developed some of the techniques we used to get various looks. This setup is very basic but covers some of the key tricks for getting a natural result and was used as a starting point for a number of shots.
I have replaced the original many-versions-old compounds with ones from Leonard’s public release, and have also left in a few “helper” compounds I built which weren’t part of his official release. I then removed everything superfulous to the basic effect and commented the resulting ICE tree throughout. Any typos or misspellings are entirely my fault. :D
The actual setup is very simple.
This scene demonstrates:
- A basic setup of a single evolving swatch of fabric, with the most basic pattern and the modifiers we used most often.
- Using the “slide profile over U/V” compound and other techniques to shape the leading edge of fabric growth.
- Using the “offset” core parameter to make the leading strands animate and form a shape for the thread tips.
- Using a second ICE “post” effect to add per-strand variance and “frizz” effects.
The early tests like this were pretty chaotic, we knew the system did a good job of creating a “perfect” weave so we were pushing in the other direction and adding ways to create chaos and randomness.
Ironically despite the first briefs being focused on “organic” and “evolving” concepts the client spent much of the latter half of the job dialing in a more out-of-box mechanical look… that’s the way it goes sometimes. But this means there is a lot of capability which hasn’t been seen yet. I’d love to see some people use some of the per-strand and per-thread modifiers, and the capability to create patterns beyond the basic “canvas,” to create a more organic, aggressive look.
Here’s the file (Softimage 2013 scene file, ~0.6mb): LKFabric_AMexample1
Softimage, Arnold, ICE and LKfabric, intensive small-team project @ Studio Royale, I think this video is meant to play in the Nike stores inside of a sculpture/model of the loom. If anyone sees it in one of the store sculptures, send me a pic, it sounds cool. :)
Two of 3 spots. “Evolution” was a small team, 3 weeks, lighting and effects with Softimage and Arnold.
I love small but intense projects like this.
“Run” was primarily Maya/Vray with a touch of ICE. The studio (Royale) is only 6 years old but advancing fast, and it’s been a real pleasure working with them. For their first exploration of ICE, Royale invited in some familiar SI friends – Ciaran Moloney, Steven Caron, Leonard Kotch, Billy Morrison and yours truly doing a first gig start to finish as a CG sup (which with guys like this mostly involved saying “go for it.”)
Like the Psyop “Telstra” spot, this commercial essentially required us to create a system for knitting cloth from massive numbers of strands. Leonard Kotch wrote a system which performs many of the same tasks as the Psyop “Entwiner” tool, but he took a slightly different direction, it was fascinating to compare how the two diverged. The progressive animation required for these two shots resulted in a pretty flexible and broad system, which we are currently using for the last of the three spots, which will wrap in production soon.
Royale has been an enthusiastic and fun group to work with and it’s been great getting to show a studio as strong as they are in design some of the possibilities ICE can bring to jobs like this. Expect to see some version of Leonard’s “LKFabric” system gifted to the community before long – very cool Royale, thanks! (They also throw good parties, their 6′th birthday celebration was impressive and… unusual.)
There are a billion discussions of the Fibonacci sequence, phi, the golden section etc. So I’m going to let you browse the wonderful web and largely find out about it for yourself (try here), with only this brief summary…
The Fibonacci sequence is a series of numbers such that the last two numbers of the sequence added together result in the next: 0,1,1,2,3,5,8,13… ie: Fn = Fn-1 + Fn-2.
If you take the ratio between any two consecutive numbers in the fibonacci sequence, they increasingly converge towards a single value, 1.61538 (memorize it!) which is called the “Golden Number” or Phi: Φ
This ratio is found throughout nature, as well as classical art, mathematics etc. It crops up in an amazing number of places. A logarithmic spiral in which points of the spiral are Φ units apart after a quarter turn is called a “golden spiral”, for instance, and can be found in seashells, seed pods, flowers, pinecones and as I said before, lots and lots of websites. If you’ve had a certain amount of coffee, this video might be illuminating:
Other artists using ICE have put out tutorials and compounds relating to these spirals, browse around (hint I’m one of them.)
Recently as I fiddled around I came across an interesting point about these kinds of distributions that caught my attention: they are a very efficient way to pack particles evenly on a surface. This is an important point to an effects artist, because not only is a large part of this job mimicking nature, but distributing points efficiently on surfaces lets us maximize the number of non-overlapping particles we emit.
So, I built some compounds, first to calculate phi (or simply return it as a stored constant, depending on the accuracy needed.) Another to convert phi into angles in degrees and radians (the “golden angle”), and finally I took these and made an emitter. Hooray, it indeed did allow me to emit a sphere of particles packed efficiently, and even better since I didn’t have to use a “generate sample set” it allows millions of particles to be emitted much faster than simply emitting particles from spherical geometry, and without any resolution-dependance on the LOD of a polygonal sphere. And this “phi” distribution has a nice, natural look.
Here are the compounds, enjoy: ICE_phiDistribution
I am a big fan of Polynoid. Ever since their first images of cybernetic snails came out I’ve been hooked on their often-dark blend of art-meets-tech imagery.
Fabian Pross of Polynoid was, for a while, maintaining a very cool blog (come on Fabian, post new stuff!) One post in particular puts into words a critical concept I and many others often try to get across to newer artists – the importance of avoiding simulation where possible.
Simulations usually don’t quite achieve what you want them to, visually. The trap people fall into is to try to force a behavior out of a simulation. You end up making endless iterations while the setup you’re using grows more and more bloated and slow. A single directoral change becomes a nightmare. You lose control and the limitations of your setup starts to dictate the look.
The solution is to create what I think of as “deterministic” solutions – setups which change over time, but in very strict ways you specify. That’s one of the things I was trying to get at with the “post simulation” tutorials, the benefit of offloading much of the look outside of what is simulated.
Even skilled vfx artists fall into this trap with some regularity. I can’t say how many times I’ve seen production scenes which have grown bloated to the point of containing hundreds of forces and collision objects just to try to achieve a simple effect. You can’t afford it. A simple directoral change blows the whole thing apart. Stop. Take a deep breath. Don’t go over that cliff. Simulate judiciously, in small doses, only where you have to.
Simple simulation + deterministic stuff for a complex look = control.
And control is what makes a VFX artist, in my mind. Anyone can pull levers until they get a nice result out of fumeFX. But to achieve brilliant results which are new or spot-on to what is needed in prodution, you have to have control – be it in fumeFX, ICE, Realflow, Houdini or whatever. And one of the best ways to achieve control is to only simulate where you have to, and keep it simple when you do.
Fabian puts this idea into words better in this post. Even if the techniques he uses here are specific to ICE, the underlying message and workflow is the same everywhere – avoid simulation to gain control and speed.
Even when you use simulation, who says that you have to stop there? Bake it and use it as an element you shape further or build on. This concept is really powerful. A good example of this idea in practice is demonstrated by a little DCC-agnostic tool called Sparta. Simulate, then shape the results.
To make a point that the underlying concepts introduced in this simple tutorial are far more important than the simple look of our example, here are some images which derive from the simple parametric circle equation discussed. The scene used to make the anaglyph is below. This isn’t rocket science stuff, this is novice level ICE… and much of it applies to realflow, thinking particles, maya or whatever. Cheers – AM
And here’s the scene used to make the anaglyph version, with comments throughout (softimage 2013 ed, ~200kb) spirographEmission_anaglyph
So, we’ve made a strand circle which rings our original point positions from the simulation, now let’s make those circles align with the rotation of the simulated particle. In practice this is very, very simple. Just insert a “rotate vector” node after you calculate the coordinates on a circle for the strand points, and then use the particle orientation as the input rotation.
Ok, that was nice, but why did it work?
Point positions are vectors. Vectors are displacements:
This is one of the simple but critical concepts that is the real purpose for me writing this series of posts, because it’s a foundational way of thinking which lets you come up with solutions to problems every day.
What is a point? It’s a place, within a space. A particle can have all kinds of attributes, like color size and orientation. But a point is just a position, it only has a single value, a vector (x,y,z). In a manner of thinking, a point is a vector. The vector which describes a point is a direction and distance from the origin. It’s a displacement from that point of reference. When you talk about “global” and “local” space you are talking about different frames of reference, different points of origin from which to draw a vector describing points.
So, what we really did when we calculated an array of strand positions on a circle was make an array of vectors. Hence, rotating those vectors is really the same thing as rotating the strand point positions to match the orientation of our original particle. Points are vectors, they are offsets (or displacements) from an origin. And ICE is very, very good at doing stuff with
points vectors. You can call these manipulations vector math if you want, but that in itself doesn’t make it beyond your average artist, who like ICE are also very, very good at manipulating points. If you are an artist you already have an intuitive grasp of vectors! You just need to define some terms, so that saying stuff like “rotate a vector” translates to the visual adjustments you do in your head day in and day out.
Seeing stars… and why modulo is so handy:
Ok, cool. We have a bunch of strand rings centered and oriented where our simulated particles were. Let’s make the rings star shapes, as a way of talking about another useful technique in ICE (it’s useful all over in fact), making patterns via the modulo function.
Ok, a digression first – some housekeeping. By now you’ve realized this isn’t one of those step-by-step makes-a-scene tutorial, I’m discussing more and glossing over a lot of the details you may need to actually plug all this together. I really should have provided a sample scene earlier, I don’t want you focusing on plugging nodes together, the whole point of this is the underlying ideas. So here you go. A sample scene with nifty comments and stuff. If all you want is a scene that will make circles and stars, there you go. And it was made with an educational license, even. But if you want the ideas used so you can make all kinds of other stuff, well then dear reader, read on.
The modulo function is just an instruction to divide two numbers and pick out the decimal remainder of that division. If you feed a linear sequence of numbers (like the index of an array: 0,1,2,3… call any of these numbers “n”) into the modulo function, you get a value counting up between 0 and 1. You can use this to identify every “n’th” item in your list. In fact if you crack open ICE’s “every n’th particle compound etc you will basically see exactly this.) If you can do things every “n’th” time, you can make patterns. Think about it. Braiding hair, knitting, drawing a dotted line – making almost any pattern involves counting and every “n’th” count doing something differently. Modulo is how you do that kind of thing in ICE (and elsewhere. Hey, realflow has an ICE like system now. And it works in scripting too. This math stuff pops up everywhere. The big secret is this – it’s just a way of looking at things you probably already do really well.
I’m a visual thinker so when I was first learning about modulo I had to scribble on a napkin, with results something like this:
All a star shape is, is a pattern where we take every other point on our circle and change it’s radius. Now we know how to find every other point from our list (the array) of strand positions, so we just change the radius of the formula we used to make the circle for those points. And you get a star.
Ok, so just one last part to this tutorial, and a brief one – how to take the single circles we made and, using the earth-shaking power of ICE and the post-simulation region, turn that result into a lot of circles: all different and making little atom things like we see in the example video. And in fact, the example scene here already shows you how, so we’re not even going to do much besides discuss it and crack bad jokes. Cheers. – AM
The file (softimage 2013 educational, 1.2 mb)
Ok, so we’ve talked about the post-sim region, and showed an example. Just what did I do in there?
Strands are one of my favorite features of softimage ICE. They are really cool. While it’s beyond the scope of this tutorial to get into everything there is to making strands, here is some foundation… Strands are essentially a bunch of per-point attributes telling ICE how to draw the resulting strands. These attributes contain information about color, orientation, number of points in the strand and so on. In our example, the most important of these to us is the strandPosition array. It is an array, one per each particle, in which each strand points position is stored. This is what we’re going to manipulate. Make a simple particle simulation in ICE, and then add a post-sim tree. We’re going to work in there…
Create a strand for each particle:
There is a compound in ICE called “create strands,” which we’ll use here. I’m not a big fan of this compound, it gets the job done but if you get into ICE strands much I advise building your own. At a minimum, I suggest opening up the “create strands” compound and looking around, and then make a single, simple change. See the compound in there called “calc strand ratios?” Plug it into a new port of the big “set data” node in there, and name it “self.strandRatio.” This is an array which assigns each strand point a value ranging from 0 to 1 along the length of the strand. Think of it as a replacement for a “u” value of a curve, it gives you an idea where on the resulting curve a point is. Take your resulting modified “create strands” compound, plug it in, and set the number of strand segments to 20 or more. (Note: depending on the size of your display you may need to click on images to see them without cropping.)
There are a lot of ways to describe circles mathematically, but for our purposes we are interested in getting cartesian coordinates (x and y values for each point on the circle). Without getting into the math suffice it to say a parametic form of the equation for a circle you were exposed to in school (x² * y² = r²) is as follows:
x= a + r cost
y = b + r sint
Where (a,b) is a center point, r is the circle radius and t is an angle ranging from 0 to 2Π (or 360 degrees).
Remember that “strand ratio” value? It ranges from 0 to 1 on the length of the strand… meaning if you multiply that by 360, you get the angle (t) for each point on the strand. So, to draw a circle with ICE strands on the x/z axis (like a hula hoop) you get this:
And the result (on a single point) looks like this:
Add this to the particle point position and you get this:
Note that I took the entire “calc strand ratios” compound (from inside “create strands”) and used it here, rather than getting the strand ratio directly where we saved it earlier. You can do it either way, and it’s slightly slower this way where the strand ratios are calculated over and over per frame rather than just being looked up from where we saved it…. but it saved some room in these screen shots. ;)
Now all we have to do is move the actual particle at the center to close the circle. Since we’re in a post-sim tree, moving the particle around doesn’t invalidate our original simulation, it just makes the change for rendering – as far as the “simulation” ice operator is concerned the particle hasn’t moved. So, let’s make the point position the same as the last point on the strand. To get that last point, we can “pop” it from the strandPosition array. Pop just takes the last member of an array, so it’s a handy way to get the value we want in this case. So we get the strandPosition array, pop the last value, and use that as our new point position.
Pretty simple, isn’t it? In the next post, we will adjust the circle to match the particle’s orientation, and then we’ll use this whole setup to create a series of concentric rings around each simulated point. Cheers – AM
Plus… seeing stars…
“What happens in the post simulation tree stays in the post simulation tree”
A quick review: ICE operators are evaluated differently depending on where they reside in the construction history (also known as the operator stack or modifier stack.) When an ICE tree is under the modeling region it is evaluated every frame unless a simulation region exists – if it does, it is evaluated once. An ice operator under simulation is evaluated every frame, and all data is updated every frame. In other words, changes persist and appear in the next frame – if you move a point, in the next frame that change is reflected. And when an ice operator is in a post-simulation region, it is evaluated every frame but changes are discarded. The “lower” regions evaluated first, then each region “above” it in the explorer, like so:
This is very, very useful. You can have an entire simulation going in the simulation region, and then do stuff to it prior to display. For instance, you could cull out all particles which aren’t visible to the camera to reduce cache size and speed evaluation. You can calculate per-particle lighting prior to rendering it, to control lighting entirely within ICE. Or, in the example below, you can move points around without altering the original simulation.
Example: Strand shapes
Here’s an interesting “look” done entirely with strands in ICE. A typical particle simulation has been used as input for an ICE operator in a post-simulation region, which uses the simulation as a basis to draw many circular strands.
First, I made a very basic particle simulation:
Then, in a post-simulation tree, I drew the strands.
… So you can see that for this effect the bulk of the work was done in the post-sim ICE tree. I use the point positions and orientation from the simulation as a center point around which I add new particles with strands. In my next post I’ll show exactly what I did, but the point I’m getting at here is that things don’t have to end with merely a simulation. You can get into some very cool stuff by considering each frame of a simulation (or a cached result) as a starting point. You can deform your entire simulation, rig it to a character, light it, or perform housekeeping tasks like camera frustrum culling. You can even treat the entire simulation as a single unit and scatter it – they sky’s the limit.
A quick note about motion blur:
When I wax rhapsodic about the post simulation tree the most frequent argument I run into is that moving particles around in a post-simulation operator invalidates motion blur calculations. This is true. Motion blur is based on the velocity of a particle, which can be considered a vector from the previous point position to the current. In the post simulation operators, the previous location is unavailable… it’s like a dog’s sense of time, only what exists “now” has any meaning. So, you have to do some extra work if you need motion blur. Basically, you store the previous point position into a user variable which can be read by your post simulation ICE tree and use that information to calculate not only how you wish to move a particle, but how you moved it in the prior frame as well. From this you can calculate a valid velocity to pass to the renderer for motion blurring. That sounds awful, but it’s not really that bad. (Still, it would be handy if the devs gave us an easier workflow than this, for instance could they store and give us access to post-sim point positions and velocity or something?)
We will look at creating the offset strand shapes – circles, stars etc. Stay tuned!