christian_clavet - all messages by user

2016/10/17 16:11:02
Thanks for the new characters! Thanks to the Muvizu team to have brought new characters in. This will bring more variety and is greatly appreciated.
I'm talking about the trick or treat junior pack (
2016/10/15 20:21:59
An open Letter to Muvizu's developers
but (to my knowledge) each action is hard coded into Muvizu, so any small changes to an action would have to be made from scratch. This could take hundreds of hours for the developers.

Hi, I'm a hobbyist programmer in C++ and worked on some small open source project. This feature should not be that hard to implement if you know your stuff...

It should not be that hard, but the dev must be able to interpolate the animation data stream and put a scaling factor over it. A experienced developer with the muvizu architecture should be able to add this (without gui) in less than 20 hours of work. Add around another 10-15 hours to link the feature to GUIs and other stuff like the keyframer and you would have the feature. Hundred of hours are highly exaggerated.
edited by christian_clavet on 15/10/2016
2016/10/15 19:51:13
An open Letter to Muvizu's developers Hi, "unlimitedmagic"
I was just thinking that many of the character actions are too extreme for me. It would be nice to have a slider to be able to set the intensity of the action. I would think that would be a fairly easy improvement as you aren't adding a new feature - more of adjusting the range of existing movement.

This would effectively be a new feature, since it would mean adding a new interface element and stuff behind. It's a good idea, the dev will surely read it, but the management will be more influenced by sales projections than then the community. If they ask their devs to add a new feature to add more value, they might pick your idea...
2016/9/4 19:26:17
Pat Marr's Contest: Entries due by Sept 15 Wow! I've just read the whole thread as I've missed it! Really cool contest! Thanks a lot Pat for showing us new tricks! I liked them all! Still I don't quite understand how the T-REX could be animated in Muvizu!
edited by christian_clavet on 04/09/2016
2016/9/4 19:00:36
The Motherland Calls Wow! Really nice work Ziggy72! Im really impressed with the cloth details! Thanks for giving us some details of your process!
2016/9/3 20:32:17
An open Letter to Muvizu's developers I agree with you. At some point Muvizu would probably need to create more "versions" of the software. The current "play" version would be a basic paying version, then you could have PRO, and ULTIMATE, something along those line. (Or going with tech addons, like keyframing, etc)

As for the assets price, their prices should be revised. It's not worth it for any artist/team to create a new character for 3$!
edited by christian_clavet on 03/09/2016
2016/9/3 19:32:58
An open Letter to Muvizu's developers Good point about Muvizu having stylized characters, that's one of it's strength and one of the reason I bought it in the first place. It would be interesting that they act on this and offer more content.

Here is a reference image of what I mean, we could have more types of styles like theses one:

Pixar styled characters:

Anime style:

For this, they would need to contract artists and get someone on dev team to integrate the art. They could even re-use the skeletons of the models already made (heros & vilain could surely work), so the animation that is already done could work also on them. The only work that would need to be done, would be on the expressions (morph? faces with bones?). Who would not be happy to get more types of character styles? If they were releasing more character styles like theses one, I would buy them immediately.

Even with a style character TYPES are also needed:
- Man, women, children, babies (geometry)
- Fat , skinny, muscular, regular (geometry)
- clean, sloppy, etc. (mostly textures)

As of other suggestions:
- The game engine can already do OCEAN with particles FX of water splashes, but it's not used in Muvizu because its not integrated in the software (game engine support this). Putting a dev to integrate it in the project, and sell this as a addon (object that is a water surface generated by the game engine), would surely generate more revenue.
The same could be done for trees that would be animated by winds. (By the way, the game engine have physic).
We could have a character trigger a ball and the system could animate the ball bouncing in the scene, or trigger a car accident (if physic was integrated with a trigger force element). More iteration and we could define wheels that would turn by themselves when we are moving a car (friction, and torque)

- As for the walking, right now. I'm trying to limit myself to using it to a minimum, because it's really not accurate. Directing the character to walk specifically in a position is quite difficult.

Would'nt it be nice if we could use "waypoints" to define exactly where the character would go and the position/rotation he will be? (Waypoints are position/rotation we define in a game so the AI for NPC can refer to it to move characters) This is something that should be in the game engine, but not in Muvizu. We could define between each waypoint if the character is running/walking and this could be made in another addon that lot of people would like to have including me.

- As for adding more customization, if we could have a IMPORT CHARACTER For each type of character (could have a licence for each type of character, that would give us the model in FBX with the full skeleton and rig). A person that would get a model say for example, the FAT MAN, could modify the mesh inside his modeling application and redo the skinning, but don't touch the skeleton so it would re-use the current animations that were done for the character. That would allow people with the proper skills (modeling/rigging and skinning) to do custom characters.

Having these characters assets on the market could surely allow to create new animations too that could be imported later as new CUSTOM animations for theses types of characters.
Having the possibility to creating custom characters for MUVIZU would be great but not for everybody. As this is quite challenging technically (skinning), and require quite good skills in modeling. So not in the reach for anybody, having a way to artist to resell their work on the asset store would be nice.
edited by christian_clavet on 03/09/2016
2016/9/1 13:54:16
Easy not perfect face attachment The face mask is the "easy" and quick way. Creating a custom texture for the character and placing pictures to have a match for the mouth is really time consuming and it will surely distord the picture (theses are still cartoon character). You might loose more of the ressemblance using this method.
2016/9/1 2:13:24
Easy not perfect face attachment Hi, You could use the photo face mask. Just change the picture of the texture for the mask for the personalities you need.
Here is a screenshot:

Note: You might need to remove the nose, hairs, and eyes to clearly see the picture.
edited by christian_clavet on 01/09/2016
2016/8/30 1:18:53
Performance problems with Muvizu with cameras... Hi,

I just finished a small project using Muzivu and think there might be a problem with the "CAMERA CUT" when using multiple cameras.
It feel like even if the camera windows are not opened, the cameras continue to render as I see a really signifiant performance drop the more I had cameras.

I started to report the problems when I completed the video here, but with the feedback from the community I think there might be a issue with this. Here is the link to the thread:

Here is my current computer setup:
- Running Windows 10 anniversary edition. Muvizu and Windows are set in FRENCH.
- Intel I7 3770k running at 3,5Ghz
- 16Gb of ram
- Windows and Muvizu are running directly from a 512Gb SSD.
- Video card installed is EVGA GTX 1080 superclocked and all drivers are up to date. (It's was recently changed from my older GTX 780)
- No issues with games or other applications (3DS MAX, 3D Coat, The Witcher 3, No man's sky) all working at 100% efficiency.

More descriptions about the problem:
Muzivu give excellent performance, when not using the camera cut feature. I was able to add lots of characters and had no issues. Then when adding more cameras, the performance dropped (even by closing the cameras windows). Performance was so slow after 6 cameras, that when I decided to change the name of camera, it took 1-3 seconds for character of the name of the camera to appear while I was trying to type it. My full project when loaded take 1Gb of ram, but by playing with the camera cut feature, it could eat up to 2gb and be really slow. without adding any new content.

If you can provide a way to only render the active camera in the next version it would be really appreciated. It feel to me that all the cameras are rendering at the same time. Rendering a camera window, is ok, but the rendering should not occur when it's closed...

If needed I could provide you with a link to my project if needed to have more ideas about what it causing this.
Here is a link to the asset if you need to test the scene. Looking at the recent comments on the site, look like this will have to wait. It feel like there 1-2 developers working part time on this.
edited by christian_clavet on 02/09/2016
2016/8/30 0:52:13
Reworked my minions animation... ziggy72 wrote:
I never work with multiple cameras open - never. One camera at a time or everything grinds to a halt on a complex scene (even on a fast machine). I never use the active cameras window (I think that's what it's called)

Hi, Ziggy72!

I try to close everything too. If I have to, I prefer to only have open the "active camera window". It look like if camera even when NO windows of them are displaying are still rendering in the background. With 6 cameras, it take 1-3 second per character to refresh when I'm changing the name of a camera!

I reloaded the project, without playing with the camera, seemed faster. Checked the ram used and it was under 1gb. I really think there is some kind of "bug" related to the camera cut. Even if the windows are not opened, each camera still render in the background. (At least it seem to me, since I have no absolute proof of this since I don't see the source). It's really strange that a completed project take 1Gb of ram fully loaded, and when playing with theses camera, it goes up to 2gb...

PatMarrNC wrote:
But since virtually all of us end up splicing a bunch of footage together in a video editor as the last step, it makes much more sense to work with one (or maybe two) cameras at a time. Once all the character actions are programmed, it's very easy to move the main camera to a new vantage point and record the same scene again.

Hi, PatMarrNC
I think also we could only work with one camera, with a external editor. I would have to set a camera for the entire sequence, render it completely, and repeat the process for each wanted angle. Once in the video editor do the cuts there. But when this is used correctly in a game engine, there is 0% lag. It simply switch from a camera to another, not render them all at once at the same time.
edited by christian_clavet on 30/08/2016
2016/8/29 5:03:56
Reworked my minions animation... Since Muvizu uses Unreal engine, it should use natively hardware acceleration. In fact, if you have not installed your video card driver, I would expect Muvizu to crash. The developers should be able to find out what is causing this using a profiler. They should have one made accessible for the engine they use. The multiple cameras RTT is probably one of the first causes. Most games will use up to 1-2 rtt for a game (most of the time for faking reflections (water)) and dynamically switch from camera to camera, but made only 1 active (rendering at a time). I created 6 cameras, and if they where active all at the same time, the scene was rendered 6 times at each frame.
edited by christian_clavet on 29/08/2016
2016/8/28 22:52:22
Reworked my minions animation... Hi, was quite busy playing games since last week (in particular No man's sky), but decided this weekend to rework a little my "minions" animation.

- Reworked the crowd, had 3 character, now more than 12! (All dancing and get afraid)
- Reworked the cameras, the cameras were not to my liking.
- Changed little things in the minions actions (pianist now is having a single eye like Bob (thanks to IKES for the idea!)
- Reworked the lighting, was too bright for a music show.

Here is the result:

Note: Because of the music used (Pitbull), Youtube warned me that the video can not be played back in Germany.

Notes on Muvizu performance:
I had no problem adding and choreographed more characters, the slowdown seem to happen when I get more cameras (used 6). At some point Muvizu was so slow that when I decided to name my cameras, that the text took 1-2 second to update per letter when I was typing it. It would be nice that we could disable the camera rendering (or decide witch camera that need to be refreshed). Once I added more cameras, the application performance started to degrade. At 6 it's was horrible!

So as a recommendation, do the camera work at last, keep the cameras at a minimum!

There also another possible reason for the slowdown, Muzivu was updated recently, and it might have updated with a 32bit version. Not sure, I have to investigate. Memory usage was about 2Gb when I saw the slowdown appearing. If it would be a 32bit application it would page a lot when reaching this amount of ram.

As for my rig, this is not an issue:
- Intel I7 Processor (I7 3770K)
- 16Gb of ram
- Everything run from a 512Gb SSD
- Video card: EVGA GTX 1080 Superclocked.

When it was lagging at the most, the CPU what idling at 25% (Load seemed balanced on all 8 logic cores), only 2Gb were taken from the ram, had more than 8Gb free. As for the geometry I could manipule 100x times the amount of polygons that I had in the scene with 3DS Max with this video card. It's not because of the crowd (at least not the geometry).

So perhaps the Muzivu developers could look more at the application with a profiler to know where the application is loosing the more time and improve upon that. The ability to disable rendering from the extra cameras could help, It seemed to me that once a camera is created, a RTT (texture render of each camera) is done at each frame and it this should only be triggered if we need it. RTT could be done 1-2 per second for the camera preview and not per frame. Also the ability to disable the camera rendering (checkbox?) would be really useful. A idea I had is to increase the speed of update on the camera preview that the mouse is hovering over and let the other refresh slower.

If you have 6 cameras, the scene is rendered from each camera perspective! And if you don't absolutely need to refer to this (not doing specific camera work), it's slow down the work a lot!

Edit: Done a check with process explorer and the application is really 64bit. So should be able to handle a lot more ram. Checked when I start it, around 600Mb of ram is used and 15% of cpu is used. (no scene at all)
edited by christian_clavet on 28/08/2016
2016/8/6 20:39:34
Re-installed Muvizu: Play+ Hi, Big wally! Got the exact same thing here.

From what I recall, from what happened before I saw this:
- Buyed the keyframing pack, and downloaded some assets from the store.
- Was unable to activate the keyframing pack
- Tried to re-activate and it failed.
- Reinstalled Muzivu (installed it over the old one). Still doenst activate the keyframing pack.
- Got to support and the next morning the keyframing pack was activated
- Checked the list of assets and have the same as your screenshot
- All seem to work here, except that the list of pack show the same as your screenshot.
2016/8/6 18:14:34
help - biting off more than computer can chew.. Hi, you can check the graphic card power requirement on the package box, it can also be found on the internet. But what is written is the lowest power supply.

For this I have some recommendation to give:

Take this exemple: A GTX970, Here is the power recommendation from the NVidia web site
The site said the card will take 145W, and recommend a 500W power supply for the whole system (they give an example of the system at the bottom).

You need to be careful on the PSU, for this 500W psu, there are some NON-CERTIFIED psu out there that rate at 550W, but they will surely break after a short time of using them in this configuration. What you need is to add a safe margin, because electrical consumption is not linear with a system, it depend on what you do. The higher you get to the limit the more temperature your PSU will produce and more risk to break. (Heat/Cold cycles break circuits/solder over a long period)

What I mean a certified PSU? Certified PSU have also grades (bronze, silver, gold, platinium). The higher the grade, the more solid the PSU will be (stable current, more efficiency), and also will be good for the video card to reduce the symptom of "whine coil". (High pitched sound mostly in high FPS situation)

So to return to the example, you take a no-brand, non certified 550W PSU, install it with a GTX 970, the psu will get VERY hot, and at some point will surely break.

For a GTX970, I would add a margin of at least 100W (to keep the PSU cooler and keep it longer), so for this card, a 600W Bronze certified PSU would work nicely, and LAST.

If you look at the recommended specs, add 100W of margin, and take at least a certified PSU, you should be fine and won't throw money out of the window.
2016/8/6 17:51:19
Second video, Minions styled characters.... Hi! Thanks for the comments!

For the performance issue, I'm working on a workflow that should improve things a lot. Muvizu have tools to improve the refresh while editing and I was not using them!

I've done a quick test this week, and in the part of the scene (Minion burning by fire that was slowing down a lot the refresh). Found out, that I can render in "unlit mode" in the view menu. This will accelerate the rendering since Muzivu don't have to render the shadows. Also found the layer and this one is REALLY powerful in crowded scenes. You can set the models you want in a LAYER then when your working to choregraph something, you can hide (no render) the geometry you don't need to do the edit, so it lower a lot the geometry to render and make it fast again. When everything is done, you unhide all the layers and render.

This worked with my current scenes and I plan to do a polished version of the video with a lot more people in the room using this. Also Ikes showed me a trick to create a single eyes character and I've done the glasses for "bob". (Here are the glasses for this one , and the SET). So the next version will have a single eye minion (the one on the keyboard).

Thanks for your post Clayster, your Minion look nice too! The suit look really detailed!
2016/8/3 22:01:26
Second video, Minions styled characters.... Thanks MrDrWho13!
Yeah, I'm still waiting for my EVGA GTX 1080 FTW but I will wait a while, most of theses cards are backordered... (Ordered it last month)

For this kind of work (choreographing cartoons), there is a surely a way to develop a good workflow that is efficient and have the best rendering at the end. The more I will work with MUVIZU and learn it, I find a way to make it more efficient in editing. I will probably post a tutorial video about this when I'll find the proper workflow. For the last video, I was working with full rendering qualities (occlusion culling on, lighting on etc), so did not help MUZIVU to display the changes quickly when I was editing the scene.
2016/8/3 21:44:38
Trying to create a "minion" Hi, Tried it and it partially work. The eye will be a little hard to choregraph, but at least it will blink and give some sense of "living".
Here how it look like:

Here is a link to the FBX MODEL
Here is a link to the set with this model

Note: It might take some time to see this, it still on the spam filters...
2016/7/31 4:47:29
Second video, Minions styled characters.... Hi, This is my second video made with Muvizu, I also used Hitfilm for this one (mostly for the titles and the audio editing).

If you want to make characters like that I have made available the assets from my web site as:
- sample .set file
- FBX of the glasses
- Body texture
Here isthe file.

The story:
Quite simple. Since the characters are "minions", they should try to behave like them. They do something and most of time it end in mahem...

I've decided to impose limits on creation as:
- Must be done in a single day. I've done a test first to see how the character worked to be sure I could have something first.

So the video could be even better, but in the time frame I had and stuff I've observed, there it is.

- Seen that dialogue audio start from frame 0 and cannot really be tweaked. I had to make tracks of audio separately covering the entire sequence (Sorry, decided to only mute the singer and guitarist voices from the original audio, when they were not singing instead of singing for them, that's why the lipsync is not accurate)
- The more stuff we had the more time it take and slower the application becomes. I have a CPU intel I7 3770K, 16 Gb of ram and a GTX 780 video card, and it was fast at first with the singer, but the more characters I was adding, the slower it was. Was also longer to render. At the end with the 6 characters the interactive display was getting quite slow. Have some of you done a project with 20-30 characters?

For this clip, with the 6 characters it took:
- 2 Gb of ram
- 45 minutes to render in full hd

After looking more into Muvizu, I found out that I could display the screen with no lighting, and could create layers (and hide some parts while working on others), on my next videos I will try this to see if it improve refreshes while editing.
edited by christian_clavet on 02/08/2016
2016/7/29 1:29:04
My first little video with Muvizu... Hi, Thank you all for the comment, this community seem very active!

I don't think I'd would be ready to compete yet. Just started and looking at the possibilities. Perhaps I'll try something in the weekend but I don't promise anything...

I've looked at some of the videos made by the community and they are really great! (Especially the one with James Kirk running and hiding all around the ship, and lots of other I've seen)
pages: 1 2