Jump to content
  • Advertisement
  • entries
    3
  • comments
    11
  • views
    437

Bumpy World

Gnollrunner

733 views

After a LOT of bug fixes, and some algorithm changes changes, our octree marching prisms algorithm is now in a much better state.  We added a completely new way of determine chunk level transitions, but before discussing it we will first talk a bit more about our voxel octree.

Our octree is very explicit. By that we mean it is built up of actual geometric components. First we have voxel vertexes (not to be confused with mesh vertexes) for the corners of voxels. Then we have voxel edges that connect them. Then we have voxel faces which are made up of a set of voxel edges (either three or four) and finally we have the voxels themselves which reference our faces. Currently we support prismatic voxels. since they make the best looking world, however the lower level constructs are designed to also support the more common cubic voxels.  In addition to our octree of voxels, voxel faces are kept in a quadtrees, while voxel edges are organized into binary trees. Everything is pretty much interconnected and there is a reference counting system that handles deallocation of unused objects.

So why go though all this trouble? The answer by doing things this way we can avoid traversing the octree when building meshes using our marching prisms algorithms. For instance, If there is a mesh edge on a voxel face, since that face is referenced by the voxels on either side of it, we can easily connect together mesh triangles generated in both voxels. The same goes for voxel edges.  A mesh vertex on a voxel edge is shared by all voxels that reference it. So in short, seamless meshes are built in place with little effort. This is important since meshes will be constantly recalculated for LOD as a player moves around.

This brings us to chunking.  As we talked about in our first entry, a chunk is nothing more than a sub-section of the octree. Most importantly we need to know where there are up and down chunk transitions.  Here our face quadtrees, and edge binary tress help us out.  From the top of any chunk we can quickly traverse the quadtrees and binary trees and tag faces and edges as transition objects. The algorithm is quite simple since we know there will only be one level difference between chunks, and therefore if there is a level difference, one level will be odd and the other even. So we can tag our edges and faces with up to two chunk levels in a 2 element array indexed by the last bit of the chunk level.  After going down the borders of each chunk, border objects will now have one of two states. They will be tagged with a single level or a two levels one being one higher than the other.  From this we can now generate transition voxels with no more need to look at a voxel's neighboring voxels. 

One more note about our explicit voxels, since they are in fact explicit there is no requirement that they form a regular grid.  As we said before our world grid is basically wrapped around a sphere which gives us fairly uniform terrain no matter where you are on the globe.  Hopefully in he future we can also use this versatility to build trees.

Ok so it's picture time......... We added some 3D simplex nose to get something that isn't a simple sphere.  Hopefully in our next entry we will try a multi-fractal.

 

 

BumpyWorld.jpg



0 Comments


Recommended Comments

There are no comments to display.

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
  • Advertisement
  • Advertisement
  • Blog Entries

  • Similar Content

    • By Josheir
      This is a follow up to a previous post.  MrHallows had asked me to post the project, so I am going to with a new fresh thread so that I can get the most needed help. 
      I have put the class in the main .cpp to simplify for your debugging purposes.  My error is :  
      C1189 #error: OpenGL header already included, remove this include, glad already provides it  
      I tried adding : #define GLFW_INCLUDE_NONE, and tried adding this as a preprocessor definitions too. I also tried to change the #ifdef - #endif, except I just couldn't get it working. The code repository URL is :
      https://github.com/Joshei/GolfProjectRepo/tree/combine_sources/GOLFPROJ
       
      The branch is : combine_sources
      The Commit ID is: a4eaf31
      The files involved are : shader_class.cpp,  glad.h, glew.h
      glad1.cpp was also in my project, I removed it to try to solve this problem.
       
       
      Here is the description of the problem at hand:
      Except for glcolor3f and glRasterPos2i(10,10); the code works without glew.h.  When glew is added there is only a runtime error (that is shown above.) 
       
      I could really use some exact help.  You know like, "remove the include for gl.h on lines 50, 65, and 80.  Then delete the code at line 80 that states..."
       
      I hope that this is not to much to ask for, I really want to win at OpenGL.  If I can't get help I could use a much larger file to display the test values or maybe it's possible to write to an open file and view the written data as it's outputted.
       
      Thanks in advance,
      Josheir
    • By babaliaris
      Hello!
      I'm trying to understand how to load models with Assimp. Well learning how to use this library isn't that hard, the thing is how to use the data. From what I understand so far, each model consists of several meshes which you can render individually in order to get the final result (the model). Also from what assimp says:
      One mesh uses only a single material everywhere - if parts of the model use a different material, this part is moved to a separate mesh at the same node The only thing that confuses me is how to create the shader that will use these data to draw a mesh. Lets say I have all the information about a mesh like this:
      class Meshe { std::vector<Texture> diffuse_textures; std::vector<Texture> specular_textures; std::vector<Vertex> vertices; std::vector<unsigned int> indices; } And lets make the simplest shaders:
       
      Vertex Shader:
      #version 330 core layout(location = 0) in vec3 aPos; layout(location = 1) in vec3 aNormal; layout(location = 2) in vec2 aTexCoord; uniform vec3 model; uniform vec3 view; uniform vec3 projection; out vec2 TextureCoordinate; out vec3 Normals; void main() { gl_Position = projection * view * model * vec4(aPos, 1.0f); TextureCoordinate = aTexCoord Normals = normalize(mat3(transpose(inverse(model))) * aNormal); } Fragment Shader:
      #version 330 core out vec4 Output; in vec2 TextureCoordinate; in vec3 Normals; uniform sampler2D diffuse; uniform sampler2D specular; void main() { Output = texture(diffuse, TextureCoordinate); }  
      Will this work? I mean, assimp says that each mesh has only one material that covers it, but that material how many diffuse and specular textures can it have? Does it makes sense for a material to have more than one diffuse or more that one specular textures?  If each material has only two textures, one for the diffuse and one for the specular then its easy, i'm using the specular texture on the lighting calculations and the diffuse on the actual output.
      But what happens if the textures are more? How am i defining them on the fragment shader without knowing the actual number? Also how do i use them? 
    • By Josheir
      I'm having trouble with glew sharing some defines that I can't resolve.  Does anyone know of a way to get the following statements working instead of an include with glew (glew resolves the red squigglies too.)
      glColor3f(0, 1, 0.); glRasterPos2i(10,10); I really want to use a quick glut command for now.  The command uses the statements above.
      Thank You,
      Josheir
    • By PerezPrograms
      Hello everyone,
      While I do have a B.S. in Game Development, I am currently unable to answer a very basic programming question. In the eyes of OpenGL, does it make any difference if the program uses integers or floats? More specifically, characters, models, and other items have coordinates. Right now, I am very tempted to use integers for the coordinates. The two reasons for this are accuracy and perhaps optimizing calculations. If multiplying two floats is more expensive in the eyes of the CPU, then this is a very powerful reason to not use floats to contain the positions, or vectors of game objects. 
      Please forgive me for my naivette, and not knowing the preferences of the GPU. I hope this thread becomes a way for us to learn how to program better as a community.
       
      -Kevin
    • By ConorH
      Looking for example code... I can find lots of ways to find the points of intersection, but not the rectangle solution im looking for (see picture)
      The black rect is a tilemap, the red rect is the camera... Im looking to supply 2 rectangles (with four members - x,y,w,h), and receive back essentially the green rectangle in the examples.
      also, what's this problem known as?

×

Important Information

By using GameDev.net, you agree to our community Guidelines, Terms of Use, and Privacy Policy.

We are the game development community.

Whether you are an indie, hobbyist, AAA developer, or just trying to learn, GameDev.net is the place for you to learn, share, and connect with the games industry. Learn more About Us or sign up!

Sign me up!