Initial questions/suggestions =)

[metaleap]

This tool is such a fantastic effort filling a real need that's only barely served on Windows (which I avoid) and not at all on Linux. I'll spread the word for sure on this cool project!

And of course I come with suggestions / questions upon my first few minutes of tinkering 😁

• Ultimately I'd want to make horizontal or vertical maps, ie. both 2048x1024 or 1024x2048. I realize power-of-two necessities but is square-ness a strict necessity for the algos being employed? Certainly for my purposes I could also consider manually joining two separately-generated square "island maps" into one "game map". But do consider offering this possibility if it's a fairly trivial thing, broadens users' design possibilities =)

• What's the 100%-black-rendered artifacts here for this lit-and-not-in-shadow ridge? They show up as gaping holes in wireframe btw. Some unconnected vertices or some such? They're gone after switching from 1024 to 4096, so not an underlying computation issue I guess, merely a representation one. So.. just curious I guess. Unmodified demo_v0.2.0.hsd (from the 2-days-ago Release). Screenshot:

• Would absolutely suggest some sort of an export-at-higher-resolution-without-the-realtime-rendering-at-that-res feature/option/node/button. Say, in the beginning one does at a fast low-res 1024 or so their nodes-driven realtime design, until utterly satisfied with the terrain. Then comes the time to generate a say 8192 or 16384 hi-res 16-bit greyscale heightmap png. So your fantastically-already-existing ExportHeightmap node could offer an upscale option and if greater-than-1 auto-untick the "Automatic Export" toggle. And then to trigger it manually have a button for that (or I guess one would click "Force Update" maybe)? And this option of course wouldn't merely "upscale the lower-res png pixels" but rather run all the nodes' computations at that higher resolution (without on-screen rendition during, to save some perf — if that's even how things work, nevermind =) — my fabulations on this may seem convoluted but stem from seeing how much slower 4096 is vs 1024, so while hi-res-computed exports would be insanely valuable, they'd probably require a slightly specialized UX path here, dunno.. or even just a command-line command arg like hesiod demo.hsd --exportHeightmap=out.png --exportWidth=16384..

[otto-link]

I created some issues to keep track of your suggestions (see below some additional comments)

Ultimately I'd want to make horizontal or vertical maps, ie. both 2048x1024 or 1024x2048. [...]

Right now, this is indeed locked on squared heightmap with 2^N sizes, but all the algorithms are written assuming an arbitrary grid size (but not thoroughly tested...) => #220

Certainly for my purposes I could also consider manually joining two separately-generated square "island maps" into one "game map".

This is on my to do list somewhere. At some point I'd like to give the possibility to edit multiple heightmaps at the same time and put them on a global layout (see scheme in the new issue). Procedural inpainting will then be used to fill the gaps between the heightmaps when exporting => #221

What's the 100%-black-rendered artifacts here for this lit-and-not-in-shadow ridge? [...]

It's rendering bug, likely the transparency going out of range, but as you noticed, it's only visual => #219

Would absolutely suggest some sort of an export-at-higher-resolution-without-the-realtime-rendering-at-that-res feature/option/node/button. [...]

There is already a functional batch mode that does that but I recon it would be nice to have this available directly in the GUI. Could be a menu option "[NICE EXPLICIT NAME TO BE FOUND]" as you suggested => #222

Right now you can use the following command line:

bin/./hesiod --batch test.hsd --shape=2048,2048