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
[] [obsidian] [obsidian] []
[obsidian] [Violet] [Violet] [obsidian]
[obsidian] [Violet] [Violet] [obsidian]
[obsidian] [Violet] [Violet] [obsidian]
[] [obsidian] [obsidian] []
also you should check out Link Removed
I caught the gist of what was being said, if not all the details. From what I understand, treat the shadow the same way we treat Falling Water. If you are above, the shadow would "fall" till it reached the lowest loaded chunk, then wait. If lower ones are loaded later, it continues being passed down. If you are below, it would check what it can, and pull down any shadows it finds record of, in all the loaded chunks above.
Slightly different idea, what if something like that was combined with the idea that shadows fade over distance. a floating island WAY up, wouldn't cast much of a shadow because of ambient light and diffusion. Impose a calculation that if the object isn't completely solid (has places where light can pass through) then the shadow drops off over distance, and eventually disappears entirely. If it's far enough overhead, that it doesn't get loaded, then it's shadow would be negligible too. How this would work in Caves: if the overhead is completely solid overhead, full darkness, but if there is a hole to let light in above somewhere, then the shadows are lighter in that chunk and surrounding.
My Favorite Texture Pack is OVO's Rustic Pack:
What are you trying to tell me?
I already know that it only works for single-block chunks!
The cost that it needs to be implemented is incredible low.
Actually:
Its a single integer and boolean that has to be sent with the chunk.
How much is that compared to the rest of the chunk?
Well, its pretty much nothing. And thats why it works perfectly fine for all single-block chunks.
And if a chunk is not a single-block chunk (Which happens pretty much all the time), then it doesn't really matter either, since only the single boolean (isAllTheSame) and the chunk data are being sent. How much of an overhead is that?
Easy:
This is ONE byte. ONE freakin byte. How does this matter?
The method that does the check if all the blocks are the same is just a simple for-loop that goes trough all blocks and looks if they are different or all equal, so that doesn't matter at all, since its incredible small and fast.
So:
Yes, there is a small overhead, and it only works for Air, Oceans, and some parts of the Nether.
No, the (microscopic) overhead doesn't matter at all, because its a small, fast and simple trick.
So what the nether where you trying to tell me, other than the things I already knew?
I made my point. End of that small disscussion.
- Longor1996
PS: Chunk-Data is already compressed using the Inflator/Deflator (G-Zip?) classes of Java, and it works pretty well already.
PPS: What parade are you talking about? I really don't care about being praised over a text-section. I didn't make a parade, I made a suggestion.
Im a modder/programmer! I am on Twitter and YouTube, and some more I won't tell you about!
[] [obsidian] [obsidian] []
[obsidian] [Violet] [Violet] [obsidian]
[obsidian] [Violet] [Violet] [obsidian]
[obsidian] [Violet] [Violet] [obsidian]
[] [obsidian] [obsidian] []
I can't believe we almost have 3,000 supporters.
As it will be in the future, it was at the birth of Man
There are only four things certain since Social Progress began.
That the Dog returns to his Vomit and the Sow returns to her Mire,
And the burnt Fool's bandaged finger goes wabbling back to the Fire;
And that after this is accomplished, and the brave new world begins
When all men are paid for existing and no man must pay for his sins,
As surely as Water will wet us, as surely as Fire will burn,
The Gods of the Copybook Headings with terror and slaughter return!
-The Gods Of The Copybook Headings, by Rudyard Kipling.
[] [obsidian] [obsidian] []
[obsidian] [Violet] [Violet] [obsidian]
[obsidian] [Violet] [Violet] [obsidian]
[obsidian] [Violet] [Violet] [obsidian]
[] [obsidian] [obsidian] []
It's not as good as the heightmap solution in the OP. Your idea requires updating down all the chunks whenever you place/remove a block, whereas the heightmap idea only requires recalculating whenever you remove the highest block in a column.
Mostly moved on. May check back a few times a year.
[] [obsidian] [obsidian] []
[obsidian] [Violet] [Violet] [obsidian]
[obsidian] [Violet] [Violet] [obsidian]
[obsidian] [Violet] [Violet] [obsidian]
[] [obsidian] [obsidian] []
I think once generation takes advantage of Cubic Chunks if/when it is added to MC, skylands being added would be the better bet/fit for MC. Space seems to attract people/ideas wanting rockets, lasers, etc all things that are to advanced imho for MC. (They are things also that have not been received well by the MC forum community in the past if you search through the forums)
[] [obsidian] [obsidian] []
[obsidian] [Violet] [Violet] [obsidian]
[obsidian] [Violet] [Violet] [obsidian]
[obsidian] [Violet] [Violet] [obsidian]
[] [obsidian] [obsidian] []
Wrong, at least in this case. If this was a talk about not sending a heightmap over the network and regenerating it client-side, for example, you would be correct. However, in this case, methods of doing, eg, RLE encoding are methods of compression.
You do know that Minecraft already does this specifically for air-only 16x16x16 "chunks", right? So no, it wouldn't even help there.
Layer-by-layer compression might help, but again adds data in the worst case, enough that I question as to if it would actually be useful. Not to mention that the data is already compressed.
Just use a proper compression algorithm already!
Is it? In that case it already compresses a chunk of the same ID to... 26? bytes - and that's with checksum and header.
As such, this adds data in the general case while not really providing much compression even in the optimal case.
We should be concerned more about worst case than about best case.
Except that the data is already compressed. This is just another layer, and one that doesn't add significant compression in the best case due to it being already compressed.
Don't reinvent the wheel, guys. The data is already being run through a compressor, and one that has had a lot more man-hours put into tweaking and improving it than any scheme anyone here can put into it, including me.
If you all are concerned about a 1-byte (or 1-bit) piece of information being sent over, you're exaggerating way too much. I agree with Longor on this one by far. If you really don't want to send over 1 byte for each chunk, either get the information from the 3DRegion file or don't send the information. The receiving system could probably detect if a chunk is exactly a certain size and determine if the chunk is normal or compressed.
It's very much an argument that could go either way. In this case, I would actually argue that the 'RLE' component of Longor's implementation is really just a simplification - "This chunk contains only air" vs "This byte array is repeated X times".
This is because Cubic Chunks can only be compared to the existing linear system. If Cubic Chunks is *perfectly* optimized, we could reduce the amount of data that needs to be compressed by upwards of 50% (vs a perfectly optimized linear system).
Additionally, information would be sent in much smaller sized packages, so even if the bandwidth usage was exactly the same, the player's experience would still be much better with Cubic Chunks than it is with the existing linear system.
I believe in the Invisible Pink Unicorn, bless her Invisible Pinkness.
This idea is nice; cubic chunks would help, but infinite horizontal travel is inpractical.
Remember, changing the chunk format doesn't necessarily mean that terrain generation changes. It means reduced lag and the current height limitations to terrain generation are now optional.
Remember, this IDEA is all about Allowing the currently impossible. the ABILITY to build up or down forever.
The server admin or you (if single player) will be completely able to turn this on or off. They can set an upper boundary, and a lower boundary if it fits what they want to do.
Terrain Generation is another subject entirely too. By default, this Idea will not change ANYthing about current terrain generation. Everything will look completely the same. Terrain Gen mods will have the ability to make what you describe if they so choose.
That is not what this thread is about though. It is about Enabling these possibilities, what you do with it is up to you.
My Favorite Texture Pack is OVO's Rustic Pack:
We dont want truly infinite height, we want the vertical axis to be similar in scale to the x & z axies. Horizontally, one can travel up to 32,000,000 blocks from 0,0 before one enters the "Ghost Chunk" area. We want a similar thing for height.
Zwei, about the server, could you export a .schematic file of something I build, and PM it to me/ post a link on here? If not, could you get me a copy of the world save after I build something?