A Unity ID allows you to buy and/or subscribe to Unity products and services, shop in the Asset Store and participate
in the Unity community.
Discussion in 'Assets and Asset Store' started by tomaszek, Oct 22, 2013.
Installing RTP3.3p on Unity 2018.4.1f1 I can't reproduce the issue within example scene. I can suspect there might be something wrong with other parameters in your setup. Please check other parameters like combined perlin texture, or can you verify detail normalmaps combined are correct? Because I can't basically see any ambient lighting on your screenshots. Snow level depends on normals - that's why I suspect there could be something wrong with it.
Installing RTP 3.3p into Unity 2018.4.11f1 on a Mac, in a clean/fresh project (only contains Voxeland & editor pack for virtual world I build content for), I'm getting this error message:
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)'
Looks like you have a modified script (the one with suffix _by_Charis...) - You should rename one of those 2 script files and see how it looks. They should both give the same output, but it depends why the modified script was written and how widely tested it is. I'd try renaming the extension on the modified one and see if you get compile errors, then try renaming just the original script and see how it performs. Ideally just having one removed will solve your issue and work without issue, but there may be requirements for the modified script in Voxeland, its hard to tell.
I haven't modified anything. The project was relatively clean and recent, fresh download from the asset store.
I've also tried installing RTP in a brand new/clean Unity 2017.4.33f1 project. Very simple - created new project, and downloaded from Asset Store. Two un-clearable errors. From what I've gathered in earlier posts, Unity 2017.4.x requires RTP 3.3m or earlier, but I have no way of getting that. I've had RTP for years, but don't manually keep an archive of all previous version downloads of assets, and the machine is periodically wiped. Is there a way to get the Unity 2017 compatible version?
Make sure you have Unity package cache cleared on your HD. Then download RTP from anything ranging Unity5.5-2018.2. AssetStore is supposed to give you suitable version - verinfo.txt signature should be "RTP3.3n for U5.5 & U5.6 & U2017 (U2018.1.0f2 checked)". There are only 2 packages available now. RTP3.3n has been forked for Unity2018.3 as Unity introduced too many differences, instanced terrains, etc. - handling everything within single package would be very inconvinient for me. So - RTP3.3n is available up to Unity2018.2. RTP3.3n and higher is available for U2018.3. Updates for versions n to p are Unity2018.3 related.
That worked, thanks!
I have no clue why but everytime I add RTP to any terrain it disables the Indirect Multiplier on the directional light? It's never done this before but if I take RTP off the terrain and go back to normal diffuse or specular lighting for the terrain material the Indirect Multiplier is activated again. Is it by chance blocking that connection on the realtime GI bake from Enlighten. Im using latest RTP and unity 2018.4.4f1. Been battling this for over a day now need to get this solved.
I've just installed Unity 2018.4.4f1 and RTP3.3p. Can't reproduce the issue on the example scene. I can control main directional light indirect intensity - interactively in realtime GI mode - see screenshots. Can you check it on fresh project and my example scene? There must be something different in yo9ur setup then. I don't explicitly affect any Unity's light property nor block it.
I am trying to use RTP for Tessellation but when I recompile the shader including the Tessellation option, the terrain disappears and I get the following errors:
Could someone please help me?
Thanks in advance,
I am having troubles with the integration of this with Ultimate Terrains, I am following the documentation here: https://github.com/ofux/uTerrainsDoc/blob/master/rtp3.md but I am getting weird light splotches see photo.
If you are looking at this I found out why it happened, it was because I used simplex noise, once I swapped to perlin fractal it was great. Has nothing to do with RTP 3.3
Check terrain instancing in Unity terrain settings. Should be turned off. With tessellation you cn use high pixel error and ask shader to refine terrain shape via tessellation. This brings down CPU usage so that instancing is basically not that much important feature.
What would you recommend to make an auto transparent mesh blend, like hand made middle zone #1? My tracks are very long so handy blending is boring
Currently RTP can provide you with autoblending at "sticked" geomblend mesh edges only. To introduce any automation you can do it via scripting as well. Blending info is stored by default on .a channel of vertex color. So it's pretty possible and not that much complex to make a script that would take underlying and overlying geom blend mesh and affect vertex colors .a channel here and there in relation to your demands.
Any Idea when you think HDRP support will be coming and which version of unity you plan on supporting for HDRP?
Hi, there! Got 2 stupid questions (RTP3.3o for U2018.3):
1) Recompile shaders is very long - took about 20 minutes or more. What can I do with this issue?
2) ClearAuxTerrainTextures.cs runs automatically or I should use it manually?
Still no release date. HDRP is still actively evolving. Even LWRP which Unity once announced to be "final/production" state went into yet another solution named URP... I've got ambitious plan to finish next big RTP iteration where SRPs will be must, but until this happens I'll probably simply add SRPs handling for current RTP state. It's so hard to give promises here as I can't really make living out of AssetStore I need to develop for other clients which can slow down (like it currently does) AssetStore products for some time. I hope I can get back overhaul my products soon (matter of few weeks where I can back working on this).
Anyway - RTP/UBER are too nice products to not have SRP support on them thus I'll definitely want to introduce it at some point (i.e. not abandoning it -built-in pipelines are not that bad in the end but everything seems to go for SRPs - that's the future trend for Unity AFAIK).
1) Whoa - what hardware (CPU/HDD) you're on? It is also related to set of features requested. On my side it takes not more than 2-3 minutes. Fortunately as soon as you decide on feature set to be used you just don't need to recompile stuff anymore. But I can feel your pain when you try to play with RTP's features to get familiar with it... I promise next RTP iteration won't require superheavy recompilation process (basically no recompilation at all although shaders will introduce a ton of variants thru #pragma shader_feature and #pragma shader_feature_local).
2) ClearAuxTerrainTextures.cs ralies on OnPostprocessScene handler - it should get called automatically by Unity when you make a build.
I got Acer Aspire notebook with Intel Core i3-4010U (3M Cache, 1.70 GHz) and SSD WD Green (https://ssd.userbenchmark.com/SpeedTest/377351/WDC-WDS240G2G0A-00JH30). Unity works quite fast, and my usual full build takes from 6 to 8 minutes (I don't even have time to tea break ).
A default RTP (on the clean project, just downloaded from assetstore) compiling long time too. In details: when I press button "Recompile shaders for given feature set", Unity hangs for a while, but still in the end, a compilation progress-bar appears in the last 4-5 minutes.
The reason may lie inside the Unity cache, it's hard to guess. I'm afraid to clean cache and Library folder to re-import all assets, because it will take several hours.
How can it be? I tried check/uncheck "Global normal map", "Far dist normals from UV blend" and other params in _RTP_LODmanager, there are no changes without recompilation.
It sounds cool, I shall wait!
Btw, another question on the attached screenshot. How to reach a blending from a "spelt flour" normals on the near distance to "craterized" surface on a far distance? A routing works only for diffuse maps, thus I tried to use a craters normal map instead Perlin normal map to make a screenshot (I love this hack ).
Moreover, the Perlin normal map scale on the base terrain tile is not suitable for ultra-long distance tiles. Moving ultra-distance tiles to another hierarchy is not working due globalized scale parameter. Should I copy a _RTP_LODmanager object to another hierarchy too?
Shader compilation results is cached in separate folder (Library/ShaderCache). You can delete it w/o neccessity of reimporting whole project. It probbly won't help with compilation time (rather the opposite), but I sometimes use it as ShaderCache folder can grow to enormous sizes after some time of working and recompiling shaders (several GBs!).
LOD manager object is strictly global one, grouping terrains in hierrchy is different thing - separately grouped terrains have their own set of textures and parameters (but not features).
In your particular usecase blending between near/far distance might be problematic. Lunar environment lighting exposes very strong contrasty bumps/shadows. UV blend routing indeed operates on diffuse colors only. Even though you select "Far dist normals from UV blend" checkbox it will introduce detail noramls at far distance but without routing. If you're shader coding aware or just brave one, you can modify this behaviour yourself. In RTP_Base.cginc (I believe you're using just 4 layers setup) look for:
#if defined(RTP_UV_BLEND) && defined(RTP_NORMALS_FOR_REPLACE_UV_BLEND)
It should be somewhere around line 5148 depending on RTP version. RTP_NORMALS_FOR_REPLACE_UV_BLEND define is equivalent for "Far dist normals from UV blend" feature (selected/compiled by LOD manager). The far detail normal stays within 4 lines calculating "n.xy". If you gonna use just a single layer as far dist normal replacement write it like this (replacemenet for these 4 lines):
n.xy = UNITY_SAMPLE_TEX2D_LOD(_BumpMap01, float4(_INPUT_uv.xy*MixScaleRouted0123.x, mipN.xx)).rg;
So - we sample combined _BumpMap01, channels .rg (layer 0, for layer 1 would be .ba) with accordingly scaled uvs (_INPUT_uv.xy is just regular detail scaled uvs).
Surely I give you no gurantee when you start messing around this code - so beware (don't ask me - "Tom shader doesn't compile or doesn't behave like advertised"). From such point it's your adventure, but I can at least give you a hint where to find a place to modify shader behaviour .
Yes, it's really works!
I decided to make it hotter and proceed to 3th level of detail (you can see on screenshot, from left to right, accordingly - near distance from sandy layer, craterized far distance from perlin slot and ultra distance from global detail normal of layer #0).
An experiment was succesful, I think
Please guide me how to get two RTP on scene. Is it possible keep an one 4-layer RTP for background terrain and 8-layer for basic terrain?
I know that I have to recompile shaders and copy them to another terrain material. What files needs to copy? Should I change string inside shader code "Relief Pack/ReliefTerrain-FirstPass"? And then create material, select renamed shader in inspector panel, assign material to terrain, right?
Another issue, should a LOD manager remain in scene or I can delete it before building project?
Thanks in advance!
You'd need to "fork" first pass and far-only shaders together with RTPBase.cginc compiled with 4 layers. Then place far terrains in separate transform hierarchy so it has its own GlobalSettingsHolder object reference. Modified first pass shader should access altered RTPBase.cginc (let's rename it after recompilation for layers to something like RTPBaseFar.cginc" and should point to far shader at the end of code as well. WIth proper basemap distance (it's RTP's Settings/Main "far distance") Unity basically shoulod use only far shader. Make material out of altered first pass shader and use for distant terrains. I hope it will work. You should leave single LOD manager, even in build.
It's all kind of hack, so you can also expect some surprises within RTP inspector that attempts to get synced with LODmanager and LOD manager attempts to get synced with what state it can find in RTPBase.cginc together with main RTP shaders.
Thank you very much for such detailed and useful instructions! I found same additional cases in this forum, most valuable with search word "rename".
I'm trying different terrain setups to reach a best and realistic view by near and far distances. Another challenge for me is to make different terrains of icy moons of Solar system. So, there are some moon setups in front of me:
1) Earth's Moon with fine-grained sandy surface at near distance, and craterized at far (mixed with something like perlin noise). Another issue is very big lunar mountains, with smooth and continuous colorized surface (global map feature is good for this).
2) Other moons has icy surface with rocks inclusions. A glitter, of course. Some snow.
3) Titan, has naphtalene sands and methane puddles.
4) 4 layers as main workflow, 8-layers as a desirable detailed addition.
So, for big distant background I've decided to use single terrain with separate simple shader with minimal features set. But this background terrain is rendered by separate camera with smaller depth value! (so it may have smaller, more convenient size).
Thereby, I tried to adjust RTP to these wishes, starting with successful experiment of normal map routing (as tested above) for lunar setup only (two terrains with two cameras).
1) I change RTP_Base.cginc to a new normal map routing algorithm and recompile shaders.
2) Rename RTP_Base.cginc to RTP_Base_route0.cginc,
copy ReliefTerrain-FirstPass.shader to ReliefTerrain-FirstPass_route0.shader,
and copy ReliefTerrain-FarOnly.shader to ReliefTerrain-FarOnly_route0.shader.
3) Edit code of ReliefTerrain-FirstPass_route0.shader
and replace name to "Hidden/Relief Pack/ReliefTerrain-FarOnly_route0".
Did the same with ReliefTerrain-FarOnly_route0.shader, replace name to "Hidden/Relief Pack/ReliefTerrain-FarOnly_route0"
Then in both shaders change #include "RTP_Base.cginc" to #include "RTP_Base_route0.cginc"
5) Recompiled again.
6) Make a new terrain material "route0.mat" and assign it to basic terrain.
Dear Tomaszek, what do you think about this workflow? Is it acceptable for my case?
I have been using your asset for 3 years now and I must say it is fantastic.
But cyclically I happen to run into an error / bug.
I read a large part of the discussion on this forum but was unable to find a solution.
Attached you will find an explanatory image of the various problems I encounter.
Unfortunately, although the error has occurred to me many times, I have not yet managed to deliberately reproduce it.
I am using the 2018.3.9.f1 version and Relief Terrain Pack V3.3
Sometimes when I select a terran tile (created with the Real World terrain asset) I get the situation in the attached image ... lost many references to your shader and terrain.
Other times, however, I don't even find the RTP settings in my Inpector and I see in its place an error symbol with "problem with number of layers, try to assign relief terrain script".
Obviously I remove the script, reassign it, but the error symbol and the writing remain.
Do you have any idea what could cause this error? And how can we resolve the situation?
this looks awesome, before i buy can i ask 3 questions
1) is this significantly better than unity's latest built-in terrain shading tools?
2) how does it handle steep terrain slopes? what's the maximum slope you can reasonably get away with?
3) assuming the answer to 2 is not very good because terrain is height map based, can i convert my terrain to a mesh and then use RPT shading on that to better handle slopes?
i have a lot of climbing in the mountains stuff and need vertical faces for my climbing stuff. thanks
Hi, sorry for late reply. I believe I already spotted the issue and it is supposed to be solved with newest RTP version. Make sure you use 3.3p (look into verinfo.txt file inside the package). Sometimes downloading of the newest package fails AssetStore side. you need to remove package cache from your hard disk (google for "Unity package cache location") and redownload it.
1. Yes, it is still way better than Unity's terrain shading (in terms of what you can get).
2. Well - Unity can give you as steep slopes as you wish, the problem is with texturing - to avoid streching you need triplanar mapping which is provided by RTP.
3. RTP shading can be used on Unity terrain, on mesh that's prepared out of Unity terrain or any mesh not related - you only need to provide it with normals while mapping will be done automatically.
Oh, thanks, I had try but...this is my verinfo text:
RTP3.3p for U2018.3
Do you create terrains dynamically? I can see you don't use any complex setup here. Just 4 layers. Remember that you can't mix 4/8 layers with RTP. Use either 4 or 8 layers. The basic workflow using RTP is supposed to be correct as far as you:
1. Create terrain (RealWorld) tiles - just Unity terrains with these 4 layers.
2. Make sure all terrains has terrain layers attached correctly in Unity terrain inspector (no missing terrain layers). The problem can be related to the way terrain layer objects are created. They should be assets in project so that their references don't break when attempt to do a prefab or cross scene object reference.
3. All terrains use the same set of terrain layers.
4. Attaching ReliefTerrain script component to terrain tiles should initialize RTP correctly then - w/o any broken reference.
I can imagine some scenarrios when terrain tiles are added/removed dynamically with their terrain layers staying out of sync with the other terrain layers. In RTP we can use different terrain layer sets for different terrains only using grouping (each group need to be separate transform in hierarchy where we place grouped terrains under).
Can you check above suggestions? Otherwise it will be extremely hard for me to spot the problem as we're talking not even about Unity terrain vs. RTP integration but also 3rd party assets (RealWorld) that might interfere here.
Hi Tom, this is my workflow:
1. Set the "Enable RTP" checkbox in the RWT settings
2. I create the terrain and automatically generates the game object "RTP_LOD_MANAGER"
3. In Figure 01 you can see how I fill in the LOD_MANAGER
4. I dig with the brush the whole part of the sea in order to obtain a great difference in depth between
seabed and the coast / beach (unfortunately RWT does not correctly generate this gap)
5. I select the terrain tiles on the coast that interest me and, in the "Coverage\Aquire" window, I save the Steepness and height images. This happens for each tile, so I have many saved images.
6. I also save the Heights 0-3 map in the "Combined Textures\Height Map" window
7. In the "Coverage\Compose" window I fill in the fields as in Figure 02 e press "Render control maps from source splats
8. I set the settings related to Global map, Perlin normal, etc ... and Layers
9. Finally I use the brush in the terrain settings to color the terrain in a different way in case there are differences between the result of the RTP work and reality (I improve the sand on the coast).
By doing this step I often have problems with terrain layers that don't correspond to the textures added in the RTP "Layers" window
10. Now my job is done. I save everything and close Unity
11. I reopen Unity and I am in the situation I described previously. I lose the references to the textures in the "Layers" window of RTP and also the layers of the terrain have problems (Figure 03)
12. Ps, I remind you, as far as the "Layers" window is concerned, you have problems with 4K resolution, see Figure 04
Thatks for your attention
great, its on my shopping list for when i'm ready to prettyfy things.
Lorenzo, I believe that best way to help you would be contacting me via private message in order to establish call/screenshare session where I can follow the workflow state step by step and spot the moment it breaks. It has something to do with out-of-sync terrain layers vs RTP layers, but still I can't tell the reason. You mentioned you have problems with drawing textures as corresponding terrain layers textures don't match RTP ones. That what basically we want to avoid in RTP workflow.
Thanks for your time Tom!
Now I try to reproduce exactly the problem so as not to waste your time and once successful I will contact you in private then.
If it can help you this warning is out today:
TerrainLayers from GlobalSettingsHolder can't be found. Create a set of layers and setup first terrain before adding RTP script to it!
ReliefTerrain:GetSplatsFromGlobalSettingsHolder() (at Assets/ReliefPack/Scripts/ReliefTerrain/ReliefTerrain.cs:201)
ReliefTerrain:GetGlobalSettingsHolder() (at Assets/ReliefPack/Scripts/ReliefTerrain/ReliefTerrain.cs:98)
ReliefTerrain:RefreshTextures(Material, Boolean) (at Assets/ReliefPack/Scripts/ReliefTerrain/ReliefTerrain.cs:282)
ReliefTerrain:Awake() (at Assets/ReliefPack/Scripts/ReliefTerrain/ReliefTerrain.cs:237)
This happened when I reopened the project after working on other projects the past few days
This part of RTP code is executed when RTP's globalSettignsHolder has no Unity terrainLayer array. GlobalSettingsHolder is scene object that's referenced and shared across RTP terrain tiles within the same group.
Basically it happens only on upgrade to 2018.3 when TerrainLayers have been introduced by Unity. Sorry - I can't tell how RealWorldTerrain integrates with its "Enable RTP" checkbox. You could make a test w/o RWT. Create a world (consisting of a few terrains). Let all terrains have the same 4 layers - Unity TerrainLayers created first as assets. Then apply RTP and setup it. As far as TerrainLayers referenced by Unity terrain and RTP's globalSettingsHolder are in-sync and are persistent objects (I mean - assets, not scene objects) you're not supposed to run into the problem. If at any point 3rd party software like RWT recreates RTP's globalSettingsHolder and doesn't take care about feeding it with right terrainLayers set RTP will throw the warning (and it can break layers indeed). So I'd suspect RTP itegration in RWT might be a outdated.
first, i love your product.
We are forced to update our Project from unity 2018.3 to 2019.2
RTP is almost working, but your custom shader for Terrain is not assigned (i tried to add RTP from scratch too). Color map and other Functions are out...
We are also using your collaborations with Terrain and World Composer. So we have more Terrain Tiles
See Picture in Attachment
Can you please help? Our Project depends on it for now
(sorry for my Czenglish)
Try to remove material, RTP script attached should set new one. AFAIK there were no breaking changes introduced by Unity since 2018.3. You could also ask World Composer if it's still valid for usage with RTP with 2019.2.
This override saved us!
I was happy little too soon. When i save+close and re-open the Project, all the bad Materials are back on Terrains. I can assign "none" again and RTP will take over again with all the right settings... Can i use this workaround more permanently? Thank you in advance
edit: it is coming from "TC_Terrain Area" script (Terrain Composer). If i turn script off, it is fine...
> then you need to ask TerrainComposer guy pointing that the script overwrites terrain materials unnecesarilly.
Ok Tom, Thank you for your answer!
I'll try disabling that check. If this were the case, the problem would be perfect.
I keep you updated
Hi, Tom! I'm stuck in a height map with mesh terrain, help please!
When applying the heightmap to RTP component on the mesh, corresponding layer becomes dark (screenshot#2). However, terrain near by of mesh, looks nice with the same layers and textures. This shading problem is only for mesh. What am I doing wrong?
Unity 2018.4.18f1, RTP 3.3p
P.S. What are the most important differences between ReliefTerrain-FirstPass and ReliefTerrain2Geometry shaders? I tried a ReliefTerrain-FirstPass for geometry mesh and it's working well (hack, I think so ). Should I continue strictly using ReliefTerrain2Geometry shader instead ReliefTerrain-FirstPass?
Hi, just out of my head - mesh vs terrain shader variants differ that mesh gives tangents while for terrain tangents are derived. Apart from this - terrain shader is ahndled a bit different way by LOD manager which recompiles it to adjust drawing passes against number of layers and shading scenario. So - as far as terrain version works for you you can try to use it this hacky way.
Looking at your screenshot seems like "faraway" shader variant (for gameobject named flat plain "равнина" treats combined heightmap odd way. Can you check tiling options for detail textures maybe?
OK, I'll take note of that! Actually, I'm looking for a maximum performance for background terrain (because that should be just background, nothing more in scene). I love the seamless terrain-mesh overlap RTP visual feature, but cannot decide what is better for background - terrain or mesh.
No, layer becomes darken both far and near distances. Tiling options copied from terrain (for seamless overlap mesh-terrain, as I said above).
Performance side I believe that using 8 terrain tiles around the area of interest ("game playground") where they have flat/low res heightmaps, low res splatmaps should be reasonable in your case. Unity can handle and draw terrains quite fast nowadays. Using terrains has also advantage that when they are far away they will use simplified shading which is handled by RTP automatically.
Yes, I like terrain tile technique, due it's nice LOD optimization. But I met some performance issues. Simple 4-layer terrain benchmark gives ~200 FPS on builtin shader
and ~110 FPS on RTP (tweaked with POM Soft Shadows, no deferred, full forward shadows, lightmaps, UV blend + Far dist normals).
The comparative performance drop measured on more powerful GPU (GTX 1060) approx ~700 FPS Builtin vs ~500 FPS RTP.
In summary, RTP gives more appetizing picture, but presses a performance in range from 50% to 30%, in my case. I can't get benchmarks on U5.6 and U2019, so this is only U2018 issue.
I want to squeeze out a maximum speed for my shooter game, so what would u recommend to raise a performance?
Drawing in forward keep your eye on lights being affecting the terrain. Some tiles can be redrawn multiple times so be careful. And surely requesting POM can hurt a bit. Isn't simple parallax enough for a shooter game where player attention is focused on shooting rather than not analysing every terrain pebble?
Thanks for hints very much! I'll try some... But can't give up parallax, it's a eye-catching feature, I do really love it )) Here is some try with RTP