Quick update on what I'm working on! I'm now working as a pixel animator at Mighty Rabbit Studios here in the Triangle area, so I will be delving into more pixel work on here in the near future.
The Angels Fall First project is progressing well, too. The finished mech rig has been put aside for now so that I can do a full overhaul on the first-person arms and weapons.
The arm rigging is pretty nuts right now. The original meshes were created using a poly-decimator, which basically takes a hi-poly mesh and tries to create a low-poly version while maintaining the overall surface shape. The problem is decimators don't create clean topology, and messy topology looks crappy when it deforms. Thus, I've had to re-topo the hands and try to fit them all to approximately the same proportions, with a marginal degree of success. I hope to explain more in a future post.
My latest work, tho, has been on the gun rigs. I've got a ton of awesome weaponry on my hard drive, and I've been having a ball working on getting it all set up to animate. I took one of the assault rifles all the way thru to a finished rig so that I can start testing thing out in-engine soon. Here's a short demo vid:
This rig took a lot more work than I'd expected. It has a lot more moving parts than most guns (sometimes all you need is 2 bones: grip and magazine), which was work enough, but the real challenge was making the switchable pivot points. I tried a number of different methods, but the eventual solution ended up being pretty simple.
At the core, it's a variation off the simple IK/FK triple-skeleton switching system. I have two skeletons for the stock and grip which drive the main control skeleton. One skeleton is rooted at the stock, the other at the grip. The main body control houses the attribute which switches between the two. Ideally, I'd like to set up a script that will allow for matching between the two versions. Way down the road, I'm hoping to write a GUI that would allow the animator to switch out weapons on the fly and do other nifty tricks, but that's gonna take a lot more planning and work.
Alrighty. That's me for now. If things go well, I should have moar soon! :D
Pipeline Dev @ Epic Games
NavBar
|
Showing posts with label UDK. Show all posts
Showing posts with label UDK. Show all posts
Monday, May 9, 2011
Sunday, April 17, 2011
Mech Rigs + Tool Writing
I've recently joined the Angels Fall First team as an animator, which is turning out to be a lot of fun already. I enjoy animating, but I love rigging and scripting, which is good since my first set of jobs are to rig (and eventually animate) the first big mech, the Velius Mk2, as well as some of the first-person arms and weapons. It's been a while since I've done any hardcore 3D work, so I've been shaking loose the cobwebs and getting back into my groove.
For the mech, I was given the in-game mesh weighted to an older version skeleton, but it was missing any sort of controls, and the existing animation had been baked down onto the bones. After looking the whole thing over, I scrapped the animation, detached the mesh, and went to work improving the skeleton. The original structure was mostly acceptable, but I added in some extra degrees of motion for the hips, torso, and neck, as well as bones for the toes. I also added in some bones which will be be used in-engine to facilitate the destructible armor plating.
Once that was finished, I weighted the mesh back onto the skeleton so it could move around. Weighting mechanical objects like a mech is a fairly easy process, since most of it simulates rigid binding, but it can still be tedious.
I then duplicated the skinned skeleton to provide a base for the control skeleton. My thinking was that by separating the control structures from the skinned skeleton, I could re-skin the mesh or fiddle with the rig controls without affecting the other too much. The two skeletons are exactly the same, except that the control skeleton has two sets of arms and legs to allow for IK and FK control sets.
Of course, a control skeleton isn't very useful without control objects for the animator to manipulate. Most rigs I've used in the past stick to NURBs curves for the controls, but I decided to mix and match. I'm experimenting with doing super-low-poly versions of the limbs instead of control curves because they are easier to spot and easier to click on. The arrow control curves were objects that I created quickly in Illustrator, saved as Illustrator 10 files for compatibility, then imported into Maya
With the control objects built, I now need to hook them up. The IK controls will be a little tricky, but FK controls are about as straightforward as you can get. However, connecting everything by hand takes a long time, so I wrote a little script to speed things up. All I have to do is select my control object, the joint I want to connect it to, and run the script. What it gives me is a control surface completely oriented to the joint with all its translation, rotation, and scale channels zeroed out. This gives the animator a nice, clean base to start with.
In all, getting to this point has taken me about a day and a half, and I loved every minute of it. I spent almost my entire weekend working this up because that's what I like to do. I'll post more shots as I finish it up. Also, go check out the Angels Fall First site! It's got a lot more cool stuff to look at!
Tuesday, April 6, 2010
I'm a tool (writer)
Things are getting pretty busy. The film is due for marks on Friday, and I'm busy trying to get something patched together for marks. To help try to meet that, I took some time today to write a little pair of tools to get me working faster.
The UDK has a nifty command switch called "dumpmovie" which forces it to save every rendered frame to the screenshots folder. In combination with the "fps XX" switch (where XX is the number of frames per second), it essentialy performs like a batch render in Maya, except there's not automatic off. Instead, it plays in a game window, and stops recording when you exit the game. Of course, the options with this are very limited. You can't (as far as I'm aware) set the path for the screenshots, and it only saves in BMP format, but it works, and that's what's important. Since BMPs are uncompressed, they take up a lot of space. A 120-frame render weighs in just over 300Mb. With WinRAR, I can collect and compress those 120 frames into a single 20Mb RAR file. That's about a 93% storage savings.
With those facts in mind, here was my workflow for rendering out a scene:
So instead, I wrote two simple batch files. One does the rendering side, the other runs the archiving. The rendering one also has the option of calling the archiver as soon as the render finishes. This is my new workflow.
As a side note for comparing UDK render time against Maya: If we assume Mental Ray is rendering at 5 frames/minute and UDK at 15 frames/sec, the ratio is 4500:1!! Render time essentially becomes a non-issue. I could render my entire film (if it were contained in a single map), check for errors, tweak the map, and re-render in about the time it would take MR to render 3-5 frames. This by itself is one of my major arguments for using real-time rendering engines (like game engines) for rapid film production work.
The UDK has a nifty command switch called "dumpmovie" which forces it to save every rendered frame to the screenshots folder. In combination with the "fps XX" switch (where XX is the number of frames per second), it essentialy performs like a batch render in Maya, except there's not automatic off. Instead, it plays in a game window, and stops recording when you exit the game. Of course, the options with this are very limited. You can't (as far as I'm aware) set the path for the screenshots, and it only saves in BMP format, but it works, and that's what's important. Since BMPs are uncompressed, they take up a lot of space. A 120-frame render weighs in just over 300Mb. With WinRAR, I can collect and compress those 120 frames into a single 20Mb RAR file. That's about a 93% storage savings.
With those facts in mind, here was my workflow for rendering out a scene:
- Save final map and assets in UDK, then close editor.
- Open command prompt and type in really long UDK shell command to start a Dumpmovie render. (example: C:\UDK\UDK-2010-03\Binaries\Win32\UDK MapName -dumpmovie -benchmark -fps 24 -resx=1280 -resy=720)
- Render out scene.
- Open Explorer to the UDK screenshots folder.
- Select all new rendered frames.
- Right click, "Add to archive."
- Set up WinRAR options.
- Delete leftover frames.
So instead, I wrote two simple batch files. One does the rendering side, the other runs the archiving. The rendering one also has the option of calling the archiver as soon as the render finishes. This is my new workflow.
- Run UDK_Render.bat.
- Give map name, choose resolution (full or half 720p).
- Run render.
- Choose to archive (or not).
- Give archive name.
- Done.
As a side note for comparing UDK render time against Maya: If we assume Mental Ray is rendering at 5 frames/minute and UDK at 15 frames/sec, the ratio is 4500:1!! Render time essentially becomes a non-issue. I could render my entire film (if it were contained in a single map), check for errors, tweak the map, and re-render in about the time it would take MR to render 3-5 frames. This by itself is one of my major arguments for using real-time rendering engines (like game engines) for rapid film production work.
Tuesday, March 23, 2010
Pewpewpew!
I've been fiddling around with animation tests and setting up particle effects this week. Now that my rigs are done, I have to put them through some quick paces to debug controls/weighting. So far the planes look good. Chester needs some work, but what he needs can only really be solved by remodeling and doing some custom rigging instead of the autorigger, so I'll just have to make do.
Anyways, I spent Sunday learning how to use the UDK's Cascade particle effects editor. It's a nice tool, very powerful and modular, but (obviously) not nearly as crazy as Maya's stuff since it all needs to run realtime. The main downside to Cascade is that comparing it's interface and workflow to Maya's is like comparing command line Linux to Windows. There's a lot you can do, but it's not pretty, it's not easy, and you better know what you're doing.
So I got some basic muzzle flash FX working, and hooked them up to my carrier plane to see how they look...
Pretty sweet. I hope to get the plane textured and add some tracer particles when I have some downtime from animating. I'm loving the pewpewpew.
Anyways, I spent Sunday learning how to use the UDK's Cascade particle effects editor. It's a nice tool, very powerful and modular, but (obviously) not nearly as crazy as Maya's stuff since it all needs to run realtime. The main downside to Cascade is that comparing it's interface and workflow to Maya's is like comparing command line Linux to Windows. There's a lot you can do, but it's not pretty, it's not easy, and you better know what you're doing.
So I got some basic muzzle flash FX working, and hooked them up to my carrier plane to see how they look...
B17 Particle/Animation test from Adric Worley on Vimeo.
Pretty sweet. I hope to get the plane textured and add some tracer particles when I have some downtime from animating. I'm loving the pewpewpew.
Friday, March 12, 2010
Lightmass
Just upgraded to the latest build of UDK since I'm still in Content Creation, and haven't committed too many assets to the engine yet. One feature I hadn't played with at all til today was Lightmass. Lightmass is a new system for creating the baked-in lightmaps for level geometry. Unlike the old system, which used purely direct lighting (requiring individual lights for all lighting effects), Lightmap uses global illumination to create more realistic effects. The results are pretty incredible.
These shots are from the DM-Deck map that ships with the UDK. The only work I did was rebuild the lighting with and without Lightmass. It's amazing to see how good the lighting looks in comparison to the old system. As an added bonus, Lightmass comes with a network redistribution feature, so I can shunt some of the workload onto my lappy and speed the process up. As a comparison of build time, the old system lighting rebuilt in just over a minute, while Lightmass rebuilt in about 15.
These shots are from the DM-Deck map that ships with the UDK. The only work I did was rebuild the lighting with and without Lightmass. It's amazing to see how good the lighting looks in comparison to the old system. As an added bonus, Lightmass comes with a network redistribution feature, so I can shunt some of the workload onto my lappy and speed the process up. As a comparison of build time, the old system lighting rebuilt in just over a minute, while Lightmass rebuilt in about 15.
Tuesday, March 2, 2010
Nazis and Shaders!
Finally! Something visual to throw out into the world.
One of the options that caught my attention when I first started playing around with UDK's material editor was the Specular Power parameter. Specularity is essentially how shiny an object is. In reality, specular highlights are reflections of whatever is casting light. In CG, esp. for games, it's an approximation. The two control parameters given are Color and Power. Color is obvious, but the Power parameter is control over the spread of the highlight. Really shiny objects like polished metal have tight, bright highlights, while things like rough-textured plastics, unfinished wood, or other duller objects would have very wide, diffuse highlights. What first came to mind was how to control that across a surface? If you could control the SpecPower, you could simulate multiple material types without having to create and assign a new shader material for each material type. It took a few tries, but I think I have a basic working solution.
In addition to creating Diffuse, Specular Color, Bump, and Normal maps for a material, I worked out a way to make a Specular Power map. The way it works is it divides the texture into 4 color channels (RGBA) and assigns each one a specific specular power. It then adds each area back together, then divides the result by the sum of the original channels. Here's an image of this set up as a shader network in UDK:
The texture can't be applied directly to the Specular Power parameter because UDK sees each color channel as a value between 0 and 1, while the SpecPower parameter is a (relatively) unlimited number, and 1 creates a very very diffuse specular. By multiplying each channel by a fixed desired SpecPower, the artist can apply a range of specular intensities in the same material. Here's a quick example of the shader in action:
SpecPwr Shader Demo from Adric Worley on Vimeo.
As you can see, the reflected white highlight is larger and more diffuse on some areas, and smaller and more focused in others.
I don't know if this has any practical application in games, or if it's too expensive for too little payoff, but if was certainly a fun problem to try to solve.
Next up: Zombies!
Now that I have a working rig with a skinned mesh, I've finally gotten down to pumping out some animation. It's not great, it's not finished, but it's something. So far all I've done is a rough walk and run, but I'm slowly getting back into the groove. Emphasis on slowly. (Also, Vimeo, in its infinite wisdom, appears to have enabled frame blend on its upload encoding, so the vids aren't great quality. shame.)
NaziWalk from Adric Worley on Vimeo.
NaziRun from Adric Worley on Vimeo.
To be perfectly honest, I'm quite disappointed with animation here at Sheridan. I haven't done any animation of note in about two years. Most of the later work in 2nd year was all lip-sync, and as I've said before, character animation does not come easily. Combine that with my still-developing character-drawing skills, and you end up with a lot of meh work. Third year was a bust, too. My action analysis was terrible because I spent so much time trying to keep up in all the other classes that animation kept getting pushed to the side (a common problem here), and my group film went similarly. I wish that we'd been given more opportunity to focus on doing animation, or at least have enough time outside of schoolwork to explore it more on our own. My friends can attest that the time I took out of class work to explore Maya took its toll on my marks. With any luck (and dedication), I'll be able to do more animating on my own once all this film stuff is done.
EDIT: I've written more about this overly-complex SpecPower shader in this post, where I realize a more efficient solution.
One of the options that caught my attention when I first started playing around with UDK's material editor was the Specular Power parameter. Specularity is essentially how shiny an object is. In reality, specular highlights are reflections of whatever is casting light. In CG, esp. for games, it's an approximation. The two control parameters given are Color and Power. Color is obvious, but the Power parameter is control over the spread of the highlight. Really shiny objects like polished metal have tight, bright highlights, while things like rough-textured plastics, unfinished wood, or other duller objects would have very wide, diffuse highlights. What first came to mind was how to control that across a surface? If you could control the SpecPower, you could simulate multiple material types without having to create and assign a new shader material for each material type. It took a few tries, but I think I have a basic working solution.
In addition to creating Diffuse, Specular Color, Bump, and Normal maps for a material, I worked out a way to make a Specular Power map. The way it works is it divides the texture into 4 color channels (RGBA) and assigns each one a specific specular power. It then adds each area back together, then divides the result by the sum of the original channels. Here's an image of this set up as a shader network in UDK:
The texture can't be applied directly to the Specular Power parameter because UDK sees each color channel as a value between 0 and 1, while the SpecPower parameter is a (relatively) unlimited number, and 1 creates a very very diffuse specular. By multiplying each channel by a fixed desired SpecPower, the artist can apply a range of specular intensities in the same material. Here's a quick example of the shader in action:
SpecPwr Shader Demo from Adric Worley on Vimeo.
As you can see, the reflected white highlight is larger and more diffuse on some areas, and smaller and more focused in others.
I don't know if this has any practical application in games, or if it's too expensive for too little payoff, but if was certainly a fun problem to try to solve.
Next up: Zombies!
Now that I have a working rig with a skinned mesh, I've finally gotten down to pumping out some animation. It's not great, it's not finished, but it's something. So far all I've done is a rough walk and run, but I'm slowly getting back into the groove. Emphasis on slowly. (Also, Vimeo, in its infinite wisdom, appears to have enabled frame blend on its upload encoding, so the vids aren't great quality. shame.)
NaziWalk from Adric Worley on Vimeo.
NaziRun from Adric Worley on Vimeo.
To be perfectly honest, I'm quite disappointed with animation here at Sheridan. I haven't done any animation of note in about two years. Most of the later work in 2nd year was all lip-sync, and as I've said before, character animation does not come easily. Combine that with my still-developing character-drawing skills, and you end up with a lot of meh work. Third year was a bust, too. My action analysis was terrible because I spent so much time trying to keep up in all the other classes that animation kept getting pushed to the side (a common problem here), and my group film went similarly. I wish that we'd been given more opportunity to focus on doing animation, or at least have enough time outside of schoolwork to explore it more on our own. My friends can attest that the time I took out of class work to explore Maya took its toll on my marks. With any luck (and dedication), I'll be able to do more animating on my own once all this film stuff is done.
EDIT: I've written more about this overly-complex SpecPower shader in this post, where I realize a more efficient solution.
Thursday, February 25, 2010
Exploratoring
Continuing in the vein of my previous few posts.... PROBLEM SOLVING!
Probably the most exciting part of solving problems for me (other than the thrill of finally fixing a tricky issue) is research. I'm a self-admitted information junkie, and I love learning new stuff. Anyone who knows me can attest that I spend a lot of time browsing for new techniques, cool tricks, or just stuff I want to know (I've gotten into a bad habit of reading Wikipedia articles on food when I'm hungry). One of the side effects of this is I've gotten reasonably good at targeting searches and finding elusive information. The sad reality is, though, that just because I'm looking for information doesn't mean that it's there to be found. This has been especially true in the case of Maya Character Sets and Trax information.
Probably the most exciting part of solving problems for me (other than the thrill of finally fixing a tricky issue) is research. I'm a self-admitted information junkie, and I love learning new stuff. Anyone who knows me can attest that I spend a lot of time browsing for new techniques, cool tricks, or just stuff I want to know (I've gotten into a bad habit of reading Wikipedia articles on food when I'm hungry). One of the side effects of this is I've gotten reasonably good at targeting searches and finding elusive information. The sad reality is, though, that just because I'm looking for information doesn't mean that it's there to be found. This has been especially true in the case of Maya Character Sets and Trax information.
Monday, February 22, 2010
Still alive...
The cake is a lie...
Just doing a quick post to keep this thing going. I don't have anything to show for the past two weeks... yet. I've been doing a lot of rigging work which is all very technical and not very visual. Long story short, I got my Nazi Grunt character fully rigged and weighted, which made me very happy. Then I exported him to the UDK for testing, and that did not.
Maya uses the Y-axis as its world-up, while UDK uses Z-up. I've been doing all my modeling and character prep in Z-up space, but the autorigger I've been using doesn't play nicely with Z-up, so I did all the rig setup in Y-up. Needless to say, that causes problems. Additionally, the autorigger adds a lot of extra bones to handle IK/FK arms, legs, and spines, and those get exported to UDK as a mass of crazy. Had to figure out how to pare it down to just what I need.
Technical Stuff
For those interested, here's how I solved these multiple problems:
1) I saved the whole rig to a new file, where I stripped the skeleton of everything except the smooth-bound joints. I then parented the floating joints (spline-IK spine) to the root spine joint.
2) I then exported a skin weights map to preserve all the weighting I'd done this weekend, then removed the mesh's smoothing skinning.
3) With the mesh and skeleton separate, I was able to rotate the mesh to orient correctly, and could freeze the rotation of the skeleton's root joint. This solved the issue where my animations played along the wrong axes in UDK. Previously, even with the controllers pointing correctly, the actual skinned bones were receiving translates/rotates along the wrong axes.
4) I smoothbound the rotated mesh to the skeleton and re-imported the skin weight maps. Because I have some mirrored UVs to save on texture memory, I had to re-paint some of the weights and mirror.
5) This file was saved, then imported into the file with the full rig. I deleted the mesh attached to the full rig, then parent/orient constrained each of the bound joints on the imported file to the rigged joints of the existing file.
This gives me a certain level of compartmentalization between the rig I'm animating versus the rig that's actually moving the mesh. I can now change around the controller mesh in various ways without affecting the bound skeleton and mesh. If, for example, the leg rig turns out to be something other than what i wanted, I can remove the control structure, create my own, and I don't have to worry about re-exporting a new version of the skinned mesh to the UDK or having to update any exported animation to account for new/deleted bones, or changed proportions.
The downside to all this is I've realized that I have to do this to Chester, too. Not as bad as having to figure it all from scratch again, tho.
Just doing a quick post to keep this thing going. I don't have anything to show for the past two weeks... yet. I've been doing a lot of rigging work which is all very technical and not very visual. Long story short, I got my Nazi Grunt character fully rigged and weighted, which made me very happy. Then I exported him to the UDK for testing, and that did not.
Maya uses the Y-axis as its world-up, while UDK uses Z-up. I've been doing all my modeling and character prep in Z-up space, but the autorigger I've been using doesn't play nicely with Z-up, so I did all the rig setup in Y-up. Needless to say, that causes problems. Additionally, the autorigger adds a lot of extra bones to handle IK/FK arms, legs, and spines, and those get exported to UDK as a mass of crazy. Had to figure out how to pare it down to just what I need.
Technical Stuff
For those interested, here's how I solved these multiple problems:
1) I saved the whole rig to a new file, where I stripped the skeleton of everything except the smooth-bound joints. I then parented the floating joints (spline-IK spine) to the root spine joint.
2) I then exported a skin weights map to preserve all the weighting I'd done this weekend, then removed the mesh's smoothing skinning.
3) With the mesh and skeleton separate, I was able to rotate the mesh to orient correctly, and could freeze the rotation of the skeleton's root joint. This solved the issue where my animations played along the wrong axes in UDK. Previously, even with the controllers pointing correctly, the actual skinned bones were receiving translates/rotates along the wrong axes.
4) I smoothbound the rotated mesh to the skeleton and re-imported the skin weight maps. Because I have some mirrored UVs to save on texture memory, I had to re-paint some of the weights and mirror.
5) This file was saved, then imported into the file with the full rig. I deleted the mesh attached to the full rig, then parent/orient constrained each of the bound joints on the imported file to the rigged joints of the existing file.
This gives me a certain level of compartmentalization between the rig I'm animating versus the rig that's actually moving the mesh. I can now change around the controller mesh in various ways without affecting the bound skeleton and mesh. If, for example, the leg rig turns out to be something other than what i wanted, I can remove the control structure, create my own, and I don't have to worry about re-exporting a new version of the skinned mesh to the UDK or having to update any exported animation to account for new/deleted bones, or changed proportions.
The downside to all this is I've realized that I have to do this to Chester, too. Not as bad as having to figure it all from scratch again, tho.
Subscribe to:
Posts (Atom)