Suggestion: Double (or more) the available Z axis in the world above-ground.
Sixty four blocks from sea level to sky is not a lot of room to work with in a world that extends almost infinitely in all directions X and Y. I think we need more headroom!
No, I'm pretty sure people enjoy their saves with mountains that go up to the clouds and have a flat surface that they can walk around on and they can't build on it.
I have a design I would like to build that is 450 feet from base to summit. If I was to begin building it at bedrock (level 1) I couldn't fit it all into Minecraft in its present form.
The present 'roof' of 128 blocks from the bottom of the world to the top of the sky is roughly the same as 420 feet. These days, many, many buildings are taller than this. If you remove a few bits from the lateral and horizontal axes (width & length) and add those bits to increasing height you can drop the size of the world to roughly equal to the size of the Earth and increase its height to 2048 blocks, which would be almost 7000 feet.
No Mt. Everest would be possible, but you would be able to build almost anything reasonable in that area.
If the chunks are loaded into memory in an 9x9 pattern, and memory is an issue, the buffer can be lowered to 5x5 and simply have mountains and hills grow taller, and have significantly more underground area to explore. This would also reduce sight distance, causing fewer chunks needing to be generated at one time.
Sounds like a good idea to me. I'm not sure how easy this would be to implement, but it certainly wouldn't hurt to be able to build epically tall structures. I also really like the idea of having mountains being even bigger than they are now.
I'm voting for this :biggrin.gif:. I'd love to have the height increased, hopefully to over 300, or even 500 blocks high. (I mainly want this so Notch would think about adding mega monsters )
These days, many, many buildings are taller than this. If you remove a few bits from the lateral and horizontal axes (width & length) and add those bits to increasing height you can drop the size of the world to roughly equal to the size of the Earth and increase its height to 2048 blocks
Minecraft doesn't work this way and this isn't the reason for the height limit.
Everyone has to realize that the vertical direction is fundamentally different from the horizontal directions. It is subject to gravity and the limitations of the lighting engine.
Don't get me wrong, more vertical space would be fantastic, but the way the engine works it just isn't an easy change.
Rollback Post to RevisionRollBack
Never attribute to malice what can adequately be explained by incompetence.
The reason this hasn't been done [or just one of them] is the issues it will cause.
A map is rendered a chunk at a time, which is 16x16x128 blocks
but more then one chunk is normally rendered/generated/put into memory
so its really 16x16x128x<Number of chunks>
even just 9 chunks make a total of 41,472 blocks
increasing the height to just 138 brings the total to 317,952, around a 10% increase
so you can see the issues with increasing the ceiling or lowering the floor more for users with slower machines
though notch has expressed interest in trying make a single chunk able to go higher
such as this:
= void, nothing, not even air blocks
[] = well, air
Ehh... Not a definite no, but I seriously question the purpose for anything so tall that you need to raise the ceiling. Perhaps maybe in creative sandbox games where the admins might be able to define the exact size of a map, but otherwise I don't think it's really needed. Certainly not in something like survival where falling a relatively short distance is already going to kill you and there are no fast AND safe ways of getting down. A waterfall or a spiraling mine cart might get you there eventually, but imagine the time to get back up? In survival, you might spend a day or two just running up to the top.
So my vote... maybe a definable height in sandboxes for the people who want to make insanely large sculptures or something, but otherwise no.
Rollback Post to RevisionRollBack
Quote from Berginator94 »
I'm almost 100% positive that this have been suggested before but i'll suggest it again anyways
Ehh... Not a definite no, but I seriously question the purpose for anything so tall that you need to raise the ceiling. Perhaps maybe in creative sandbox games where the admins might be able to define the exact size of a map, but otherwise I don't think it's really needed. Certainly not in something like survival where falling a relatively short distance is already going to kill you and there are no fast AND safe ways of getting down. A waterfall or a spiraling mine cart might get you there eventually, but imagine the time to get back up? In survival, you might spend a day or two just running up to the top.
So my vote... maybe a definable height in sandboxes for the people who want to make insanely large sculptures or something, but otherwise no.
imagine an elevator like this (yes it works)
=waterspring
=waterflow
=where you have to stand, and press 'W' to move up (looking up ofcourse)
how it looks from the top:
front view:
this is the quickest possible way to get up, however it does require a bit of space
If this can truly be done in a memory cheap and quick way, im not sure
but yes, many would like taller/deeper maps
I like this idea quite a bit... Getting extra height when and where your world needs it without all the performance overhead from doing a blanket increase.
These days, many, many buildings are taller than this. If you remove a few bits from the lateral and horizontal axes (width & length) and add those bits to increasing height you can drop the size of the world to roughly equal to the size of the Earth and increase its height to 2048 blocks
Minecraft doesn't work this way and this isn't the reason for the height limit.
Everyone has to realize that the vertical direction is fundamentally different from the horizontal directions. It is subject to gravity and the limitations of the lighting engine.
Don't get me wrong, more vertical space would be fantastic, but the way the engine works it just isn't an easy change.
The lighting seems to be top-down constant value until it hits a block. That doesn't require a fundamental change to anything as the distance it goes down isn't relevant to its value (I dug a tunnel from ceiling to base of the world and filled it with glass once to test this and it was just as bright at the bottom as it was at sea level and above.
Gravity is also a relative constant (acceleration to a fixed speed), regardless of height. This reasoning doesn't make sense to say that a taller world would be more difficult to code when this is a constant not relative to height.
Quote from magix39 »
The reason this hasn't been done [or just one of them] is the issues it will cause.
A map is rendered a chunk at a time, which is 16x16x128 blocks
but more then one chunk is normally rendered/generated/put into memory
so its really 16x16x128x<Number of chunks>
even just 9 chunks make a total of 41,472 blocks
increasing the height to just 138 brings the total to 317,952, around a 10% increase
so you can see the issues with increasing the ceiling or lowering the floor more for users with slower machines
though notch has expressed interest in trying make a single chunk able to go higher
such as this:
= void, nothing, not even air blocks
[] = well, air
If this can truly be done in a memory cheap and quick way, im not sure
but yes, many would like taller/deeper maps
I recognize the memory problem and even suggested a change to take that into account. Only rendering to 5x5 chunks instead of 9x9 to account for the increase in vertical memory space. With the terrain getting taller you wouldn't be seeing as far anyway, so rendering farther away wouldn't be terribly necessary until you got up to a tall location.
People on higher-end machines can set their view distance to Far to take advantage of their available memory while people on lower-end machines can set their view distances to as small as Tiny so as not to take up as much memory.
In neither case is this an impossible or unrealistic task.
Actually, I have a potential solution: two categories of chunks: Above sea level, and below sea level.
Above sea level chunks can go up to 256, or even 512. They are rendered out to 9x9 normally as the majority of their values are going to be air squares which don't require as much video memory to render. This will be where most of the RAM-intense storage will be.
Below sea level chunks get generated as they are moved into, or within viewing distance of your location. You never see very far underground at one time anyway unless a miner intentionally digs a long, straight tunnel. This will also help to prevent the 'I can see way underground when the map's not loaded' effect in SMP, as well as making maps in single player easier to view in most of the editors/viewers, without being able to really search around underground without actually travelling there first. Given that, while underground, you won't have to render any above-sea-level chunks they can be unloaded from memory, freeing up resources.
Ehh... Not a definite no, but I seriously question the purpose for anything so tall that you need to raise the ceiling.
I enjoy recreating buildings in Minecraft. One in particular I would LIKE to recreate is Castle Ravenloft from the 1983 AD&D adventure.
The castle, itself, is 450 feet from base of the bottom floor to the top of the steeple on the top floor.
450 feet = 135 blocks vertical
Current limit = 128 blocks from bottom of WORLD, let alone sea level.
Then, we have the surroundings:
The castle rests on a hill with sharp cliffs surrounding it, of at least 500 feet in height.
Accounting for how much of the castle is underground, that requires around 900 feet from base of cliff to top of steeple.
900 feet = 270 blocks vertical
But wait, there's more!
Those cliffs overlook a village, which is itself at roughly 0 elevation, but at least 1000 feet beneath the base of the cliffs around the castle.
That requires, to build this entire area, an available vertical height of 1900 feet, without anything underground in the nearby village. Giving it even 100 feet below the village is roughly 2000 feet.
2000 feet = approx 600 Minecraft blocks in height.
No way I could build it in Minecraft as it now stands.
(side note: I am building another, more flat city (called Briarwood) on zeryl's minecraft server (called Moose Valley). Probably take me a few months to finish but it's not too terribly tall, which is why I am trying it. I keep hoping the ceiling is raised so I can make the Ravenloft castle while I am offline, and Briarwood when I am online.)
The lighting seems to be top-down constant value until it hits a block
Yes, it is. When a chunk is first generated the lighting engine has to determine where to stop the lighting. For this it basically has to scan downwards. It keeps track of the highest block in each column to make this operation faster afterwards.
The other issue with increasing vertical chunk size is a processing step that generates the actual block faces that the engine has to render. Doubling the vertical height would double the chunk loading time. It would also double the memory requirements for the game.
This reasoning doesn't make sense to say that a taller world would be more difficult to code when this is a constant not relative to height.
It makes perfect sense when my goal is to point out fundamental anisotropies between different directions. I don't know why you're hung up on this "it's a constant so it doesn't matter" nonsense, because it's entirely beside the point. Gravity itself doesn't slow things down, what it does is allow the player to reach large speeds in the vertical direction. This means that splitting chunks vertically can run into problems with chunk loading times if a player is falling (this is straight from Notch's mouth when someone asked him on the IRC channel). When you're walking or riding a mine cart, it can manage to load the chunks just fast enough that you won't notice, but these are both significantly slower than falling would be.
Another problem with vertically split chunks again comes with the lighting engine no longer being able to locally keep track of the highest block in a column since the highest block may not actually be within a given chunk. This means that modifying a high altitude chunk would have to check each chunk below it (which may not be loaded) to make sure to update its state.
Rollback Post to RevisionRollBack
Never attribute to malice what can adequately be explained by incompetence.
water elevators using a boat is the quickest way up... other than that it's laders....
a good way to work those is:
[] [] []
[]
[]
[] [] []
with being laders
makes a nice safe area for fast climbing and decent
Rollback Post to RevisionRollBack
I aim to please ... and occasionally mentally scar. "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:
I personally like the idea and Biggie Smalls, but there should be clouds and stuff still the way it is just like stars or something higher like a new layer above the clouds...idk work with me! :wink.gif:
I personally like the idea and Biggie Smalls, but there should be clouds and stuff still the way it is just like stars or something higher like a new layer above the clouds...idk work with me! :wink.gif:
Yeah!
Also you should be able to go into space and visit the moon o.o lol
Ehh... Not a definite no, but I seriously question the purpose for anything so tall that you need to raise the ceiling.... *clipped*
I enjoy recreating buildings in Minecraft. One in particular I would LIKE to recreate is Castle Ravenloft from the 1983 AD&D adventure.
The castle, itself, is 450 feet from base of the bottom floor to the top of the steeple on the top floor.
450 feet = 135 blocks vertical
Current limit = 128 blocks from bottom of WORLD, let alone sea level.... *clipped*
Which would be the exact reason I said it might be fine for sandbox/creative maps, just not in things like survival. Make sure you read an entire post before quoting just the first few words of it.
Rollback Post to RevisionRollBack
Quote from Berginator94 »
I'm almost 100% positive that this have been suggested before but i'll suggest it again anyways
Sixty four blocks from sea level to sky is not a lot of room to work with in a world that extends almost infinitely in all directions X and Y. I think we need more headroom!
I have a design I would like to build that is 450 feet from base to summit. If I was to begin building it at bedrock (level 1) I couldn't fit it all into Minecraft in its present form.
The present 'roof' of 128 blocks from the bottom of the world to the top of the sky is roughly the same as 420 feet. These days, many, many buildings are taller than this. If you remove a few bits from the lateral and horizontal axes (width & length) and add those bits to increasing height you can drop the size of the world to roughly equal to the size of the Earth and increase its height to 2048 blocks, which would be almost 7000 feet.
No Mt. Everest would be possible, but you would be able to build almost anything reasonable in that area.
If the chunks are loaded into memory in an 9x9 pattern, and memory is an issue, the buffer can be lowered to 5x5 and simply have mountains and hills grow taller, and have significantly more underground area to explore. This would also reduce sight distance, causing fewer chunks needing to be generated at one time.
No, seriously, check it out. It's got content!
Minecraft doesn't work this way and this isn't the reason for the height limit.
Everyone has to realize that the vertical direction is fundamentally different from the horizontal directions. It is subject to gravity and the limitations of the lighting engine.
Don't get me wrong, more vertical space would be fantastic, but the way the engine works it just isn't an easy change.
A map is rendered a chunk at a time, which is 16x16x128 blocks
but more then one chunk is normally rendered/generated/put into memory
so its really 16x16x128x<Number of chunks>
even just 9 chunks make a total of 41,472 blocks
increasing the height to just 138 brings the total to 317,952, around a 10% increase
so you can see the issues with increasing the ceiling or lowering the floor more for users with slower machines
though notch has expressed interest in trying make a single chunk able to go higher
such as this:
= void, nothing, not even air blocks
[] = well, air
[]
[]
[] [] [] [] [] [] [] []
[] [] [] [] [] [] [] []
[] [] [] [] [] [] [] []
If this can truly be done in a memory cheap and quick way, im not sure
but yes, many would like taller/deeper maps
I support the height increase.
I support these!
So my vote... maybe a definable height in sandboxes for the people who want to make insanely large sculptures or something, but otherwise no.
imagine an elevator like this (yes it works)
=waterspring
=waterflow
=where you have to stand, and press 'W' to move up (looking up ofcourse)
how it looks from the top:
front view:
this is the quickest possible way to get up, however it does require a bit of space
I like this idea quite a bit... Getting extra height when and where your world needs it without all the performance overhead from doing a blanket increase.
The lighting seems to be top-down constant value until it hits a block. That doesn't require a fundamental change to anything as the distance it goes down isn't relevant to its value (I dug a tunnel from ceiling to base of the world and filled it with glass once to test this and it was just as bright at the bottom as it was at sea level and above.
Gravity is also a relative constant (acceleration to a fixed speed), regardless of height. This reasoning doesn't make sense to say that a taller world would be more difficult to code when this is a constant not relative to height.
I recognize the memory problem and even suggested a change to take that into account. Only rendering to 5x5 chunks instead of 9x9 to account for the increase in vertical memory space. With the terrain getting taller you wouldn't be seeing as far anyway, so rendering farther away wouldn't be terribly necessary until you got up to a tall location.
People on higher-end machines can set their view distance to Far to take advantage of their available memory while people on lower-end machines can set their view distances to as small as Tiny so as not to take up as much memory.
In neither case is this an impossible or unrealistic task.
Actually, I have a potential solution: two categories of chunks: Above sea level, and below sea level.
Above sea level chunks can go up to 256, or even 512. They are rendered out to 9x9 normally as the majority of their values are going to be air squares which don't require as much video memory to render. This will be where most of the RAM-intense storage will be.
Below sea level chunks get generated as they are moved into, or within viewing distance of your location. You never see very far underground at one time anyway unless a miner intentionally digs a long, straight tunnel. This will also help to prevent the 'I can see way underground when the map's not loaded' effect in SMP, as well as making maps in single player easier to view in most of the editors/viewers, without being able to really search around underground without actually travelling there first. Given that, while underground, you won't have to render any above-sea-level chunks they can be unloaded from memory, freeing up resources.
No, seriously, check it out. It's got content!
I enjoy recreating buildings in Minecraft. One in particular I would LIKE to recreate is Castle Ravenloft from the 1983 AD&D adventure.
The castle, itself, is 450 feet from base of the bottom floor to the top of the steeple on the top floor.
450 feet = 135 blocks vertical
Current limit = 128 blocks from bottom of WORLD, let alone sea level.
Then, we have the surroundings:
The castle rests on a hill with sharp cliffs surrounding it, of at least 500 feet in height.
Accounting for how much of the castle is underground, that requires around 900 feet from base of cliff to top of steeple.
900 feet = 270 blocks vertical
But wait, there's more!
Those cliffs overlook a village, which is itself at roughly 0 elevation, but at least 1000 feet beneath the base of the cliffs around the castle.
That requires, to build this entire area, an available vertical height of 1900 feet, without anything underground in the nearby village. Giving it even 100 feet below the village is roughly 2000 feet.
2000 feet = approx 600 Minecraft blocks in height.
No way I could build it in Minecraft as it now stands.
(side note: I am building another, more flat city (called Briarwood) on zeryl's minecraft server (called Moose Valley). Probably take me a few months to finish but it's not too terribly tall, which is why I am trying it. I keep hoping the ceiling is raised so I can make the Ravenloft castle while I am offline, and Briarwood when I am online.)
No, seriously, check it out. It's got content!
Yes, it is. When a chunk is first generated the lighting engine has to determine where to stop the lighting. For this it basically has to scan downwards. It keeps track of the highest block in each column to make this operation faster afterwards.
The other issue with increasing vertical chunk size is a processing step that generates the actual block faces that the engine has to render. Doubling the vertical height would double the chunk loading time. It would also double the memory requirements for the game.
It makes perfect sense when my goal is to point out fundamental anisotropies between different directions. I don't know why you're hung up on this "it's a constant so it doesn't matter" nonsense, because it's entirely beside the point. Gravity itself doesn't slow things down, what it does is allow the player to reach large speeds in the vertical direction. This means that splitting chunks vertically can run into problems with chunk loading times if a player is falling (this is straight from Notch's mouth when someone asked him on the IRC channel). When you're walking or riding a mine cart, it can manage to load the chunks just fast enough that you won't notice, but these are both significantly slower than falling would be.
Another problem with vertically split chunks again comes with the lighting engine no longer being able to locally keep track of the highest block in a column since the highest block may not actually be within a given chunk. This means that modifying a high altitude chunk would have to check each chunk below it (which may not be loaded) to make sure to update its state.
a good way to work those is:
[] [] []
[]
[]
[] [] []
with being laders
makes a nice safe area for fast climbing and decent
"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:
Yeah!
Also you should be able to go into space and visit the moon o.o lol
Which would be the exact reason I said it might be fine for sandbox/creative maps, just not in things like survival. Make sure you read an entire post before quoting just the first few words of it.