RPGWatch Forums
Page 1 of 2 1 2

RPGWatch Forums (https://www.rpgwatch.com/forums/index.php)
-   Off-Topic (https://www.rpgwatch.com/forums/forumdisplay.php?f=8)
-   -   Metahuman facial animation (https://www.rpgwatch.com/forums/showthread.php?t=47446)

Ripper April 19th, 2021 12:33

Metahuman facial animation
 
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…

Redglyph 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.

Ripper April 19th, 2021 13:22

Quote:

Originally Posted by Redglyph (Post 1061638496)
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.

Redglyph 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?

Ripper 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,

Redglyph April 19th, 2021 18:31

Quote:

Originally Posted by Ripper (Post 1061638501)
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).

duerer April 19th, 2021 18:41

Quote:

Originally Posted by Redglyph (Post 1061638498)
. . . 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.

Redglyph April 19th, 2021 19:13

Quote:

Originally Posted by duerer (Post 1061638517)
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.

joxer April 19th, 2021 20:46

Honestly?
Meh.

duerer April 20th, 2021 16:01

Quote:

Originally Posted by Redglyph (Post 1061638518)
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.

Redglyph 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 :lol: 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.

duerer April 20th, 2021 20:45

Don't quite agree with you, but that is the beauty of a good dispute :)

Quote:

Originally Posted by Redglyph (Post 1061638621)
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.

Quote:

Originally Posted by Redglyph (Post 1061638621)
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#)

Quote:

Originally Posted by Redglyph (Post 1061638621)
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. . . :)

GothicGothicness 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.

duerer April 20th, 2021 22:02

Quote:

Originally Posted by GothicGothicness (Post 1061638639)
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".

GothicGothicness April 20th, 2021 22:13

Quote:

Originally Posted by duerer (Post 1061638644)
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.

duerer April 20th, 2021 22:21

Quote:

Originally Posted by GothicGothicness (Post 1061638646)
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)

Redglyph April 21st, 2021 00:37

Quote:

Originally Posted by duerer (Post 1061638635)
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.
Quote:

Originally Posted by duerer (Post 1061638635)
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.

Ripper April 21st, 2021 01:00

Quote:

Originally Posted by Redglyph (Post 1061638649)
(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.

Redglyph 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.

Atrachasis April 21st, 2021 11:54

Quote:

Originally Posted by Redglyph (Post 1061638675)
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.


All times are GMT +2. The time now is 01:08.
Page 1 of 2 1 2

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