I’m working on a VR project! I learn stuff and share stuff, some of which is awesome!
In the last Developer’s Blog we learned that VR is Mobile VR is All About Optimization. I suggested that optimization should inform every aspect of development from beginning to end. Accordingly, I began with an island.
An island has the following optimization benefits:
- Sparsely populated
- Sparsely decorated
- Desirable destination (users should be willing, active participants in the immersion)
Immediately however, I ran into problems as evidenced by the following screenshot:
The discoloration of the huts is a shader issue related to the fact that it uses multiple legacy cutout transparencies. The issue was (or should have been) addressed here. The problem with the textures however proved to be much more insidious.
Being a problem related to both Terrain and resolution, a developer might rightly expect to find the solution in Unity’s Terrain>Settings>Resolution. Unfortunately, the resolution here refers not to pixels but geometry. The exceptions, of course, are Control Texture Resolution and Base Texture Resolution. Base Texture Resolution is very poorly named. It doesn’t refer to what should rightly be called the base/terrain texture. It refers instead to the resolution of the base/terrain texture mipmap. It’s a low res texture that gets swapped with the terrain texture when the player is far enough away that the difference is negligible. It can be ruled out as a culprit.
Control Texture Resolution is also poorly named. Unlike Base Texture Resolution however, which suggests complicity in Terrain texture resolution, Control Texture Resolution belies its importance. A better name for it would be splat map resolution. As such, it is right to suspect it as being responsible for our texture resolution problems. Experimentation reveals that you cannot specify the Control Texture Resolution parameter however. Every time TT’s “Apply procedural texture” is run, the Control Texture Resolution resets. Search results and consultation with SixTimesNothing reveals that Control Texture Resolution is tied to Heightmap Resolution. The workaround is to export your Heightmap, make a copy for safe keeping, embiggen it to the resolution you want your Control Texture Resolution to emulate, and then reimport it.
After all is said and done, increasing the Control Texture Resolution does not mitigate pixelation of the Sand texture. Experimentation showed it to have No Discernable Effect.
Since texture resolution is tied to the image’s size, a developer might rightly expect to find that the Sand texture is smaller than the Grass (Hill) texture. This is not the case. Terrain, however, uses something of a meta texture. This meta terrain texture is defined by the splat map and tiling parameters. To create a terrain texture, a splat map takes several different materials and tiles (repeats) them over the terrain’s surface. Think of each material (which in turn is made up of textures and shader instructions) as a pixel in the larger Terrain texture. Too few material tiles and the terrain texture looks pixelated (because they have to stretch). Too many, however, and the tiling’s repetition becomes evident and distracting. The developer must find an optimal meta resolution as defined through the tiling parameters.
Tiling is typically defined in the material editor. TT however accepts only textures, straight up. While it must tile behind the scenes, those settings are not readily available to the no-code developer. While this and the splat map may yet be responsible, we must move on.
I investigated texture compression schemes (as initially devised, also as determined in Build Settings) and file formats. Both had NDE.
Eventually I opened up a fourth (not including the cliff) texture slot in TT and added an image file. Astonishingly, it revealed that all odd-numbered texture slots became pixelated. Knowing this, I was able to devise a workaround.
Workaround for Terrain Toolkit’s Mobile Pixelation:
- Duplicate textures into the odd-numbered slots
- Make sure that the start and finish of odd numbered slots overlap
- Pile on the start point of the consecutive texture
In the above image, the finish point of texture one is buried beneath the start point of texture two. The start/finish points of texture 3 are similarly buried beneath the start point of texture 4. This works… relatively well. There occurs a seam at texture 3’s elevation however:
I manually painted the Grass (Hill) texture over the seam. Pixelation occurs at the seam but it is hardly noticeable. I suspect the pixelation issue to be related to the Control Texture Resolution/Heightmap Resolution issue. Specifically, I think it’s somehow related to the fact that Heightmap Resolution isn’t power of 4 (2049 vs. 2048).
Whatever the reason, the question begs, is free worth it? I’ve heard good things about Terrain Composer!
//edit, future Mike here. Terrain Composer has the absolute worst UI I’ve ever encountered. It will feature in an upcoming Scrutiny Saturday video.
In this case, TT may still be worthwhile since I’ve incurred all the time costs for you. Lucky!
In the next Developer Blog, LOD vs. Unity’s Paint Details.
A Note from Admin:
I hope you found this content useful. If so, please like and subscribe and consider contributing to
so that I can continue to produce great #gamedev and #game art content while battling cancer!
Subscribe and get ahead with the latest tech recommendations, tricks, and tutorials!
learnindiedev.com Unlike Udemy, this site will feature live lessons and game jam learn-a-thons (exactly what it sounds like)! Featuring No-Code Video Game Development, the only video course to become a published text book!
openforcommissions.com Why be hard to find? Upload your portfolio, change your open/close status with a single tweet, get paid!