I think it's best dropping this whole 'Minecraft 2!!!' thing. I mean the entirety of the idea isn't even finished so it's hard to support this. Making a sequel to bring back players doesn't always work the way people like to assume it does. I mean look at Mass Effect: Andromeda. I know that's a harsh comparison, but more doesn't always equal better.
Rollback Post to RevisionRollBack
The Unofficial Suggestion Guide - Everything you need to know to not make goofy mistakes in a suggestion! Honestly though, you should really go there.
I think it's best dropping this whole 'Minecraft 2!!!' thing. I mean the entirety of the idea isn't even finished so it's hard to support this. Making a sequel to bring back players doesn't always work the way people like to assume it does. I mean look at Mass Effect: Andromeda. I know that's a harsh comparison, but more doesn't always equal better.
he's already stated that he plans to create something completely different than what we currently have, overhauling every single aspect of the game, and that the reason it's being split up into multiple threads is because it's going to be one of, if not the biggest suggestion the forum's seen to date, kind of like how Girbilcrab475's aether/new nether suggestion took up 10 posts just to complete, partially for organization, but mostly because 1 forum post would be over loaded, if it can even go up to that big
Rollback Post to RevisionRollBack
Anyone know how to change my user name?
"And just when you thought you where the sexiest one here, i show up" -Fernando
I would actually be interested in seeing Bloom make it into the game, it makes light sources look a lot better.
Rollback Post to RevisionRollBack
My avatar is a texture from a small block game I made in Python. It's not very good and it probably won't work if you install it.
I'm very alone in my Minecraft worlds as I don't have a very good internet connection to run a server. If you're like me, you might be interested in my Posse mod suggestion.
How I didn't see this thread, I don't know, but I've gotta chime in...
Sunlight will also be affected by this, and would only cast shadows from blocks that are currently rendered (this would mean floating islands or high ceilings that are above render distance will not cast a shadow, but I believe it's a small price to pay).
This actually might not be too big of an issue. When rendering the shadow map, what you can do is project the current pixel into the camera frustum, and see if it intersects the camera frustum. In simpler terms, you can check if the shadow of a given pixel in the shadow map would end up on screen, if it doesn't, discard the pixel.
Light passing through translucent colored blocks would be tinted depending on the base color of the block (light passing through red stained glass will always be pure red, even if you've retextured it to be purple or several colors).
This could be an issue with shadow maps, because of the fact that you'd have to store albedo, which takes up 32 bits per pixel in the shadow map, and it'd only work for the first block the shadow map intersects. Shaders currently do the exact same thing for the sun/moon, but the thing is, that's only 1 shadow map. For potentially hundreds (which I'll get to soon), this all adds up and can kill performance.
The good thing is, though, that coloured shadows would automatically work with resource packs, since it's just the albedo / base texture of the block being rendered out to the shadow map.
Dynamic lights will also be a thing. They aren't really laggy when implemented correctly, though with the addition of shadows, they will have more of an effect on performance than the current dynamic lights mod, but not by much.
Aren't really laggy, within Minecraft's lighting engine. Dynamic lights, with shadows, will murder performance if a lot of them end up on-screen. If you have the time, try to download either Unity or Unreal Engine 4 and dump about 20 or so dynamic point lights in the scene, preferably overlapping, and see how much FPS you get. Then add another 20. Then another 20.
Rendering shadow maps is a very costly procedure, because it requires rerendering the world over again from the perspective of the light source. Not only do you have to store the albedo for coloured shadows from transparent objects, but you also have to store a 32-bit floating point value for the depth, for each pixel. For a single 1024x1024 shadow map (which, for reference, our shaders use around 2048x2048 for standard, 4096x4096 for high), that's roughly 4MB, just for the depth. Plus the overhead of buffers, if they have any memory overhead. Now that'll either give you the depth including or excluding transparent blocks. So no coloured shadows with a single 4MB, 1024x1024 shadow map, even if we added albedo. Now we need to add a second depth buffer for the shadow map, so that doubles it for 8MB. Then add in the 32 bits for RGBA albedo, that's 12MB. Hell, why not throw in an auxiliary output, maybe it can store the normal or something for global illumination. Another 32 bits, 16MB. A single 1024x1024 shadow map, excluding buffer overhead. Let's say you had 20 torches nearby that have to have their own shadow maps rendered out, that's 320MB in just shadow maps. Maybe someone wants to bump that up to 2048x2048, that's 67MB for a single shadow map. 20 shadow maps?
1.34GB. My 6GB 1060 only has 6 gigabytes of memory to work with, most older cards only had 2-4GB, and a lot of integrated GPUs have at max 1GB of memory available to them. That's just for shadow maps, you also need to factor in the main framebuffers, all the textures, all the geometry data, uniform data, arbitrary buffer data, and such. So yeah, in memory usage alone, this has already exceeded what integrated GPUs tend to have. And I don't want to get into the actual computation overhead of rendering so many shadow maps, but to sum it up, a single shadow map through Optifine halves FPS. I don't think it's terribly optimised, but yeah. Shadow mapping is very expensive.
There is stuff you can do, though. All those hypotheticals give lights their own little shadow map, however realistically, you don't need to. What you could do is divide the shadow map into quadrants, so a single 2048x2048 shadow map can contain 4 1024x1024 mini shadow maps. Divide one of those up again, and you have 3 1024x1024 shadow maps, and 4 512x512 shadow maps. Divide one of those 512x512 shadow maps up... and you can keep going until it gets to the 1x1 size, if you wish. What you could do here is divide the lights up by "level of detail". Maybe you really only need lights near the player, and that the player can see, to be full res. Well, you could put up to 3 of these lights into the 3 1024x1024 quadrants, then divvy up the rest into the smaller quadrants based on the "level of detail". A lot of modern games actually use a technique similar to this. They'll have a single, say, 2048x2048 shadow map divided into 4 1024x1024 shadow maps. Then they'll render a given light to these out, progressively zooming farther and farther out, like this. You can see that it progressively zooms out farther and farther. The premise of this is the more physical space a given object takes up in the shadow map, the more pixels are available to represent its shape, and more detailed the final shadow becomes. We use something similar in our shaders, actually. What we do is use some math to blow the shadow map up like a balloon, scaling up objects near the player so they take up more space in the shadow map, which vastly improves the quality and detail near the player, at the cost of quality and detail away from the player.
This applies some feathering around the edges of objects to reduce the jaggedness of diagonal lines. It can be set to off, FXAA (cheap, "fake" anti-aliasing), 2x, 4x, 8x, and 16x.
Assuming you mean MSAA by "2x, 4x, 8x, and 16x", depending on which renderer the game is using, this won't be possible. If the game will be using a deferred renderer, which realistically, it'd need to be to have cheap per-pixel lighting, MSAA is insanely hard to do without hurting FPS, just due to the way things work. You'd have FXAA, TAA, SMAA and other assorted post-process AA techniques.
Rollback Post to RevisionRollBack
Author of the Clarity, Serenity, Sapphire & Halcyon shader packs for Minecraft: Java Edition.
This could be an issue with shadow maps, because of the fact that you'd have to store albedo, which takes up 32 bits per pixel in the shadow map, and it'd only work for the first block the shadow map intersects. Shaders currently do the exact same thing for the sun/moon, but the thing is, that's only 1 shadow map. For potentially hundreds (which I'll get to soon), this all adds up and can kill performance.
Well, it's not like these blocks exist naturally. Blocks that change a light's color would only be crafted, so it wouldn't have too much of an effect on normal gameplay.
Aren't really laggy, within Minecraft's lighting engine. Dynamic lights, with shadows, will murder performance if a lot of them end up on-screen. If you have the time, try to download either Unity or Unreal Engine 4 and dump about 20 or so dynamic point lights in the scene, preferably overlapping, and see how much FPS you get. Then add another 20. Then another 20.
Yeah, I'm well aware of how easily non-baked lighting can hurt performance (I'm an amateur game developer learning Unity), though my system is old and obsolete so I anticipate any contemporary system could handle many more lights at a time. While I plan that there could be dynamic lights, they aren't common and are rarely natural.
Rendering shadow maps is a very costly procedure, because it requires rerendering the world over again from the perspective of the light source. Not only do you have to store the albedo for coloured shadows from transparent objects, but you also have to store a 32-bit floating point value for the depth, for each pixel. For a single 1024x1024 shadow map (which, for reference, our shaders use around 2048x2048 for standard, 4096x4096 for high), that's roughly 4MB, just for the depth. Plus the overhead of buffers, if they have any memory overhead. Now that'll either give you the depth including or excluding transparent blocks. So no coloured shadows with a single 4MB, 1024x1024 shadow map, even if we added albedo. Now we need to add a second depth buffer for the shadow map, so that doubles it for 8MB. Then add in the 32 bits for RGBA albedo, that's 12MB. Hell, why not throw in an auxiliary output, maybe it can store the normal or something for global illumination. Another 32 bits, 16MB. A single 1024x1024 shadow map, excluding buffer overhead. Let's say you had 20 torches nearby that have to have their own shadow maps rendered out, that's 320MB in just shadow maps. Maybe someone wants to bump that up to 2048x2048, that's 67MB for a single shadow map. 20 shadow maps?
1.34GB. My 6GB 1060 only has 6 gigabytes of memory to work with, most older cards only had 2-4GB, and a lot of integrated GPUs have at max 1GB of memory available to them. That's just for shadow maps, you also need to factor in the main framebuffers, all the textures, all the geometry data, uniform data, arbitrary buffer data, and such. So yeah, in memory usage alone, this has already exceeded what integrated GPUs tend to have. And I don't want to get into the actual computation overhead of rendering so many shadow maps, but to sum it up, a single shadow map through Optifine halves FPS. I don't think it's terribly optimised, but yeah. Shadow mapping is very expensive.
There is stuff you can do, though. All those hypotheticals give lights their own little shadow map, however realistically, you don't need to. What you could do is divide the shadow map into quadrants, so a single 2048x2048 shadow map can contain 4 1024x1024 mini shadow maps. Divide one of those up again, and you have 3 1024x1024 shadow maps, and 4 512x512 shadow maps. Divide one of those 512x512 shadow maps up... and you can keep going until it gets to the 1x1 size, if you wish. What you could do here is divide the lights up by "level of detail". Maybe you really only need lights near the player, and that the player can see, to be full res. Well, you could put up to 3 of these lights into the 3 1024x1024 quadrants, then divvy up the rest into the smaller quadrants based on the "level of detail". A lot of modern games actually use a technique similar to this. They'll have a single, say, 2048x2048 shadow map divided into 4 1024x1024 shadow maps. Then they'll render a given light to these out, progressively zooming farther and farther out, like this. You can see that it progressively zooms out farther and farther. The premise of this is the more physical space a given object takes up in the shadow map, the more pixels are available to represent its shape, and more detailed the final shadow becomes. We use something similar in our shaders, actually. What we do is use some math to blow the shadow map up like a balloon, scaling up objects near the player so they take up more space in the shadow map, which vastly improves the quality and detail near the player, at the cost of quality and detail away from the player.
Well, I'm sure it's possible, though conventional lighting techniques might have to be avoided to work with the custom voxel engine. If we use "lighting LOD," make shadows low-res by default and only render lights near the player, I don't see it being too big of an issue. A lot of older players will be left unable to play, but I imagine it would be playable on modern consoles and computers made in at least the last several years.
Assuming you mean MSAA by "2x, 4x, 8x, and 16x", depending on which renderer the game is using, this won't be possible. If the game will be using a deferred renderer, which realistically, it'd need to be to have cheap per-pixel lighting, MSAA is insanely hard to do without hurting FPS, just due to the way things work. You'd have FXAA, TAA, SMAA and other assorted post-process AA techniques.
I don't know how anti-aliasing works, so I'll just say you're right. Though, of course anti-aliasing would hurt FPS, as it's a quality setting.
I think it's best dropping this whole 'Minecraft 2!!!' thing. I mean the entirety of the idea isn't even finished so it's hard to support this. Making a sequel to bring back players doesn't always work the way people like to assume it does. I mean look at Mass Effect: Andromeda. I know that's a harsh comparison, but more doesn't always equal better.
The Unofficial Suggestion Guide - Everything you need to know to not make goofy mistakes in a suggestion! Honestly though, you should really go there.
he's already stated that he plans to create something completely different than what we currently have, overhauling every single aspect of the game, and that the reason it's being split up into multiple threads is because it's going to be one of, if not the biggest suggestion the forum's seen to date, kind of like how Girbilcrab475's aether/new nether suggestion took up 10 posts just to complete, partially for organization, but mostly because 1 forum post would be over loaded, if it can even go up to that big
Anyone know how to change my user name?
"And just when you thought you where the sexiest one here, i show up" -Fernando
check out my suggestion for Yggdrasil, the great world tree
FOR THE HOLY LOVE OF ARCEUS AND HELIX COMBINED PALADINS IS NOT AN OVERWATCH CLONE. tf2's the true king anyways
-Let's make some noise
I would actually be interested in seeing Bloom make it into the game, it makes light sources look a lot better.
My avatar is a texture from a small block game I made in Python. It's not very good and it probably won't work if you install it.
I'm very alone in my Minecraft worlds as I don't have a very good internet connection to run a server. If you're like me, you might be interested in my Posse mod suggestion.
How I didn't see this thread, I don't know, but I've gotta chime in...
This actually might not be too big of an issue. When rendering the shadow map, what you can do is project the current pixel into the camera frustum, and see if it intersects the camera frustum. In simpler terms, you can check if the shadow of a given pixel in the shadow map would end up on screen, if it doesn't, discard the pixel.
This could be an issue with shadow maps, because of the fact that you'd have to store albedo, which takes up 32 bits per pixel in the shadow map, and it'd only work for the first block the shadow map intersects. Shaders currently do the exact same thing for the sun/moon, but the thing is, that's only 1 shadow map. For potentially hundreds (which I'll get to soon), this all adds up and can kill performance.
The good thing is, though, that coloured shadows would automatically work with resource packs, since it's just the albedo / base texture of the block being rendered out to the shadow map.
Aren't really laggy, within Minecraft's lighting engine. Dynamic lights, with shadows, will murder performance if a lot of them end up on-screen. If you have the time, try to download either Unity or Unreal Engine 4 and dump about 20 or so dynamic point lights in the scene, preferably overlapping, and see how much FPS you get. Then add another 20. Then another 20.
Rendering shadow maps is a very costly procedure, because it requires rerendering the world over again from the perspective of the light source. Not only do you have to store the albedo for coloured shadows from transparent objects, but you also have to store a 32-bit floating point value for the depth, for each pixel. For a single 1024x1024 shadow map (which, for reference, our shaders use around 2048x2048 for standard, 4096x4096 for high), that's roughly 4MB, just for the depth. Plus the overhead of buffers, if they have any memory overhead. Now that'll either give you the depth including or excluding transparent blocks. So no coloured shadows with a single 4MB, 1024x1024 shadow map, even if we added albedo. Now we need to add a second depth buffer for the shadow map, so that doubles it for 8MB. Then add in the 32 bits for RGBA albedo, that's 12MB. Hell, why not throw in an auxiliary output, maybe it can store the normal or something for global illumination. Another 32 bits, 16MB. A single 1024x1024 shadow map, excluding buffer overhead. Let's say you had 20 torches nearby that have to have their own shadow maps rendered out, that's 320MB in just shadow maps. Maybe someone wants to bump that up to 2048x2048, that's 67MB for a single shadow map. 20 shadow maps?
1.34GB. My 6GB 1060 only has 6 gigabytes of memory to work with, most older cards only had 2-4GB, and a lot of integrated GPUs have at max 1GB of memory available to them. That's just for shadow maps, you also need to factor in the main framebuffers, all the textures, all the geometry data, uniform data, arbitrary buffer data, and such. So yeah, in memory usage alone, this has already exceeded what integrated GPUs tend to have. And I don't want to get into the actual computation overhead of rendering so many shadow maps, but to sum it up, a single shadow map through Optifine halves FPS. I don't think it's terribly optimised, but yeah. Shadow mapping is very expensive.
There is stuff you can do, though. All those hypotheticals give lights their own little shadow map, however realistically, you don't need to. What you could do is divide the shadow map into quadrants, so a single 2048x2048 shadow map can contain 4 1024x1024 mini shadow maps. Divide one of those up again, and you have 3 1024x1024 shadow maps, and 4 512x512 shadow maps. Divide one of those 512x512 shadow maps up... and you can keep going until it gets to the 1x1 size, if you wish. What you could do here is divide the lights up by "level of detail". Maybe you really only need lights near the player, and that the player can see, to be full res. Well, you could put up to 3 of these lights into the 3 1024x1024 quadrants, then divvy up the rest into the smaller quadrants based on the "level of detail". A lot of modern games actually use a technique similar to this. They'll have a single, say, 2048x2048 shadow map divided into 4 1024x1024 shadow maps. Then they'll render a given light to these out, progressively zooming farther and farther out, like this. You can see that it progressively zooms out farther and farther. The premise of this is the more physical space a given object takes up in the shadow map, the more pixels are available to represent its shape, and more detailed the final shadow becomes. We use something similar in our shaders, actually. What we do is use some math to blow the shadow map up like a balloon, scaling up objects near the player so they take up more space in the shadow map, which vastly improves the quality and detail near the player, at the cost of quality and detail away from the player.
Assuming you mean MSAA by "2x, 4x, 8x, and 16x", depending on which renderer the game is using, this won't be possible. If the game will be using a deferred renderer, which realistically, it'd need to be to have cheap per-pixel lighting, MSAA is insanely hard to do without hurting FPS, just due to the way things work. You'd have FXAA, TAA, SMAA and other assorted post-process AA techniques.
Author of the Clarity, Serenity, Sapphire & Halcyon shader packs for Minecraft: Java Edition.
My Github page.
The entire Minecraft shader development community now has its own Discord server! Feel free to join and chat with all the developers!
Well, it's not like these blocks exist naturally. Blocks that change a light's color would only be crafted, so it wouldn't have too much of an effect on normal gameplay.
Yeah, I'm well aware of how easily non-baked lighting can hurt performance (I'm an amateur game developer learning Unity), though my system is old and obsolete so I anticipate any contemporary system could handle many more lights at a time. While I plan that there could be dynamic lights, they aren't common and are rarely natural.
Well, I'm sure it's possible, though conventional lighting techniques might have to be avoided to work with the custom voxel engine. If we use "lighting LOD," make shadows low-res by default and only render lights near the player, I don't see it being too big of an issue. A lot of older players will be left unable to play, but I imagine it would be playable on modern consoles and computers made in at least the last several years.
I don't know how anti-aliasing works, so I'll just say you're right. Though, of course anti-aliasing would hurt FPS, as it's a quality setting.
Want to see my suggestions? Here they are!
I am also known as GameWyrm or GameWyrm97. You can also find me at snapshotmc.com