Jump to content

  • Log In with Google      Sign In   
  • Create Account


Member Since 04 Aug 2009
Offline Last Active Jul 08 2013 09:52 AM

Posts I've Made

In Topic: Yet another voxel terrain system: presentation of my work and ideas

02 October 2012 - 09:14 AM

Hmm... wait, why do people rely on sampling so much? Be a little more procedural with the way you handle things.

In my case the terrain can be modified, it's not a static procedural defined shape.

Grass: Smartest I've seen is a grass map, greyscale map of grass density and then just spawn based on the map. A single easily generatable texture shouldn't be much memory. Of course you're only getting a single height layer, no grass in caves. But then why would you want that? I suppose if you did could always use a multi channel texture to store it and then have up to X heights depending on the channels you have available.

I don't see why I couldn't have grass in caves, the greyscale map just has to be three dimensional as you said. But once again, since the terrain can be modified I don't see why I'd want to store the grass density in any map, it should be part of the voxel data.

For your case, I recommend you just describe enough for the sampling to know what's appropriate i.e. a single scalar code for each voxel which corresponds to a 6-sided set of materials Examples: some material sets may entirely include the cliff texture, sometimes a mix of messy grass at the top and cliff on the sides, dirt ontop and red rock on the sides, or chalky-dirt with weeds on the top and cobble on the sides etc.

I did plan in fact some sort of merging to describe voxels with grass on top and rock on the sides, but I don't think that having materials that describe each side (or even two) is useful; if there is rock on the sides, so there is on top and everywhere else. I just thought of using a single bit to know whether there should be grass on top or not. For dirt on top and rock on side, just have a voxel layer of dirt on top of rock should be enough.

In Topic: GLSL automatic texture coordinated for cube

21 August 2012 - 12:57 PM

You might be interested by triplanar texturing. Using the local position and orientation of the vertices you can compute texture coordinates for arbitrary oriented/sized cubes. If you can use geometry shaders, you could also consider using them to generate the whole geometry of your cube.

In Topic: Yet another voxel terrain system: presentation of my work and ideas

14 August 2012 - 09:33 AM

Thank you guys for your help and suggestions.

You should experiment with more sophisticated normal map generation (which should also improve the automatic tri-planar texture blending). I'm thinking of using a "deeper sampling" into the voxel data to improve the distribution of things. Look at the bottom half quarter of your image. See the unrealistic, voxel-regular distribution of blending between grass and cliff? Also, near the cliff-slopes and thin spans of higher elevation, there shouldn't be any grass (either dirt or cliff). The diffuse lighting looks distributed good enough (although could be enhanced), but the texture distribution needs improvement more than anything else.

Sorry for the late answer, I was busy working on something else. I remember trying to sample a larger area for normal generation at first, but the only difference I could notice was a slight performance drop on geometry generation. I figured sampling 6 values was quite enough, especially if I'm doing some normal mapping or grass rendering (which I plan to do... later) on top of it. I agree that the texture transition looks quite bad though, I didn't really work on rendering yet. I quickly made a noise blending, and it looks a bit better though it still lacks some tweaking:

Posted Image Posted Image

The terrain geometry is generated as we move around

This will impose restrictions on the terrain generation. Any part of the terrain you generate can not depend on neighbor chunks. That makes it difficult to have "classic" terrain generation, for example making rivers by following the terrain from high to low elevation. This may be a necessary design limitation.

I was actually talking about geometry generation (via marching cubes) for rendering. The voxel generation is currently hardcoded in my test sample, the entire world is generated (or loaded from HDD) at the beginning. I don't know how I plan to generate the world if the player moves too close to the border. I'm aware of this kind of problem though, Shamus Young made a pretty nice blog entry about it.

Marching cubes have some limitations. When you have voxels of different types beside each other, it is tricky to determine out what texture to use. And then, some voxel should be drawn as cube (for example bricks).

With geometry shaders it seemed to be the easiest way to generate the isosurface (plus I had a nice article to steal from). I haven't tried using multiple materials yet, I guess you are right about texturing, but does it really depend on the isosurface generation algorithm? I don't plan to use the terrain to build any structure, so I should be OK with cubes.

However I can't go around compressing/decompressing files on the fly as needed

Why not? Compressions is good not only for disk space, but also for communication bandwidth. But you may want to consider a very quick algorithm. The server should be able to cache chunks at several stages: on file, loaded to memory compressed, uncompressed in memory. You then need an algorithm that moves data back and forth between these stages. Use a checksum for each chunk, to make it easier and faster to communicate with the clients. And then, the clients also need to cache chunks.

Hm, it may not appear so but it is (except for the checksum) what I was trying to say, I probably didn't make myself clear. By "on the fly" I meant "from HDD to memory to HDD everytime needed, without cache", which is (I believe) too expensive. Anyway the caching system is pretty much done and working now.