I thought of another idea for increasing the draw distance. It works similar to how I believe the Eihort world viewer works, but takes the idea further. At the very least it ought to work for normal convex surfaces (which is usually the case, ignoring trees for the moment).
The main reason there is a GL quad for every exposed block surface is that you can't easily make assumptions about the terrain texture. To keep things generalized, each block face gets its own polygon with its own uv mapping. One of the reasons the performance is so bad is that these polygons cannot be trivially reduced, and even though GPUs are good at handling lots of polygons, Minecraft pushes cards to their limit.
I believe that among its optimizations, Eihort constructs surface meshes wherever there are connected blocks of the same type, doing so with this library. The meshing algorithm tries to find the minimum number of triangles needed to express the shape. Since the texture is continuous across the mesh, there is no problem is the internal triangles don't make squares. For continuous regions like grass, sand, and water the benefit is dramatic.
But what if we didn't have to stop wherever terrain switches over? What if, instead, the GPU could figure out what texture belongs in each cube space? The polygon savings would be unimaginable. With GLSL, this is doable. All you have to send to the GPU is the surface geometry, and have the block data already stored on the GPU. The shader thread could then easily figure out the correct texture position and light blending. For instance, you would have the blockID (or more accurately the sprite ID), and the two light levels, in some compressed format and stored in texture memory for quick access. You could split the geometry into regions like 16^3 chunks (or maybe even larger) for easy segmentation, and then again for each of the 6 faces. This would allow you to keep only visible geometry in GPU memory.
Take it a step further, and load every flat surface region as its own mesh. Since they would be flat, have square elements, and have relatively few permutations, it would be easy to do a lot of optimizations to generate the meshes.
Another thought I had was what if you deliberately connect multiple faces in the same plane, even if they are partially obstructed? That would lower the polygon count even further. This is more risky, as you would be using the depth buffer to keep track of which surface goes where. If handled improperly you could end up trying to draw to the screen multiple times.
There are some limitations to this strategy. The most obvious is that it uses GLSL, which will prevent some people from using it. Another is that it would be unable to cope with non-cube blocks stairs, doors, and and even tracks. Those would have to be drawn normally. Also I'm not sure if it could handle the smooth lighting or not.
In any case, this method of drawing terrain would be ideal for near to mid-range rendering. When a single block is still large enough to cover many pixels, polygons are still the way to go, leveraging Minecraft's blocky nature to our advantage. This could be used by itself or in tandem with the voxel engine I mentioned a few pages back, to take over the higher resolution cases with more efficient computation.
Niiiiice. :smile.gif:
Rollback Post to RevisionRollBack
- The Cubic Chunks Mod is back! Be a part of it's rebirth and Development.
-- Robinton's Mods: [ Mirror ] for some of his Mods incl Cubic Chunks Mod, due to DropBox broken links.
From what I've read, constructing the SVOs needed for fast GPU raycasting is a rather expensive step. Slicing up an octree pyramid depending on distance is a promising idea though, and I'd like to try sometime to implement it in a more classic polygon-based fashion. However, if you manage to get it working as a true voxel renderer, the results will be absolutely stunning!
The dynamically loaded octtree implementation was done in CUDA. I'm not certain OpenGL+GLSL is able to provide enough control to manage the resources properly. OpenCL may provide that ability if the former cannot, but right now I'm just doing well to follow the GLSL discussion, so I couldn't say for sure how to pull it off.
I have seen an implementation that uses a geometry shader to tesselate the voxel data on the GPU, so this idea would definitely work. (I just can't find the link right now.) I have also written a blog post about face merging and using GLSL to do the uv mapping, you might find it interesting.
I've actually been using your work as reference material. :smile.gif:
I'm still not completely sold on the server-side occlusion culling, but I have to admit it seems to work pretty well in your latest video.
-------------
New thought. Once more ignoring trees and non-cube blocks, if you perform binary space partitioning on the region to remove all concavities, you can store block information really efficiently. For each convex region, you have from 0 to 6 2D textures (each textel containing, let's say, a 2 byte sprite ID and two nibbles for lighting). The textures are orthogonal projections of the visible part of that region and face, sized accordingly, and treated as GL_TEXTURE_RECTANGLE_ARB.
The block vertices and alone are stored to a VBO, with no UV or normals. The vertex shader, with a little precalculated information, converts the world coordinates directly into proper UV coordinates. The fragment shader then takes those UV coordinates, extracts the proper sprite in a 3D texture array, and then handles lighting and texturing all at the same. I'm not sure how it works, but I imagine smooth lighting could also be incorporated with a little more information, which would allow this method to entirely replace the current polygon system in regards to opaque cube blocks.
It will become inefficient once the polygons get down to a few pixels, but for close-to-mid range it should be really good.
With the new world height i'm guessing ships can get bigger, and the golems that are in the game could be demolished if you guys can get robots with better AI's :biggrin.gif:
With the new world height i'm guessing ships can get bigger, and the golems that are in the game could be demolished if you guys can get robots with better AI's :biggrin.gif:
Ships will get bigger, but my 5.88x1011-block supercruiser still won't fit. :sad.gif:
Rollback Post to RevisionRollBack
May the Force be with you. Unless you're a troll, in which case, may the farce be with you.
Glad to hear it has been useful :smile.gif:. The occlusion culling in the latest videos is purely client-side, although it does tie in closely with the rest of the voxel-shoveling pipeline, down to the network requests. Server-side culling will play an important role to reduce network load though. I'm reading through your dev log on the Futurecraft forum, and your fast culling method sounds ideal for this purpose! (I've shortly experimented with this type of culling, but never got past checking only the 6 direct transitions to the next chunk, instead of the 15 combinations you described. Of course my initial idea was too simplistic to work, and the hardware accelerated occlusion checks were fast enough, so I shelved it.)
I can PM you my source. It might help explain things, though the main loop was pretty aggressively optimized which makes it hard to follow. Relies pretty heavily on magic numbers.
The bottom line, though, is that while it may have a very low overhead, on a decent video card a ~70% occlusion efficiency over advanced opengl isn't enough to close the gap. The main cause of false inclusion is that line-of-sight cannot be confirmed with this level of detail in a cellular network. If it's even vaguely possibly visible, it gets included. However, being dirt cheap, it certainly makes for a good first pass.
That should work, although I'm not sure it will perform and scale better than a LOD'ed octree.
Besides the heavy memory requirements, my major concern with the voxel engine is the amount of stress it would put on a high-resolution window. Most of the test videos I've seen were in 480p or less. To try and maintain good performance at 1080p unaided is asking a lot. If we could more efficiently implement polygons for the near-to-mid range, it would save a lot of unnecessary work for the long-range rendering. Fortunately, the more distant the object the better it performs, since it can use coarser resolution data. So that works out pretty well.
I recently made a ship and would like someone to critique it. It is a small ship who's primary objective is core fuel transfer, despite not being designed to be a fighter it can fill the role if necessary.
Images of the ship from the outside.
Inside the cockpit.
The storage area.
View from the bottom showing the weapons (brick stairs), these extend and contract with 2 switches inside the cockpit.
I recently made a ship and would like someone to critique it. It is a small ship who's primary objective is core fuel transfer, despite not being designed to be a fighter it can fill the role if necessary.
Images of the ship from the outside.
Inside the cockpit.
The storage area.
View from the bottom showing the weapons (brick stairs), these extend and contract with 2 switches inside the cockpit.
Criticisms are highly welcome.
the inside is slightly cluttered and also the entire ship from the outside makes me go What The F*ck
make the ship a little more smooth by removing the big plate right behind the cockpit but otherwise not bad
I recently made a ship and would like someone to critique it. It is a small ship who's primary objective is core fuel transfer, despite not being designed to be a fighter it can fill the role if necessary.
<snip>
View from the bottom showing the weapons (brick stairs), these extend and contract with 2 switches inside the cockpit.
Criticisms are highly welcome.
Looks pretty good. It's much too big to be a starfighter, looks to be about dropship size. I like the cockpit.
Rollback Post to RevisionRollBack
May the Force be with you. Unless you're a troll, in which case, may the farce be with you.
I think the shape is good (except the engine positions, it looks wierd with the top one sticking out), but the block choice seems odd, the stairs don't go with the iron blocks very well and the glowstone-lantern-thingies dont look that good either (maybe replce them with normal glowstone). Mostly, though, the obsidian just seems out of place, either it's a iron ship or a obsidian bunker (that can fly :wink.gif: ), but not both.
the inside is slightly cluttered and also the entire ship from the outside makes me go What The F*ck
make the ship a little more smooth by removing the big plate right behind the cockpit but otherwise not bad
I agree its a little cluttered, but it IS a cargo ship, I personaly feel like its supposed to be that way, anyway you read futurecraft too?
I have been watching futurecraft for some time now and i just wanted to say that if i were to join the main unedited server (when it comes out) would there be a start for it like.... a pistol and a weak fighter or would it be a set of wood tools that make it a long time before you would be doing any FC stuff? also if you need any texture help tell me
I built my ship in creative (a early one) which looks a bit like the tantive IV but functions like the millenuim falcon
i would post screenshots but the save was corrupted :sad.gif:
and i think american pie band camp was like 2002 not 90s :wink.gif:
Edit: i would also like to be a server mod when it starts (if you can trust me)
If Facebook, Myspace, and Twitter were all destroyed, 99% of teens would go insane. If you're one of the 1% that would be laughing at them, copy this into your signature and hope it happens.
If Facebook, Myspace, and Twitter were all destroyed, 99% of teens would go insane. If you're one of the 1% that would be laughing at them, copy this into your signature and hope it happens.
Niiiiice. :smile.gif:
- The Cubic Chunks Mod is back! Be a part of it's rebirth and Development.
-- Robinton's Mods: [ Mirror ] for some of his Mods incl Cubic Chunks Mod, due to DropBox broken links.
- Dungeon Generator for the Open Cubic Chunks Mod
- QuickSAVE-QuickLOAD for the Open Cubic Chunks Mod
The dynamically loaded octtree implementation was done in CUDA. I'm not certain OpenGL+GLSL is able to provide enough control to manage the resources properly. OpenCL may provide that ability if the former cannot, but right now I'm just doing well to follow the GLSL discussion, so I couldn't say for sure how to pull it off.
I've actually been using your work as reference material. :smile.gif:
I'm still not completely sold on the server-side occlusion culling, but I have to admit it seems to work pretty well in your latest video.
-------------
New thought. Once more ignoring trees and non-cube blocks, if you perform binary space partitioning on the region to remove all concavities, you can store block information really efficiently. For each convex region, you have from 0 to 6 2D textures (each textel containing, let's say, a 2 byte sprite ID and two nibbles for lighting). The textures are orthogonal projections of the visible part of that region and face, sized accordingly, and treated as GL_TEXTURE_RECTANGLE_ARB.
The block vertices and alone are stored to a VBO, with no UV or normals. The vertex shader, with a little precalculated information, converts the world coordinates directly into proper UV coordinates. The fragment shader then takes those UV coordinates, extracts the proper sprite in a 3D texture array, and then handles lighting and texturing all at the same. I'm not sure how it works, but I imagine smooth lighting could also be incorporated with a little more information, which would allow this method to entirely replace the current polygon system in regards to opaque cube blocks.
It will become inefficient once the polygons get down to a few pixels, but for close-to-mid range it should be really good.
Ships will get bigger, but my 5.88x1011-block supercruiser still won't fit. :sad.gif:
I can PM you my source. It might help explain things, though the main loop was pretty aggressively optimized which makes it hard to follow. Relies pretty heavily on magic numbers.
The bottom line, though, is that while it may have a very low overhead, on a decent video card a ~70% occlusion efficiency over advanced opengl isn't enough to close the gap. The main cause of false inclusion is that line-of-sight cannot be confirmed with this level of detail in a cellular network. If it's even vaguely possibly visible, it gets included. However, being dirt cheap, it certainly makes for a good first pass.
Besides the heavy memory requirements, my major concern with the voxel engine is the amount of stress it would put on a high-resolution window. Most of the test videos I've seen were in 480p or less. To try and maintain good performance at 1080p unaided is asking a lot. If we could more efficiently implement polygons for the near-to-mid range, it would save a lot of unnecessary work for the long-range rendering. Fortunately, the more distant the object the better it performs, since it can use coarser resolution data. So that works out pretty well.
Images of the ship from the outside.
Inside the cockpit.
The storage area.
View from the bottom showing the weapons (brick stairs), these extend and contract with 2 switches inside the cockpit.
Criticisms are highly welcome.
[CENTER]
the inside is slightly cluttered and also the entire ship from the outside makes me go
What The F*ck
make the ship a little more smooth by removing the big plate right behind the cockpit but otherwise not bad
Looks pretty good. It's much too big to be a starfighter, looks to be about dropship size. I like the cockpit.
I think the shape is good (except the engine positions, it looks wierd with the top one sticking out), but the block choice seems odd, the stairs don't go with the iron blocks very well and the glowstone-lantern-thingies dont look that good either (maybe replce them with normal glowstone). Mostly, though, the obsidian just seems out of place, either it's a iron ship or a obsidian bunker (that can fly :wink.gif: ), but not both.
...............
It's probably better than I can do though...
I agree its a little cluttered, but it IS a cargo ship, I personaly feel like its supposed to be that way, anyway you read futurecraft too?
I built my ship in creative (a early one) which looks a bit like the tantive IV but functions like the millenuim falcon
i would post screenshots but the save was corrupted :sad.gif:
and i think american pie band camp was like 2002 not 90s :wink.gif:
Edit: i would also like to be a server mod when it starts (if you can trust me)
Classified. Your attempt to access restricted information has been noted. I'd guess weeks - months.
Futurecraft was released! :biggrin.gif:
:wink.gif: :tongue.gif: Welcome back Doc.
- The Cubic Chunks Mod is back! Be a part of it's rebirth and Development.
-- Robinton's Mods: [ Mirror ] for some of his Mods incl Cubic Chunks Mod, due to DropBox broken links.
- Dungeon Generator for the Open Cubic Chunks Mod
- QuickSAVE-QuickLOAD for the Open Cubic Chunks Mod
nah, I just killed them all with my army of necromancy zombies and skeletons :laugh.gif:
EDIT: well......except for MineCrak. He's to damn powerful...
Don't forget me with my army of creepers
It was?!?
If Facebook, Myspace, and Twitter were all destroyed, 99% of teens would go insane. If you're one of the 1% that would be laughing at them, copy this into your signature and hope it happens.
unhelpful.
If Facebook, Myspace, and Twitter were all destroyed, 99% of teens would go insane. If you're one of the 1% that would be laughing at them, copy this into your signature and hope it happens.
Seriously, if you're interested in tracking the progress of this mod this is the place to be. Best thing since Pop Tarts.