Probability math speedup?

[o-jasper]

find_height has to iterate the map, and then the roll often throw away that computation. Probabilities can get pretty low, sub-1% even.

Nodes are already chosen at random, we want to add to that that they're run in the right fractions. We could approximate different probabilities with bins, each bin corresponding to p[k] probability has n[k] entries, the frequency of it f[k] occuring in general is f[k]=n[k]p[k]

I think randomly pick locations, put them in some bin-list k, as the top probability is calculated. Measure the n[k] of each bin, by simple number of encounters, likely some running average, based on the rate of the area is expected to change. Work through the lists for each bin at the proper frequency.

Bins at high f[k] and low n[k] may run out, and then you get more, likely finding a lot of the other k instead. Bins of which the bin-list gets too long, dump the oldest.(as we're pretty much hoping the information isn't stale..) Of course if this happens a lot, the savings are lost. On the other hand, finding many to dump lowers the estimate of the number out there; n[k] and thus f[k] by the moving everage. I am not sure how much faster it'd be in the end..

I might try implement it later.

[o-jasper]

I was confused, this is the java version.. Doing the stuff in lua.. Well, thats dumb, pushed the minetest lua one onto the forked java stuff here, have nothing to do with each other code-wise.. ><

Btw, that adds eroding-to-a-slope,(it could do a sludge, although probably only good for if you want to do that at long timescales) changes the sed blocks ... to sed rate [r], sed radius [r], added sed hit [N] which does the current area.

Adds a sed debug displace it skips the preceding probabilities and "always displaces" running it on a tower, had about 40×40 area.. need more like 1000×1000 for a map, thats ~600 times more, it took about 3 min.. to reduce a sand tower.. Still, but true geology will probably take at least 100×— that, so 3000hours=125days, not good enough, and probably the optimization above isn't that good, and other stuff is needed with the geology too... I suppose it is only one order of manitude and 100× is a high estimate.. Could also simulate it outside of MT first and then make it finer inside MT. Note that this is really only about generating the map to start with, once it is ready for players, CPU costs are probably fine..

[o-jasper]

If you can see all changes, you could do a memory intense approach if randomly select from all the options in data structured for the purpose.

[sofar]

I don't see any changes here, did you fork and patch the lua version?

[o-jasper]

Well i pulled it here, but but dumbly pushed onto(edit: deleted that) the minecraft sedimentology repo... I'll delete that one and fix..

[o-jasper]

Moved it to the proper place, i don't know if i should pull-request it, it is pretty different from what your code does, depends a bit on what you want. (I think it is better of course :P) I can make branches with some of the particular features in it.

Haven't gotten round to the speed improvements i wrote about yet. It is not high priority at all for me though. I think a more memory intense approach is good for when you have a sludge or something that needs to move faster.(or you're really going for it as main thing..) Which is something i want "for industry-like stuff" or maybe "sewers".

One thing i forgot to mention, a slope dropping one block every N only works if in each steps it looks N blocks around. Perhaps could go around by sometimes changing one block into two half blocks and recombine them. Pretty serious complication though, in general you can get very complicated with this, but dunno if we want to. (what if there are two species.. don't want piles of half-blocks..)

Sorry, being pretty verbose..

[sofar]

I'm not very interested in rapid geological processes like slumps, landslides etc. While they would be realistic in some circumstances (e.g. a collapsing cliff), the problem with them is that they're only a very small portion of the amount of material affected by erosion in reality.

Making sedimentology memory-intensive would likely pose problems for multiplayer servers where large areas may be loaded for long periods, consuming lots of memory. The stateless approach is really efficient.

However, if you are interested in doing something "big" and "fast", I am very interested in seeing if a separate mod could do e.g. strike-slip faulting, landslides and cave collapses and the likes on a large scale, which would be a nice but separate mod to have.

[o-jasper]

Well, i meant just running the whole geological process(regardless if it involves landslides) faster so the map is "real". Or non-geological cases, slurries or something. When people actually on it, would't want geology destroying their stuff much.

I don't know much about geology. Also, i do think a "real" map like that might be a silly thing to do.

[sofar]

I don't want this mod to be faster. It's meant to be slow, and purposely in a way that is hard to see by players.

[o-jasper]

I agree.. Even with the geology a bit, perhaps just running geology fast on part of the map initially, and having active geology there, so it can easily be avoided.

With "what you want" i meant more how it moves and stuff. I think maybe it is nicer, as you can set slope limits. If you make a great pillar, dirt makes a gradient of slightly less than 45° and sand more like 30°. So erosion would stop entirely eventually.(untill someone upsets it)

Note that running faster-in-cpu-time is nice, although if you run it really slowly, neglibly so. Also as you run(parts of) it faster, pretty sure it becomes worth spending more memory on those parts. Although that'd be a bunch of work to actually implement.

I want to be able to run it fast because then you can do sludges and such on the same system. But perhaps aswel for "preparing a map", like for instance simulating a vulcano(and places to disappear blocks, or it'll only add forever) for a long in-game geological time, and then slowing it down for actual play.(speed of geological time could also be location-dependent.) However as noted above, the CPU-costs to do this might turn out prohibitive..