A while back, I picked up the book Introducing Character Animation with Blender from blender3d.org. I primarily bought it to support the blender foundation because I love using the software so much… but I finally got around to cracking it open.
Most of my blender knowledge comes from watching youtube videos. This approach is good because it provided me with a lot of practical modeling skills, but it doesn’t delve much into the intention of the features built into blender. I think that actually going through and reading the manual will be useful for me at this point.
I think I’ll combine this getting back to basics with the actual character design of “The Weirdo” for my video game project… kill two birds with one stone so to speak.
It’s been a little while since I did stuff in Blender. Here, I made a 16-pin IC. I tried to make the model fairly generic so that I can easily do larger or smaller chips. If you want to check out the model, I have it checked into github:
Continuing my efforts to fill in all the models needed to render the first Little Robots Script, I started on modeling a phone… in this case, my iPhone4.
I thought incorrectly that the simple shape of the phone would make the modeling go by pretty quickly… but it turns out that there is some trickyness involved with how you get the little buttons and indentations into the body itself. There’s also texturing complications. You want the screen to be a single rectangular texture so that when you animate, you don’t have to worry about strange artifacts involving the screen content being stretched or otherwise transformed.
On this model, I still need to add the speaker holes and interface jack at the bottom as well as the buttons on the side. I need to revisit the front surface though. I’d like to actually put a transparent layer over it just like the real thing… I’ll be able to easy texture that with smudges and blemishes.
Here’s what I have rendered in-scene…
The metal texturing still isn’t quite right. For some reason I’m getting strange textured reflections from the surface of the phone. You can see it toward the home button in the render. It looks like it’s reflecting the wall, but the stucco pattern is way too emphasized.
Adding to the list of random things on my desk, we have a pen and a piece of paper.
The piece of paper is about as trivial to model as you might thing. I decided to UV Map it so that I could have both a front and back side of the page (though you can’t see it here). It also means that the stuff on the page itself will deform properly if I decide to wrinkle or otherwise mess with the page.
The pen was trickier to model than I thought. There are some funny curves and you have to cinch the subdivision surfaces at the right places for them to look right. For some reason the label that I applied to the pen refuses to show up in this rendering. I’ll have to dig into that later.
The way you model cables in Blender involves is summarized with this video: Making a Cable in Blender.
The thing is, that tutorial was created using the older interface… and it’s a bit tough to find in the new one. After struggling with it a little bit… I came up with the cable you see to the right.
I can now begin to create lots and lots of cable… which is good because cables make the world go round!
Creating book covers, particularly when you don’t really care about how well the book will actually sell… is a lot of fun. For the first Little Robots animation, I need to come up with a *TON* of books…. here are the first two…
These are both hard cover books… I still have to build out a soft cover model as well as a Schaum’s outline style workbook model. I’m sure that the softcover and workbooks will be more challenging than one might think… Sure, you could model it like just a box… but unlike hard cover books, the covers of their lighter weight counterparts tend to lift up on their own… plus there’s the possibility of the covers kinking and creasing.
If you’d like to use any of these book covers in your own models.. or are just curious what the images I built for them look like… here you go! Click for larger version.
I designed this one last night at like 1am. It’s a pretty stoic design… and really was meant to be just the template image to use for future books. I ended up liking the way it came out… so It’ll probably get used in the actual animation.
This second book I took a little more time with. The image that you see on the front and back covers was taken with my iPhone. I had a couple of old 1GB DIMMs from my Mac Mini. I placed them side by side and snapped the image being careful not to have any company logos or names showing.
I need maybe 4 or 5 more tech related books to have laying around on my desk. Any ideas?
This weekend I went through and added a couple new models to my desk scene..
First off, I wanted to model out a computer. This is my rendition of a mac mini (older model). Right now it’s really just the basic shape and a little bit of texturing… but it’ll do. The power light is always on, even if it’s not plugged in. It occurred to me while I was modeling this, I have no real idea how to make lights switch on/off… this is probably something I need to look into.
Along with the computer, it seemed pretty obvious that I’d need a monitor of some kind. This is a pretty generic looking monitor. I took the basic shape/button layout from a Dell 17″ LCD but stretched it out a little to make it wide screen. At the moment, the buttons are all blank, but at some point in the future, I’ll add the UV mapping for a power switch, +, -, and source. The base isn’t very inspiring, but I didn’t really want to spend a great deal of time on it…
Here’s a real rendering with the new computer components. I still need to add cables, but in proper lighting both of these models look pretty good… you should be able to click for the full sized image.
… stays on my desk…
This image is just me showing off the new desk model that I created in blender. This is based on my actual desk layout at home… although the objects resting on the desk in this case are fictional. This is the first of many models necessary to bring about the scene described in a previous blog post… essentially where my first little robot will be born.
You aught to be able to click to get the original rendering. Probably the most complex bit of this rendering is the lighting. There’s a mix of yellowish artificial light coming from spotlights located behind the turret… and then a slightly blueish “natural” light from behind.
I took some time over the Labor Day weekend to finalize Seña’s eye rigging. As you can see from the image to the right, the rigging itself is made up of something like 25 bones. Crazy but awesome.
A particularly pleasing aspect of finishing this rig is, it satisfies all of the requirements that I set forth in my previous post about Eye Detail. This means that I wasn’t forced to compromise with the features I wanted… I was able to figure it all out.
While rigging the “eye petals” (the four sun shades around the outside of the eye), I ran into another peculiarity of blender‘s armature system. Let me describe the setup… The eye petals each have a vertex group (upper petal, lower petal, left petal, right petal) and each vertex group has an associated bone in the armature (they’re the largest ones in the image above). Whenever I’d rotate a petal, though, it’d deform in very peculiar ways. Below is a simple rig that reproduces the problem…
For the first say, 20 degrees of rotation everything looks fine. You’ll notice though as the bone is rotated, the box it rotates starts to get smaller and no longer seems to follow the track of rotation. Grrr… what’s causing that??!
Before I present the solution, I need to show you how the vertex groups are set up so that I can explain what it is we’re seeing here…
You can see that I have two vertex groups… “Upper Box” represents the box we’re trying to move and “All Boxes” is a group containing both the upper and lower box. “All Boxes” is associated with the parent bone (behind blue one) and “Upper box” is associated with only the box that we’re moving.
Because the upper box is being influenced by two different bones at the same time, their overlapping influence on the vertexes of the box causes the strange behavior. The solution is to remove the upper box from the “All Boxes” vertex group. Once I removed the overlap in bone influence everything works as expected.
A while back, I had posted about a strange rigging behavior that I was seeing. I’m not sure that the description that I was terribly useful… so I decided to make a couple animated gifs to help with the visuals…
Here you see what a proper rigging is supposed to look like. The block rotates with the rotation of the “Bone”. Now, The following image illustrates what I was looking at…
You can see here, the cube is actually moving faster than the rotation of the bone. The exaggerated motion caused all kinds of stuff to get out of alignment.
The way you associate the Armature or Skeleton to an object is you set the Armature as the “Parent” of the object. In this case, the object is the cube. You do this by simply selecting the cube, then the Armature and hitting CTRL-P (You can also parent by going through the menus).
When I created the simplified case of the single bone and a single cube, it worked just fine. On a hunch, I decided to un-parent then re-parent the object and armature… and voiala! the problem was reproduced. It turns out that in Blender 2.5, you’re not actually “parenting” you’re setting a modifier on the object… so clearing the object’s parent does NOT clear its relationship with the armature. When you then re-parent the two, you create a SECOND modifier between the object and the armature, so any changes to the armature are magnified 2x… which is the behavior you see in the 2nd image.
Okay. Well, this is all well and dandy, but if you can’t un-parent, how do you get rid of the armature to object relationship? It ends up in the object modifiers tab. Here’s what it looks like if you’ve got an Armature associated multiple times with an object…So… all you really have to do at this point is figure out which of the two modifiers you want and X the other one(s).
In the situation with my aperture, I had created 3 modifiers.. so the pose was affecting the object three times as fast.