Metahuman facial animation - RPGWatch Forums
|
Your donations keep RPGWatch running!
RPGWatch Forums » General Forums » Off-Topic » Metahuman facial animation

Default Metahuman facial animation

April 19th, 2021, 12:33
Very interesting software from Unreal, for creating and animating human characters. Now in beta, hopefully it will help to make high quality character performances more accessible to more studios.

These clips are just some guys having a play around with it, and it's already impressive.

loading…



loading…
--
"I cannot define the real problem, therefore I suspect there's no real problem, but I'm not sure there's no real problem."
Richard Feynman
Ripper is offline

Ripper

Ripper's Avatar
Ngikufisela iwela
Moderator

#1

Join Date: Nov 2014
Posts: 10,144
Mentioned: 90 Post(s)
+1:

Default 

April 19th, 2021, 13:01
The level of realism we get these days is astounding.

I'm wondering what amount of data it requires for each face. Maybe too much for small indie studios but I wouldn't be surprised if face sets were sold as IPs, maybe of famous actors and characters.
Redglyph is offline

Redglyph

Redglyph's Avatar
Keeper of the Watch

#2

Join Date: Aug 2020
Location: Good old Europe
Posts: 994
Mentioned: 24 Post(s)

Default 

April 19th, 2021, 13:22
Originally Posted by Redglyph View Post
The level of realism we get these days is astounding.

I'm wondering what amount of data it requires for each face. Maybe too much for small indie studios but I wouldn't be surprised if face sets were sold as IPs, maybe of famous actors and characters.
It runs in the cloud, and I'm sure there's a huge amount of data processed behind the scenes. To start with it comes with 60 face types, and each one can be customised and morphed to some degree, to create original faces. The idea is that the shape for each face base type can be modified to a certain degree without creating problems, and 60 starting points give a wide range of possibilities. Then they can be exported and further edited in other software.

For indies, the facial performance capture can be done on an iPhone. I do think this has enormous potential for improving the standard of facial animation. It seems to be part of Epic's strategy for Unreal - you're only allowed to use it with Unreal games. And, TBH, Unreal is bringing so much to the table these days, it's almost a no-brainer in many cases.
--
"I cannot define the real problem, therefore I suspect there's no real problem, but I'm not sure there's no real problem."
Richard Feynman
Ripper is offline

Ripper

Ripper's Avatar
Ngikufisela iwela
Moderator

#3

Join Date: Nov 2014
Posts: 10,144
Mentioned: 90 Post(s)

Default 

April 19th, 2021, 14:23
@Ripper Nice, that's good thinking.

I'd (selfishly) rather see more Unreal titles, hopefully that will be another motivation for studios. I understand Unity is more approachable since it uses C#, doesn't charge royalties, has a simpler flow than Unreal which seems to require more specialized developers & artist / designers. Also, C++ isn't for everyone, but there's simply no comparison with C# in terms of performance, and it can be felt in Unity games… I do love the elegance of C# as a language and its frameworks, but it's too easy to abuse it because of all the underlying process. Maybe the blueprints are a good compromise that still give Unreal an edge? Or the scripting language, if that's still being used.

I wonder if both engines are equally taught in schools. Or whether that actually matters. I wasn't taught the tools of the trade in engineering, the understanding and methodology were more important, surely it's also true in game development?
Redglyph is offline

Redglyph

Redglyph's Avatar
Keeper of the Watch

#4

Join Date: Aug 2020
Location: Good old Europe
Posts: 994
Mentioned: 24 Post(s)

Default 

April 19th, 2021, 14:42
They dumped the scripting language a few years ago, but they've continued to improve the Blueprints system, which is very good. Just from being an amateur that loiters around the gamedev communities, it seems to me that a popular approach is to prototype a game in Blueprints, then have a C++ guy code the performance-sensitive parts, which are then exposed as custom nodes in the blueprinting system, allowing non C++ devs to continue building out the game.

I'm not sure how widely it's taught in schools, but, as you say, I don't think that's too significant. A huge amount of what goes on in game engines is essentially conceptually the same, and I don't think it would take a trained game dev too long to move among them. There are probably fewer Unreal-skilled folks in the jobs market, though,
--
"I cannot define the real problem, therefore I suspect there's no real problem, but I'm not sure there's no real problem."
Richard Feynman
Ripper is offline

Ripper

Ripper's Avatar
Ngikufisela iwela
Moderator

#5

Join Date: Nov 2014
Posts: 10,144
Mentioned: 90 Post(s)

Default 

April 19th, 2021, 18:31
Originally Posted by Ripper View Post
it seems to me that a popular approach is to prototype a game in Blueprints, then have a C++ guy code the performance-sensitive parts, which are then exposed as custom nodes in the blueprinting system, allowing non C++ devs to continue building out the game.
That sounds like a very good approach Profiling the game and replacing the slow parts in the critical paths is the natural way to proceed, I didn't know both methods were easily interchangeable but it makes sense (I have to admit I only have a very rough idea of how those Blueprints work, never been a big fan of graphical representations of sequential systems but I understand the appeal to people who have a visual-oriented mind).
Redglyph is offline

Redglyph

Redglyph's Avatar
Keeper of the Watch

#6

Join Date: Aug 2020
Location: Good old Europe
Posts: 994
Mentioned: 24 Post(s)

Default 

April 19th, 2021, 18:41
Originally Posted by Redglyph View Post
. . . I understand Unity is more approachable since it uses C# . . . Also, C++ isn't for everyone, but there's simply no comparison with C# in terms of performance, and it can be felt in Unity games . . .
Hmm, well, bad coders can do horrible things both in c# and c++ . . . I think it's not the language itself that makes Unity slow or Unreal complex -- it is the inadequate developer, who cannot use these engines properly.
duerer is offline

duerer

Keeper of the Watch

#7

Join Date: Mar 2008
Posts: 771
Mentioned: 7 Post(s)

Default 

April 19th, 2021, 19:13
Originally Posted by duerer View Post
Hmm, well, bad coders can do horrible things both in c# and c++ . . . I think it's not the language itself that makes Unity slow or Unreal complex -- it is the inadequate developer, who cannot use these engines properly.
It's possible, and that's what I said, it's easy to abuse it (for the C# part). But it starts with disadvantages for the performances, being JIT-compiled and based on garbage collection.

C++ has its disadvantages too and it's a lower-level language that requires more development time, but programmers have to be aware of memory management since they do it themselves. If there's a bad behaviour, it's more exposed to code reviews. They also have a better visibility on the loops and how the data is handled. It's so much easier in C#, but you really have to know what is done behind the scenes.
Redglyph is offline

Redglyph

Redglyph's Avatar
Keeper of the Watch

#8

Join Date: Aug 2020
Location: Good old Europe
Posts: 994
Mentioned: 24 Post(s)

Default 

April 19th, 2021, 20:46
Honestly?
Meh.
--
Toka Koka
joxer is offline

joxer

joxer's Avatar
The Smoker
Original Sin 1 & 2 Donor

#9

Join Date: Apr 2009
Posts: 23,065
Mentioned: 199 Post(s)

Default 

April 20th, 2021, 16:01
Originally Posted by Redglyph View Post
It's possible, and that's what I said, it's easy to abuse it (for the C# part). But it starts with disadvantages for the performances, being JIT-compiled and based on garbage collection.

C++ has its disadvantages too . . .
Hmmm, if you write high level game logic code and you have JIT-related performance bottlenecks. . . you are doing something very very wrong

Here's why: most game logics are relatively simple: they use (mostly) simple algorithms and data structures. Problem is, that simple stuff is very tempting to be written with brute force.

Here's a quick example:
You are writing a simple tile-based RPG, and your world is, say, 1000x1000 tiles.
This means you have to store 1000x1000=1million tiles.
Now, if you test your player whether he can move to North from the current tile. . .
. . . is it really efficient to sweep through 1million tiles to find the tile just North of you?
. . . is it really good to do this in every single frame when the player presses the Up button?
. . . is it really necessary to keep this much data in memory all the time?

This is the highly inefficient brute force approach, and believe me, it won't be any better in C++ or even assembly. The only way to make it efficient is to think about the problem and solve it by with effective algorithms and data structures.
If you have these at hand, you'll realize that c# is just as good as c++.

Mind you, theoretically, you are right: any JIT-based language is slower than a precompiled one. However, when you do high level coding and your algos and structs are okay, the speed difference is marginal.
duerer is offline

duerer

Keeper of the Watch

#10

Join Date: Mar 2008
Posts: 771
Mentioned: 7 Post(s)

Default 

April 20th, 2021, 17:41
@duerer I agree, but it all depends on the specifics. I'm not too concerned by high-level code, or using the wrong algorithm, but rather by code that must handle a lot of objects repeatedly.

Take for example inventories that you display and close, which contain quite a lot of items. Each time you create and discard lists and all the objects needed to display them.

You know that C# and Java (and Python, …) need to manage that by counting how many times every instance is used and released, to know whether the memory is still used somewhere or not. Every now and then the CLR will go through all that to free memory. It becomes very noticeable in some situations. Sure you can start working around by reusing the same objects but it's quickly getting as tedious as writing C++. It's like trying to control gears on an automatic gearbox. And programmers who don't have those notions won't understand what's happening to them.

The fluidity and responsiveness I could obtain with C++ and, for example, Qt, was so much better than a C# with Forms or WPF, even by using low-level bitmap widgets to draw the elements.

An impressive example by Introversion to illustrate what I mean (demo starts around 16'44"), they're using C++ and OpenGL. I wouldn't dare try that in C# or Java.

Assembly is perhaps too low It's fun but I don't do that anymore, except on hardware projects for home-made little processors when there is no other choice.
Redglyph is offline

Redglyph

Redglyph's Avatar
Keeper of the Watch

#11

Join Date: Aug 2020
Location: Good old Europe
Posts: 994
Mentioned: 24 Post(s)

Default 

April 20th, 2021, 20:45
Don't quite agree with you, but that is the beauty of a good dispute

Originally Posted by Redglyph View Post
I'm not too concerned by high-level code, or using the wrong algorithm, but rather by code that must handle a lot of objects repeatedly.
(emphasis by me)
And that is good Sir, the root of the problem. Most programmers simply ignore the power of well chosen algorithms, which is a big no-no.
Effective handling of large data is exactly the reason why certain algos and structs exist.
Imagine: your game simply want to manage, say, 10 thousand objects (hey, are you writing a Minecraft clone?), and you have a bottleneck -- while a well engineered server backend written in ASP.net (c#) can handle MILLIONS of requests effectively. So large data handling is not the language's limitation, rather the programmer's skill.

Originally Posted by Redglyph View Post
Take for example inventories that you display and close, which contain quite a lot of items. Each time you create and discard lists and all the objects needed to display them.
For this, you must have a decent dynamic object manager at hand.
Without this, in c# you will trash the garbage collector, in c++ you'll trash the memory and get constant processor cache misses.
So. . . it all depends on the object manager you want to use, and how well you use it - and not the language itself.
(Mind you, both Unreal and Unity has its own object manager, and each has its own limitations. If you disobey the limits, your code will be under-performing,no matter if it was written in c++ or c#)

Originally Posted by Redglyph View Post
The fluidity and responsiveness I could obtain with C++ and, for example, Qt, was so much better than a C# with Forms or WPF, even by using low-level bitmap widgets to draw the elements.
Again, this is not the language's quality, rather the third-party window manager's.
Qt is easier to use than WPF, but less flexible. If you love Qt, use it anywhere - even in c#, because it has a binding for c# as well (also available for python too!).

Hope you won't find this rant as a lecture, I'm just commenting this from experience. It took me about 15 years to realize this. . .
duerer is offline

duerer

Keeper of the Watch

#12

Join Date: Mar 2008
Posts: 771
Mentioned: 7 Post(s)

Default 

April 20th, 2021, 21:28
There is a reason that almost all AAA games is written in C++….. is that not enough proof? I guess it is not much to debate even.
GothicGothicness is offline

GothicGothicness

GothicGothicness's Avatar
SasqWatch

#13

Join Date: Oct 2006
Posts: 6,151
Mentioned: 10 Post(s)

Default 

April 20th, 2021, 22:02
Originally Posted by GothicGothicness View Post
There is a reason that almost all AAA games is written in C++. . . is that not enough proof? I guess it is not much to debate even.
Not quite. The engine and some performance-heavy aspects (i.e. AI framework) are written in c++, yes, but oftentimes, the actual game logic (puzzles, triggers, overall level logic) is written in some very high level scripting language, i.e. lua (GTA), blueprint (Unreal games), some custom language (Galaxy - Starcraft), or even python/ruby/javascript.

Why? Because games nowadays are based on the "data-driven" approach, meaning: the actual game logic has to be data too (resource/asset, you name it), so it can be modified quickly and easily while designing the gameplay - without recompiling the game code. (btw, that's why certain games are so easy to mod)

But why? Because the game logic is nowadays not coded by the programmer, but the level scripter (formerly: level designer). The programmer is now doing engineering stuff and provides a bullet proof framework for the scripters to do their job.

Again, why? Because a content-heavy AAA project needs much more scripting work than actual engineering. Also the programmer salary is much higher than the level scripter's, so. . .

But. . . this is ridiculous! So game development is like some g*ddam factory assembly line?
EXACTLY! That's why so many burned out AAA game developers revert back to indie and do stuff "just like in the good old days".
duerer is offline

duerer

Keeper of the Watch

#14

Join Date: Mar 2008
Posts: 771
Mentioned: 7 Post(s)

Default 

April 20th, 2021, 22:13
Originally Posted by duerer View Post
Not quite. The engine and some performance-heavy aspects (i.e. AI framework) are written in c++, yes, but oftentimes, the actual game logic (puzzles, triggers, overall level logic) is written in some very high level scripting language, i.e. lua (GTA), blueprint (Unreal games), some custom language (Galaxy - Starcraft), or even python/ruby/javascript.

Why? Because games nowadays are based on the "data-driven" approach, meaning: the actual game logic has to be data too (resource/asset, you name it), so it can be modified quickly and easily while designing the gameplay - without recompiling the game code. (btw, that's why certain games are so easy to mod)

But why? Because the game logic is nowadays not coded by the programmer, but the level scripter (formerly: level designer). The programmer is now doing engineering stuff and provides a bullet proof framework for the scripters to do their job.

Again, why? Because a content-heavy AAA project needs much more scripting work than actual engineering. Also the programmer salary is much higher than the level scripter's, so. . .

But. . . this is ridiculous! So game development is like some g*ddam factory assembly line?
EXACTLY! That's why so many burned out AAA game developers revert back to indie and do stuff "just like in the good old days".
Ok, yes, I got your point, for sure the scripts would not be done in c++ it makes no sense, but I think they'd seldom be done in C# either, I thought it was some kind of comparison between C# and C++ for core game/engine logic.

Agree on you on the other point as well, so much things are scripted in the AAA games that they are more like movies than actual games these days.

Also, few companies dare to take any risk at all with the AAA games so most of them are very "safe", that is the reason I am also doing my own game…. I sure would like the have the resources they have for those AAA games though.
GothicGothicness is offline

GothicGothicness

GothicGothicness's Avatar
SasqWatch

#15

Join Date: Oct 2006
Posts: 6,151
Mentioned: 10 Post(s)

Default 

April 20th, 2021, 22:21
Originally Posted by GothicGothicness View Post
Ok, yes, I got your point, for sure the scripts would not be done in c++ it makes no sense, but I think they'd seldom be done in C# either, I thought it was some kind of comparasion between C# and C++ for core game/engine logic.
And that is my point: from the game developer's perspective, the actual language should not matter too much.

If you are an engine developer (engineer), then it is an entirely different discussion.
(Mind you, an advanced engine can be written in exotic ways also, i.e. Ubi's AnvilNext engine is a hybrid of c++ and c# codebases -- but again, the reasons for this are way off topic for now)
duerer is offline

duerer

Keeper of the Watch

#16

Join Date: Mar 2008
Posts: 771
Mentioned: 7 Post(s)

Default 

April 21st, 2021, 00:37
Originally Posted by duerer View Post
And that is good Sir, the root of the problem. Most programmers simply ignore the power of well chosen algorithms, which is a big no-no.
Effective handling of large data is exactly the reason why certain algos and structs exist.
That's not what I mean I'm not saying I don't care about using the proper algorithm, which would be plain silly, I'm saying it's not the variable I'm discussing, assuming the correct choice has been made. So all other things being equal, I'm considering, as a typical example, the processing of large groups of data. The low-level processing. In other words, I'm not discussing higher-level functionality (overall scheduling, state machines, and so on).

There may be custom GC that are optimized for such or such applications, but in C++ it is up to the programmer to manage the memory, no need to guess what a black box will do or when. Moreover, it develops a more acute awareness of the memory usage.
Originally Posted by duerer View Post
Again, this is not the language's quality, rather the third-party window manager's. Qt is easier to use than WPF, but less flexible. If you love Qt, use it anywhere - even in c#, because it has a binding for c# as well (also available for python too!).
When you access the low-level bitmap, it doesn't matter that much, but the same comparison could surely be done with Qt on either side.

The fact is when you are using a higher-level approach, you trade performance and resources for programming efficiency because you leave that up to the compiler and pre-made, generic libraries, and it may be almost as good, but not in all cases. It was the same when going from assembler to C, from C to C++, and it is the same when jumping from C++ to C# or Java. Any benchmark will show that.

So to come back at the source of the discussion (somewhat OOT - sorry @Ripper!), when I said there was no comparison between the two in terms of performance, I wasn't discussing about high-level programming or network/file-based queries (which depends heavily on the hardware throughput), but about the more inner loops of intense processing and the real-time aspect of it. That usually doesn't concern the whole development team, indeed.

But the problem is larger than performance. Usually it's fine with a higher-level language, and since it's more comfortable, safer, quicker to program, and more importantly since the learning curve is not as steep - it's easy to hire developers!, the choice is usually obvious.
Redglyph is offline

Redglyph

Redglyph's Avatar
Keeper of the Watch

#17

Join Date: Aug 2020
Location: Good old Europe
Posts: 994
Mentioned: 24 Post(s)

Default 

April 21st, 2021, 01:00
Originally Posted by Redglyph View Post
(somewhat OOT - sorry @Ripper!)
No worries. I'm not a professional coder, so I might learn something. I've picked up a lot from developer discussions.

And really, this topic is probably more interesting to developer types, anyway. As we see, the examples have failed to impress an aesthete like Joxer. But, if you look at it in terms of putting powerful tools in the hands of indie devs, I think it's a lot more interesting.
--
"I cannot define the real problem, therefore I suspect there's no real problem, but I'm not sure there's no real problem."
Richard Feynman
Ripper is offline

Ripper

Ripper's Avatar
Ngikufisela iwela
Moderator

#18

Join Date: Nov 2014
Posts: 10,144
Mentioned: 90 Post(s)

Default 

April 21st, 2021, 09:04
Devs are more and more dependent on so many tools, libraries, frameworks… It's possible to achieve so much more, and on more complex systems, but it's far from the era we had to develop everything ourselves, except maybe the compiler or the assembler Sometimes it's hard to shake the old habit of doing everything and reinventing the wheel. Or maybe that's just pride? Because we see that in young developers too.
Redglyph is offline

Redglyph

Redglyph's Avatar
Keeper of the Watch

#19

Join Date: Aug 2020
Location: Good old Europe
Posts: 994
Mentioned: 24 Post(s)

Default 

April 21st, 2021, 11:54
Originally Posted by Redglyph View Post
It's possible to achieve so much more, and on more complex systems
Not always. Excessive reliance on frameworks and popular libraries may reduce your flexibility. I once had a contractor, who relied heavily on AngularJS, confess to being unable to reproduce a certain chart that I wanted in a web application (a line chart superimposed on a heat map) with their usual tools. Mind you, I had never expressed any need for client-side rendering, and eventually they found a complex workaround by pre-rendering everything on the server. The irony is that the simple, CGI-based demonstrator that I had coded from scratch (my grasp of web development stopped somewhere in the 1990s) and given them as a model was already doing everything I had been asking for.

More on topic, I should hope that these facial animation tools will impact the movie industry more than the games industry, because I certainly cannot envision any way in which this will elevate the quality of an RPG.
Atrachasis is offline

Atrachasis

Watcher

#20

Join Date: Jul 2007
Posts: 87
Mentioned: 3 Post(s)
RPGWatch Forums » General Forums » Off-Topic » Metahuman facial animation
Thread Tools Search this Thread
Search this Thread:

Advanced Search

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off

Forum Jump

All times are GMT +2. The time now is 06:45.
Powered by vBulletin® Version 3.8.11
Copyright ©2000 - 2021, vBulletin Solutions Inc.
vBulletin Security provided by DragonByte Security (Pro) - vBulletin Mods & Addons Copyright © 2021 DragonByte Technologies Ltd.
User Alert System provided by Advanced User Tagging (Lite) - vBulletin Mods & Addons Copyright © 2021 DragonByte Technologies Ltd.
Copyright by RPGWatch