ogrecave / scape Goto Github PK

Currently, only brushes are implemented that change the heightmap, depending on how the user uses the brushes.
One could implement operations that change the whole heightmap.
In the simplest case, this could be a constant height (/reset the whole heightmap).

Originally it was intended to interact with the Engine project over the EngineInterface class.
I don't think that this is the best solution since there are many unrelated methods together in one class.
One could change this class to interact with other classes and mark this classes with some Export definition.

Maybe this program could need a version scheme.
The original program stopped at 0.1.1.
Someone wrote 15.02 in the title which seems random to me.
But I don't know how to do this and if this is really necessary.

Some settings have been defined in the config.json file inside the Startup section.
There is no way to change this except to change it directly in the file.
One should implement a dialog to change this easily from the program.
This could be difficult because this requires a restart of the program.

I quickly skimmed over the codebase and noticed:

• Mixed tabs/spaces. It's mostly tabs but most files contain some mistakes. I suggest using spaces for both indent + alignment because it's the simplest option to avoid mistakes. I'm linking the indent/alignment article solely for the purpose of being the first to bring it up. People get very clever on this topic.

• Deadcode. The \wxEditor and \Barebone directories are commented out in CMakeLists.txt, the \Editor directory seems to be ignored completely. I suggest to simply delete it.

Opinions?

To determine the version number I see two possible ways:

1. Set the version number with CMake in the project() command.
2. Use git to use a tag name and a commit hash as version number.

One could then generate a file like ScapeVersion.h which defines the version number after being generated by CMake using the configure_file() command.

The first way is easier to set up but the second way doesn't need as much maintenance but may be a bit more inaccurate.

I don't know which way could be better.

The QtPropertyBrowser submodule is outdated, unmaintained and has some bugs.
Maybe one could replace the property browser by some native dialogs.
Related to #36 and #37.

Maybe the config files(Resources.cfg, Settings.cfg) could be similar to the ones from the samples.
(Names and settings that may not work easily.)

Currently, the heightmap gets clipped when importing from images with different size.

Some settings that are related to the brush (radius) can only be changed by some shortcuts.
Maybe one could implement a dialog which shows the values and makes it easy to change them.

Can we require the usage of the C++11 standard for this project?
It looks to me like OGRE requires this itself.
https://github.com/OGRECave/ogre/blob/f4709042cf7722757d86fa830fedea0985017d53/CMakeLists.txt#L19-L21

Some macros have been defined in the UIElementClasses class.
It seems to me that someone saved up a Singleton class by doing this.
One should replace the macros in a way, that the use of some macros could be replaced by inheritance.
These macros are difficult to maintain and error prone.

Someone put a random text inside the about-dialog.
Someone could think about a nice text for this.
Maybe related to #31.

Maybe one should describe what one can do with this tool and add some nice images.

When starting the qtEditor binary after compiling, I get the following output:

./qtEditor 
Created page 'HeightfieldBufferPage1'
Created page 'HeightfieldBufferPage2'
Created page 'HeightfieldBufferPage3'
Created page 'HeightfieldBufferPage4'
Created page 'HeightfieldBufferPage5'
Created page 'HeightfieldBufferPage6'
Created page 'HeightfieldBufferPage7'
Created page 'HeightfieldBufferPage8'
Created page 'HeightfieldBufferPage9'
Created page 'HeightfieldBufferPage10'
Created page 'HeightfieldBufferPage11'
Created page 'HeightfieldBufferPage12'
Created page 'HeightfieldBufferPage13'
Created page 'HeightfieldBufferPage14'
Created page 'HeightfieldBufferPage15'
Created page 'HeightfieldBufferPage16'
Created page 'HeightfieldBufferPage17'
Created page 'HeightfieldBufferPage18'
Created page 'HeightfieldBufferPage19'
Created page 'HeightfieldBufferPage20'
Created page 'HeightfieldBufferPage21'
Created page 'HeightfieldBufferPage22'
Created page 'HeightfieldBufferPage23'
Created page 'HeightfieldBufferPage24'
Created page 'HeightfieldBufferPage25'
Created page 'HeightfieldBufferPage26'
Created page 'HeightfieldBufferPage27'
Created page 'HeightfieldBufferPage28'
Created page 'HeightfieldBufferPage29'
Created page 'HeightfieldBufferPage30'
Created page 'HeightfieldBufferPage31'
Created page 'HeightfieldBufferPage32'
Created page 'HeightfieldBufferPage33'
Created page 'HeightfieldBufferPage34'
Created page 'HeightfieldBufferPage35'
Created page 'HeightfieldBufferPage36'
Created page 'HeightfieldBufferPage37'
Created page 'HeightfieldBufferPage38'
Created page 'HeightfieldBufferPage39'
Created page 'HeightfieldBufferPage40'
Created page 'HeightfieldBufferPage41'
Created page 'HeightfieldBufferPage42'
Created page 'HeightfieldBufferPage43'
Created page 'HeightfieldBufferPage44'
Created page 'HeightfieldBufferPage45'
Created page 'HeightfieldBufferPage46'
Created page 'HeightfieldBufferPage47'
Created page 'HeightfieldBufferPage48'
Created page 'HeightfieldBufferPage49'
Created page 'HeightfieldBufferPage50'
Created page 'HeightfieldBufferPage51'
Created page 'HeightfieldBufferPage52'
Created page 'HeightfieldBufferPage53'
Created page 'HeightfieldBufferPage54'
Created page 'HeightfieldBufferPage55'
Created page 'HeightfieldBufferPage56'
Created page 'HeightfieldBufferPage57'
Created page 'HeightfieldBufferPage58'
Created page 'HeightfieldBufferPage59'
Created page 'HeightfieldBufferPage60'
Created page 'HeightfieldBufferPage61'
Created page 'HeightfieldBufferPage62'
Created page 'HeightfieldBufferPage63'
Created page 'HeightfieldBufferPage64'
qtEditor: /opt/scape/Engine/HeightfieldGeom/HeightfieldGeomMaterialSplat.cpp:797: virtual void ScapeEngine::HeightfieldGeomMaterialSplat::bindShaderConstants(): Assertion `technique' failed

Looking at that source file, it looks like technique would be null? I'm curious if this is due to using an outdated version of Ogre

I'm on Ubuntu 20.04. I compiled Ogre myself using v1.12.6

There are some custom types implemented for Vector, Matrix and Quaternion.
I don't think that this is necessary because Ogre has some own types for this.
I also believe that they have more features and have been tested much more.
Some custom types aren't used at all and I think that all others can be replaced by Ogre types.

• Noise GPU
• Directional noise GPU

the following work fine

• Noise CPU
• Soften GPU
• Eraser GPU

Some keyboard shortcuts have been defined in the config.json file inside the ButtonDefinitions section.
There is no way to change this except to change it directly in the file.
One should implement a dialog to change this easily from the program.

I think it might be useful to add support for OpenEXR in importing/exporting images.
According to their website they have:

Support for 16-bit floating-point, 32-bit floating-point, and 32-bit integer pixels.

If I understood it right, OGRE itself even has OpenEXR support by the EXRCodec plugin, which, however seems to lack some features:
https://github.com/OGRECave/ogre/blob/cd252a4e151fb5aa8550db016963a098c29ee9f0/PlugIns/EXRCodec/src/OgreEXRCodec.cpp#L60-L64

So far, I noticed that there are 4 different configuration file formats used:

• XML
• Ogre::ConfigFile
• Some own hierarchical format defined in the SettingsDataset class.
• Some serialised format which belongs to wxWidgets (link). (This file is unused anyway.)

I think it might be useful to keep only XML and Ogre::ConfigFile and drop the other ones.

System Information

• Ogre Version: v1.11.0
• Operating System / Platform: Debian GNU/Linux 9 (stretch)
• RenderSystem: RenderSystem_GL
• Graphics Device: Nvidia GeForce GTX 660

Detailled description

I managed to compile the tool.
It does start and I can see the window.

It displays the SkyBox and the terrain (in which im not sure, if it does that right).

Most importantly, there are several errors in the log, saying that the GPU operation shaders didn't compile.
Mainly they are issues complaining about some "exceeded limits".

I don't think this is an issue of my hardware, since I use a relatively up to date graphics card.
I think this has something to do with the profiles in the GPU2DOperation.material file.

Scape.log (only the important part)

error C6002: Instruction limit of 1024 exceeded; 1296 instructions needed to compile program
error C6002: Instruction limit of 1024 exceeded; 1320 instructions needed to compile program
error C6007: Constant register limit exceeded; more than 32 constant registers needed to compiled program

In the code every string constant is wrapped in the _T() macro.
According to (link), this is used for Unicode support.

Apart from that i've never seen this macro in any other source and if I understand it right, OGRE_WCHAR_T_STRINGS is used for this purpose, too.

Would it be useful to remove all the _T() macros (using Regex maybe) and use Ogre::String everywhere?

Someone defined a property mechanism by UIElementClasses.
I think that way was chosen to work with the EngineInterface class (#36) and to be easy to serialize.
One could use the classes directly to avoid type conversions from and to string.

In some places header includes are missing. (#include)
One can also break the build by changing the order of the header includes.
Moreover, the build doesn't work well on some systems.

While I was looking around and searching for a GPU implementation/shader (just out of interest), I noticed that the CMake script in the "Dependencies" folder uses the external zip file ScapeMedia.zip.

I also noticed that this zip file contains some shaders.

Wouldn't it be more useful to include the contents of this file into this project and to manage the files (especially shaders, since they contain a kind of application code) here?