Cubes – A Block World Framework [Update Preview]

@echospot said: http://stackoverflow.com/questions/18279456/any-simplex-noise-tutorials-or-resources

I looked here for where I’m going to make my own generator. Nice and simple right off of Stefan Gustavson’s code.

Note: while that thread is excellent, it doesn’t really go over how to use noise for multi-octave fractal implementations like terrain generation.

I’ve responded separately from my other answer to address that specifically… for those who can’t get their hands on the book and would rather not bother with the depth.

Anyway, there are probably better sites but I don’t have them to hand… but the full GPU Gems 3 article is available online:
http://http.developer.nvidia.com/GPUGems3/gpugems3_ch01.html

…that’s essentially what I built my IsoSurface stuff off of.

Skip down to the section: 1.3.2 Generating the Density Values

It walks through building up terrain generation from source noise. The type of noise doesn’t really matter from a perspective of how to use it (whether Perlin, Simplex, other).

1 Like

Thanks all.
So I gather that the thing that made @pspeed mention fractal-based noise is the use of a vector->scalar function instead of interpolating. Is that correct?

Nearer to “give me the concepts” track, I found this simplex noise tutorial. It first explains Perlin noise, then simplex noise, gives a sample implementation and explains what the trade-offs in that implementation were.

@toolforger said: Thanks all. So I gather that the thing that made @pspeed mention fractal-based noise is the use of a vector->scalar function instead of interpolating. Is that correct?

Yes.

Especially with something like midpoint displacement, generating an “endless world” is really difficult because every part of the world is indirectly dependent on every other part of the world.

Whereas with the layering of fractals I use in Mythruna, I can sample any part of the world I want instantly. Aside from terrain type classification which relies on the neighboring cells, everything is 100% independent. And frankly, I think the results are better, too. In 3D, approaches like Diamond-squares and other midpoint displacements start to show strange aliasing that you can pick up if your are looking for it.

I thought I’d posted my fractal editor here once before but I couldn’t find it. So, for anyone interested… I’m clipping a post from the mythruna forum (that’s donators only there).

I wrote this around 2006 and resurrected it to use to design Mythruna's terrain fractals.

You can download versions for the different platforms here:
http://mythruna.com/MapMaker/MapMaker-20120204-Windows.zip
http://mythruna.com/MapMaker/MapMaker-20120204-Linux.zip
http://mythruna.com/MapMaker/MapMaker-20120204-MacOSX.zip

The parameters are probably kind of baffling as they require some understanding of fractals to really know what’s going on. But sometimes just adding things and messing with them can show good results.

I’m attaching the config file that most closely resembles Mythruna’s terrain. I’m not sure it’s the same since I may have tweaked Mythruna’s settings in code.

The basic GUI works like this:
You start with a flat terrain at sea level (that’s why it’s all yellow)
You can add layers that either replace the previous layer or add to it. These layers can also be “affected” by the previous layers.

What is the difference between “additive” and “affected”?
Additive: the values produced by this layers generator are added to the values of the previous. previousValue + thisValue.
Affected: many fractals actually take a 3D coordinated and produce a 3D coordinate. For these layers, “affected” means that it will use the previous layers height as the Z in the next layers 3D coordinate.

Affected is really only useful in fractal-based layers. Additive works for any layer.

If neither is selected then the previous layer is completely replaced (which is kind of a waste).

What do the different generators mean?
Diamond/Squares - One of the original terrain generation algorithms people play with when writing terrain generators. I think I first goofed around with Diamond/Squares in 1993 or so. I had to include but it’s not a very useful generator as it has to generate all of terrain at once.
Adaptive Diamond/Squares - Some variation on the above.
Midpoint Displacement - an algorithm similar to Diamon/Squares. These are provided more for completeness and nostalgia. This one is obviously uglier then D/S and has the same down sides.
Multi-Fractal - Now we’re talking. The fractals are nice because for any x,y coordinate in the whole world they can instantly give you the height. You do not have to generate all surrounding points. This makes them ideal for an infinite world like Mythruna.
Ridge Fractal - Another cool fractal. Especially nice when affected it turned on. Can be used to add interesting features to a previous layer.
Heterogeneous Fractal - Another fractal. I no longer remember what its specific difference is.
Fractal Sum - One of the better ones. The base mythruna terrain is a “Fractal Sum” layer with a “Ridge Fractal” on top.
Turbulence - a wavy bumpy noise-based generator resembling turbulence.
Perlin Noise - the basic 3D noise that is used by the other fractals. Sometimes useful on its own. For several of the above fractals you could simulate them by layering a dozen perlin noise layers with different settings.
Spherical - generates spherical bumps. This is a useful bottom layer because it will help ensure that you have large above water sections and large underwater sections. It provides large scale underlying variation. Mythruna uses this as its bottom layer to make sure that there is plenty of land and water.
Erosion Operator - filters the previous layer providing some erosion simulated smoothing. This one is not as flexible as the fractal based layers since it requires the surrounding points of a given x,y in order to determine the final elevation… but it’s still nice to play with.

Note: Mythruna actually swaps x and y for its terrain. The story of why is longer than I want to go into here… but when you load the Mythruna config file that’s probably why the spawn area isn’t instantly recognizable. It’s there right in the middle you just have to imagine x,y swapped. (north/south is east/west in Mythruna, etc.)

You can kind of see it in this pic:

Hopefully you find some minutes of fun poking around.

I find it educational to be able to play with the parameters of the various types of fractals to see what they do.

2 Likes

@pspeed, I admire your work and knowledge, and most of all, thank you for sharing with us!

Thanks all! I seriously knew little to nothing, now to keep learning. ^-^ @pspeed like lawsy said, your work is awesome!

1 Like

First of all, thank you all for helping out echospot and I. Our game is coming along really well and it’s seriously amazing to me the level of support that you all have offered. Now back to our lighting issue…

@lawsy said: Just for a little test, I copied your code from the link in the previous forum and ran it in my Greedy Vox project and worked fine, also never had any issues before using lights and shadows with the cube framework either, sorry I can't help, not experienced enough engineer with jmonkey, but looking at your examples you posted, kind of seems like a graphics card glitch, just throwing out some ideas, hopefully some of the guys on this forum can give you better advice.

We’re still struggling with lighting, here are a couple screenshots:


Does anyone know what could be causing this? Is it because the surfaces are flat, or maybe we are too far from the pointlight (about 3000 units), or could it be a graphics card glitch? I’m seeing such beautiful images with shadows from all you guys and it baffles me that we can’t achieve the same results. Thanks for any help :slight_smile:

@PewPewKapowie said: First of all, thank you all for helping out echospot and I. Our game is coming along really well and it's seriously amazing to me the level of support that you all have offered. Now back to our lighting issue..

[…]

Does anyone know what could be causing this? Is it because the surfaces are flat, or maybe we are too far from the pointlight (about 3000 units), or could it be a graphics card glitch? I’m seeing such beautiful images with shadows from all you guys and it baffles me that we can’t achieve the same results. Thanks for any help :slight_smile:

Just to show on different machines, here’s a shot on my Intel Graphics laptop:

And on my ATI Raedon HD 6670 card:

Thanks much.

Just a shot in the dark-- but have you tried using the directional light instead? If you’re representing the Sun, a directional light would be far better. Point lights would be better for things like torches and lamps and whatnot.

EDIT: Another thought… how are your physics doing? You getting any weird “sliding” behaviors, or perhaps getting stuck partway through blocks? To me, it looks almost like you have two similar objects stuck in exactly the same spot, which can also cause physics problems. Do you add two spatials to the scene by accident? You could check by system.out.printing the location of all your chunk controls from a loop, then checking for duplicate locations.

@ulfgur said: Just a shot in the dark-- but have you tried using the directional light instead? If you're representing the Sun, a directional light would be far better. Point lights would be better for things like torches and lamps and whatnot.

EDIT: Another thought… how are your physics doing? You getting any weird “sliding” behaviors, or perhaps getting stuck partway through blocks? To me, it looks almost like you have two similar objects stuck in exactly the same spot, which can also cause physics problems. Do you add two spatials to the scene by accident? You could check by system.out.printing the location of all your chunk controls from a loop, then checking for duplicate locations.

A directional light wouldn’t work for us, as this isn’t infinite terrain like Minecraft. We are planning on having multiple cube “planets” that all literally orbit the star and rotate on their axes. So instead of having just a texture of a star like in Minecraft, we would actually have a real star that the player could build a rocket ship and fly to or whatever.

Yes we are having some weird physics problems. I never thought that we could have blocks overlapping eachother, I will check that out and let you know, thanks!!

Edit:
I ran a loop that printed out the locations of every BlockChunkControl and had no duplicates. Also we have block placement and removal working, so I assume I’d have to probably click twice or something to remove a block, but I only have to click once. I tried moving the planet closer to the pointlight, and it seems to help, but not enough to look good:

3000 units:

1000 units:

500 units:

Hmmm…

That just looks sooo much like an overlap problem to me. I don’t know, I could easily be wrong, but I strongly suspect you’re getting on overlap somewhere. Is it possible that you generated extra terrain controls somehow?

You might also try the following for the physics problem:

[java]
(CHUNK NAME HERE).addChunkListener(new BlockChunkListener()
{
@Override
public void onSpatialUpdated(BlockChunkControl blockChunk)
{
Geometry optimizedGeometry = blockChunk.getOptimizedGeometry_Opaque();
RigidBodyControl rigidBodyControl = optimizedGeometry.getControl(RigidBodyControl.class);
if(rigidBodyControl == null)
{
rigidBodyControl = new RigidBodyControl(0);
optimizedGeometry.addControl(rigidBodyControl);
bulletAppState.getPhysicsSpace().add(rigidBodyControl);
}else
{
bulletAppState.getPhysicsSpace().remove(rigidBodyControl);
optimizedGeometry.removeControl(RigidBodyControl.class);
rigidBodyControl = new RigidBodyControl(0);
optimizedGeometry.addControl(rigidBodyControl);
bulletAppState.getPhysicsSpace().add(rigidBodyControl);
}
rigidBodyControl.setCollisionShape(new MeshCollisionShape(optimizedGeometry.getMesh()));
}
});
[/java]

I adapted this from some previous posts, it manages my physics very nicely.

I really don’t know much about the framework, and am only mildly experienced at java, so I hope I’m not leading you on a wild goose chase. Don’t pay too much attention to this advice. : )

@ulfgur said: That just looks sooo much like an overlap problem to me. I don't know, I could easily be wrong, but I strongly suspect you're getting on overlap somewhere. Is it possible that you generated extra terrain controls somehow?

You might also try the following for the physics problem:

[java]
(CHUNK NAME HERE).addChunkListener(new BlockChunkListener()
{
@Override
public void onSpatialUpdated(BlockChunkControl blockChunk)
{
Geometry optimizedGeometry = blockChunk.getOptimizedGeometry_Opaque();
RigidBodyControl rigidBodyControl = optimizedGeometry.getControl(RigidBodyControl.class);
if(rigidBodyControl == null)
{
rigidBodyControl = new RigidBodyControl(0);
optimizedGeometry.addControl(rigidBodyControl);
bulletAppState.getPhysicsSpace().add(rigidBodyControl);
}else
{
bulletAppState.getPhysicsSpace().remove(rigidBodyControl);
optimizedGeometry.removeControl(RigidBodyControl.class);
rigidBodyControl = new RigidBodyControl(0);
optimizedGeometry.addControl(rigidBodyControl);
bulletAppState.getPhysicsSpace().add(rigidBodyControl);
}
rigidBodyControl.setCollisionShape(new MeshCollisionShape(optimizedGeometry.getMesh()));
}
});
[/java]

I adapted this from some previous posts, it manages my physics very nicely.

I really don’t know much about the framework, and am only mildly experienced at java, so I hope I’m not leading you on a wild goose chase. Don’t pay too much attention to this advice. : )

Thanks so much for that code! The physics seem so much better now. I used to be able to walk through blocks with ease, but not anymore. I will keep searching for places I might be overlapping the blocks. I agree with you, it seems like blocks must be overlapping. I’ll let you know if I find anything.

You’re welcome. Most of it is based off of (if not completely ripped off of) previous posts in this thread, so the credit is not all mine. Anyway, when I’m at the right point I’ll probably ask for your research on noise. :wink:

@ulfgur said: You're welcome. Most of it is based off of (if not completely ripped off of) previous posts in this thread, so the credit is not all mine. Anyway, when I'm at the right point I'll probably ask for your research on noise. ;)

Haha you’re gonna want to ask echospot about that. I’ve let him handle all the noise generation and GUI while I work on things like physics, mechanics, and data. We’d be happy to share though!

Sounds good!

D’you know something, the strange lighting actually looks kinda awesome. I dunno if it’s just me, but the inconsistency seems to add something interesting where people wouldn’t really think to look. I’d actually keep it that way (Unless it’s inefficient, of course, and you can’t optimize it).

That’s just me, really. And unfortunately, I can’t help you with the lighting issues, since I’m not very good with lighting myself.

@Eliwood said: D'you know something, the strange lighting actually looks kinda awesome. I dunno if it's just me, but the inconsistency seems to add something interesting where people wouldn't really think to look. I'd actually keep it that way (Unless it's inefficient, of course, and you can't optimize it).

That’s just me, really. And unfortunately, I can’t help you with the lighting issues, since I’m not very good with lighting myself.

Haha it does look pretty cool, but that’s only really when it’s a screenshot. If you move the camera around, the fuzziness dances around and it looks really weird. (Did that make any sense? :stuck_out_tongue_winking_eye: ) I actually probably would leave it like this, but when you build a house or whatever, I’d like the inside to be dark, but light shines through like it’s not even there.

Here I am standing in a dirt house I just built, completely closed off, no doors or windows. I am facing the direction of the star.

I just had a thought, could the lighting problems be caused by me working in Eclipse? echospot also works in Eclipse. It seems unlikely. Is there a way I could test this?

Edit: Just exported the jar and ran it, same lighting problems. I doubt it’s Eclipse.
Something else I’ve been meaning to ask, and I’m sorry if this is going off topic, when I fly inside a chunk, I can see the walls of other chunks from inside. Is it supposed to be like this? It seems like they should all be transparent:

Thanks for the support.

Eclipse is the least likely candidate for causing lighting problems. Or any 3D-related problems at all.
In fact the JME SDK is more likely to cause issues, because it’s doing 3D stuff. That would require a bug in the OpenGL driver, the SDK shouldn’t have any reason to directly interfere with the 3D aspects of the application.

The whole “chunk walls inside a chunk wall” is because chunks are localized to themselves - I believe that the regular chunk control doesn’t allow for inter-chunk checking, so it registers every block outside of the chunk’s boundaries as empty, and appropriately generates those faces.

I got around that by letting every chunk reference it’s ChunkGrid (in my code) as a parent, and when I generated the chunks, I had the ChunkGrid do all the checking, since it knew about all of the chunk data, and it removed those walls.

It did take me a while to do, especially since I had to create an appropriate method for checking stuff that regularly wouldn’t have been checked.

If I had to do it in code, it’d be something like this:

[java]

public boolean checkFace(Chunk chunk, Vector3I chunkpos, Face face) {
Vector3I blockpos = BlockGrid.toAbsoluteGridPosition(chunkpos); // This method would be either multiplying by your chunk size and taking the remainder (modulus-style) or doing the reverse, to convert the chunk-space coordinates to grid-space coordinates. I’m not quite sure how I did it, as the code’s gone.

    Block block = chunk.parent().getBlockAt(blockpos);
    if (block != null) {
            
            Block neighbor = chunk.parent().getBlockNeighbor(blockpos, face);
            if (neighbor != null) {

                    if (neighbor.isOpaque() == block.isOpaque()) return false;
            }
            return true;
    }
    return false;

}

[/java]

Something like that, anyways. Like I stated, I don’t really remember how I did it, since I deleted the code a while ago for some stupid reason. But that should be relatively close.

@toolforger said: Eclipse is the least likely candidate for causing lighting problems. Or any 3D-related problems at all. In fact the JME SDK is more likely to cause issues, because it's doing 3D stuff. That would require a bug in the OpenGL driver, the SDK shouldn't have any reason to directly interfere with the 3D aspects of the application.

Alright, thanks! I’ll keep playing around and see if I can get light working.

@Eliwood said: The whole "chunk walls inside a chunk wall" is because chunks are localized to themselves - I believe that the regular chunk control doesn't allow for inter-chunk checking, so it registers every block outside of the chunk's boundaries as empty, and appropriately generates those faces.

I got around that by letting every chunk reference it’s ChunkGrid (in my code) as a parent, and when I generated the chunks, I had the ChunkGrid do all the checking, since it knew about all of the chunk data, and it removed those walls.

It did take me a while to do, especially since I had to create an appropriate method for checking stuff that regularly wouldn’t have been checked.

If I had to do it in code, it’d be something like this:

[java]

public boolean checkFace(Chunk chunk, Vector3I chunkpos, Face face) {
Vector3I blockpos = BlockGrid.toAbsoluteGridPosition(chunkpos); // This method would be either multiplying by your chunk size and taking the remainder (modulus-style) or doing the reverse, to convert the chunk-space coordinates to grid-space coordinates. I’m not quite sure how I did it, as the code’s gone.

    Block block = chunk.parent().getBlockAt(blockpos);
    if (block != null) {
            
            Block neighbor = chunk.parent().getBlockNeighbor(blockpos, face);
            if (neighbor != null) {

                    if (neighbor.isOpaque() == block.isOpaque()) return false;
            }
            return true;
    }
    return false;

}

[/java]

Something like that, anyways. Like I stated, I don’t really remember how I did it, since I deleted the code a while ago for some stupid reason. But that should be relatively close.

Great idea, thanks! I’ll try to implement this and let you know if it works.

Did anyone make any progress on some sort of LOD with this? I have absolutely no idea how to go about it. I know @sebasoft had something going previously in the thread. Sure you can take the average 4 blocks in an area but how does that all work rendering side?

Oh and I wanted to get a greedy mesher with the framework for some performance , and I tried implementing @sleaker 's code with no avail.

Anyway, thanks for everyone’s help with this stuff! 8)

@destroflyer here’s some love =D your framework is awesome. Laid a ton of ground work for us!

10,000,000 blocks and counting. Amazing stuff. (PS yes I can unload chunks, but we like pretty screenshots =D)