Posted: Sat Aug 04, 2007 10:00 am Post subject:
otsmapgen testing
Subject description: forum discussing how to create certain types of terrain using otsmapgen
As you may have been aware, I, Equiredox, have been creating otsmapgen. The map generator may seem limiting, and simple, but given time to play around with it, and understand its workings, it proves somewhat powerful.
To operate this terrain generator, involves supplying a set of basic algorithms, that when 'superimposed' upon each other, form different styles and feels of terrain which can vary radically in behavior. Basically, otsmapgen works by allowing the user to input a list of in-built algorithms (in order) which are to be applied to a surface. Each of these algorithms is "behavior independent" (they each do their own thing which cannot be reproduced by combinations of the other algorithms - think of "linear independence" of a set of vectors but in terms of algorithms and how they affect the terrain). Also the order of the algorithms which are applied matters (not commutative). So there are a lot of different solutions you can get providing on what parameters you supply – and their orders.
I need some people to play around with otsmapgen, using different lists of algorithms and parameters, to try to come up with some funky styles of terrain. The objective is to produce a list of known inputs which create cool and different types of terrain. If you find some inputs which form interesting results, post the details here. People who discover different types of terrain, will be credited to helping with the development of otsmapgen.
I have attached a rar archive file which contains a complied version of otsmapgen v1 beta - for use, and four sample terrain outputs I recently obtained - to show how changing the parameters can vary the behaviour. These are a small set of possible solutions. For usage details of otsmapgen, just run otsmapgen.exe without any args in command prompt, and brief usage details will appear.
In previous cases, I stated that otsmapgen will include the use of a fractal algorithm - however, it had not been implemented yet, and isn't seen as a compulsory "feature / function / requirement" at this stage. Also, I did program a feature that sped up otsmapgen by changing the size of the drawing surface to suit the destination heightmap size - however, it became apparent that if you used the same set of parameters / args on different heightmap sizes, they differed in nature and behaviour because the size of the drawing surface was changed. So that feature was exluded - and no matter the heightmap size, it will draw to a 1024 x 1024 surface then condense it down after the heightmap is generated.
-------------------------------------------------------
EDIT:
-------------------------------------------------------
An optimised version of otsmapgen V1.0B can be download here: http://www.ppmsite.com/forum/download.php?id=17179
Which produces terrain much faster then the standard V1.0B
It is a command-line / console application - so it needs to be run via command prompt. By default in windows - if you run it by double clicking on it, windows will show the console until the app exits, which I assume is that "flash" you discuss.
To overcome this run otsmapgen via command prompt directly.
Goto Start->Run
Type "cmd"
Hit enter
Now run the application via command prompt directly.
it's a command-line utility _________________ Micro TS
Portable, no campaign, movies or music, just the engine and needed resources for skirmish and lan. QUICK_EDIT
It is only a beta and fairly unoptimised. As an example, if you have my source (in the main topic forum), look at how it draws and compares values against a straight line for fault algorithm generation, total utter crap in terms of optimisation. For every pixel it recalculates the line, and there is a lot of wasted time. I could easily make this run 50x faster - seriously. What about my filter / blur algorithm? - it recalulates tonnes of redudant values for every pixel it processes!
However, "speed" wasn't a primary requirement of these early stages, it came secondary to the quality of the maps it generated - and given my limited time (have to share it with many things) I am trying to focus on the major features first.
Since people keep bringing it up though, I think I will start to look over my code and optimise it.
------------------------------------------------------------------
EDIT:
------------------------------------------------------------------
Anyway, here is the optimised executable running
around 50x faster. It produces the maps in seconds (seriously).
The terrain that took 4-5 minutes to generate, is now taking 5-20 seconds.
otsmapgen_v1beta_binary_optimised_version.rar
Description:
V1.0 Beta optimised - runs ~50x faster then previous releases
Joined: 08 Jul 2006 Location: in your closet... Post = true
Posted: Tue Aug 07, 2007 7:30 pm Post subject:
Not bad - try to aim for some "characteristic" for your maps. Bottlenecks, cliffs, having a map not just with "ups" and "downs" in a different height.
though I guess youre already moving towards that - but you asked _________________ audiopulse sagt:
your raging arse is creating storms?
Luke | CCHyper sagt:
yup, neptune size! QUICK_EDIT
Not bad - try to aim for some "characteristic" for your maps. Bottlenecks, cliffs, having a map not just with "ups" and "downs" in a different height.
though I guess youre already moving towards that - but you asked
Thanks for your input. I got a free moment to try out some new input parameters. I used a negative value for the canyon depth flag and got some interesting results. Otsmapgen doesn't currently check for "accessibility" of the map - so it doesn't make 'ramps' that allow access to certain levels / parts of the terrain as of yet.
I have attached the args needed to produce the terrain in this testset. However - be aware that the optimised beta version has issues with its 'filter' feature and doesn't work sometimes if the filter length is less then 50 pixels. As a result - I have used the "slow" version of otsmapgen to produce these results until I have time to correctly go over and fix the optimised filter algorithm - which should be soon.
Joined: 08 Jul 2006 Location: in your closet... Post = true
Posted: Thu Aug 09, 2007 8:54 pm Post subject:
these ones DO look interesting. The one down at the second row at the right would be almost usable. _________________ audiopulse sagt:
your raging arse is creating storms?
Luke | CCHyper sagt:
yup, neptune size! QUICK_EDIT
typedef unsigned int UINT16; // unsigned int
typedef unsigned long UINT32; // unsigned long
typedef unsigned char UCHAR; // unsigned char (byte)
The naming scheme refers to ANSI C minimum acceptable values. According to "The C Programming Language by Brian Kernighan and Dennis Ritchie" - in the standards section, the minimum length of int is 16 bits, however it can be 32 bits or greater depending on the compiler etc. I just named it such that "16" represents, that at the least, it is 16 bits.
Also, I tend to do alot of PIC programming, like in CC5X - where an "int" would represent 2 bytes - so I am just use to it.
Quote:
also please don't use C99 standart, not all compilers support it.
Yeah, I know. I am going to brush it up, and actually try to keep to more supported standards. This is just a hobby I do in my free time, and a work in progress, so to speak. But I agree with you totally. QUICK_EDIT
Why don't you typedef ints from stdint.h?
You have both exact size ints and fastest,probably exact size ints there. _________________ Time will tell...
Sooner or later...
Time will tell... QUICK_EDIT
Why don't you typedef ints from stdint.h?
You have both exact size ints and fastest,probably exact size ints there.
I have just been taking into account the C89 standard libraries (no stdint.h there - C99 thing) - even though I haven't been following the standard entirely, I do plan to conform to that spec (C89) later on - like moving all the variable declarations to the beginning of a function etc. QUICK_EDIT
Here are some current sample images taken directly from the GUI program. I note that perhaps around 1 of 3, or even 1 of 2 maps generated looks crap, but you can get some nice ones inbetween - which require just a bit of tweaking to make them playable. Also, upon further testing, using the app during 10am - 10:59am generates the same map it seems - something wrong with the random seed - need to look into it.
Joined: 08 Jul 2006 Location: in your closet... Post = true
Posted: Mon Aug 20, 2007 7:41 pm Post subject:
I suggest keeping the maps for around 20 years somewhere at a dark cellar to have them riping xD _________________ audiopulse sagt:
your raging arse is creating storms?
Luke | CCHyper sagt:
yup, neptune size! QUICK_EDIT
I suggest keeping the maps for around 20 years somewhere at a dark cellar to have them riping xD
They do look a 'little' bit green, lol. The colour is just used as a distinction between heights. This colour seemed to make it the easiest to use / visualise.
OTSMAPGEN Summary / Conclusion:
This is probably as far as I will go with otsmapgen - knowing Judeau is writing some pretty spiffy software atm for ots which should blow this thing away. But, it hasn't gone to waste as it may provide a good sample demonstration to my 'software portfolio' to prove I can write in C, use Direct X and spawn child processes in .NET when it comes time for work experience (but needs a bit of cleaning up still).
But then again, what do you expect out of 1.5hrs work a week on it as a hobby? In terms of quality vs. time spent - I think it went reasonable - but still requires some work (is there such a thing as a finished software product?). As a lesson, I should whip out the P.S.P. and try to learn from how I tackled this problem.
I also think, this proves that in iterative software development processes, and in the case of agile development, getting prompt customer feedback and product testing (both in functionality and acceptance) proved very useful in determining the direction and stage of this product (as a form of software measurement/completeness). This otsmapgen project heavily relied on a test driven software development model, and since you can't write a program to evaluate how good terrain is easily - the testing took the form of customer feedback (which is why there was a lot of stuff released in increments).
Anyways, thanks guys for your input. I have seen some of Judeau's work - and it is really good. But I don't want to leak any info Judeau wants to keep secret atm. QUICK_EDIT
Also Known As: banshee_revora (Steam) Joined: 15 Aug 2002 Location: Brazil
Posted: Mon Aug 27, 2007 2:17 am Post subject:
I haven't visited this topic for a while, so sorry for the bump. Anyway, as far as I could look at these height maps, most of them lack a space for 'buildable bases'. I think you could make a post processing procedure to add spaces that could qualify as candidates for buildable bases and maybe expansion bases. Remember that the final objective is to get height maps for a playable RTS engine. QUICK_EDIT
I don't think RMG should be taken so important. It will help mappers to start, but the best maps will still be made from scratch. _________________ Time will tell...
Sooner or later...
Time will tell... 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
otsmapgen testing
