Small, frustrating accomplishments

This week was kind of frustrating for thesis, as it seems like I wasn't able to get anything done. Not that I'm complaining too much, because it was my birthday on the 26th. My parents came to town and we watched Spamalot (in crappy balcony seats). The show was okay, not sure if I would have preferred going to MetroCAF instead.

Anyway, there are some updates I am happy to report. One of the first things I did was model this lamp for the scene.



It's a park light, so it makes more sense within the context of the scene. It looks good, but I may redo it and put all those tiny little ridges in a bump map instead. I looked at a similar park light in the Tudor City garden and the ridges are not that deep, and from a distance not that noticeable. The ridges in my current model are geometry, which will add to render times, and worse, could flicker when in motion without high sampling. Bah, I hate modeling. More on that later.

A little more fun, though not by much, was this stupid box rig. It's like my old box, except this one has four animatedable flaps instead of just one, and the flaps have a thickness to them.



Of course, adding thickness means adding more than two points, which means I had to paint weights. And of course I painted weights for the whole thing before realizing one of the joints was incorrectly placed, and I didn't want to go through the trouble of saving a weight map, so I did the whole thing from scratch twice. I've gotten pretty efficient at rigging boxes, now. I also fixed the UV's with Omri's texture reference from scratch method. UV projection maps swim, which I guess makes sense with construction history on, but it's a pain because you have can't delete history on a rigged model. Basically, you duplicate the geometry, take it out of the rig but keep it within the highest level group node for the object. Do Copy Attributes (NOT Transfer Attributes) from the new geo to the old, rigged geo. Hide the new geo. Yay, no more swimming UVs. It's basically doing the same as a texture reference but without using the texture reference command, which seems to be a bit buggy. That took nearly 3 hours, just to rig that stupid box. It's more fun than modeling, though.

I went through a couple more Brinsmead tutorials, specifically the one on creating a forest and the one on turning a page using nCloth. Here is Duncan's forest scene, with added layers of paint effects, and fog and light, to show the different steps.


Grass only.


Grass and flowers.


All foliage.


Fog added.


Extra light added.

One thing I noticed was the difference with and without the fog. While the fog is a little too swamp gas-like for my taste, it's interesting how the fog, normally associated with obscuring detail, actually manages to bring out a lot of shape detail in the leaves on the trees. We lose a little color detail, but that doesn't seem to be as important at a distance. To me, it's more important that they read as tree leaves and not blackish blobs. The added light in the last picture creates a nice translucent look for the leaves, but is not as applicable to my project since my setting is night time.

I saved out one of Duncan's tree presets and put them in my scene, along with a quickly modeled road.



This is the start of my final environment file that I will reference for animation. One interesting note, the glow does not show through the paint effect trees. I had to render the glow separately and composite in photoshop. So the order of compositing within Maya seems to be: beauty pass, then glow on top, then paint effects on top. This means that I'm going to have to eventually convert the trees to polygons, something I'm not looking forward to. I also need to convert in order to get access to the paint fx shaders, because the color of the trees is terrible. I really like my ground shader. Covered with a layer of paint fx grass, it should look pretty nice. I may also create the road simply using bump, the way Duncan does it in his forest scene.

nCloth, I am happy to report, is quite easy to pick up. I followed Duncan's tutorial, and it sort of worked. I wasn't happy with the wiggling and the "wind blowing the pages" effect, so I added another transform nConstraint and used it to turn a single page. With a whole bunch of stationary transform nConstraints to reduce the wiggling, I think this could be a great, easy way to get realistic page-turning animation without having to rig a manual explicitly. It's awesome, I turned a painstaking animation task into a much more fun effects task.

And I also continued to add texture to the well. Here's what it looks like with smoothed normals, a granite-rock shader, and puffed out bricks.



I'm considering smoothing the whole thing, but with the smoothed normals and smoothed geo it looks more like a French cruller. I kind of like this look. Add some ambient occlusion and some grime in the cracks and it'll look great. What's nice is that it also looks decent up close, although I figure at some point I'm going to have to do a separate texture for the well's close up shots.

Finally, I installed and started working with RealFlow. It's really easy! If you know Maya, that's a big plus because the transform tool hotkeys, and the camera movement hotkeys are identical to Maya's. I set up my very first RealFlow project. Time to do the good ol' dynamic fountain assignment. It looks like there's an easy rippling function in RealFlow which would be great for the water drops. I'd love to start doing some tests with exporting meshes.

I don't want to show my dragon model because I spent very little time on it. This is because it is the most important part of my project right now and I hate modeling. Hence, I've gone and done all these secondary tasks instead of trying to focus on this important one. Maybe I'll get someone to model for me.

Getting into the swing of things

It's kind of irritating that Donkey Hoti is taking so long. I guess I always underestimate how long troubleshooting the rendering process takes. It's also sobering for the amount of work I have to do for thesis.

Anyway, between last week and this week, not much as been done. I did start on the final dragon model, as you can see here. I'm planning on doing the rough surface in NURBS and converting to polygons. Hopefully I won't have so much detail that I need to do subdiv modeling.



I am taking a dynamics class during thesis to get a better idea of some of the visual effects that I want to do. Our second week was to do a splash, so I decided to do it in the context of the shot where the final ingredient falls into the well. Here you can see the quick 3D texture I put on the well model, and some animated water.





Obviously, the splash itself needs a lot more work, and I'm not even sure if that's how I'll do it. Realflow might be a better solution, and I might end up using this particle effect for mist or steam in the splash. The water would be bright orange at this point anyway from the other ingredients.

Speaking of which, I tried to go with the one ingredient idea that Boaz came up with last semester, but Gavin (Gavin Guerra is my thesis advisor) said the montage sequence added to the story by providing a reason why Billy doesn't want to screw up the final ingredient -- so as not to lose all the work it took to get to that point. Ugh, that means more work. More animation, more coordination of renders, and worst of all, more editing.

Gavin said the part at the end where the dragon is pissed at the manual was not clear. There needs to be a better comparison between the image in the manual and the dragon itself. Gavin suggested that the dragon stay on the well ledge, and Billy should look from the image to the dragon a couple times. Gavin really liked the two proceeding shots, the one with Billy and the dragon in a side view (the "reveal" shot), and the following one with Billy's huge face compared to the small dragon size (the "scale" shot). From there, (1) Billy stay's in place and looks to the manual, maybe the camera pulls out to reveal the manual, (2) the picture with "Enjoy your new mighty dragon" is shown, (3) Billy looks from one to the other back and forth, no sigh, (4) dragon looks down at the page, (5) closeup of the dragon pissed, (6) dragon burns manual, (7) Billy scared face, (8) burning ash (with smug dragon in frame?), (9), and a cool final shot with the dragon and Billy looking at each other in another side view.

Another idea I had was for that funny looking streetlight. I'm going to make it into a park light instead. Maybe I'll go to central park and check out some of the lighting they use in the park.

Goals for this week, the second to last week for modeling/texturing: model the dragon, model the lamp, model a fifth finger for Billy, start texturing the well, create the environment file that will reference everything at first and import when all the models are finished, and subsequently it will become the file that the animation scenes reference. Lot's on my plate, as usual. This and I have to finish Donkey Hoti and deal with life in general. Let's not forget food and sleep.

More Production

So today I spent most of my time on Donkey Hoti. Hopefully my contribution will be done this week, and I can channel all my energy into thesis. It would be nice to get some part time work as well, but one step at a time.

Anyway, I did manage to get some stuff done between yesterday and today. I modeled the well, which will of course look much better with textures and bump on it.



After much fretting I decided to put most of the final ingredient bottle detail in bump and possibly displacement texture. What I did do, however, is rig a liquid meniscus that can go up and down, and rotate, simulating the moving surface of liquid as the bottle is jolted or picked up. A wireframe showing the rig, and the render itself.




tomorrow and friday: redo textures for manual for single ingredient idea, rework 3D animatic, model the dragon. Yeah right, but I'll work as hard as possible, I promise!

Brinsmead inkdrop and Maya fluids

It seems like Duncan Brinsmead has already documented solutions for nearly all my effects problems. Here is one that looks like it would work great for my underwater shot where liquid flows out of the container:

Brinsmead inkdrop

I spent Monday morning basically dissecting this effect. It's actually quite simple to set up. It's a basic 3D fluid with a constant color, high resolution, higher detailed solve, self-shadowing, and negative buoyancy to get it to flow down slowly instead of upward. The calculation times are pretty intense, though, running at a few minutes per frame. The render itself actually doesn't seem to take that long, about 20 seconds, but that's for a small preview size.

--------------------

I spent some time playing with Maya fluids and learning how to cache fluid dynamics. A point to remember: always have the file saved in the correct location with the project set correctly before starting the cache. One wrong move, and the whole cache file is destroyed. Also important, you have to save the file before Maya saves out the cache file from the temporary folder to the data folder in your project. Unfortunately, this makes it take longer to save the file and longer to open it. One should probably also back up the cache data so as not to accidentally save over it.

One interesting option I had not considered is the ability to create segmented cache files, meaning a new cache file for each segment of frames where you set the number of frames per segment. The advantage here is the ability to use different sampling settings for different segments. Also, it allows you to create caches for files that may otherwise be unmanageable, e.g. a 8 GB cache file broken up into four segmented 2 GB cache files. This will almost definitely be necessary because my test for the fluids cache was over 20 MB for 10 frames. Thus, it is possible that a three second shot with a high-res fluid simulation might well be over 2 GB, the maximum file size for an individual file in XP.

Another cool trick is the use the Paint Fluids tool, which can be used to paint attributes right into the fluid container using the artisan tool. With 3D fluids, this is done by painting on 2D slices of the container. You can either have autoset initial state checked, or, at the end of your painting, set the initial state of the fluid. There are tools to select how thick a slice is, to paint through multiple slices, or to even specify a subvolume within the container to paint in. Fluid properties can be exported or imported as "slice maps."

It's relatively easy to make a fluid collide with an object, but the main consideration is not the surface of the object, but the resolution of the fluid system. I found that fluid "leaks" out of the object (I have a bowl to "hold" the fluid"), but this problem is due to the fact that the geometry cuts some voxels in half. In this situation, if more than 50% of the voxel lies within the bowl (I think that's how it works), the voxel still contains fluid. Thus, if 60% of the voxel is within the bowl, the other 40% of the volume of that voxel will have fluid in it where it shouldn't.

I did a basic cache by doing Fluid Effects -> Create Fluid Cache. Maya saves out a file to the data folder in my project, one that is copied and renamed if the project or scene name is changed (due to saving the scene file with a new name). At this point, the fluid resolution was pretty low, and I did not have the fancy settings that Duncan used (self-shadowing, higher detailed solver), but I did have the default incandescence from temperature on. It dissipates from a glowing pink to a dark red. An example image (you can see the problem with the "leaking"):



I'm feeling pretty good about this effect, but I just need to integrate the liquid geometry in the bottle with the actual fluid effect. Then again, I could forget the geometry altogether and just have a bunch of fluid particles start out in the bottle. It will also be nice to have reference footage. I'm thinking of filling a bathtub up and dropping a small vial of blue food coloring mixed with glycerin or something to make it thicker. I'll experiment with different liquid densities and materials: water, glycerin, oil, paint etc.. That will be a fun project to film.

Intro to fluid simulation

My thesis is essentially a test drive of the major fluid simulation abilities of different off the shelf or freeware software packages. I quick surf of Wikipedia returns four options: Blender3D, Glu3D, AfterBurn, and Realflow. To those four I'm going to add OverBurn, Flowline, and Houdini.

Blender 3D is a freeware program for 3D production (GNU public license) and includes a fluid engine:


Glu3D is a plugin for 3D Studio Max and Maya. It uses particle-based hydrodynamics in conjunction with particle-wrapper geometry for the liquid shape and wet maps to simulate the differentiation between wet and dry parts of the surface:


Afterburn is also a plugin for max and maya developed by Sitni Sati of Afterworks.com. It includes various methods for creating mainly gaseous fluid effects, from what I've seen:


Overburn is a plugin for Maya and the brain child of Peter Shipkov. As far as I can tell, it uses Maya fluids to shade particles using the particleSamplerInfo node. It's freeware! (Double-click the movie below to play it again):


Flowline is the proprietary software of Scanline VFX and there is probably no way I will get my hands on it any time soon. But it has really nice looking renders; I remember being absolutely blown away during SIGGRAPH 2006:


And finally, Houdini from Side Effects Software, the grandaddy of particle effects. It is a purely procedural program and relies heavily on various operations:


The main issues are obviously the simulation and the rendering, and they are definitely two separate issues. For simulation, it's a matter of finding the software program that achieves the best qaulity results in the least amount of time. Learning software and testing the simulation are the big hurdles. With rendering, a potentially major hurdle is mental ray itself. I have heard that mental ray fights fluids and doesn't render properly, and moreover the mental ray to maya plugin does not support the particleSamplerInfo node, according to Peter Shipkov. I suppose there are ways around using the particle sampler via added attributes and expressions or direct connections, but it's still more work.

---------------

The heart of all fluid simulations is, of course, fluid dynamics. Fluid dynamics are based on fundamental laws of physics: conservation of mass, momentum, and energy. A fluid's main properties, velocity, pressure, density, and temperature, are used to define the behavior of the fluid at given points in time and space. Although fluids of course are made of discreet molecules, for the purposes of physical calculations this fact is mostly ignored and the fluid is assumed to be a continuous body.

Of course, computer scientists hate the idea of a continous body and tend to divide the fluid into discreet volumes, referred to as voxels. These, of course, are almost always much much larger than a single molecule of fluid. System's of energy, mass, and momentum are calculated for each voxel for each frame. Fluids, like all dynamic effects, are influenced by forces acting upon them, including gravity, turbulence, torque, and the like. Fluid molecules tend to want to stick together, and this stickiness is usually a controllable attribute of the fluid and/or particle system. Shading can be done volumetrically or using sprites for gases, or shaded and raytraced like normal geometry for liquids.

This is really really simplified, and I am not a scientist by any means. But I think a foundational knowledge is key to understanding the attributes, which in turn is key to understanding how to create a good fluid simulation.

Yay science.

3D animatic musings

Here are some more screen shots from my 3D animatic. Sorry for the low quality, but I'm using my old laptop at home with simple software so the images have been through a couple jpg compressions. I don't want to post the actual animatic yet as I will still be spending a little time next week re-editing it and I have no web space at the moment.

My main concern right now is the timing of the shots and the camera angles, something which, again, is a previz issue. I don't think the editing of this piece should be invisible, although the cuts themselves should feel natural enough such that they aren't noticed. As I mentioned, comic timing is important and I have to give the audience a chance to react to the piece. There are many shots, and a whole bunch of cuts, lending this to an editing exercise as well. Perhaps I can get more help from my fellow thesis student Demetri Patsiaris on this.

Some comments from CADA student and Maya expert Mehma Sachdeva, who I like to go to for comments because she always tells me what's bad about my piece. She reacted to the story, so at least that carried over well, but said there were a lot of problems with the timing of the shots. I tend to agree. She also said that the cricket sounds stopping midway through the piece was distracting, and that I should take the volume down but keep them going all the way through. I think I'll do that for 3D animatic purposes, but after I get the piece scored it might be less necessary to have background noise.

Speaking of which, I have recruited my friend Germono Bryant to score my animation, but he seems a little disinterested and of course has his own projects to worry about. We'll see. For now, I will definitely consider the possibility that I may have to score the piece myself or look for royalty free music (or pay for it, another possibility).

So, changes, from the top:



I have since changed my title from How to Make a Dragon to Mighty Dragon. This seems more appropriate considering the theme of the animation. I cut out the establishing shot with Billy carrying the box. It's too much animation and modeling and texturing and doesn't add anything to the film. So instead, I'm going for a "closed opening" (going back to Visual Literacy terms) where the viewer needs a few shots to discover where they are.



The first shot is the box coming down on the well, followed by a few quick shots of Billy taking the manual out. His face is not shown until he puts his hand on the page and smiles at the dragon he is about to create.



My page turning rig was pretty cool at the time I made it, just a few simple blend shapes with a driven key "page turn" attribute. This worked, and I used it for every shot where a page but I think I will try out Duncan Brinsmead's page-turning rig using nCloth. Another visual effect to add to my toolkit.





One thing that kind of irritates me is the montage sequence with all the ingredients. It's hard to animate and it's a lot of animation that will have to be tweaked in order to look non-repetitive. I'm thinking of going with Boaz's idea (my lighting professor) and keeping it to one ingredient: PRO-QUEST brand instant dragon formula, or something. The montage sequence also doesn't add anything to the film.



The ocean shader shot under the water turned out really well, and I think I'll keep that shot in the film as a fluid effect. I need liquid viscously coming out of the bottle, and maya fluids might be a good solution. The refracting I will either handle in post or with mental ray's glossy and refraction nodes.



The glowing well water is easy to achieve through incandescence, glow intensity, and an extra spot light in the appropriate places. It's a great moody effect that's incredibly easy to achieve. The only thing, of course, is that dastardly ocean shader and its refusal to rotate.



I composited the dragon splash with After Effects. It took just a couple hours of color correction and keying, plus a slight roto. Turned out decently. I might use some compositing in the final piece but the main effect is probably going to be particle-based, unless I can simulate something pretty well in realflow.







I'm having trouble getting the dragon to look big for its first shot, even with a fish eye lens and lower perspective. I think it's the size of the well. This will be a difficult shot to pull off.



The fire effect took about a day to achieve, and involves extra spotlights linked to the dragon and Billy separately, with animated intensities, and the standard Maya fire effect with scripted tweaks. Instead of the fire flowing upward, it flows along the vector defined by the direction from the dragon's mouth to the manual. The simulation took a long time. I actually really like this shot, even though it took the longest to render.



The smoke effect of the burnt manual is merely a texture on a deformed NURBS plane with some composited smoke, and again I like how it looked. The smoke was multiplied on top and taken from CADA's stock footage. This is actually a viable alternative, unlike Maya's smoke effect, which I spent several hours tweaking to no avail. Maya smoke, I find, is best for smoke viewed from a distance, not closeup. I think this is a consequence of using sprites.

So what took the longest time? Do I even have to say it? I spent about 60% of the time tweaking animation curves for the kid, the dragon, and the final ingredient bottle. Another 30% of the time was spent on creating and rendering out special effects, and the last 10% was everything else, including setting up the cameras, basic basic modeling and texturing, and even the dragon rig took less than half a day.

Goals for next week:
-Model the well and the final ingredient bottle, two key elements that will be needed regardless of any changes made to the script.
-Find a solution for the trees, be it paint effects or a modeled tree, or a purchased one. Think about, maybe even start the matte painting background and how that will integrate.
-Iron out the 3D animatic for timing, tempo, and rhythm of shots (yay for Story)
-Research fluid solutions
-Come up with a nice ground plane shader that renders quickly in mental ray.
-Iron out story elements, especially the design of the lamp.
-Model and shade the lamp
-Model and design textures (perhaps not finish the texturing) for the box
-Talk to my fellow classmate Vanessa Weller about foley sounds. She took Pro-tools and is sold on the importance of sound in animation.
-Model the dragon. Three words, yet this will be the hardest task I think. I need Cidalia's and Patrick's design sketches scanned before I can start, so unfortunately there is a bottleneck there.

Hit the ground running

Whew, I just had my first thesis class with Gavin, and it has only underscored how much work there is yet to be done. There really is no time to waste.

So for the past week and a half, I have been working to create the 3D animatic that should have been completed in Previz. Unwittingly, it has also served as a kind of test run for my project. I spent a little time modeling, texturing, rigging, animating, lighting, creating visual effects, and compositing the rendered frames. I'll go into more detail on the 3D animatic in a bit, but first a couple things this mini-project has taught me. Some I may have mentioned before.

-Always keep the character's rotations zeroed out in relation to the environment and the camera, not the other way around. Rotational disaster occurred when I referenced the character into the scene, and rotated him 45 degrees to get him in the correct spot. This messed up the rotational axes for nearly every joint. It took me nearly a day of painful animation before I decided to rotate the character back, rotate the entire environment instead, and re-reference the scene.

-Fluids are nearly impossible to simulate well. Yes, the focus of my project, fluids, turns out to be one of the hardest problems to solve in CG. And yet, there is something about well-rendered water that really excites me, so I'm happy to rise to the challenge. As it happens, Maya fluids are in fact really bad for liquids, and work much better for gases. I'm researching more ways to do fluids. Some possibly promising solutions are using Maya Hair dynamics, Maya particle simulations, and Realflow. My fellow students Tyquane Wright and Parthibahn Elangovan, and my dynamics professor, Adam Burr, the former effects supervisor for Blue Sky, have all offered to provide insight into these methods.

-Animation takes the most time, and lighting takes the least. For some reason, it is always very easy for me to set up lighting systems, even if it requires in-depth understanding of shadow casting, or complex light linking. Animation, on the other hand, really has no corners to cut. You really just have to spend a lot of time on it.

-The frickin Maya ocean shader doesn't rotate! What a pain in the ass! I rotated my liquid plane around and around and rendered out the frame sequence, only to be faced with completely still, non-rotating ocean waves. I tried all kinds of hacks with all kinds of nodes to try to rotate the ocean wave displacement but it just doesn't work. Perhaps this is question to pose to the all-knowing Maya god Duncan Brinsmead.

-After Effects is okay for the quick and dirty. I've always thought of After Effects as a quick and dirty program. I mean, for motion design or title design it's great, but as far as its usefulness as compositing or editing software, it's only good for simple tasks. Such as compositing and editing a 3D animatic. I did, however, use Final Cut Pro to edit in the sound. Why use AFX to edit when I could have used FCP, you ask? Because, and this irritates me to no end, FCP has no good way have handling frame sequences (that I know of). In the FCP help, one of the suggestions is to import the images one at a time and drag each of them into your sequence individually. How unhelpful.

-Rhythm and tempo are key in my piece. Today Gavin said he liked the "comic timing" of my piece, giving the audience a chance to react to one shot before cutting to the next one. It's really, in a nutshell, a cosmic punchline: We create something that's different than expected, but still just as good as what we intended to create. Omri mentioned that he thought there were too many beats at the end, where the kid is surprised by the smallness of the dragon, then content with it, then disappointed after seeing the mighty dragon image, then surprised by the fire, then happy with the dragon yet again. Perhaps this can be resolved by changing the "being content" beat to "being reluctantly accepting." This carries over into the disappointment of the next beat. On the other hand, to change this would be a little sad for me because the "being content" shot was one of my favorite shots while animating.

-Laddoo is fine. So it's a downloaded model and rig. Modeling and rigging are completely not my focus. And he's probably better than anything I could create in such a short period of time (according to last entry's schedule, I should be finished modeling by next week).

Against the judgment of several of my fellow students and professors, I am making the focus of this project visual effects, and character animation as the secondary focus. To those who still say, why are you doing a character animation if your focus is not character animation: leave me alone! I like my story. Animation is hard but I can do it. And, most importantly for me, visual effects are much more fun than animation, but only when used to augment the story. Actually, if I could make story the focus of the project, I would. We did, after all, spend nearly all of previz on it.

Coming up next: a more in-depth look at my 3D animatic, and goals for next week.