Consolidated discussion of ideas related to platec

[MM1nd]

Hi,

1. In my current local version (Faster watermap #245), platec.step is the biggest time consumer. I suspect that this will get relatively worse when I continue to improve on the other parts. I also suspect it will be much harder to make platec faster because the easy way of "let's move this to numpy" is not available. I haven't looked into the platec code base, maybe there are some low hanging fruits, but eventually there is only so much that can be done.

2. Regarding [Feature Request?] Low res without changing landmasses #230, making the python parts faster makes the creation of many maps to choose from more feasible, but eventually platec will be the bottleneck and this is never going to be fun. I think @PeteMichaud is right on that issue: Regarding a world's potential to be interesting it matters far more that the shape changes with resolution than that everything else changes. So my suggestion would be to support running platec at a lower resolution than everything else and upscale the result. So you could indeed create a large number of worlds in a small resolution, select the interesting ones and rerun them with the shapes upscaled and subsequent steps running at full resolution. That way you'll get a world that has the same shape as the low-res one but is different in the details. I think this is a good tradeof.

• Somewhat related: Add operation to rescale a world #80, but what I mean is more than scaling after everything was completed.

3. Regarding the number of plates obviously we would want to make that an option (Move option for the number of plates among generation options #215). I understand @sara-02's question in Number of plates default should be ~50 #227 to go in that direction. However, there are limitations. I don't think a "realistic" number of 50 plates, as discussed there, would work, even on the largest currently feasible map sizes. This makes me question two things:

• For what size is the current default of 10 optimized? @psi29a @ftomassetti ?
• More generally, how should the relationship between map size and numbers of plates be? Making this an option is fine, but the default should probably depend (logarithmically?) on the size of the map. For very small maps I think even 10 plates is too much.

Cheers
Alex

[ftomassetti]

Maybe it is already clear but note that platec is written in C++ and it is very complex code we recovered from a thesis. We have polished it over time and addes a few tests but it is far from being easy to change.

Regarding using different resolutions, yes, that would be good but I think that running the plates simulation at an higher resolution give more interesting results. Running resolution at low resolution, scale and then perform the other operations (like erosion) would give probably slightly less nice results but the advantages seem great.

Regarding the number of plates, of course it should be an option but I think we should also give sensible defaults, maybe considering the resolution. The value was chosen by experimenting at different resolutions. I would say we have to experiment to find the optional link between size and number of plates

[ftomassetti]

Let me also add that I think this project is really good and much better of any alternative I know of. Lately I did not have the energy to invest in this one as I am captured by my business and other open-source projects so I am extremely happy to see someone else showing interest and moving things forward.

[psi29a]

Just a heads up, I've come across this project and it has tickled my interest:
https://github.com/rlguy/FantasyMapGenerator

It is almost entirely in C++ aside from rendering bits. It's quite possible that we can incorporate different 'backends'. I've been wanting to do this for awhile for the different methods I had for landmass creating in worldsynth.

In other words: platec is just one of many 'backends' that can be used to create a realistic landmass. Otherwis might not be as 'realistic' as a tectonic simulation but they can be good enough for some things.

What do you guys think?

[ftomassetti]

I agree, I think WorldEngine should be modular. However that will mean a more complex interface for the user and the necessity for clearer documentation

[MM1nd]

pytectonics as mentioned in #123 has a successor that seems to be still in active development:

http://davidson16807.github.io/tectonics.js/blog/news.html

My current roadmap, if you want to call it that, is as follows:

• Get two more PRs merged for speed of the world generator. One is already online as transpose next_land_dynamic for greater speed and clarity #247 we're almost done here and I think we did good.
• Aside: In my final local version most of the time is spent in platec (as predicted at the beginning of this thread) and protobuf.

2. Do the same thing to ancient_map, maybe finally getting to a point where running the tests is no longer a five minute wait.
3. Try my hand at the long standing ocean_level issue (How can I make a huge land mass. #241)
4. Maybe some cleanup and documentation, although I'm not particularly sure what needs to be documented. Maybe that should be discussed in another thread.

• Aside: Am I right to assume that the simulations are often tuned to produce what looks good, rather than actually simulating the real thing?
• Aside: When I first looked into worldengine last year, I toyed with the idea of implementing http://www-ljk.imag.fr/Publications/Basilic/com.lmc.publi.PUBLI_Inproceedings@117681e94b6_fff75c/FastErosion_PG07.pdf However, that's hopeless on the CPU. GPGPU has become massively more usable in recent years. There is always the option to implement that paper in C using the GPU (or find an implementation ready made) and interface with it. However it's not a low hanging fruit, to say the least.

5. More modular and more configurable backends, as discussed here.
6. Pick uo the Tiled feature Support interoperability with Tiled #180 if @Asday doesn't get around to it before me.

Of course I can't promise to keep up the current pace forever. So all of the above has to be read as "in an ideal world".

[ftomassetti]

We looked into that paper and we have implemented some variants of it but we were not impressed by the results.

All in all, if you do even a fraction of this I think WorldEngine will be in a better shape. And that could also mean more people will contribute in the future. So, we are rooting for you!

[Asday]

Howdy. I'm on with number 6 on your list now, @MM1nd, but no promises; I am young and stupid. @ me if you get to there before I have news, and I'll do what I can to hand over.

[MM1nd]

"I am young and stupid."

Don't worry. We all were at some point.

[psi29a]

Just a heads up, I'm looking into modularizing our backends. I have a stripped down version that simulates a 'plates' run by returning numpy zero arrays for elevation and plates. By doing this, our baseline is:
real 1m10.831s <-- this is how long it takes to run everything except for platec at 1024x1024

I plan pushing/wrapping everything having to do with heightmap/elevation map in to a specific class that can be 'run' with parameters.

I plan on making the parameters simple: the user defaults to platec but can also choose another backend for their needs.

[psi29a]

Also something interesting:
http://numba.pydata.org

Nvidia seems to be supporting it as well:
https://devblogs.nvidia.com/parallelforall/seven-things-numba/

It will try to JIT things on GPU if it's there otherwise fall back to CPU. This with a simple @jit decorator... too good to be true..