Replacement for /perlin

by Sparr on 05/08/2005 07:43, 14 messages, last message: 05/11/2005 17:26, 3056 views, last view: 05/05/2024 04:00

I was disappointed with the performance of /perlin so I found a more pleasing implementation and borrowed it. The GPL'd terrain generation software Terraform has a very nice generator, and it was rather easy to port. I really only wrote about 10 lines of code that actually made it into the working version, although many more were spent on testing.

The required files can be found here:
http://sparr.homeip.net/newperlin/

rndmap.cpp is the only cube file that has been modified here, with the original perlin implementation (which would appear to be of http://freespace.virgin.net/hugo.elias/models/m_perlin.htm) replaced with an include of the Terraform perlin and random number source files (include to avoid having to add them to the makefile). I also removed the check for vdelta>128 because it seems the game can render vdelta up to 255.

You will also need to modify your Makefile to indicate the include path for glib (-I/usr/lib/glib/include for me) in your CXXFLAGS and to link to the math and glib libraries (-lm -lglib) in your CLIENT_LIBS.

On to usage... The syntax of /perlin has not changed (to avoid modifying more source files), however the meanings of the parameters have. The first parameter scales the landscape down in the X and Y directions, resulting in narrower hills and steeper inclines. The second parameter indicates the random seed, change this if you dont like the layout of the hills and valleys. The third parameter scales the landscape down in the Z direction, resulting in shorter hills and less steep inclines. If the third parameter is lower than the first parameter then you will see unclimbable hills begin to appear.

   Board Index   

#1: Picture, plans

by Sparr on 05/08/2005 08:28

Obviously the picture is not required for compilation, simply a quickly generated example of how the new hills look.

I would like to work on expanding on the function to allow it to produce less predictable patterns, with a few high peaks and low valleys among all the average size hills.

Another nice feature would be to have the edges adjusted to match the height of existing adjacent terrain (then again, that would be nice with slopes and arches too).

Also, please note, height fields of this magnitude are not for the hardware-ly challenged. A 256x256 map filled with a heightfield like this produces a wqd on the order of 30000. Small heightfields are suggested, as well as generous placement of occluding structures.

reply to this message

#2: ..

by staffy2005 on 05/08/2005 14:08

http://sparr.homeip.net/newperlin/terraintest.png

looks cool. :)

reply to this message

#3: ..

by BonX on 05/08/2005 14:27

what is perlin ?

reply to this message

#4: Question?

by jean pierre on 05/08/2005 15:54

Same question as BonX

reply to this message

#5: what is perlin?

by Sparr on 05/08/2005 16:17

perlin is the command in the map editing mode to generate random terrain (hills and valleys in a heightmap)

reply to this message

#6: ..

by jean pierre on 05/08/2005 17:09

Did you made it yourself?

reply to this message

#7: Re: ..

by >driAn<. on 05/08/2005 17:18, refers to #6

jean pierre:
"The GPL'd terrain generation software Terraform has a very nice generator, and it was rather easy to port."

reply to this message

#8: origin

by Sparr on 05/08/2005 17:25

No, I did not make it myself. The code for the generator is from the program Terraform. I just wrote the code to interface Cube's perlin function with Terraform's perlin functions.

Also, one thing to note, Terraform includes other terrain generators than perlin. Some of them produce more dynamic terrain. I shall investigate integrating more of them as I move along on this mini-project.

reply to this message

#9: Re: ..

by tentus on 05/10/2005 04:39, refers to #2

nice. could you go into editing mode and hit showmip and get us another screenshot? my time and connection speed are extrememly limited right now, so i want to be sure this is worthwhile :) but the wqd doesn't look that bad, considering. give it some buildings and other occluders and it oughta be playable.

reply to this message

#10: showmip

by Sparr on 05/10/2005 05:04

here is a 256x256 map completely perlin-ized, with 8-thick walls surrounding the center 1/9th of the map.

outside the walls, high wqd:
http://sparr.homeip.net/newperlin/terraintest_showmip1.png

inside the walls, "low" wqd:
http://sparr.homeip.net/newperlin/terraintest_showmip2.png

as you can see, the game does its best to find 2*X and 4*X areas to combine into single planes, there just arent that many. you end up generating pretty much exactly as many cubes as you select, minus a few.

I perlin'd the default visible area of a 64x64 map (48x48) and ended up with 2283 cubes (wqd from outside a corner of the map with occlusion turned off). That is a tad shy of the 48*48+6*4=2328 (wow, numerical anagram!) cubes that a completely subdivided map would be, but not by much.

If you are going to make large outdoor maps, I seriously suggest *NOT* perlin'ing the entire map. It is simply impossible to occlude enough of it to get the wqd down to a respectable level. However, I think this will be very useful for small outdoor sections, the bottoms of water pools, etc.

reply to this message

#11: Faulting

by Sparr on 05/10/2005 19:34

I have added the faulting generator as well. This one took a bit more code, youll notice that there are a lot more files that have changed. Also, I moved the terraform code into its own directory to make sure they stayed seperate. Most of the terraform files are intact, however a few have been modified slightly, and one ripped apart, to eliminate as many GTK gui quirks as possible. However, GTK dependencies remain so I had to add that to the makefile includes list as well :( Hopefully in the end I will be able to eliminate that, but for now it stays.

Usage:

/fault method iterations iterscale vertscale seed cycles

method: 0-5, determines the faulting method, see below
iterations: number of faults to create
iterscale: 2-inf, determines scaling as the iterations progress. higher numbers tend to lead to more uniform terrain with less 'unique' features
vertscale: scales down the Z axis, higher number makes flatter terrain
seed: small problem here, the generator makes up a new seed even if you pick the same one. ill fix that eventually.
cycles: how many times to run the algorithm in the case of the squares and particle methods

Methods:
0 = line. faults are arbitrary lines, one side of the line is raised and the other is lowered.
1 = sin line. same as 0, but faults are smoothed with a sin curve
2 = cos line. like 0, but a trench is dug along the line
3 = circles. not very useful, haven't quite figured out the scaling on this one
4 = squares. digs square holes in the landscape, with successive squares overlapping. good for putting arbitrary 'potholes] in an otherwise flat landscape if you tweak the parameters right
5 = particles. very random. again, need to figure out the appropriate scales.

I find that method 1 and 2 generate the best terrain overall, with 4 being good for small abnormalities in flat terrain.

reply to this message

#12: Re: ..

by D.plomat on 05/11/2005 13:32, refers to #9

When using perlin and showmip it looks like the surfaces are grouped in small "bands". Maybe adding an option to try to keep the same angle 2 by 2 adjacent cubes could allow the mipmapper to use bands of 2 cubes width and possibly divide the wqd?

I don't really understand how does it groups those in lines, as they don't have the same angle they're different polygons. Or do this applies only to texture mapping?
Will give a try at reading showmip related code but i've nearly 0 knowledge on OpenGL rendering.

reply to this message

#13: Re: ..

by Sparr on 05/11/2005 17:25, refers to #12

I think that is just a bug in the mip display, it shows 1xN lines across a heightfield no matter how badly mismatched the angles are. However, the 2xN blocks displayed are chosen correctly, and are coplanar as expected. Grouping into twos could cut the wqd in half, however it would also produce less smooth terrain by more so than you would expect, because all corner heights would have to be divisible by two or four to ensure that the 'middle' vertices had integer heights.

reply to this message

#14: half?

by Sparr on 05/11/2005 17:26

did i say half? i meant quarter. my bad.

reply to this message

   Board Index