CTS - Complete Terrain Shader

I have another plugin called TerrainImporter. I am using WorldMachine to create my terrain. TerrainImporter imports my .r16 height information, .png Texture/Normal, then creates a standard Unity terrain. When I add CTS to the terrain and then Create And Apply Profile my texture looks like it gets flipped. How do I prevent CTS from fliping my texture or flip it back to the correct orientation? I am using CTS 2019.

Thanks for testing & reporting back! Looks like bad and good news again, bad that is not working, but good that you were able to debug and find out that the first alphamap slot in the array is empty, even though it should be filled...I fear this might be an unity bug, could you please tell me which version you are using? (I was testing in 2018.4.0 and 2019.1.0)
I double checked how the alphamap arrays look like for me, they are both filled in slot 0 but what is suspicious is that on the original terrain that splatmap texture is also named "Splatmap 0":View attachment 445328
While on the new neighbor terrains it is called "Splatmap 1" even though it sits at index 0:View attachment 445331

Another thing that could play into this is that my scenario uses a CTS profile with only 4 textures while you use 15, maybe the issue with alphamap slot 0 being empty stems from there. If you could tell me your unity version I would try to replicate in that version with a profile with 15 textures.

Click to expand...

Where do these splatmap textures come from? Are they generated by CTS or by Unity?

EDIT: Been digging and still not sure where terrain.terrainData.alphamapTextures comes from. I wrote some debug scripts and a stock Unity terrain doesn't have any. Length of the array is 0. It isn't until I "Add CTS to Terrain" that the array length becomes 4 (on a working tile) but I can't figure out where in CTS they are getting set.

This is definitely an area of Unity where I'm not very comfortable but I'm trying to dig through it to figure out what is breaking.

This is using CTS 2019 and Unity 2019.2b6, however not currently using HDRP. Using CTS2019 for the instanced support

Click to expand...

I tried to reproduce the issue in 2019.2b and was able to reproduce it instantly, so this seems to be bound to the unity version. It looks like the issue you are experiencing is a unity bug in the neighboring system in this version: When I set up a single terrain with multiple textures on it (no CTS involved), and try to paint one of the textures over to a neighboring terrain, unity will throw this error message and will display visual glitches in the terrain inspector as well:

So it looks like there is some issue with the setup for splatmaps / texturing / terrain layers with the terrain layer system, in 2019.1 it is possible to paint over to a neighboring terrain with a texture without any issues.
Please note that 2019.2b is a beta version which we officially don't support for this exact reason: The beta versions can still contain bugs that are difficult to track down and can appear and be fixed again with any update to the beta.

I would recommend to only use the alpha and beta versions to check out the new unity features or to test for stability, but not for working on an actual project.

Can you please try to downgrade to 2019.1 to see if you can recreate the issue there? I will report this issue as a bug in the unity beta so it will be investigated before 2019.2 will release.

I have another plugin called TerrainImporter. I am using WorldMachine to create my terrain. TerrainImporter imports my .r16 height information, .png Texture/Normal, then creates a standard Unity terrain. When I add CTS to the terrain and then Create And Apply Profile my texture looks like it gets flipped. How do I prevent CTS from fliping my texture or flip it back to the correct orientation? I am using CTS 2019.

Click to expand...

For clarification: Are the single texture images flipped, or is the overall splatmap (the texture positioning on the terrain) flipped? Can you maybe post a before-after screenshot?
Normally CTS should flip neither of those two, it should take the orientation of the single textures as they are and bake them in its internal texture array, and normally it should also not touch the splatmap orientation as well.

I tried to reproduce the issue in 2019.2b and was able to reproduce it instantly, so this seems to be bound to the unity version. It looks like the issue you are experiencing is a unity bug in the neighboring system in this version: When I set up a single terrain with multiple textures on it (no CTS involved), and try to paint one of the textures over to a neighboring terrain, unity will throw this error message and will display visual glitches in the terrain inspector as well:

So it looks like there is some issue with the setup for splatmaps / texturing / terrain layers with the terrain layer system, in 2019.1 it is possible to paint over to a neighboring terrain with a texture without any issues.
Please note that 2019.2b is a beta version which we officially don't support for this exact reason: The beta versions can still contain bugs that are difficult to track down and can appear and be fixed again with any update to the beta.

I would recommend to only use the alpha and beta versions to check out the new unity features or to test for stability, but not for working on an actual project.

Can you please try to downgrade to 2019.1 to see if you can recreate the issue there? I will report this issue as a bug in the unity beta so it will be investigated before 2019.2 will release.

Click to expand...

This is why its GOOD to use Beta versions because now we've found a bug that needs to be reported so it can be fixed This might have gone unnoticed otherwise.

Thanks for posting the screenshots! After staring at them for a good while it looks to me that in the "After" shot, the terrain seems to utilize the terrain texturing of the lower left quarter of the "Before" terrain only:

This is very weird, as there is no code in CTS to actively scale the splatmap or only use portions of it - it always should use the full splatmap normally. Can you please check the following:

1. Can you please check if the terrains "Control Texture Resolution" setting somehow changes between "Before" and "After"?
2. Can you please check how the terrain splatmap looks and if it resolution changes between "Before" and "After"? You can find the splatmap inside the terrain's terrain data object in the asset hierarchy. If you are having trouble locating it, you can look at the terrain collider component, it has a reference to the terrain data object this terrain is using:

Inside the terrain data object you can see the splatmap that stores the texture distribution on the terrain, this is also the file CTS should use to decide which texture from the profile goes where:

It would be interesting to see if this splatmap texture changes in any way from "Before" to "After", if it gains or loses resolution, etc. Also the texture format at the bottom of the preview window (ARGB8 UNorm in my example) could be interesting if it changes.

I tried to reproduce the issue in 2019.2b and was able to reproduce it instantly, so this seems to be bound to the unity version. It looks like the issue you are experiencing is a unity bug in the neighboring system in this version: When I set up a single terrain with multiple textures on it (no CTS involved), and try to paint one of the textures over to a neighboring terrain, unity will throw this error message and will display visual glitches in the terrain inspector as well:

So it looks like there is some issue with the setup for splatmaps / texturing / terrain layers with the terrain layer system, in 2019.1 it is possible to paint over to a neighboring terrain with a texture without any issues.
Please note that 2019.2b is a beta version which we officially don't support for this exact reason: The beta versions can still contain bugs that are difficult to track down and can appear and be fixed again with any update to the beta.

I would recommend to only use the alpha and beta versions to check out the new unity features or to test for stability, but not for working on an actual project.

Can you please try to downgrade to 2019.1 to see if you can recreate the issue there? I will report this issue as a bug in the unity beta so it will be investigated before 2019.2 will release.

Hio, is there a way to avoid triplanar plopping between near and far? Otherwise blending works fine but with triplanar, textures seem to switch hard. Is there a way to get triplanar texturing for far distance too, so that they blend seamlessly ?

Hio, is there a way to avoid triplanar plopping between near and far? Otherwise blending works fine but with triplanar, textures seem to switch hard. Is there a way to get triplanar texturing for far distance too, so that they blend seamlessly ?

Click to expand...

I'm afraid that is not possible at the moment: Triplanar is currently active in both near and far rendering, the popping to non-triplanar is happening when you cross the LOD Distance where a cheaper version of the CTS shader is used to render the terrain:

What we could look into is to make triplanar a separate setting for near and far so that you could deactivate it for far rendering so it would blend in the near->far distance instead of plopping at the "hard" LOD distance.

Do you have planned a feature for far "bright" and "tint? It would be awesome to make, for example, a grass texture darker at the distance so the transition between trees being culled is less noticeable. (Or is it already? )

Do you have planned a feature for far "bright" and "tint? It would be awesome to make, for example, a grass texture darker at the distance so the transition between trees being culled is less noticeable. (Or is it already? )

Click to expand...

Not yet, but I will add it to the list for "things to look into for future updates", thanks for the suggestion!

Maximum number (256) of shader global keywords exceeded, keyword _MAIN_LIGHT_SHADOWS will be ignored

I get this 7 times in my console and when I click on it. surprisingly it takes me to a CTS script. Cause usually that error doesn't take me anywhere lol.
I understand its from having to many shader keywords.

But it takes me to this script on the CTSShaders Class
Is CTS always using these Shaders all the time? or what ever its doing lol?
Wondering if its tripping the keyword limit for no reason.

But it takes me to this script on the CTSShaders Class
Is CTS always using these Shaders all the time? or what ever its doing lol?
Wondering if its tripping the keyword limit for no reason.

Click to expand...

I do not know 100% how the 256 keywords limit is calculated, but as far as I know even unused shaders can count towards that limit. If I remember correctly you are using CTS 2019? If so, you could take a closer look at the "Shaders" folder, and deactivate Shaders that you don't need. The contents of the Shaders folder are built up as follows:

The Shaders sitting directly in the "Shaders" directory are the ones for the built-in rendering pipeline. Then there is a folder that is just a SRP version number, in the screenshot above it is called 5.7, under Unity 2018.3 you see 4.8 instead. This folder contains a LWRP and a HDRP folder which - you probably guessed it - contain the shaders for the respective rendering pipeline.
The library folders contain .txt files that will be converted / renamed to shaders when required, but those should not matter regarding your issue.

Depending on which pipeline you are using, you can delete, or rename the unused shaders:

If you are using built-in rendering only, you can remove the contents of the "5.7" folder (just leave the folder itself intact, otherwise CTS will just reinstall the shaders again from the library after a second!)

If you are using HDRP, you can remove the shaders in the "Shaders" directory, and in the 5.7\LWRP folder

If you are using LWRP, you can remove the shaders in the "Shaders" directory, and in the 5.7\HDRP folder

This should free up shader keywords in your project so that you don't see this message again. We have it planned for a future update that CTS will activate & deactivate the shaders according to the currently activated pipeline, so that this action will be performed automatically then.

Thanks man always big help.
I have a pretty large keyword issue atm. I fixed it once but it came back after upgrading to 2019 it seems.
It's hard to figure out what shader is using g a ton of keywords.

Thanks man always big help.
I have a pretty large keyword issue atm. I fixed it once but it came back after upgrading to 2019 it seems.
It's hard to figure out what shader is using g a ton of keywords.

I use unity2018.3. Can I make the HDPS version of CTS 2019 support 4.9? Because RAM 2019 uses HDRP4. 9. Otherwise, these two plugins will not work properly in my project.

Click to expand...

Officially CTS only supports SRP 4.8 in Unity 2018.3 & 2018.4 and SRP 5.7 in unity 2019.1. These limitations have to do with the HDRP version not being compatible with each other: every new version adds, changes or removes stuff which makes it difficult to create new shaders for every version that is coming out.

However if you are willing to experiment a bit, you should be able to get CTS running in HDRP SRP 4.9 as well. To do so, you would need to do the following:

3. Open the file system and drop the two files from the zip file in the attachments in the Package cache in your project. The Package cache directory is at the same level as the "Assets" directory in your project folder. The exact location you need to put them in is:
Library\PackageCache\com.unity.render-pipelines.high-definition@4.9.0-preview\Runtime\Material\TerrainLit
(Those two files are part of the HDRP 5.7 package normally)

5. Copy the HDRP folder from
Assets\Procedural Worlds\CTS\Shaders\Library SRP 5.7 over in the 4.8 folder

6. Inside the 4.8/HDRP folder, remove the "file" suffix from all extensions so that
".shaderfile" becomes ".shader",
".hlslfile" becomes ".hlsl"

7. Make sure the renamed files show up as shaders in unity after the rename, if in doubt right click on the 4.8/HDRP directory and select "Reimport". After this step, CTS should run with the 5.7 shaders in a 4.9 HDRP project.

Officially CTS only supports SRP 4.8 in Unity 2018.3 & 2018.4 and SRP 5.7 in unity 2019.1. These limitations have to do with the HDRP version not being compatible with each other: every new version adds, changes or removes stuff which makes it difficult to create new shaders for every version that is coming out.

However if you are willing to experiment a bit, you should be able to get CTS running in HDRP SRP 4.9 as well. To do so, you would need to do the following:

3. Open the file system and drop the two files from the zip file in the attachments in the Package cache in your project. The Package cache directory is at the same level as the "Assets" directory in your project folder. The exact location you need to put them in is:
Library\PackageCache\com.unity.render-pipelines.high-definition@4.9.0-preview\Runtime\Material\TerrainLit
(Those two files are part of the HDRP 5.7 package normally)

5. Copy the HDRP folder from
Assets\Procedural Worlds\CTS\Shaders\Library SRP 5.7 over in the 4.8 folder

6. Inside the 4.8/HDRP folder, remove the "file" suffix from all extensions so that
".shaderfile" becomes ".shader",
".hlslfile" becomes ".hlsl"

7. Make sure the renamed files show up as shaders in unity after the rename, if in doubt right click on the 4.8/HDRP directory and select "Reimport". After this step, CTS should run with the 5.7 shaders in a 4.9 HDRP project.

Ya im aware of that free tool. It really isn't that useful to me. Its still a huge mess. Anyways i found a better tool in the asset store called Shader Control. That allows me to see the keywords way better.
Its really nice.

CTS originally created those materials whenever there were changes in the CTS profile which then would slowly pile up in the project. Newer CTS versions create a temporary material on the fly for this, but there is also a possibility to create such a persistent material by Disconnecting and Reconnecting the CTS profile. Disconnecting the profile is normally a performance feature, but as a "side product" it creates a material that you can use on a mesh for example. When you disconnect a profile, CTS will:

Create a persistent material in the Profiles\Material folder

Create persistent copy of the terrain splatmaps in the Profiles\Splatmaps folder

This puts CTS in a minimal state for a build to save memory and build size. When you reconnect the profile, all the steps above are reversed, but the material is still there in the folder. Try backing up your project and then Disconnecting / Reconnecting the CTS profile via the button in the CTS component, and then check the material in the Profiles\Material folder.

Thanks for your help Peter. Sorry I did not respond soon. We got busy and figured it out. We put the main Texture in the Terrain ColorMap. That worked. I thought the ColorMap was where you put the SplatMap

Performance is awful for me in the Unity 2018.3.1 I get 90 Fps with RTP + POW enabled and 55 Fps with CTS

Click to expand...

Did you resolve this performance issue? I'm trying to decide if I should use CTS or RTP, I already have both assets. I wish to target both PC & Mobile platforms with the same shader. Easy to use and quick to implement is also important, I'd take 15FPS less just for that.

This is by design, CTS only supports fixed SRP versions tied to certain Unity versions: HDRP / LWRP 4.8 in Unity 2018.3 & 2018.4 HDRP / LWRP 5.7.2 in Unity 2019.1 2019.2 went out of beta yesterday and we will support it soon in HDRP / LWRP as well. The reason for this is that the different SRP versions are not 100% compatible with each other and we need to adjust the shaders individually for each released version.

This is by design, CTS only supports fixed SRP versions tied to certain Unity versions: HDRP / LWRP 4.8 in Unity 2018.3 & 2018.4 HDRP / LWRP 5.7.2 in Unity 2019.1 2019.2 went out of beta yesterday and we will support it soon in HDRP / LWRP as well. The reason for this is that the different SRP versions are not 100% compatible with each other and we need to adjust the shaders individually for each released version.

Click to expand...

Do you have any (even vaguely accurate) timeframe for when the support for the newest SRP will come out?

Do you have any (even vaguely accurate) timeframe for when the support for the newest SRP will come out?

Click to expand...

Using the package manager you can often manually install an older SRP/HDRP version than he default in a given Unity version, thus allowing you to use CTS. This worked fine for me in an earlier build, but I haven' tried it yet in 2019.2, but will be looking into that when I get back from Siggraph. Its worth a try anyway.

In a test scene with a normal unity terrain its projecting fine but in our main scene with the terrain using CTS texture thing its not working

Click to expand...

Hi can you tell me please if this is a regular unity projector or if you are in HDRP and using the HDRP Projector component?
If it is a regular projector it could be worth a try to see if it is working when switching instanced terrain off, as far as I know there can be issues with the projector component and instanced terrain.
For HDRP I would need to check back again with shader development, iirc it was difficult to support it in the earlier SRP versions, but we might be able to support it now when we create the new shaders for Unity 2019.2 / SRP 6.9.

Hi can you tell me please if this is a regular unity projector or if you are in HDRP and using the HDRP Projector component?
If it is a regular projector it could be worth a try to see if it is working when switching instanced terrain off, as far as I know there can be issues with the projector component and instanced terrain.
For HDRP I would need to check back again with shader development, iirc it was difficult to support it in the earlier SRP versions, but we might be able to support it now when we create the new shaders for Unity 2019.2 / SRP 6.9.

Click to expand...

Hi,

using unity standard project and light projector shader that comes in the standard assets

not using HDRP in this project

yes the draw instanced option appears to be my issue, thanks

tho something is forcing the option back to true at runtime? would cts be doing that?

tho something is forcing the option back to true at runtime? would cts be doing that?

Click to expand...

Yes, that could be, there is an option for "Draw Instanced" in the optimization settings of the CTS profile, this setting will switch it back on again when it notices that it is not enabled on the terrain.

I've recently discovered that my previous and current game, has very low performance on amd video cards (Rx 580 & 590) to be more specific. On (Rx 580 & 590) video cards, my game had performance that was equal to Nvidia GTX 680 while, those cards are much more powerful than Nvidia GTX 680 and in every other game my friends had much larger fps on those cards compared to GTX 680. Both of my friends experience this issue. I've took Radeon Rx 590 from one of my friends to debug it and figure that CTS is a major contributor to this difference. For some reason CTS performs very poorly on those video cards compared to default unity terrain shader.
In my test scene, when I change CTS to unity default shader, FPS on RX 590 jumps from 90 fps to 132 fps! While on NVIDIA 680, with unity default shader and CTS shader I get basically same result (around 92 fps).

Do you have AMD video cards in the studio? Did you noticed huge performance difference between Nvidia and Amd video cards when CTS shader is being used?

P.S. My test project is using Unity 2018.4.5f1. But my previous game made with Unity 5.6 that is also using CTS.

Update: Did some more tests. Even CTS lite performs worse than default unity terrain shader on amd, although not by much.
CTS Lite: 119 fps
Unity default: 131 fps
And I don't use strip textures, cause plugin called Crux depends on texture information.

Did you noticed huge performance difference between Nvidia and Amd video cards when CTS shader is being used?

Click to expand...

We are currently not aware about a general performance difference / issue on AMD cards. What we did notice however since the release of the new terrain system with "Draw Instanced" etc. in Unity 2018.3 that we are getting reports of obscure cases where certain combinations of Unity Version / CTS Version / hardware trigger performance losses. These cases are often difficult to debug because the issue can disappear at the slightest change, so even if the user sends us their complete project it might not be reproduceable on our PCs.

Could you please try if you can reproduce the issue in the demo scenes that come with CTS as well? When you run them, you can switch through the various CTS shader types with the number keys on your keyboard, so you can compare between unity (1) and the CTS shaders (2-5) directly.

Then it would be great if you could take a look at the profiler in your own project where it shows the issue, and check if you can pin the performance difference down to a certain entry in the profiler hierarchy. If you are not familiar with the profiler, please do the following:

1. Start your scene
2. While the game is running, open Window > Analysis > Profiler
3. In the profiler window, you should see a performance graph appear, try to click in a "normal" flat area that represents the average performance of the scene like so:
(If you would select the spike instead, you would probably see some internal process of unity running in the results, which can be interesting on its own but would be less suitable for our comparison.
4. Switch to hierarchy view in the lower part of the compiler, and sort by "Time ms" descending.

5. You now have a list of processes that contributed to the CPU load for the frame you selected above. You can unfold this hierarchy to look at the sub-processes as well. It would be great if you could compare this list between CTS and Unity shading in your project to see if you can find one or more entries that create the difference in processing time.

It could also be that the difference is created on the GPU and not the CPU, you can add a GPU Profiler to the Profiler window and do the same analysis by clicking in the GPU graph then instead:

By investigating the issue from your side you could help us out a lot to pin issues like these down and then investigate further from our side and / or raise this with unity support as well.

We are currently not aware about a general performance difference / issue on AMD cards. What we did notice however since the release of the new terrain system with "Draw Instanced" etc. in Unity 2018.3 that we are getting reports of obscure cases where certain combinations of Unity Version / CTS Version / hardware trigger performance losses. These cases are often difficult to debug because the issue can disappear at the slightest change, so even if the user sends us their complete project it might not be reproduceable on our PCs.

Click to expand...

I've returned AMD RX 590 back to my friend so I can no longer debug it. I don't use instancing on terrain. The difference was entirely GPU related. GPU was a bottleneck, that's why I took RX 590 from my friend, installed it on my PC and witnessed same performance difference/issue. And GPU load was 100%. In the end, I've switched terrain shader from basic to lite, because I don't use any features a of basic shader and it gave a significant performance boost on AMD RX 590, while making almost no difference on Nvidia GTX 680. If you don't have any AMD video cards, it might be a good idea to get one.

This was originally sand that had cts tessellation applied to it and as you can see the heightmap tess depth isn't even that high. Whats strange is that the tessellation was working perfectly fine a couple hours ago and I don't recall changing anything.
The tessellation works fine up until tess depth .2 but extreme tearing happens after that. I'm using Unity 2019.1.8f1, SRP

Hmm, I think I have never seen anything like that and I'm not sure what could cause it. The tesselation density on top of the profile seems rather high, can you try how it looks if you reduce it a bit?

Other things you could try:
* re-bake your textures
* Try to create a new scene, add a terrain, add a CTS component and use your existing profile on it. Please note that when the terrain is 100% flat, tessellation might not work as good as if it has little bumps into its geometry because Unity will auto-optimize larger flat planes to use less polygons.
* Try to enable wireframe view and observe how the tessellatíon is applied when you increase the tessellation depth, maybe this gives some indication what is going on.
*Try to check if tessellation is still working in the CTS demo scenes, if it is maybe you can find something when you compare the two setups / profiles.

I just wanted to say I am also eagerly waiting for an HDRP update for CTS. Unity 2019.2 is the first version that says it supports SpeedTree now. I would really like to use CTS in this version with the HD Renderpipeline.

I've had this issue for a bit now and have tried to solve it many ways. Unfortunately CTS keeps screaming. I am using 2018.4.3 and have imported the PostProcessing Stack. It seems when I pulled in CTS there was no issue but now when I pull in certain assets I get the following error:

I've had this issue for a bit now and have tried to solve it many ways. Unfortunately CTS keeps screaming. I am using 2018.4.3 and have imported the PostProcessing Stack. It seems when I pulled in CTS there was no issue but now when I pull in certain assets I get the following error:

That sounds like you have a "namespace" issue in which Unity can't determine which "PostProcessLayer" name to use properly, since it's defined in two locations at once. This happens a lot when using a lot of 3rd party assets in your project.

I don't use the CTS Demo controller script at all in my games, so usually when I get these errors I simply comment the problem code statements out. For example, open up the CTSDemoController.cs script and find where the PostProcessLayer is defined and try commenting it out.

Sometimes asset developers try to code for multiple platforms at once, which can lead to some troublesome code. For instance, if there is a "WebGL" block of code, and you don't use WebGL, then you can comment out the WebGL related code...... but again it depends on what you want to use.

I would not delete anything yet unless you know what you're doing. You can always "uncomment" it out if it leads to even more errors. Just my suggestion -- don't do anything that you can't undo. Might be a good idea to backup your project as well.

Oops...

"Unity", Unity logos, and other Unity trademarks are trademarks or registered trademarks of Unity Technologies or its affiliates in the U.S. and elsewhere (more info here). Other names or brands are trademarks of their respective owners.