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.
> You're going to need the latest hardware to get access to all that graphical power, though. The demo we saw was running on a top-of-the-line NVIDIA GeForce GTX 680 graphics card, and we were told explicitly that the engine was currently being targeted for the next generation of console hardware rather than the Xbox 360 and PS3
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.
It's not claiming that design or art in lighting is unnecessary. It's freaking obvious that's necessary.
Between then and now we've gradually gained enough GPU power to move towards a unified, real-time lighting model with most of the desired real-world properties. Although limits still exist, we can finally start addressing lighting primarily from the designer's perspective.
For example? (genuinely curious)
For example, if you want an ominous feel to a cathedral, you need to know what light colors are more ominous than others, what direction of lighting (maybe bottom up, rather than from the top), what types of lights...many dim point lights? or single directional lights?, if light scattering through a medium like fog would look good, etc etc. And also keeping in mind functional aspects like, can the player still see items or things he needs to do, even with all of this specific lighting.
Another example might be that while lighting and materials might behave naturally, sometimes they still behave in undesireable ways. Suppose the angle of the sun reflected off of a reflective surface right into the player's face right while he was at a specific location where he needed to do something. If you can't move the surface, can you shift the light? Will that effect the scene much? Maybe now that you shifted the light, the rays of light that were going through a tree branch beautifully are not there any more.
Look at old film noir movies on TV, they have very exaggerated lighting for dramatic effect.Often you are reducing light to remove information from the scene, so that the viewer can focus on the dramatic subject.
Also, none of the graphics engines really capture the wave-nature of light - intereference/diffraction etc. Radiosity captures a bit of this but from an intensity/energy point of view.
http://www.eurogamer.net/articles/digitalfoundry-vs-unreal-e...
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.
http://cubeengine.com/forum.php4?action=display_thread&t... http://www.youtube.com/watch?v=ZkFT1ra2w-A
Deferred shading, realtime lighting, etc. etc. Also it has the Sauerbraten in-game editor (like Unreal is getting).
Probably the best complete open source game engine out there. And it's zlib (unlike the id Techs which are GPL).
Some real-time version of PRT? "RTRT"?
As a programmer, I find this much more compelling than the graphical improvements.
http://www.amazon.com/Game-Engine-Architecture-Jason-Gregory...
An older book like Eberly's 3D Game Engine Design was more a loosely knit compendium of theory and algorithms. Eberly's more recent 3D Game Engine Architecture is closer to Gregory's in intent. Unfortunately, it's more a reflection of the idiosyncrasies of the author and his personal code base than an investigation of game engines as developed and used in the industry.
I've also heard good things about Mike McShaffry's Game Coding Complete. McShaffry is a game industry veteran, so he knows what he's talking about. However, it seems to be targeted at rank beginners, so a lot of the material might not be very useful to you.
Below that tier, of course, you have an endless array of how-to books written by incompetents. The worst is the "here's my shitty homebrewed codebase" variety.
For rendering in games, you'll need a separate book. Real-Time Rendering is the canonical reference. The first and second editions were my favorites. The third edition added a lot of information on recent techniques but at the expense of reading too much like an annotated bibliography, skating from topic to topic while rarely going into enough detail to be useful and often listing several alternative solutions to a given problem without comparing their relative merits and trade-offs. The first editions flowed more like textbooks and were thus better suited as introductions. Some of that might be hindsight bias on my part; I'm curious what others think who first learned the subject from the third edition.
I also want to give a shout-out to Christer Ericson's Real-Time Collision Detection book. It's full of clear explanations and practical, hard-earned knowledge that you can't get anywhere else. Plus, the accompanying code is robust and well written, a far cry from the usual crap that either straight-up doesn't work or is inextricably entangled with a massive code base (I'm looking at you, Eberly!).
http://duriansoftware.com/joe/An-intro-to-modern-OpenGL.-Cha...
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 best tutorials I've found for modern OpenGL is "Learning Modern 3D Graphics Programming" by Jason McKesson. The only problem I have with these tutorials is that there aren't enough! http://www.arcsynthesis.org/gltut/
http://www.amazon.com/Tricks-Programming-Gurus-Advanced-Grap...
Note that this is the type of programming now implemented in hardware GPUs, and in libraries such as DirectX and OpenGL. If you were to write a modern game, you would do it on top of one of these hardware-accelerated libraries, and you wouldn't be writing this type of code in software anymore. But if you really want to learn how to do these things from the "ground up", this book can help you build that foundation
Since modularity is one of the keypoints of how this editor/game engine work so well together, it's probably a good idea to have some idea of how to structure game components to lessen the 'ball of mud' feeling.
I've been pretty fascinated with data-oriented "entity/component" systems for a while, as opposed to heavily inheritance based models. There's a decent introduction here: http://cowboyprogramming.com/2007/01/05/evolve-your-heirachy...
It seems like a lot of modern game engines (one example would be Unity) utilize this approach to varying degree.
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.
"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 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.
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.
Writing a highly parametrized engine like that with JIT script compilation is plain awesome!
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