Posted: Sun Jul 15, 2007 5:57 pm Post subject:
A couple programs I just made.
So, inspired by Equiredox's heightmap generator for OTS, I decided I would try and see what it would take to make a decent one. So far, it hasn't gone great.
My first thought was perlin noise, but that notion soon fell flat on its face. Then I remembered that some time ago I had written a piece of code in PHP that generated a neat colourful image, so I then set out to recreate that in VB. It was actually surprisingly easy to do, as I just had to translate it line by line, which was no challenge. There were of course a couple setbacks. VB has nothing nearly so powerful as GD2 readily available to it, so I had to write all the image manipulation code. I then decided to take that one step further and make blur parameter. I spent a couple hours on that, first seeing if there was any information online and, not finding any, winging it. I started out creating a simple bilinear blur, but I soon decided I wanted something nicer, something that didn't stick out so much at the edges. Plus I knew it would come in handy with the terrain generation.
Attached under the name NoiseGen is the fruit of my labours (so far) in the area of converting my PHP script to VB code, and a screenshot of it. Its great for making cool wallpapers, but that's about it, You will see if you run it however, that it would be useless for terrain, since, because I draw each pixel based on the already drawn pixels, lines form. It ends up looking a lot like the Fibers filter in Photoshop, albeit way cooler since its not monochromatic.
Back to the business of terrain... I had looked up perlin noise, as I said earlier, and ultimately decided that if my terrain was going to look half good it would have to use a similar (Although much, much simpler) principle. Basically, I decided to arrange a grid of nodes, and each would emanate the colour that is assigned to it. I though that would work just fine, and that it would be perfectly simple to implement. For the most part, I was right. I have implemented the entire concept fully, except for the small detail of how the nodes emanate. The result, though, is much better than I think I would have achieved otherwise.
Attached is the terrain generation program identified as TerGen, and a couple screenshots of it.
Note that neither of these programs are really done, and they both contain controls that don't do anything yet.
In NoiseGen, I've disabled Colourise until I can get it working better than it has been...
In TerGen, Diversity and Levels do nothing yet.
Also, the screenshots were taken in the IDE, the compiled programs are much faster (More than twice as fast, in fact)
Please tell me what you think of them, what's good about them, what sucks about them!
Oh well, I've been working more on TerGen, and I've decided to generate the terrain the way I'd originally planned, so it's no longer all weird like in the last version. Additionally, this means that blurring is needed less, or not at all, since what it generates is naturally smooth.
I've implemented levels, but right now the edges are sharp, so blurring is required. If you add a bit of noise (Another new feature), then you can get very realistic ridges along the edges of the levels, as shown in the attached screenshot. This is in part thanks to my new blurring technique. Although it looks better than before, it is slightly slower.
I've attached the new version of TerGen, and hope you try it out.
Oh yeah, and as for the really long generation time shown, that is due to a large blur and the fact that it was running in the IDE. Normally, generation is done in around 10 seconds.
it certainly looks interesting, what algorithms are you using ? _________________ Micro TS
Portable, no campaign, movies or music, just the engine and needed resources for skirmish and lan. QUICK_EDIT
Nothing fancy, all homemade stuff (except for a new linear blur that doesn't work properly anyways), just a nodes system for initial colouration and a fake gaussian blur I came up with... _________________ QUICK_EDIT
The major downfall with otsmapgen is the complexity of the algorithms it uses, which generally take O(n^2) time or in some cases worse then that. However (in the BETA version - released yesterday) I made it a bit faster - same complexity though- , and it seems to output useful terrain.
I would be interested in viewing your source code / algorithms. QUICK_EDIT
Well, I've attached the source as well as a new binary, as this now includes the much faster blur (Almost instant).
I have to warn you though, I did a lot of stuff really stupidly in favour of writing the code quickly. I plan to fix this sort of stuff up as I go along...
Oh, and its completely uncommented.
I'd appreciate it if you could help me figure out the fast blur, I didn't write it and so I don't know why it keeps messing up.
I'd appreciate it if you could help me figure out the fast blur, I didn't write it and so I don't know why it keeps messing up.
I will have a look at your code when I have some free time - which should hopefully be soon.
Typically, one fast algorithm I am aware of involves taking an average of a square boundry (of constant size) about particular point (the point being at the centre of the square) and setting the point as the average height of the all the pixels in the square. otsmapgen doesn't have a constant size boundry - it allows for variation - but the effects it creates are probably not worth the time cost.
If the side of this square is of constant size, when you move from pixel to pixel (going from left to right) across a row, instead of recalculating everything (adding up all the heights of the pixels in the square), subtract all the heights of the left most column of pixels from the current square's total height value and add the heights of the column of pixels just infront of the rightmost column of pixels in the square to the square's total height value. Then set the centre pixel's height as (square total height) / (side ^ 2).
This finds a proper average and is a per pixel operation - so it won't be the fastest, there are many "hacks" which get good blur effects by approximation. In terms of speed (which I assume you are already using) use GDI/+ and take advantage of special cpu features for fast calculations. You may get away with calculating the surface, then to blur it, redraw the image upon itself several times with some transparency positioned to the left, right, up and down (may need to increase the transparency with the displacement distance from the centre of the image), which will be much faster then a per pixel operation if you use GDI to draw it for you. QUICK_EDIT
The linear blur is just adapted from the last blur algorithm shown here. It should simply average the pixels horizontally within the radius of one pixel, and from then on and and subtract from each side as necessary. It does this for each row, and then the image is rotated and it does it again, before rotating it back.
I'm not using GDI+, I am storing the image in a byte array with GetBitmapBits, so it should be quite fast as is. Unfortunately, I do use a slower method for actually drawing on the preview, which I will likely change when I have some time to do so. _________________ QUICK_EDIT
I've made quite a few changes to the terrain generation program, including a new, more robust interface. I'm also getting ready to add brushes for deforming the terrain, and more cool things.
Since my printscreen key is not working, I've just included a saved image from it demonstrating the (now fixed) box blur. Unfortunately I am now using a slightly slower technique for the box blur, and a much quicker technique for the "gaussian blur", resulting in it being only unnoticably slower. Both still have problems that I plan to address in the future, but they're both pretty nifty even now.
I've once again included a runtime and the source code.
I've attached a new version of TerGen.
It now includes Raise, Lower, and Flatten brushes. I am working on adding 'Stamp' support (Basically a brush made out of an image and a mask).
All filters now work, except for Reduce Noise. There is currently a bug in the Gaussian Blur, but I'm not really sure how to fix it.
Oh yeah, and I'm not really sure about sizes other than 512x512. I know smaller sizes definitely won't work, but I haven't tested larger sizes since I added brushes, and don't really know if they work properly.
Oh yeah, and the zip with the source code now also includes the images I used.
I only picked up a bit of programming (VB, C#, C++) but you have got a brain on you mate, keep it up _________________ Soader, Drum N Bass!!!! QUICK_EDIT
Looking very nice. Should market it as a freeware graphics editor because it is looking like one and probably get a larger market.
However, why did you decide to use VB6? It is much slower and much more limited then VB.NET and released around a decade ago (1998). I remember using VB 6.0 back in an intro high school programming subject 4 yrs ago and had to make a connect 4 game using direct X:
http://www.megaupload.com/?d=BMI85V3X
And even then it was classed as 'old'.
I personally wouldn't recommend VB in a "real" programming job other then for rapid prototyping or business apps (it was a mistake to use it for OpenSun - but as stated, my major premise for using it was due to its simplicity and rapid app dev properties).
However, if I had to use VB, I would use VB.NET because it will make your life 100x easier then using VB 6.0 for graphics programming, given that it is sortof a ripoff of Java (in a sense of the 'imports' statement) which makes accessing drawing / filesystem / control features simple and no need to really declare external functions from system dlls which VB 6.0 brings about. Also .NET is somewhat portable - compared to the COM approach VB 6.0 uses.
I know, I know, VB6 is just plain bad, its true.
The problem is, its the language I've done the most graphics work in. I may try to port this over to C# or VB.NET, but with VB6 its just really easy to get a lot of code done fast, and that's what I've done. _________________ QUICK_EDIT
Here are a couple 3D renders of a terrain made and edited entirely in TerGen.
Its really easy to see how well this translates into a map for a game, and the flat surfaces would really help with pathfinding.
Also attached is the heightmap and colourmap I used for the render*.
*Actually, the original texture was entirely procedural, this is a baked version of it.
Here are a couple 3D renders of a terrain made and edited entirely in TerGen.
Its really easy to see how well this translates into a map for a game, and the flat surfaces would really help with pathfinding.
Also attached is the heightmap and colourmap I used for the render*.
*Actually, the original texture was entirely procedural, this is a baked version of it.
i like, also, don't worry much about texgen, the OTS map editor will handle that for you _________________ Micro TS
Portable, no campaign, movies or music, just the engine and needed resources for skirmish and lan. QUICK_EDIT
Make sure you finish it though, it can come in handy for many things.
I would still do texgen personally, but probably focus your product towards being a generic solution for all 3D strategy games, rather then just ots levels (which I am not saying you were... just saying).
Joined: 14 Feb 2006 Location: Flying into hostile territory
Posted: Fri Aug 10, 2007 1:33 pm Post subject:
very nice. I have an idea for pathfinding Have it o that the AI finds as many attack and defense paths as possible instead of having to define them yourself like you have to do in zh and tw _________________ QUICK_EDIT
You cannot post new topics in this forum You cannot reply to topics in this forum You cannot edit your posts in this forum You cannot delete your posts in this forum You cannot vote in polls in this forum You cannot attach files in this forum You can download files in this forum
A couple programs I just made.
I'll seriously make a background on Noise Maker. 
I agree with Crashking, this is BG tools 
