From time to time we will inform the community of certain areas of Skyline Development. If we have decided to add a new features or new demos in development etc we will try to make a post in this topic.Feel free to leave your comments to help encourage out development team ; )

v2.0 - Plans for the next level terrain

v2.0 - Plans for the next level terrain

Postby SolarPortal » 08 Jul 2020, 23:54

Today, i have been mulling over the concept of how to get more textures on the terrain without blowing up the memory budget and primarily focused on the splat maps as that has been the crux of the system as previously on all versions of skyline we had 5 textures. 1 basemap and 4 layers.

Splat maps

Each of those 4 layers had their own 8bit texture that associated where the texture was placed on the terrain.
So 4 channels(rgba) allowed 4 layers. However when scaling up to use more textures it would become memory hungry and would be quite a pain to blend all the channels of different textures to know whether a texture was there or not, and on top of that the ordering of the second splatmap would overwrite the first splatmap.
On top again of this, to paint or remove the texture from terrain would require iterating over 2 textures if the max was 8 terrain layers. However what if number of terrain layers was 128. This would require 32 different splat map textures with each channel filled. Quite a lot to bind to the GPU per frame at runtime. and of course would also use a shab load of memory.

What we have come up with is an approach similar to material ids where a colour is placed on a mesh and then the shader translates that to a material. However, this approach does not work well if you need to blend 2 materials together.
Enter the new system:
The new approach would be to have 2 textures for the entire chunk of the terrain(more to come later on this).
  • Texture 1 would be a 4 channel unsigned int which is 32 bytes wide; in each pixel we can store up to 32 layer ids and we have 4 channels, so in fact that is 128 layer ids per pixel. However we cannot blend that many textures so setting the number of terrain layers per pixel will be 4. Why 4?
  • Texture 2: This texture will be a standard RGBA texture holding an 8bit alpha value on each channel for each of the 4 terrain layers that were assigned for the previous texture. This allows us to use the full bit depth range for blending which means we wont have any stepping and the overlaps will look as smooth as they are now..... ( getting there :P )

Essentially this new technique will allow us to use 128 texture layers with 4 active layers on one pixel at a time. so you could blend your grass to your mud and rock and one other, but on the next pixel you could use 4 different textures. Remember that painting with a brush you cover many pixels on the splat maps and generally unless edge blending, only 1 texture would be used per pixel on the texture.

This is also hyper efficient on memory as scaling up to 128 textures with separate splat maps would not be as intensive on memory as separate channels per splat map as we use only 2 textures for all data.

For instance, with the old system, if scaled up to 128 textures; it would have 32 textures with 4 8bit channels. So for a 1024x1024 splat map assigned from the front of the terrain editor, would use: 128mb of memory but remember 32 textures ( limit of GL is 16 )
With the new system we have 2 textures, one 32bit wide per channel which is 16mb and another 4mb for the alpha data texture talked about before. Again only 2 textures for all 128 layers.

Scaling up to 2048 and 4096 will see 4x or 16x the amount of memory on both. On the old way of doing things at 4096 would use 2Gb of video memory to store all the 128 splats in 32 seperate textures of 4096 width and height, however on the new system only 320mb would be used... quite a big difference from unusable to very much usable even on older cards that dont have as much memory.

More details of the first texture: This is the layer ids storage and as mentioned before we could store 32 layer ids per pixel per channel using "bitwise inclusive or" operations. Bitwise for those that dont know is a useful ability to shift up and down the binary codes..e.g. "0000 0001" would represent an 8 bit value of the integer 1. We are using 32 bits so that looks like "0000 0000 0000 0001" for the same value of 1. But means we can store 32 options inside a single 32bit integer.
Each channel of the texture would represent a terrain layer id range, for example
  • Channel 0 = 0 - 31
  • Channel 1 = 32 - 65
  • Channel 2 = 64 - 95
  • Channel 3 = 95 - 127
Giving us storage of all 128 layer ids in a single texture.
However, if you only needed 32 textures for your terrain, we could reduce down to 8bit unsigned ints to make use of the 0-255 range instead of 0 - 4,294,967,295 which is 32 bit.
Bitwise works by bitshifting. so for example a 0-256 range would allow us to store 8 layer ids per channel giving us a total of 32 terrain layers.
  • bitshift left: 1<< 0 = 1
  • bitshift left: 1<< 1 = 2
  • bitshift left: 1<< 2 = 4
  • bitshift left: 1<< 3 = 8
  • bitshift left: 1<< 4 = 16
  • bitshift left: 1<< 5 = 32
  • bitshift left: 1<< 6 = 64
  • bitshift left: 1<< 7 = 128
  • bitshift left: 1<< 8 = 256
This will be an option on the terrain editor of how many textures you want maximum and the shader would then change depending on which option is selected as an 8bit texture would use only 4mb like the alpha for a 1024x1024 texture of 32 layers.
Thats 2mb over the 4mb ( 1024(width) x 1024(height) x 1(byte) x 4(textures) ) used of the older system for 32 textures instead of 128 textures. Remember the math scales exponentially.

Ok, enough math as ive probably lost a few of you already lol :P

Its all down to the fact of how we can increase the number of layers without exponentially increasing memory usage over just a simple splat map and how we would combine that data in the shader to know what layer goes where without overriding the previous 4 layers.
Because with the new system you could use layer 2 and layer 30 and the texture data would have the correct information stored and be able to blend those 2 layers without having to load different textures to access their blend map data's.
It does mean that importing or exporting a terrain layer blend map would be a bit harder for us, but you guys would not see that side of things.. it would just work.

Paged terrain and large scalable worlds

Next is the plans on how to make that infinite world. This problem is much simpler.
Basically as you go around the world(could be millions of units), you would have a set amount of chunks around you at all times, this could be 16km of tiles but the magic comes down to how we handle the painting and editing of the terrain at that scale.
One issue we all know is that if we create a larger terrain, we lose resolution of both painting and editing.
The new terrain paging will use similar size tiles all over and start to use a new texture when the size of an area enters a new coordinate, could be based on each tile or could be based on a set number of tiles. These set number of tiles would share a splat map and the tiles next to those a different splat map and so on.
These would be loaded and unloaded on the fly.
Keeping tiles to a same dimension regardless of the overall terrain size would for this example, imagine that the highest resolution you could edit would be 1m polygons. You would be able to edit 1m polygons if it was a 16km terrain or a 1 km terrain as the terrain tiles or chunks would be loaded and unloaded rather than stretching them to based on an overall resolution currently set on the front terrain panel. You would now set the resolution of a chunk and a world size that you wish to use.. this could become a editor where you make a grid that represents your world.
Now generating terrain data on the fly is intensive, so when a tile is generated it would cache the data for that coordinate to disk so when the terrain chunk is unloaded, it would reload from the disk cache rather than generating again. When editing we often edit up to 4 chunks or more depending on brush size when editing edge seams or larger brush sizes which might encompass more than 4 tiles at once(typically why is gets slow to raise a large portion of the terrain).
This wouldnt be too different, until it comes to painting. Since we might have more than 1 splat map now to keep good resolution even when editing a large world, we would now be required to edit the data of the splatmaps based on brush size and location. Only having to update a minimal amount of textures to paint will be much easier than seperate splats.

For Instance if the splat maps were like the old one and you edited over 4 splat maps(corner of each for example), that would be 128 x 4 texture edits... yikes, hope you have all year for one mouse click. Now we would only edit 2 x 4 = 8 textures if you edited at the seams of a paged terrain splat maps. Still quite intensive though.....

So what if we utilised the GPU with its mighty power and did the work on a compute shader. 8 textures would probably be doable in 2 compute shader calls.. Texture 1(layer IDs) x4 and texture 2(alpha blends) x 4. Now that would probably start happening in real time if we can keep the textures sizes to a minimum.

Remember that because the terrain would be fully paged and we would have multiple maps to keep resolution of the area, the texture sizes wouldnt need to be as big as they used to.. a 256 or even 512 could be the highest resolution needed to paint at a 25cm resolution.

Conclusion

So yeah, thats what ive been up to today, working out how to make more use of the terrain and the painting to get more resolution yet have a larger world, like seriously larger, perhaps infinite if you have the disk space haha....

These sames techniques can also be applied to vegetation like spraying grass, bushes or tress and keeping resolution rather than having like a 10m block of editing control at 16km lol :P

Hope you find it interesting, if you can understand it that it :P

How many textures do you guys think the terrain needs maximum ?

Edit:
I may have gotten something wrong as its all been purely theoretical today and is subject to change as looking and reading back it might be wrong that to fit bit 32 and a lower bit would be larger than a uint32, so bitwise range 0-16 would be used. But that is a problem for when i come to implement the whole thing... it would still be around 120-124 or 28 textures on an 8bit integer though :P
Skyline Game Engine - Lead Dev.
Please provide as much info as possible when asking for help.


Specs: OS: Win 10 64bit, CPU: Intel i7 3770 3.4ghz x 4 core(8 threads), GPU: Nvidia GTX 1060 6GB, Ram: 16gig DDR3, Windows on 250gb Samsung Evo 860

Twitter: @SolarPortal
Instagram: @SolarPortal
User avatar
SolarPortal
Skyline Founder
Skyline Founder
 
Posts: 3215
Joined: 29 Jul 2012, 15:56
Location: UK
Skill: 3D Modeller
Skill: 2D Artist
Skill: Programmer
Skill: Level Designer

Re: v2.0 - Plans for the next level terrain

Postby Sage1969 » 09 Jul 2020, 22:22

Maybe I misunderstand, does the "Foliage Plugin" not already spray decals? If so can something be done in that sense with a fade brush for terrain textures at cost of one call each? Probably grossly misunderstanding things. :P

If I could have 9 separate ground textures to blend for any one scene I would be satisfied. :D

Like the visions of large paged terrain. I was trying to figure out a script to preload maps adjacent to the currently occupied map so there was just a transitional pause/zone at any boarder.
User avatar
Sage1969
Skyline Padawan
 
Posts: 54
Joined: 29 Jan 2016, 08:13
Skill: 3D Modeller
Skill: 2D Artist
Skill: Level Designer
Skill: Concept artist
Skill: Great creative

Re: v2.0 - Plans for the next level terrain

Postby SolarPortal » 10 Jul 2020, 00:01

yeah, the foliage plugin does do a painting but like the terrain the density map for each grass layer is locked to the entire size of the terrain, so the larger the terrain, the less ability to spray or remove grass where you want it because the pixels get to big.

If I could have 9 separate ground textures to blend for any one scene I would be satisfied

9 haha :P And theres me talking about 128 textures lol :P

Like the visions of large paged terrain. I was trying to figure out a script to preload maps adjacent to the currently occupied map so there was just a transitional pause/zone at any boarder.

Yeah, it just wouldnt have been possible with the terrain meshes. If you wrote your own terrain in lua then yeah doable, but not with the current system.
However, what the next system is envisioned to do will be what you were after but keeping resolution also.

And not to mention what it would look like if it had tesselation :P
Skyline Game Engine - Lead Dev.
Please provide as much info as possible when asking for help.


Specs: OS: Win 10 64bit, CPU: Intel i7 3770 3.4ghz x 4 core(8 threads), GPU: Nvidia GTX 1060 6GB, Ram: 16gig DDR3, Windows on 250gb Samsung Evo 860

Twitter: @SolarPortal
Instagram: @SolarPortal
User avatar
SolarPortal
Skyline Founder
Skyline Founder
 
Posts: 3215
Joined: 29 Jul 2012, 15:56
Location: UK
Skill: 3D Modeller
Skill: 2D Artist
Skill: Programmer
Skill: Level Designer

Re: v2.0 - Plans for the next level terrain

Postby Sage1969 » 10 Jul 2020, 01:20

and as many of those 128 would be used as needed. I just want to have more than a single rock, grass or dirt to blend and hide patterns just the base textures eat up 4 slots.

Now if you get to 128 or even 64 you would want the ability to paint in a much finer and intricate detail. IMO
User avatar
Sage1969
Skyline Padawan
 
Posts: 54
Joined: 29 Jan 2016, 08:13
Skill: 3D Modeller
Skill: 2D Artist
Skill: Level Designer
Skill: Concept artist
Skill: Great creative

Re: v2.0 - Plans for the next level terrain

Postby SolarPortal » 10 Jul 2020, 14:43

agreed, the 4 layers we have had has been so limiting and on a large world didnt leave much scope for artistic design and change across the world. At least with this many you could create different biomes on one terrain.

If all you used was 9 textures, then the shader would compensate and only iterate for those 9 and back out.
There will be an obvious performance tradeoff between number of textures used. In this case, it could be an idea that the shader per terrain chunk only compiles the layers used to keep cost down. so 128 layers available but if only 4 textures were used on a chunk then the shader would only deal with those 4, on a different chunk it could be a diff set of textures of varying number.
Something for me to think about on that one but leaving scope for access of all these textures.

Now if you get to 128 or even 64 you would want the ability to paint in a much finer and intricate detail. IMO

Absolutely, the goal is to be able to at least the 0.25 of a unit as a default depending on performance / size of world / resolution of tiles / resolution of textures / resolution of splats lol :P
Skyline Game Engine - Lead Dev.
Please provide as much info as possible when asking for help.


Specs: OS: Win 10 64bit, CPU: Intel i7 3770 3.4ghz x 4 core(8 threads), GPU: Nvidia GTX 1060 6GB, Ram: 16gig DDR3, Windows on 250gb Samsung Evo 860

Twitter: @SolarPortal
Instagram: @SolarPortal
User avatar
SolarPortal
Skyline Founder
Skyline Founder
 
Posts: 3215
Joined: 29 Jul 2012, 15:56
Location: UK
Skill: 3D Modeller
Skill: 2D Artist
Skill: Programmer
Skill: Level Designer


Return to Skyline Development

Who is online

Users browsing this forum: No registered users and 1 guest

cron