Gorgeous Unreal Engine 4 brings direct programming, indirect lighting (opens in new tab)

I was more impressed by the live recompilation. It didn't interrupt his gameplay at all.

It's mentioned in the parent article:

> 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

To elaborate: Only about a decade ago, 3D game lights were almost uniformly "additive spheres" supplemented with some ambient or directional light. They didn't bounce or diffuse properly. Environments and characters each had separate lighting treatments, making the characters look like "cut outs" in most circumstances. Reflective surfaces were a special case feature, and most details could only be represented with a cleverly painted texture. Everything was faked, and as such, the art of a lot of these games had to hew closely to tech limitations.

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.

Achieving a specific mood or "feel" for an environment requires someone who is very sensitive to lighting, color, and architecture, and who has knowledge of techniques to achieve certain looks.

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.

Natural light is boring, and often distracting. As a very simple example, I live in an old house and have windows broken into small square panels. For a scene where someone is looking through that window I would put a light outside to make a shadow on their face for dramatic effect, even if the sun was not really coming from that direction or if it was raining (which usually softens shadows). But if I was showing the same person looking back into the room, then the shadow on their back would be a distraction from what was inside the room, so I would soften the lighting or put a screen to limit the natural light, and fill in the darker areas of the room with a soft light.

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.

Raytracing for one.

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.

For C++? That's the impressive part.

source, link, reference, anything?

Sauerbraten has an experimental branch called Tesseract

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

Voxels would be too heavy. I have worked with volume rendering before and it's way too expensive to do it at this scale (although their scene with the light passing through the volumetric smoke column kind-of defied this).

Some real-time version of PRT? "RTRT"?

The physical renderer in Cinema 4D is pretty fantastic, and calls it Indirect Illumination. It's pretty crazy slow at rendering this stuff. I've had 6h+ renders, per frame.

In some cases, it involves calculating the angle and falloff of the original light, and placing extra lights at the right angles to simulate the bounce light.

I'm not sure about UE4, but Geomeric's Enlighten tech was added to UE3 last year. It seems likely to me that it would be the same thing in 4.

I agree it's incredibly neat -- but let's say I'm just personally most interested in the core engine side of things -- much less a however-advanced "Game Studio" of sorts. Is it compelling -- you bet.

Indeed. Having been in the game industry for close to a decade now (apropos of this thread, my first job was at Epic Games as an engine programmer working on UE2 and UE3), I can't say I personally learned a lot from Gregory's book (outside of some tidbits on character animation, where the book is especially strong), but I can say that it's the best book on the subject I've read.

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!).

When I started learning I spent a lot of time reading NeHe tutorials. But modern OpenGL feels so far removed from those tutorials that it feels like learning a completely different API.

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/

If you want to know all of the math and functions involved in pushing individual pixels to the screen and building something along the lines of a Quake 2-level engine in software, this book is a pretty good introduction to it all:

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

It might be worthwhile to take a look at certain types of game engine architectures.

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 thought Kismet was pseudo-script (albeit with a GUI).

Edit: http://www.unrealengine.com/features/kismet/

Yeah definitely -- I guess what I meant was that there's now an interface to manipulate code, without having to touch code, and then it automatically goes through the process you mentioned