Relief Terrain Pack (RTP) v3 on AssetStore

I want to use RTP again because of its mesh blender. For now I'm suing Unity 2018.4.2f and just get RTP from asset store but there an is error I get now.

Assets/ReliefPack/Scripts/ReliefTerrain/GeometryVsTerrainBlend.cs(694,12): error CS0121: The call is ambiguous between the following methods or properties: 'NormalSolver_by_CharisMarangos.RecalculateNormals(UnityEngine.Mesh, float)' and 'NormalSolver.RecalculateNormals(UnityEngine.Mesh, float)'



Also there is another error from mesh deformer asset I get after importing RTP.

Assets\ReliefPack\Scripts\ReliefTerrain\GeometryVsTerrainBlend.cs(706,12): error CS0121: The call is ambiguous between the following methods or properties: 'NormalSolver.RecalculateNormals(Mesh, float)' and 'NormalSolver_by_CharisMarangos.RecalculateNormals(Mesh, float)'

 

This is interference of 2 classes that defines RecalculateNormals() as an extension to Mesh class. RTP has it defined in GeometryVsTerrainBlend.cs in line 2851 while in your project there is yet another extension that also does it (probably the same thing). I'd suggest to try removing extension defined in my script (just remove this function and the end of my class and recompile. Then check if geom blend in RTP works as expected. Otherwise - take a look (search your project for) at the other implementation present in your project and check the difference or (in case it's not used nor critical) - remove that implementiation in NormalSolver static class.

Tom

 

Anyone have a screen shot of what the settings have to be set to in order to have snow viable on the terrain? My snow does not appear.

 

Hello.
I'm trying to use RTP in Unity 2019.4.14.
However, when I install RTP, I get the following error in the log when I start the Unity editor

Shader 'Hidden/Relief Pack/ReliefTerrain-AddPass': fallback shader 'Relief Pack/ReliefTerrain-AddPass' not found​

I removed and re-imported the RTP, but the error did not go away.
Do you have any good ideas?

 

Briefly checking I can not reproduce the error. Imported newest RTP3.3q (check yourside in verinfo.txt file in RTP asset folder) into Unity 2019.4.14f1.

Could you give exact setup? (LOD manager state after recompiling shaders, lighting path, platform). Also - does error impact rendering (might be error reported on non used shader as add passe is not always needed)?

 

I'm considering buying this pack, but I'm not sure about supported features and price is... well, quite significant for me, as I'm not a company and not from first world country. Does your shader pack supports HDR? Can I edit shaders source code for my project? How fine POM with silhouettes works, like, will I need hundreds of passes to display fine details on object's silhouette, or there's some optimization features? Is it only POM, no other techniques, like cone step mapping? Because AFAIK, POM can step over some small peaks on height map when viewing angle is very steep. I've seen your shaders support point sources, but does that include both self-shadowing and shadow casting? And how that shadow casting works, I guess, by default - using cubemaps?
To be more specific, I need to render planets using very HD textures, at least 8k*4k and with point light source very far away. That's where problem with POM and fine details for silhouette arise. I don't expect appropriate shadow casting on such distance and I guess I'll need to fake shadow casting myself without using cubemaps, but if your shaders using some other technique than cubemap for point light sources, that could be decisive factor for me buying your pack.

 

I'd like to make sure we're talking about my Relief Terrain Pack (wchich this thread is dedicated to) or my other product - UBER?

1. HDR is what Unity takes care of here - has basically not much to do with my shaders specific features. Both UBER and RTP handles it in both forward and deferred lighting paths.
2. Shader source code is included by default. It doesn't mean modifying shaders will be easy task (depending on what you'd like to do). RTP is based on surface shader. UBER is modified Unity Standard shader code.
3. POM isn't realised using separate rendering passes. It's computed in pixel shader functions (in loop - which you might refer to be as "passes"). Step size is customizable so that you can tune precision against performance. This custom implementation of Parallax Occlusion Mapping with secant search step (so it can minimize number of spets necessary to resolve it).
4. Silhouettes - this is something that only UBER handles. Still - perfect (artifact free no matter viewing angle) silhouettes can be achieved only using tessellation which both UBER and RTP can do. Then - we're not refering to POM at all as tessellation will do it granularizing mesh GPU side on-fly.
5. Shadows - tessellation provide mesh for shadow casting pass so it's fully casting/collecting suitable. As for shadows solved via POM. RTP doesn't support silhouettes nor writes into depth under shadow casting pass. It can only solve self-shadowing of bumps that come from heightmap. Shadowcaster see this geometry as proxy (regular mesh without bumps - RTP terrain that uses POM will not cast bumpied shadows on anything else). UBER can do more - it modify depth when rendering shadow casting pass. So - if you select silhouette POM UBER shader variant you can get silhouettes casted from object as well as it collects shadows from other objects inside its "heightmap bumps" (because regular rendering pass also can write into depth).

For your specific usecase which seems to be planetary system with a point light star in the center - you'll most probably run into trouble of objects being extremely large scaled. Existing solutions for such use case assumes that one plant can cast shadow on the other procedurally - that is planetary shader calculates which other planet spheres occludes a pixel accordingly.

 

Oh, sorry, I've meant UBER, ofc. Support link from store was at this post, I didn't though it's same page for other products too.

3. By passes I've meant surface search steps, yes. AFAIK, default technique is just making predefined amount of steps at an equal distance (except for binary search or other methods to find precise hit point), usually with optimization that makes less step when viewing angle is close to 90 degrees and more steps at steep angles, but I've heard there's some other more adaptive technique, though I didn't happen to know which exactly, so, maybe it's just what I've wrote - amount of steps depending on viewing angle. But I've read nothing about secant search step, so, maybe it's it. Also, I know that cone stepping, especially relaxed cone stepping, tends to find surface level at much fewer steps and also is much more precise, as it's practically never misses small bumps. I've tried to implement it, and I mostly did, but then I failed with silhouette implementation.
4. As for tessellation, I believe, I can't use it on such HD textures, because it'll probably ruin performance, and if I'd make tesselation grid less precise that won't give correct silhouette.
5. I see. Well, I'm impressed that UBER can cast silhouette in shadows, but yes, I guess I'll have to use procedurally generated shadows with my code anyway.

Ok, thank you. I guess it mostly fits my needs. Though, I'll think a bit more.

 

Following Error popping up in 2019.4.17 LTS . Wasnt there in 2019.4.16 LTS
maybe 25 Errors on different codelines. Allways same error.

Shader error in 'Relief Pack/ReliefTerrain-FirstPass': not enough actual parameters for macro 'UNITY_SAMPLE_TEX2D_LOD' undeclared identifier 'UNITY_SAMPLE_TEX2D_LOD' at Assets/ReliefPack/Shaders/ReliefTerrain/RTP_Base.cginc(1070) (on d3d11)

 

Sorry for delayed response. We all need to take some rest this time .
The problem here is that Unity (at last) introduced missing macros to sample specific lod levels of texture. As I used the same naming convention and Unity uses macro with 3 params (while RTP uses 2) the macro usage in code is badly used.

I'll introduce this fix in next minor update soon. Fortunately fixing the issue isn't complex - the easiest way we only need to undef Unity's macro and redefine it the way RTP uses it in shaders.

in RTP_Base.cginc and (simial part in RTP_AddBase.cginc) find this part:

Code (csharp):

1.  
2. //#if defined(SHADER_API_D3D11) || defined(SHADER_API_XBOXONE) || defined(SHADER_API_GLES3) || defined(SHADER_API_GLCORE) || defined(SHADER_API_PSSL)
3. #if defined(UNITY_USING_SPLIT_SAMPLERS)
4.    #if !defined(UNITY_SAMPLE_TEX2D_GRAD)
5.        #define UNITY_SAMPLE_TEX2D_GRAD(tex,coord,dx,dy) tex.SampleGrad(sampler##tex,coord,dx,dy)
6.    #endif
7.    #if !defined(UNITY_SAMPLE_TEX2D_GRAD_SAMPLER)
8.        #define UNITY_SAMPLE_TEX2D_GRAD_SAMPLER(tex,samplertex,coord,dx,dy) tex.SampleGrad(sampler##samplertex,coord,dx,dy)
9.    #endif
10.    #if !defined(UNITY_SAMPLE_TEX2D_LOD)
11.        #define UNITY_SAMPLE_TEX2D_LOD(tex,coord) tex.SampleLevel (sampler##tex,(coord).xy,(coord).w)
12.    #endif
13.    #if !defined(UNITY_SAMPLE_TEX2D_LOD_SAMPLER)
14.        #define UNITY_SAMPLE_TEX2D_LOD_SAMPLER(tex,samplertex,coord) tex.SampleLevel (sampler##samplertex,(coord).xy,(coord).w)
15.    #endif
16.    #if !defined(UNITY_SAMPLE_TEX2D_BIAS)
17.        #define UNITY_SAMPLE_TEX2D_BIAS(tex,coord) tex.SampleBias (sampler##tex,(coord).xy,(coord).w)
18.    #endif
19. #else
20.    #if !defined(UNITY_SAMPLE_TEX2D_GRAD)
21.        #define UNITY_SAMPLE_TEX2D_GRAD(tex,coord,dx,dy) tex2Dgrad(tex,coord,dx,dy)
22.    #endif
23.    #if !defined(UNITY_SAMPLE_TEX2D_LOD)
24.        #define UNITY_SAMPLE_TEX2D_LOD(tex,coord) tex2Dlod(tex,coord)
25.    #endif
26.    #if !defined(UNITY_SAMPLE_TEX2D_LOD_SAMPLER)
27.        #define UNITY_SAMPLE_TEX2D_LOD_SAMPLER(tex,samplertex,coord) tex2Dlod(tex,coord)
28.    #endif
29.    #if !defined(UNITY_SAMPLE_TEX2D_BIAS)
30.        #define UNITY_SAMPLE_TEX2D_BIAS(tex,coord) tex2Dbias(tex,coord)
31.    #endif
32. #endif
33.  

and replace with tweaked version:

Code (csharp):

1.  
2. //#if defined(SHADER_API_D3D11) || defined(SHADER_API_XBOXONE) || defined(SHADER_API_GLES3) || defined(SHADER_API_GLCORE) || defined(SHADER_API_PSSL)
3. #if defined(UNITY_USING_SPLIT_SAMPLERS)
4.    #if !defined(UNITY_SAMPLE_TEX2D_GRAD)
5.        #define UNITY_SAMPLE_TEX2D_GRAD(tex,coord,dx,dy) tex.SampleGrad(sampler##tex,coord,dx,dy)
6.    #endif
7.    #if !defined(UNITY_SAMPLE_TEX2D_GRAD_SAMPLER)
8.        #define UNITY_SAMPLE_TEX2D_GRAD_SAMPLER(tex,samplertex,coord,dx,dy) tex.SampleGrad(sampler##samplertex,coord,dx,dy)
9.    #endif
10.    #if defined(UNITY_SAMPLE_TEX2D_LOD)
11.        #undef UNITY_SAMPLE_TEX2D_LOD
12.    #endif
13.    #define UNITY_SAMPLE_TEX2D_LOD(tex,coord) tex.SampleLevel (sampler##tex,(coord).xy,(coord).w)
14.    #if !defined(UNITY_SAMPLE_TEX2D_LOD_SAMPLER)
15.        #define UNITY_SAMPLE_TEX2D_LOD_SAMPLER(tex,samplertex,coord) tex.SampleLevel (sampler##samplertex,(coord).xy,(coord).w)
16.    #endif
17.    #if !defined(UNITY_SAMPLE_TEX2D_BIAS)
18.        #define UNITY_SAMPLE_TEX2D_BIAS(tex,coord) tex.SampleBias (sampler##tex,(coord).xy,(coord).w)
19.    #endif
20. #else
21.    #if !defined(UNITY_SAMPLE_TEX2D_GRAD)
22.        #define UNITY_SAMPLE_TEX2D_GRAD(tex,coord,dx,dy) tex2Dgrad(tex,coord,dx,dy)
23.    #endif
24.    #if defined(UNITY_SAMPLE_TEX2D_LOD)
25.        #undef UNITY_SAMPLE_TEX2D_LOD
26.    #endif
27.    #define UNITY_SAMPLE_TEX2D_LOD(tex,coord) tex2Dlod(tex,coord)
28.    #if !defined(UNITY_SAMPLE_TEX2D_LOD_SAMPLER)
29.        #define UNITY_SAMPLE_TEX2D_LOD_SAMPLER(tex,samplertex,coord) tex2Dlod(tex,coord)
30.    #endif
31.    #if !defined(UNITY_SAMPLE_TEX2D_BIAS)
32.        #define UNITY_SAMPLE_TEX2D_BIAS(tex,coord) tex2Dbias(tex,coord)
33.    #endif
34. #endif
35.  

There is also similar code in standalone shaders where we overwrite RTP_Base.cginc inits.
Find this:

Code (csharp):

1.  
2. //#if defined(SHADER_API_D3D11) || defined(SHADER_API_XBOXONE) || defined(SHADER_API_GLES3) || defined(SHADER_API_GLCORE) || defined(SHADER_API_PSSL)
3. #if defined(UNITY_USING_SPLIT_SAMPLERS)
4.    #if !defined(UNITY_SAMPLE_TEX2D_GRAD)
5.        #define UNITY_SAMPLE_TEX2D_GRAD(tex,coord,dx,dy) tex.SampleGrad(sampler##tex,coord,dx,dy)
6.    #endif
7.    #if !defined(UNITY_SAMPLE_TEX2D_GRAD_SAMPLER)
8.        #define UNITY_SAMPLE_TEX2D_GRAD_SAMPLER(tex,samplertex,coord,dx,dy) tex.SampleGrad(sampler##samplertex,coord,dx,dy)
9.    #endif
10.    #if !defined(UNITY_SAMPLE_TEX2D_LOD)
11.        #define UNITY_SAMPLE_TEX2D_LOD(tex,coord) tex.SampleLevel (sampler##tex,(coord).xy,(coord).w)
12.    #endif
13.    #if !defined(UNITY_SAMPLE_TEX2D_LOD_SAMPLER)
14.        #define UNITY_SAMPLE_TEX2D_LOD_SAMPLER(tex,samplertex,coord) tex.SampleLevel (sampler##samplertex,(coord).xy,(coord).w)
15.    #endif
16. #else
17.    #define UNITY_SAMPLE_TEX2D_GRAD(tex,coord,dx,dy) tex2Dgrad(tex,coord,dx,dy)
18.    #if !defined(UNITY_SAMPLE_TEX2D_LOD)
19.        #define UNITY_SAMPLE_TEX2D_LOD(tex,coord) tex2Dlod(tex,coord)
20.    #endif
21.    #if !defined(UNITY_SAMPLE_TEX2D_LOD_SAMPLER)
22.        #define UNITY_SAMPLE_TEX2D_LOD_SAMPLER(tex,samplertex,coord) tex2Dlod(tex,coord)
23.    #endif
24. #endif
25.  

and replace with this:

Code (csharp):

1.  
2. //#if defined(SHADER_API_D3D11) || defined(SHADER_API_XBOXONE) || defined(SHADER_API_GLES3) || defined(SHADER_API_GLCORE) || defined(SHADER_API_PSSL)
3. #if defined(UNITY_USING_SPLIT_SAMPLERS)
4.    #if !defined(UNITY_SAMPLE_TEX2D_GRAD)
5.        #define UNITY_SAMPLE_TEX2D_GRAD(tex,coord,dx,dy) tex.SampleGrad(sampler##tex,coord,dx,dy)
6.    #endif
7.    #if !defined(UNITY_SAMPLE_TEX2D_GRAD_SAMPLER)
8.        #define UNITY_SAMPLE_TEX2D_GRAD_SAMPLER(tex,samplertex,coord,dx,dy) tex.SampleGrad(sampler##samplertex,coord,dx,dy)
9.    #endif
10.    #if defined(UNITY_SAMPLE_TEX2D_LOD)
11.        #undef UNITY_SAMPLE_TEX2D_LOD
12.    #endif
13.    #define UNITY_SAMPLE_TEX2D_LOD(tex,coord) tex.SampleLevel (sampler##tex,(coord).xy,(coord).w)
14.    #if !defined(UNITY_SAMPLE_TEX2D_LOD_SAMPLER)
15.        #define UNITY_SAMPLE_TEX2D_LOD_SAMPLER(tex,samplertex,coord) tex.SampleLevel (sampler##samplertex,(coord).xy,(coord).w)
16.    #endif
17. #else
18.    #define UNITY_SAMPLE_TEX2D_GRAD(tex,coord,dx,dy) tex2Dgrad(tex,coord,dx,dy)
19.    #if defined(UNITY_SAMPLE_TEX2D_LOD)
20.        #undef UNITY_SAMPLE_TEX2D_LOD
21.    #endif
22.    #define UNITY_SAMPLE_TEX2D_LOD(tex,coord) tex2Dlod(tex,coord)
23.    #if !defined(UNITY_SAMPLE_TEX2D_LOD_SAMPLER)
24.        #define UNITY_SAMPLE_TEX2D_LOD_SAMPLER(tex,samplertex,coord) tex2Dlod(tex,coord)
25.    #endif
26. #endif
27.  

Notice that now in case there IS defined macro UNITY_SAMPLE_TEX2D_LOD (as Unity introduced it recenetly in HLSLSupport.cginc) - we #undef it:

Code (csharp):

1.  
2.    #if defined(UNITY_SAMPLE_TEX2D_LOD)
3.        #undef UNITY_SAMPLE_TEX2D_LOD
4.    #endif
5.  

and #define RTP one below.

Happy New Year!

 

tomaszek, why when successfully importing Relief Terrain into Unity 2020.2.1f1, am I not seeing the full Terrains in ANY of the example scenes?

 

Someone can help?

 

Hey there, I have an issue (on freshly imported projects and also existing ones, version 2019.4.9f)


after completing all the steps in this tutorial (I found this more up to date than the official ones)
(2) Unity5: Using Gaia with RTP - How to add RTP to your Gaia Terrain - YouTube
This is how it shows up in my project. Basically the further you get away the more terrain shows, but when you are close, it appears like this.
What I've done: Used Gaia for terrain stamping, put the rtp core script on terrain, compiled shaders as in the video (with POM), recompiled, created a texture and saved in the project, put that texture in global maps section, added heightmaps to the maps through RTP, re-applied height texture, and then refreshed all. This is my end result, third time on a brand new project. Tried both linear and gamma. Any ideas?

 

Check in wireframe scene view mode to see if terrain disappears at "pixel stage" or mesh is missing. The thing I'd suspect - in case of tessellation usage - make sure you don't use instancing on terrain and proper heightmaps are used.

 

I believe it's realted to bug I described the one post above yours. Does Unity show any shader compilation errors?

 

Yes, it has a gUV undefined error. In which case I am waiting for an update.

 

Yes, disabling this:

Fixed my issue. Any other things I should be doing? Disable batching (static, dynamic)? Or am I fine to go along now?

 

Hello Tobias

I have an issue. I have a lot of RTP related textures show up as sized 42.7MB in the Unity memory profiler. Those are combined normalmap and heightmap textures.


When I double click them, they are only 21MB.


Do you have an idea why they would use up double the size in the memory?

Also I tried saving the combined textures to files to see if that helps. They still show up as 42.7MB even though they are only 1024y1024 on disk.

 

Also, is there a way to save the memory for normal maps? I don't need to use normal maps, only height maps.

 

Hey thanks for your answer

None of those textures are read-write enabled



@tomaszek

 

Historicaly combined textures are preferred to be uncompressed to get rid of DXT5 4x4 blocky artifacts (can be realy nasty on combined heightmaps when we try to resolve heightblending with contrast). After saving combined texture as .png you can basicaly use any compression format though (like BC7 which is a lot better than DXT5 and works fast on modern hardware). Saved textures are meant to be the only referenced objects by RTB scripts. If there are more memory reported it might mean there are still some references C# for uncompressed textures while they are not even used - hard to say without getting exact memory profiling/referencing objects info. As for normals - RTP assumes they are always used. Sure you can just prepare dummy 4x4 texture with linear flat grey (0.5, 0.5, 0.5, 0.5) and plug them into combined normalmap slots in RTP. Should save memory and tex fetch on performance, still - they will get unpacked in shader.

Tom

 

Hello, I just bought the asset. Does it support mobile from 2018?

 

Yes, it should - generally gles3 required, but depends on features you request. Some of them are still too expensive for mobile.

 

Hi Tomaszek,
I'm facing the following dilema:
I'm using a terrain from RWT with the satellite textures, and it has your RTP auto-applied to it (which was fantastic for far-viewing usage of the scene).

I need to improve the close-up quality of some areas and to add detailed soil and some other assets like stones.
I thought of using QUIXEL photo scanned textures (albedo, normal, mask) and adding them into the terrain layers (actually, when i'm looking at the TERRAIN PAINT tool i can't see any of the RTP textures) and trying to paint over the existing texture (without losing completely the satellite image), but from the few efforts i made i managed to paint with black color only...
Do you have an idea how i can make this process work? or maybe another idea of how to integrate the more detailed textures suitable for relatively close viewing?
thank you!

 

I'm not sure if RWT auto-apply follows all of my recent updates that were related to new terrain layer treatment introduced in Unity 2019.3 (before it was just a pair of diffuse/glos + normal textures managed inside terrain, now terrains uses separate terrain layer assets as layers).

You would need first to test close-up painting (which RTP is basically all about - far away views are something that uses only 10% of whole RTP potential). Starting from plain terrain, creating 4-8 Unity terrain layer assets, plug them to terrain - you can paint it using Unity functionality. Then add RTP script to terrain. It should correctly grab layers and manage it internally for custom rendering. The problem you're facing is probably because of some broken references of unity terrain layers against RTP layers.

 

Hello, there is a problem when working with more scenes and different ground textures sets on them. The current scene overwrites the settings for the scene you load next to edit. As workaround you can save your scene, delete terrain / terrain engine. load new scene. unload previous scene without saving. But its very annoying when you have much scenes.

Is this something you can fix ?

 

If your terrains need different textures and settings - group them in separate anchors. For example:
1. scene0 - terrains_of_scene_0_transform/terrain A, terrainB
2. scene1 - terrains_of_scene_1_transform/terrain A, terrainB, terrainC
3. scene2 - terrains_of_scene_2_transform/terrain A

although RTP_LOD manager should be present on single scene only.

 

Hi,

I had a question about mesh.
So if I apply rtp on mesh then I can not paint texture like terrain?
Does it mean that the whole mesh will just have all the texture blended everywhere?

Also if I have a unity terrain with rtp is there a way to convert that into mesh terrain and preserve the rtp texture?

Thank you very much.

 

You can use RTP on mesh in multiple ways:
1. create Unity terrain, setup with RTP (plain, use generators, etc.), export terrain to mesh, optimize, etc. - still you can use it. So - applying main RTP script on mesh will just give you all RTP features except for that it's not terrain anymore (so you can't just paint coverage). Although it uses splat coverage textures from Unity terrain.
2. take any mesh and use it as "standalone" RTP object - then it's just a material with shader that can mimic most of RTP features. Coverage can be then driven via vertex colors (so - you can use vertex paint tool like Polybrush) to control coverage.
3. As like in 2. but coverage can be also defined to be automatical depending on normals. Thus voxel terrains can be quickly textured triplanar way (sides rock, top - grass, etc.)

Tom

 

Hi! I'm trying to figure out a work-flow for cutting holes. I need to cut them with the Unity terrain "Cut Holes" tool, AND cut them in RTP's "Cut holes" tool (in the global colormap section). But I can't see the holes that I've cut with the Terrain tool -- RTP renders those areas like normal. So I can't tell if I'm lining my holes up right.

If I manage to cut the holes with both tools, everything works fine! So there's no technical problem, I just can't figure out how to actually make the holes with both tools.

Edit: using Unity 2019.4.20f1 and latest RTP

 

RTP is a tool that comes from Unity 3.5 era - and it's not any shame itself . It only shows RTP attempted to address challenges that were there back in Unity 3.5. Hole in Unity terrains is something from 2019.3+ as far as I remember. It works different comparing to RTP. Let's clarify:

Unity holes:
1. B&W texture mask sized and aligned to heightmap resolution
2. fragment shader cuts hole pixels basing on that
3. terrain collider excludes triangles that cover holes

RTP holes:
1. hole mask is taken from global colormap alpha channel. UVs taken are perturbed by perlin noise (when using perlin to disturb global colors)
2. same as with Unity - it's cutout in fragment shader but RTP holes can be shaped round/jagged (because of UV adressing), anyway they are not aligned to heightmap
3. object vs terrain collision is solved using trigger colliders. When object enters trigger terrain vs object collision is excluded (object can go thru hole). When object exits trigger terrain vs object collisions get restored

So - the main advantage of Unity holes is that we don't need any collision triggers as workaround. Although RTP holes uses different hole mask (global color alpha instead of dedicated texture) the way holes are solved is basically the same.
To see holes the same way for Unity terrain and RTP, my tool would need to sample the Unity's hole texture mask. I still solve it own way for sake of skipping additional texture fetch (Unity hole mask). In terms of usability it's a bit cumbersome as you can't see "Unity holes" and you need to draw them separately with RTP.

The question is - if you have only a few holes there's basically better to forget about Unity holes and use RTP ones only (with triggers setup like on my example scene). If you plan to put swiss cheese amount of holes. It might be better to use Unity holes for sake of physics. To sync visually RTP with Unity - well - there is no ready tool for that, but if you would aquire Unity holemask and apply it on RTP global colormap alpha, results should stay more or less in sync.

 

I'm having an issue in Unity 2019.4 where RTP doesn't receive any ambient lighting.



Is there a setting for that? Can't seem to find one in the interface.

 

Also I'm having this strange effect when using deferred rendering (does not happen in forward):
https://gyazo.com/c0db0d3e01708b676ed7b316acda4545

Seems connected to the terrains "Base map dist" property in settings. Changing the property seems to reset it back to 25 however after a while.

 

Does the wall on the left on your screenshot receives ambient? Hard to judge at first glance, but looks like it receives reflections only. Check lighting settings whether ambient light got precalculated. Select terrain as non static (so it won't get lightmapped automatically) and select auto generate lighting for your scene.

 

Basemap dist is controlled and used internally by RTP (it's close distance in RTP settings). In deferred you need to compile shaders in 8 layers mode so taht everything is drawn within single pass. 4+4 setup (4 layers in first pass + 4 layers in 2nd pass) doesn't work correct in deferred. I'ts usable in deferred when your terrain has 4 layers only, but it's even more limiting in real scenarios.

 

My terrain only has 4 layers so it should work? I tried enabling the 8 layer option, but that just gave me a black terrain:



These are my settings:
https://gyazo.com/734b3125501b2244ad82e8f9b571061a

EDIT:

Apparently, it DID have 8 layers but only 4 were used. If I removed the superfluous layers, the 4 layer shader would start working.

Using 8 layer shader with 4 layers would produce this result:
https://gyazo.com/cc55800903a004832bc1baa9c349e9eb

The terrain is a lot darker and weird black lines around patches.

 

Black terrain in "8 layers mode" when you apply RTP in terrain with 4 layers would produce black output (undefined coverage data for missing layers).

You need to decide on your setup before compiling RTP shader variants with LOD amanger. If you go for 4 layers you definitely need to uncheck "8 layers mode". If you go for 8 layers you have 2 options - 8 layers in single pass ("8 layers mode in LOD manager") that works in forward/deferred or rendering in 2 passes ("8 layers mode" unchecked) which works in forward.

So I assume you can move forward now? I can see wall on your screenshot receives ambient now?

Tom

 

@tomaszek

Ah ok, thanks for the clarification!

Regarding ambient - turns out the post processing volume was just making the terrain very dark, and the RTP shader wasn't as glossy as the default one, causing me to think it wasn't receiving any ambient. But it's all good now!

I have one last question regarding something entirely different.

Is there any specific reason why the mesh blending tech couldn't be made with a transparent shader rendering on top of the object receiving the effect? I.e., why would the receiving object have to change shader, if the effect is rendered with a special shader anyway? Couldn't the object keep its shader, then have another instance of itself render on top with the terrain textures alpha blended?

 

In regards to geom mesh blending - it works exactly like you said, but in inverse order. Geom blend object attaches "underlying child" transform that renders terrain (mesh that uses underlying terrain look to mimic it at blending edges). Then on the top of it regular object is rendered as alpha blended (with transparency applied at blending edges or wherever you need it). Blending/transparency is controlled via .a channel of vertex colors. So - you basically can use any transparent shader for your object - it's rendered w/o depth write (because underlying "base" object already writes it) with LEqual ztest and alpha blending. The main reason I introduced a bunch of geom blend shaders is that they implement some of RTP features like water, snow - this way dev can put objects on the terrain that "matches".

 

Fair enough.

I think it would be good to offer both methods. The object which the level artist wants to blend may have special shader that can't be replicated with the provided shaders. In that case, the opposite order would have been a better fit.

In any case, thanks for all the help and thanks for a great product.

 

Might be good idea for the future. Still - making custom geom blend shader is nothing special or complex. Just make your 100% custom shader with single extra feature - it should be able to use vertex color .a channel for transparency/blending. If you like better blending (with heightmaps / hieghtblending) you would need to provide it yourself anyway - no matter the order we mix stuff (unless you would be happy to have heightblended terrain basing on terrain detail heightmaps alone).

 

Hi!

I have no idea why geom blending acts like on upper screenshot. Bottom screen taken from another scene, blending works well. I'd like to get any thoughts how to get rid off these inexplicable bright areas, please!

 

If you refer to streaks present due to top planar mapping - they are expected, still textures seem to not match perfectly (geom blend base at the bottom of the mesh vs underlying terrain). Also check normals if they follow. I mean bottom vertices of geom blend base object should have normals matching terrain (flat y plane). Refreshing geom blend mesh doesn't fix it?

 

I found that streaks appear in case of a certain sequence:

- restore presets
- geom blending
- streaks!

In case of another sequence, things getting well:

- geom blending
- restore presets
- no streaks!

I've done a few terrain restoration jobs with right sequence, then result is OK

 

You could also add a area on the mesh to make a nicer blend... I do this on rocks and other things i'm blending. That is a flat object so that is another reason why it looks a little off, with a dark texture...So I would go around that mesh with a texture like the ground and make a nicer blend..

 

I'm having an issue adjusting layer properties. Brightness, Gloss, UV scale. I used to be able to adjust these in realtime. I can't get any property to update at all. Is there a fix for this? Thanks.

RTP3.3r
Unity 2019.4.22 - URP

 

Hi, sorry to say RTP is not URP compliant. Built-in RP only.

 

In the future rtp support URP?

 

In the future there might emerge new terrain shader product. I'll take my lessons learned with RTP doing this. It will handle URP/HDRP and will give some framework base for SRPs. New product if/when it comes will favorize current RTP customers by lower price. For RTP alone there's no plan to port it to URP.