Hi Dretch,
I apologise for the delay, and thank you for your question. Unfortunately, I think my answer is going to be disappointing, but here goes...
Alas, the erosion algorithm is not multi-threaded at all, so I will have to parallelize it before you can take advantage of a greater core count. This is on my to-do list. Multithreading has so far been applied to the calculations for the texture map, light map, normals map, and attributes maps, as these are typically generated at higher resolution than the heightfield, and therefore take longer than generating the heightfield. They were also relatively easy to parallelize, as each pixel is not dependent on its neighbours. This is unfortunately not the case for erosion, where each region strongly affects its neighbours, which requires inter-thread communication and synchronisation, so multithreading erosion will be more complex to implement, and won't scale as well to many cores anyhow.
As for increasing the supported core count; unless I resort to dark voodoo, the core count is limited to the size of the thread affinity mask for the process, which is 32 threads on a 32 bit system and 64 threads on a 64 bit system. Even then, I suspect the algorithms would not scale well to so many threads on a single system, as you'd most likely run into problems with disk bandwidth or thread-sync overheads. As far as my testing goes, most of the multithreaded calculations scale OK out to 6-8 cores, but thereafter there does seem to be diminishing returns (things may be better on newer systems, though).
Regarding Beowulf clusters; unless virtualisation has come a long way without me noticing (a distinct possibility), to run on a cluster L3DT would need to run separate instances on each system, and synchronise the jobs over the network. This is quite different to just multi-threading within one process on one system, and is quite independent of the core limit of the L3DT process. Anyhow, about a
8 years ago, I did actually develop code for running L3DT as a render farm across multiple systems, but as far as I can tell, I never quite finished it (the record shows I got distracted by scripts, graphs, 64-bit builds, other performance optimisations, etc.) It may be possible to take this work up again, but since it's a niche feature, it's not likely to be a high priority for some time. My guess is that it will also likely be significantly more difficult to support (networks are trouble), so if I do finish it, it is unlikely to be included with a normal 'indie' license (or trial, for that matter).
Best regards,
Aaron.