April (2014) Monthly WIP Screenshot Thread

This is my first screenshot here. In fact, this is the first game really intend to finish. Even though the game might be old, I think it’s still fun and definitely a great startup project for a first game. I’m not new to programming though, I have a bachelor in computer science, and I’ve been working as a java developer for six years now. My little brother is learning blender, as he’ll be studying 3d animations next autumn. Any feedback (and critism!) will be greatly appreciated! :slight_smile:

6 Likes

Nice. Reminds me of today’s Maximumble: http://maximumble.thebookofbiff.com/2014/04/01/821-fit/ :slight_smile:

I have been playing around with the FX Builder from tonegod for lighting up my dungeons a bit. This is a still image based on 50 particles of flames from a 4x4 flames sprite sheet. It looks quite convincing. So now I have one point less to worry:

Thanx for tonegod for sharing this fx builder. It makes creating new effects (nearly) a no brainer…

11 Likes

Working on a 3D press spacebar to slash crap. The player model will be ready next week but got some npcs and trees:

5 Likes

Working on relative paths handling in Nifty-Editor :

4 Likes

Implemented Voronoi noise on the GPU and wrote a procedural crater algorithm…Here are some shots of them on a martian planet:

deep with broad rims:

deep with no rims:

shallow with no rims:

13 Likes
@okelly4408 said: Implemented Voronoi noise on the GPU and wrote a procedural crater algorithm...Here are some shots of them on a martian planet:

Wow. Very pretty. You should write something more detailed up sometime if you feel generous. :slight_smile:

@pspeed said: Wow. Very pretty. You should write something more detailed up sometime if you feel generous. :)
Oh yea definitely; I love talking about it. Just on the craters or the whole thing in general?
@okelly4408 said: Oh yea definitely; I love talking about it. Just on the craters or the whole thing in general?

“Implemented Voronoi noise on the GPU and wrote a procedural crater algorithm”

Every bit of that sounds interesting. :slight_smile: Is the noise also used to generate the craters or just the texture… is the crater generation on the CPU or GPU?

I’m always interested in noise.

@pspeed said: "Implemented Voronoi noise on the GPU and wrote a procedural crater algorithm"

Every bit of that sounds interesting. :slight_smile: Is the noise also used to generate the craters or just the texture… is the crater generation on the CPU or GPU?

I’m always interested in noise.

Well there are actually no textures in the above pictures. I’ve found that the normal maps that I generate from the height maps look so good that textures aren’t really necessary.

So the Voronoi noise (also called Worley noise I believe) is extremely simple to implement. I first generate a texture (on the CPU side of things) that contains random float values in each of the RGBA channels.
I index this table based on the vertex that is being examined (like with most texture based noise approaches. Based on the random vector returned I can look up several more points “around” the first one. The distances to these points are compared and the closest and second closest distances are returned from the algorithm.

[java]
for (int z = -1; z <= 1; z++)
{
for (int y = -1; y <= 1; y++)
{
for (int x = -1; x <= 1; x++)
{
cell = getVector(xi + x, yi + y, zi + z).xyz; //from texture
cell.x += (float(x) - xf);
cell.y += (float(y) - yf);
cell.z += (float(z) - zf);
float dist = dot(cell, cell);
if (dist < dist1) //dist1 and dist2 are two arbitrarily large values
{
dist2 = dist1;
dist1 = dist;
}
else if (dist < dist2)
{
dist2 = dist;
}
}
}
}
[/java]
Many interesting patterns can be created with the returned values but for my purposes I only care about the distance to the closest point. These distances can be illustrated as follows:

But the distances don’t really matter to me. What matters is the points around the center of each cell (the dark areas in the middle of the cell).
One can isolate these centers by using a simple smoothstep() method:

[java]
float c = smoothstep(0.1, 0.3, cellNoise);
[/java]

Which gives the following:

Simply adding this output to my regular terrain values works…but it is not the right way to do it. First of all everything BUT the craters are raised by the max height limit of the planet which makes things looks awful for thin-atmosphered planets. Second, these craters are just simply holes…there are no ridges surrounding them like you would normally see with craters.

The actual function I wrote to generate craters is as follows:
[java]
float craterNoise3D(in vec3 p, in float radius, in float slope, in float rimWidth, in float depth, in float frequency, in int octaves){
float fractal = fBm(p * frequency * 2.0, octaves) * 0.17;
float cell = cellNoise((p * frequency) + fractal ).x;
float r = radius + fractal;
float crater = smoothstep(slope, r, cell);
crater = mix(depth, crater, crater);
float rim = 1.0 - smoothstep(r, r + rimWidth, cell);
crater = rim - (1.0 - crater);

return crater * 0.125;

}
[/java]
As one can see from the above algorithm, I rely on fractional Brownian motion made with Perlin Noise to make this (Perlin noise as seen here: http://hub.jmonkeyengine.org/forum/topic/gpu-improved-perlin-noise/)

This fractal offsets the input to the cell noise, returning wavy non-uniform cells. It is also used to offset the “radius” of each crater so that they are even more non-circular.
The first instance of the crater variable does the same thing as the aforementioned smoothstep() function: isolates the holes. The center of the crater is then made negative (the variable “depth” should be set negative) so that the center part of each crater depresses the terrain. This is accomplished through simple linear interpolation: crater = mix(depth, crater, crater);
So no we have a crater with a negative center surrounded by 1.0s (see the white sphere with black holes above). To kill two birds with one stone, I creates rims or lips around each crater. This is done simply by subtracting a smoothstep of the start of the rim (the end of the crater) to the length of the rim (defined by the user) from 1.0. So this gives me a dome with the now non-existent crater in the middle. To add the crater to the dome I subtract (1.0 - the crater) from the dome. This gives me a sloping upward rim as well as an indented crater. This also ensures that all other values besides the craters are 0.0. This allows me to simply add this crater noise to my terrain. So our sphere now looks like so:

(Note the values have been scaled up so that they can be seen in a picture)

This entire process is done on the GPU in a pixel shader. The output from this pixel shader is rendered to a texture using a frame buffer. All elevation data (craters included) is stored in the red channel of the texture. The other channels are reserved for biome computation related noise.

I hope I did an OK job explaining that all. Feel free to post questions/critiques!

10 Likes
@okelly4408 said: I hope I did an OK job explaining that all. Feel free to post questions/critiques!

Yep. Probably could/should have been a separate post then you could bask in the upvotes. :slight_smile: Perhaps less likely to be found here in the long run but I appreciated it.

Procedural textures is something I play with from time to time and Voronoi noise can be used as the basis for lots of stuff.

@pspeed said: Yep. Probably could/should have been a separate post then you could bask in the upvotes. :) Perhaps less likely to be found here in the long run but I appreciated it.

Procedural textures is something I play with from time to time and Voronoi noise can be used as the basis for lots of stuff.


Yea, I will probably make a separate post to share the complete Voronoi shader…
That is true, I have dabbled with using Voronoi has a basis for my mountains. It gives surprisingly good results…probably because the cell-like nature of a Voronoi diagram is similar to the ridge/valley layout of a mountain range.

Not as exciting as mars… but I finally got my pager far enough along that I can have different paging grids depend on parent grids. Here we see a fledgling ‘grass’ layer that depends on the terrain layer. That perhaps sounds simpler than it is but keep in mind that all of these things are built on background threads, the child grid can be smaller than the parent, etc… The pager keeps track of all of that and makes sure not to build the child until the relevant parent has been built. (The wireframe boxes are for debugging the various zone sizes.)

Right now I’m just plotting a line at the triangle’s center. Lighting influenced by triangle normal (not yet surface normal) and direction slightly influenced by triangle normal.

Next is to random plot… then to add actual grass.

The real grass will fade with distance so then it will be a matter of tweaking the grid parameters until they look right.

Edit: P.S.: So far, anyway, it has no trouble keeping up with the maximum fly speed of 20 m/sec. (about 45 mph)

5 Likes

o i :smiley: Nice work guys. Keep it up. For my part, I’m still working on a procedurally generated open world environment using a lot of other people’s JME3 classes. I can honestly say it’s slow paced and man sometimes I wish there was 48 hours in a day!.. but to me, it’s worth every hour I put into it. Last week, I started making “real 3D” (multi-faced) trees and rocks (with rigidity) that the routine can now lay around (with moderation) on the terrain. Tough, most of what you see there are camera-facing billboards to speed up the fps until I balance/optimize this enough to be playable.

9 Likes

@okelly4408 that looks really nice and thanks a lot for the interesting read! =D

Following up my previous pic that had the ugly wire frame grass plots and grid lines with something nicer:

Next up… trees.

13 Likes

Wow. That looks beautiful :slight_smile: =D 8)

To both @pspeed and @.Ben.

oh, nice :slight_smile:

The grass looks really good Paul!

EDIT: Thanks @kamran :smiley:

Are the rays of the sun actually blocked by single grass leaves or is it a coincidence that it looks that way?