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
-
View User Profile
-
View Posts
-
Send Message
Curse PremiumDo not confuse "Chunks that have to be loaded for ticking" with "Chunks that have to be loaded for display".
In a dedicated server, these are clearly different -- the server has a bunch of loaded chunks, and sends a subset of them to your client.
In single-player, you could do something similar. There is already a render-culling step to try to reduce stuff sent to the display, all you would do is add one more "don't even consider these for display" step.
The point of cubic chunks is that for any given x/z chunk, you'll load -- even in super mountains -- an average of 3 minichunks or less, and if you are deep in caves, you can probably optimize that down even more.
Total load is no longer dependent on the height of the world, for normal minecraft worlds
Imagine, if you dare, a mystcraft world, with gigantic "ravines" going from the worldtop at 240 down to the exposed bedrock at 1-4, with water down at 64. Large tunnels in the natural landscape all over the place. Huge, giant "amplified"-like terrain gen. (That was part of today's dev stream, by the way.)
Or imagine a nether-style world, with a 256 scale instead of a 128 scale.
There is no way to cull out in those environments. You can see all over. Even looking down, the idea that you only need two or three minichunks down no longer holds -- you want to see how far down that waterstream goes, to decide if you can take it down safely or if you'll run into lava, or worse, void if you don't even (yet) know if the world has an ocean or a bedrock. (Not all mystcraft worlds do ...)
And this is not the only mod with new terrain gen. I have no clue how Aether or galacticgraft generate their worlds, and what little I saw of Creeporium (I think that's the name) had a gigantic, sky-filled landscape.
So even if this is a win for normal types of worlds, it can fail miserably with others.
Again.
The amount of horizontal "send to client" information would be determined for each server based on load and network. Do not assume that it will automatically increase the cpu load or the network.
That seems like a reasonably accurate summary. You seem to feel that a ton of work, and/or compatibility, is not worth worrying about. Frankly, both of those are serious limitations.
===
I agree that a video game is, in some sense, a time sink.
It could also be considered, for some people, a form of artistic expression. For some people, a popular-enough form that they have "patrons". See Direwolf, Etho, Guude, etc. For them, it's not just a time sink -- it's a way to entertain others.
However, for the normal population of players, yes, it is a time sink.
There is one game, released by Mojang, where there is a timesink of mining, finding ores, etc.
There is another game, played by some, where the timesink is the construction. For these people, finding the ores is a waste of time because their goal is the construction.
A friend of mine showed me a world that they had -- a mystcraft desert world -- where they were making a gigantic sandstone construction. For the amount of sandstone that they needed, they had an automatic sandstone generator. Was that defeating the purpose of playing the game?
Only if you think that the purpose of the game is to spend the time mining as well as crafting.
If you think that this is a construction game, well, some people want something in-between "creative" and "vanilla survival".
* Promoting this week: Captive Minecraft 4, Winter Realm. Aka: Vertical Vanilla Viewing. Clicky!
* My channel with Mystcraft, and general Minecraft Let's Plays: http://www.youtube.com/user/Keybounce.
* See all my video series: http://www.minecraftforum.net/forums/minecraft-editions/minecraft-editions-show-your/2865421-keybounces-list-of-creation-threads
(In regard to a mod that gives realistic animal genetics):
Would you really rather have bees that make diamonds and oil with magical genetic blocks?
... did I really ask that?
This extensive overhaul got them running in a lot of circles; they learned a lot of tricks in programming and can use these tricks to streamline future content; but recreating MC from scratch seems to have gotten nowhere quick.
At least, that's what I interpretted from Jeb's earlier excerpt.
OFFICIAL POSTING/REPLYING GUIDELINES
UNOFFICIAL POSTING GUIDE (PRT)
UNOFFICIAL REPLYING GUIDE (FTC)
So the problem here is we need to design Goldilocks. Something that's robust enough for the needs of the new system but light enough to be useful on any system. In this case, the 2D height-map already has us covered.
OFFICIAL POSTING/REPLYING GUIDELINES
UNOFFICIAL POSTING GUIDE (PRT)
UNOFFICIAL REPLYING GUIDE (FTC)
Your name is amusing.
I mean it would be extremely difficult getting rid of the lava inside of it, and there is the constant risk of death, but the challenge of it all would make it worth it.
You sir (or madam) are wise. "If you can have anything you want simply by uttering a few words, the destination matters not, only the journey to it." I like you.
This is the reason I like building underwater, and also why I'd love the deep deep oceans that cubic chunks makes possible.
That and underwater lights look really cool at night.
-
View User Profile
-
View Posts
-
Send Message
Curse PremiumIt is possible but there are some issues with the additionsl chunks:
-RAM usage - Each chunk (16x16x16) takes: 4kB to store block ID, 2kB to store metadata, 4kB to store lighting (skylight+blocklight) and possibly additional 2kB with block ID>255.
-Rendering the chunks would be problematic because of how Minecraft rendering is implemented (but it isn't impossible)
-Ticking additional chunks on big servers isn't a good idea - currently all big servers are using the lowest view distance (3 chunks).
I know that it doesn't have to be enabled but if in wouldn't be ebabled on server it would fix the problems onl
on singleplayer and small servers.
Some calculations:
view distance 3 chunks (linear), 200 players far away from spawn. Each player loads (3*2+1)^2 chunks (49 chunks), 200 players - 9800 chunks, Every tick server have to check all of the chunks ant tick if there are any blocks to tick (And there are mobd in all of the chunks!). Each chunk uses about 40-80 kB RAM (60kB average), 9800 * 60kB = 588000 kB = 588 MB = 0.58 GB
RAM (with mobs it would use more RAM)
Cubic Chunks, view distance: 3 cubes + 5 additional cubes: Each player loads (3*2+1)^3 cubes (343 cubes) + additional loaded chunks ((8*2+1)^3-343=4570 cubes) for 200 players it's totally 68600 + 914000 cubes, each cube - 10kB (50% of the chunks would be empty so there would be 491300 cubes with blocks), 491300 * 10kB = 4913000kB = 4913MB = 4.9 GB RAM.
Loading only cubes to tick would help but only without simulating mobs (with mobs all of the chunks have to be loaded).
Also currently there is something simillar - server loads (by default) all chunks in radius of 10 chunks from any player and send all of the chunks. Client renders only chunks that are in player's render distance
Cubic chunks discord server
-
View User Profile
-
View Posts
-
Send Message
Curse PremiumFor redstone it's possible to load chunks when it's required (when redstone signal reaches unloaded chunk).
Intelligent chunk unloading would work but mods would cause some problems.
Currently there is no way to detect mob farms from the code.
Rendering "islands" below player/ceiling: Possible to implement but there is one limitation: There are zFar and zNear velues in OpenGL, everything that is further than zFar isn't rendered. Setting too big zFar values may cause rendering glitches (problems with z-buffer, more info).
EDIT: There is also problem with fog. It's always sphere (vertical distance to the fog is always the same as horizontal).
Cubic chunks discord server
-
View User Profile
-
View Posts
-
Send Message
Curse PremiumCubic chunks discord server
Heightmaps, or more accurately, above ground/below ground dividers are actually a pretty good idea for distance viewing, at least in regards to non-amplified terrain.
Aside from trees and artificial structures, the only surfaces exposed on the overworld which don't follow the heightmap are overhangs and caves. In both cases, the transition from one to the other is unambiguous because it deviates from the heightmap. And if we track where these transition regions are, we can easily divide the world into overworld, below-ground, and transition points. In caves, coarse raytracing is really efficient. The overworld has broad occlusion zones caused by hills, which can be subdivided by following the countours of the heightmap. These approximations are far from optimal but it would be dirt cheap for a server to track, even over long distances.
On the client-side, I've had good luck with an LOD heightmap-based overworld, again disregarding trees and artificial structures, and when that is in place, there is more than enough memory and pipeline left over for special cases like volumetric structures. At least that's what I've found so far. Still working out the finer points...
Basically, partial solutions are perfectly acceptable if they can take the weight off the more thorough techniques.
They already know of the proposal of the system being a thing.