Gameplay
Cubic Chunks: Reduced lag, infinite height, and more [The #1 Suggestion Thread of all time!][Updated! 6/14]
Poll: Which parts of this system do you like?
Ended May 15, 2014
Poll: Which parts of this system do you NOT like?
Ended May 15, 2014
Poll: Do you support this system's implementation overall? (If yes, if
Ended May 15, 2014
When (if) it's implemented into vanilla MC it will be epic
also you should check out Tall Worlds
I believe in the Invisible Pink Unicorn, bless her Invisible Pinkness.
would it be possible to load a small area around the player (like 5 or 6 chunk radius) and any chunks they can see (that has at least one block in it) plus some down/out from that (to help prevent world holes) up to a limit? or do (air) chunks have to be loaded to see what's on the otherside?
also with all that is being changed by Cuchaz for his mod it seems, from the perspective i have at least, that it would make more sense to recode the whole game..
-
View User Profile
-
View Posts
-
Send Message
Curse PremiumNever!
Thanks! I would really like to see the explanation explained. I'm really curious.
That is the first time the term "LOL" has actually meant something to me...
fair enough.
but what about my question?loading visible/almost visible chunks would keep all caves from getting sunlight, if a player can roughly see the chunk the roofs blocks are in.. and allow lookout towers to be useful as long as the player's display/graphics can display/process things at that scale.
i'm just putting my two cents in, but i only am just learning to program, in python, so as far as i know its fools gold.
-
View User Profile
-
View Posts
-
Send Message
Curse PremiumI do want to do something with advanced visibility calculations some time. There's a possibility there to get some really great-looking landscapes without bringing everyone's gfx cards to their knees, but that's a long ways off. I need to figure out some kind of algorithm for doing efficient visibility calculations in a voxel-based world. Relying on the gfx card to do occlusion calculations is probably less reliable than actually coming up with a decent algorithm.
Python is one of the best maths languages ever!
Anyway, expanding from what Cuchaz said, the key thing is that Minecraft is a voxel world. We don't have to use proper occlusion based visibility. We don't have to trace rays from the player and see which chunks they pass through.
Fundamentally, we are just asking if a chunk ~might~ be visible, or rather, in which conditions may a chunk be ~invisible~.
The most important thing to note is that Minecraft is a voxel based world. When dealing with visibility, this gives us a couple of massive advantages. Basically, in Minecraft; every block is either transparent or opaque, and lines up perfectly with a very tidy grid. Compare this to say, a game which uses complicated models and polygons, with hundreds of thousands of vertices strewn over the screen and well... the advantages of a voxel world should become much more apparent.
One simple example is the fact that a chunk will not be visible if it is completely surrounded by chunks filled with nothing but solid blocks. We can take this further by recognizing that, at any one time, an observer can see no more than 3 faces of a cube, and that we can very quickly check which faces of the cube will be visible to said observer. This means that we really only need to check whether 1-3 faces of a chunk are covered to determine whether or not the player can see it.
Taking this one step further, we can use some simple trig and vector based maths to determine which chunks will ~definitely be obscured~ by a solid chunk, since if you can't see a chunk, it is safe to assume that you can't see the chunks behind that chunk, and so on.
I believe in the Invisible Pink Unicorn, bless her Invisible Pinkness.
...Oooooh.
Those proof-of-concept screencaps look gorgeous. I would love if this got into vanilla.
[EDIT] I tried out the latest snapshot, 14w25b, today. It would appear that cubic chunks are very much going to be a part of vanilla Minecraft, if I'm reading the lagometer correctly. Puzzlingly, the artificial height limit is still there at 255.
On the mojang page there is some blanks supposedly to be hidden things added, but one of the blanks is just long enough for "Cubic Chunks" to fit. Half Life 3 confirmed.
Gladly.
Note the "Chunk" line on the left: "x y z in X Y Z" where (x,y,z) is your block coordinates within the chunk and the (X,Y,Z) is the chunk's coordinates in the world. It appears it's using 16x16x16 cubic chunks.
Note also the "Looking at" line indicating the coordinates of the block I currently have in my cursor: I can't build my lovely column of mysterious blue rock any higher than that.
Minecraft has been using 16x16x16 sub-chunks since they implemented the Anvil format of storing worlds. This has led to confusion in the past with the subject of Cubic Chunks, but I (and anyone from Mojang) can assure you that Cubic Chunks are not in 1.8, and likely won't exist for some time to come. See MogMiner's "Infinity Years" tweet and you'll understand what I mean by this.
Now then, on to the subject of what these "sub-chunks" actually are. While Minecraft's storage format stores chunks in areas of 16x16x16 blocks, it can't actually process what's going on in such an area by itself, and can't load such an area alone, either. It has to load each section of 16 sub-chunks in a chunk in order to process anything going on in them. The sole reason they exist is because (ironically) Anvil is a 3D storage system. It is naturally designed to store three-dimensional areas, and kept this behavior when Mojang implemented it into the 2D chunk processing of Minecraft. It's simply more efficient to store small areas and have blocks reference their positions inside of such an area than have them worry about all of the other blocks within a chunk.
I'm still a little curious why it displays chunk coordinates in that way when, to my (admittedly limited) knowledge, it's never done that before. Thanks for the correction, though.