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
Oh, why didn't you say so? Regenerating them is a really bad idea. But having separate render distances with different detalizations seems awesome.
No it would! Because you don't want to save anything it would regenerate and regenerate and regenerate to no end because there are few quadrillions of blocks to check to base chunk blocks upon to base region blocks upon. This will never work, you are just piling useless taxing calculations on top of already failure of a system.
It will never fit in any amount of RAM for one thing, so you are bound to save it one way or another. Are you really willing to generate terrain in 32k block radius in per block algorithm every time you load the game just to save a few megabyts of disk space? Even moving one chunk in any direction will force you to check at least 16 384 000 000 blocks to update region blocks on the corner in your idea.
Maybe we are not quite getting each other, so I'll describe my understanding of how this should work. First of all, there must be three terrain generation algorithms working at the same time, with far ones being fastest as they'd generate only some block in the middle, don't generate caves, maybe consider only binary state (blocks/air) for region chunks or some clever math. All three generated maps should be saved separately and must overlap each other meaning they all cover the place where you stand. There should not be a strict border between them, meaning that the lower resolution starts at the place where higher one is not loaded even if it is less then a render distance. As for updating, this seems right, except that this update must only be performed once with the results saved, meaning that you would not need to check every chunk to figure out if it was changed from the seed and then forming their approximations every time they are loaded. My number was about that.
Because that would actually require them to work, and nobody wants that ^^
-
View User Profile
-
View Posts
-
Send Message
Curse PremiumBecause of reasons. =)
Those damn reasons, they just have to go and suck the fun out of everything, don't they :'(
I believe in the Invisible Pink Unicorn, bless her Invisible Pinkness.
as have I, on the same page
Someone is!!
Except not. Writing a mod is a bit different from writing a post. There is no download, so that thing does not exist (yet?)
That's specifically why I used the word "is" instead of "has." Verb tense is important.
The mod is being worked on. It has not yet been released.
What you stated was "Someone make this!!" Not "Someone conveniently already have made this so I can download it immediately!!"
#Cubic Chunks
Well, it wasn't me
But yes, in the way you worded it you are technically correct.
I guess so? I don't know why you'd have any reason to be skeptical about it though.
I mean Chuchaz has a website, videos, and a repository for the code, all in all proof that work has been done towards a cubic chunks mod. All of which was easy enough to find from that thread I linked you too.
That puts it at a little higher on the existence scale than "does not exist (yet)" I think. Technically speaking.
It depends, because not all of the world is loaded at once. In fact, on low render distances, (<8 chunks iirc), a cubic chunks world would actually load less blocks then a normal world.
When you set the render distance to something really big, then you could see a reduced performance, unless you can change the 'thickness' of the rendered world and set it to 16 chunks.
No, and Yes. If using cubic chunks, no (for reasoning read main post). If not, definitely. You would need to load all Infinite blocks per chunk, making your machine catch on fire, and melt.
It's just that all those things were there like a year ago, and I still don't see any result I can use, not even alpha ^^
____________________________________
By the way, wouldn't generating only a crust of the world (only chunks you can actually see) but in much higher distance limited by the number of the chunks loaded instead of the radius make much more sense? I guess there would be a problem with caves be completely mobless first time you enter them... As for breaking block on the chunk edge and seeing emptiness for a split second, it could consider block that are getting destroyed as if it wasn't there already.
Not so. You could ignore the chunks if and only if they contained only solid blocks, or were outside of a certain distance from a player. If a chunk was within a certain distance (say, 64 blocks) and was not 100% solid, then it would always be loaded and processed normally.
As for emptiness when breaking blocks.... The best solution is probably just to keep ALL chunks in a certain area around the player loaded.
Ultimately, it may be that the best solution (all things considered, including maintainability of code), is to simply ALWAYS load a 4 chunk radius around the player, and then use aggressive chunk culling beyond that range (as the distant chunks will be mostly irrelevant. There are some special situations that could arise here [i.e, you have a furnace or crops in the semi-distant chunks], however that's an entirely different discussion imo).
I believe in the Invisible Pink Unicorn, bless her Invisible Pinkness.