the first image is fuzzy (AA at low rez perhaps?).
the second two are good. hi rez. doesn't seem to be textures, just high rez small solid voxels. and good lighting with some shadows.
the last image is simply too low rez, and thus pixelated.
Tell me more about that "good lighting", that's what I want to know.
And in last image, I don't think that pixelation or texture is what makes it look bad, it's probably poor lighting and shading.
the first image is fuzzy (AA at low rez perhaps?).
the second two are good. hi rez. doesn't seem to be textures, just high rez small solid voxels. and good lighting with some shadows.
the last image is simply too low rez, and thus pixelated.
Tell me more about that "good lighting", that's what I want to know.
And in last image, I don't think that pixelation or texture is what makes it look bad, it's probably poor lighting and shading.
in the minecraft shot, there is no lighting/shadows at all?
Tell me more about that "good lighting", that's what I want to know.
The top images seem rendered offline, hard to tell if they use AO or radiosity, but it's very high quality. Probably minutes per frame.
(The last one definitely uses full GI, not just AO)
Soft shadows and AO/GI probably raytraced, using hundreds of rays per pixel.
Realtime games use cheaper approximisations and they won't look that good.
Voxelization can be used to do GI in real time (Cone Tracing), not yet used in a realeased game(?), see Tomorrow Children or Deep Down on PS4
Tomb Raider DX12 added voxelized AO.
Those techniques don't suffer from missing information of cheaper screenspace tricks, but they are expensive, harder to implement and still unable to reach the quality from those shots for a large game world.
The traditional approach is to precompute as much as possible, store in lightmaps / lightprobes, combine with realtime lights using shadowmaps.
Works only for mainly static scenes.
A minecraft style game where the user can change the world would need to update (and store) the lighting on demand - very complicated.
Minecraft solves it by updating some AO thing per block assuming light direction from above, and adding some directional shading from the sun ignoring shadows.
(Not sure about the details, but this is how it looks. Your screensot lacks this feature). That's pretty solid and beats screenspace AO on a larger scale.
Lighting is a very large topic...
If everything is static, would it be possible to just bake everything into the texture to achieve this look in real-time? If I bake texture + GI/AO, would it be possible to later change the scene lighting in real-time easily?
How is radiosity different from AO?
@Kryzon god damn, it looks beautiful. He seems to be using the same magic lighting I'm trying to find out more about.
Yes, this image is a perfect fit for baked lighting. Yo can do this without any worries about performance or hard implementations :)
To make it work, easiest way is to add nonoverlapping UVs for a single texture for the whole model (UV unwrap).
Any 3D modeling packege should be able to bake lighting to texture using this UV map for you.
How is radiosity different from AO?
Radiosity assumes perfect diffuse surfaces everywhere and calculates the light interreflections from each surface to each other.
Because there are no reflections, surface light is view independent, so everything can be precomputed to a single color per lightmap texel.
AO looks for blocking near geometry. More blocking -> less chance to receive light -> darken the surface. (Typical darkening in corners)
Looks best in combination with a enviroment mapped light source, e.g. a prefiltered image with sky and sun that gives light on given surface normal.
View dependent too, but not physically correct.
Seems the Mario images uses AO, because i can't spot any color bleeding.
Comparing AO / radiosity with simple direct lighting there's a big difference:
Radiosity makes the image brighter with every additional bounce of light (reality has infinite bounces)
AO can only make the image darker.
GI = Everything. Similar to radiosity, but also handling non diffuse materials (reflections, refractions, scattering).
Because Reflections ar not view independent, it's not possible to bake it except for bump mapping or very glossy reflection demands (directional light maps).
nvm, didn't read the thread carefully enough before answering... now, if only there was a delete button 
If all voxels have the same geometry(cube) and AO doesn't depend on lighting, wouldn't it be possible to bake AO for a single voxel and reuse it for all? E.g. bake normal edge AO and 90 degree angle AO and just somehow calculate where to put it. Might be some more edge cases, but idea stays the same. This way we could get high quality AO without sacrificing performance.
The bad example is:
- flat shaded
- textured without texture filtering
The good example is:
- not textured
- shaded (though even with flat normals)
- shadowed
- perfectly antialiased
- using some form of good ambient occlusion/ambient light
Without seeing the good example in motion, you cannot realy know yet how good it is though. Depth light can provide great stills, but is unusable in moving dynamic scene, unless extremly weak.
