I thought this might be of interest to some of you guys: Accidental Noise Library

As far as I can tell you can consider it as an alternative to LibNoise or Noise++ (I've never used any of them so I can't compare). It's written by JTippets, who did some work on MineCraft-style terrain generation and used PolyVox for some visualisation.

He's also written a very cool article, which is well worth checking out: 3D Cube World Level Generation

Quick review of the noise libraries

libnoise: painfully slow, and last updated 8 years old (from what I can tell). It has the best documentation and a couple of examples and tutorials.
noise++: Much faster than libnoise (and from what I can tell more feature rich). It even has threading capability. 4 years since last update and its wiki page is down for a while now. It does however contain a list of all classes (ala polyvox api page ), and you can work from that and the included examples.

Haven't tried Accidental Noise Library yet, but the it's the library that was most recently updated of them all (2011) and documentation is pretty good.


I'm honestly surprised at the distribution of time spent on generating procedural worlds, 11% of time spent in polyvox, and 81% of the time spent in noise++. In memory compression disabled for polyvox, and no threading used for noise++ though.

Happy voxeling!

For some reason I was under the impression that Noise++ was a C++ wrapper for libnoise... but apparently this isn't correct.

Anyway, interesting results. When you say that 11% of the time is spent in PolyVox this is just for reading/writing the volume data? You're not including extracting a surface here?

That 11% is the time spent on surface extraction, So less than 8% of the time is spent on adding the data to polyvox. Visual Studio 11's performance analyser didn't mention the amount of ticks it spent inside mVoxTerrain.mVolume.setVoxelAt(x,y,z,voxel), probably due to inlining but I am doing other stuff in that 8% slice of time as well.

Screenshot of separate run, slightly different results.

last 2 columns are inclusive % and exclusive %.

Do note, that I'm slightly new to C++, so my code is definitely not the fastest.

It's interesting to see that the call to PolyVox::Array::resize() is fairly cheap. It performs a dynamic memory allocation and I had assumed that caching/pooling these would give a speed boost, but it perhaps maybe not then. Anyway, I'm glad that PolyVox is not a bottleneck for you

Hello,
Let me start off by thanking you for the selfless contribution you have made to the community with this wonderful library.

I am writing a game with terrain similar to Minecraft using the Irrlicht and PolyVox libraries. I am trying to use the Accidental Noise Library to generate a Minecraft-like terrain, so I looked at the example on their website. It works well, but it is SO SLOW. It takes like 5-10 minutes (actually I think its much longer than this) to just generate a 128x128x128 block chunk. I tried to use a thread to speed the process up, but it didn't do anything. The website says something about using a single fractal for generation to make it faster, but I'm kind of lost. If they use different types (FBM, RIDGEDMULTI, BILLOW, etc.), different number of octaves, etc., then how can I use the same fractal for everything? Does anyone understand this, and if so, can you point me in the right direction?

Also, sorry if this thread is too old for an update, I'm not good at that (lol).

Thanks,
Joey

UPDATE:

With this link: http://www.gamedev.net/blog/33/entry-22 ... world-gen/

I can generate a 128x128x128 chunk in 55 seconds. This is obviously still too long, but a step in the right direction.

I feel stupid... Chunk is too large. With 32x32x32, it generates in 866ms... that is pretty good.

I'm afraid I don't actually have any experience with the Accidental Noise Library so I can't help you directly. Do you have any idea what the expected performance is? Perhaps the author can give you a ballpark figure here.

For reference, Minecraft uses 16x16x128 chunks which contain the same number of voxels as your 32x32x32 chunks. It does seem feasible that Minecraft spends 1 second generating each chunk.

Yes, I'm happy with the 32x32x32. I was trying 128x128x128 before and it wasn't taking too long. Someone told me to use multiple rawvolumes to store the chunks instead of largevolumes. Is this recommended?

Usually it is not remommended to use multiple RawVolumes instead of a single LargeVolume, because you will encounter problems on the boundary between volumes when extracting a mesh. So you should avoid this if you can.

You may find that the RawVolume has better performance though, as the logic behind reading/writing voxels is much simpler. You should try to determine if this is really a bottleneck for you though. I think LargeVolume will get some more attention in the future as we plan to use it for our next project.

I'm getting low fps with Irrlicht, but I'm not sure how to improve it. I don't think it has anything to do with the volumes though. After a couple of 32x32x32 chunks have been extracted and rendered, it starts to slow down.

I am compiling Minetest to compare my results (I am not expecting similar results, but I just want to see if my hardware in this laptop just sucks, or its the video driver or something).