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
No, because there is none, we're experiencing some delays and have no idea how long they will last. Could be a week, could be a couple months, we have absolutely no idea.
Yeah, just give them a chance. They're putting a lot of effort to the mod, and by now, I can expect them to get annoyed that people are asking when the mod is releasing countless times, even when they have the answer "we do not know, just be patient" yet they go begging for an answer they would want to hear.
Yeah. Trust me, we want it out as soon as possible. Once the current delay is over, we should have a solution that stops any future delays.
How would CC's loadout compare to anvil's current implementations? What are the benefits and penalties that CC brings that chunk+sectioning would not?
OFFICIAL POSTING/REPLYING GUIDELINES
UNOFFICIAL POSTING GUIDE (PRT)
UNOFFICIAL REPLYING GUIDE (FTC)
SUPPORT!
Testers report an FPS increase of up to 100% at normal render distance, and 30% over Optifine's FPS increase.
There are no penalties unless you like to nitpick(E.G.: You complain that if person A drops sand towards person B 2000 blocks below them, that sand will not reach them until the intermediate chunks are loaded).
Awww man!! But thats so much fun!! *Sarcasm self-test complete*
Can't explain it, but it might be due to the fact that lighting calculations do not work properly (yet). However, the evidence does not lie, just watch my 180 FPS average with CC while recording with Fraps, which normally reduces my performance by a lot (CC is AMAZING!).
Then CC mod was started a few months later and I was like wooo hooo some one listened or least got the same idea i had.
When CC mod stopped updating I started preaching again.... and got ignored a lot.. x.x
Finally Calacbolg offered to take this off my artistic dyslexic hands and put it in ways people could understand and things are finally looking awesome 2000+ supporters and counting...
oh yah.... funny thing my reason for cubic chunks was only half for mountains... alpha didn't have oceans or exstream hills.......
wanting mountains wasn't as big as an influence as wanting deep deep deep oceans for building underwater cities
"Because it's your right as an American to butcher the English language."
This is my baby, please support her and get her into vanilla:
Understanding above:
Currently MC is not multi-threaded (on world update information), this is problematic as high CPU usage can force MC's framerate through the floor.
Minecraft isn't terribly GPU intensive, but it will eat through RAM and CPU clocks like they're pork rinds. Breaking the world-update into more manageable chunks (CC) alleviates some of this stress.
My suggestion (in the image) is an extension off of it. First, there are 3 zones; a red zone, orange zone, and green zone.
The red-zone is the backburner updater. If a system can run all settings with max efficiency, it will. If not, this is the first to be hit. Since the red-zone is the more distant and less-prominent chunks, it's far easier to reduce it's frame rate without a significant noticeable impact from the player (if there's an impact at all), often rendering it to 5FPS or lower depending on CPU stress.
The orange-zone is the non-critical updater. This is basically any data that the player can see and interact with in a short span of time. Since these chunks are a bit closer, it's more imperative that these retain a decent frame rate overall. Anything over 24 would be nice. Again, if a system is terribly taxed, this will be second on the list of things to axe.
The green-zone is the critical DO IT NOW updater. This is all the things you are already interacting with. This is all the block-update data, every block you pop, every torch you place, every lighting change. It happens here. Because of this, it's the smallest chunk, but also the most important one, you want to be able to see mobs/players coming from a distance and react instead of laggy lurchy combat that is unfair and can easily kill you simply because your CPU or the server's CPU is garbage. But, if your computer is really that bad, even this would be hit, but it would be the last to be hit.
With the above, lower-priority threads are the first to be hit; increasing higher noticeable framerates and smoother gameplay through LAN and servers and increased speed on mom-and-pop rigs. This may also reduce system requirements as less-required threads are simply optimized into oblivion until the system can run respectably well. Again, the target number is 24fps in my definition.
OFFICIAL POSTING/REPLYING GUIDELINES
UNOFFICIAL POSTING GUIDE (PRT)
UNOFFICIAL REPLYING GUIDE (FTC)
Moreover, since we're moving lighting updates and "expensive" operations to the "do it now core" and forcing it exclusive to the nearest chunks, we're cutting down on the overhead via that methodology.
OFFICIAL POSTING/REPLYING GUIDELINES
UNOFFICIAL POSTING GUIDE (PRT)
UNOFFICIAL REPLYING GUIDE (FTC)
lol ah well I only searched the form when I did it way back when I didn't keep up much with the develpmental blog save for the future features and changelog lists
"Because it's your right as an American to butcher the English language."
This is my baby, please support her and get her into vanilla:
And I suggest a "has sunlight" - flag for chunks, comparable to the "isempty" - flag.
Yes, I can see that my suggestion is not bullet-proof.
All flags have to be recalculated at a given time. Even the "chunk-is-empty-flag" will be false if anybody just builds one single stone brick into it. I mean that flags are not meant to last forever but for delaying calculations, speeding up the rest. In standard MC, when the world is rendered, each and every block gets calculated. When looking at Yoshi9048's post you could make flags less important the nearer a player comes. With the "has-sunlight" - flag non-adjacent chunks could be rendered without caring too much about lighting. If the player comes closer, more care will be taken in calculating light. In my opinion "Sunlight" ist something special in minecraft, used only for special actions like burning skeletons or zombies. I love flags. I could imagine using a flag "monstered" for a chunk which indicates if there are any badass-mobs in it. And so on.
I believe that a cubic chunk system will have a GUI where we can adjust things according to our taste and our computer's possibilities. There will be very rough calcuting-time-saving settings which are fast but ugly aside with more time intesive settings for the graphics gourmet.