.
By default when you import a character model from any 3rd party application you are given the option to assign the mesh to an already import rig. If you leave this option blank the first time the armature is saved as a separate file as well as the mesh which contains the weight table and morph targets as well you can import the textures and assigned materials and generate a physics asset. Using the first import feature you can add all of the the game requirements using the single character framework and instance the parts that are attached from whatever mesh object you import that can use the single framework.
For example if on the second character import you select the first armature/rig imported then only the mesh is imported with just the attached morphs and make use of the single channel approach and make as many different characters you wish but only have to do the animations and ragdoll stuff once and instance the parts as part of a character BP. You could take it a step further and combine all of the head shapes as part of a single head object and create an on the fly dynamic crowd sub-system, say like in Assassin’s Creed, with out having to do unique characters.
.
Yes there are some animation features built into DS that can be export to FBX. Since I use MotionBuilder for our animations I’m not up as to the extent of the tool set but I see no reason why one could not use DS to do simple stuff like cycles and expression sets. For example I used DS to create an expression set of about 30 different shapes using cluster shaping that can be layered per bone for general expressions, happy sad pain, as well as phonemes to do a simple chatterer box system.
.
Well as an oped and as an animator the base Epic rig has some serious problems as a base working from the top down and from the start should have involved a bit of though as to how the over all design is going to paint everything that comes afterwards into a corner unless the need is for 6 foot 3 robots so for our needs we went with Genesis as a “replacement” for the Epic base rig.
As an opinion the Epic rig as a single point asset has created a development pathway that for most off the shelf solutions ends as to the need for more AAA type character actors as to extend into more complex designs. I could go into a rant but if anything I think it’s time to replace Blueman with something a bit more advance as it’s current use really limits any BP based on the design and really needs an update.
Bottom line, and with due respect, Blueman is a really really bad single point starting point and should never be used as part of a modular top down design. Unless you need 6’3 hunched back monsters that can not even talk or express.
.
To be honest I don’t know about that stuff and have no need to learn it as I mentioned we use MotionBuilder and is possibly the number one reason why AAA studios no longer have 300 animators but maybe 3 or 4. It’s a case of letting the software do the hard work.
-
MB has a voice device that allows sound samples to drive the facial animations so if I need a Genesis character to talk I just pull in a template, add the dialogue track, and plot the result just like any other kind of animation requirements. The annoying thing is UE4 tends to blend everything so the audio tends to go off sync so there is a timing issue I have yet to figure out.
-
Animation data is animation data be it a walk cycle or facial animations but based on experience attempting facial animation as a procedural event lands up being goofy as to a result (Mass Effect comes to mind). Once again MB can save you a lot of effort by keyframing the dialogue to a sound track and then use UE4 to trigger the animations just like any other event be it run time or via sequencer. Using a sound driver in UE4 would be the last thing I would go with as it only solves the bottom up problem (aka make it work today) rather than solving the problem top down at a system level.
-
Sure it’s possible but as an animator the process sounds more like trying to write a book using a spreadsheet. Sure you could but why would you?
Opinion wise once again the root of the problem is not in the bottom up direction of solving the problems using patch work solution but by first starting with a single point solution that EVERYONE agrees to use as the foundation by which more complex designs can be created using a modular approach which UE4 is already very good at.
As a suggestion, if starting a project form scratch, serious consideration needs to take place as to the foundation development of a framework solution that solves the problems you might have, and you know will work, rather than doing patchwork that only solves the bottom up problem.
So first question anyone???
What makes for the ideal character base as a single point solution? Once you have a solid foundation everything else follows.