
BioShock Infinite Lighting  - jamesmiller5
http://solid-angle.blogspot.com/2014/03/bioshock-infinite-lighting.html
======
danso
> _Programmers don 't generally have reels, but we do have blogs. I've been
> explaining the rendering work I did on BioShock Infinite quite a bit due to
> recent events, and I thought it made sense to write some of it down here.
> For the bulk of development, I was the only on-site graphics programmer. As
> Principal Graphics Programmer I did quite a bit of implementation, but also
> coordinated and tasked any offsite rendering work._

Kudos to the OP...I wish more graphics programmers did this. I got into
programming because I wanted to do game development but never got into it, but
I'm still fascinated by the actual work...not so much the gameplay programming
(though I love reading about design choices), but just, well, how it differs
from web development. I loved programming in OpenGL, but I've wondered how
much linear algebra you bounce in your head on a day-to-day basis in the
professional world, and what is the equivalent to "Rails", if any, for
graphics work, and if there isn't such a thing, what about graphics
development makes such a conceptual framework impossible or unrealistic? And
is graphics programming as constrained by the artist workflow as web
development is constrained by content-makers/writers?

\---

And a little more both on and off topic: reading the OP makes me sad that
Bioshock Infinite had such a beautifully-realized world...but focused a
disproportionately amount of gameplay on how to best grind generic-policemens'
faces with a meathook.

~~~
flipgimble
> Kudos to the OP...I wish more graphics programmers did this.

In my experience this mostly happens when a game programmers are switching
jobs. Compared to the open source community, or indie community, console game
developers rarely publicize their work. To be fair, most of them are under NDA
and under a time crunch.

> what is the equivalent to "Rails"

Unity... its "Rails" for game development in general. You can do simple things
quickly, and you can dig deeper into shaders and (if you have the commercial
version) some advanced visual effects. Of course its not a substitute for
writing your own, but unlike writing your own engine, you might actually
finish a project with Unity :-)

~~~
Cthulhu_
> To be fair, most of them are under NDA and under a time crunch.

Notable exception being of course ID / Carmack, who open source their engine
after a number of years. <3

~~~
kibibu
I have my doubts that idTech5 will ever be GPL'd

------
GuiA
I find this stuff fascinating; I used to mess with OpenGL quite a bit in high
school/college, but then moved to HCI in grad school and iOS dev/backend web
dev later when I moved into the industry.

I'd love to eventually work on that kind of stuff full time- how would one go
about making the transition? Do you basically have to learn/work on projects
like this during your free time, and hope your "portfolio" gets you a job?

~~~
jheriko
> Do you basically have to learn/work on projects like this during your free
> time, and hope your "portfolio" gets you a job?

I always thought this and i applied for my first industry job with a game demo
and some tech demos built on a moderately over engineered engine, and my
second one with a fps demo with most standard last gen (360/PS3) lighting
features and support for real world data formats (quake 2/3 bsp, md2, obj,
3ds, lwo, png, tga, jpg etc.) and a tools pipeline involving radiant and the
appropriate game bsp compilers to create levels.

sadly most people i have worked with have made no serious demos or games in
their spare time and this is much less common than i had imagined.

knowledge about things like rendering, audio, AI, networking is rarer and will
help - however a gameplay programmer is a thing - although despite it seeming
like a super generic role there is a skill to creating good and flexible
gameplay systems for designers, or in picking the right hacky function to make
something 'feel' 'fun'.

oh and be prepared for low pay on the way in - you don't have to tolerate it
but i've heard salaries ranging from /actually very illegal/ to £20k for new
juniors. i took £17k for my first - if i had known better - and esp the pay
rates of my compatriots then i would have asked for more from the beginning...

also try agencies if you don't know many games companies.. you will never be
able to rid them from your life and they will do stupid things like call you
at your current job and speak to your boss when they can't get through to your
personal phone - but its their job to find you something or be honest if they
think its not possible.

~~~
ohblahitsme
Did the portfolio work for getting a job? For some reason the games industry
seems quite impenetrable to me, so I'd like to know what worked/didn't for
getting a job in it.

~~~
jheriko
i had a friend who recommended me and thats always the best way - however the
only real good advice i can give is to keep trying. some of the juniors i have
encountered doing their first jobs found them through agencies, former
university colleages, applying to their favorite games company etc.

however, yes the demos helped considerably... its a very strong proof of
knowledge and skill. a working demo of reasonable complexity is worth more
than any level of academic background or past experience outside the industry
imo. you just need to get it seen.

as a programmer i can't really offer much advice for design, art or production
though. i imagine design and production is basically luck or attitude to get
into - everyone wants to do it and the skill is difficult to measure. artists
tend to have impressive portfolios and/or showreels demonstrating past work
and personal projects...

A surprising amount of production staff have a background in the QA department
in my experience too... QA is definitely a way in for all the disciplines but
I have no experience of how that works well.

------
gavanwoolery
I'm a big proponent of unrealistic lighting in games, for two reasons:

1) Trying to simulate realistic lighting in realtime is a fool's errand - even
with every trick we know, lighting can never look completely realistic on
today's hardware.

2) There is a certain art to unrealistic lighting. We see reality all the time
and it is fairly boring, why not take advantage of the simulation to produce
something visually interesting? I recently revamped my lighting for an
unrealistic, but stylistic look:

    
    
      http://i.imgur.com/t1gC4ME.png

~~~
aras_p
Side note: there's a recent push towards "physically based rendering" (in
games; film folks have made that a few years ago). This means making light
behave in a physically plausible way. This is different from "photo realistic
rendering".

Probably best example is Pixar's rendering style - it's not "realistic", but
it is very much at the forefront of "physically based".

~~~
tomlu
This is partially because of difficulty of debugging a completely ad-hoc
pipeline.

When you have 50 moving parts and the final image doesn't look right, it's
hard to know where the problem is. Instead, you try to make each part adhere
to "reality" by making them "physically based", thus enabling objective
testing.

~~~
aras_p
Yes. It can also be cheaper to make, since the same material can look good
under more different lighting conditions. So an artist can make the textures &
material once and it will mostly look "correct" when put in anywhere. As
opposed to older ad-hoc models where often in a different lighting setup at
least some parts had to be redone.

Just wanted to make a distinction between "physically based/plausible" and
"photorealistic", since I've seen both being mixed up a lot of times.

------
cousin_it
I want a lighting algorithm that handles static and dynamic geometry
uniformly, with respect to lighting and shadows, and still manages to look
"good enough", if not necessarily cutting edge. Does such a thing exist?

The last such approach that I remember was Doom 3's stencil shadows, but it
handled only direct lighting. Now that people are used to approximate indirect
lighting, we get these huge piles of hacks and we have to reinvent them for
every new art style...

~~~
wlesieutre
Crassin's "Interactive Indirect Illumination Using Voxel Cone Tracing" [1]
might be of interest. A snippet from the second page:

> We handle fully dynamic scenes, thanks to a new real-time mesh voxelization
> and octree building and filtering algorithm that efficiently exploits the
> GPU rasterization pipeline. This octree representation is built once for the
> static part of the scene, and is then updated interactively with moving
> objects or dynamic modifications on the environment (like breaking a wall or
> opening a door).

It takes a somewhat beefy computer to run, but the results are impressive. I
don't have a link handy, but there was a UE4 editor demo showing some of it a
few months ago. IIRC it's been axed as a feature because it wouldn't have run
well enough across all of the platforms they were targeting.

[1] [https://research.nvidia.com/publication/interactive-
indirect...](https://research.nvidia.com/publication/interactive-indirect-
illumination-using-voxel-cone-tracing)

~~~
Arelius
So, Voxel Cone Tracing doesn't actually treat static and dynamic geometry as
the same. It makes two hierarchical voxel trees, one static, and pre-built.
and the other dynamic, and generated per frame. This is really the only way it
can stay performant.

~~~
wlesieutre
Not quite. They're all the same to the lighting/shadowing calculations, but it
doesn't re-voxelize geometry that didn't change between frames.

From section 4.2:

> Both semi-static and fully dynamic objects are stored in the same octree
> structure for an easy traversal and a unified filtering. A time-stamp
> mechanism is used to differentiate both types, in order to prevent semi-
> static parts of the scene to be destructed in each frame. Our structure
> construction algorithm performs in two steps: octree building and MIP-
> mapping of the values.

------
jheriko
Good article. Lots of high-level generic detail :)

> Dynamic shadows from toggleable lights would be projected into this buffer
> using a MIN blend

Just wanted to quote this because as much as i love id and JC this bugged the
crap out of me in Rage. Overlapping shadows from the same light source do not
combine irl :P

------
vacri
To me the lighting in Infinite was completely overwhelmed by everything
looking like you were viewing it through a cloud of flour if the scene was
'bright' at all. I nearly stopped playing several times because of that issue
alone.

------
n1ghtmare_
As a web developer this looks very complicated, reading stuff like this makes
me feel useless. I wonder whether game developers feel the same reading about
the web stack.

~~~
aras_p
Yes, very much so.

I'm a graphics programmer at Unity (the game engine), and recently I toyed
around with Rails. That made me realize _how much_ of assumed knowledge and
jargon is in any particular field.

As a complete noob, all the information in Rails case sounds like "yeah you
just rake your gems, bundle the capistrano and don't forget to bootstrap the
angular node" \-- stop, WHAT?! And all this while trying to do a _very_ simple
"hello, world" CRUD app.

I'd imagine graphics programming sounds exactly like that from outside, just
with different words. "Oh yeah, you just swizzle your lanes, dispatch the
predication queries and don't forget to Fresnel your BRDFs" _(no, this
sentence does not make any sense whatsoever)_.

Of course if I'd spend even a month in the Rails/web field, I could at least
navigate without bumping into everything. Spending a year or two would
probably make me comfortable. Same with game or graphics programming. The
author of original blog post has been doing this for 20 years...

~~~
n1ghtmare_
Yeah that's exactly how your jargon sounds to me :) I fiddled with Unity
everyone was saying it's "simple"/"easy" ... Sure it is :)))

You know, it's funny how people out of our industry perceive us (at least in
my experience) - I mean you say you're a programmer and it's immediately
presumed that you just know computers and coding, but we have so many
branches, languages, platforms at times it's absolutely overwhelming.

Outside of the basics of programming (you know algorithms, runtime analysis,
basic code structure) we have almost nothing in common. It now starts to make
sense why the big companies interview in these areas.

~~~
aras_p
"you you're a dentist? good, that means you know how to do a surgery. both are
medical field, right." :)

