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
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.
I just have one question; how would this affect world edit?
Again.
The dropper3 actually has ben mentioned MANY times in this thread.
Yea. Glad you like it after being away from MC for that time!
Glad to see the suppourt this gets! I have an itching feeling that we are really close this will be 1.8 - 1.9 or so. Yea. That close.
Rei's minimap?! ._.
actualy an empty chunk flag is better because untill something is placed in it, or a tree grows into it, or the like..... there is no need for it to load ever..... it just has to have something there to note it's been generated already but is empty and can be ignored
"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:
He was suggesting that the hasSunlight flag be added, not replace the isEmpty flag.
-
View User Profile
-
View Posts
-
Send Message
ModeratorI'm basing my reasoning off of giving empty chunks a flag because of the same reasons, but the OP does not mention anything about 100% solid chunks. I have read it back and forth, and the closest thing I saw was the bit about disabling X-Ray on servers, but not loading 100% solid chunks you are not near is kind of different. If I did indeed miss it somehow I do apologize.
If you use an X Ray texture pack, you can see that there can get to be some pretty big empty sections underground, so an isFull flag for anything more than 2-3 chunks away might be able to increase performance.
Want some advice on how to thrive in the Suggestions section? Check this handy list of guidelines and tips for posting your ideas and responding to the ideas of others!
http://www.minecraftforum.net/forums/minecraft-discussion/suggestions/2775557-guidelines-for-the-suggestions-forum
WorldEdit, with sk89q's permission, was partially converted over for use with Cubic Chunks back in beta 1.7.3 by Ciduxek. The conversion was called WorldEditXT and worked really well! So it would definitely be possible to update it and continue that work if someone wanted to. In fact, Ciduxek even made the Source Code avaialble before he stopped updating it! Thanks sk89q and Ciduxek!
There was also a map utillity made compatible with Cubic Chunks a long time ago, I'll have to track that down.
Plus; now that MCEdit has been updated for Anvil AND is open source, it will be easier to update it for cubic chunks than it was back in the day!
I will leave you all with a little more Cubic Inspiration:
- The Cubic Chunks Mod is back! Be a part of it's rebirth and Development.
-- Robinton's Mods: [ Mirror ] for some of his Mods incl Cubic Chunks Mod, due to DropBox broken links.
- Dungeon Generator for the Open Cubic Chunks Mod
- QuickSAVE-QuickLOAD for the Open Cubic Chunks Mod
I agree. But there are a lot of possibilities to speed up things using flags.
That sounds useful. I never saw it in MC, but if it were there, we were prepared
Anyway, this was the result using 8x8x8 sized propagation regions.
I tried applying it to a server plugin for vanilla clients, but the problem is that at least at the time, all the lighting was calculated on the client side, so it couldn't recreate light coming from occluded chunks. If you are using modded clients, however, this can probably be amended.
I'll try to hunt down the code.
*EDIT*
Woohoo, found it!
public static final short NORTHKEY = 0x7C00; public static final short SOUTHKEY = 0x43C0; public static final short EASTKEY = 0x2238; public static final short WESTKEY = 0x1126; public static final short UPKEY = 0x895; public static final short DOWNKEY = 0x44B; public static final byte NORTH = 0; public static final byte SOUTH = 1; public static final byte EAST = 2; public static final byte WEST = 3; public static final byte UP = 4; public static final byte DOWN = 5; public static int MAXBUFSIZE = 50200; public static OcclusionChunk buffer[] = new OcclusionChunk[MAXBUFSIZE]; public static void enque(OcclusionChunk chunk) { buffer[bufFront] = chunk; bufFront = (bufFront == MAXBUFSIZE-1)? 0 : bufFront+1; bufSize++; } public static OcclusionChunk dequeue() { OcclusionChunk chunk = buffer[bufBack]; buffer[bufBack] = null; bufBack = (bufBack == MAXBUFSIZE-1)? 0 : bufBack+1; bufSize--; return chunk; } //N = -Z //S = +Z //E = +X //W = -X //U = +Y //D = -Y //Connection Table: //_000001111222334 //_123452345345455 //---------------- //_NNNNNSSSSEEEWWU //_SEWUDEWUDWUDUDD public static void cull() { largestBuf = 0; int dX, dY, dZ; int absDx, absDy, absDz; int setX, setY, setZ; camX= cSet.camX; camY= cSet.camY; camZ= cSet.camZ; short occlusionLegal; int workspace; short rule; while(bufSize > 0) { OcclusionChunk chunk = dequeue(); chunk.encountered = false; if(!chunk.empty) chunk.visible = true; dX = chunk.x - camX; dY = chunk.y - camY; dZ = chunk.z - camZ; absDx = (dX>0)? dX : -dX; absDy = (dY>0)? dY : -dY; absDz = (dZ>0)? dZ : -dZ; occlusionLegal = (short) (chunk.raySource & chunk.occlusionMap); //build rule set //Workspace //00 NNNNN SSSSS EEEEE WWWWW UUUUU DDDDD outgoing //00 SEWUD NEWUD NSWUD NSEUD NSEWD NSEWU incoming workspace = 0x3FFFFFFF; workspace &= (dZ>0)? 0x01FFFFFF : 0x3EF7BDEF; workspace &= (dZ<0)? 0x3E0FFFFF : 0x1FFBDEF7; workspace &= (dX<0)? 0x3FF07FFF : 0x2F7FEF7B; workspace &= (dX>0)? 0x3FFF83FF : 0x37BDFFBD; workspace &= (dY<0)? 0x3FFFFC1F : 0x3BDEF7FE; workspace &= (dY>0)? 0x3FFFFFE0 : 0x3DEF7BDF; if((absDx < absDy) || (absDx < absDz)) workspace &= 0x3FFDEFFF; if((absDy < absDx) || (absDy < absDz)) workspace &= 0x3FFFFFDE; if((absDz < absDx) || (absDz < absDy)) workspace &= 0x1EFFFFFF; chunk.rules = workspace; //check each face (outgoing) //down rule = DOWNRULES[workspace & 0x1F]; if((occlusionLegal & rule) != 0){ cSet.flag(chunk, DOWN); chunk.output |= 1<<DOWN; } //up rule = UPRULES[(workspace>>>5) & 0x1F]; if((occlusionLegal & rule) != 0){ cSet.flag(chunk, UP); chunk.output |= 1<<UP; } //west rule = WESTRULES[(workspace>>>10) & 0x1F]; if((occlusionLegal & rule) != 0){ cSet.flag(chunk, WEST); chunk.output |= 1<<WEST; } //east rule = EASTRULES[(workspace>>>15) & 0x1F]; if((occlusionLegal & rule) != 0){ cSet.flag(chunk, EAST); chunk.output |= 1<<EAST; } //south rule = SOUTHRULES[(workspace>>>20) & 0x1F]; if((occlusionLegal & rule) != 0){ cSet.flag(chunk, SOUTH); chunk.output |= 1<<SOUTH; } //north rule = NORTHRULES[(workspace>>>25) & 0x1F]; if((occlusionLegal & rule) != 0){ cSet.flag(chunk, NORTH); chunk.output |= 1<<NORTH; } } } public static final void flag(final OcclusionChunk chunk, final short faceKey) { if(!chunk.encountered){ //check if first time encountered enque(chunk); chunk.encountered = true; } chunk.raySource |= faceKey; //apply view ray direction } public static final short NORTHRULES[] = {0x0,0x400,0x800,0xC00,0x1000,0x1400,0x1800,0x1C00,0x2000,0x2400,0x2800, 0x2C00,0x3000,0x3400,0x3800,0x3C00,0x4000,0x4400,0x4800,0x4C00,0x5000, 0x5400,0x5800,0x5C00,0x6000,0x6400,0x6800,0x6C00,0x7000,0x7400,0x7800,0x7C00}; public static final short SOUTHRULES[] = {0x0,0x40,0x80,0xC0,0x100,0x140,0x180,0x1C0,0x200,0x240, 0x280,0x2C0,0x300,0x340,0x380,0x3C0,0x4000,0x4040,0x4080, 0x40C0,0x4100,0x4140,0x4180,0x41C0,0x4200,0x4240,0x4280,0x42C0, 0x4300,0x4340,0x4380,0x43C0}; public static final short EASTRULES[] = {0x0,0x8,0x10,0x18,0x20,0x28,0x30,0x38,0x200,0x208,0x210,0x218,0x220, 0x228,0x230,0x238,0x2000,0x2008,0x2010,0x2018,0x2020,0x2028,0x2030, 0x2038,0x2200,0x2208,0x2210,0x2218,0x2220,0x2228,0x2230,0x2238}; public static final short WESTRULES[] = {0x0,0x2,0x4,0x6,0x20,0x22,0x24,0x26,0x100,0x102,0x104,0x106,0x120, 0x122,0x124,0x126,0x1000,0x1002,0x1004,0x1006,0x1020,0x1022,0x1024, 0x1026,0x1100,0x1102,0x1104,0x1106,0x1120,0x1122,0x1124,0x1126}; public static final short UPRULES[] = {0x0,0x1,0x4,0x5,0x10,0x11,0x14,0x15,0x80,0x81,0x84,0x85,0x90,0x91,0x94, 0x95,0x800,0x801,0x804,0x805,0x810,0x811,0x814,0x815,0x880,0x881,0x884, 0x885,0x890,0x891,0x894,0x895}; public static final short DOWNRULES[] = {0x0,0x1,0x2,0x3,0x8,0x9,0xA,0xB,0x40,0x41,0x42,0x43,0x48,0x49, 0x4A,0x4B,0x400,0x401,0x402,0x403,0x408,0x409,0x40A,0x40B,0x440, 0x441,0x442,0x443,0x448,0x449,0x44A,0x44B};As with the new terrain generation that will be implemented with the first public release of this mod and possibly future support for multi-layered biomes being planted before they are actually released-will we be able to create(through an api of sorts) different generation and biome code without compromising compatibility as minecraft mods do now-or will we have to modify base classes if we would want to generate our own biomes?(considering all of this would seem to need to be modified for release and considered functional thus meaning youd also have to write your own api for creating new biomes/etc similar to how forge/modloader currently do it). Essentially, are you making this forge compatible so that players can have their own biomes generated?(or would forge-coders have to make forge compatible with this mod rather than the other way around to be able to add in our own stuff on top of this mod that are also related to what this mod does, being generation of chunks, ores, and perhaps even working something with the devs of voxelsniper for specific terraforming accustomed to cubic chunks?)
In Short:
Can players add in their own terrain generation mods to override cubic chunks' default, the same way vanilla minecraft/forge(or modloader) now do it or will forge/modloader need to add support for cubic chunks to be able to do that? Also, will there be a decent terraforming mod/plugin for cubic chunks? I suppose voxelsniper would work best but idk about it being better suited to worlds like cubic chunks generated ones...(perhaps ENORMOUS treegen and volcanogen commands etc)
Everything mentioned there is something other mods would have to add, as such, there is no real answer here. A quick search shows that this topic has also come up many times and should be added to the faq, unless it has already been added, in which case, the faq should have a larger title.
Its not in the faq. But i did read the last ~9 or 10 pages and didnt see anything similar so i just decided to reply
Edit: after another ~40 pages or so, now i realize current terrain generation can already support infinite hights, but if generated terrain goes above/below height limit it simply gets cut off. As for the world generators/editors, its up to the respected owners to release compatibility for it(which lets face it, they will), this simply enables increased y axis and everything vanilla already supports it, some mods will have to be changed a bit to fit with this though(most likely forge, map modifiers, etc)
By Forge and non-forge versions, does this mean that there will be a mod applicable to the base vanilla server, and one availible for MCPC-Plus? (MCPC Plus being bukkit, spigot, and forge in one) or is forge compatibility not enough, will it need to actually be a bukkit mod for it to also work or... how would compatibility with MCPC Plus work being that forge is compatible, does that mean that cubic chunks would also be compatible?