Build errors on windows

[lonestarr1986]

Hi Henrik,

I got the following error after compiling the exe and trying to run it: Sorry for the German, it translates to "The procedure entry point GOMP_parallel could not be located in the dll [...]". I suspect I am missing some dll's, as I seemed to be missing "libgomp-1.dll" and "pthreadGC2.dll" when I foolishly executed erodr.exe in hope for a user interface... ^^

I got those DLL's covered, but to no avail. Running the program in powershell, nothing happens:

Do you have any clue what could be wrong? A friend successfully compiled the exe and runs the program just fine (he is a programmer, possibly has the required libraries?), but when transferring the .exe it still won't work for me.

[henrikglass]

If erodr executes without error you should see no output. I.e. "nothing happens" is expected behavior.

edit: If erodr executes without error you should see output like this "Particles simulated: xxx".

Try running the following in powershell:

diff (cat 'apollo.pgm') (cat 'out1.pgm')

If it prints a bunch of garbage that means erodr did something. If it prints nothing the files are identical. You could try opening 'out.pgm' in an image editor like gimp to see the results. It's been a while since I worked on this project, but here's a picture I found showing what you could expect:

https://imgur.com/a/TzD7C02

I think I used some pretty extreme settings for that one, so your results might not be as obvious.

As for the dll's, they are related to OpenMP, a library I used to parallelize parts of the code. If all else fails, you could just step back one or two commits to before the "parallelism is hard" commit and try to build them. I give no guarantees for success though. I have only built this project on Linux. I might try to provide some pre-built binaries when I find the time, since people actually seem to be using this project.

As a side note, do you mind me asking where you found out about this project? It seems like it got some traction recently from out of the blue. I'm just curious. :-)

[lonestarr1986]

Hi Henrik,

thank you for the speedy reply. I'll try your suggestions out later today or tonight.

The previous commit suggestions sounds good, that might work. No idea why OpenMP library doesn't work for me, I had MinGW install many libraries, but cannot rule out me just being completely clueless in this regard. My only programming experience is with Matlab for my master's thesis, and I dare not show my code to anyone, lol.

Pre-built binaries would be a blessing for those other tech imbeciles like me. There's definitely demand for simple (and cheap?) erosion software. Everything else I have seen so far (although there's some python code out there I still have to try) is only part of a software suite (usually sophisticated procedural terrain generators), costing usually some 200€ and more.

So how did I find out? Some google fu when looking for "heightfield/heightmap erosion" and I stumbled across Beyer's bachelor's thesis your program is based on. I think I was actually googling his name, hoping he would release his own code somewhere.

And what do I use it for? I am creating Minecraft worlds, lol. So far I draw everything by hand, erosion an all (very unsophisticated by using the smudge tool, lol, but it works alrightish - it's just a very tedious process). Here's the output (left, I think) my friend generated from a pre-existing volcano island. As you can see, he wasn't very successful in terms of erosion, one possibly need to up the values quite a bit. Anyway, the handcrafted version is alright, but the process is agonizing.

I'll try your approach first, but since the program never even writes a "out1.pgm" as I instructed it to do. Speaking of no messaging, I expected sth like this what my friend got: but my powershell just returned the path and did nothing of the sort.

[henrikglass]

I'm sorry, you're right. You're definitely supposed to see the "Particles simulated: xxx" output. I'll try to see if I can replicate it when I get home.

Meanwhile, you could try switching to gcc and building the program. It's a simple case of changing these lines:

#CC         = gcc
CC      = clang

# compiler specific flags
#CSFLAGS = -fopenmp # gcc
CSFLAGS = -fopenmp=libomp # clang

# linker
#LINKER     = gcc
LINKER  = clang

to this:

CC      = gcc
#CC         = clang

# compiler specific flags
CSFLAGS = -fopenmp # gcc
#CSFLAGS = -fopenmp=libomp # clang

# linker
LINKER  = gcc
#LINKER     = clang

in the makefile. It might be worth a shot given that mingw includes a port of gcc.

If that doesn't work you can try building and running it under Windows Subsystem for Linux. That should definitely work.

And yep, you probably need to tune the parameters a bit to your preference. As I said, I used some pretty extreme settings in the imgur example.

EDIT: Added the linker to the lines that should be changed

[lonestarr1986]

I already compiled it in GCC, sadly. Although I'll recheck the flags, maybe there was an error made there.

I'll report back later. Thank you for your time :)

[lonestarr1986]

For notification purposes in a new comment:

Using an older commit actually did the trick, many thanks!! Now it's time to see what I can actually achieve, hope the lack of parallelization won't hurt me too much but my single speed CPU speed is okish. Is there a size restriction on the heightmap? My mate actually found that a relative large heightmap of 3700x1700px (approx.) was not rendered, a smaller one (around 1000px or so?) worked.

[henrikglass]

I was able to build erodr (with OpenMP) on windows under cygwin by making the necessary changes to the makefile, as shown in my previous comment. I used the latest stable versions of make (4.3), gcc (10.2.0), and libgomp. Everything executes as expected.

The size of the image should not cause any technical issues (unless I've been a bad programmer). Keep in mind that the number of particles is constant. For a 512x512 image, the default setting (70'000 particles) produces a visible result. For a 2048x2048 image, you would need 64 times as many particles (4'480'000) to get a similar result. IIrc I've tested erodr on 4096x4096 without issues.

Also, I forgot to mention changing the linker from clang to gcc in my previous comment. Check out the edit.

[lonestarr1986]

So my happyness was premature. I tried to erode this:

And it turned out as this (standard settings):

Image is 512x512, pgm format, ASCII. Exported with GIMP. Am I doing sth drastically wrong?

EDIT: This is commit "1838da38e2eb6bf1326fabd20ff80f1cb77a5d7e"

EDIT2: If I use your example:

I get:

I wonder what's wrong now...

EDIT3: I managed to compile your newest commit just fine and ran it just fine also (wonder why it didnt work earlier...), but I got the same error. Huh. It looks a tiny bit different, but generally it looks the same.

[henrikglass]

You're probably not doing anything drastically wrong. This is project is a "happy path only" type of deal. There is bound to be some issues. I'll probably take the weekend to find and fix any bugs I can.

I was unable to reproduce the results you're seeing. I downloaded the images and converted them to ASCII format *.pgm files in gimp. I only got the "spikes" bug mentioned in the readme (which has a workaround, at least). It looks like you're getting a combination of that and some missalignment in the output image. Could you send me the exact files you used?

[lonestarr1986]

Sure thing.

I am happy you are providing me with all that help! I'll try the program on another machine, maybe it's sth with my PC as well, who knows. --> Did just that, no use, same error :(

Here's the latest commit that I used. https://www.dropbox.com/sh/t9ikxvcbuwo6sgd/AAAwHlSgVnG_eNm-WCjKmKr2a?dl=0

[henrikglass]

I downloaded the version of the repo from your dropbox and built the program. I ran it on test5.pgm. This is my result:

I only get the spikes issue, which is expected on input with white or black clipping (I'll try to patch it soon). Are you absolutely positive you're successfully building and running the latest version of erodr? The missalignment looks like one of the earlier issues I had in development.

EDIT: As a side note, I fixed the spikes issue. The latest version is: 6e14f78d691aa9e3d4b9687c7cfc8d0d74fa05cd . These are my results now:

[lonestarr1986]

I'll give that one a try! I thought it'd be a problem on my side compiling the exe, but the compiled exe that my friend send me was working in a similarly bad fashion. I wonder if it's an out of date library of sorts?

My "make" process (turned on GCC again because I don't have clang)

and the output is (lazily screencapped fom GIMP):

EDIT: What does the white or black clipping mean, btw? That I have a white or black border somewhere which could fuck up the erosion process?

EDIT2: The "fuzzy border" part is definitely gone, now I just got proper static. Can you supply me with your .pgm you worked with in your example? I was converting your png into pgm, maybe it's just a silly error on my end.

[henrikglass]

Black or white clipping is when parts of the image are completely black or white (0 or 255 for an 8 bit .pgm). For instance, if an area is completely black, any erosion will be outside the dynamic range of the image. I.e. we will get results < 0. It's not clear what the simulation should do. Either we remap the color range, or we ignore any results outside the legal range. The latest patch does the latter and gives you a warning.

I notice the "Particles simulated: xxx" print-out in your example is not in order. That in itself isn't weird, since the simulation is concurrent, but I don't get it on my machine. It could just be that my solution isn't robust enough (maybe slapping OpenMP preprocessor directives everywhere isn't all there is to concurrent programming ¯\_(ツ)_/¯ ). Could you try commenting out the -fopenmp flag in the makefile and retesting? Like this:

CSFLAGS = #-fopenmp # gcc

That should disable concurrency. It might give you a warning but that's fine.

I used the .pgm from you dropbox folder, so that shouldn't be the problem.

[lonestarr1986]

Right, I will try that tomorrow. I'll also try the latest commit of yours just to be sure.

I noticed the order thing earlier, but wasnt sure how you programmed your parallel processes, but since I got the weird output either way, no matter which commit I used (parallel and not parallel), I fear that's not the solution either.

TTYL :)

[lonestarr1986]

Just to be sure, I commented it out as instruncted and I get:

and when trying to execute, I get: "error when running erodr.exe", the file or directory is damaged and not readable in line 1, character 1."

And still results in:

:/

Je suis cursed

[henrikglass]

Sorry, I should have mentioned that you should run make clean before you run make to remove any object files from previous compilation attempts. From the first image it looks like make is just trying to link the old object files into an executable.

But I am also a bit confused. You say you get "error when running erodr.exe" but still manage to run it in the next image?

Sorry for the late reply. Busy week.

EDIT: As a side note. I've tried building and running the latest version of erodr on at least 4 different machines, including a friend's machine who also got the out of order "particles simulated" printouts, both on Windows and Linux. I haven't been able to reproduce the bug.

[lonestarr1986]

I'll try make clean just in case.

Yeah I worded that a bit poorly. I ran the newest commit with the same result, but that may be because of the lack of make clean. I'll retry tonight.

Really curious that it's only my machines. I tried it on my home PC and my work laptop with the exact same result (in the latter case I just sent myself a readily compiled folder+exe) plus some dlls I seemed to need, with the same result. It's probably something in the compiling process that's gone awry. I rushed the installation of GCC, etc. and may have made errors in the process. Haphazardly downloading missing dll's from god knows what resource to quell the errors that pop up when running the exe when double clicking in windows.

Which public/external dlls are using for erodr? I tried dependency walker on a compiled exe but the program hung itself (that itself should be a red flag I guess).

Do you think you could compile a windows exe (I assume when you compile in linux you get a different executable?) for me to have a look at? That way we could exclude some compiling shenanigans.

[lonestarr1986]

Make clean does not work for me, the installation process returns: "the order "rm" is written incorrectly or could not be found". No idea what I am missing now :)

A regular "make" resulted in the same fuzzy picture as I always get.

At this point I am giving up. I have no idea what I did wrong and since you cannot repeat the issue, it's something wrong on my end. Alas I cannot run the exe on my other windows machine for lack of .dlls, and upon downloading those missing ones return the same error.

So there's some fundamental lack of understanding of programming on my end that I cannot reconcile right now.

Sorry for wasting your time, but at the same time thank you for bearing with me.

Keep me updated if you ever try to release a "all-in-one" solution ready to download, I'd very much be in your debt. Until then I guess I will have to find another solution for my erosion problem :)