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".
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
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.
That Real-Time Collision Detection book sounds particularly interesting to me. I had resigned myself to just using Bullet in the toy engine I'm working on since I couldn't find any good resources on the subject. I'll check that out!
The only book you're missing is the one that explains how to get your foot in the door ;)
Edit: I also wanted to point out that in the author's preface, he discusses what he considers the downside to most introductory texts and tutorials in 3D graphics programming - presenting "fixed functionality" that allows newcomers to more quickly use the tools at hand by abstracting much of the foundational information away.
While this is certainly useful for experienced developers learning a new derivative technology on top of what they already know, I have always found this approach for introductory stuff frustrating. At the end of the day I may come away pseudo-understanding a "higher level" concept, but ultimately much has been abstracted away and I am left ignorant and, as the author says, "Programming thus becomes akin to magical rituals: you put certain bits of code before other bits, and everything seems to work."
I wish I knew of more texts like this for other fields where over or premature abstraction could endanger comprehension. (For example, I know I would like to see a similar approach taken to other complex topics, like networking.)
If you're looking for something lower level, the book you probably want is the white book - Computer Graphics: Principles and Practice. I have the 2nd edition from 1992, which is the still the standard intro graphics textbook for many CS departments. Though Amazon says there will be a 3rd edition coming out at the end of this year!
http://www.amazon.com/Computer-Graphics-Principles-Practice-...
Another highly recommended book (also recommended in another comment here) is Real-Time Rendering, but I've only used bits and pieces from this one, so I don't know how good it is for folks just starting out. Still probably one you'll want to add to your shelf if you continue on in the field.
http://www.amazon.com/Real-Time-Rendering-Tomas-MOller/dp/15...
Oh, and also also, head over to YouTube with some snacks and a drink, sit down, and watch the weekly Overgrowth game developer videos from Wolfire Games. It's both inspirational to see what other people are doing, and a great demo of concepts that you'll read about in GEA, such as animation blending: http://www.youtube.com/playlist?list=PLA17B3FAA1DA374F3&...
That isn't to say this doesn't happen now, just that it's only going to get better.
If I may ask, don't you think decisions related to the "feel" of any game/entertainment device rests squarely on the shoulders of the art director?
I feel that statements such as that on ars is not meant to mock the artists but instead convey the message that "Hey programmers, next time the artists/director want these lights and this reflective properties, you can do it very quickly instead of hacking through messy code."
Now, personally what I think is going to happen is that with even more control, and lesser instances of programmers telling the artists "I could do that for you, but we're going to blow the next 6 month worth of budget for 5 people. Is that effect still important now?", artists are going to be able to come a step closer in realizing their intended vision.
(Of course the (fairly lo-res compared to your screen) voxelized geometry representation is not rendered directly to screen ala Atomontage or Gigavoxels -- the the GI is based on RT scene voxelization and approximate cone-tracing.)
Well that's awesome because at least there's (A) a paper for this (grokking it is another matter) and (B) seems like it runs really smoothly on next-gen GPUs!
On the other hand, object-oriented approaches are not great for simulating huge numbers of entities, where column-major array-based layouts are a lot more efficient.
I wonder if Kismet data-flow graphs may end up getting too complicated for their own good. They look like they could do with a textual representation. The obvious manual iteration involved in the creation of the orrery in the gametrailers demo video posted in the comments elsewhere here shows how painful this approach can be.
This sounds like the virtual classes that Tim were talking about ten years ago. (For the curious, the first programming language with virtual classes was BETA from Aarhus University.) They never made it into UnrealScript. His language research after that time was less incremental and sought to uproot almost everything about programming games. He moved away from object-oriented programming and more towards functional programming, specifically type theory. When I arrived in 2004, he was all about dependently typed languages, the big inspiration being David McAllester's Ontic. For a long time his plan was that his new language would be used to implement most if not at all of UE(n+1). Eventually that ambition had to be tempered by reality and thrown aside; I'm not sure if he's still working on programming language design.
Do you know if this can be done in UE1? I'm actually developing something called "NewNet" in UT99 for fun - plus, more people actually still play that game than all the others! Basically it fixes the movement lag associated with high pings and simulates zero ping by keeping track of the positions of all actors from within the past second or so, and "rewinding" the server to that saved position according to the ping of the shooter. There are mods for UT2003/UT2004 (UE2) and UT3 that do this, but nothing for UT99 - although there's the ZeroPing mod which is way too easy to exploit, as it's clientside hit detection. People said it couldn't be done for UT99 but I've managed to get a working prototype, even though it's quite messy and hacked together. It'd be great if I could do what you've mentioned, as it'd clean things up quite a bit.
The hacks I've had to do it get it to work right have been pretty silly, and there's a lot of duplicate code because I had looked for something like you mentioned (the sideways inheritance) but maybe I didn't look long enough, because I couldn't find it for UE1.
Normally you don't even store entities like that, I've seen all sorts of crazy data structures, such as storing them spatially, so you can ignore visual updates.
Or am I completely not getting what your saying here...
So instead of:
class Entity { Vector location; Foo foo; Vector velocity; }; // etc.
Entities[] entities;
Vector[] locations;
Vector[] velocities;
Foo[] foos;
There was an excellent presentation (from some games conference) on this topic posted here on HN a few years ago, but I can't find it easily.