markw

And another thing... I'm on a Mac here and A:M will not Embed nor Consolidate any sound file's that are used in a project. Can others confirm this? Is this normal? Should I A:M report this as well?

Humm, proxy sound files you say… Will have to experiment with that sometime and see what the effect on real-time playback is like. Just did a quick experiment and A:M will accept 8, 16 & 24bit WAV files. It's just the 32bit ones it refuses. A small detail perhaps to include in an update of the TechRef when that day comes? I must confess apart from "Keep a Secret" and some experimenting, I've not done much lip-sync. Apart from dialog, which has to be in there before animating, most any other sound I've always added later to the rendered movie in a video editing app.

I've just found that A:M only supports 16bit WAV files and not 32bit ones. This was after 10min of head scratch as to why it kept telling me I was trying to load an invalid file! I wonder are there technical reasons for A:M not handling any other depths or formats of sound files?

Thanks for the info fea_alba. I routinely have active projects baked up on Dropbox. Could I just email you the link to my segment when its ready for you to download from there.

That might be me... There are no built in Help files for us Mac people like there is in Windows We just have to look in the TechRef PDF. But the good news is that v17 now comes with A:M Answers built in Its early days yet for it but who knows, eventually we may not need the TechRef at all.

That's looking much better now. Yes, still more tweaking to be done but its getting there. Maybe look at the feat next as there's still some slipping going on and look at the hip null too. Hard to tell in wire-frame at that angle but it looks like it stops moving forward at one point (I could be wrong) but it shouldn't, in a normal walk it should always be moving forward.

Thanks Robert, another gem to add to the colection

Some of that body jitter seems to me because as one leg comes up, moves forward and then hits the ground the body dips forward and back twice in that one step. Most evident in the side view, with the constrained camera, giving a rather rapid woodpecker like motion to the upper body. When seen in perspective from the other camera, because of the speed of those dips forward, it makes the body seem to jitter. The constrained camera was my suggestion Rob, sorry! But I have found it helpful at times to have but would agree it would be very difficult to do all the animating from a constrained camera. Mostly I'm in Birdseye View in the Chor and the camera that I render from always has the final say. Forgive me Simon I maybe should have been clearer in the other thread where you asked.

Just a thought here, and forgive me if this is obvious but I've been known to forget this step some times! But after making any changes to particle systems, like deleting the sprites from the plane, did you re-bake the project? If not then it will still use the bake information it used the last time an ignore the changes you made. However I think you definitely have something strange going on as active particle systems shouldn't interfere with each other when rendering. Again, if you can, let Rob take a look at it...

The image with the flowers missing, was that rendered strait after the other one? and with the same render settings? I fear this maybe is something peculiar to your project, I'v been using particles as well and not had any problems so far. I'm sure if you can let Rob have a poke around in your project he will be able to help.

This is a good vid from Robert on doing a walk freehand in the Chor. http://www.hash.com/forums/index.php?s=&am...st&p=345732 Although its a robot the principles are much the same for all bipeds. Top view is useful for seeing if your character is still on track to its destination and I use Bird's Eye a lot too to check progress. But what can also help are "temporary" cameras that are constrained to aim at and move with the model so that you can always have a perfect side, back or front view if/when you need them.

I'm not sure I fully understand, sorry. Could you post some screen shots of what you are describing. I can find no 'Property' for baked particles. Group prop. to on? Which files did it say were missing?

Doh!! Embarrassed head in hand time Was sure I had set the camera to HD720 Sorry for the falls alarm

Is A:M supposed to automatically re-size the images in an image sequence when it imports them? The images were rendered out at 1280x720 but as soon as they get imported back into A:M they become 864x480 and so far I can find no way to stop this or chose what size the exported movie will be played at. I seem stuck with 864x480

Ouch! 1hr 30 per frame! I'v used particles in my contribution too but my slowest frames are around 10min from memory for a non stereo render. I'm soon to do a step render of the whole thing in stereo but I'm hoping the added stereo will only make it around 20min a frame at worst. As I understand it one of the main reasons for baking particles and dynamic constraints, is so we can use Netrender for rendering if we have more than one CPU core available to us. And at 1hr 30 a frame, I would recommend using Netrender (if you aren't already using it) to cut your overall render time down.

Love it :lol:

Yes Darkwing mine's a little over a year old I think and can boot in 64bit using the 6&4 keys. Never really noticed much performance difference doing the every day stuff on it so mostly leave it in 32bit mode. I was maybe hoping a 64bit AM would shave even more seconds off render times

Thanks for the clarification there Steffen, as a non programmer I have no idea what carbon calls in the middle layer are but I'll take your word for it that they're important As some newer Mac's boot in 64bit by default will A:M run OK?

Ah, thanks Rodney they're back And to prove they work this is what I was going to attach last time. My computer definitely thinks AM is not 64bit...

Are you sure that you dont have a 64bit version already? Macs are no longer sold with 32bit-cpus and like that I thought that more recent Mac-versions of A:M are 64bit... (this is only a guess and does not need to be true!) See you *Fuchur* Which is what got me thinking. Here's what System Profile has to say about the AM; 64-Bit (Intel) No On a side note, can we not upload attachments in this part of the forum? I see no buttons for it.

Just wondering if anyone can say if a 64bit version of A:M is likely in the future for us Mac people?

Hi Simon, Not sure if this is good news or bad, but I've just tried your project in 15j+ up to v17 on my Mac and I get no problems with the positions of the lights. They stay where I leave them. Maybe just try restarting the Mac and/or resetting AM first before doing a fresh install.

Have you turned on particles in the choreography you're intending to bake? If its not on then the bake option will be greyed out. If you are still adjusting timings and things I would wait on the baking front. Save it to the very last thing to do. When you bake particles, A:M will generate some new files, .par & .pai, which contain the particles rendering information. They will be made in the same location as the project file containing the choreography that you are baking. These new files and the project that generated them must remain together especially if you are using NetRender, it only loads projects containing choreography's and not the choreography files themselves. Netrender will assume the .par & .pai files are in the same location as the project loaded into it. I'v found it best to make a specific folder containing the project file solely for doing particle baking to stop things getting lost.