Minecraft Forums

Quote from Barteks2x»

If the mountain is actually loaded...

And the problem isn't that you can see the sun when you shouldn't. The problem is how to determine light levels when blocks above you are not always loaded.

The light levels are hardly the problem. The shadow of a floating, unloaded island can safely be ignored because we don't know if the user will ever go up there. Do you really care about the shadow of some huge island in the sky on the ground making the lightlevel equivalent of a cave unless you know about it (in other words, it was loaded before)?

Quote from link_the_programmer»

The light levels are hardly the problem. The shadow of a floating, unloaded island can safely be ignored because we don't know if the user will ever go up there. Do you really care about the shadow of some huge island in the sky on the ground making the lightlevel equivalent of a cave unless you know about it (in other words, it was loaded before)?

Problem is not in some hypothetical islands somewhere, it's in the high ceiling that is just one block out of your render distance. Besides, it's solved already, so stop with that.

Dear Jeb:

Quote from Johnbgood626»

Dear Jeb:

DO IT DO IT DO IT DO IT DO IT DO IT DO IT DO IT DO IT DO IT DO IT DO IT DO IT DO IT DO IT DO IT DO IT DO IT DO IT DO IT DO IT DO IT DO IT DO IT DO IT DO IT DO IT DO IT DO IT DO IT DO IT DO IT DO IT DO IT DO IT DO IT DO IT DO IT DO IT DO IT DO IT DO IT DO IT DO IT DO IT DO IT DO IT DO IT DO IT DO IT DO IT DO IT DO IT DO IT DO IT DO IT DO IT DO IT DO IT DO IT DO IT DO IT DO IT DO IT DO IT DO IT DO IT DO IT DO IT DO IT DO IT DO IT DO IT DO IT DO IT DO IT DO IT DO IT DO IT DO IT DO IT DO IT DO IT DO IT DO IT DO IT DO IT DO IT DO IT DO IT DO IT DO IT DO IT DO IT DO IT DO IT DO IT DO IT DO IT DO IT DO IT DO IT DO IT DO IT DO IT DO IT DO IT DO IT DO IT DO IT DO IT DO IT DO IT DO IT DO IT DO IT DO IT DO IT DO IT DO IT DO IT DO IT DO IT DO IT DO IT DO IT DO IT DO IT DO IT DO IT DO IT DO IT DO IT DO IT DO IT DO IT DO IT DO IT DO IT DO IT DO IT DO IT DO IT DO IT DO IT DO IT DO IT DO IT DO IT DO IT DO IT DO IT DO IT DO IT DO IT DO IT DO IT DO IT DO IT DO IT DO IT DO IT DO IT DO IT DO IT DO IT DO IT DO IT DO IT DO IT DO IT DO IT DO IT DO IT DO IT DO IT DO IT DO IT DO IT DO IT DO IT DO IT DO IT DO IT DO IT DO IT DO IT DO IT DO IT DO IT DO IT DO IT DO IT DO IT DO IT DO IT DO IT DO IT DO IT DO IT DO IT DO IT DO IT DO IT DO IT DO IT DO IT DO IT DO IT DO IT DO IT DO IT DO IT DO IT DO IT DO IT DO IT DO IT DO IT DO IT DO IT DO IT DO IT DO IT DO IT DO IT DO IT DO IT DO IT DO IT DO IT DO IT DO IT DO IT DO IT DO IT DO IT DO IT DO IT DO IT DO IT DO IT DO IT DO IT DO IT DO IT DO IT DO IT DO IT DO IT DO IT DO IT DO IT DO IT DO IT DO IT DO IT DO IT DO IT DO IT DO IT DO IT DO IT DO IT DO IT DO IT DO IT DO IT DO IT DO IT DO IT DO IT DO IT DO IT DO IT DO IT DO IT DO IT DO IT DO IT DO IT DO IT DO IT DO IT DO IT DO IT DO IT DO IT DO IT DO IT DO IT DO IT DO IT DO IT DO IT DO IT DO IT DO IT DO IT DO IT DO IT DO IT DO IT DO IT DO IT DO IT DO IT DO IT DO IT DO IT DO IT DO IT DO IT DO IT DO IT DO IT DO IT DO IT DO IT DO IT DO IT DO IT DO IT DO IT DO IT DO IT DO IT DO IT DO IT DO IT....please?

Sadly they aren't going to move a finger. See my signature? Colored lights are actually working, but guess what? They just don't care.

Quote from straightdigger»

Sadly they aren't going to move a finger. See my signature? Colored lights are actually working, but guess what? They just don't care.

Yeah, if there is one thing that bugs me about Minecraft, it is Mojang itself. Instead of listening to community suggestions and what the fanbase wants to see in the game they are a fan of, they only seem to add what 'they' think is necessary at the time. And not at all to dis it, but for me, even though this new PvP update is cool, I think Minecraft is really due for a performance/mechanics improvement. Not to say Mojang never listens to the community, for example, More Wood Items, but they really could do it more than rarely--especially when it is something that is SO practical to performance (or atleast will be,) take, for example my situation: usually, I'll average around 200 fps (which is already great of course,) but then paired with cubic chunks (development version) it hit 1200 fps at some times! Anyway, I totally see your pain, man!

[Btw, I know 1200 fps has NO practicality, but I used it just as a reference for the performance increase provided by cubic chunks]

Quote from DragonPoizen»

... especially when it is something that is SO practical to performance (or atleast will be,) take, for example my situation: usually, I'll average around 200 fps (which is already great of course,) but then paired with cubic chunks (development version) it hit 1200 fps at some times! Anyway, I totally see your pain, man!

[Btw, I know 1200 fps has NO practicality, but I used it just as a reference for the performance increase provided by cubic chunks]

I would not take those numbers as a proof yet. On one hand, it's still in development, so there should be plenty of space for improvement and optimization, but on another one current worlds in the mod are much more simple than vanilla ones, simpler terrain generation (exactly one block of dirt and one grass on top of the stone), no trees anywhere, less caves (I may be wrong, but for me it looked like they start to spawn only in the negative Y ore somewhere around zero) and I don't think I saw a mob spawn naturally, so no pathing calculations.

In other words, it can still go both ways for Tall Worlds, but in principal it really should help.

In relation to the problem of sunlight, what if you were to create a large noise map, use it to generate the position of chunks, then apply sunlight to the chunks above the map. you could then generate a second map below that map with a little variance, and use that to generate the actual terrain. you could then take the difference between the two maps, and apply sunlight to that.

Quote from straightdigger»

I would not take those numbers as a proof yet. On one hand, it's still in development, so there should be plenty of space for improvement and optimization, but on another one current worlds in the mod are much more simple than vanilla ones, simpler terrain generation (exactly one block of dirt and one grass on top of the stone), no trees anywhere, less caves (I may be wrong, but for me it looked like they start to spawn only in the negative Y ore somewhere around zero) and I don't think I saw a mob spawn naturally, so no pathing calculations.

In other words, it can still go both ways for Tall Worlds, but in principal it really should help.

Yeah, man! You are totally right about that too. The whole performance spike I was noting was of course, under the just about the best conditions, so I was hoping that it didn't sound like I was saying that is the case for everyone, either--I guess it sorta did though ;P. Anyway, as you mentioned, I was just providing the example it had increased my performance, showing the potential to do so, and that it has potential to make up for fixing mobs and landscape decoration in that, it still has lots of room to be optimized as well! ;D

Anyway, I am still very excited in just the concept of this mod and the overall improvement to minecraft it will provide. Anyone who disses it--to me atleast--better have a darn good reason! XD

Quote from Brettd3000»

I am actually interested in coding and stuff, but mainly do javascript, not quite as complicated as java

I would have thought the shading would be calculated based on more than just the column above the block, but thinking about it, blurring the result would actually be better.

yeah! i agree with cuchaz! that is a great idea!

i am also interested in java programming too, but i seem to be stuck struggling with system.out ;P

Edit: sorry, i guess this wasnt really my conversation to drop in on, i felt subconsciously obligated when someone brought back the sunlight issue and responded an intelligent way XD ...yeah again, though, great thinking!

Quote from straightdigger»

Problem is not in some hypothetical islands somewhere, it's in the high ceiling that is just one block out of your render distance. Besides, it's solved already, so stop with that.

Then in that case, give the user control as to how far you can see chunks, but only make it a soft reference so that only visible chunks are loaded. For instance, that high ceiling. If you have a render distance of 2, and the ceiling is 3 chunks above, that would count as visible. If the ceiling is higher than the vanilla minecraft height, then it can be ignored. Also, I don't think that anyone would build a ceiling that you can't see from the ground because usually you want a person to actually see the ceiling rather than a large hole in the roof because the chunks aren't loaded.

Really, the way I would load chunks is:

1. load visible chunks

2. always keep immediate chunks loaded (all chunks immediately surrounding the player)

3. load ceiling chunks last.

4. Have chunks generated on their own thread.

In other words, give chunks a dynamic priority (of type byte) that is calculated from raytracing and distance from player.

In their thread, have the chunks queued onto a ChunkQueue by their priority type(0's first, 1's second, etc). Have it

calculate the priorities of the chunks with a mouseMoved() Event and only of unloaded chunks.

If the player leaves the area, the Chunks should be cached into RAM and unloaded. I would suggest that if the player

goes more than 16 chunks from when that chunk was unloaded, that it be compressed so as to not hog memory,

and decompressed in a separate thread when the player re-enters a 16 chunk region.

Other optimizations would include:

• replace the current minecraft game loop with Fork/Join.
• optimize particles.
• optimize smooth lighting.

But hey I mean that's just how I would optimize the game with 3D chunks... Just sayin' Mr. @Calacbolg and @straightdigger No biggie

Quote from link_the_programmer»

Really, the way I would load chunks is:

1. load visible chunks

2. always keep immediate chunks loaded (all chunks immediately surrounding the player)

3. load ceiling chunks last.

4. Have chunks generated on their own thread.

But hey I mean that's just how I would optimize the game with 3D chunks... Just sayin' Mr. @Calacbolg and @straightdigger No biggie

Load? You mean render? Loading chunks in a radius about the player is best to preserve the world simulation. Even invisible chunks. Hidden redstone/mobs still need to be loaded into the world to function. Rendering can be done completely separately without affecting loading (within limitations), but loading chunks should be based on straight proximity, not fancy visibility calculations.

Quote from kwerti»

Load? You mean render? Loading chunks in a radius about the player is best to preserve the world simulation. Even invisible chunks. Hidden redstone/mobs still need to be loaded into the world to function. Rendering can be done completely separately without affecting loading (within limitations), but loading chunks should be based on straight proximity, not fancy visibility calculations.

No, I don't mean render. And loading chunks in a radius about the player is #2 if you didn't get that the first or second time. The CPU intensive calculations are in the world generation (chunk loading) because of the generation algorithms, so loading chunks based on a calculated priority based on what you are looking at ([raytracing] which is already in vanilla chunk loading), and how far the player is from that chunk (the radial distance), would be an efficient way of loading chunks (theoretically).

That's what happens in minecraft already, and I wouldn't think anyone has any plans to stop allowing the user that option?

The soft reference isn't only for that. See next sentence.

No it wouldn't, because 3 > 2? If it's only loading chunks 2 chunks away, it won't load a chunk 3 away?

That's what the soft reference is for. It's a soft reference because it is more like a target render distance that you try to stay within, and only exceeds that limit if necessary.

o.
One of the points of having cubic chunks is so that you can build above the vanilla minecraft height. So if you give the user that option, and then when they actually use it, saying "that doesn't matter, what you just built "can be ignored"" is ridiculous.Just because someone has built something which is outside of their render distance does not mean they want whatever they built to be ignored, it simply means they don't have a high enough render distance to see it. If I have a render distance of 5, and build a wall and ceiling 6+ chunks tall, I would never want the ceiling to be ignored, saying that you don't think someone would build something outside of their render distance is silly.

256/16 = 16 chunks. The max vanilla render distance is 16 chunks. Do you want the ceiling algorithm to exceed a soft reference of 2 chunks for a ceiling that is more than 16 chunks high? A ceiling 16 chunks high exceeds the target render distance of 2 by 14 chunks! Probably shouldn't do that hm? Perhaps a ratio of chunks for the soft reference... how about 2/8? a render distance of 16 would now allow 64 cumulative extra chunks for all axes.

: what if the player is looking upwards?4 is irrelevant, world generation is not really an issue here, as far as I know.

3:*cough* dynamic chunk priority *cough* 4 is entirely relevant. You usually spend your time doing 25% mining, 25% crafting and using apparatuses, and 50% exploring the world, depending on the person. World generation and loading in one of their own threads at an above average priority would improve performance.

Using fork/join is fine, "optimize particles" and "optimize smooth lighting" are not actual optimizations, you are merely listing things you think could be optimized, not how to actually do it.

actually, all three are just listings. I know for a fact particles could be optimized because for some reason, particles and floating text are why I get lag, rather than chunk loading or entity ticking :L and smooth lighting causes a 10 FPS drop during chunk loading because of obvious reasons.

World generation and chunk loading are two separate things, a chunk will only be generated once when it is first loaded, but loaded every time the player comes near it. Loading chunks can be intensive, but not to the same extent as world generation, and world generation is only done once(per chunk), so including that in the priority won't have much of an effect.

see paragraph before last. Also, even if it's done once, they are the reason for lag spikes, besides the lag spikes we already get from loading chunks in the first place (that are less intense). I have found that a great minecraft FPS booster is my USB 3.0 1TB HDD which has a faster read/write speed than my system drive. If minecraft only wrote and read to RAM, then saved to harddrive on shutdown, minecraft would be so much faster, but at the risk of losing all the work after you just finished building a giant redstone house because your computer crashed somehow.

I hope that raytracing is not in vanilla minecraft, loading chunks based on what axis you are looking at is fine, but using raytracing to load chunks seems to me to be over complicated, and inefficient.

Ray-tracing is just another technical term for calculating what your eye is looking at, and is as simple as getting the position of an object on screen (and since things are translated as (x, y, z) -> (u, v), it's as simple as getting the vector (u, v). No biggie). It would be like with a 2D game and getX() or getY() which don't take any calculations at all, and isn't complicated as you can see. If you don't have getX() or getY(), then you would have to calculate them, which is stupid.

Quote from Brettd3000»

Ok, sorry I would have a more specific definition of raytracing, what you are talking about I would call perspective projection, or 3d projection, and yeah, it's fairly simple.
Raytracing however, I would not use in the same way, I do 3d graphics and stuff, so I would think of raytracing as something different, literally tracing a ray, and finding intersections/reflections/shadows. Of course minecraft would use 3d projection, every 3d game uses it to actually display the world, but raytracing is a lot more intensive to compute, generally it would only be used for realistic, none realtime graphics.
Anyway, back to chunks. 3d projection is all very cool, but I don't see why it's needed? when loading chunks, I would think it would be easier, and simpler to just use the direction the player is facing, and load chunks based on that, instead of the chunks position on screen?

Sorry for getting into the conversation, I just feel like a little clarification is needed.

First, raytracing is actually in the game, that's how explosions work. Second, it can be used to load and render chunks that are farther away from you. Imagine you have a radius where every chunk is strictly loaded, and then radius where only visible ones are. And it would be best to have that second radius actually limitless, but limit it with the amount of chunks that can be loaded at the same time. This way you could see high celling that are out of your normal render distance, or a tall tower on the horizon. Or you can see the surface of the mountain without needing to load the insides of it and all the chunks that consist of air only above. It will push the visible distance much farther than if you'll just load all chunks in one direction.

Quote from Brettd3000»

Oh yes, I forgot about explosions.

Loading visible chunks in that way is a good idea, but since raytracing relies on collisions, could be somewhat problematic. Of course, you could have a "solid" or "empty" tag for chunks, as has been suggested before, and ignore/include chunks based on that, but in the case of a mountain side, you will have a lot of chunks which are partially filled, and that would probably require getting collisions with individual blocks inside the chunks.

I haven't really thought about this to much, so I'm probably missing something.

Guess if the chunk have even one block that is not air in it (don't fall under empty category) you should trace the corners of it (which must be also reused for adjacent chunks) and load the whole chunk if even one of those reaches the point of view. I haven't done the actual math, but something tells me you'll get one ray for one chunk or something about that, so it should be pretty efficient.

I've noticed in the first post, there's this comment on the isEmpty flag:

When the bit is 1, all data for the chunk besides the isEmpty flag is deleted and ignored, which reduces filesize.

To me, this sounds like it could be a possible security hole. A malicious client could send back a malformed chunk update that sets any generated chunk to "Empty" and as such erases anything inside it.

This is probably a moot point, as the server itself should be able to examine it's own copy and see something's wrong, but it might be something to consider.

Quote from PanJouda»

The client doesn't upload the chunk to the server. The cient dowloads the map and sends to the server the position of block he wants to edit. The clients have much limited possibilities, they can't modify the world as they wish. They can only send requests to the server, that modifies the world itself. It's the same with that the clients can't use MCedit when playing or they can't change the biome or whatever.

Oh, ok. I had a bit of a misunderstanding how client-server communications work. I'm not a programmer (although I aspire to be :P).

Any word on 1.9? I hope Mojang implements something like this.