I'm setting up a server with custom made planets and I need to add more diversity to the planetary terrain. I've been looking for an explanation on how to implement the new splatmaps and if they work on dedicated servers. From what I can see to this point, we need a more modular approach to planet design and placement, it seems very scattered at the moment.
Theres splat maps and there yamls ready made in the default game now, just take them yamls ,change there name, edit them ,and save them as your own.
That really doesn't explain anything though. I need to know if splatmaps work on MP, where in the Yaml does it point to the splatmap, what are splatmaps and how to edit them. As it is now, I can make a planet look like Akua, but if all my planets look like Akua, then I don't have the diversity I'm looking for. As it is now, each planet is scattered throughout several different folders. We need a modular system for the planets instead of just a yaml crammed in a playfield folder. Everything that that yaml calls should be in that folder. Textures, maps, prefabs, terrain, and anything else should be stored in that folder so that way we can create a more diverse set of planets in each system. The way it's set now, I can make 50 planets, everything from Lava to Barren to Lush jungle worlds, but if you look closely...they all look the same. I tried to set a different seed for each planet and all that did was create 2 maps that conflicted with each other even though there was no main seed. Splatmaps look good and seem to be a step in the right direction, but we need just a bit more, and more explanation to what they are and how to use them, otherwise they're completely useless.
Splatmap terrains or any other custom terrains (xml) won't work on multiplayer (yet), as the devs haven't found a way to ensure that everyone has the same files and versions. I don't know if it would be possible, if everyone copied the files to the respective folders, but i doubt it. Anyway, here's how they work in SP (at least the things I know): In every playfield folder there is a terrain.ecf file, that describes the terrain. In there you will find the heightmap name, and the splatmaps that should be used for it. 1st line: { Material Name: NewAlien The Name of the heightmap raw file located in the content\terrains folder. It's also the terrain name that you put into playfield.yaml in the terrain section. HeightMapMax: "400" max. height the terrain is stretched to. SplatMap_1: "NewAlien_splat1.tga" SplatMap_2: "NewAlien_splat2.tga" Splatmaps to be used by terrain located in content\terrains folder. Those define the texture maps, you can configure/change in-game via the terraineditor ('te' in console). The splatmaps are RGBA files, so you can say, you have 4 layers to work with, which means you can control 4 different settings by using colors red, green, blue and the alpha channel map to distribute things (and also a mix of those by defining values from 0 to 1 for each layer). That way you can set up a texture for the red layer with and effect of 0.5 and for the blue layer you have set up another texture with also an effect of 0.5, so in conculsion you get a mix of two textures by 50% in that pixel/voxel. The child sections in the terrain.ecf are controlled by the terrain editor, so you can ignore then in the ecf file. Playfield.yaml: Under the terrain section in the playfield.yaml, you have to setup your terrain, here 'NewAlien'. The splatmaps can also be used to define the placement of biome clusters in playfield.yaml in v7. You still can use the old system, but as an alternative you also have the splatmap now to have better control of the biome cluster distribution. Here you can see that the biome cluster is applied to the alpha channel (layer) of the splatmap1. you could also define it for splatmap2, but which is not the case in this example. If you wanted to set up the biome cluster to use red color instead, you would change it to: Splat1: [1, 0, 0, 0] or both alpha and green: Splat1: [0, 1, 0, 1] Hope that helps, but as I said, only useable in SP (for now). /jmc
This is awesome, thanks. It's everything I asked for or could have asked. I understand why they don't work on MP servers, really the only thing transferred from the servers are Yamls. Great work on the Playfield Designer, you've saved me hours from hand writing the playfields. I promoted your work on my Empyrion Tutorial series on YouTube and Vid.me . Once I apply what you posted in my SP world, I'll give you more credit in my Tutorial video. ^_^
Wow, thanks a lot for the kind feedback and your fantastic tutorial video. If you need any further assistance or have any issues, feel free to contact me any time. As a side note: The reason i'm not updating a lot at the moment is mainly because i started work on v2, which should be a lot more userfriendly and then will include the sector editor as well. Also the biome and cluster editing will get some general overhaul and simplification in the process. /jmc
@jmcburn Thanks for the explanations. Although I don't know how far I'll get with DIY splatmaps it's always good to know how things work.
Are the "exampleplanet" and "examplespace" yaml files up to date? Is the info in there still reliable? Are the splatmaps also used to define slopes? Where (coordinates) do the rectangular splatmaps fit on the square heightmap?
They are quite up to date, as far as i can see (AllowSV is already in). Just the splatmap info isn't in there yet. And no, they cannot be used to define slopes, as far as i know. The heightmap also isn't square, it's the same aspect ratio as the splatmap (2:1), just bigger. So the splatmaps are simply stretched to fit the heightmap. /jmc
Thank you! I just had the wrong settings for the .raw heightmap import... Now it looks like an usual greyscale, 4096 x 8192. As for the splatmaps, when pixels show different values on 1 channel (lets say red 80 vs red 128 ) what does it represent? When pixels have 2 colors mixed I guess they can support textures / deco fitting both channels? Also, in the playfield directories, there are lo_map.raw, lo_map_n.raw, map.raw and map_n.raw ; what are these, and how are they generated? How is the in-game map made, and the one viewed from space on the planet? In the terrain directory, what is the use of the dll files for each type of terrain?
Careful, there are two maps stored in the raw file. That's why i'm still hesitant to release my converter for RAW->PNG and back. Because i don't know, what to do with the second map. But it's causing issues in game, if i ignore it. I think it has to do with LOD, as it is a 'stepped' grayscale map. Here's the NewDesert Example: Just screenshots, as every extracted PNG has 60MB each. Main map (screenshot): second map (screenshot): This layered pattern describes an addition/subtraction to the first map, i'm guessing, where black is no change and white maybe 1 height difference. But i don't know yet. Splatmaps as i understand them: each color channel can represent one texture in game, so with RGBA you could theoretically use up to 4 textures for each voxel, all mixed by the values in the in game terrain editor. For biomeclusters, i think, you can only put 1 in for each channel (Never seen any decimal values in there, but haven't tried yet). But it makes no sense to use 50% of one cluster and 50% of another for same voxel. That way you would stand on a voxel in game that would partially be in "TropicalForest" and partially in "Openplains". That would also cause issues with CreatureSpawning then, i think. /jmc
Your 2nd map was what I obtained when importing in photoshop at first. Searching around Unity forums and blogs I got a few clues and after a few tries I got a normal greyscale map (your 1st image). The 2nd image was square when I imported it because photoshop simply did not detect the right dimensions. The map was also flipped vertically. It also showed these strange patterns because photoshop needed to convert to proper grayscale to allow me to change the "interlace" order to "not interlaced". After this it imported correctly. I read that some imaging programs like photoshop have an habit of making a user profile on first imports and leaving it that way afterwards, so I had to find a way to "update" it. Now all raw maps import as proper 16 bit grayscale. So to import the raw image in photoshop : "open as" and choose "raw" set width 8192 and height 4096 channels count : 1 depth 16 bit byte order IBM pc Then I flip the image vertically, and it fits with the splatmaps. In the splatmaps some pixels are present in many channels, and they show as a mix of (ex) blue and red, or blue and green. If I isolate each channel I can figure out they represent different aspects of the terrain, but still there are overlaps. Here is a part of the "new temperate" splatmap 1: You can see the "overlaps" as pixels with values of red & green or red & blue. If I look at the ecf file in the "new temperate" playfield I can see two channels used for "child 2" : { Child 2 Brightness: "1" Saturation: "1" RGB: "(1, 1, 1)" AddCol: "1" ReliefStrength: "0.1" NearScale: "0.4" DistantScale: "0.06" TerrainId: "33" TerrainLayers: "0" UnderTerrainId: "33" SplatMap_1: "(0.1, 0.0, 1.0, 0.0)" SplatMap_2: "(0.0, 0.2, 0.0, 0.0)" What are these "child" things ? Do you know?
To edit the raw image I had to convert it to 8 bit (I made a closed shape in the middle). After editing I converted it back to 16 bit and flipped it vertically: It looks like this in game : There were a few ripples on the ground just beside the edited part (coarse texture). I guess I could have simply made it as 16 bit RGB for the editing, then convert it back to 16 bit grayscale. I use a very, very old version of photoshop, and surely I loss some smoothness converting to 8 bit. It should be easy to at least make a few custom edits to actual terrains with simple modern image software. All I have to check is how the "cliffs" are to be textured by the splatmaps, because evidently the slopes on my edited shape are covered with grass, and the engine did not rely on the heightmap to apply proper textures. To make a custom splatmap I have to know how to extract it, probably using another antique program that can do the job by using custom colors for different cliff / slope values. The playfield yaml uses altitudes, and slopes are defined by numbers (degrees?), but still the splatmaps have to match the terrain.
Yeah, I had some similar results already with my importer. https://empyriononline.com/threads/tool-empyrion-playfield-designer-v1-36-1.9789/page-30#post-173683 Sadly, with newer photoshop versions like CC2017, when you choose 'Open As...', you only have the option to choose between camera raw and photoshop raw, both of which do not have any settings and photoshop just aborts on loading the raw with 'unknown format' error. Irfanview can read it with some playing around with the settings, but then i couldn't convert it back to a proper raw map after editing. So i've written this little tool to extract the map bytewise into a png image. I'll give it a try with 16bit, that could work as the size of the raw then would fit again. That could be the issue. But then i wouldn't know, into which common image format to convert the raw to edit it, as you would lose 8 bits of information, as every common image format only uses 8 bits per color, maybe 10, as far as i know. And i think, Empyriopn somewhat makes use of the extra precision, as you have 512m high terrains, and with only 8 bits you can only represent 256 height steps, this maybe could look strange in some situations. So i would have to write my own image editing tools, which could end up in a real mess. Regarding the splatmaps: I too can only speculate. I would have to test around a bit for myself there. /jmc
I found out that I lost smoothness on all the terrain. Will work on this... damn... I saw that some used Gimp to import / export raw/data to unity. They simply change the extension prior to import in Gimp, since the raw format used is sometimes not recognized.
After a reload of the game I see square columns and holes, something similar another player found on his server after a patch. This is coherent with the 2nd image you posted in your message up here : white pixels right next to dark ones. What is strange is that the whole terrain is not like this, just a few pixels. Since that player found that as a bug, I don't know what to think. The terrain generator seems very picky, and I did not see these artefacts the first time I loaded the game.
I had some similar issues. How big is your raw after saving, if it's not 64MB again, but 32, you lost the upper bits (or the detail map, whatever it is now), which would cause those issues, as the terrain generator maybe is picking the next pixel in your raw map as the upper bits, and that can cause issues, of course. Especially, if they are completely different shades of gray, otherwise, it won't make much problems. So in some areas will be holes/columns and in other areas it will look just fine. But this is all just speculation, without an image editing program that can handle and save back 16bit raw files, i don't think, we have a lot of testing possibilities. So i didn't continue very much on the project lately. I was hoping to get some insight from the devs, but i have no answers there yet. /jmc
The file remained the same size, but after a close look it lost details from the conversion. Since we're talking about very close shades of gray it was not obvious, but after conversion to 8b and back to 16b isolated pixels were visible. Water edge also changed, beach wall full of spikes, etc. Thanks for the hints anyway, I will take it easy like you since there is no easy way to edit 16b raw images for now. I installed the latest Gimp (experimental) which is supposed to be able to do it, but to load a 16b raw image I have to build the importer... Maybe I will try working with tiff format or something like that. And I agree we are searching tiny matches on the floor in the dark without some cues from the devs. Which only makes your playfield designer more of an impressive gift to the community here.
Hi all! Square columns and holes: @Kassonnade : Don't know how big are those you encountered, but- The game saves terrain height data even when you're not digging: Close to picked plants, where mobs reside, and sometimes just for fun! (...it seems). If you modify the terrain (=e.g. change the value for terrain height in the ecf, use a modified .raw or different .xml), then these previously 'saved' places stick out. Delete the 'areas' folder of the savegame to fix this. (You'll lose all your digged holes.) Terrain/Texturing - The name of the terrain in the playfield seems to be the important one. The name in the ecf will get adjusted, as soon you overwrite it with the texture editor. - playfield.yaml texture placement (altitude, slope) is ignored, if there is an ecf file in the same folder. Ecf and childs: - The ecf defines 5 different textures (='childs'), but the game is able to use 8 texture channels (=the number values, e.g. SplatMap_1: "(0.0, 0.9, 0.0, 0.0)"). These channels are shown in the terrain editor (te) at the bottom. - Those channels correspond to each a 'colour' of the two RGBA-splatmaps. The values of 0.0 to 1.0 are the amount the 5 texture 'childs' of the ecf are mixed to the those channels: '1' means this texture is mixed in to 100%, '0.5' means 50%. If you turn a texture to zero, and there is no other texture to fill that 'gap', the result will be a featureless and black patch. (It is possible to add all 5 textures on top of each other if you set in each child the same spot in of a splatmap to 1. The brightness and saturation of the textures will be added, too. So the result of this will be probably white and unsightly.) - Splatmaps with 'mixed' RGBA-colours mix the texture channels automatically by overlap. E.g. a 'Pink' region in splatmap01 has an amount of both texture channels/'childs' corresponding to splat01-R and splat01-B. Texture on steep walls and cliff edges: - The resolution of the splatmaps is much lower than that of the terrain. (Terrain 8192x4092 vs. splatmap 2048x1024- For an impression of the size of a 'pixel', teleport to Ningues and look directly down on a mountain snow patch). So for such steep walls to have a different texture, the upper and lower edges would get that texture, too. - There is no way to use splatmaps in a higher resolution. This seems to be hardcoded. ---- - Thanks for all the info about importing and the contents of the .raw. My guess for the strange 'stepped' map in the raw file: This is additional data to fill the 'middle values' between different 'whole /integer' altitude numbers, with a limited grayscale palette. It could be the terrain slope between regular altitude intervals.
