RTP - Relief Terrain Pack with geometry blend on AssetStore

I am about to modify the shaders the way you are suggesting and try them in DX11 mode. I'll keep you informed of the results.

I have created a Photoshop script to automate the Splatmap channels generation process and it seems to work perfectly.

Nevertheless I believe that an easy and straightforward mask import for the generation of the splatmap would definitely be a great add to your pack.

 

I have modified the three shaders, commenting the lines you suggested.

The new version seems to work fine in the editor and the build also works fine in windowed mode.

The rendering of the shader seems a bit different though with more specularity.

The build still crashes at launch if launched in full screen mode. =(

I also still see the same shader compilation errors I listed in an earlier post.

 

USed 8 now but instead of grey its coming up as black.. do the height taxtues have to be saved in any particular way?


ok turned off the color map i had on the terrain and POM seems to work tho the black blops are still there.. guess its somthing i have messed up will double check everything..


ah detail transition sharpness was the issue

 

Hi Tomaszek,

You mentioned developing a specific tool to import the splatmaps. I think that it would be really great actually.

Although I have created a Photoshop script to automatically generate the correct two splatmaps with the correct channels, I have some problems when trying to import them into Unity.

I had been using a very simple script in the past but it only handles one splatmap and does not perform any normalization on the ARGB values leading to unwanted results in the game.

I have purchased the "Tom's Terrain Tool" on the Asset Store and I have been trying to use it in the last couple of days. But I was getting some pretty weird results.

Not only does the normalization calculation ruin the masks but the code is bugged and does not take into account the alpha channel of the imported splatmaps. Instead, it tries to deduct the necessary values from the existing RGB values. This work more or less of with one splatmap but not at all with two splatmaps.

I have been trying to modify the Tom's Terrain Tool script to take into account the Alpha channel but for some reason the program is unable to read the Alpha channel of the splatmaps and only entirely fills the alpha channel with white color. In addition, it modifies the import settings of the splatmaps, turning them from ARGB32bits to RGB24bits each time I run the tool.

I have been scratching my head for hours trying to figure out what's wrong with the code but I didn't find the problem. Maybe that's why the programmer of the tool also ended up trying to deduct the A value from the RGB values.

Anyway the only workaround I found is to use three splatmaps instead of two. The script reads the RGB values of the two first splatmaps and the R and G values of the third one. that's 8 channels all in all. So finally I am able to export the two splatmaps correctly. but with a very inelegant workaround.

I still need to make the normalization right. I thought that doing:
R = R/(R1+G1+B1+A1+R2+G2+B2+A2),
G = g/(R1+G1+B1+A1+R2+G2+B2+A2), etc

for each texel, would do the trick. But I find the resulting splatmaps a bit weird. It seems that the contrast is lost. Maybe a more clever calculation is required.

 

Thanks for the help getting this working btw

Its a shame you cant control the POM strength on each texture separately tho.. but still its an awesome addition to unity and makes the engine loo kso much better.

Probally my best buy in the store so far.

Thanks

 

For me looks cool Have you used heightmap on grass ? Can't say much precise due to video codec quality reduction, but it looks like extruded stuff. I'm currently working on better geometry blending solutions (better lightmapping), need to simplify workflow (UI) and add some kind of splat map importer (I'll stick to WorldMachine to test it output trying to apply it to my RTP system). I hope incoming release will be also more stable in DX11 and some openGL machines.

ATB, Tom

 

Yeah i did use a heightmap on the grass was a texture i made up for Cryengine and needed a lot of work anyway just wanted to test to see what it came out like you cant really see it in the video but its a bit noisy, I removed the height for the grass as I need to do it again.

Yeah video is a bit low quality, program i compressed it a bit too much and then youtube did as well lol.

I use world machine its an awesome program and seems to be very popular.. next release is sounding good as well.

 

Controling the POM strength (separate height value taken from heightmap texture) on each texture will be included in the next release. Height control can be done via heightmap modification _per layer_, but user need to edit texture and redo combined heightmaps (BTW, they will be combined automatically now). I've decided to put one lerp() call per heightmap texture fetch because it's not that expensive comparing to the overall shader cost. User will be able to modify resultant height value by slider associated with layer.

 

ah very nice cant wait for that

 

As I'm working on feature for importing external spalt (alpha) control textures I've got question; esp. for WorldMachine users (I don't want to favorize this app, but I'm just using it for my new RTP demo and it seems to be quite cool ). In which format do you export control maps ? I'm thinking about importing alpha (or choosen color channel from any texture) per layer and combine it to Unity's splatmaps (importing splatmaps in raw Unity RGBA normalized format is now already done - user will be able to port controlmaps from one terrain into another).

My doubts are that as far as I'm aware importing splat controls could be realised at least 3 ways:

1. sum every source alpha channel so that resultant alpha for separate channel will be normalised. This method doesn't take into account layers order (no matter which layer is "top" or "bottom"). Let's say 4 layers. Every layer has value of 1 (they just overlap for given pixel). This way resultant splat control will be (0.25, 0.25, 0.25, 0.25) RGBA.

2. taking layer order so that "top" layer will totally cover underlying content in case its value is 1 (just as in case we paint over terrain, no matter which layer we use, rest of layers will vanish)

3. Or maybe solution 1 with weights. We could "boost" some layer, so when we normalize overlapping content, such layer would take more. Let's say 4 layers. Every layer has value of 1 (so they overlaps), but first layer has "weight boost" set to 100. This would result in something like (0.97, 0.01, 0.01, 0.01) output -> first layer "wins" taking most importane in such case.
One may notice that using such weighting we could mimic 3rd method sorting layers by "bootsing weights" (for example any layer with very high boost factor would be always "top" layer).

To properly normalize content, one layer should be treated as "plain" and reveal when no other layer has control set to value greater than zero. in my case it's just first layer.

Any suggestions, how to resolve it sensible way ? I'm on 3rd solution side, but would love to take some constructive feedback on that .

ATB, Tom

 

When i export splat from WM they're all unnormalized and unrelated, i definately want 1, have all of them be summed and treated equally.

 

Must admit i have not really tried exporting anying more than a basic color map from World Machine, tho its the main tool I use for creating map as I have the pro version..

I will take a proper look at it when I get chance..

 

I'll attach tmd World machine 2.2 (Standard edition) file into RTP so that WM users will be able to take a look how do I export control maps (detail coverage maps) and how do I use them in my product. Finally I've introduced both mentioned methods of composing splatmaps in Unity. Ordered / unordered + weights and coverage channels can be masked - useful when user will need to put difersity over one surface type. Let's say we've got grass coverage map imported and want to make it "not-that-tiled-or-everywhere-the-same". Simply we use 2nd detail layer and drive its coverage by some noise masked by main grass layer coverage mask. This way we've got grass areas sweeten with 2nd grass type here and there (noise driven, but only on main grass area).

In case user does not use WM or 3rd party software to compose coverage maps, I've introduced opportunity to export (save as png) 3 types of aux textures:

1. steepness (might control rock coverage for example as grass tend to grow on rather flat surfaces).
2. height (it's just heightmap saved as png not raw)
3. direction. Can't say where such mask could be used, but when we compare light direction with terrain normals we could get kind of lightmap that might be used for global color. Then (dir light must be static) we could put high pixel error (low poly) and still get detailed very look (together with global normalmapping at mid/far distance). My tests are promising (I use such technique in RTP demo).

People can use above textures combining them in editing soft (photoshop or whatever). Anyway - painting rocks at steep areas over huge terrain is just insane (unless somebody got weeks of free time to waste ). Terrain system in Unity fine, but definitely only for tweaking, not for doing terrains from scratch. It's virtually impossible to get realistic look without good external stuff (satellite heightmaps or WM output).

ATB, Tom

 

Sounds good to me

 

Personally I use WM to generate a series of grayscale masks, using all kinds of parameters like slope, height, flow map, erosion map, etc. and combination of those parameters.

I make an extensive use of the idea evoked by Tomaszek of a 2nd detail layer which coverage is based on some noise, masked by the main layer. To create this particular mask, I either use the "fractalize" node of WM or directly edit the mask in Photoshop.

Basically you need 7 masks if you are using 8 detail maps, since the first layer is always considered covering the entire terrain surface.

Once the masks generated, I import them in Photoshop for further editing. I create one colored layer for each detail layer and add the corresponding mask from WM to each layer. Then I order the various layers and modify the masks. As usual in Photoshop, each layer prevails on all the layers below it. This gives me a good idea of what the final terrain will look like in Unity. Once I am happy with the results, I use a Photoshop script I have created which "normalizes the splatmaps". What this script does is merely substracting each layer mask to the layers below it. This script also generates the final splatmaps to be imported into Unity.

Then I use a modified version of Tom's Terrain Tool to import the splatmaps and apply them to the terrain. I had to modify the tool because it is only designed to import 4 colors (RGB + black) splatmaps directly exported from WM, which is far too limited and incompatible with the use of 8 detail maps.

Tomaszek, if you decide to work on a splatmap importer/editor, it would be great if this tool could:
- input 7 grayscale masks, one for each detail map, except for the first one.
- add a cursor beside each mask to control its opacity/influence on the terrain (the best would be, but I wonder if it possible, to see the results in real-time on the terrain while moving the cursors).
- show low performance areas. You mention in your documentation the fact that combining detail maps between 0 and 3 with detail maps between 4 and 7 is more costly and that this should be avoided as much as possible. you could show the areas where this occurs on the splatmap to allow the user to better order the masks and limit these low performance areas as much as possible.
- "normalize" the splatmaps using the same method I use in my Photoshop script, by substracting each mask to the masks below it. I think that this is far better than merely averaging the values.
So I would definetely pick the option 2. in your post, but with a cursor near each mask, so kind of inbetween options 2. and 3. =)

 

Thank you very much for your input. In fact, I've already implemented it before get feedback and it will work as you requested (no cursors "real time" though, but each layer has its "importance" multiplier). Each grayscale mask (their number is equal to the number of layers, but first layer in ordered mode is should be considered 1) can be separately masked, so you don't have to mask it in photoshop to get "variety". This functionality now works out-of-box in RTP.

If you choose, you can import ready made splatmaps directly into RTP (like in Tom's Terrain tools) - just drag'n' drop it into texture slot, which is now impossible (we can only view and save current splatmap).

There are also more helpful features introduced. I'll describe them when I'll find a moment and when advertising RTP 2.0. Yes, number of improvements justifies naming it this way .

Option for visualizing high cost areas is very interesting and I'll probably add something like this - it would simply show texture where splatmaps 0-3 (r+g+b+a of first control splat texture) sum to something greater than 0 and lower than 1 which imply that area is "high cost".

 

Purchased yesterday, so far I am very impressed! Great work.

 

Thank you. For those who already bought it...you won't be disapointed with new update, I promise . For those who haven't yet - it's bad but I will have to raise a bit price of the system (too many improvements and new fatures coming). I know it will reward current users, but they're people who support product developement.

 

SUPPORT REQUEST:

I have 1 project with multiple scenes. I am using your RTP system in 1 scene on the terrain and it is working great.

I have a 2nd scene in this project with terrain that I do not plan to use the RTP script. I am using the standard Unity terrain script for this scene. Since installing the RTP package the rendering of the terrain in this second scene is corrupt. (image below)

Is there a way to disable the the RTP shaders for this second scene? I do not have the script attached to the terrain, but something related to RTP is causing this side effect.

 

1.Getting artifact at bottom of screen...


2. Also some kind of strange overlay... when details adds it become dark...

 

At this moment the best way is to switch to classic rendering on 2nd scene (standard Unity's terrain shader algorithm is used). I'm not sure if there won't be problems with case your 2nd scene use less than 5 layers (current RTP version works well on 5-8 layers). I've described how to switch between render modes some posts before. In incoming RTP 2.0 there will be kind of manager present on scene so switching will be very straightforward (on different scenes you'll use different manager settings, only calling "refresh()" menthod will be probably needed at scene load).

Tom

 

you're probably viewing terrain hill downwards - some weirdness might occur there in POM mode. In RTP 2.0 I improved hill view rendering. By now you can flatten steep areas (parallax extruding will be canceled) using geometry blend script (allows paint over terrain to flatten it), or manage it yourself - global colormap alpha channel is responsible for flattening (black alpha - full flat).

You could give a screenshot. When using RTP and 5-8 layers nothing should be strange.

 

Any news of the latest release I would love to get this working with DX11

 

Ineteye, you may want to try turing of self shadowing.

 

Thank you for this information Tom. I searched this thread and could not find your description of how to switch between render modes. If it is not too much trouble could you post this information again?

 

To foosart -- I tried this does not helps...

 

OK, hoped it would. Was just a guess

 

Page 5 of this thread, 3rd post from the top - a piece of code where you can adjusy render mode (by setting maximum shader LOD level).
In RTP 2.0 it will be possible to call function on RTP_manager script to adjust it w/o writing much code.

Tom

P.S. @ caldrin. I'm almost there, but I'd like to introduce many new features that are implementation expensive. I believe it's not that long ahead to release it .

 

good news, ive just started messing around with DX11 tesselation on models and stuff so it would be cool to have the terrain system working as well but im not in any hurry or anything

 

It is currently unclear how the detail maps atlasing works. Where and when are these atlases saved?

Most of the time if I save the scene, the atlases are saved but not each time. For some reason on some terrains, the atlases are not saved when saving the scene and I have to recreate them each time I launch Unity. Besides, if I build the game the detail maps are also gone on this terrain.
I also noticed that if I create a prefab out of a terrain, the atlases are not saved in the prefab.

Of course, It is great to have an automatic atlasing tool but it may be better to keep it in the "Relief Tools"menu, like the 4 to 1 channel mixer tool. And to then let us drag and drop the resulting atlases in the inspector.

This would also allow us to generate the atlases manually in Photoshop.

 

Atlases are simply Texture2D public objects that are members of ReliefTerrain scripting object. When you generate them and you see them in script inspector foldout submenu I see no reason they might be not saved. Refering to detail maps - you mean maps that store grass/add meshes coverage on terrain or detail maps in terms of terrain textures ? Anyway I have to test it before new release more than I assumed then. Prefabs issue - have to look into it as new RTP 2.0 will introduce so many changes in scripts I have to check carefully.

Atlasing in photoshop - you may do it in photoshop and put it into atlas slots manually, but it's not recommended I believe. I use high quality padding/resampling service to make them (better scaling algorithms than photoshop bi-quadratic). And they're not simply 4 textures sticked together. Due to MIP mapping treatment it's more complicated. I made it quite good IMHO - there are no visible seams or color bleeding even for high MIP levels.

Thank you for reporting feedback !

 

Yes I am talking about the terrain textures and not the maps for terrain detailing objects like grass.

Your atlasing algorithm is indeed very good and in fact manually generating the atlases in Photoshop would not really make sense. I was mostly talking about moving your atlasing function from the inspector to the "terrain tools" menu so that it can be manually saved.

 

So I'll add save atlas feature, but the only reason I could think of is that you need to use the same atlas on multiple terrains and you don't want to pay extra mem for this as every ReliefTerrain script has its own atlas textures. Detail textures are not necessary, but they're used in shader fallback. They're stored by unity terrain - I don't store permanent (serializable) references for them in ReliefTerrain script and when they disappear it's weird as they belong to regular unity terrain system, not mine.

 

In fact the detail textures do not disappear, only the atlases. I have not found the reason yet. For some terrains it works fine for some others it doesn't.

 

Weird is that it works only for some terrains ? But I probably found the reason you're loosing atlas texture reference when making prefab out of it. When I use Textures that are "real" entities stored on the disk (not as an scene object serialized/stored inside ReliefTerrain script) it works. The same is for global colormap which can be edited via geometry blending script. When it's reference to texture not existing on the disk we're loosing reference when making prefab. So, ability to save all textures used by the shader will be helpfull I guess.

ATB, Tom

 

Tomaszek. We have the switch working partially. The scene that uses the RTP shader display ok. There are 2 problems with the scene that uses the standard terrain shader.

1. For the scene that we switch to the standard terrain shader, the display of the detail maps remains corrupt until we enter "play" mode. Any way around this?

2. After entering "play"mode in the scene that uses the standard terrain shader, the detail textures display ok. But the lighting on the terrain is too bright. It is as if an extremely bright diffuse or specular value is being applied.

 

ad.1) you have manually set shader to the "classic" mode by setting shader LOD level. It's not done automatically after scene is loaded. In RTP2.0 there will be lod manager object to handle this. It could "refresh" lod level settings after scene is loaded (you should then call manager function on any handler that is called after scene load).

ad.2) how many layers do you use in RTP scene and in default shader scene ? Do you use lightmapping ? Overbrighting is sometimes caused by "Shading strength for lightmaps" param that tries to recover bumpmapping on lightmapped terrain.

 

re. 1 ) Yes, I am manually setting the shader to classic mode by setting the value in our shader tweak to 400. Here is the script we are using to set the shader:

using UnityEngine;
using System.Collections;

public class RTPShaderTweak : MonoBehaviour {



public Shader replaceShader;
public Shader geometryBlendShader;

public int maxLod = 400;


// Use this for initialization
void Start () {



Shader replaceShader=Shader.Find("Hidden/TerrainEngine/Splatmap/Lightmap-FirstPass");
Shader geometryBlendShader=Shader.Find("Relief Pack/TerrainGeometryBlend");
replaceShader.maximumLOD=maxLod; // 650 for PM, 500 for SIMPLE, 400 for CLASSIC
geometryBlendShader.maximumLOD=maxLod;



Terrain terrain=(GameObject.Find("Terrain").GetComponent (typeof(Terrain))) as Terrain; // "Terrain" is game object name in scene which is our terrain
ReliefTerrain script = terrain.GetComponent(typeof(ReliefTerrain)) as ReliefTerrain;
script.InjectBasicMaterialParams();

}

// Update is called once per frame
void Update () {

}
}

re. 2) I am using 8 layers in the RTP scene which renders great. I am using 4 layers in the default shader scene. Yes I am using lightmapping in the default scene. I tried uncommenting the "force_shade_support" to adjust the "shading strength for light", but this had no effect. End result was I broke the shader and had to re-import.

Here are some images of my default scene before and after importing RTP.





Thanks for your input.

 

@foosart

Lighmapping in default scene doesn't change anything as we don't use bumpmaps there (classic Unity terrain shader don't use it). The problem is the most probably linking RTP scene of 8 layers with default scene of 4 layers. Shader doesn't work much good with less than 5 layers, but at this moment there is fast solution - as you're using 4 layers in defult scene, disable (cut/comment) 2nd pass in RTP replacement shader. Find "LOD 400" in code - it's "classic" subshader. Inside you've got two sections starting with CGPROGRAM ending with ENDCG. Remove 2nd one. This way your default scene set to classic shading should start working (hopefully ). The drawback is that fallback into classic won't work much good in RTP scene - you'll handle only 4 layers and rest will become black. If you won't use CLASSIC mode in RTP (8 layers) scene, nothing bad will happen.

It's generally very tricky to manage passes with arbitrary number of layers in replacement shader. I'm finishing work on RTP 2.0 where user will be able to use shader of 8 layers per first pass or newly introduec _4LAYERS mode where first pass won't use atlasing and will render 4 layers. This way we won't have switching problems, but we'll be constrained to max. number of 8 layers in every scene.

 

Thank you Tomaszek, this worked great!

The last issue that we've come across is texture tiling. I have individual tile settings for each layer in the default scene. These are being overridden by the Tile Size in the Relief shader. So all four layers are tiling at the same scale.

Do you know if there is a way to allow the default scene to use its own tile size setting, rather than the setting in the relief shader?

Thanks again.

 

Then you have to copy original terrain replacement shader code into LOD400 fallback - such shader template can be found in Unity's default shaders download.

 

RTP 2 is coming. You can get feature tour here:

http://forum.unity3d.com/threads/171394-RTP-Relief-Terrain-Pack-v.-2-features-tour

 

Latest working demos available at link above or at the first post of this thread.

 

RTP2 is live on AssetStore.

REMEMBER - this version has so many things changed that upgrading it on your current project might rise potential risk of missing references, also some scripts, shaders have been arranged differnet way (different names, folder placement, etc.

So - it's best to backup your project before upgrading.

P.S. Be patient while shader compilation. GLSL versions take ages to build... :/

 

Does RTP 2.0 include the LOD manager to switch between classic terrain renderer and RTP?

RE: "you have manually set shader to the "classic" mode by setting shader LOD level. It's not done automatically after scene is loaded. In RTP2.0 there will be lod manager object to handle this. It could "refresh" lod level settings after scene is loaded (you should then call manager function on any handler that is called after scene load)"

We currently use 1.0, and would love to updatet to 2.0 if it is not too risky. Will our current work on the terrain using 1.0 be preserved?

 

RTP2 doesn't "destroy" anything. In the end it's just Unity terrain. Some scripts, shader names are different now, so the best way would be probably to backup your project, clear RTp1 from it (default terrain shaders will be used then) and then download update. In RTP2 you'll have to setup textures (height / detail maps) and params again, but it's not that nasty job.

If your project doesn't use any new RTP2 feature and is targeted to not use DX11 (which is only possible for standalones), I guess you don't have to upgrade, but you might do it as RTP2 has better UI and things can be managed simplier. As far as I remember you're using standard unity terrain shader on some scenes. RTP "classic" mode is almost the same, but doesn't offer different texture coords for layers. To use very default Unity terrain shader you could think about adding it's code in shader first/add passes as another LOD level (lest say LOD80) and turn it when you need.

ATB, Tom

 

Hi tomaszek -

First, your work looks great. I'd love to use it, but I need the above quote clarified.

What exactly do you mean by "it's just Unity terrain"? I hear that Unity's built-in terrain system suffers in performance. I may need to replace it myself, but to save time, is this a replacement of Unity terrain functionality, or does it build on top of (and is dependent on) the built-in system?

 

It's built on top of default system. It's kind of advanced shaders system with a few more features that helps use it better.

"Lack of performance" - what do you mean ? It's quite relative. Even large terrains on Unity work quite fast on mid-end hardware. It all depends how far would you like to push it. Setting PixelError param to 1 makes it look better, but might generate millions of polys per terrain which of course lacks fo performance. What I did is shaders that make terrain looking good wihout necessity to handle its dynamic meshes of more than 150-200k polys in sum.

"It's just Unity's terrain" means that I don't replace built-in terrain functionalities, dynamic mesh generation, but replace shaders which renders it with new one. More I provide methods to adjust features needed, let decide user what do he/she need. Then I provide methods to compose control splat maps using any grayscale mask generated either by my script (steepness, height, direction) or 3rd party software (like WorldMachine, or so). And many more - refer to features tour or documentation.

In the end - if you don't like Unity's built-in terrain you can use another functionality I've made - you can use my shaders (constrained to 8 layers per mesh) on any mesh. There is example scene in the package which clarifies how it's done.

My shaders are highly adjustable, either realtime (switching between POM shadows on-off / PM / SIMPLE shading) or offline where you can adjust options needed and recompile shaders and it may be done automatically with my LOD manager script, you don't have to touch shaders themselves. This way you're able adjust look vs. performance. Don't expect it run fast on low-end machines when you turn on all options like POM with self-shadowing, dynamic snow, super detail, and so on. However if you're using smaller set of options, less layers, my shaders can work quite fast and still look much better than default shaders (comparing to classic splatmapped or Unity's4 bumped specular).

Tom

ATB, Tom

 

Thanks for the great shaders, they look quite good. I am under the impression they should work with multiple terrains in unity 4, but am having some trouble getting it to work. The primary terrain sets up beautifully, but adding additional terrains doesn't seem to work, they remain white even with the script and settings applied to them... any thoughts on what I'm missing? Or do the shaders not work with multiple terrains?

edit: fixed, just had to manually add a separate material to each terrain, 'cause I was duplicating them. Another question, I'm getting an flag "shader wants tangents, but the mesh doesn't have them" which I assume relates to my using terrains instead of meshes, but I just want to turn it off unless it means there is something I should be doing... really good looking stuff here BTW.

 

Forget about missing tangents. Dynamically created meshes in Unity's terrain system just don't have it, only normals, but that's harmless. My shaders approximate tangents inside vertex program (in shader code), so we don't need it to be in terrain mesh data. As far as I know the only problem might occur when you'd like to lightmap terrain using directional mode. This moment tangents would be necessary as Beast need it. The only practical solution now would be to make own real temporary terrain mesh basing on terrain heightmap, lightmap it and use it's lightmap texture (lightmap index) on real terrain.

ATB, Tom