That system is indeed quite nice. While I can totally believe that they can push that level of geometric complexity through a modern GPU at that speed, I am a bit at a loss about how they apply the animation modifiers while maintaining the frame rate. I guess you could get away with doing that on the CPU considering the low complexity of the control meshes.

Still, it's awesome. That's what you can pull off once to can afford to throw a bunch of programmers at such a problem for sufficiently long time...

The high end is where RenderMan shines. This is a tool for experts. The studios that use RenderMan pay people to become experts in very specific domains (modeling, shading and lighting are separate domains for these people) and this software has been the ultimate tool for the shading and lighting stages for the last 2 decades.

However, as the summary notes, Arnold is the new shooting star among production renderers. It's a completely different beast - different basic algorithms which imply different ways of dealing with it, but at the benefit that the results usually obey the laws of physics without further ado. RenderMan was never designed to work that way, yet this is what the VFX industry moves towards.

In very simple terms: RenderMan is a software that is used to convert 3d scenes into 2d images. It would never replace Blender or other 3d modeling tools - they complement each other.

Above ground has two disadvantages that come to my mind:

1. You have to guarantee for the maintenance of the storage facility. Otherwise it will decay and expose the stored material to the outside world. This is a problem in the long term because you have to preserve the technology and knowledge on how to do it as well as keep the personnel around.

2. Any kind of waste is better protected from any forces on the surface when buried underground. Natural disasters and man-made weapons or tools can destroy anything we can build above ground and expose its content. This is a lot harder when you have hundreds of meters of solid ground to dig through first. Nukes detonated on or above the surface won't do that much damage down there and won't form craters deep enough to release any waste stored down there. And those are the most powerful weapons we currently have.

You can easily kill performance by doing stupid things, like uploading textures in formats the driver doesn't like that much (that one actually surprised me a lot, but it can matter). Or like loading the data in an order that keeps the disk seeking when it could instead be reading. The later is something that gets optimized for a lot on consoles where the optical disk seek times are a nightmare.

In which aspect? DirectX and OpenGL generally have enjoyed feature parity in the last couple of years. OpenGL even makes it easier for hardware vendors to expose new features to programs. So you won't hear a complaint from me regarding that.

BUT: the tools suck. I don't know about current tools for DirectX now that PiX is dead and burried, but I can state that the current tools for OpenGL are definitely not good - to put it mildly. It's still embarrassing to see AMD CodeXL not show a texture for with a format that has been in the OpenGL spec as mandatory format since 3.0 (that is, for 5 years now). I'm unable to figure out how the viewers for VBOs and textures in nVidia nSight is supposed to work. And none of the tools the hardware vendors provide can do GLSL debugging....

OpenGL has an exactly identical mechanism for storing the results of compiled shaders. The problem is that the game then has to watch out for changes in driver versions and recompile the shaders after each change because the OpenGL spec says that compiled shaders are only valid for the exact same combination of driver and hardware. So this is not such a useful feature.

That's one of the funny things about OSS: when it comes to graphics, I perceive open source software to be mostly lagging behind by a couple of years at least. - whether it's 2d image manipulation, 3d modelling, offline rendering or real-time rendering. Somehow these topics don't get that much attention from the OSS community. Is it because so many hackers think that the purpose of X11 is to render more than one terminal window at once and the purpose of the window manager is to keep them arranged? Who needs window decorations with mouse buttons when you can do your window management with obscure keyboard shortcuts? People who work this way can often do awesome things with shells and programming languages, but at least 9 of 10 of them don't seem to care for graphics in any way. Those that remain are not enough to put the manpower to build decent OSS graphics software.

OpenGL works... if you use proprietary drivers, which aren't installed by default and most OSS zealots users won't install them and end user distros don't install them automatically. But especially the nVidia proprietary driver is really good and the only sane OpenGL implementation on Linux that I know. Mesa typically is sort-of OpenGL compatible but leaves out features in unexpected places - either because they are not done yet or more annoyingly because they don't want them to be in there for political reasons. At times Mesa even goes as far as claiming that something works OK when in reality it is faked in a way that is totally broken. I still remember the night shifts I've had because of that one...

Alright, I've mentioned elsewhere in this discussion that recording the whole light field data at decent framerates isn't currently possible in an economically feasible way. It could be done if you throw enough money at the problem, but at that point it's cheaper to redo the shot a couple of times.

Hm, I'm not sure that this kind of camera is able to generate good depth maps. The visualization that helps adjust the focal range in this demo video illustrates the point: it is basically an edge detection filter run on each focal depth that gets recorded. If it finds an edge thin enough then that area must be in focus and gets highlighted. This is why edges get highlighted, but not surfaces with low frequency textures. Finding the sharpest image of a low frequency texture in a focal stack is not a simple thing and this is where the generated depth maps will also break. The nasty part about this is that all the large and rather flat areas in your image will end up suffering.

As far as I remember, the Lytro cameras use a micro-lenslet array to refocus the image differently for different patches on the sensor. So it is recording multiple focal planes at once. But when you dig a bit into light field representations and light field interpolation (e.g. the original light field and lumigraph papers), then you'll probably see that you can process the data in more interesting ways than simply flipping through a focal stack.

That would be the equivalent of a 80 megapixel raw video in order to retain all the viewing/editing capabilities afterwards... storing that away in real time isn't yet economic. And I honestly have no idea if there is a decent compression scheme for the data, either.

So you want to strap yourself to an exploding console? Neat!

I actually wonder at the many plot devices that placed high power conduits through control consoles. I mean, really? Why wouldn't you design the bridge system as low power system sending control signals to high power equipment in some cabinets a few firewalls away?

Almost all characters in TNG got twisted and bent to fit the plot at some point or another. This is really annoying to watch at times. I find it amazing that the actors put up with that and managed to act out these scripts. There's actually some really good acting from almost all main actors in there, but also a good amount of bad acting as well.

As far as I can tell the problems aren't the Realtek chips themselves, but some half-assed mainboard integration. The snd-hda-intel driver is full of workarounds for wrongly connected chips. Plus, nobody cares for the quality of the analog audio signal which is generated and amplified on the board. The result is fucking terrible. I can listen to my programs working when I connect my headphones to the onboard audio. At times I was able to tell which stage of the algorithm the GPU was computing from the noise.