Hi all & happy new year! @Kassonnade , @binhthuy71 : - A .raw-terrain will work with playfield defined textures, if there is no ecf in the same folder. Ecf overrides a playfield's texture, full stop. Except... for the parameter 'colourChange'. That one is still functional. NoiseStrength may be, too. - Ecf/ splatmap worlds only support up to 5 different textures, but up to 8 different regions for texture placement, defined by splatmap distribution. (That's why I call them 'texture channels'). You can mix the same texture in different channels. - The optional 'deco-distribution by splatmap' in the playfield is tied to the 8 texture channels. A '1' means the deco will be placed on that position, if there is an amount of a corresponding splatmap's colour there. Splat1: [ 1, 1, 1, 1] Splat2: [ 1, 1, 1, 1] Will place the deco everywhere, just depending on the biome altitude and slope, as usual. May help to prevent snowy grass growing on stone... - Currently, the terrain replacements / cutouts (POI, lowest altitude flattening, possibly dugouts, too) don't fade splatmaps. From a mixture of texture channels you'll see only the first of the texture bunch per splatmap 'pixel', at full strength, ignoring all the pretty surroundings. This wasn't an issue when there were just single textures tied to altitude. Now it's my major headache... - The map edges are smoothed and mirrored to prevent 'edge walls'. Usually the mirrored 'butterfly' seams are hidden in flat areas, but in this map it's not. Large parts of that map are tied to an underlying seed, which made the edges very different and hard to blend together. This wrapping worked better in the classic procedural planets, but with the cost of losing nearly all control over the placement of terrain features. (Not sure about that 'under terrain'-thingy, haven't tested it yet. I guess it's the dugout's texture, with the number defining it's depth layers?)
Very interesting. I use symmetrical mode when sculpting the edges of the terrain. They mirror seamlessly that way. I'll be back to working on the map import once I've wrapped up some things IRL. I'm wondering if it would help for us to all be working from the same minimal test solar system. At this point I'm for eliminating all of the variables I can. Thank you for your work on this. Every bit helps.
Sorry to interrupt you guys, but have you already some finished maps or nearly finished? We are setting up a new "galaxy" and looking desperatly for some extra handmade height maps, even if it is for experimenting...i would send you the test results And of course: keep up the good work, maybe i try your complete guide myself. (when i have my new computer )
Keep up the good work guys, bigger is better and is inbound so it might be something you guys look at when they come, TM* soon ! What happens if our planets get 64 odd times bigger then ? Do the features just become blended to smooth I assume ? But wouldn't making a higher' bitmap then go outside the parameter ? I don't understand all of what you guys have done here but I like where your going with it.
I haven't touched the maps for a few weeks now, being busy at work & home with other things. Custom maps can be made with relative ease, as well as texturing, with the only difficult part (for me) to assign proper textures to slopes. This is a minor detail, but to make splatmaps that "understand" slopes from a simple grayscale height map is a bit tricky. Another tricky part is that even if a splatmap follows cliffs precisely, any modification of the height in the .ecf file will modify slopes and might force "cliff" textures where there should be grass or sand, for example. But that is really a minor detail. I am waiting for indications on what Eleon has planned for the playfield size and format. Now each pixel of the raw heightmap represents 1 meter of terrain in game. Having a lower resolution may lead to "smoother" features, if they don't want to make too big raw maps. Maybe it's possible to add local noise for each "pixel" but I don't know how they would do this, or even if they are going to make the terrains in "chunks" that would be stitched together, etc. Actual "terrain mapping" systems use layers (different layers for roads, water, crops & trees, etc) that are stored separately from the main "altitudes" map. Maybe such a system could be made, where the basic "elevation data" would be smooth (to keep the heightmap not too big) and then "layers" for features could be made to fit in a coordinates system. Land is made of large flat areas, long and smooth slopes, and a zillion tiny details that can be seen only when close by. These details don't need to be in a huge bitmap, or if they have to then they may be simple lines or shapes on an otherwise empty "image" (black where no "detail" feature). This can allow to have a 30 meter per pixel resolution for general elevation, and details like small channels and ridges that are added "locally" in another layer. Some "rocks" and big boulders could also be added to add local details, and if they are scalable they can be reused, mirrored, flipped / scaled everywhere to make more interesting terrain features. But I'm just making guesses here. I have to wait and see what they have in mind. To have "deformable" terrain everywhere might prove difficult to implement, or too heavy on systems for a game. And logically, who would succeed to carve a "hole" in the side of a cliff (imagine the face of the K2 in the Himalayas) without seeing a part of the mountain falling down? What if players can "cut" a steep mountain top from its base? Makes no sense. There has to be a hard limit somewhere. As for these "layers" to put details on a larger meters-per-pixel map, the color values could be used to determine the "dimensions /position" of the features. For example, in a 100 meters-per-pixel "elevation map", if you have to make a 5 meters deep channel (small creek bed) by 10 meters width, it could be represented by a single 1 pixel line (100 meters "wide") in the big "water layer" map with a value of 10% red (width) and 5% blue (depth / height), which would mean "10% of the line width, in the center of the line" and "5% of a 100 meter pixel height" . I don't know if they could define "deformable" zones with such a system, to avoid having all of the terrain being a 1 or 2 meters voxel grid.
I was thinking more along the lines of assets placed on planets over textures. For example a planet now is just 1300m round or flat which works outs to be about 8klm rectangle. Lets say they expand that right out to 32 times bigger than they are now so about 256klm long but rectangle in shape still. Do our tree settings in yaml now need changing or will it scale so chunk size increases and thus % of land vs trees stays the same, I see big issues either way. If it does scale we end up with maps with so many assets the triangle count will be out of this world, but if it doesn't scale it means a whole lot of yaml editing for every planet in the game to suit the new scale. In anycase it will be great to mess around with and find out, if we, for a loopy experiment lol, shrink a planet to be smaller, which we can do right now, we end up with the game spawning less trees per chunk, so I dunno how it works in that regard but all seems very odd.
Maybe they could try to replace 3d objects with sprites at greater ranges instead of relying on LOD models. Having forests & big boulders "disappearing" at range like we have now, on small or bigger playfields, is not a very appealing sight. There are converters in the Unity store just for this, I don't know if they could use something like this to keep assets density reasonable on scaled terrains, without cranking up the triangle count.
I don't work with Gimp, but I guess it has a standard "color picker" so just make sure you have the same values for red, green and blue channels and it should give you correct "gray". If values go from 0 to 255 then your "scale" will be 100% = 255 (500 meters), 50% = 127 (250 meters) etc.
Apparently, it doesn't matter how to do this in GIMP, because you can't save in Photoshop IBM RAW. I have no clue why they chose such a format that massively pay-gates planet creation, but until I get the Photoshop trial, no matter what formats I tried nothing good came of it. About the closest I got was something with roughly my map shape, but with an ugly mess of bumps that didn't come from my heightmap (wrong byte order).
HI! @Ithirahad (I don't think it's much of a decision of the devs - more of an Unity thing ) - The free paint program 'Krita' can read and wirte the raw that are used in the game. Internally it handles them as '.r16'. So before reading, rename your.raw to that format. Make sure that you use the correct ratios. For Alpha 7 fixed terrain this should be 8192 x 4096. (Stamps of Alpha 8 Experimental have different ratios. If you use the packaged stamps from the game, you can check the .png for the correct numbers.) Then change the pic in Krita, or save in a different format to modifiy the terrain in another program. To re-convert in to raw, (load your pic back into Krita,) export in .r16 format, and rename that format to .raw again.
@binhthuy71 Me neither I'm just passing info along. (But using that program now. Seems to be primarily made for tablet drawing. - Pressure-sensitive input may be useful for terrain sculpting, too.)
Just tried Krita and it impressed me so much that I went to MS and bought the paid version. It fills a spot that my Adobe CS5.5 didn't quite hit. Thanks again!
The devs could import or write file conversion libraries if they wanted to make things more accessible. Thanks nonetheless; I'll try Krita whenever my Photoshop trial runs out.
Looking at the Krita r16 (raw) output in a hex editor: The raw format is actually very very simple. Its basically just each 16bit value (2 bytes) written one ofter another. No header is used here. (no information on size, or proprietary stuff) Should be easy to write a simple converter to convert for example a png or jpg to the raw format. (plus point for adding some gaussian blurr to smooth over the 8bit input)
There is the free ImageJ solution I mentioned in one of my previous posts: https://imagej.nih.gov/ij/download.html It has some editing capabilities, and some decent filters like a generic "smooth" and adjustable gaussian blur, selection and draw tools, etc. It can work directly in 16 bit grayscale so no conversion is needed. The raw files in Empyrion can be opened in ImageJ by going to File > import > raw... and then selecting the proper dimensions which are usually the same as the corresponding png file for the "stamps". For whole terrain maps, these are usually in a ratio of 2:1 (2048 x 1024, 8192 x 4096, etc). Here is an example of what to select for the CraterLava_1.raw stamp, which is the same size as CraterLava_1.png : ImageJ can then export the file in various formats or save as raw again ( File > save as > Raw data... ) In the "terrains" folder, all "maps" in the raw format at size approx. 67 mb are 8192 x 4096, including the new SnowC5.raw, DesertC4.raw and NewLava2_V2.raw. The new TemperateC2.raw is 1024 x 512.
Thank you! I wasn't going to work on handmade maps again until things settled down post-8. It appears that it's safe to start again.
The only problem is the new format of "splats" which I don't quite understand. They're not "bitmaps" anymore, and to test if textures are appropriately assigned to surfaces (cliff or flat/ smooth slope) I need to "replace" stamps in their original folder. I did not test this yet.
