#game lighting

Environments: Paintovers

As far as I understand it (and I am not a graphics programmer, so I really don’t understand a lot of this), most games and simulations use the “Radiosity” model to calculate lighting primarily for performance reasons. 

Radiosity operates in a finite number of passes. It first calculates the direct light from each light source onto all of the elements in the scene the light shines on. After it’s finished calculating that, the renderer calculates all of the first-order reflections from the stuff that the light source shines on. Something dull doesn’t reflect as much light as, say, something made of chrome, so the second pass would illuminate the things near the chrome object more due to its reflectivity. On the third pass, it calculates any second-order reflections from the first-order reflections, and so on and so forth. The more passes we do, the more accurate the lighting looks, but the subsequent passes tend to provide less additional accuracy than its predecessor (i.e. diminishing returns). In order to maintain a certain level of performance, we usually cap the maximum number of passes the renderer will take. This often gets us a “close enough” result.

Ray Tracing generates a more accurate simulation of what things (should) look than Radiosity because Ray Tracing will get all of the reflections instead of the maximum number of Radiosity passes, but it is much more expensive in terms of performance. The way lighting works in physical space is that light comes from a source (e.g. the sun) and bounces around the physical world until it reaches our eyeballs. Some rays of light will never reach our eyeballs - they point away from us. Ray Tracing ignores all of the light that won’t reach our eyeballs (the camera), and instead goes in reverse - if our camera can see it, there must be some path from the camera to the object and beyond, bouncing as many times as necessary, to reach the light source. Since we know all about the light source and exactly how many bounces there were and the material properties of each bounce point, we can use that to calculate what that pixel should look like.

The trouble with Ray Tracing is that those reflections and bounces could number in the hundreds or even thousands before reaching the light source. The renderer must run those calculations for each pixel its camera can see. We’ve actually had ray tracers for decades now. Writing a ray tracer is actually a great introduction to computer graphics for computer science students. A friend of mine actually wrote a ray tracer while we were in middle school, but it took the computer of the time five minutes to render out a simple scene with just one light. The main difference between then and now is that we’ve finally reached the point in graphics hardware where we can actually do those calculations in real time. That’s why ray tracing is now a big deal, it’s because it’s more accurate at lighting things than the old Radiosity model.

By the way, Disney Animation Studios put out this video in 2016 that explains how Ray Tracing works much better than I can. If you’ve got nine minutes or so and are interested in a great explanation of computer graphics technology, give it a watch.

[Join us on Discord]

The FANTa Project is currently on hiatus while I am crunching at work too busy.

[What is the FANTa project?] [Git the FANTa Project]

Got a burning question you want answered?

Short questions: Ask a Game Dev on Twitter

Long questions: Ask a Game Dev on Tumblr

So today we are back at uni and back into production of our game.

The Programmers whipped up some gifs of there work so that we can put them in our presentation to show off our mechanics  

here we have:  Movement  Ranged stun mechanic  Dash 

This is a recent work of mine done entirely in unreal engine 4.

This is a story of a demon trapped and imprisoned in a stone in the form of a sword. The only way for the demon to be free is to be wielded by a master swordsman. In the dark, cold solitude the sword awaits its wielder.