Rendering optimizations are well beyond the scope of what I'm trying to do with this mod. I certainly don't want to rewrite the tesselator. I'm just focusing on chunk management to raise the world height.
Perhaps an easier solution though is to make a special block that you can place next to your smelters that keeps that cube from unloading. That's something a mod could definitely do pretty easily.
If by "a mod could definitely do [that] pretty easily" you mean "there have been mods that do that", you are completely right. ChickenChunks (third spoiler from the bottom in that list, including the EAQ), while being outdated, is an example.
If by "a mod could definitely do [that] pretty easily" you mean "there have been mods that do that", you are completely right. ChickenChunks (third spoiler from the bottom in that list, including the EAQ), while being outdated, is an example.
Brilliant! That looks like a very useful mod. =)
I've heard of CodeChicken before, but I didn't know they had chunkloader tools too.In other news, I'm working on making the world generator cube-based! I'm almost done, except the damn lighting system hates me with the fiery passion of a thousand burning suns. Expect another fun video when I finally get this damn thing working.
I've heard of CodeChicken before, but I didn't know they had chunkloader tools too.
In other news, I'm working on making the world generator cube-based! I'm almost done, except the damn lighting system hates me with the fiery passion of a thousand burning suns. Expect another fun video when I finally get this damn thing working.
My guess is that it's because the lighting system is really bad.
Cuchaz, you might have to patch up, or completely rebuild a huge part of the lighting system at some point if you want to infinity-ise the world height. Afaik, the current system was sort of hacked in around a world height of 128 and simply cannot cope with really tall worlds.
Are you familiar with the heightmap solution from the Cubic Chunks suggestion thread?
And in regards to chunk-loaders -> it would have to operate on a 16x16x16 chunk, and by the looks of things, it seems like a normal chunk loader probably would not do this properly. It might be a really nice feature to add into the tall worlds mod by default (give it the command block texture or something lol).
My guess is that it's because the lighting system is really bad.
Cuchaz, you might have to patch up, or completely rebuild a huge part of the lighting system at some point if you want to infinity-ise the world height. Afaik, the current system was sort of hacked in around a world height of 128 and simply cannot cope with really tall worlds.
Are you familiar with the heightmap solution from the Cubic Chunks suggestion thread?
And in regards to chunk-loaders -> it would have to operate on a 16x16x16 chunk, and by the looks of things, it seems like a normal chunk loader probably would not do this properly. It might be a really nice feature to add into the tall worlds mod by default (give it the command block texture or something lol).
One thing that minecraft does very inefficiently is that when it loads a chunk it load 16*16*256, when really it only needs to load a max of 64 down/up from the player. And I do not understand how the lighting system being 'basic' would break it, lighting is applied to each fragment or geometry based on the coder's choice, so because he is drawing vertices, the only way the gpu understands, the fragments should still be shaded!
One thing that minecraft does very inefficiently is that when it loads a chunk it load 16*16*256, when really it only needs to load a max of 64 down/up from the player. And I do not understand how the lighting system being 'basic' would break it, lighting is applied to each fragment or geometry based on the coder's choice, so because he is drawing vertices, the only way the gpu understands, the fragments should still be shaded!
1) The vanilla chunk system CANNOT only load 64 blocks above and below the player. It HAS to load 16x16x256 because this is how the data is arranged. Of course, the world is rendered in 16x16x16 pieces, but that is an entirely different discussion. Of course, if anything, it may be better to load many chunks below the player, kind of as a safety net, since you can fall much faster than you can travel in any other direction.
2) It's not that the lighting system is "basic". The problem is with calculating WHEN and WHERE to use rendering powerz to make the block look HOW MUCH lighter/darker. For every block, the game calculates 2 light values, from 0 (dark) to 15 (light), one for torches and stuff, and one for the amount of sunlight that hits the block during the day.
Originally, the lighting system was not designed to accommodate future advancement in the game, and instead of redoing the kind of broken system, the devs really just kept patching it up and forcing it to work.
Afaik, the big problem is that the lighting system was hacked together with the linear chunk system in mind. That is: it is designed around the assumption that it knows where every block is on the vertical axis. Since this assumption does not hold when using Cubic Chunks, the lighting system goes insane and starts smearing its poo on the walls.
1) The vanilla chunk system CANNOT only load 64 blocks above and below the player. It HAS to load 16x16x256 because this is how the data is arranged. Of course, the world is rendered in 16x16x16 pieces, but that is an entirely different discussion. Of course, if anything, it may be better to load many chunks below the player, kind of as a safety net, since you can fall much faster than you can travel in any other direction.
2) It's not that the lighting system is "basic". The problem is with calculating WHEN and WHERE to use rendering powerz to make the block look HOW MUCH lighter/darker. For every block, the game calculates 2 light values, from 0 (dark) to 15 (light), one for torches and stuff, and one for the amount of sunlight that hits the block during the day.
Originally, the lighting system was not designed to accommodate future advancement in the game, and instead of redoing the kind of broken system, the devs really just kept patching it up and forcing it to work.
Afaik, the big problem is that the lighting system was hacked together with the linear chunk system in mind. That is: it is designed around the assumption that it knows where every block is on the vertical axis. Since this assumption does not hold when using Cubic Chunks, the lighting system goes insane and starts smearing its poo on the walls.
Every word of this is absolutely 100% true. Poo on the walls indeed!
I'm tempted to completely rewrite the lighting system now. The current lighting system is just bizarre...
In order to fix sunlight at world gen... I don't see how you could do it WITHOUT rewriting sunlight gen...
I mean... you could start everything black, and just implement the skymap/heightmap solution to start with...
But the entire lighting engine though?
Where are you sitting in the mess?
In order to fix sunlight at world gen... I don't see how you could do it WITHOUT rewriting sunlight gen...
I mean... you could start everything black, and just implement the skymap/heightmap solution to start with...
But the entire lighting engine though?
Where are you sitting in the mess?
A total rewrite is in progress. The new lighting system is going to be epicly awesome. It will also greatly reduce server lag during chunk generation. I'm offloading lighting calculations to different places so server ticks aren't overly delayed. Mojang wishes they had my lighting system. =)
Sadly, nothing in this damn mod is easy. It's all hard. I guess that's why it keeps my interest.
As for being hired; I wouldn't be surprised if they wanted to McMergerize this into their source. My only concern is that the Mojang devs are not the best coders ever, and I don't know if they could maintain something like this very well. At the very least, I do not think they would be able to improve or optimize anything that Cuchaz didn't.
This means that it would sort of be like the lighting system (albeit much less broken), in that it would go in, and then they would spend the next 50 versions applying ever more bootlegged patches trying to force it to keep working around all the other changes and additions to the game.
Lighting system rewrite is done. Chunk generation is SUPER FAST now! The whole system just screams.
I need to start working on breaking the height limit and generating some more interesting landscapes. =)
Total rewrite, or just a partial rewrite to remove the omniscience assumption?
If it's not the latter, then my onion of your skills just went up a LOT. [yes, onion]
EDIT: So you did go to the CC thread I avoided making a big deal over there, since this thread could get as inundated as that one, and that's never good during WIP stages imo.
As for being hired; I wouldn't be surprised if they wanted to McMergerize this into their source. My only concern is that the Mojang devs are not the best coders ever, and I don't know if they could maintain something like this very well. At the very least, I do not think they would be able to improve or optimize anything that Cuchaz didn't. This means that it would sort of be like the lighting system (albeit much less broken), in that it would go in, and then they would spend the next 50 versions applying ever more bootlegged patches trying to force it to keep working around all the other changes and additions to the game.
Lol, let's not get carried away here. If they want to use the source, then I'm sure we can work something out. I'm not going to worry about that though unless it actually happens.
Total rewrite, or just a partial rewrite to remove the omniscience assumption? If it's not the latter, then my onion of your skills just went up a LOT. [yes, onion]
I'd say I re-wrote about 75% of the lighting system. I tried to reorganize things to reduce lag (on the server in particular) and make it work for cubic chunks.
EDIT: So you did go to the CC thread I avoided making a big deal over there, since this thread could get as inundated as that one, and that's never good during WIP stages imo.
Yeah, I saw it. I try not to pick on Mojang's code too much. What I'm seeing is the result of a decompiler running on obfuscated class files. It's just not going to look pretty after all that madness no matter how awesome the code was to begin with. That being said, I can tell they've done a hell of a lot of optimization to try to make things speedy. There's only a few places where I can actually make improvements, and they tend to be bigger changes like vertical partitioning of the world, and different scheduling for light updates.
Lol, let's not get carried away here. If they want to use the source, then I'm sure we can work something out. I'm not going to worry about that though unless it actually happens.
Yeah, I have some negative feelings towards Mojang atm (1.8 update = "hey let's C&P slime blocks from another mod! :)"). I will try and remove myself from that bias and make my point in a less abusive way
My concern is that when you use someone else's code, especially for something like this, it can often be extremely difficult to grasp everything that it actually does and can do, no matter how well commented and organized the code is. I think that this poses a huge risk for any dev team that uses any code that they did not create themselves.
Additionally, I've always felt that Mojang have not made any big changes recently for an amalgam of two reasons, the first being a slight amount of laziness. The other is that I don't think Mojang has a resident wizard (that random dude who knows everything can fix anything, and everyone always looks to them for advice and stuff), and this makes complex changes very intimidating for a smaller dev team in Mojang's position (aka COMPATABILITY, deadlines, community expectations, etc).
The result is a more conservative dev team that is not confident enough (for lack of a better description) to make any huge steps or take any flying leaps noting that said steps and leaps are not necessary ~yet~. Instead, they have fallen back on general optimizations, minor QoL-esque tweaks, and implementation of ideas with proven popularity and feasibility. Not that this is innately bad, it's just... a frustrating shift from the old entrepreneurial approach when MC was younger.
I'd say I re-wrote about 75% of the lighting system. I tried to reorganize things to reduce lag (on the server in particular) and make it work for cubic chunks.
Looking at your source, it looks like quite a tidy implementation. If I'm not mistaken, each column of each chunk is essentially marked as being either empty or not, allowing you to skip air chunks very quickly when calculating sunlight downwards? Was there anything like that in the vanilla lighting system (I haven't looked through it for aaaages)?
Ok, good luck, and have fun. bye
ChickenChunks (third spoiler from the bottom in that list, including the EAQ), while being outdated, is an example.
also you should check out Link Removed
-
View User Profile
-
View Posts
-
Send Message
Curse PremiumBrilliant! That looks like a very useful mod. =)
I've heard of CodeChicken before, but I didn't know they had chunkloader tools too.In other news, I'm working on making the world generator cube-based! I'm almost done, except the damn lighting system hates me with the fiery passion of a thousand burning suns. Expect another fun video when I finally get this damn thing working.
Whats wrong with the lighting?
My guess is that it's because the lighting system is really bad.
Cuchaz, you might have to patch up, or completely rebuild a huge part of the lighting system at some point if you want to infinity-ise the world height. Afaik, the current system was sort of hacked in around a world height of 128 and simply cannot cope with really tall worlds.
Are you familiar with the heightmap solution from the Cubic Chunks suggestion thread?
And in regards to chunk-loaders -> it would have to operate on a 16x16x16 chunk, and by the looks of things, it seems like a normal chunk loader probably would not do this properly. It might be a really nice feature to add into the tall worlds mod by default (give it the command block texture or something lol).
I believe in the Invisible Pink Unicorn, bless her Invisible Pinkness.
One thing that minecraft does very inefficiently is that when it loads a chunk it load 16*16*256, when really it only needs to load a max of 64 down/up from the player. And I do not understand how the lighting system being 'basic' would break it, lighting is applied to each fragment or geometry based on the coder's choice, so because he is drawing vertices, the only way the gpu understands, the fragments should still be shaded!
1) The vanilla chunk system CANNOT only load 64 blocks above and below the player. It HAS to load 16x16x256 because this is how the data is arranged. Of course, the world is rendered in 16x16x16 pieces, but that is an entirely different discussion. Of course, if anything, it may be better to load many chunks below the player, kind of as a safety net, since you can fall much faster than you can travel in any other direction.
2) It's not that the lighting system is "basic". The problem is with calculating WHEN and WHERE to use rendering powerz to make the block look HOW MUCH lighter/darker. For every block, the game calculates 2 light values, from 0 (dark) to 15 (light), one for torches and stuff, and one for the amount of sunlight that hits the block during the day.
Originally, the lighting system was not designed to accommodate future advancement in the game, and instead of redoing the kind of broken system, the devs really just kept patching it up and forcing it to work.
Afaik, the big problem is that the lighting system was hacked together with the linear chunk system in mind. That is: it is designed around the assumption that it knows where every block is on the vertical axis. Since this assumption does not hold when using Cubic Chunks, the lighting system goes insane and starts smearing its poo on the walls.
I believe in the Invisible Pink Unicorn, bless her Invisible Pinkness.
-
View User Profile
-
View Posts
-
Send Message
Curse PremiumEvery word of this is absolutely 100% true. Poo on the walls indeed!
-
View User Profile
-
View Posts
-
Send Message
Curse Premium-
View User Profile
-
View Posts
-
Send Message
Curse PremiumIn order to fix sunlight at world gen... I don't see how you could do it WITHOUT rewriting sunlight gen...
I mean... you could start everything black, and just implement the skymap/heightmap solution to start with...
But the entire lighting engine though?
Where are you sitting in the mess?
-
View User Profile
-
View Posts
-
Send Message
Curse PremiumA total rewrite is in progress. The new lighting system is going to be epicly awesome. It will also greatly reduce server lag during chunk generation. I'm offloading lighting calculations to different places so server ticks aren't overly delayed. Mojang wishes they had my lighting system. =)
Sadly, nothing in this damn mod is easy. It's all hard. I guess that's why it keeps my interest.
\(* o*)/
I would be very interested to see if such a thing prompts Mojang to do something about the poopy vanilla system.
I believe in the Invisible Pink Unicorn, bless her Invisible Pinkness.
Also, please separate vertical and horizontal view distances. You would likely want to see higher and lower than side to side.
-
View User Profile
-
View Posts
-
Send Message
Curse PremiumHaha, Mojang probably couldn't afford me. =)
Besides, this is a hobby project. It's just for fun. If it was my job, it might end up being less fun.
Already done. =)
-
View User Profile
-
View Posts
-
Send Message
Curse PremiumOf course.
-
View User Profile
-
View Posts
-
Send Message
Curse PremiumI need to start working on breaking the height limit and generating some more interesting landscapes. =)
Have you considered using an ovoid view distance?
As for being hired; I wouldn't be surprised if they wanted to McMergerize this into their source. My only concern is that the Mojang devs are not the best coders ever, and I don't know if they could maintain something like this very well. At the very least, I do not think they would be able to improve or optimize anything that Cuchaz didn't.
This means that it would sort of be like the lighting system (albeit much less broken), in that it would go in, and then they would spend the next 50 versions applying ever more bootlegged patches trying to force it to keep working around all the other changes and additions to the game.
Total rewrite, or just a partial rewrite to remove the omniscience assumption?
If it's not the latter, then my onion of your skills just went up a LOT. [yes, onion]
EDIT: So you did go to the CC thread
I believe in the Invisible Pink Unicorn, bless her Invisible Pinkness.
-
View User Profile
-
View Posts
-
Send Message
Curse PremiumYup. I don't like the way it looks though. I think eventually I'm going to do real visibility calculations.
Lol, let's not get carried away here. If they want to use the source, then I'm sure we can work something out. I'm not going to worry about that though unless it actually happens.
I'd say I re-wrote about 75% of the lighting system. I tried to reorganize things to reduce lag (on the server in particular) and make it work for cubic chunks.
Yeah, I saw it. I try not to pick on Mojang's code too much. What I'm seeing is the result of a decompiler running on obfuscated class files. It's just not going to look pretty after all that madness no matter how awesome the code was to begin with. That being said, I can tell they've done a hell of a lot of optimization to try to make things speedy. There's only a few places where I can actually make improvements, and they tend to be bigger changes like vertical partitioning of the world, and different scheduling for light updates.
Yeah, I have some negative feelings towards Mojang atm (1.8 update = "hey let's C&P slime blocks from another mod! :)"). I will try and remove myself from that bias and make my point in a less abusive way
My concern is that when you use someone else's code, especially for something like this, it can often be extremely difficult to grasp everything that it actually does and can do, no matter how well commented and organized the code is. I think that this poses a huge risk for any dev team that uses any code that they did not create themselves.
Additionally, I've always felt that Mojang have not made any big changes recently for an amalgam of two reasons, the first being a slight amount of laziness. The other is that I don't think Mojang has a resident wizard (that random dude who knows everything can fix anything, and everyone always looks to them for advice and stuff), and this makes complex changes very intimidating for a smaller dev team in Mojang's position (aka COMPATABILITY, deadlines, community expectations, etc).
The result is a more conservative dev team that is not confident enough (for lack of a better description) to make any huge steps or take any flying leaps noting that said steps and leaps are not necessary ~yet~. Instead, they have fallen back on general optimizations, minor QoL-esque tweaks, and implementation of ideas with proven popularity and feasibility. Not that this is innately bad, it's just... a frustrating shift from the old entrepreneurial approach when MC was younger.
/end my opinion about Mojang
Looking at your source, it looks like quite a tidy implementation. If I'm not mistaken, each column of each chunk is essentially marked as being either empty or not, allowing you to skip air chunks very quickly when calculating sunlight downwards? Was there anything like that in the vanilla lighting system (I haven't looked through it for aaaages)?
I believe in the Invisible Pink Unicorn, bless her Invisible Pinkness.