Jump to content
  • Advertisement
Sign in to follow this  
  • entries
    31
  • comments
    55
  • views
    46641

SeedWorld (voxel world engine) update 2

Sign in to follow this  
CC Ricers

2454 views

One week later into my voxel engine, which I now call the SeedWorld engine, I am still facing a lot of technical issues but still made a lot of progress. I finally have a octave noise function that I am very satisfied with, in creating those very believable rolling hills you see a lot in procedural landscapes. Here is the breakdown of the current technical specs of the voxel world generation.

  • Voxel data is discarded as soon as chunk meshes are made. Chunks store only vertex data at the minimum*
  • Far draw distance (I want to emphasize this in faster PCs)
  • World divided into 32x32x256 chunks, with an area roughly 2000x2000 in size for the visible portion
  • Multi-threaded support for voxel and mesh generation

    Future specs include:

    • Material determines the attributes in game, color gradients, and sounds for interaction feedback
    • Persistent storage for voxels only in the player's immediate surroundings*
    • Different biomes which affect the visuals and interactivity of the materials

      *This supports interactivity for making the world destructible, but only where it makes sense (near the player), and keeps the managed memory footprint low.

      When I was still tweaking with different combinations of noise patterns, I could only come up with very large smooth, round hills, or many little but very bumpy hills. No repetition, but very bland to look at.

      I had the basic idea down- combine many layers of Simplex noise of different frequencies, offsetting the X and Y for each of them just a little. But I had a derp moment when I realized I should be reducing the amplitude (effectively, the height variation) as I increase the frequency for best results. JTippets' article on world generation really helped here.

      Here are some screenshots of various builds, in order of progression. Here is "revision 2" as it follows the first build mentioned in my last journal entry:

      YNVDyXS.png

      Already in revision 2 I have added optimized mesh generation to remove hidden faces. The wireframe render shows this well.



      Revision 3 shows the vast improvements in terrain generation that I mentioned previously. The draw distance is improved, and noise patterns create much more natural looking hills and valleys. Color is determined by height variation and whether or not the block is a "surface" block. The white patches you see are sides of steep hills that don't have the top face visible.

      FQKbfnD.png

      Between revisions 3 and 4 I was trying out ways to speed up voxel generation, mostly with octrees. That didn't work out as planned, for reasons I will state later in this post. So I went back to my previous way of adding voxels. The biggest feature update here is simple vertex ambient occlusion through extensive neighbor voxel lookups.

      3Y4jT0J.png


      FSf7BPz.png

      It is a subtle update but it greatly improves the appearance of the landscape a lot. I applied the AO method that was discussed in the 0FPS blog. The solution is actually simple to do, but the tedious part was combining the numerical ID lookups for all the neighbor voxels so that each side is lit correctly. I should really change those numbers into Enums for voxel locations so the code is less confusing.

      Here is a screenshot just showing just the AO effect.

      oUiRbhP.png

      It is around revision 4 when I also made a Git repo for the project, and it has also been uploaded to a private Bitbucket account.

      Performance stats, you say? Unfortunately I am not yet counting the FPS in the engine and I believe my stopwatch use of tracking time for chunk updates is wrong, because when it reads 15 milliseconds (about 67 FPS) the program becomes incredibly slow, as if it was updating only twice per second, but at 10 milliseconds or less, the program runs silky smooth without any jerky movement.

      What I can tell you, though, is that currently I am sticking to update just one 32x32x256 chunk per frame in order to keep that smooth framerate. At 60 chunks per row, It's still quick enough for the world generation to catch up to movement up to around 25 blocks/second. This is throttled by a variable that I can change to tell the program how many "dirty" chunks per frame it should update. My processor is a Pentium G3258- a value CPU but still decent for many modern games (as long as they are not greatly dependent on multi-threading), especially since it is overclockable. I have mine overclocked to 4.2 Ghz. If you have a CPU that can run 4 threads, has 4 cores or more, you should be able to update several chunks per frame very easily.

      About using octrees- I did not perceive any performance gains from using them so far. I wanted to use octrees as a way to better find potential visible voxels without the brute force option of going through all the voxels in the array. The good news is: I got the octrees to technically work (also did some nice test renders) and I also learned how to do so using Z-curve ordering and Morton encoding. At least I gained some interesting knowledge there. Bad news: reducing the amount of voxel lookups with octrees did not result in being able to quickly update more chunks per frame, which was the ultimate goal. So I am putting aside the octree-related code for now and maybe it will come in handy later.

      Persistent local voxel storage concept, and future updates

      The persistent storage for local voxels is definitely something I want to implement, and make a key feature in my engine. Keeping voxel data for the entire visible world is usually wasteful and it only makes sense really to know what you will see immediately around you. After all, if you have a pickaxe, you are not going to reach that block that is 500 meters away. This data storage will update as you move around the world, storing at the most 4 chunks worth of voxels.
      This can be applied further with other objects that may interact with the world surface. Say you are a mage that can cast a destructive fireball. Upon impact, you want to calculate the voxel data for the area around the fireball so it can make a crater. Or an ice ball to freeze the surface. Obviously you want these calculations to be done very quickly, so it sounds like a good way to stress test the engine with lots of fireballs and who knows what else being thrown around.

      Other more features I want to add soon are the creation of pseudo-random rock formations and measuring slope steepness which will help in generating other pseudo-random elements. Probably gonna add those voxel trees first, in order to add more to the landscape.
Sign in to follow this  


3 Comments


Recommended Comments

Interesting

 

Thanks for your comment. I was reading your game development blog on RuinValor since last year and it got me thinking how easy or hard it would be to roll my own voxel world engine. I'll probably make an RPG with it too.

Share this comment


Link to comment

This is looking quite nice. Your journal entries are also quite informative ... and inspiring wink.png

 

MoreChunks.jpg

Share this comment


Link to comment

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
×

Important Information

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

Participate in the game development conversation and more when you create an account on GameDev.net!

Sign me up!