Random System Generator app - Textures/Configuration issuses

[Bill2462]

Hi!

I'm not quite sure if this is the right place to ask this questions but anyway (: 

I'm writing a random planetary system generator for KSP. It is an app written in C++ and designed to randomly generate a whole solar system with all necessary configuration and textures. For importing everything into a game, it uses Copernicus.

The whole idea is to make it as simple as writing configuration for a generator,  launching an app and copying results into gameData.

So obviously I can't use any external editor to generate textures for the system. 

So far I've managed to generate random properties and terrain without major problems. 

But I've encountered two major issues with : 

1. Normal map generation.

2. Creating simple Copernicus configuration that just adds planets with all necessary properties and PQS mods. 

Problem with normalmap is quite weird : 

My generator uses LibNoise library to create random terrain and then lodePNG library to convert results (BMP file) into PNG. 

Example generator output :

Heightmap :

 

Colormap :

 

Normalmap : 

 

Unfortunately, the map view is broken  (Planet looks like ideal sphere without any mesh) : 

Also, something is not right with the planet shadow :

It is probably caused by a wrong normal map.

But I have no idea how to fix that.

 

The second problem is connected with Copernicus configuration . 

Generated copernicus cfg looks like this:

@Kopernicus:AFTER[KOPERNICUS]
{
 Body
 {
     name = Cyran

     Template
     {
         name = Moho
         removeAllPQSMods = true
     }

     Properties
     {
         description = This planet was randomly generated
         radius = 370000
         geeASL = 0.6
         rotationPeriod = 525178.380846
         rotates = true
         tidallyLocked = true
         initialRotation = 0
         isHomeWorld = false
         timewarpAltitudeLimits = 0 30000 30000 60000 300000 300000 400000 700000

         ScienceValues
         {
             landedDataValue = 2.484671
             splashedDataValue = 2.757956
             flyingLowDataValue = 2.402657
             flyingHighDataValue = 2.481151
             inSpaceLowDataValue = 2.797260
             inSpaceHighDataValue = 2.140740
             recoveryValue = 2.842828
             flyingAltitudeThreshold = 12000
             spaceAltitudeThreshold = 2.289556
         }
     }

     Orbit
     {
            referenceBody = Sun
            color = 0.415686,0.352941,0.803922,1
            inclination = 1.27
            eccentricity = 0.0127567
            semiMajorAxis = 409355191706
            longitudeOfAscendingNode = 259
            argumentOfPeriapsis = 0
            meanAnomalyAtEpoch = 2.27167344093323
            epoch = 99.6799999999973
     }

     ScaledVersion
     {
         Material
         {
             texture = randomSystem/Cyran/Cyran_color.png
             normals = randomSystem/Cyran/Cyran_normal.png
         }
     }
     PQS
     {
         Mods
         {
             VertexHeightMap
             {
                 map = randomSystem/Cyran/Cyran_height.png
                 offset = 0
                 deformity = 12000
                 scaleDeformityByRadius = false
                 order = 20
                 enabled = true
             }
             VertexColorMap
             {
                 map = randomSystem/Cyran/Cyran_color.png
                 order = 20
                 enabled = true
             }
         }
     }
 }
}

 

Configuration structure is defined in generator source code. Only parameters are changing (they are randomly generated). 

Problem is that heightmap looks quite nice but resulting terrain does not. 

It is surprisingly boring and flat. 

 

My question is: What kind of Copernicus configuration structure I should use to get nice terrain out of heightmap? 

 

Please excuse bad english (: 

Edited September 8, 2017 by Bill2462

[Poodmund]

Unity handles normals a bit funky, this thread has some great info though: 

 

[Bill2462]

Thank you for your help (:

I found some more information about it in :  https://github.com/ducakar/TextureReplacer

Quote

Normal Maps

Unity uses "grey" normal maps (RGBA = YYYX) to minimise artefacts when applying DXT5 texture compression on them. When a normal map has a "NRM" suffix Unity converts it from RGB = XYZ ("blue") to RGBA = YYYX ("grey") normal map unless it is in DDS format.

In short: you should supply "blue" normal maps when a texture has "NRM" suffix and is in PNG format (JPEGs and TGAs are not recommended for normal maps) and "grey" normal map for textures in DDS format or without "NRM" suffix.

"Grey" normal maps can be created by saving the standard "blue" normal map as a DDS with DXT5nm compression or by manually shuffling its channels RGBA -> GGGR.

I will try to shuffle RGBA -> GGGR in gimp and hopefully this will work. 

 

 

Edited September 9, 2017 by Bill2462

[Poodmund]

The whole "Grey" moniker doesn't really make sense though as you can have any information in the Red and Blue channels when using DXT5, typically solid white or black, giving the normal map a very pink or very green look respectively. It will still function exactly the same. Saving an image as DXTnm does this automatically as it blanks the Red and Blue channels.

It should also be noted that KSP renders the ScaleSpace maps on the sphere from inside, like a 1st angle projection, which is why the planets look to be flipped horizontally in KSP to how they appear in your imaging program. Due to this, inverting the X Axis Tangent Space may be required.

Theres a good couple of articles here: http://wiki.polycount.com/wiki/Normal_Map_Compression & http://wiki.polycount.com/wiki/ChannelPacking#Swizzle

[Bill2462]

Problem with normalmap solved!

So far I did it in Gimp but adding this steps to generator source code shouldn't be too complicated.

 

Simple instructions how to convert 'blue' normalmap to normalmap that can be loaded into KSP : 

1. Load normalmap into gimp. 

2. Decompose image into Red Blue and Green layers (using Colours ->Components ->Decompose).

3. Duplicate Red layer. 

4. Rename duplicated red layer to 'alpha'. 

5. Delete Red layer. 

6. Delete Blue layer. 

7. Create two duplicates of Green layer. 

8. Rename them to 'red' and 'blue'.

9. Compose  all layers into RGBA (using Colours -> Components -> Compose). 

10. Export final image. 4

 

No X axis inversion was needed. Look's like libnoise map exporter does this by default. 

 

But I still can't solve issues with copernicus configuration.

 

Planet terrain look's like this :

 

 

It is almost flat, but according to heightmap it shouldn't.

What I'm doing wrong? 

 

Edited September 9, 2017 by Bill2462

[danielboro]

perhaps you can find relevent code in this

 

[Bill2462]

I think I found a solution to Copernicus problem. 

Instead of hard coding Copernicus file structure into the code, I will write a parser that reads a template file and replaces specified keywords with generated values.  

This will allow users to easily modified Copernicus file structure without modifying the code. 

This also means that I don't have to care about Copernicus configuration  anymore.   
I only need to provide some example templates. 

I think I will use the configuration from outer planets mod as an example.