Neil - all messages by user

2011/1/10 13:09:01
Can lip-sync be made more precise? Kaynine wrote:
As I watched it, it occurred to me that the automatic lip-sync, which is such a useful feature, really does need to be made more controllable and precise. Chuckles' movie would benefit enormously if the lip movements at least stopped and started when the speech was heard. As things stand at the moment, he would not have had enough control to make this happen.

I'm afraid I must respectfully disagree with you here, Kaynine. As rwtread01 pointed out, the controls do exist to switch off lip-syncing when it's not required. This will prevent the character from 'accidentally speaking' the music or other background noises. These talk and shush events can be roughly generated in real-time and then tweaked in the timeline afterwards to better effect. I do agree that the process can be much improved, however. We are taking steps to make it easier and give the user more control.

Kaynine wrote:
I've encountered this problem myself in my own simple experiments, so I'd seriously suggest that tightening this feature of Muvizu be made a priority. Once this is done, it will make it much more possible for users to create quite complex animations involving dialogues, arguments, monologues etc. in which the mouths aren't flapping around during silence, or remaining shut during speech.

As I recall, the biggest problem you had was with how we use a single dialogue track that is shared across every character. I'd promised that we would address the issue and while it's not something we've been able to release yet, we have been actively working on it. I'm hopeful we can talk more about it once we've completed our upgrade to the latest Unreal Engine.

ziggy72 wrote:
Also, you can just fake it - record yourself speaking the lines of a song (without any music, and as in- time as possible) and use that to animate the lip sync, then overdub the actual music track later. Looks better, I think.

This is something that you can do within Muvizu, without needing to overdub afterwards. Load your spoken audio track into Muvizu as the character dialogue (Prepare dialogue -> Audio), but set the volume to zero. Then, load the music audio track into Muvizu as a background track (Prepare audio -> Background). When you play or record your movie, the character will lip-sync to the spoken track, but you'll hear the music track.

Dreeko wrote:
...And a neutral face option for when characters are not speaking

A neutral face is quite hard to do for a dragon. We'd need to model it, texture it, animate it, blah blah blah. :p

But seriously, neutral moods and facial animation are also on our roadmap. Honest.
2011/1/7 13:33:23
xtranormal no longer free... FurryCakes wrote:
I would love to know what improvements we end-users can expect to see when these updates have been made.

For the most part, the changes will be "under the hood", so there likely won't be any immediately obvious new features or other improvements. It does enable us to start working on a whole raft of things that wouldn't have been possible with the older engine, however.

For a brief rundown of some of the things we're considering once the update is complete, have a read of our latest news post:
2011/1/6 10:00:58
better way to move characters ukBerty wrote:
On a 32bit OS you basically get 3GB addressable RAM, regardless of how much RAM is in the box (as long as there's more than 3GB). As far as I understand the OS will allocate 2GB of RAM to Muvizu, but if other applications and Windows uses more than 1GB RAM then some of this 2GB pool will be swapped to disk. This is what slows the application down (along with processor and graphics speeds).

On a 8 GB box, I would have thought that Windows 64 would allocate the full 2GB to the 32bit Muvizu as before and only swap if other apps and Windows used more than 6GB.

This is correct. The biggest advantage of a 64-bit PC is that the system as a whole can support more RAM, and can therefore support more applications running at once without paging it to disk.

As Emily said, Muvizu works great on Windows 7 64-bit. That's how I use it at home, and many of our in-house testers use it.
2011/1/5 15:37:30
better way to move characters ukBerty wrote:
However I have a question. What is Muvizu memory. Mine keeps filling up. If I have a 64 bit machine with 12GB RAM do I get more Muvizu memory, or is it capped regardless of the RAM you have. I may be about to waste a lot of money.

The current version of Muvizu that is available is a 32-bit application, so it's limited by the operating system to around 2Gb. Adding more memory to this setup is going to be a waste of money. However, with the engine upgrade that we're currently busy working on, we're hoping to produce a 64-bit version which won't have this limit on PCs running 64-bit Windows. On those machines, more memory will certainly help.
2010/12/31 13:37:12
character actions We did try to address it for the last release so that you can perform any animation while sitting OR standing, but there were technical problems which meant we had to leave it until after the Unreal Engine upgrade. Ironically, the problem is a side-effect of how freakmoomin and the other animators have produced the animations, but it's us coders who seem to be bearing the brunt of it.

But yeah, it's not very user friendly and we're sorry about that. A fix is in the pipeline.
2010/12/17 15:22:09
puppeteering or manual animation Dreeko wrote:
I'm sure the devs have it on that andrex toilet roll of a list they are working from!

That's a scarily accurate description of our todo list.
2010/12/10 12:52:35
New Tutorial Vids toonarama wrote:
I know i have had similar problems and for me a "sensible view" could be to be able to move to the same view as a selected camera?

I tend to use the scene window then select a character then use "M" or "L" (I think)

It's not quite what you're after, but you can also right-click a camera's view in the camera window and your viewpoint will move to that camera.
2010/12/10 12:09:43
New Tutorial Vids chuckles wrote:
Is there a way to make the screen display go back to a sensible view?

Slightly off-topic for this thread, but hey, I'll roll with it.

Could you define "sensible view"? It seems a bit arbitrary.
edited by Neil on 10/12/2010
2010/12/7 12:26:24
Logging in It's a known bug.
2010/12/6 11:50:26
Head movement and smoothing Dreeko wrote:
Don't worry about the dragon.
We're holding out for a tap dancing octopus now!
With a twirling bow tie (obviously)

2010/12/6 11:48:44
Christmas Muvizu laptop glasgowjim wrote:
at least 2GB of RAM and a dedicated graphics chip with at least 512MB of ram

I'd suggest at least 4Gb of RAM, and more if you can get it as Muvizu is quite RAM-hungry with complex scenes. The next release of Muvizu will offer support for 64-bit OSes, so it'll finally have access to more than 2Gb.

Good advice on the graphics chip, Jim. The "integrated graphics" chips are usually dreadful, but some of the newer laptops have a switch that toggles between a low-power "integrated" chip and a souped-up, power-hungry "games" chip which could be a great feature if you want to use it for non-graphics work without draining the battery.
2010/12/6 11:37:00
What actions would Muvizuers like to have? freakmoomin wrote:
cuddle and kiss
some explosion flying through the air death type animations
poison choke death

Is anyone else scared by what sort of video would need this sequence of animations?
2010/12/6 11:29:18
bleeding edge beta and things that made me go hmmn ziggy72 wrote:
Hang on, been using the new version, and a familiar problem appreared again - I moved a piece of scenery, it hit another bit of scenery which moved, and brought my entire set down. The bits of set were all locked - am I to understand 'locked' doesn't mean it's actually locked, just...what? My understanding is that locked would mean unmovable, uneditable, and, you know, locked, so it can't be affected by anything else you're doing. I build complex sets, I need to be able to have stuff stay where I left it - could you make lock actually lock the buggers down properly? Thankyou.

Locked items shouldn't be moved by collisions, so this is a bug. I was hoping to be able to get back to you today with a proper answer about this, but unfortunately the developers responsible for this part of Muvizu are on holiday and/or lost in the snow. I'll let them know about it however and hopefully there'll be a fix for it in the next release.

ziggy72 wrote:
Also, thankyou for adding the keyboard shortcuts to the zoom buttons in the timeline window, just as you said you would. You make me hopeful that the lock will get sorted too

You're welcome. If there's anything else you'd like to see added, simply follow Dreeko's lead and make a hilarious video outlining the issue for us all to see.

ziggy72 wrote:
And for goodness sakes, give Dreeko his dragon! I think he's earned it! Applause

We're working on it, but we need to model it, texture it, animate it, make attachments for it, etc.
2010/12/6 11:15:39
Delete one block, All are gone. We really haven't designed it or even committed to it yet, so anything I say here is purely speculative, but by waypoints I mean something like a system of drawing a movement path by placing markers on the ground and instructing the character to walk to them over a defined period of time. The markers can then be moved and edited.
2010/12/6 11:09:54
How to rotate (roll) camera? It's been moved to the "Prepare camera movement" dialog. Hope that helps.
2010/12/6 10:54:06
Head movement and smoothing Ok, fine!!! You can have a slider to adjust the smoothing / speed of the head movement in the next release!!! But it's gonna impact our dragon development schedule! :p
2010/12/3 17:13:34
Delete one block, All are gone. It seems there's been a misunderstanding. The behaviour you're seeing is correct, and not a bug. We discussed it in this thread...

In response to Dreeko's question about it, I said...

Neil wrote:
Speaking to CrazyDave, it seems the old behaviour (that you liked) was a bug, and the new behaviour (that you dislike) is correct. Ummm... I don't really know what else to... ooh look, a bee!

Jamie summed it up in a later comment:

Jamie wrote:
This type of movement, where the system basically assumes the correct movement path to go between 2 blocks is bad practice and can lead to unpredictable results. There may be a more elegant solution to this situation, but that will be some time away, at least until the Unreal engine has been updated.

The behaviour that you're expecting is currently not possible, but will hopefully be addressed in a later release, probably if/when we do a waypoint movement system.
2010/12/3 12:09:11
AZERTY keyboard Hi, Vilghost. We do plan on eventually adding key remapping to Muvizu, but it's not something we're currently working on so it's likely to be quite a while before we get there.

In the meantime, you can edit the config files to manually change the key mappings to something you're more comfortable with.

Find a file called "MuvizuInput.ini"; it should be in the "C:\Program Files\Muvizu\MuvizuGame\Config" folder, or something similar. Open the file in notepad or some other editor, and find these lines:

    • Bindings=(Name="A",Command="Axis aStrafe Speed=-1.0 | Axis aActorStrafe Speed=-1.0", bIgnoreCtrl=True)

    • Bindings=(Name="W",Command="Axis aForward Speed=1.0 | Axis aActorForward Speed=1.0", bIgnoreCtrl=True)

    • Bindings=(Name="Q",Command="Axis aUp Speed=1.0 | Axis aActorUp Speed=1.0", bIgnoreCtrl=True)

      Change them so they look like this: (changes highlighted in bold)

      • Bindings=(Name="Z",Command="Axis aStrafe Speed=-1.0 | Axis aActorStrafe Speed=-1.0", bIgnoreCtrl=True)

      • Bindings=(Name="Q",Command="Axis aForward Speed=1.0 | Axis aActorForward Speed=1.0", bIgnoreCtrl=True)

      • Bindings=(Name="A",Command="Axis aUp Speed=1.0 | Axis aActorUp Speed=1.0", bIgnoreCtrl=True)
      That should set up your movement keys to work properly on an AZERTY keyboard.

      Please let me know if you have any trouble with these instructions, or with any other aspect of using Muvizu. Good luck.
      edited by Neil on 03/12/2010
      2010/12/3 11:42:44
      Bug? - lights have gone out This was a deliberate change, it gives you the ability to make videos in the unlit mode, to give it a cartoony style. If this is an unpopular change, we can look at making it a separate toggle for the camera preview windows. In the meantime, you can re-enable the lighting with the F3 key before you start recording your video.
      2010/12/2 12:19:51
      Ragdoll mode? Emily wrote:
      Buncha commitment-phobes!!

      No, we're just lazy. :p
      pages: 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19