Minecraft Forums

After a bit more poking, it seams the mipmap and AA filters alredy present are responsible for the decrease to 190. It is possible to turn those filters off with optifine, however the textures then start producing a nasty moire pattern arround 210.

Quote from JingKob

After a bit more poking, it seams the mipmap and AA filters alredy present are responsible for the decrease to 190. It is possible to turn those filters off with optifine, however the textures then start producing a nasty moire pattern arround 210.

As in, the distance is ~12 chunks regardless of actual screen or window resolution? Is it possible to manually control the distance by tweaking settings in the filters?

tonight I'll do some testing with different texture sizes. With the right sized textures at various distances, we may be able to do away with most of those filters compleatly.

Am I correct in assuming that the filters get applied at the GPU level?

If so; is there even any point in turning them off? Do they mess with your distant LOD texture approach or something?

Mipmaps decrease texture detail at a distance to make distant objects with the same resolution texture as close object look better. However, if you decrease the texture size for distant objects instead, you may be able to keep a better level of detail at a distance. This will save on video memory and possibly increase preformance. i cant see blurring the optimized textures as helping much anything. But I could be wrong. I'm going to try a few things after work.

For those scholastically inclined, this technique is pretty close to what I am basing that global illumination proposal on (for the lazy, it's a paper on the global illumination used in CryEngine 3). The pdf is the actual paper, but the ppt is a good companion resource. There is a second paper here, which goes into greater detail about the implementation.

A few interesting considerations from this (will probably only make sense if you read the paper):

1. They are getting away with a mere second-order spherical harmonic representation. That's just 4 floats. If a cell covered a 4^3 volume of blocks, the SH would win just in terms of raw storage.
2. All the spheres are mapped to a uniform grid with no change in resolution. To handle greater volumes, they used additional grids,but the grids do not interact apart from sampling light from the same sources.
3. After looking around, I can't actually find any sources describing a good way to propagate light in a multiresolution grid of SH. That's not a good start, but since these techniques are centralized around GPU implementations, that doesn't necessarily mean it doesn't work.
4. Light-blocking obstacles are also stored as SH. That's not something I had considered. Not sure if that'll be particularly important here, though, since a CPU implementation has a lot more options in terms of logical processing. If this was able to tie into the built-in occlusion culling, even better.
5. The light propagation grid doesn't handle interaction within a single cell. That means some level of degree of local lighting will still be needed. That said, this implementation is still useful for its ability to illuminate things more than 14 blocks away.
6. Using this cell structure could be problematic due to the relative size and discreteness of the voxels in question. If you have a shaft of light entering a cave from a hole in the ceiling and it hits the floor squarely, in this model, that light is going to bounce predominantly upward and illuminate the ceiling, but the horizontal spread of light from that first bounce would be almost nonexistent. In truth, this is actually what would happen in the real world with perfectly head-on lighting (and probably look pretty damn cool from a cinematic standpoint), but it would also be impractical from a gameplay standpoint since sun shafts would not effectively light areas anymore.
7. A practical solution to 6. would be to "cheat" a little and redirect some of the light from each light source in the opposite direction it was pointing. If you completely level out the directional intensity and make it 100% isotropic, you're basically left with traditional minecraft lighting, so there's no reason to think some configurable middleground wouldn't work. I have no idea what sort of effect feedback might have on the propagation system, though.
8. Additionally, I'm not convinced it's actually necessary to maintain a uniform grid of SH. Ideally, each SH should have a decent vantage point over the blocks in its domain and roughly contour to the physical surfaces, since that's where the action is. That may be too much thinking for a GPU but who's to say that's still the case on a CPU? One disadvantage is that we wouldn't be able to use the precomputed contribution factors between grid points.
9. The big reason for doing all the global illumination stuff in the first place is to remove the need for re-lighting the full path of every light shaft every time they appear or disappear, but there is a problem to consider:. When a vertical wall is immediately adjacent to a light shaft, you would expect it to be fully lit every time since its air block is in the path of the light shaft, but since the light shaft is perfectly vertical, it actually wouldn't be lit at all. In the wild, cliff faces would be shrouded in darkness (or lightly shadowed if the ambient light is doing its job). We can easily fix this by deliberately illuminating any block face that falls into this category, but now we're back to querying blocks from every chunk again. It wouldn't be nearly as many, but it's also not zero. I have no idea whether this will become an issue or not, but it seems unavoidable.
10. We will also need to be able to track an individual light source (or batch of light sources) through the propagation volume, since we need to be able to both add and remove individual source contributions. That part should be doable. What might not be doable is tracking a propagation at a midway point (for instance, altering the terrain such that it limits the light between two nodes.) That could potentially invalidate a hefty chunk of the stored light data. That'll have to be solved or mitigated in order for this to work.
11. This approach makes no mention of ambient lighting or ambient occlusion. Presumably those are static factors in most environments. Depending on the effectiveness of the light bounces, however, it could be an important factor for us. Ambient light will work with the propagation volume, but it could be difficult to approach on an infinite grid with no well-defined entry points. Plus it can theoretically propagate infinitely, so we should avoid brute forcing that. I'll have to try some stuff.

So yeah, a lot to think about and no immediately obvious answers. That said, I'm feeling pretty good about this approach. We don't have GPU horsepower to work with, but we also don't have hundreds of light samples per cell to deal with, nor are we constrained to a 10ms window, or a fixed number of iterations, and most importantly we don't need to rebuild the whole thing from scratch every frame.

This lighting technique looks quite promising.

Mmm, I'm still concerned that accommodating a dynamic voxel environment might be a little tricky, but after reading through those links I think it seems much more feasible to me than it did the other day when you first brought it up

Quote from 4HeadTiger

Mmm, I'm still concerned that accommodating a dynamic voxel environment might be a little tricky, but after reading through those links I think it seems much more feasible to me than it did the other day when you first brought it up

Right? I mean, it's certainly not simple, but broken down, this individual parts aren't all that magic. That second-order SH, for instance, is really just an absolute magnitude with a +/- bias along the X, Y, and Z axis (which is also why they keep specifying hemispherical light rather than full freedom of movement. My original proposal expected an order or two more fidelity, but if this is enough to pull it off, even better.)

Has tall worlds made any progress In the last few months? The front page hasn't changed at all. If the mod isn't dead, you should update the front page so people don't lose hope.

Will this mod allow me to build higher?

Quote from Endguy14»

Will this mod allow me to build higher?

It's totally not like that's literally the entire point of the mod or anything...

Quote from ZacIsCool67456

Has tall worlds made any progress In the last few months? The front page hasn't changed at all. If the mod isn't dead, you should update the front page so people don't lose hope.

Why would people lose hope when the dev himself posts regularly in the actual thread? *genuine question btw*

Been spying but never actually replied, don't have anything useful to say... except COOL, this would be great for allowing massive deep oceans (under-water bases) and for things like building a sky fortress or space base

It's nice to see so many issues being worked on, water simulation, cubic chunks, long distance rendering, light simulation... and to top it off, Frost is in the fray as well!