Friday Facts #112 - Better noise

Regular reports on Factorio development.
kovarex
Factorio Staff
Factorio Staff
Posts: 8053
Joined: Wed Feb 06, 2013 12:00 am
Contact:

Re: Friday Facts #112 - Better noise

Post by kovarex »

cpy wrote:
cube wrote:Guys, do you know that the whole noise thing is supposed to be only performance improvement? At this stage, at least.
Meh, just thread world generator more and we'll have faster stuff. :)
Like why all passes have to run in 1 core? Can't they just make 1 core prepare 1 part then 2nd core process it while 1st core is preparing new and with all 4 world generation passes it could be sequenced a bit faster? If you also throw in that new faster algorithm, it should be insanely fast?
Isn't it better to make it 10 times faster on one core, than having to use more cores for it?

aka13
Filter Inserter
Filter Inserter
Posts: 282
Joined: Sun Sep 29, 2013 1:18 pm
Contact:

Re: Friday Facts #112 - Better noise

Post by aka13 »

Easier, but not necessary better.

Since the new intel leak for the k-Series with 10 cores and 20 threads, I think multicore has a brighter future.
Pony/Furfag avatar? Opinion discarded.

User avatar
TuckJohn
Filter Inserter
Filter Inserter
Posts: 335
Joined: Sat Jul 04, 2015 4:11 pm
Contact:

Re: Friday Facts #112 - Better noise

Post by TuckJohn »

I really like the longer post- I would love to see more FFF like it.
~1200+ hours clocked in factorio. Avid KSP and Factorio player

kovarex
Factorio Staff
Factorio Staff
Posts: 8053
Joined: Wed Feb 06, 2013 12:00 am
Contact:

Re: Friday Facts #112 - Better noise

Post by kovarex »

aka13 wrote:Easier, but not necessary better.

Since the new intel leak for the k-Series with 10 cores and 20 threads, I think multicore has a brighter future.
No, it is really better to make the algorithm faster on one core, when it is possible, other cores can always be used for other things, the power consumption is lower and it always can be multithreaded but only as a last resort, and would be more effective anyway.

aka13
Filter Inserter
Filter Inserter
Posts: 282
Joined: Sun Sep 29, 2013 1:18 pm
Contact:

Re: Friday Facts #112 - Better noise

Post by aka13 »

From my humble experience, projects which were not built ground-up with multithreaded support from the beginning tend to never end up having proper multithreading, simply because of the expenses and complexity of the said task after most of the project is complete. But I have no large field experience with that, so not arguing with you.
Pony/Furfag avatar? Opinion discarded.

User avatar
Tev
Fast Inserter
Fast Inserter
Posts: 148
Joined: Sun Aug 02, 2015 7:42 pm
Contact:

Re: Friday Facts #112 - Better noise

Post by Tev »

cube wrote:Guys, do you know that the whole noise thing is supposed to be only performance improvement? At this stage, at least.
Considering popularity of RSO people would like if you try to improve more than "only performance" . . .

kovarex
Factorio Staff
Factorio Staff
Posts: 8053
Joined: Wed Feb 06, 2013 12:00 am
Contact:

Re: Friday Facts #112 - Better noise

Post by kovarex »

aka13 wrote:From my humble experience, projects which were not built ground-up with multithreaded support from the beginning tend to never end up having proper multithreading, simply because of the expenses and complexity of the said task after most of the project is complete. But I have no large field experience with that, so not arguing with you.
Well, the map generation was done in the same thread before and now it runs parallel with game, so we have done step like this already. Going from "running in one separate thread" to "running in x separate threads" would be much easier.

The problem with using lot of cores is, that we can't do it. The game needs to generate the map slow enough, to make it still smooth on the worst computer we want to support. We can't generate faster on faster computers, as the game needs to be deterministic.

Considering this argument, optimising it on single core is even better.

User avatar
Phillip_Lynx
Filter Inserter
Filter Inserter
Posts: 541
Joined: Mon Jul 21, 2014 6:00 pm
Contact:

Re: Friday Facts #112 - Better noise

Post by Phillip_Lynx »

kovarex wrote:... Considering this argument, optimising it on single core is even better.
Thx for this. I am on a 2 core / 4 threads computer and have not the money to get a better rig. The house is eating up all my money :).

Lee_newsum
Filter Inserter
Filter Inserter
Posts: 433
Joined: Wed Jan 15, 2014 9:41 am
Contact:

Re: Friday Facts #112 - Better noise

Post by Lee_newsum »

kovarex wrote: The problem with using lot of cores is, that we can't do it. The game needs to generate the map slow enough, to make it still smooth on the worst computer we want to support. We can't generate faster on faster computers, as the game needs to be deterministic.

Considering this argument, optimising it on single core is even better.
Yes for Multiplayer game but you have to tink some of the one player game. can you add this like this that work of one player games?

p.s. i have i7 6 core / 12 threads computer i have the threads to use.

Kayser
Long Handed Inserter
Long Handed Inserter
Posts: 82
Joined: Mon Aug 10, 2015 9:43 am
Contact:

Re: Friday Facts #112 - Better noise

Post by Kayser »

sillyfly wrote:
Kayser wrote:I'm not a huge fan of the results of the current map generator. I understand that the devs want to be able to calculate any point of the map independently of all others, but that constraint it is getting in the way of creating fun, variable, interesting maps with replayability value. I'm sure a better map generator could be found if that constraint was dropped. Don't get me wrong, it could still be infinite.
Not sure what you mean by "...be able to calculate any point of the map independently of all others...", but can you explain what constraints such approach inherently has?
It means that when determining the properties for a point on the map the algorithm can't look at e.g. adjacent points to determine what properties the new point has; instead it must base its calculations only on the seed and parameters given initially. This rules out generating maps based on procedural algorithms that simulate e.g. rainfall or erosion.

User avatar
Kewlhotrod
Fast Inserter
Fast Inserter
Posts: 165
Joined: Thu Apr 23, 2015 5:20 pm
Contact:

Re: Friday Facts #112 - Better noise

Post by Kewlhotrod »

aka13 wrote:Easier, but not necessary better.

Since the new intel leak for the k-Series with 10 cores and 20 threads, I think multicore has a brighter future.
thats the intel extreme part for enthusists, like 600£ cpu if not more, although no details on the price of the parts have been released yet although judging by the price of there last enthuist part it would be costing more because of more cores.

kovarex
Factorio Staff
Factorio Staff
Posts: 8053
Joined: Wed Feb 06, 2013 12:00 am
Contact:

Re: Friday Facts #112 - Better noise

Post by kovarex »

Lee_newsum wrote:
kovarex wrote: The problem with using lot of cores is, that we can't do it. The game needs to generate the map slow enough, to make it still smooth on the worst computer we want to support. We can't generate faster on faster computers, as the game needs to be deterministic.

Considering this argument, optimising it on single core is even better.
Yes for Multiplayer game but you have to tink some of the one player game. can you add this like this that work of one player games?

p.s. i have i7 6 core / 12 threads computer i have the threads to use.
When the performance becomes an issue, it will be probably related to game updates. And it is a good point for multithreading, as you have to calculate it anyway. Some things are especially good for multithreading, like electric network calculations.

ratchetfreak
Filter Inserter
Filter Inserter
Posts: 950
Joined: Sat May 23, 2015 12:10 pm
Contact:

Re: Friday Facts #112 - Better noise

Post by ratchetfreak »

kovarex wrote:
Well, the map generation was done in the same thread before and now it runs parallel with game, so we have done step like this already. Going from "running in one separate thread" to "running in x separate threads" would be much easier.

The problem with using lot of cores is, that we can't do it. The game needs to generate the map slow enough, to make it still smooth on the worst computer we want to support. We can't generate faster on faster computers, as the game needs to be deterministic.

Considering this argument, optimising it on single core is even better.
What actually needs to happen is that a request to gen a map tile and the actual insertion into the game logic should be allowed to have a few game ticks between them. Then you can offload the generation to another threadpool and come back later for the result to push it into the game world.

In multiplayer you can use a ballot of who's finished with the generation to decide whether to insert the tile yet (or to perform a download of the tile data by the slower PCs).

kovarex
Factorio Staff
Factorio Staff
Posts: 8053
Joined: Wed Feb 06, 2013 12:00 am
Contact:

Re: Friday Facts #112 - Better noise

Post by kovarex »

ratchetfreak wrote:
kovarex wrote:
Well, the map generation was done in the same thread before and now it runs parallel with game, so we have done step like this already. Going from "running in one separate thread" to "running in x separate threads" would be much easier.

The problem with using lot of cores is, that we can't do it. The game needs to generate the map slow enough, to make it still smooth on the worst computer we want to support. We can't generate faster on faster computers, as the game needs to be deterministic.

Considering this argument, optimising it on single core is even better.
What actually needs to happen is that a request to gen a map tile and the actual insertion into the game logic should be allowed to have a few game ticks between them. Then you can offload the generation to another threadpool and come back later for the result to push it into the game world.
This is exactly how it works in Factorio.
In multiplayer you can use a ballot of who's finished with the generation to decide whether to insert the tile yet (or to perform a download of the tile data by the slower PCs).
I strongly believe, that the extra bandwith and replay size wouldn't be worth it. Isn't just making the map generation 10 times faster simpler? :)
Actually, if the map generation becomes very fast, it can be even worth of not saving most of the terrain in map save and re-generate it when loading the map. (The other way around)

ratchetfreak
Filter Inserter
Filter Inserter
Posts: 950
Joined: Sat May 23, 2015 12:10 pm
Contact:

Re: Friday Facts #112 - Better noise

Post by ratchetfreak »

kovarex wrote:
In multiplayer you can use a ballot of who's finished with the generation to decide whether to insert the tile yet (or to perform a download of the tile data by the slower PCs).
I strongly believe, that the extra bandwith and replay size wouldn't be worth it. Isn't just making the map generation 10 times faster simpler? :)
Actually, if the map generation becomes very fast, it can be even worth of not saving most of the terrain in map save and re-generate it when loading the map. (The other way around)
Then the map download when joining a multiplayer game will also be reduced

User avatar
tobsimon
Fast Inserter
Fast Inserter
Posts: 104
Joined: Wed Apr 29, 2015 10:58 am
Contact:

Re: Friday Facts #112 - Better noise

Post by tobsimon »

Did I just read "better rail system".
I sure hope this includes a fix for the "circles" *cough* *cough*.

User avatar
cube
Former Staff
Former Staff
Posts: 1111
Joined: Tue Mar 05, 2013 8:14 pm
Contact:

Re: Friday Facts #112 - Better noise

Post by cube »

Kayser wrote:It means that when determining the properties for a point on the map the algorithm can't look at e.g. adjacent points to determine what properties the new point has; instead it must base its calculations only on the seed and parameters given initially. This rules out generating maps based on procedural algorithms that simulate e.g. rainfall or erosion.
Not entirely, I hope. I was thinking about this for some time, and I think that we can cheat this a little. Already there is a mechanism where every chunk has a level to which it is generated (now it is raw tiles, corrected tiles, tile variations, entities) and there is a rule that chunk with level n must have all neighbors at least on level n-1. So we could add a level after raw tiles that looks at the neighbors' raw tiles and does some erosion fun. Theoretically.

Furan
Burner Inserter
Burner Inserter
Posts: 15
Joined: Sun Jul 05, 2015 2:54 pm
Contact:

Re: Friday Facts #112 - Better noise

Post by Furan »

While you're at it, please consider reworking the structure of the resources. At this point they are generally homogeneous convex patches.
I'd like to see stripes resembling stratification. Use a periodic function (triangle wave) on the main terrain noise, ultimately creating distinct or blurred bands parallel to the coastline.

Kayser
Long Handed Inserter
Long Handed Inserter
Posts: 82
Joined: Mon Aug 10, 2015 9:43 am
Contact:

Re: Friday Facts #112 - Better noise

Post by Kayser »

cube wrote:
Kayser wrote:It means that when determining the properties for a point on the map the algorithm can't look at e.g. adjacent points to determine what properties the new point has; instead it must base its calculations only on the seed and parameters given initially. This rules out generating maps based on procedural algorithms that simulate e.g. rainfall or erosion.
Not entirely, I hope. I was thinking about this for some time, and I think that we can cheat this a little. Already there is a mechanism where every chunk has a level to which it is generated (now it is raw tiles, corrected tiles, tile variations, entities) and there is a rule that chunk with level n must have all neighbors at least on level n-1. So we could add a level after raw tiles that looks at the neighbors' raw tiles and does some erosion fun. Theoretically.
Alright. I'm looking forward to it :)

User avatar
Gandalf
Filter Inserter
Filter Inserter
Posts: 294
Joined: Fri Dec 19, 2014 10:15 pm
Contact:

Re: Friday Facts #112 - Better noise

Post by Gandalf »

So cube, I see you're using Awesome as well? :D

Love the tech-talk. It made me realize how little I know about non-cryptographic hash functions.
OS: Linux Mint 19 x64 | desktop: Awesome 4.2  |  Intel Core i5 8600k  |  16GB DDR4  |  NVidia GTX 1050 Ti (driver version: 410.104)    (2019-03)

Post Reply

Return to “News”