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.
40GB is going to be the start of the future. With every new generation of consoles so far the size of the game data increases *a lot* because the new generation of console hardware is capable of handling that and competition with other game titles required that the hardware gets pushed to the limit. Get used to it!
Randomness in sensor data surely exists. Take a recording with your computer's microphone or line-in port with maximum amplification and take the least significant bit of each sample. Unless you manage to get a recording where each and every sample is clipped (most won't be, even if you have clipping), the result is very random and absolutely not predictable.
Actually, it is quite true. Slowness in Java can come from many things (inefficient algorithms, inefficient memory usage, overloading the GC with too many claimable objects on the heap,...), but the code that JITs generate for Java can be very good and fast. At least Sun's/Oracle's JVM really can claim a good performance. I've benchmarked it repeatedly by porting Java code to C++ and running it on the same problem. And I've been surprised. If there's a big performance difference somewhere it's most likely because your own code is doing something wrong and there's often a way to fix it. Of all the things annoying or broken in Java, raw execution speed isn't.
Well, neither gtk nor qt use any drawing primitives within X. They have their own, quite complex internal rendering backends for that and just push the resulting images to the X server in many cases. The reality is a bit more complex than that because they can draw things entirely in software, use OpenGL acceleration, fall back onto the X server for some things where it is useful and so on. But essentially, when you run a gtk and a Qt application at the same time, you're already running that kind of duplication. So with a lightweight display server you get at least the third independent implementation out of your RAM.
Given that the front of those cars is already loaded with sensors for loads of other stuff (braking assistants, etc.) it shouldn't be hard to try to actually figure out the shape of the road ahead...
He is the head of the state. Similar separations of offices exist in other countries. The Weimar constitution did give the President a lot of powers, for instance, to declare a state of emergency and to take any emergency measures he deems necessary. This was a loophole that was exploited by Hitler.
The successor of the that constitution removed almost all remaining powers from the President. This is a mostly representative role these days with very little freedom for making decisions. Most of his tasks (appointing the Chancellor and Ministers, signing laws etc.) are strictly mandated by the constitution. The only exception I know is that he may call the "Bundesverfassungsgericht" (special court ruling on matters related to the constitution) before signing a law if there are serious doubts about the law being in accordance with the constitution.
Same here, strangely enough. Looks like a measure to avoid load caused by foreigners that got curious from all the bad reporting that this website got.
The film opens with a recruitment commercial which is a bit over the top and then shows a small ad like piece of clear propaganda about the new planetary defenses. This should make you suspicious of the tone of the film right there. And as the film goes on, these inserts become more and more ludicrous.
Slashdot Mirror
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.
40GB is going to be the start of the future. With every new generation of consoles so far the size of the game data increases *a lot* because the new generation of console hardware is capable of handling that and competition with other game titles required that the hardware gets pushed to the limit. Get used to it!
And the show is more about the hidden costs of that "business" and the related lifestyle...
Randomness in sensor data surely exists. Take a recording with your computer's microphone or line-in port with maximum amplification and take the least significant bit of each sample. Unless you manage to get a recording where each and every sample is clipped (most won't be, even if you have clipping), the result is very random and absolutely not predictable.
Actually, it is quite true. Slowness in Java can come from many things (inefficient algorithms, inefficient memory usage, overloading the GC with too many claimable objects on the heap, ...), but the code that JITs generate for Java can be very good and fast. At least Sun's/Oracle's JVM really can claim a good performance. I've benchmarked it repeatedly by porting Java code to C++ and running it on the same problem. And I've been surprised. If there's a big performance difference somewhere it's most likely because your own code is doing something wrong and there's often a way to fix it. Of all the things annoying or broken in Java, raw execution speed isn't.
Well, neither gtk nor qt use any drawing primitives within X. They have their own, quite complex internal rendering backends for that and just push the resulting images to the X server in many cases. The reality is a bit more complex than that because they can draw things entirely in software, use OpenGL acceleration, fall back onto the X server for some things where it is useful and so on. But essentially, when you run a gtk and a Qt application at the same time, you're already running that kind of duplication. So with a lightweight display server you get at least the third independent implementation out of your RAM.
Given that the front of those cars is already loaded with sensors for loads of other stuff (braking assistants, etc.) it shouldn't be hard to try to actually figure out the shape of the road ahead...
He is the head of the state. Similar separations of offices exist in other countries. The Weimar constitution did give the President a lot of powers, for instance, to declare a state of emergency and to take any emergency measures he deems necessary. This was a loophole that was exploited by Hitler.
The successor of the that constitution removed almost all remaining powers from the President. This is a mostly representative role these days with very little freedom for making decisions. Most of his tasks (appointing the Chancellor and Ministers, signing laws etc.) are strictly mandated by the constitution. The only exception I know is that he may call the "Bundesverfassungsgericht" (special court ruling on matters related to the constitution) before signing a law if there are serious doubts about the law being in accordance with the constitution.
No, its the head of the executive branch similar to the US President or UK Prime Minister. Chancellor is just a German name for that position.
Same here, strangely enough. Looks like a measure to avoid load caused by foreigners that got curious from all the bad reporting that this website got.
The film opens with a recruitment commercial which is a bit over the top and then shows a small ad like piece of clear propaganda about the new planetary defenses. This should make you suspicious of the tone of the film right there. And as the film goes on, these inserts become more and more ludicrous.