BioShock Infinite Lighting
solid-angle.blogspot.com
solid-angle.blogspot.com
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.
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 :-)
Notable exception being of course ID / Carmack, who open source their engine after a number of years. <3
Riddled with terrible amateur mistakes, awful design choices and some truly embarrassing bugs. The overhead is huge and the respect for memory and performance is really far from what I've seen working on in-house code or with popular engines.
The editor however is very finished and if you want to make a game rather than learn its definitely the way to go.
There is good bit of overhead from the Mono .NET scripting runtime, which is never going to be as optimal as (hard to write correctly) native code, but then again its light years compared to most game scripting designs. I've also seen some in-house AAA engines, and expensive licensed engines with the same performance and memory issues. Thats why they hire people like AO to beat an engine into shape.
Do you have any links or references to substantiate "amateur mistakes, awful design choices and some truly embarrassing bugs"?
Granted, one embarrassing thing about Unity is the infamous and prolonged lack of any viable built-in UI solution.
i had some real issues with the physics not being deterministic or handling the most common edge cases like high speed objects with thin colliders. i'm inclined not to blame PhysX... tbh part of this is poor game design on our part that it was a problem. we should know better than to want to rely on deterministic physics...
i don't think they have particularly implemented components well. but that can be personal taste - everything having a transform is reasonable but the implementation of transform itself i find terrifying and confusing. it seems to really be an elaborate tree thing containing the whole hierarchy...
if i want to iterate over all of the components of a given type i have to use some scary looking functions with 'find' in their name which suggest to me not really understanding the implementation benefits of components...
scales live in the matrices...
the maths library is missing lots of common things and is messy (eg. vector3.lerp vs. mathf.lerp) some of this is because c# makes performant syntactic sugar hard with its lack of clean non-temporary references (you can use boxing but it is, in theory at least, slow)
the random number generator is not very good - maybe its a mersenne twister or something suitably complex but the results are easily beaten with the usual LCGs (which have their own classic problems).
the game object interface is not very complete. where are get and set position? i apply them to the transform? does it cache this? in short my confidence is broken when something like moving an object is handled poorly - its a classic case of something you often want to cache until the next frame and imo that should be a clear part of the entity/game object system not something you have to investigate or write yourself. i find myself writing functions to get lists of children - finding that including self as a child is vague and ambiguous in the built in functions and so make aliases for them so i don't have to get confused by that... find parents and children requires going through the transform? that is - to me - severely broken encapsulation. forget the class keyword - the spirit of OO is worth following imo (if not the die hard 'everything is an object' approach).
the overheads of .net are there but they do not cause me a problem afaik.
all my problems can be summed up as 'i don't like writing this code i always have to write for any game - why isn't it in your engine already? i would have put it there.'
the editor is really good i can't say that enough. its a small sentence but the implications are enormous... its what makes unity so good for making things quickly.
really as an argument that is super significant... making tools regardless of how is enormously time consuming compared to working around the issues i describe.
i've worked at 'AAA' studios - some of them are pretty appalling too. lots of programmer wankfest code for 'performance' which is completely unjustified if you go and measure it... tbh i'm embarassed with the state of gamedevs. i stayed out of the industry for a long time (my fault) assuming i wasn't good enough - when i finally got in the most overwhelming lesson was that the quality bar is much lower than i could have imagined... even in the engine, rendering, audio etc. specialist areas...
While graphics programmers never update their blogs as much as many would want (which is true of almost all bloggers with interesting things to write about), if you instead look at a large set of graphics programmer blogs, you get new posts all the time.
And, good news! Someone has been collecting them :)
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?
It's really that easy, as strange as it sounds. Just find some graphics stuff you like doing, and do it a lot.
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.
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.
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.pngAlso reminds me "Das Cabinet des Dr. Caligari" where they were using expresionism in costumes, acting and in the set..
Probably tjats where the future of rendering is.. freedom from reality.. we already have one, isnt? :)
Probably best example is Pixar's rendering style - it's not "realistic", but it is very much at the forefront of "physically based".
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.
Just wanted to make a distinction between "physically based/plausible" and "photorealistic", since I've seen both being mixed up a lot of times.
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...
> 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...
The original article describes the careful technical tradeoffs and mixing/matching of techniques that is required to pull off a game like Bioshock Infinite on ancient hardware (at least as relative to current PCs and high-end GPUs).
Interestingly when Unreal Engine 3 was first being demonstrated to potential licensees and in the media, it was using a very high quality and elegant one-pass per light rendering algorithm. The demo scenes were basically a room or hallway with several colored lights, and the resulting multicolored shadows cast by an animated character. In 2004/5 this blew people away and a lot of game executives signed expensive licensing deals with Epic. No games to my knowledge actually shipped with that type of lighting, at least on a console. Then Epic and engineers like the author of the article spend the next several years (an entire console generation really) retrofitting UE3 with actually practical rendering technology that involved a lot of sacrifices, careful balancing, and artist headaches.
This generation Epic is showing a mind blowing UE4 demo with Voxel Cone Tracing and the cycle starts again.
One thing is very clear to me, Irrational threw out a ton of invaluable institutional knowledge when they laid off that team. I suspect competing studios, especially those using Unreal, are scrambling and having a bidding war trying to hire them.
http://www.joystiq.com/2012/06/08/unreal-engine-4-demo-decon...
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.
there is an argument that high quality shadow maps can encode the penumbra, but current gen console hardware is miles away from that quality (top end PC hardware is not).
nowadays with stencil shadows there are performance arguments - we would rather use our fill rate on HD resolutions, deferred passes and post effects. there is also the potential patent issue (is that still a thing? its embarrassing really for such a trivial algorithm :( )
> 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
That said, graphics engine development is very technically and mathematically advanced, I would say much more so than the web stack.
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...
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.
Try flask --> http://flask.pocoo.org/