It's stunning that this runs on a single Nvidia GeForce 680GTX in an editor without any visible lag at all. I wonder why tesselation wasn't enabled though, it may have been because of performance issues.
Coming from a film background, it is clear there is a lot of conflation happening in these articles between light that 'behaves' like it would in the real world, and 'good' lighting. That is why you get quotes like in this article 'I light my scene by dropping a sun in'.
In reality, there is a whole lot more to lighting then simply having lights and materials that behave naturally. Sure, this gives you more realistic looking results out of the box, but it doesn't mean you don't have to sculpt and massage and tune your lighting to achieve the artistic result you want, especially for interiors, or scenes with characters in the foreground.
The quote is about overcoming a technical constraint that forces laborious placing of secondary lights to restore behavior that you get for free in the physical world.
It's not claiming that design or art in lighting is unnecessary. It's freaking obvious that's necessary.
The bit where he made a change to the source code, let it recompile on it's own, got a little alert in the editor when it finished and then had the change apply all without restarting the engine...WOW!
Unity does this now. You can recompile a file while your game is playing in the editor, and the running code is replaced. And I almost never use it -- I should figure out why that is.
That's because UE4 probably contains a lot better quality of code (and better GPU acceleration) than the horribly slow and buggy Flash plugin that powers that video.
Incredibly stunning tech. Now, I'm gonna go fantasize about an open-source version of this with updates every month (instead of every 3 years) -- as a compromise, I could do without the whole hot-reloading IntelliEditor shebang and consoles support -- a concentration on PC hardware that "will be commodity in 2 years, on mobile in 4 years, but can already be bought as state of the art now" (aka Kepler GPUs) would be enough.
To the pros: in your opinion, which of the many FOSS engines out there (many of which carrying a large legacy code-base of supporting soon-outdated modes of operation such as DX9 or lower or GL < 4.0) is the most likely candidate to offer a deferred pipeline incorporating lighting / particles such as we see here in this UE4 demo, at that level of performance and (expected but also demoed) robustness? Again, their "industry" tack (smart editor / console support, "we license only to pro developers" stance etc) would not be required ... only the "metal".
Back in the day, OGRE, Crystal Space and Irrlicht used to be the dominant FOSS ones.
Crystal Space is a bit outdated now. Irrlicht is stuck at DX 9.0 and OpenGL 3.x
OGRE seems the most likely candidate (ie the project is the most active and has been for years). Although it is also stuck at SM 3.0 - so no geometry shaders or access to the compute pipeline.
I am likely to be missing out on some other engines here.
Also I'm wondering about the lighting. Some folks on Twitter called it dynamic Global Illumination but here they just call it indirect lighting. I wonder -- are they still using an ambient light? More specifically, what's their GI algorithm? Might be something like the voxel approach sported by @icare3D but then it seems that one's just barely interactive, not as "real-time" as this stuff -- or well it might be on a GTX680 with a really-lo-res voxelization.
Eventually I'd expect a "linux of 3d realtime rendering" to emerge. It will then find its way into nearly everything that gets put on a screen from the smallest phone apps to the largest multi-screen games.
This stuff is really fascinating. Does anyone have any recommended reading or general advice as to how to learn more about game/graphical engine implementation? I mean, from the ground up. (I'm a CS undergrad and the closest we've gotten to learning about this has been the computational geometry chapter in CLRS, but that was a mildly esoteric introduction to everything that is possible in this field.)
I read Jason Gregory's "Game Engine Architecture" cover-to-cover and I'd highly recommend it for someone new to the industry who's interested in learning about game development. Gregory is a developer at Naughty Dog (Uncharted series).
While people mentioned NeHe, and it's where I started years ago, it's widely outdated. Here's one that helps you get started with modern GPU rendering concepts in OpenGL.
On the flip-side, if you're interested in rendering realistic scenes that appear physically accurate but aren't suitable for real-time rendering (useful for movies, ads, etc.), Physically Based Rendering (aka PBRT) by Pharr and Humphreys should be your go to book.
NeHe's OpenGL tutorials used to be a good (although now kind of outdated) starting point. Shaders didn't use to exist back then. But still a good start:
A game engine is much more complex than a graphics engine.
Maybe somebody can point to guides for creating physics/sound engines and AI/gameplay stuff as well?
The graphics stuff is amazing, but I'd be also interested to know how they achieve hot-loading with C++. It seems to me that Erlang's philosophy (or FP in general) would be of great advantage here - just have the engine handle entity state and make all of the game world manipulating functions referentially transparent. This way one can swap code between world "ticks" (or update cycles) without worrying about breaking something.
I don't know how efficient something like that would be though; somebody mentioned cache issues with lumping heterogenous properties together, but maybe this could be optimized behind the scenes.
At this point, seeing this kind of extremely high production value animation used to enact this kind of fantasy scene instantly makes me think of hackneyed backstory and plot focus-group optimized to death to appeal to slightly dull 14-year-olds. You don't throw out that sort of development budget to try out something with even a hint of narrative experimentalness, and you can always rely on there being kids with disposable income who haven't yet been saturated with cliches to the point of fatigue.
"This looks very well done, it's probably bad" is a strange heuristic to have.
"This looks very well done, it's probably bad" is a strange heuristic to have.
It's the same for Hollywood movies, isn't it?
When the producers want to focus your attention on how expensive and uniquely complicated a game or movie production was, that's a sign that the actual content was a secondary concern.
I see what you're saying, but the target audience here is the game development community. The animation was clearly designed to show various capabilities: indoor lighting, outdoor lighting, outdoor scenes, interiors with various materials, fluids, etc. etc. As with movies, it's still up to the team to use the tool to create a worthwhile experience.
We've certainly come a long way since Demon Attack and Pitfall! :)
I remember 23 years ago, trying to do 'ray tracing' on my Amiga would take... hours for one frame. It looked pretty good, but... wow. This is jaw-droppingly cool.
Why are people getting so excited about realtime global illumination and code hot-swap? CryEngine 3 already supports both, and has done so for the past year or so.
Realtime global illumination has been possible for the past few years. I believe Crytek was the first studio to make a game engine with support for the same (www6.incrysis.com/Light_Propagation_Volumes.pdf)
And the code hot-swap feature in the freely-available CryEngine 3 SDK isn't just for Lua, there's the CryMono project which adds support for hot-swapping C# scripts.
Very Beautiful! The demo has a nice Skyrim/LOTR feel to it and the lava flows were just gorgeous! If that lava flow generation is completely procedural then I'm extremely impressed.
Writing a highly parametrized engine like that with JIT script compilation is plain awesome!
In a way, this system reminds me of Light Table[1] in its ability to change some code/settings and get instant feedback. It totally changes the way people create content because it becomes so much more accessible and so much faster to see changes -- you can play around with a lot of different approaches more quickly, resulting in more room for experimentation.
Pretty amazing stuff! Really curious to see the tools that power all of this, as well as hear the architect's (or architects') vision for all of this
[+] [-] kristofferR|14 years ago|reply
It's stunning that this runs on a single Nvidia GeForce 680GTX in an editor without any visible lag at all. I wonder why tesselation wasn't enabled though, it may have been because of performance issues.
[+] [-] alainbryden|14 years ago|reply
[+] [-] augustl|14 years ago|reply
[+] [-] TrevorJ|14 years ago|reply
In reality, there is a whole lot more to lighting then simply having lights and materials that behave naturally. Sure, this gives you more realistic looking results out of the box, but it doesn't mean you don't have to sculpt and massage and tune your lighting to achieve the artistic result you want, especially for interiors, or scenes with characters in the foreground.
[+] [-] jasonwatkinspdx|14 years ago|reply
It's not claiming that design or art in lighting is unnecessary. It's freaking obvious that's necessary.
[+] [-] gbrindisi|14 years ago|reply
For example? (genuinely curious)
[+] [-] laserDinosaur|14 years ago|reply
[+] [-] bvdbijl|14 years ago|reply
[+] [-] robterrell|14 years ago|reply
[+] [-] TwoBit|14 years ago|reply
[+] [-] jlongster|14 years ago|reply
[+] [-] corysama|14 years ago|reply
http://www.eurogamer.net/articles/digitalfoundry-vs-unreal-e...
[+] [-] nacs|14 years ago|reply
[+] [-] dualogy|14 years ago|reply
To the pros: in your opinion, which of the many FOSS engines out there (many of which carrying a large legacy code-base of supporting soon-outdated modes of operation such as DX9 or lower or GL < 4.0) is the most likely candidate to offer a deferred pipeline incorporating lighting / particles such as we see here in this UE4 demo, at that level of performance and (expected but also demoed) robustness? Again, their "industry" tack (smart editor / console support, "we license only to pro developers" stance etc) would not be required ... only the "metal".
[+] [-] photon137|14 years ago|reply
Back in the day, OGRE, Crystal Space and Irrlicht used to be the dominant FOSS ones.
Crystal Space is a bit outdated now. Irrlicht is stuck at DX 9.0 and OpenGL 3.x
OGRE seems the most likely candidate (ie the project is the most active and has been for years). Although it is also stuck at SM 3.0 - so no geometry shaders or access to the compute pipeline.
I am likely to be missing out on some other engines here.
[+] [-] dualogy|14 years ago|reply
[+] [-] dkersten|14 years ago|reply
As a programmer, I find this much more compelling than the graphical improvements.
[+] [-] noonespecial|14 years ago|reply
[+] [-] adrianm|14 years ago|reply
[+] [-] malexw|14 years ago|reply
http://www.amazon.com/Game-Engine-Architecture-Jason-Gregory...
[+] [-] lloeki|14 years ago|reply
http://duriansoftware.com/joe/An-intro-to-modern-OpenGL.-Cha...
[+] [-] bronxbomber92|14 years ago|reply
[+] [-] photon137|14 years ago|reply
http://nehe.gamedev.net/
A game engine is much more complex than a graphics engine. Maybe somebody can point to guides for creating physics/sound engines and AI/gameplay stuff as well?
[+] [-] prezjordan|14 years ago|reply
[+] [-] pka|14 years ago|reply
I don't know how efficient something like that would be though; somebody mentioned cache issues with lumping heterogenous properties together, but maybe this could be optimized behind the scenes.
[+] [-] rsaarelm|14 years ago|reply
"This looks very well done, it's probably bad" is a strange heuristic to have.
[+] [-] pavlov|14 years ago|reply
It's the same for Hollywood movies, isn't it?
When the producers want to focus your attention on how expensive and uniquely complicated a game or movie production was, that's a sign that the actual content was a secondary concern.
[+] [-] projectileboy|14 years ago|reply
[+] [-] mgkimsal|14 years ago|reply
I remember 23 years ago, trying to do 'ray tracing' on my Amiga would take... hours for one frame. It looked pretty good, but... wow. This is jaw-droppingly cool.
[+] [-] ameyp|14 years ago|reply
Realtime global illumination has been possible for the past few years. I believe Crytek was the first studio to make a game engine with support for the same (www6.incrysis.com/Light_Propagation_Volumes.pdf)
And the code hot-swap feature in the freely-available CryEngine 3 SDK isn't just for Lua, there's the CryMono project which adds support for hot-swapping C# scripts.
[+] [-] jebblue|14 years ago|reply
[+] [-] photon137|14 years ago|reply
Writing a highly parametrized engine like that with JIT script compilation is plain awesome!
[+] [-] asianexpress|14 years ago|reply
Pretty amazing stuff! Really curious to see the tools that power all of this, as well as hear the architect's (or architects') vision for all of this
[1] http://www.kickstarter.com/projects/ibdknox/light-table
[+] [-] mck-|14 years ago|reply
[+] [-] wtracy|14 years ago|reply
[+] [-] mochizuki|14 years ago|reply
[+] [-] f0untain|14 years ago|reply
[deleted]
[+] [-] neuroelectronic|14 years ago|reply
[deleted]