Eric Chadwick has been working very hard on the Polycount Wiki, and has just released a massive amount of information about Normal Mapping that pretty much covers all the tech you need to know.
When working with lots of rigs you want to automate as much as possible, especially as they become more complex. I’m working with Character Studio Biped as a base, and then adding custom roll/twist bones on top of this, so it made sense to take the time out to develop a script that could connect up several rollbones in a rig so that I’d get the same results every time. The first and most obvious thing to do was to create these extra bones using script, so I wrote a function called BuildNewBone that builds a new bone between two points and links it to a parent.
The next step was to connect these new bones to the Biped system so that they would behave in the way I wanted, rotating based on the underlying rig. Biped is a relativley closed system, so to query the rotation of Biped bones you need to expose the internal values using expose transform helpers. I set these up via script, so that as well as always having the same name I can position them on screen and even set their colour for easy identification.
Wiring rollbones in max uses the paramwire.connect command, and this takes three variables: the driving or controller bone (in the case of Biped I use the aforementioned Expose Transform Helper as the driver), the bone you want to affect, and a control expression which controls the amount of twisting.
With twist bones like the forearm twist you will most likely want to affect them on the X axis only so that as the hand rotates the rollbone will twist around the forearm bone. Bones like a neck roll however will roll in all three axis. Also in the case of the twist bones like the upper arm twist bone which is parented to the clavicle then you require it to follow the driver bone (in this case the upper arm) 100% in the Y and Z axis.
What I was finding was that I was calling the paramwire command several dozen times to link up an entire skeleton, sometimes calling it 3 times in a row with the same rollbones just to specify a different axis each time.
To makes thing easier for myself, I ended up writing a function to wire rollbones where I could simplify this to a single call:
-- Wire up a Local rotation rollbone given a bone to roll, a controller object and a roll amount per axis.
-- If any of x, y or z are 0, skip the wiring for that axis (inherits parent rotation)
fn wireRoll theRollbone theDriver xr yr zr = (
if xr != 0 then
(
controlExp = "Local_Euler_X*" + (xr as string)
paramWire.connect theDriver.baseObject[#Local_Euler_X] theRollBone.rotation.controller[#X_Rotation] controlexp
)
if yr != 0 then
(
controlExp = “Local_Euler_Y*” + (yr as string)
paramWire.connect theDriver.baseObject[#Local_Euler_Y] theRollBone.rotation.controller[#Y_Rotation] controlexp
)
if zr != 0 then
(
controlExp = “Local_Euler_Z*” + (zr as string)
paramWire.connect theDriver.baseObject[#Local_Euler_Z] theRollBone.rotation.controller[#Z_Rotation] controlexp
)
)
So with a calf roll that is parented to the calf bone, I want it to make it rotate 50% in the X axis as the foot rotates in the X axis:
wireRoll $'L Calf Roll' $eTM_LFoot 0.5 0 0
I’ve had the EEE PC for a few weeks now, and I’m writing this in the pub (no wifi signal so I can’t browse the net).
It’s an exceptional little machine. It’s tiny, dinky even - which is both it’s greatest strength and weakness. The keyboard is very small, but more on that later. It’s so light that I hardly notice it in my bag, whereas my old Toshiba was like carrying round a couple of bricks.
Although the screen is small (800 x 480), it’s fine for most purposes (I’d bought it purely as a thin client/dumb terminal to connect to the internet. Of course this pub has no wifi). By most purposes, I mean using the internet, and that means Firefox. By running Firefox in full screen it’s perfectly usable.
If I wanted a serious laptop, I’d have bought a serious laptop, however I made the conscious decision to buy the EEE PC because it wasn’t an expensive, powerful computer. Although I’m a computer artist, if I wanted to do any art I’d not want to work on ANY laptop, especially since I have a 24 inch monitor on my powerful iMac. Over the last year I’ve moved most of my computing software to Google - email, RSS reading, document editing, calendar et al., so all a I wanted was Firefox, a screen and a keyboard.
Since there is no wifi here, I’ve switched off the Wifi mode (Function key+F2), which seems to make a huge difference to the battery life - indeed the battery life is my second biggest issue after the keyboard size. I get about 2.5 hours withWiFi enabled, and just over 3 hours with it disabled.
The keyboard is what takes the most getting used to. It’s not ultra tiny, and it’s certainly much more usable than the soft keyboard on my iPod touch. It’s comparable in size to the iGo Stowaway Bluetooth keyboard, and to be perfectly honest, after 2 to 3 minutes of typing each time I use it my hands adjust. It’s similar to the switch I had to make when I switched to playing guitar after playing bass for a few hours. The biggest bugbear is actually the arrow keys, which are placed so close to the right shift that I continually hit the up arrow when I try to use shift. Again, after a few minutes this becomes less of an issue.
I’m writing this is Google Docs - but as I mentioned I have no Wi-Fi here. Thankfully Google have brought their Google Gears technology to Docs, which means I can create new documents and edit existing ones offline. When I get home (or find any network signal), the documents will sync again. Google Reader also works fantastically well with no network thanks to Gears. I’d been away for a few days, so I’d built up 600-700 unread feed items. Google Gears downloaded all these and I was then able to read them offline.
If only Google mail had an offline mode…
I’ll get around to installing a load of rubbish on it, swearing at Linux, then reverting it back to a base install with 1 week*.
*Edit: 2 days.
A small post to say that I managed to write some fairy nice code that links my joysticks to bones, allowing me to specify angle limits. It all works as planned in my tests at home, but breaks on certain real world hierarchies.
This is something I need to figure out before I post a breakdown of it, but for those interested, the code is available here:
Google has some of the greatest services around, though I wish they’d bought Flickr instead of what they are doing with Picasa web albums.
I’m also surprised that they are missing a Google Address Manager too - not for email addresses, but for real addresses. In Google Calendar, I’ve created a Birthdays calendar. I’ve shared that with several family members so we can all add and keep tracks of family birthdays. Imagine the same features in an addressbook, available from and computer or handheld device. Want to send a postcard to Auty Mable while you are in Tokyo?
Group addresses as Public, Private, Friends, Family.
Create new groups, and assign viewing and editing privileges to other google users.
I think a lot of 3D artists overlook the power that scripting with their 3D application provides them.
“I’m an artist - so why do I care about scripting?” I hear you cry. Scripts are great for automating repetitive tasks, and you don’t need to be a superb programmer to take advantage of them. That being said, if you understand a few of the basic aspects of programming like loops and variables then scripting becomes even more powerful.
I predominantly use 3d Studio Max at work (along with Silo for modelling), and I’ve found that maxscript is relatively easy to learn. I’m not a Maya user, but I understand that it’s scripting language, Mel, is fantastic.
How about some examples of where scripting is useful?
I know that all the characters I build in my current project have the same bones, so rather than creating them from scratch each time, I have a script that loads them from an external file. After the bones are loaded, it creates 2 selection sets - 1 for all the bones (but no nubs), and another set with a drastically reduced bone list for the LOD model (no fingers, toes, helper bones or face bones for example). The script finds all the components that need a skin modifier applied, applies it and assigns the correct bone set (thats the benefit of a sensible naming convention for you).
I like all my renders to look the same, so I’ve written a render script - it loads a scene with my preferred lights, floor and camera, sets the background colour of the scene to be neutral and changes the lighting tint. It selects the camera, sets the output size, grabs the name of the model from the max filename so that it can name the image, then renders and saves the image to the same folder as the model. It also renders Front, Back and 3/4 views.
Sound useful? How about a batch script? It loads a list of models in turn and executes another script. So if I need to render out all my work, I just point my batch script at my models and tell it to execute my render script - then I can bugger off for a coffee, or leave it running overnight.
Setting up all your shaders? Press a button and maxscript converts all my max materials to shaders, with all the shader values set to our correct defaults.
So where do you start?
The best thing to do is to pick a simple task and try to script it. I learned to script not by doing abstract examples, but by just grabbing the bull by the horns and trying to write something useful. But where can I START? The first step?
3DSMax has a tool called the Maxscript Listener, which records almost everything you do in max. This is usually my first step - I open the listener, then I perform the entire task manually. The listener records all the steps (usually, sometimes the listener has selective hearing), and I can simply copy and paste them to a new script document where I can then edit until I’m content.
It’s worth mentioning that not just 3d applications that can have their workflow improved by scripts - Photoshop is a good example of a 2d package that allows you to create actions to automate repetitive actions - such as resizing and sharpening an entire folder of textures.
Resources:
These are a few things I could think of to help you along the way.
The component input on our TV is mixing the colours up - I’d noticed this when I got my Xbox360, but since I was connecting it via VGA, I wasn’t that bothered. Then I realised that when I pick up a Wii, I’ll be connecting that via component, and since I’d paid £1000 for the TV, it bloody better work, so an Engineer was dispatched.
This is when I realised that the guy sent to fix my TV didn’t see the difference between a composite and a component connection. Then I remembered someone posing a similar question on an art forum. Could it really be that hard to understand? I explained it to the TV guy, then thought “Hmm, thats was easy, and might make a useful post…”
Lots of people will have consoles that aren’t displaying their games as well as they could be, so I’ve written this to try to help.
Firstly, the most simple thing I can do is just list te connections in order of quality
The most simple thing you can do is look at your TV to see what connections it accepts, and then you connect your console using an appropriate cable. If you’ve simply read this far and done that, you’ve probably got the best connection you can get. If you want to know WHY some connections are better than others, then read on…
So why are some better than others? It’s really all down to compression, and a lot of that has it roots in television broadcasting.
A video signal contains quite a lot of information - you are sending 50 or so different images every second. These are made up of 3 signals: Red, Green and Blue. With connections like VGA, DVI and HDMI you are sending just that - the RGB signal (along with other information, such as sync rates and perhaps digital audio). HDMI and DVI are both digital signals, which gives you best quality picture you can have since the signal is pure and unaltered.
The VGA connection also sends an RGB signal, however it gets converted to an analogue signal, then back to digital, so you have already introduced a conversion, and therefore you can lose a little clarity.
However, this is a lot of information to transmit, especially over the airwaves (and these signals have their root in TV broadcasting), so over time various methods of compression were used to be able to broadcast them more effectively. The signals get compressed to a faster method for transmission, and then they get reassembled when they are received.
Component, which has a red, a green and a blue cable doesn’t actually carry a pure RGB signal, which is pretty misleading. The Green cable carries a black and white signal, and the Red and Blue cables carry a mix of the colour. The signal gets converted to this efficient format, is transmitted along the cable and then it gets reassembled at the other end. It looks very good, but not quite as good as a pure RGB signal.
Svideo takes the same approach, but goes one step further with the two colour signals - it combines then into one, leaving you with one colour signal and one black and white signal, which is yet another step down, but it is still better than composite…
Composite is the next step down in quality, because it combines all the video signal into one wire (usually yellow). The other two cables (Red and White) carry left and right audio. Yup, 2 cables for audio and one for the picture.
The worst of the lot is RF/Coaxial which hasn’t been on a console for years, would still find it is the default on your SNES or Megadrive. It takes all that video information, and all the audio and compresses it into one tiny cable. This is also the same system most televisions have used for years.
Finally RGB SCART, mainly used only in Europe. I left it to the end cos it throws a bit of a spanner in the works depending on your TV. SCART is type of connector that allows different signals to be sent across it - composite, svideo, RGB and stereo sound. So in theory it should be better than component since it transmits RGB, and it is on standard definition TVs, but not on Hi-Def.