Messages - thecolclough

there's also a master switch buried in the menus... in v1.0 you go View > Preferences, which brings up a dialogue, and then in the File Output box at the bottom there's a checkbox marked 'Shadows' - make sure that's set to on. i think it's the same path if you're using an earlier version.

not really sure why that File Output stuff is under the View menu and not the Render one.

...something that could always be improved (especially amongst Anim8or users, as we're so caught up with making decent looking characters that we don't think about it) is the camerawork, making the camera move in a way that feels natural and stuff.

that's certainly true. i think the camerawork in Swobu #1 works fairly well, as the movements are relatively subtle and are close to how a handheld camera could move in real life. to be honest, i've shot live footage that had much messier movement than that! but i've seen plenty of other CGI projects where the camera flits and floats around as if it doesn't weigh anything and isn't attached to anything, which can seriously detract from the realism of the videos. i guess the bigger and more complex the video you're making, the more this ends up being an issue you need to be aware of.

a good-quality real-life camera will weigh at least a kilo or two, with higher-end cinema cameras clocking in at several kilos. when you're setting up a shot, it's always good practice to think 'how heavy is my camera? what's it attached to? how will that let it move?' if it's on a tripod then it can't move at all (only rotate); if it's on a dolly track then it can usually only move in a straight line; if you're going for a big swooping aerial shot then you should think about the physics of how a crane works or how a helicopter flies. handheld shots give you all sorts of flexibility, but it's still worth stopping to think how big your virtual 'cameraman' is relative to the subject, and what s/he's having to do with their body to get the camera in position - are they crouching down, standing on tiptoes, or...? in this video, for example, i'd guess one of two things: either the cameraman is another orc, and he's standing on a box or something to give him a bit of height relative to Swobu, or he's human and is just taller.

when your main interest is in the character animation, this sort of thing can seem like a bit of a faff, or even an unwelcome distraction, but it's worth taking the effort to get your camerawork right as it adds a lot to the overall effect of your on-screen storytelling.

the main useful point of difference between f and F is 'all non-hidden elements' vs 'all selected elements'; i'd argue that both commands should behave the same apart from that - i.e. they should affect the same view(s). i've been frustrated before when i wanted to frame one view and found all four changed at once, and i can't remember if i've ever actually wanted to frame all views simultaneously (although i guess others might - open question to the floor?) so i'd vote option 2.

i'd say no, it shouldn't. since the camera's field of view is supposed to be determined by its position, orientation and FOV settings, there shouldn't be any other way to affect what it shows, especially not something like the 'frame' command which can have such wildly variable results depending what's in the scene.

Steve - when Fefe mentioned enabling the depth channel, i think he's talking about the option to output the depth channel as a separate render, which is available for stills but not for movies (per the attached screenshot). i've wondered about this discrepancy before too.

you can simulate it by doing multiple render passes for different elements and then applying artificial focal blur when you recombine the renders in GIMP or Photoshop or similar (i think there's a tutorial floating around somewhere), but it's a fiddly process, especially if you're trying to do video.

i just realised something... clever clogs here basically forgot i had this thread open, and never posted any images from my new main logo. duh. well, better late than never, i guess...

i went off up a creative dead end at first, trying and failing to design something clockwork-looking, which resulted in the horrible cluttered mess you can see in the image below.

the final draft has a bunch of floating segments which circle around and gradually fit together into a complete ring with the text in front - the server won't let me post with all of the attachments at once, so the finished stills will have to follow on another post. stay tuned.

the video runs 10 seconds in total (although i often use a cut-down version on shorter projects), and was rendered as a PNG sequence using Scanline in v1.0 Beta 2 - if i remember correctly - over the course of... well, quite a few hours

The cans are seperate objects and when I moved them at the frame whereThe action happens, they sort of started moving in the starting frames.

I thought I had made a keyframe when the action happens to make sure they would start moving there, but I had to do a clumsy job of moving them into their place where they werent supposed to move. Thats why they move a little before he hits them.

whenever you start keying an element's position or orientation, another key is automatically added at frame 0. sometimes this is useful, and sometimes it isn't. in this case, that extra key is what's causing your unwanted movement (i sort of understand the reasons why it does that, but it's a bit complicated; Steve could explain better). if you want the element to stay still at the beginning of the scene, you can do that by deleting the auto-added key at frame 0; the program will then keep the element at the position (or orientation, or whatever) specified by the first key it can find, even if that key doesn't appear until hundreds of frames later.

nice video overall though - looks like your animation career is off to a good start