Relief Terrain Pack (RTP) v3 on AssetStore

Hello Tom, I'm testing your new RTP 3.1 features and I've got a problem right here. Basically everything that depends on the start distance values gets stuck in terrain's pivot.





As you can see, paralax and superDetail(in this case) is just in the corner, even if I move the camera position. Any idea about this?

 

Hi !

Thank you for this update!
You say you can not change the type of the fog.
But i have a day / night system and I want to dynamically change the fog color .
Is that possible?

 

Oops, can't believe they approved this below week... This means I need to hurry up with new pdf docs because there is only RTP3.0 available now. I will try hard to make pdf update, even if this won't be complete today.

@laurent.clave - select fog type used in lod manager and recompile. Then every time you change fog properties in render settings you need to call RefreshAll() function mentioned in current docs.

@Luis - I'll check this again as soon as possible and I'll get back here this afternoon.

ATB, Tom

 

Thank you tomas

 

3.1 is approved? woohoo! timing could not be more perfect what with the new suimono beta out for grabs. I've just finished baking out the myriad of textures to be used for coverage on my new lil project thing, with any luck i'll be giving this some decent time with prettiness all-in

 

Double checked this. Works fine. Your example is rather extreme one. As fragment of the terrain seen is flat - triangles there are also very big. Distances in shader are computed per vertex. Thats why you might have an impression that close distance gets stuck in the corver (where (0,0,0) vertex is placed). Enable texture/triangles view in scene view and come closer to any other vertex - you'll near effects there, too (parallax and superdetail). Anyway - rendering terrain with such a big triangles is bad idea if you intend to have good parallax effects. Big triangles cause distortion in parallax shaders (due to view dir interpolation errors).

ATB, Tom

 

Hello, with your new version old problems have been solved, but there is another one. We have a problems with multiterrains. If I create 1 terrain everything is OK, but if I create 4 terrains (manualy - no TC) detail textures start to behave very weird. They randomly changes to combined normal maps or even splat maps. Everything happen in Unity terrain menu, RTP menu is OK. If I try to paint textures, it paint the right texture even though in the menu is displayed incorrect one. But this make TC integration impossible ... Please check it.

Thanks

 

If you don't use U4 materials it's expected behaviour (the same was in RTP3.0 - you can check in current docs). In the end terrain is rendered right. Isn't it ? You can paint manually right layers. The only inconsistence is that you see wrong textures in Unity terrain menu which in unavoidable. Anyway - in presence of 4 terrain objects, it's always better to check "Use U4 materials" in LOD manager and recompile shaders. You won't have any inconsistency then and overall performance should be better. I explained this many timnes before (don't use materials in presence of _many_ terrain tiles like >20).

RTP integration features in Terrain Composer should be aware of this (we have setup RTP multiterrain in TC many times before with Nathaniel). I'm not sure if newest TC version takes into account newest RTP features, but it shouldn't be that problematic.

Tom

 

Tom,

I upgraded to RTP3.1 and the textures on both my custom terrain as well as the terrain in your TerrainScene are not showing up correctly on the terrain. They appear fine on the meshes, but not on the terrain. Do I need to do something by default after upgrading to 3.1? I'm using Deferred Lighting in the Player Settings. Are all the Settings in the LODManager correct by default or do I need to go in and check certain boxes to make sure they are correct? Will you be including how to create emissive terrains in the new documentation? Can't wait to try out all the new features, just need to get this initial hiccup taken care of. Thanks!

 

Thank you so much ... Now all seems ok, but "Perlin normal map that affect only one terrain from 4" problem appears again ... Removing component did not help. Terrains was set up by TC. The last thing that need to be solved. I am grateful for any advice. Thanks.

 

Oh, thanks Tom, I totally forgot about that, thanks, everything else looks like is working fine. Great update!

 

That's insistent problem I see... After setup check if these 3 problematic terrain tiles got right perlin normalmap made (go to settings/perlin normal tab in RTp for each of tiles, then right texture should be present in combined textures/special tab - that's the texture actually used by the shader). Or maybe you could catch me on skype ? (tstobierski)

 

hey there, the fog issue has stopped mostly....... except in a night time situation. (using unistorm) the fog ends up making terrain far distances look extremely white, but is grey during the day

night fog



day fog

 

this is using 3.1, just updated

 

This might be related to lighting condition setup by unistorm for night time. Is there any directional light with light strength >0 present on the scene ? I believe you could try to adjust fog color manually when it's night. I guess when you set it to black for RTP rendering they just can not produce such weird results. I could also suspect that fog settings might cause problems here. Could you give me render settings screenshot used night time in unistorm ? I'm sure we can solve this by setting up different fog parameters for RTP alone (now it's synchronised with RenderSettings everytime you call RefreshAll() in ReliefTerrain.globalSettingsHolder instance). Using black as fog color (or almost black for RTP should do the trick).

Tom

 

A bit updated pdf docs (unfinished though) is available at the official RTP.pdf link.
Describes LOD manager and some settings.

Tom

 

Where's the official RTP .pdf link located? In the current RTP .pdf?

 

I just updated to 3.1 - noticed a quite big FPS loss on the update. Scene runs with 15 MS using RTP 3.0 and 22 MS using 3.1 -

Settings General:
- RTP_Shadows, RTP_Soft_Shadows, U4 Mats, 1st Pass, add pass, far dist
- d3d9

FirstPass/AddPass Settings
- No detail color
- UV blend
(everything else off)

Now RTP 3.1 comes with new features and settings but i wasn't able to get the performance i got with 3.0 back...

 

Yes, RTP3.1 is more powerfull at a cost... Main GPU hit difference is caused mostly by:

1. PBL lighting (more complex lighting functions)
2. Additional features (new UV blend mixing, new per layer controls, UVblend like technique applied to perlin normal, global colormap improvements)

I though about it all, but in the end I wanted to make system that won't be outdated for next 2-3 years even while hardware considerations will constantly diminish.

A few toughts to improve it.
1. Check all your textures, and compress them where possible (esp. special combined texture where caching issues might arise otherwise).
2. Use 8 layers mode, preferably with no overlap (quickest solution)
3. Make sure number of your UV blend sources are minimized (preferably to one source) with the same UV blend tiling scale for all layers that uses it. I mean UV blend routing in LOD maanger could point to one layer.
4. Disable fog function in LOD manager when you don't use it

All above should compensate a bit performance hit.

Tom

 

Like before:
http://www.stobierski.pl/unity/RTP.pdf

 

I'm pretty new to RTP. I've got a good understanding of the details...I think. But, I need some help understanding the bigger picture.

If I use 8 layers in first pass, I can't have a global normal map + IBL Diffuse cube map (Skyshop). I'm told too many auxiliary textures being used. I can drop it down to 4 layers and compile. However, when I go to the terrain, I still see 8 layers listed under "Layers".

Do these extra layers exist as a second pass?

In general, is it better to use 8 layers without the IBL or 4 layers with it? I don't really have a use for layers 4-7 yet, but maybe it's just because I'm new to this.

When I think about painting on trails, streams, burnt areas on the ground, etc... should I think about them as layers or are these more like additional meshes or decals I should place?

I've been through the documentation and that's gotten me pretty far. I think I just need help with how it all fits together.

Thanks.

 

If you need 4 layers only - there is no need to use 8 layers mode which is meant to handle 8 layers in one (first) pass - not 4 (handling terrain with 4 layers in 8 lyers mode would make problems). Need 4 layers ? - use 4 layers mode (with unchecked 8 layers mode in LOD manager). It's always faster, 8 layers mode needs texture atlasing which brings additional GPU overhead. However, it's still faster in most cases than rendering 4+4 in two passes (Unity would need to handle terrain meshes twice).

If your additional decorations are rather sparse and "ocassional" you might consider puting them on the terrain using geom blend features. Otherwise, I'd recommend using 8 layers - you'll have simplier and straightforward workflow and less headache about placing very many geom blend objects.

In 8 layers mode you can use both global normalmap and diffuse IBL cubemap when you disable lightmapping (check nolightmaps in LOD manager). Then you should be able to compile shader in 8 layers mode using 3 dedicated textures (so you could use even one more feature that needs texture sampler). Although IBL diffuse seems to be tempting for many developers, I'd say - maybe it's enough to use complementary lighting (much quicker and no resources needed) or baked global ambient emissive map (in most cases gives better results, albeit it's not yet fully described in available pdf docs, I'm just in the middle of describing them in next update available later today).

Where IBL diffuse can look better are bumped details that are precisely shaded depending on their worldspace direction. Complementary lights and ambient emissive maps does it by some approximations (simplifying assumptions), still they can looks very good. Esp. global ambient emissive maps can provide your terrain with more visual richness than IBL cubemap (you can bake indirect lighting, large scale AO and shadows there). In fact this RTP feature can be comparable (competitive) with dual lightmaps. Ambient emissive map is LDR (A channel used for baked shadows), but indirect lighting doesn't need high dynamic range though.

Talking about rendeing scenarios. When you've got 8 layers used on terrain and you don't use 8 layers mode, they will be rendered in 2 passes (firstpass 4 + addpass 4).

Tom

 

More about new RTP3.1 functionality - global ambient emissive map. I've just finished describing this in updated docs. They should be available in a minute on my server (http://www.stobierski.pl/unity/RTP.pdf as usual). I encourage people to get familiar with this technique, because this might be considered one of most effective ambient/indirect lighting solution in RTP (I'd say it has quite stronger potential comparing to diffuse IBL). Tomorrow I'll maybe put here on the forum some screenshots taken from docs as seeing is believing... (and many visitors just don't read my pdf, even if they are my customers... ).

Tom

 

Thanks Tom! Exactly what I needed.

 

I'm scanning the docs now but am I right that to use 3.1 correctly with Lux in Linear/Deferred mode, I just have to:

1) Set PBL Fresnel Term and PBL Visibility Term to TRUE
2) Set Basic PBL Fit for Deferred to FALSE
3) Set Color Space is Linear to TRUE

And then other than that, I can use 8 Layers mode and everything else more or less like I was with 3.0?

For a scene with a moving sun and day/night cycle, how would you recommend handling ambient light? Should I stick with the basic ambient light color from render settings, or is there a way I can use Global Ambient Emissive or IBL and fade between maps for day/night somehow?

 

Is the usage of RTP v3.1 with the new Planetary Terrain upgrade documented somewhere?

 

Those are awesome performance tips! Thanks! I really need every millisecond i can get... will give it another try with those settings. Don't get me wrong btw, the 3.1 update is awesome, i just got a bit disappointed i couldn't use it due to all the stuff going on in my scene... RTP really is a must-have for anyone who's seriously developing with unity...

 

Everything else works like in RTP3.0, but you must know that alpha channel of your detail textures is now gloss/roughness map and you'll need to adjust specularity settings per layer (they are first section in inspector when you're in layers tab). I'll try to describe them today and upload updated docs.

For ambient lighting and dynamic night/dya cycle:

1. Diffuse IBL cubemap - you'll need to implement script to interpolate between cubemaps (day/ naigt or more inbetween one). Then you can change such prepared (interpolated) cubemap in aReliefTerrainInstance.globalSettingsHolder._CubemapDiff cubemap property. Then call aReliefTerrainInstance.globalSettingsHolder.Refresh().

2. The same for global ambient emissive map - you could preapre 2 textures (as described in docs - most straightforward way for me was using near lightmap from this dual lightmap pair generated by beast. I used Skyshops's LM extended that used skybox hdr image to bake it). Then you can interpolate runtime between them. Interpolation you will probably realize on CPU (script GetPixels32()... and so on) and this might be costy, but you can split whole job into small parts as time doesn't change aburptly

3. The most straightforward method would be changing complementary lights realtime. That would be quickest way to do things. You need to judge if this is enough for you in terms of wuality and resource drain (compl. lighting is fastest, diffuse IBL is slowest for GPU in shader).

Not in pdf docs yet, but you have example scene included and info .txt file included with description how to make PT working wirh RTP3.1. Instructions are valid for PT 1.01. I haven't checked this with newer PT version, but I assume HenryV introduced there tweaks needed to work with RTP out-of-the-box. You'll need to adjust shader features in it's code (they are well commented in properties block and #defines section below). Example scene uses many things you'll probably don't need (like global colormap or global normalmap), so you just disable them for start of your work.

Performance is always my concern, but we just can't have something for nothing. Every time I figure out an improvement, I just code it into shader. Maybe in time I'll find some quicker ways to handle terrain shading, but not now (for example indexed texture arrays in DX11 would probably lead to some lighting fast solutions, but I can't rely on one platform only, besides Unity doesn't implement texture arrays).

Tom

 

Just to say thanks for this tom, you worked your arse off on this and ive been buried in it with very little sleep for days, cant drag myself away! Brilliant work and a must-have. Really looking forwards to getting something out of it that i've wanted to for ages, kind of the stars aligning in the heavens with the tools becoming available at the moment

 

Here are screenshots presenting global ambient emissive map feature.

Ambient lighting off:


Global ambient emissive map applied (taken from "near" dual lightmap baked using LightmapExtended included in Skyshop):


Ambient lighting off:


Emisive map applied, but without modulating its brightness basing on shader normals and detail heightmaps:


Emissive map applied, with modulating its brightness basing on shader normals and detail heightmaps. Difference is subtle, but you can notice darker parts at bottoms of large rocks layer (with strong modulation we've got darker parts that are both - not flat in tanget space and lower in detail heightmap):


Emissive map applied, but without modulating its brightness basing on shader normals and detail heightmaps. Although we see bumpiness, it comes from detail color texture only (layer normalmap and its heightmap have no influence on results here):


Emissive map applied, with modulating its brightness basing on shader normals and detail heightmaps (bumps and lower parts of rock texture cracks are much darker):



Shadowmap baked in A color of global ambient emissive map:


For shadows this might be considered similar to what we get using dual lightmaps in deferred, but there are differences as follows:
1. dual lightmaps are HDR (RGBM encoded)
2. dual lightmaps are stored in 2 textures, while RTP uses only 1 (ambient / indirect LDR lighting)
3. RTP can recover bumpiness at any distance while dual lightmaps handle bumpmaps only up-close
4. RTP works for Unity free version while dual lightmaps doesn't (there is no deferred for Unity free). However it's pro feature to get dual lightmaps baked (we need near – this with indirect lighting only) as RTP's ambient emissive map (RGB) and either bake shadows info in 3rd party software or do it the way I did for sake of above presentation. I just subtracted near lightmap from far lightmap to get direct lighting data (shaded parts and those in shadows). Then I turned up contrast to get only very obvious unlit parts emphasized. Such texture (as grayscale) as merged with near lightmap from beast into RGBA texture used by RTP. Of course you can bake anything you need into global ambient emissive map. When some shadowed/occluded areas are 100% static (they can be in shadows casted by static, lightmapped objects) you can consider darkening these parts in RGB map color (not in A channel which is meant to blend with realtime shadows).

Tom

 

Hello Tomasz. Please take advice about your RTP shader. We have trouble with standart settings of parallax. We suppose that normal maps are bad of something else.
At first picture we have no parallax effect.
http://tinypic.com/r/9kcwtx/8
At second we make parallax stronger and we have waving artifacts.
http://tinypic.com/r/264swpk/8
At next picture we have grass with same settings.
http://tinypic.com/r/15ywu8x/8

We tried to use POM, PM but it's not working good.

Best regards
Mikhail.

 

Check if triangles on the terrain are not too big. When terrain mesh is flat triangles produced by Unity's terrain engine are very big which is bad for parallax mapping (any, not only RTP). To tell you more about your issue I'd need to see all your detail textures (espacialy heightmaps).
Refer to my docs - by default PM is used (POM when you check thich in LOD manager and recompile). For heightmaps that are of very high frequency this will never work fine. Anyway - you won't get grass blades extruded the way you'd like to see them as in the nature...

Tom

 

Mesh from same place:
http://tinypic.com/r/28l9tnr/8

Textures:
http://sharesend.com/c7ke85z1

 

I absolutely love this thing - here's a screeny of today's work which looks highly likely to end up as a game of some sort. Can get great results and only scraping the tip of the iceberg

 

Wow, global ambient emissive looks awesome. I'm only having one problem with RTP right now: My terrain now looks so good that the rest of my assets look terrible in comparison.

 

RTP's already doing it's promo magic, it's good times, it seems like with a bit of elbow grease an rtp3.1/lux product is coalescing

 

We have minimum values of parallax like 0.01-0.005, but there are waves on terrain. It's look like texture was extruded in the side. Please look at textures in the post above.

 

Your textures looks fine, but I see your mesh isn't Unity terrain, but probably custom one. I assume you're using RTP on your own mesh. Are you sure you've got it uv textured properly (preferably the same like Unity terrain top planar with uv bounds of 0..1 x 0..1 for straightforward global mapping) ? I would say you might have tangents badly calculated for your mesh. Eventually you can give me your mesh (or part of it) in private forum message link so I can check this myself.

Tom

 

It's not my own mesh. This is raw which i imported from world machine (2049 hiegthmap). I think its normal resolution for terrain.

 

So it has been probably split into several meshes as Unity's triangle count limit for single mesh is 65k. Anyway - you need to make sure it has been properly uv mapped and tangents have been calculated when importing.

If you find it better for your workflow to use WM meshes, that's up to you. But - wouldn't this be better to import raw height from WM (remember it's flipped in one axis !) and make unity terrain object out of this ?

Tom

 

We found dicision! We made low detail hieghtmaps with blur effects and its work! Now terrain looks pretty well.


Thanks for your advices. Your shader is realy good.

 

And one thing about 4096 defuse maps.. Unity crashs when we make color atlases from them using RTP.
If i change number of layers from 12 to 8. Its woking bad.

 

4k detail textures is bad overshoot which would imply making atlases of 8k x 8k size which are not possible in Unity (and Unity 32 bit editor crashes when you try to make them). Considering number of layers - chaning their number after RTPhas been setup on the terrain might lead to some problems. Setup things aga from scratch (8 layers terrain and the apply ReliefTerrain script). When you'd like to use 4k textures you can't use atlasing modes (8 layers mode by default).
I assure you that your ame won't work much performant even on hiend machines when you will use 2k textures, too. They are too demanding in terms of GPU caching.

Tom

 

Ok, i see. So, when unity 5 comes out. We will be able to use 4k texs?

 

Question should be adressed to Unity... As I said - you can use it even now (4 layers unatlased mode and for desktop apps only), but performance won't be astounding anyway.

What makes it so crucial to use such big layer detail textures ? If detail tile size will be small you will probably never benefit from their MIP 0 level (wasting resources) unless you come and look at ground from 50cm distance. Going with bigger detail tile size (like 10-20m) might solve some tiling patterns problems at mid distance, but you should be able to succesfully use 1k textures with tiling size of 4-5m and use all techniques available to reduce patternization as well.

Tom

 

Ok, its comprehensive answer. Thx.

 

I noticed that RTP's fog does not automatically update when the fog color and distance settings change at runtime. I can get it to update by clicking the "Refresh All" button in RTP Settings -> Main. Is there a method I can call to do this at runtime? Preferably something that just recalculates the fog rather than actually refreshing everything, as I assume that is slower.

 

Refresh All button invokes aReliefTerrainScriptInstance.globalSettingsHolder.RefreshAll();

It might be slow when you've got many terrain objects. To make it faster call

aReliefTerrainScriptInstance.globalSettingsHolder.Refresh();

Also - refer to docs where you've got every parameter described - you can refresh only fog params (they are global shader properties).

BTW - new docs available. Today I was working on PBL / IBL options (http://www.stobierski.pl/unity/RTP.pdf). They are almost fully described (placed in section about layer properties).

ATB, Tom

 

Hey tom, I'm having a issue right here using spot lights. When I point up with them, I get no duffuse reflections:


But if I'm pointing down:


The light source position must be higher than terains reflected light height to work properly.
Any sugestion about this?

 

I don't see anything suspicious on your screenshots and I'm not sure where your spotlight is placed in relation to terrain surface. When you put its anchor below ground level you might have weird behaviour (we should have no light then, should we ?). For test purpose I setup night conditions (no realtime light except for this spot light). Spot light is placed in the problematic orientation, but everything looks fine on my side:





(sunk cubes are white so they reflect diffuse light much stroinger than terrain). If you find your additional geometry (rocks) are too bright when spotlit - maybe you should check their brightness incomparison to terrain in the same lighting conditions ?

Tom