Terrain Generation Overhaul Guidebook

[Alphado-Jaki]

Terrain Generation Overhaul Guidebook

Ver. 0.2.0

Second pre-release edition

 

Changelog (Ver. 0.2.0):

Fixed Checkerboard and Cylinder frequency from 500 to 512.

Added manuals for almost all of module.

(excepting non-fast modules, Spheres, Voronoi, RotateInput, DisplaceInput)

 

Read on web

Download PDF

 

I write this book to summarize existing knowledge distribute in this forum.

The main purpose of this book is to encourage new modder on terrain generation, and to make good atmosphere to discuss new idea each other.

 

This book is hosted on GitHub, so anyone who has GitHub account can make change request via PullReq.

However, I'm happy to receive comment or request in this forum.

 

For this first release, I attached the whole template for existing modules.

I haven't finished writing the guide for each module, but those who wanna test can play with it.

 

I'm making an unofficial DLL fix patch featuring terrain and hub generation, so next release may come 1-2 month later.

-> Done

[xyth]

Very nice. Thanks for doing this!

[Tin]

Nice work so far!

[n2n1]

Thanks !

 

 

I'm looking for a way to increase the percentage of the "downtown zone", and change the width of the streets inside the hub. (it's hardcoded) does anyone know that now?

[Alphado-Jaki]

I'm looking for a way to increase the percentage of the "downtown zone", and change the width of the streets inside the hub. (it's hardcoded) does anyone know that now?

 

Sadly, haven't tested about that.

 

But as seeing related classes, HGSocket.TW may have effect to "downtown zone".

For width of the street, the constructer of PathSocketStreet seems to have effect.

 

Not sure, though. :I

[Tin]

Thanks !

 

 

I'm looking for a way to increase the percentage of the "downtown zone", and change the width of the streets inside the hub. (it's hardcoded) does anyone know that now?

 

Yep, it's hard coded and you cant change either at this time but I sure hope we can get control over the zoning sizes and street width at some point.

 

Or I should say none that I know of..

[Alphado-Jaki]

Okay, I confirmed this works correctly for pathradius.

I'll post instruction later (maybe the same time tomorrow?), but in short.....:

 

Open RWG2.PathGenerator.PathSocketStreet.ctor (2nd one)

Replace 10.5f into _pathRadius

[Tin]

Okay, I confirmed this works correctly for pathradius.

I'll post instruction later (maybe the same time tomorrow?), but in short.....:

 

Open RWG2.PathGenerator.PathSocketStreet.ctor (2nd one)

Replace 10.5f into _pathRadius

 

So you need to go in the nuts n bolts.. meh, not going to mess with that, just not worth it atm for me

Once TFP actually decide on everything that's when I'm going to do a thorough in depth twixery of everything.

[Alphado-Jaki]

So you need to go in the nuts n bolts.. meh, not going to mess with that, just not worth it atm for me

Once TFP actually decide on everything that's when I'm going to do a thorough in depth twixery of everything.

 

Yep. :/

This is too much effort to get the single feature working for most of modders.

And EAC need disabled is bad aspect also.

[Tin]

Yep. :/

This is too much effort to get the single feature working for most of modders.

And EAC need disabled is bad aspect also.

 

Good practice anyhow to get familiar with how they're doing things so not a total loss

[n2n1]

Open RWG2.PathGenerator.PathSocketStreet.ctor (2nd one)

Replace 10.5f into _pathRadius

Ahhh....10.5!?....i was looking for the wrong number! (for some incomprehensible reason- i believed it to be an integer...)

 

Thank You very much!

[Alphado-Jaki]

Ahhh....10.5!?....i was looking for the wrong number! (for some incomprehensible reason- i believed it to be an integer...)

 

Thank You very much!

 

That confused me also.

I'm not sure why but 2 times of path_radius seems to be used.

[StompyNZ]

So you need to go in the nuts n bolts.. meh, not going to mess with that, just not worth it atm for me

Once TFP actually decide on everything that's when I'm going to do a thorough in depth twixery of everything.

 

once sdx is ready for a17 im happy to do some patch scripts to make some unique requirements work for rwg

 

Not enough time to do any thing significant atm before a17 with my other projects on the go though

[StompyNZ]

That confused me also.

I'm not sure why but 2 times of path_radius seems to be used.

 

path radius in the xml adds to the center 1 block, so total width 21, half that for 10.5

[Alphado-Jaki]

path radius in the xml adds to the center 1 block, so total width 21, half that for 10.5

Ah, that makes sense!

 

So, correct way to fix is "replace 10.5f with _pathRadius + 0.5f".

[n2n1]

path radius in the xml adds to the center 1 block, so total width 21, half that for 10.5

Lol

 

Thanks Cap !

[Alphado-Jaki]

Updated for Ver. 0.2.0

 

Almost all of manual for module is done. (Appendix 2-4)

[n2n1]

I still can't understand what the "seed_additive"...

Will give the same result in: seed_additive="0" and no_seed="true" ?

 

 

upd:

that is, seed_additive - additional influences that have affected seedname?

then why these parameters ? (digit)

 

upd2:

previously, i assumed that the parameters indicate how much influence seedname has on the result.

ie 0 - disabled seedname influence on the result, 1 - little influence, 2 - more impact seedname on the result and so on...

Is that not right?

[Alphado-Jaki]

seed_additive is added to seedname.

For example, using "1111" as seedname and setting seed_additive="1" for a module, result that it actually use "1112" as seedname.

(Actual process encode "1111" via UNICODE or ASCII, so may not true. This example is just to understand.)

 

no_seed forces a module to output always same result, whatever the seedname is.

[Alphado-Jaki]

I've made a simple example. Following pics are from RGW previewer with NOT same seedname. But using seed_additive, we can cancel the gap of 2 seedname.

---

Case 1: Seedname=1 seed_additive=1

		<terrain_generator name="vanilla" use_old_final="false">
		<module name="ridge" type="FastRidgedMultifractal" [color="#000080"]seed_additive="1"[/color]>
			<property name="octaveCount" value="20"/>
		</module>

		<module name="scaleBiasOutput" type="ScaleBiasOutput">
			<property name="sourceModule" value="ridge"/>
			<property name="scale" value="-90"/>
			<property name="bias" value="90"/>
		</module>

		<output module="scaleBiasOutput"/>
	</terrain_generator>

 

Case 2: Seedname=2 seed_additive=0

		<terrain_generator name="vanilla" use_old_final="false">
		<module name="ridge" type="FastRidgedMultifractal" [color="#000080"]seed_additive="0"[/color]>
			<property name="octaveCount" value="20"/>
		</module>

		<module name="scaleBiasOutput" type="ScaleBiasOutput">
			<property name="sourceModule" value="ridge"/>
			<property name="scale" value="-90"/>
			<property name="bias" value="90"/>
		</module>

		<output module="scaleBiasOutput"/>
	</terrain_generator>

---

This example shows that the world seedname + seed_additive of each module is used for a seed of the module.

 

As we know, changingthe world seed, even if 1 char, results completely different world. The seed_additive for a module is same. If we change seed_additive, even if only +1, completely different module is generated.

[n2n1]

Whoa! even so?!

Now I'm more clear, thanks.

 

Yes, i now understand what it is and how it works, but anyway - very strange thing

 

 

UPD:

I wonder, when You started Your work on the study of generation - You started with a flat surface?

[Alphado-Jaki]

Whoa! even so?!

Now I'm more clear, thanks.

 

Yes, i now understand what it is and how it works, but anyway - very strange thing

I'm glad to hear that.

Keeping seed_additive unique is keeping your world generation variated.

 

I wonder, when You started Your work on the study of generation - You started with a flat surface?

Yes. At first, what I know is only from rwgmixer.xml and the RGMIXER.XML EDIT thread. I hadn't know this kind of thing at all, when A15.1 was drop.

 

Last year, my modding activity was only about generation. Researching via internet & books and experimenting my ideas. But, I've never felt it painful, it is much fun for me. =D

[n2n1]

Yes. At first, what I know is only from rwgmixer.xml and the RGMIXER.XML EDIT thread. I hadn't know this kind of thing at all, when A15.1 was drop.

 

Last year, my modding activity was only about generation. Researching via internet & books and experimenting my ideas. But, I've never felt it painful, it is much fun for me. =D

 

Oh Yes, i understand what you're talking about

Just, a generator with its wave structure - is very interesting and will fully attract all the attention - i understand it... . I noticed that You for some time disappeared from the forum

[Alphado-Jaki]

I noticed that You for some time disappeared from the forum

As that thread has no conversation, I started my work by myself.

 

 

BTW, about "lacunarity". It works nicely with FastNoise and FastBillow. But if I use with FastRidgedMultifractal, it behave pretty weirdly.

 

For FastNoise, "lacunarity" changes output slightly. But for FastRidgedMultifractal, "lacunarity" seems not to refer its number, it's just refering whether "lacunarity" is set or not.

[Alphado-Jaki]

lacunarity is working on A17.

For those who wanna see effect of lacunarity, see this.