Jump to content
  • Advertisement
  • entries
  • comments
  • views

Now With Splash Screen...

Sign in to follow this  


Hi! I'm going to talk of what I've progressed so far, blurring, rivers, some infrastructure for tool switching and a little splash screen biggrin.png

[font='comic sans ms']Now With Splash Screen[/font]

In my last entry I talked about how the new GUI was going, had ridges up and running, plus the binding from the UI parameters to the actual terrain parameters.

Now I will talk on what I've progressed so far, blurring, rivers, some infrastructure for tool switching and a little splash screen biggrin.png

[font='comic sans ms']Splashin'[/font]


Pretty sweet splash image right? Well no, but you get the idea tongue.png The circle thing actually draws each piece one by one to complete the full circle again and again until the main window is loaded, like every cool loading circle thingy that is so cool these days.

Main thread creates a SplashThread that does the splash frame instancing and drawing, while the Swing Event Queue executes the runnable that instantiates the main window, passing to it the SplashThread. Once the main window is instantiated (not visible yet), the runnable signals the stop to the SplashThread, which closes the splash frame and the main window gets set as visible.

This one is made out of an AWT Frame and an AWT Label, I choose those since they take slightly less to load up, and since the splash screen is the first thing that you should see, it should load fast.

I discovered that Java has an actual API to do these splash screens, loads up a .gif/jpg/etc even before the VM that executes your .jar starts, but I haven't used that, I'll will in the future.

[font='comic sans ms']And there was rivers[/font]

I got river generation working! Yay! That means that I grabbed the old river generator and made a new one that functioned better with "one at a time" river generation.

River generation is in the same precarious state as before, they can hang the whole program since the condition for them to finis his to reach 0.0f height, and since they don't write their heights modifiers until they're finished, they can get stuck and hang everything.

I added parametric "turbulence" so you can actually say how much your rivers randomly vary in direction in spite of the landscape.

[font='comic sans ms']Debug view[/font]


Prolly the most useful feature is the "DebugImagePanel". For displaying the heightmap I had a class that inherited from JPanel but draw itself from a BufferedImage.

Bad thing is that height values are only one part of the whole thing, there is also the state map, direction map, and I could make use of an non colored heightmap view.

So I implemented the debug panel that can draw four images on itself, thus allowing me to view when exactly everything changes (because I can't remember all the stuff I did, when or where).

Upper left is raw heightmap, upper right is a colored heightmap, lower right is the state map (white is NULL, blue RIVER, brown RIDGE) and lower left is the direction map, which is used so the river particles know where to go at each position.

There is no "strength" for the river direction, that means that all height differences are equal. I could probably work out some "direction strength" coefficient so the directions aren't as plain.

[font='comic sans ms']

Tool madness


Now, the issue I'm having right now is that I need to come up with some abstraction for the tools. See, when you switch from ridge to river, there is a bunch of state changes that go around.

You have to grab the blur bean, blur the selected map with its parameters, generate the direction map, and let the user draw what they want. But what happens if the user goes back to ridge tool? Then you have to discard blurred heights, re initializing all heights to 0 and re write the existing ridges to the map.

Worse, what happens if you undo a river? You have to zero everything, write ridges, blur them, create the direction map then draw the rivers again. Madness!

I have to come up with some abstraction for what it is a tool, besides the Listeners and parameter JPanels they use.

[font='comic sans ms']Moar dependencies[/font]

The only good thing of all of that is that by chance the way I designed the generators lends itself to the undoing of particles. I just have to grab the particle collection, remove the last one, and that's it. Particles contain every position they touch so by deleting particles I delete all their effects. That doesn't means that they're removed from the heightmap, generators receive a map as a parameter so they cant grab a map and undo their changes.

Moreover, if only the generators know what changes are going to be made (river carving, position state, etc), how are they going to back up what they did? They can't know every single map they have touched.

My idea is to create some sort of undo system that grabs a generator, a map and saves up every single thing that could be touched. I don't want to couple generators or maps with undo actions since they're pretty much an GUI tool.

[font='comic sans ms']El Fin[/font]

So that's it for now, I'll see what can I do about the tools and undo operations, bye! biggrin.png
Sign in to follow this  


Recommended Comments

Can you share the source code? I want to know how you got erosion etc. to build into my own terrain engine.

Share this comment

Link to comment

Sorry, not right now, I'll see what I'll do with the sources once I'm finished.


Besides, I don't have any erosion going on :D The rivers as they are are really really crappy, they just follow whatever next point is lower.


Here is the loop that makes them go around http://pastebin.com/bU74Fz9K


map.heightMap holds height values, map.directionMap holds the unit direction vectors that point to the lowest point around that cell.

Share this comment

Link to comment

I am also working on my own terrain and was recently thinking about if and how to generate rivers. My idea is inspired by nature and how rivers naturally form. Here are a few notes from my observations:

1. "Rivers", "Creeks", and "Streams" should not really be distinct from each other. The terminology all represents the same thing: Water flowing down hill, but the terminology is only concerned with the volume of water flow.
2. Therefore, all we're really concerned with is water flowing down hills.
3. downhill water flows are generated by rain which has eventually converged into a local valley.
4. Water will always flow down if its on a non-flat surface.
5. If a water flow enters into a basin, it will fill up that basin and form a "lake". This standing body of water will see its water level rise until some point on the shore crests. This is where the water flow resumes flowing downwards.
6. Water flows carve out a bit of a channel in the terrain due to erosion. This helps define and refine future water channels.
7. Most water eventually flows out into the ocean.

This kind of points towards the algorithm I have in mind. During the terrain "creation" period, you'd have a "water and erosion" generation step. In this step, you would evenly place tiny little balls at a very high elevation and let them fall onto the existing terrain. When the balls intersect with the terrain, you'd find the downward slope for that spot and roll the ball down along that slope. As you're rolling the ball down the slope, you're also tracking its path along the terrain. Eventually, the balls will start to converge into channels, which will be your rivers. I suppose you could have some sort of threshold value for the number of paths required before something becomes a stream or river, but that'd be something to tweak/play test. In the same time, you could also divit the terrain a little bit along each path to generate some erosive water effects. Run a few rain cycles like this and you'll have some nicely defined rivers and lakes :)

Of course, easier said than done, and it may be computationally expensive... but if you compute it as a part of the height map generation instead of during load time, you only have to compute it once instead of every time you load the terrain.

Share this comment

Link to comment

Ohh I completely forgot to link you something.


That's usually how water erosion it's done as far as I've seen. This is one of the papers I've found when I started this project: [url=http://oddlabs.com/jo/terrain/An%20Erosion%20Model%20Based%20on%20Velocity%20Fields%20for%20the%20Visual%20Simulation%20of%20Mountain%20Scenery.pdf]Erosion Model Based on Velocity Fields, Chiba et al.[/url]


This one is a little bit more complex, since it calculates the "energy" of the impact with the height field.


I've seen other approachs, like, make a heightmap, set an ocean level, then from random high points calculate shortest path to the coast, and there define a river.


On the computational side, I never meant any of this to be real-time anyway :D

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.

GameDev.net is your game development community. Create an account for your GameDev Portfolio and participate in the largest developer community in the games industry.

Sign me up!