Why not just make a chunk size 16x16x256 that way, it's a full integer array (0xFF) it's still not absolutely perfect, but it's better than 128. lighting can be calculated on a 16x16x16 basis (0F,0F,0F) in an 8 segment high chunks. solid earth chunks are precalculated and need not be lighted unless the player is close to unearthing that segment. this solves the issues of increased height, reduces workload for the CPU, and makes thing easier.
you could map large chunks where no space or light is available (i.e. it's 16 blocks from the nearest light source, no caves, solid earth) and just not render that area at all but force it to render and check lighting if it's close to the player.
would this work to speed up the game with larger vertical sized maps??
You should srs tweet this to Mojang. Don't just tell Notch, tell _Jeb too. There are 100000000's of posts asking to "OMG MAKE HIGHT LIMT [email protected]!!!!!!!!!!!" but that was actually really well thought out. o.O
Cool story Bro, ask me if i care and ask me if i know what any of this means.
If you can't understand it you are better off remaining quiet or asking politely.
Jeb said at Dreamhack they were playing around with increased map height and this seems like a good enough reason to do it if your technical info is correct. The main thing I would like to see is a thicker layer of topsoil (something like 6-8 blocks instead of the 3-4 we have now) and little to no dirt and gravel underground.
Rollback Post to RevisionRollBack
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!
Though i don't fully understand the ramifications those changes would have on the system, it certainly sounds like a good idea. :tongue.gif: I think most people would welcome a world height increase. :smile.gif:
Jeb said at Dreamhack they were playing around with increased map height and this seems like a good enough reason to do it if your technical info is correct. The main thing I would like to see is a thicker layer of topsoil (something like 6-8 blocks instead of the 3-4 we have now) and little to no dirt and gravel underground.
What do you have against dirt and gravel underground? That's my main source of gravel. Also, it's a great place to get dirt if you're OCD and don't want to **** up the landscape.
This would be great. You could build much taller buildings, and mining would be more of an effort, since you would have to go twice as far to get to the good stuff.
Cool story Bro, ask me if i care and ask me if i know what any of this means.
the skinny of it is, currently minecraft renders light in 16x16x128 chunks. I was suggesting increasing the vertical limit of the map to 256 blocks high, making it 16x16x256. but notch tweeted at one point or another [citation needed] that the main reason that he hasn't increased the height limit was because of the slowdown involved with the lighting system of rendering that extra space. now, I'm not completely positive, but if notch coded this as i think he did, he made an integer (whole number) array detailing chunks and what's in them. (at least this is how I would do it)
now, 15 in hexidecimal (base 16 numbers) is represented as 0f, since programmer math starts with 0 instead of 1 like normal human math, that makes a total number of usable "slots" in each array 16. that means that, for simplicity, notch probably has a 3 dimensional array for each chunk going from 00 to FF where 00 to 0f is the first block in the chunk, and FF is the final block in each chunk, and then using a "signed" integer (maximum -128, or 128 in each direction) to go upward inside each array detailing what blocks are in each slot. which if he made it an unsigned int, he's be able to make it 256 blocks depending on his lighting system.
the signed int makes it computationally simple to calculate lighting math, as it's just an integer, and without the fancy effects, it just shows the light as another int ranging from 0 which is black, to 15, which is sunlight or lightstone) which is probably why he was using a signed int.
Though, this is all just me making assumptions, I admit that I don't have that much experience with light engines in 3d games, and the details in how it really works in minecraft are a complete mystery to me, so I'd have to look at the sauce to see how he did it before i could make total suggestions.
though, even better culling could improve performance, but i have to say that the current method is pretty slick.
you could map large chunks where no space or light is available (i.e. it's 16 blocks from the nearest light source, no caves, solid earth) and just not render that area at all but force it to render and check lighting if it's close to the player.
would this work to speed up the game with larger vertical sized maps??
-
View User Profile
-
View Posts
-
Send Message
ModeratorIf you can't understand it you are better off remaining quiet or asking politely.
Jeb said at Dreamhack they were playing around with increased map height and this seems like a good enough reason to do it if your technical info is correct. The main thing I would like to see is a thicker layer of topsoil (something like 6-8 blocks instead of the 3-4 we have now) and little to no dirt and gravel underground.
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
What do you have against dirt and gravel underground? That's my main source of gravel. Also, it's a great place to get dirt if you're OCD and don't want to **** up the landscape.
the skinny of it is, currently minecraft renders light in 16x16x128 chunks. I was suggesting increasing the vertical limit of the map to 256 blocks high, making it 16x16x256. but notch tweeted at one point or another [citation needed] that the main reason that he hasn't increased the height limit was because of the slowdown involved with the lighting system of rendering that extra space. now, I'm not completely positive, but if notch coded this as i think he did, he made an integer (whole number) array detailing chunks and what's in them. (at least this is how I would do it)
now, 15 in hexidecimal (base 16 numbers) is represented as 0f, since programmer math starts with 0 instead of 1 like normal human math, that makes a total number of usable "slots" in each array 16. that means that, for simplicity, notch probably has a 3 dimensional array for each chunk going from 00 to FF where 00 to 0f is the first block in the chunk, and FF is the final block in each chunk, and then using a "signed" integer (maximum -128, or 128 in each direction) to go upward inside each array detailing what blocks are in each slot. which if he made it an unsigned int, he's be able to make it 256 blocks depending on his lighting system.
the signed int makes it computationally simple to calculate lighting math, as it's just an integer, and without the fancy effects, it just shows the light as another int ranging from 0 which is black, to 15, which is sunlight or lightstone) which is probably why he was using a signed int.
Though, this is all just me making assumptions, I admit that I don't have that much experience with light engines in 3d games, and the details in how it really works in minecraft are a complete mystery to me, so I'd have to look at the sauce to see how he did it before i could make total suggestions.
though, even better culling could improve performance, but i have to say that the current method is pretty slick.
I'm not going to explain culling, and will leave that as an exercise to the reader.
Start here: http://en.wikipedia....e_determination
let me know if you need any more explanation. however I cant vouch that it will become less complex. :laugh.gif: