Moho Forum

Hey LM!

I need some reply on this

my client will give me an answer in 1 week or 2 :
will we use moho / mac for that 5 month prod ?
I added many scripts as good workarounds so finally i reduce the number of problems, but actually

the worth things are :
- the lack of audio playback to tweak animation (audio is not really usable under osX once the scene has some animation)
- general slowness (same cause different effect)
- the great "lock" bone feature adds extra keyframes when u tweak anim and
- when the character doesn't move the locked bone is jiggling/vibrating like a bee !!!!???(very funny but it didn't make laugh my client hahaha)

I think my scripts fixed the other limitations but if you find other please post them here

here is an example
about the locked bone vibration :

http://animatic.no-ip.com/pub/dev/moho/ ... s_bug.moho

see the locked foot....
there is no kframe, only a lock, and it's moving!

best regards
Julien

When I have tried the locked bone, I have also experienced the same bone vibrating/shaking that you have illustrated. I have yet to get the bone lock to work properly - or how I perceive it should work.

I have had the same problem. I found it helps a little setting rotational limits on the bones.

Let's see if I can answer these:

1. Audio playback and general slowness. This is not the fault of the audio - the audio is just slowing down to match the video. There are some things you can do to speed up playback - take a look here:

http://www.lostmarble.com/forum/viewtopic.php?t=935

If you're working on a large, complex animation, it really makes a huge difference to turn off layers you don't need. For example, if you're animating facial features, then turn off background layers, particle effect layers, unrelated characters, etc. If you have the minimum number of layers visible for what you're working on, playback will definitely be smoother.

Also, we've done some work to speed up playback for the next update. Hopefully this will help.

Finally, performance on the Mac is just not as fast as other systems. Because of the various visual effects in OS X, it makes MOho's drawing go through all kinds of extra layers of operating system code to get to the screen. This makes for cute visual effects, but not efficient display. If you can use Moho on a Windows system, you'll see the framerates jump dramatically. (An on some Linux systems it runs even faster.)

2. Extra keyframes with bone locking. Moho intentionally adds an extra keyframe when bone is locked or unlocked. Think of it like this: if your character is squatting down with a locked foot, and you unlock the foot, the leg would spring straight out. Moho adds an extra keyframe here to the entire leg chain so that when the foot is unlocked, the leg has a keyframe to tell it to stay where it is at that moment.

You can, however, turn off this feature. Go to the Moho Preferences dialog and turn off "Auto-assist with bone locking keyframes".

3. Locked bone vibration. I don't know if it was you who brought this up recently, but someone else was having trouble here too. We've been working on the IK solver to get rid of the vibrations, and this will be fixed in the next update. I tested the file you uploaded with the current development version of Moho, and the vibration is gone.

Hey LM

Playback/vibration:
i can't wait to see the new version!
It would be really cool if i could show it to my client within our next deadline (1 or 2 weeks), but i'd understand if that's not possible...
(You must be thinking "well why don't u work under windows or linux" ..i know , but i cannot change the client on this choice...)

turn off "Auto-assist with bone locking keyframes".

Great! I didn't notice that one...

It's really a pleasure to work with a so reactive developper
Thank you very much

Julien

about audio playback,

i think adding a little script with optimal setting for smooth playback would help to convince / not discourage newbies like me...

Could we also think of an enhanced 'build preview' function , customised for synchro work

janimatic wrote:(You must be thinking "well why don't u work under windows or linux" ..i know , but i cannot change the client on this choice...)

No, I'm not thinking that - I understand that for one reason or another, everyone has their platform of choice, and it's not always an option to switch. That's why Moho is available for Windows, Mac, and Linux.

What I don't understand is why the client cares? If they're hiring you to produce an animation, why do they care what kind of computer you use? Unless of course you're using their computers.

janimatic wrote:Could we also think of an enhanced 'build preview' function , customised for synchro work

I'm not sure what you mean here - could you be more specific about what this feature would do?

And yes, the update should be ready in a week or two. We're trying to get in a couple more things, but it's getting close. If you don't see the update by your deadline, contact us and we can get you a pre-release build if that would help.

Janimatic - this one I haven't tried, but might help on the sound. It might be possible to decrease the overhead by downsampling the audio file as much as possible. If it's only a reference, you could drop it down to 8 bit mono 11kHz (it'll sound like crap, but do the job), a would probably smooth things a bit. Way back in the old days when I was trying to use a 486 in my recording studio, I found that 48kHz stereo files just didn't worked, 44.1 didn't jitter and skip only if nothing else was happening on the computer, and 32k was always fine. But even 48k would work if the file was mono. Downsampling drastically cuts down on a lot of processing and passing data to the OS. The same should go for using uncompressed vs. compressed files, decompressing takes more work.

LM - I know the real time rendering is pretty dynamic, but wouldn't it be possible to have some sort of "pre-render in memory" mode,maybe running in the background, kinda like After Effects? Not a full export type render, but just a memory cache of what you would normally see while you are working. Even if it wasn't that long, it would be nice to see that 10 seconds you are working on dead on without having to export. Or, as a lesser alternative, a "preview" export mode that just exports exactly what you would se on the screen. Might help in the interim.
Just a thought.

About the audio. Like 7feet said, 32kHz and make it Mono, everything runs smoothly... and don't use MP3s, i find they hog alot of CPU usage even though they claim to be "Compressed." So .WAV all the way!

cribble wrote:About the audio. Like 7feet said, 32kHz and make it Mono, everything runs smoothly... and don't use MP3s, i find they hog alot of CPU usage even though they claim to be "Compressed." So .WAV all the way!

Yes, I believe that they require more cpu because they have to be uncompressed on the fly, vs. a wav file that is not compressed.

Lost Marble wrote:

If you're working on a large, complex animation, it really makes a huge difference to turn off layers you don't need. For example, if you're animating facial features, then turn off background layers, particle effect layers, unrelated characters, etc. If you have the minimum number of layers visible for what you're working on, playback will definitely be smoother.

The short, 7 second animation I made (Busy LIttle Bees) ( http://www.lostmarble.com/forum/viewtopic.php?t=1436 ) with a frame rate of 24fps had lots of elements and camera movements in it. With all layers on & with sound on it was plugging along at play preview mode of 4 fps. With sound off, still 4fps. The fastest I could ever get it to go was 17 fps - this is with just the bones layer moving. Still too slow.
Doing this type of animation with lots of elements in "3D" mode seemed to really bog things down.
I am using a new, fairly fast Window´s computer with a good video card.
Using "frame skipping" is not really viable, because I want to see how the sound matches with the movement in the animation.

yes

LM, your suggestions for playback are good but not not enough.
I think we need some c++ function for that :

Depending on project's start/end frames (or start/end passed as function's args)

>ram preview with audio would do it
(I think of it as a image seq. player software i wrote a long ago in c++ [Qt] using openGL textures loaded in ram... requieres a lot of ram but it ensures true framerate I'll see if i still have the source)

>audio conversion to mono 8khz/8bit could be done internally on disk cach once for all (except the file out rendering)

>The audio could start at any frame
(actually when you render a file starting at frame 100 it offset the audio to start at frame 100 instead of using audio file from frame 100 !)

>all the others LM suggestions should be put in a lua script called "preview" (user's options restored when preview is stopped)
>Fast Buffer
>Allow frame skipping
>main window size
>close timeline
>hide unselected layers

> finally could we add an option to turn of the audio pitch? It's even worth when the playback is to slow to have the audio pitch changed

thank you!

unfortunately,

i had a disk crash and lost the source code of my Qt_GLplayer,
but anyway i don't like Qt anymore cause of their license price,
and it could be done easily with wx (it was very simple sequence image loader in openGL texture).
But i dunno if that's a good idea to use openGL on mac except if my cleint buy the latest NVidia card for mac (it could be a good option)
I guess you know that stuff anyway...