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
There are plenty of sources which you could draw entropy from. The exact millisecond the system clock is when the RNG reads it, some internal counter the CPU uses, the amount of pagefaults that occured in the last period which was determined by the previous CPU counter read, etc.
Anyways, why would you need anything approaching true randomness unless you were doing encryption anyways? I'd think a deterministically generated algorithm would be just as good from a playability standpoint unless it had obvious or easily deducable patterns that werent added by design (e.g. a desert biome always generating 2 spaces to the right of a taiga biome, certain other biomes always or nearly never generating next to each other, etc.)
And please, Pentrit and Gotolink stop fighting. Pentrit is right, computers are based off of pure logic and you cannot simply generate a lightmap without terrain. Generating light without terrain would require a secondary generation algorithm that wouldn't reduce lag. Why can't we just go with the OP's solution and generate the height-map for lighting? I still don't see anything wrong with it. Generating downward from y=128 still generates less terrain than the current system and meets Jeb's requirement for efficiency in that sense, and works in every case.
I agree, It is possible to do what Gotolink is saying, but it would just cause more lag than reduce by requiring more threads and generation algorithms.
-
View User Profile
-
View Posts
-
Send Message
Curse PremiumI wasn't talking about computer. Nor something remotely practical. But if you want to hear that theroetical idea:
Pure logic would imply entirely deducing the terrain from its light, which would put more and more constraints over each new parts of the terrain, leading to a loss of entropy, growing repetitiveness and ultimately, a deadlock.
Well, I couldn't find another word for "something that comes after in a time sequence, with a soft dependency".
So...no gigantic ravines in your worlds ? No deep oceans ? No abrupt cliffs between some biomes ?
Try exploring your worlds without jumping or placing blocks, you'll see there are places that you can't reach.
And let's be serious here, if you are not happy with how a world generates, you don't have to play on it.
The only thing needed is the light rules to be consistent with the way light is calculated currently. No more rules have to be made for that. If you can't conceive in your mind those rules being applied before generating terrain...
Try to picture a screening process after terrain is generated. If terrain doesn't pass that step, roll the terrain-generating dice again.
That sequence is less efficient, but easier to imagine, i hope.
Then for "the requirement of being actually usable"
Choose a setup that would mainly output things that looks like what you want. That's what is currently done anyway. No changes required.
I didn't want to sound harsh or hurt anyone. I am sorry if i did.
You generate terrain without anything. You can thus generate light without anything. The idea is not obvious, but I don't see any real obstacle. Once I saw both as world data, it unlocked the idea in my brain.
The current problem is, unless you find an extremely efficient way of calculating light from your height-map, that is what is going to cause you lag each time you load a chunk. Sure, generating light is going to take some more time when generating new chunks, but it is done once, not every time. This also prevents any "surprisingly" inaccurate lighting when exploring. The light engine wouldn't need to fix light errors occuring because of weird terrain. It would be accurate the first time you see it. (no more extremely dark areas needing updates below a terrain overhang)
I guess it is me having a slight preference over changing things so they work better, instead of applying a patch to things that don't work.
-
View User Profile
-
View Posts
-
Send Message
Curse Premium1. each time a chunk saves it would calculate the light level at one block below the bottom of the chunk.
for(0x to 16x) {for(0y to 16y) { num += lightlevel }} lightlevel /= 256;
that light level is saved in the chunk file
if the location of that piece if data in the file is know we could load/manipulate that data without recalculating light.
(haven't looked into the lighting system too much but I assume it starts at the block being calculated an working up)
in such a case where the average light level at the bottom of one chunk is 0 we can stop looking and assume the block underneath is at zero too so we never need to go all the way up. Also if you build enough layers above other layers the light level will eventually hit zero in the lower layers anyway.
ascii are picture: (8x8 to simplify, each line one chunk)
------x- avg light level: 14
-------- skip empty chunk
-------- skip empty chunk
xx--x-x (14 - 8) = 6
xxxxx-- (6 - 12) = 0 (clamp between 0 and 16)
xx-xxx- 0 (only need to check one up)
I hope this is useful.
thanks! that really explained it really well... and as you rightly said, i think i was reading the EULA too closely
@ the rest... i have no real input here, but i am reading this thread avidly as being the most interesting thread i've ever seen on these forums - totally fascinating stuff.
as an aside re RNGs i was looking at Chua's circuit a few months ago for an electronics project i am working on where i wanted random output... there's a c implementation available here but it's probably still deterministic - i haven't tried it myself, but it may be useful? [ really not sure, as a lot of the above thread is outside my field of software dev ]
-
View User Profile
-
View Posts
-
Send Message
Curse PremiumYes, still deterministic, but it's sorta off point. They are debating about world gen, and certain concepts. Deterministic random variables seemed to play a small part in the discussion, but it wasn't the key point.
That being said, your circuit has some good points of discussion.
Chua's Circuit is still deterministic because the values come from a known set of circumstances. After all, we all know that V = IR, Q = CV, etc... the issue here, is that this little circuit is incredibly complex. In fact, noone seems to be able to accurately predict how the circuit will behave. It's not that we can't identify the internal workings, its just that we can't predict whats going to happen in 5 seconds.
*reads article a little more closely*
Turns out, we've taken several steps in identifying several of the components at play. So, this actually breaks down the discussion of "truly random" versus "very hard to predict"
.
Things that are deterministic, can be "very hard to predict". They can seem random, but if we spend enough time, and enough computational power, we can solve them permanently because they are based on a set of facts. This makes them lose their "randomness". Several science minded folks would take this a step further and argue that this means that everything in our universe falls under the deterministic category. Things that appear "truly random" are simply things we don't understand completely. Then take it a couple steps further and all of a sudden you're in some Quantum Computation course. A rapidly developing science exploring the fundamentals of seeming random behavior within the components of atoms.
While you probably don't know what a model of Chua's circuit will do in 5 seconds, and while it's output can return a normally distributed value, the question of whether it's deterministic or not isn't based on our perception. We can't say, "I don't know that, so it must be truly random." In Chua's circuit, the circuit is still deterministic, but we still don't understand it completely. That doesn't make it a "truly random" phenomenon.
-
View User Profile
-
View Posts
-
Send Message
Curse PremiumSo, you managed to think of a way to build the worst terrain in your opinion.
You imply that Mojang might want to choose that particular generation setup for the game.
You blame this idea because it doesn't specifically prevent that to happen ?
But you don't blame the current terrain generation from not preventing that either.
Sorry i don't think it makes sense.
I not only realize it, I hope there are a lot of solutions. The more solutions, the more likely the terrain generator will build a suitable terrain in the first try. If your worst-terrain-ever only has one billionth of a chance of being built, there would be no reason to worry about. The worst case would be if no solution were available, resulting in the terrain generator using the most loop turn before light generator is forced to build another situation.
No, i am not talking about a non deterministic process. Unless you think rngs, in which case, terrain generation already uses that (and has currently no criteria for being "playable", "natural feel" or whatever).
I expect Minecraft to have a set of rules for light updates and values. That is what the light generator would use to convert its generated light data into directions for the terrain generator. Depending on the rules, it could imply generating light data further than terrain, above/below/around/whatever. If you know what those rules are, please tell, I could be more precise with the process flow.
Virtually infinite height:
i voted "don't like"
- not because I don't see it as a good thing to strive for, i just don't see it as needing solving in this fashion - minecraft isn't about space exploration [unless you're using galacticraft, but that's a side point] - it's about mining.
Virtually infinite depth:
i voted "don't like"
- this really is silly... minecraft as i say, is about mining - if there's a planet in the universe with infinite depth, then i'd be all for it... but it's just a silly concept.
More efficient chunk-handling:
i voted "don't like"
- i'm all for more efficient chunk handling, but not in this way. for one, i WANT the whole vertical column to be loaded - else when playing modded minecraft i'd have to have an "infinite" stack of chunkloaders just to operate a deep quarry/pumping system... mining goes up and down more than side to side - hence having infinite horizonal chunks is useful but loading the whole vertical chunk is also better for most gameplay
Ability to utilize 3D biomes(Allows for underground, underwater biomes, and intricate random structure generation) :
i did "like" this. but i think there's simpler ways to solve it - using a limited stack of chunks, say, 32 blocks high each, stacked on top of each other - the vast majority of gamers would never use more than 16 [ 512 high ] - probably half that - so the "infinite light tracing" issue would be less of an issue. so you could still have a biome at 0-32 and another at 33-64 etc.. allowing for a "deep" biome without requiring the issues with infinite prediction into the sky. [ see above re: why i don't see infinite hight and depth to be adding anything to game play ]
Ability to utilize much larger and more realistic terrain generation :
i didn't asnwer this - as i think it's just a rhetorical pathos driven statement - just saying the previous assertions in a different way. There are many biome mods which [ in my game playing, not my "purist developer" opinion ] do this well enough for 99% of the user base... KISS principle applies.
Reduction of server-client bandwidth usage and connection lag:
i didn't vote on this, for the same reasons as the previous - i think it's rhetorical pathos, and although technologically true, in practice i think "power users" will just force more chunkloading - you'll have chunkloaders all over the place - and you've got little benefit for a lot of effort.
Crippling of X-ray hacks(Only in SMP, and can be disabled) :
this is a bit irrelevant reading the latest snapshot notes - as jeb claims this is now fixed at the renderer.
and overall, i think the tone of the original post is laden with rhetorical pathos - designed to make the reader go "yeah, that's a bad thing, silly mojang"
specifically where the OP says "That's why, to fix this, Minecraft must change over to a cubic chunk system." - reading that sentence just made me think "what an arrogant statement"
overall, i think the whole thing is a really good idea in purist academical terms, but pragmatically unsuitable with the reality of the majority gameplay.
that said, I reckon a lot of good academical thought springs lateral ideas which are compatible with the game - and so it may be an academical exercise in my feelings, but that doesn't mean it isn't a really really good way of discussing all the possibilities...
and as a final note: i think the tone some people are using against each others ideas is ugly, statments like "You have no idea how computer's work." just make the poster out to be arrogant.
-
View User Profile
-
View Posts
-
Send Message
Curse PremiumI would like to point out, You could change a chunk loaders behavior to keep all vertical segments loaded OR just the 16x16x16 cube (or maybe a variable dimension of chunks open?)
Basically, saying that "current chunk loaders only load one chunk" is entirely valid. But, that doesn't mean that behavior cant change if chunks are reduced to 16x16x16
Was that your only objection to "More efficient Chunk Handeling"?
I was actually quite surprised by your answer, although you have some fantastic reasons to do so!
I think it is a simple solution. If there are no blocks that are more than let's say 5000 blocks above the one you are checking then just assume that it is lit. Just like you don't see a huge shadow of the ISS from earth because the light just goes around it.
OR, just make a max height for each world that is ridiculously high. Like 500,000 blocks, then you wouldn't need to check forever.
What about range trees and height maps? Didn't someone already find a solution?
Are you referring to the Anvil Format?
@ partly Pentrit + mostly CptSpaceToaster - re: the vertical chunks - well, that's sort of the point i was making - the net result is that people will load all the vertical chunks anyway using such a modified chunkloader... thus the vertical saving is nullified or at least not the huge gain it would be in a vanilla "perfect case" world.
not that i think this detracts from the project as a whole - more that this perhaps needs to be considered as part of the design to see if there's a middle ground [hence my ponderance/ blue-skying on the 8 stack o chunks limit possibility ]
Cubic chunks won't really kill x-ray mods.
Just because MC loads ALL blocks in every chunk in render distance.
also you should check out Tall Worlds
- Rendering
- Only transparent blocks will now render as transparent (eliminates the use of x-ray texture packs)
... so i'm still not sure if it matters[ edit: aside: i hate it when you post and it's on the next page...]
i did a similar thing where i had a server doing the culling for a multi user flash based app to reduce the client side maths - but that was simply for backface culling of the rendered models, but i understand the difference here...
Oddly enough, for some reason I can still use x-ray texture packs in the snapshots, which already supposedly fixed it; in this thread I got into bit of an argument over whether it still worked (they claimed that I was using spectator mode, but I posted screenshots obviously taken from above ground and in Survival mode).
Regardless, the new spectator mode can be used to the same effect, and actually even better for obvious reasons (of course, this won't work in multiplayer unless you are OPed).
TheMasterCaver's First World - possibly the most caved-out world in Minecraft history - includes world download.
TheMasterCaver's World - my own version of Minecraft largely based on my views of how the game should have evolved since 1.6.4.
Why do I still play in 1.6.4?