'
-->
});
});
My first task was to work with a colleague of mine, Branndon Fricks, to complete some modeling. As always with modeling (and all aspects of a project) reference is critical. We began to do some basic research on what we'd be modeling and discussed how we'd go about doing it. The above images we gathered as reference to work from.
For Branndon and I, an emphasis in the modeling was speed: speed in the time it took us to actually get it modeled because there were other things to get to, as well as speed in rendering (the complexity of the objects needed to be low, but not quite "game asset - low poly" kind of low.) The storyboards were considdered and appropriate detail was put on objects that got close enough to the screen to warrent them, while others were given just enough detail to look correct from a distance. I think since I was so used to a specific way of modeling, it took me a second to switch my brain over from sub-d modeling everything to accepting a simpler form of an object. Some of this was helped by knowing that rounded corners on things could be achieved by the Arch & Design shader.
The above images are some renders I put together to demonstrate the progress of the modeling to the client. These are the complete rig that Branndon and I worked on with their textures and all.
I'd had some troubles with making some renders of this shot, probably mostly out of stubborness. I really wanted to get the gradient background on the image, and I was encountering numerous problems in doing so. First off, the ramp map worked fine with the MSR shader and a standard directional light, but with that light the shadows came out really nasty.
Second, I used a daylight system, but couldn't get it to be not blown way out without using exposure control. I can't seem to get exposure control to work with render elements either, they get blown waaay out ... In using the daylight system and exposure control the MSR shader didn't work because it didn't accept the change in exposure. I tried to generate a shadow pass as a render element, but it came out terribly and would never pre-multiply properly.
Finally, what I did was generate a render of the geometry by itself with no ground. I then made a pass of the geo with a ground plane and a matte white material applied to everything. I used this pass as a multiply over the alpha'd geo and a ramp in AE, and did a bit of color adjusting. I've learned better methods since then to handle something like this, but I suppose the important thing was at the time, I found a solution with what I knew.
With the rig completed (for the most part) Branndon set about making a pad to put it on, and an environment for that to exist in. He did some cool stuff with PFlow and tree cards for the stuff in the distance to cut down render times, and it looks cool. Chas Naylor (another awesome professor of my from school) did the lighting and rendering/compositing for this shot.
After the rig there was still plenty to do. An asset that was to be used was the 'bobbing donkey' or the pump jack. These are used when the initial pressure of the oil pocket runs low to help draw more oil out (instead of it spewing like it did at first.) After some discussion, Branndon decided he wanted to model the jack, and that I'd rig it. I thought it would be pretty simple to rig, and at first it was, but I was working on it late one night and was a 90% done with it when I hit a snag that was breaking the rig. Instead of beating my head over it, I went to sleep and decided that two brains were better than one so I'd convene with Branndon in the morning. After a heafty amount of BS'ing, we finally sat down with the rig and it turned out the solution to the problem was amazingly simple. It turned out to be a simple check box or something, I can't quite remember, but it felt great when the whole thing came together and was finally working.
This is a simple asset I needed to make. It's a blow out preventer. It's what goes on top of the hole that's drilled to prevent oil from spewing out everywhere. Tubes are connected to the different horizontal cylinders with the valves and the oil is pumped to large vats. There wasn't much too this thing. Even the texture is pretty simple. Most BOPs I looked up were painted solid colors and only had a little bit of bump from the paint. The geometry of this guy is simple in that the cylinders are intersecting and such, and rounded filets are achieved with the Arch & Design rounded corners feature.
These two videos are the fluid simulations I did for this project. The top one, the graph fill, wasn't used in the main video itself, but as a side graphic for the company. Michael Eudy had done several brochure graphics for King Consolidated and wanted one of them to be animated, so he set me to task. I used Realflow for the simulations and rendered them in 3ds Max. These graphics went through several itterations and versions. There was a lot of feedback from both Michael Eudy and Chas Naylor, and I had to make lots of adjustments before the final versions were made. I'll explain that below.
This video shows one of the first fluid sims I made for the chart graphic. The brochure graphics were tall and thin, but were later changed to the wide ones in the video because the aspect ratio used for our video was 2.35:1, and the tall ones left way too much empty space in the shot. I'd encountered a lot of problems when first doing this because the fluid simulations I was making, at least in Realflow, were very 'jiggly' and weren't settling like a fluid would. I fixed several of the issues I was having with the fluid filling the rectangular prism bu using a "drag" and "kspeed" daemon to fix most of the issues. I used the drag daemon and key framed it's strength toward the end. The kspeed daemon was used to not kill particles that went below a certain threshold of speed, but to basically lock them in place. I also played a lot with the fluid settings to make it look less like water, and more like a goopy oil substance. If it didn't read in a simple gray mesh, then making it black wasn't going to make a difference.
Above is a short clip I made to demonstrate how the graph for the competition would fill. This was after the adjustment to the wide graphs was made. Their method wasn't as good as King Consolidated's method was, so their graph didn't get to fill as much. I attempted to jazz it up a bit to make it slightly less boring, hence the little burst toward the end, but I was told to take that out entirely. It gave the graph for the competition to much spark, too much visual interest, and we wanted them to seem boring. It made me a little sad to take it out, but this wasn't for me, it's was for the client.
My initial take at filling the wider graph ended up not going through. I had the fluid emmiting from the corners of the prism because using one emmitter wasn't filling it fast enough. I tried turning up the rate at which it emmitted particles, but it just ended up being too intense and crazy, so I went with two. For some reason I thought they had to both start at the same time and be in different places, but I was just thinking too lineraly. I later had 4 emmitters, but they didn't start until the initial burst of oil coming from a central point has some fluid in the bottom of the graph which would hide other emmiters beginning to fill, and at that point the illusion is that it was just coming from the one spurt point.
I encountered a problem with the oil fill graph scene. As a whole scene, the frames were taking about 12 minutes a pop to render. This was a problem due to the amount of frames needing to be rendered, which made the whole animation come out to over 70hrs to render on one computer.
The first thing my mind went to was to network render it, but that wasn't possible due to the fact that none of the computers at school had RealFlow on them and therefore could not reference the .bin files in order to import the meshes into the scene.
A different approach to rendering the scene needed to be found. I wracked my brain over it for a bit, and even asked Naylor for some help. I took some of the info he gave me and combined it with some ideas I had and came up with a solution.
First off, the liquid is rendered separately (it renders much faster by itself) and put over everything else (it's the only thing that animates, so the rest of the scene could be rendered in one frame). The problem with that is obvious in that it needed to be "in" the glass containers. To make it look like it was in the containers I did two things:
First, I took the reflections element from the glass (they were rendered as EXRs with embeded elements) and "added" it over the goop. This went far in making the goop look like it was in the containers, but not all the way.
Second, due to refraction and the BRDF there are parts of the container that reflect so much or refract so heavily that those areas (almost) completely obscure what's inside the container. So, I masked out those portions of the goop to make it look more "under" the glass. This isn't entirely realistic, but it's close, and given the weight of this shot it doesn't need to be perfect I don't think.
I also used a mask for the cylinders going into the goop, and animated the masks going up as the fluids fill the container.
Using these methods I wasn't able to get it EXACTLY like the original, all in one, beauty, but it's really close and pretty convincing. It was a much better solution than waiting 78 hours for a render.
These two videos are my first attempt at figuring out how to work the 'fracing fluid'. In trying to figure out how to do this, it was first suggested I try to use one of the 3ds Max AEC primitves (one of the trees) to get a veiny, cracky look, but that wasn't working for me. I instead used the free form tools in 3ds Max to draw out what looked like brancy fractures. I used this geometry in Realflow to fill with fluid. This ended up being a problem because the way it looks as this, there appears to be a container that's being filled by fluid. Well, the fracing process doesn't work that way. The perfing gun causes fractures in the sediment, and those fractures are pumped full of a certain type of liquid at a really high velocity to, via high pressure, crack the strata even further. So, filling something looks entirely different than a very fast, high pressure fracturing of weakened strata.
The first video is an orthographic sideview of the particle system, while the second is a perspective view of the particles meshed. The mesh isn't quite right, it's way too ... separated and 'hole-y', but it didn't matter because this whole idea was scrapped to go with another method anyway.
These vidoes show the next attempt at the fracing fluid process. I used the same idea behind the previous one with the drawn out geometry with the freeform tools, but due to some critique, I made them more cracky and earthy. I actually had a picture of some really dry mud in the viewport background and was using that as a sort of guide. Before they were too curvy and loose, didn't quite look like fractured earth. With a few main tendrils created, and their corresponding branches, I decided I didn't need to make 18 unique tendrils. I instead broke the branches off of their tendrils and then instanced the tendrils and mixtures of the branches. With one side made I mirrored it on the X and Y for the other side. The seep at which this was all occuring should make it look random enough.
Now with this method, I wasn't using fluid sims at all. I was attempting to be more economical and quick with the process. With all the tendrils and branches instanced, I only needed to apply the "slice" modifier on the original ones to get the animation of them extending out. I set the modifier to "cut off the top", and then just animated them moving out in the appropriate direction at the right time. The only problem this caused was since the instanced versions were set about in random places with other random tendrils, they would start at odd times. So I cloned the ones that were wrong, as copies not instances, then I moved their keys and deleted the instance (if there's a better way to make an instance unique let me know.) With all the geometry placed and animations set, I used the water material like Eudy said, and set about to render.
This still wasn't quite what Chas was wanting, so I went about yet another method for the fracing fluid process.
So the lightning sequence above was a clever solution to the problem that I hammered out with Branndon. We had gotten into some crunch on the project, and the fracing fluid sequence needed to be done quickly, and look like what was wanted. This worked out well because the lightning had the craked look that we were going for, and it was quick to generate so a few itterations could be made for some variety. The lightning sequences were made in After Effects with the simple lightning effect plugin, and masking was used to animate them out. The lightning was rendered out as a sequence of images and taken into RealFlow and used as a map for the water to be generated from. 5 versions of the lightning were made, and with that 5 different fluid sims. It was all generated pretty quickly, but lots of optimization had to be done in 3ds Max in the end to reduce render time. In the end, we got it done in time and everyone seemed pleased with the new look.
King Consolidated
.....
.....
.....
The above videos are cuts from a project I worked on (the portions I was involved with.) The full video can be seen on Michael Eudy's website: Polygrinder. This is a project that was done for a company based in Dallas, Texas that specializes in acquiring and operating crude oil and natural gas properties: King Consolidated. I was really excited when the lead instructor of the Media Arts department at school, Michael Eudy, approached me to do some work for him on the project. I was in my last quarter at school, and it was the first time I'd get to apply what I'd been learning on a professional project. I'll admit that I was a bit daunted at first; there I was with a lot on my plate already trying to graduate, and adding more work to that feast wasn't going to be easy, but I was excited and I knew it would be fun.
.............................................
.....
.....
.....
.....
.............................................
.....
.....
.....
.....
.....
.....
.....
.....
.............................................
.....
.....
.....
.....
.............................................
.....
.....
.....
.....
.............................................
.....
.....
.....
.....
.............................................
.....
.....
.....
.....
.....
.............................................
.....
.....
.....
.....
.............................................
.....
.....
.....
.....
.............................................
.....
.....
.....
.....
.............................................
.....
.....
.....
.....
.....
.....
.....
.....
.....
.....
.....
.....
.............................................
.....
.....
.....
.....
.....
.....
.............................................
.....
.....
.....
.....
.....
.....
.....
.............................................
.....
.....
.....
.....
.............................................
.....
.....
.....