Notch rips this thing a new one, explaining how exactly it's impossible.
Except Notch is not a competent programmer. So whatever Notch rips, doesn't really gives it any less merit. Everything he has claimed in the past to be impossible to be done with minecraft is being done by modders. The only credit I give Notch is for sticking to his project.
Did you actually read what Notch wrote? It's generally a pretty accurate assessment in this case. The main gist of it is it isn't nearly as impressive as they make it out to be.
Yup I did and nope it isn't. Notch assumes, wrongly I might add, that you need to know every single atom in order for things to render or even work when in reality, most voxel engines only care about surface atom, so his working memory assessment are verily wrong. Secondly, subdatasets let you take a big area and say plainly, it's composed of this. So you use waaay less than a single byte pet atom to fill up an area. When you have subdatasets of elements present all over the place, for example, a rock, you have a single rock composed of atoms and then elements that say "There's a rock in this position, with this rotation, and this deformation." therefore you only have a tiny overhead of bypes in the memory per rock and you can have thousands of them with little memory cost, simply because you have a default rock.
This is also used in rendering tricks, where you render a single person once and then use it as a base to create a huge population. If you want an example of this, one of the Hitman games had a scene where you had to walk through a few hundred people, all rendered on the fly, using the very same technology in question.
Seriously, if there's one thing notch is not good at is managing memory and data. Minecraft absolutely sucks at that. Don't listen to him.
As for the rock example I gave, lets say the rock itself has around 10megabytes worth of atoms. Now lets lets say each (data) tree structure has the following elements:
3D positioning - 3 * 8byte (64bit float)
3D rotation - 2 * 8byte (64bit float)
3D deformation vectors - Array of 1 to 3 * 8byte (64bit float again)
Now, lets say that on average, each rock has 2 deformation vectors that deform on average 2 axis each. Each rock would have an overhead of 72byte on average. Now... Lets say we have 100 thousand rocks in a scene. That uses 6.86mb of ram. For 100000 rocks. If a rock gets thrown around, only 5*8bytes get changed. The only case in which the rock would take more space was if you actually changed its atoms, so you'd have to create an instance of a sub data set in which you tell which atoms got changed, which would still take less than the size of the original rock.
So yes, the trick is in searching that tree-like database fast enough to pick a given atom of the root-rock decide which color should be placed on the pixel you're drawing.
As for lightning and other screen effects, don't fool yourself much, even with our 3d games, it's all based on cheap tricks and illusions for speed and that can be applied just the same to this. For example, the rock element could have a shader just like polygon objects do and that could texture it and do all the fun things 3D engines do right now, just without using polygons.