Refactoring and modernizing

[tarTG]

After the suggestion of https://github.com/tarTG/RTplatec/issues/9 , I plan to refactor and modernizing this library. Thus I have some questions:

1. Switching to c++14 This would allow to make the code a lot more efficient and readable, but would exclude some older compiler versions.

2. Library usage I would suggest to use libnoise for fractal generation and glm for mathematics. But in https://github.com/Mindwerks/plate-tectonics/issues/7#issuecomment-78313674 you mention, not to use external libraries.

3. Additional features In my fork, I have some additional features I needed, like runtime adjustment of parameters or terrain manipulation. Would you like to have such stuff also here or is this out of the scope of this project?

[psi29a]

I <3 your RTWG project, the video you made was amazing. :)

1) Yes please.

2) Was in reference to export/import, as a general rule we try to avoid deps, but we made an exception for GDAL for example because it handles SOOOO many formats. We can negotiate this. :)

3) As I said, love your project. Yes, this is within scope of the project. We have another repo with a bare-bone GUI made in Qt. We would like to see if we can get OpenGL to play nicely inside Qt where Qt callbacks hook into OpenGL. There are libs like OSG that can do this for us within the Qt GL context (osgQt plugin). Perhaps this is something we can do or if you have something else in mind, we're open to possibilities. :)

[tarTG]

Thank you for liking my project :)

2. I have to admit, that i am not very happy about the way, the start terrain is generated at the moment, because it does only support 1 kind of generation. To make this better, we have two options:

   • include a library that handles generation
   • we make it user defined. The plate-tectonics has no generation and the user has to pass in a texture.

3. Ok. I will see what i can use from my fork. If you want to include OpenGL to QT, there is already a interface

[psi29a]

WorldSynth, my precursor project to WorldEngine supported multiple ways to create terrain which can be used before being fed into tectonic simulator. https://github.com/psi29a/worldsynth

One of the last things I implemented was multi-pass perlin noise (almost brownian motion) which used the Noise (libnoise) library. The idea being that the terrain could be tile-able and generated on fly when needed.

Is this something we can use?

Also included are: midpoint displacement, diamond/square and simplex noise

[ftomassetti]

I like all of your suggestions. Until we have all tests passing I am fine :D

[tarTG]

We have a huge problem on this. The builds without python are working fine with C++14 on all three compilers. The GCC-5 build with python works, because C++14 is the default setting here. But the clang/msvc builds with python are a problem.

For the clang build: The python setup ignores all system flags. So it thinks it is using GCC even if its not. In all your CI builds, it was always using GCC. I changed this and need to set -stdlib=libc++ for C++14 in the setup.py for clang, but i cant, because the setup still thinks it is using GCC.

On the MSVC: Through the fact, that you need specific SDK versions to build the python wrappers, I am not able to use C++14 here, because there all older than 2010.

[psi29a]

So not necessarily a huge problem, just typical MSVC problems. ;)

The clang build is a bit worrying, but there might be a python trick or two. Normally Clang honours all GCC related flags so that shouldn't be a problem. You mean that Python is still calling gcc instead of clang, have you tried using scan-build? This will swap out a lot of GCC environment settings with Clang... so unless Python is ignoring those as well, it should work.

[tarTG]

Maybe I will find a workaround for the clang build. I have to admit that I never used python before. But what is about MSVC. Do we cancel the support? Or should we just support python 3.5+, which should have modern C++ support (see here)

[psi29a]

Python 3 is the way to go and we should be migrating to that in the future.

It would be great to have Python 2.7 support, but if it is impossible to support then we can look at disabling that.

[tarTG]

OK. I finally works. On Clang, I check the OS environment, if clang is installed. On MSVC it works on Python 3.5

So I can continue to work on my modernize Branch. With support for all GCC and Clang builds, and MSVC with Python 3.5. So it is later up to you, if you want to merge it or not.

[psi29a]

Thank you for the all the work. :)