Everyone knows Minecraft is not for the slow computers, but there is one very big mistake made when developing the game that deepen that issue -- BSP is always rendered every tick on every block in the view frustus.
1. BSP per height
Not just BSP would act only in the blocks that are in the same render distance from the player, but would also act only at blocks roughly 24 blocks above and below the player for better performance. Of course this could be adjusted in the View Settings.
2. Preloaded BSP
As does most First-Person Shooter games (including Doom and Unreal Tournament), every loaded chunk would generate a small BSP tree of sub-chunks and segs. The sub-chunks in the tree would be split into blocks when inside the player's view frustus, which means more FPS, instead of just splitting into blocks already.
Every save would contain another file that contains the BSP sub-chunks and segs.
Sub-chunks are like cubic chunks, but serve for no other purpose than BSP and have 4x4x4 dimensions (the sub-chunk and chunk dimensions can be adjusted at the Advanced Settings).
3. Spherical Render Distance
The render distance would also act vertically.
If you read well, you can note some sub-suggestions, like chunk dimension adjustment.
Everyone knows Minecraft is not for the slow computers, but there is one very big mistake made when developing the game that deepen that issue -- BSP is always rendered every tick on every block in the view frustus.
There are actually a lot of low-end computers that can run the game fine on around medium-high settings.
As a game programmer I'm a bit embarrassed to say there's a couple parts of this suggestion I'm not getting. I don't understand the benefit of spherical rendering. When you talk about Doom and the classic Unreal Tournament, you're talking about how each "room" is a sector right? And that sector becomes unloaded or just partially loaded when you can't see that sector anymore?
Rollback Post to RevisionRollBack
Yeah, that guy in the avatar is me. I'm *that* strange. It happens. Sometimes people act like that. Just go with it. I can offer help with suggestions even before you post them - NOT make your suggestions - but help you with them.
There are actually a lot of low-end computers that can run the game fine on around medium-high settings.
As a game programmer I'm a bit embarrassed to say there's a couple parts of this suggestion I'm not getting. I don't understand the benefit of spherical rendering. When you talk about Doom and the classic Unreal Tournament, you're talking about how each "room" is a sector right? And that sector becomes unloaded or just partially loaded when you can't see that sector anymore?
Spherical rendering allows you to just render stuff in a spherical radius so you don't e.g. need to apply BSP in stone blocks like 100 blocks below you. The height gets tidier when above sea level as you don't need to worry about stuff under or below you -- exception is Extreme Hills.
In Unreal Tournament each "room" is not a sector but a subtractive brush. I already mapped for Doom and Unreal Tournament so I know each bit of it.
As for the sub-chunks, they are just partially loaded when you can't see it anymore.
Rollback Post to RevisionRollBack
As can see, made an Xbox account via an Win8 Games app.
In Unreal Tournament each "room" is not a sector but a subtractive brush. I already mapped for Doom and Unreal Tournament so I know each bit of it.
So have I. With Doom, rooms and some brushes are treated as sectors. Unreal Tournament is all brushes, though you need to use zoning and anti-portals to optimize for performance (at least in the 2003/2004 versions, never mapped for UT99). Yeah, something thing tells me that we're gonna confuse most people reading our posts.
As for the sub-chunks, they are just partially loaded when you can't see it anymore.
The game already has that. Chunks outside of the render range are unloaded, while chunks with redstone circuits are just "partially loaded".
Rollback Post to RevisionRollBack
Yeah, that guy in the avatar is me. I'm *that* strange. It happens. Sometimes people act like that. Just go with it. I can offer help with suggestions even before you post them - NOT make your suggestions - but help you with them.
Everyone knows Minecraft is not for the slow computers, but there is one very big mistake made when developing the game that deepen that issue -- BSP is always rendered every tick on every block in the view frustus. As already said, Minecraft is actually fairly easy to run due to how simple its graphics are. It's not like its using complex rendering techniques like SSAO, MSAA / FXAA, bloom, HDR, physically-based rendering, gods rays / volumetric lighting, physically accurate dynamic lighting (with GI), etc. It's just a simple game with voxels that has low-res textures, and such most low-end computers can run it fine. Though Minecraft isn't perfect, for its simplicity it should be running much better on modern hardware, and hence is where the true problems arise: poorly optimised rendering and logic code, nearing decade old fixed-function OpenGL function calls, and generally misuse of the CPU for graphics (using the CPU to compute lighting where the GPU would do a better job, though this is debatable).
1. BSP per height
Not just BSP would act only in the blocks that are in the same render distance from the player, but would also act only at blocks roughly 24 blocks above and below the player for better performance. Of course this could be adjusted in the View Settings. This is actually redundant because the game includes occlusion and frustum culling (I know for a fact 1.8 employs frustum culling, pretty sure 1.8 also includes occlusion culling, I know 1.7 and previous included it under the Advanced OpenGL setting), which basically culls out any blocks that the player cannot see, whether it be because they're not within the view frustum or they're occluded by other blocks (I'm pretty sure the game just checks if any of the sides are exposed to air for this).
2. Preloaded BSP
As does most First-Person Shooter games (including Doom and Unreal Tournament), every loaded chunk would generate a small BSP tree of sub-chunks and segs. The sub-chunks in the tree would be split into blocks when inside the player's view frustus, which means more FPS, instead of just splitting into blocks already.
Every save would contain another file that contains the BSP sub-chunks and segs.
Sub-chunks are like cubic chunks, but serve for no other purpose than BSP and have 4x4x4 dimensions (the sub-chunk and chunk dimensions can be adjusted at the Advanced Settings). Technically already done with chunks, though quite not to how Doom and UT does it as Doom's and UT's geometry is static and isn't bound to a grid of integers, Minecraft's is dynamic and is bound to a grid of integers, hence the chunk system is designed to support the fluidity of Minecraft and how it's such a dynamic game.
3. Spherical Render Distance
The render distance would also act vertically. As I said in point 1, this is redundant as the game already uses occlusion and frustum culling.
If you read well, you can note some sub-suggestions, like chunk dimension adjustment.
First and foremost, what exactly do you mean by BSP? Coming from Unreal Engine 4, I first thought you meant BSPs as in the level designing geometry that UE4 offers, where you can apply materials to them and resize them freely without running into scaling issues. Obviously this is not the case, so what do you mean by BSP? I'm going to assume you mean the geometry of the game.
Anyways, responses in bold.
No support. There's no need for any of this, points 1 and 3 are just redundant because the game offers occlusion and frustum culling, and point 2 is basically a fancy version of what chunks already offer.
Rollback Post to RevisionRollBack
Author of the Clarity, Serenity, Sapphire & Halcyon shader packs for Minecraft: Java Edition.
First and foremost, what exactly do you mean by BSP? Coming from Unreal Engine 4, I first thought you meant BSPs as in the level designing geometry that UE4 offers, where you can apply materials to them and resize them freely without running into scaling issues. Obviously this is not the case, so what do you mean by BSP? I'm going to assume you mean the geometry of the game.
Anyways, responses in bold.
No support. There's no need for any of this, points 1 and 3 are just redundant because the game offers occlusion and frustum culling, and point 2 is basically a fancy version of what chunks already offer.
Happens BSP is the method of determining whether or not is an object rendered, and how it's rendered if yes. Minecraft applies it to all blocks in the view frustus excluding culling.
Also subchunk partitions aren't even stored, all they do is hold data. If a subchunk is fully filled with solid blocks it's not even loaded.
Rollback Post to RevisionRollBack
As can see, made an Xbox account via an Win8 Games app.
Happens BSP is the method of determining whether or not is an object rendered, and how it's rendered if yes. Minecraft applies it to all blocks in the view frustus excluding culling.
Also subchunk partitions aren't even stored, all they do is hold data. If a subchunk is fully filled with solid blocks it's not even loaded.
Never heard of BSP being used for that.
And what's the point of sub-chunk partitions if chunks along with frustum and occlusion culling perform the same thing but better? Sounds like needless complexity.
Rollback Post to RevisionRollBack
Author of the Clarity, Serenity, Sapphire & Halcyon shader packs for Minecraft: Java Edition.
Well every 3D game is based on BSP for its rendering to work.
Sub-chunks are for the sake of BSP tree preloading (which is only used upon chunk generation and dies the first block change in the parent chunk) and for checking if something is completely filled with solid blocks and don't need to be loaded.
Rollback Post to RevisionRollBack
As can see, made an Xbox account via an Win8 Games app.
Well every 3D game is based on BSP for its rendering to work.
Sub-chunks are for the sake of BSP tree preloading (which is only used upon chunk generation and dies the first block change in the parent chunk) and for checking if something is completely filled with solid blocks and don't need to be loaded.
Again, what's the point of this though? What tangible benefits will this bring that we don't already have? Chunks are already selectively loaded, unloaded and rendered based on where the player is in the world (IIRC a 9x9 chunk radius around the player is always kept loaded), which chunks are currently active and their respective activity levels (redstone partially loads a chunk, a tile entity can partially load a chunk, mods that add chunk loaders keep a chunk fully loaded in memory), and each chunk is only rendered up until the player's render distance (or the server's render distance).
Along with that, culling techniques such as frustum and occlusion culling keep per-block rendering under control. If a block isn't exposed to air on any of its 6 sides, it isn't rendered because the player can't see it, thus it's pointless and a waste of resources to render that block. Of course that block is still ticked, which doesn't cause much lag unless it's a tile entity and has some complex code behind it (and stopping it from ticking would do much more harm than good, imagine not having your power generation system and item routing system not work because there is a wall between you and all the blocks). I don't see a tangible benefit to what you propose, which is effectively cubic chunks, purely for rendering (which is the sole thing you've talked about). It's just adding needless complexity where it isn't needed.
The game already culls out blocks you can't see, so culling out volumes of solid blocks using this "BSP tree" method is pointless because the problem has already been solved by a much simpler method. And there's no point in having all this only affect a chunk upon loading as the culling methods are constantly being applied whenever the world is rendered, so that's pointless too. I don't see any benefits to your suggestion.
Rollback Post to RevisionRollBack
Author of the Clarity, Serenity, Sapphire & Halcyon shader packs for Minecraft: Java Edition.
Everyone knows Minecraft is not for the slow computers, but there is one very big mistake made when developing the game that deepen that issue -- BSP is always rendered every tick on every block in the view frustus.
1. BSP per height
Not just BSP would act only in the blocks that are in the same render distance from the player, but would also act only at blocks roughly 24 blocks above and below the player for better performance. Of course this could be adjusted in the View Settings.
2. Preloaded BSP
As does most First-Person Shooter games (including Doom and Unreal Tournament), every loaded chunk would generate a small BSP tree of sub-chunks and segs. The sub-chunks in the tree would be split into blocks when inside the player's view frustus, which means more FPS, instead of just splitting into blocks already.
Every save would contain another file that contains the BSP sub-chunks and segs.
Sub-chunks are like cubic chunks, but serve for no other purpose than BSP and have 4x4x4 dimensions (the sub-chunk and chunk dimensions can be adjusted at the Advanced Settings).
3. Spherical Render Distance
The render distance would also act vertically.
If you read well, you can note some sub-suggestions, like chunk dimension adjustment.
There are actually a lot of low-end computers that can run the game fine on around medium-high settings.
As a game programmer I'm a bit embarrassed to say there's a couple parts of this suggestion I'm not getting. I don't understand the benefit of spherical rendering. When you talk about Doom and the classic Unreal Tournament, you're talking about how each "room" is a sector right? And that sector becomes unloaded or just partially loaded when you can't see that sector anymore?
Yeah, that guy in the avatar is me. I'm *that* strange. It happens. Sometimes people act like that. Just go with it. I can offer help with suggestions even before you post them - NOT make your suggestions - but help you with them.
Unofficial Suggestions Guide (2.0) - by Theriasis
Unofficial Critics Guide - by yoshi9048
Spherical rendering allows you to just render stuff in a spherical radius so you don't e.g. need to apply BSP in stone blocks like 100 blocks below you. The height gets tidier when above sea level as you don't need to worry about stuff under or below you -- exception is Extreme Hills.
In Unreal Tournament each "room" is not a sector but a subtractive brush. I already mapped for Doom and Unreal Tournament so I know each bit of it.
As for the sub-chunks, they are just partially loaded when you can't see it anymore.
So have I. With Doom, rooms and some brushes are treated as sectors. Unreal Tournament is all brushes, though you need to use zoning and anti-portals to optimize for performance (at least in the 2003/2004 versions, never mapped for UT99). Yeah, something thing tells me that we're gonna confuse most people reading our posts.
The game already has that. Chunks outside of the render range are unloaded, while chunks with redstone circuits are just "partially loaded".
Yeah, that guy in the avatar is me. I'm *that* strange. It happens. Sometimes people act like that. Just go with it. I can offer help with suggestions even before you post them - NOT make your suggestions - but help you with them.
Unofficial Suggestions Guide (2.0) - by Theriasis
Unofficial Critics Guide - by yoshi9048
First and foremost, what exactly do you mean by BSP? Coming from Unreal Engine 4, I first thought you meant BSPs as in the level designing geometry that UE4 offers, where you can apply materials to them and resize them freely without running into scaling issues. Obviously this is not the case, so what do you mean by BSP? I'm going to assume you mean the geometry of the game.
Anyways, responses in bold.
No support. There's no need for any of this, points 1 and 3 are just redundant because the game offers occlusion and frustum culling, and point 2 is basically a fancy version of what chunks already offer.
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!
Happens BSP is the method of determining whether or not is an object rendered, and how it's rendered if yes. Minecraft applies it to all blocks in the view frustus excluding culling.
Also subchunk partitions aren't even stored, all they do is hold data. If a subchunk is fully filled with solid blocks it's not even loaded.
Never heard of BSP being used for that.
And what's the point of sub-chunk partitions if chunks along with frustum and occlusion culling perform the same thing but better? Sounds like needless complexity.
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 every 3D game is based on BSP for its rendering to work.
Sub-chunks are for the sake of BSP tree preloading (which is only used upon chunk generation and dies the first block change in the parent chunk) and for checking if something is completely filled with solid blocks and don't need to be loaded.
Again, what's the point of this though? What tangible benefits will this bring that we don't already have? Chunks are already selectively loaded, unloaded and rendered based on where the player is in the world (IIRC a 9x9 chunk radius around the player is always kept loaded), which chunks are currently active and their respective activity levels (redstone partially loads a chunk, a tile entity can partially load a chunk, mods that add chunk loaders keep a chunk fully loaded in memory), and each chunk is only rendered up until the player's render distance (or the server's render distance).
Along with that, culling techniques such as frustum and occlusion culling keep per-block rendering under control. If a block isn't exposed to air on any of its 6 sides, it isn't rendered because the player can't see it, thus it's pointless and a waste of resources to render that block. Of course that block is still ticked, which doesn't cause much lag unless it's a tile entity and has some complex code behind it (and stopping it from ticking would do much more harm than good, imagine not having your power generation system and item routing system not work because there is a wall between you and all the blocks). I don't see a tangible benefit to what you propose, which is effectively cubic chunks, purely for rendering (which is the sole thing you've talked about). It's just adding needless complexity where it isn't needed.
The game already culls out blocks you can't see, so culling out volumes of solid blocks using this "BSP tree" method is pointless because the problem has already been solved by a much simpler method. And there's no point in having all this only affect a chunk upon loading as the culling methods are constantly being applied whenever the world is rendered, so that's pointless too. I don't see any benefits to your suggestion.
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!