I just read the blog post at Unity Blog
Amazing work and information!
However,
One thing I’m curious about, is technically two questions I apologize. Question 1: Is there a built in way to handle height information for textures? So we can like, protrude rocks on surfaces, etc. (Parallax/Tessellation, etc.) Question 2: If not, will this be made in a way that we can modify the shader to put this? Or is it some hard coded shader that we can’t modify?
Thanks mate, didn’t realize there was documentation for it yet, I just downloaded the beta yesterday again hoping to have new terrain in it, wasn’t so didn’t even think to check if docs existed for it yet.
The new terrain is in the beta.
If you look at the inspector there is some new paint tools, also on the settings “tab” there is an instancing checkbox to get the new GPU based rendering.
The current built-in terrain shaders do not support parallax or tessellation. This first pass was mostly about performance and API updates. Though we are planning to look at more visual improvements along those lines in the near future.
Yes, you can override the terrain shader & material with a custom material (in the settings). As noted above, you can re-purpose the mask textures in the terrain layer to define your height maps. We are hoping to make the terrain layers more general in the future, to support custom properties.
is there a spesific format needed or could you add a RGBAFloat texture to the mask and pass more data?
The shader would of course have to know this and decode.
The latest beta does support the new terrain! I have it running on my machine here. If you’re running beta 2018.3.0b3 or newer, you should be set. I’m new to Unity, so it may have been in earlier betas, but I know for sure it’s in at 0b3 and newer. So grab 0b5 via the Hub if you haven’t already.
Regarding documentation! We are actively working on updating this right now. Keep an eye on this page and subpages: https://docs.unity3d.com/Manual/script-Terrain.html It should be updated with at least a first pass of new information before 18.3 leaves beta!
Awesome! Gonna check it out now! Thanks so much mate! Height maps aren’t extremely important for my current game, just thinking of future stuff. I mean, is there some real technical issues with supporting parallax maps and such? Seems like it should be just as simple as any other parallax map, I’ve made plenty of shaders in the past, but it always stumped me to why on terrain it has to be much more complicated in general, like the few assets that do support it (for the now old gen terrain), it was only specific slots that supported it, not all of them.
If you are already using a custom terrain shader/material, that shader probably needs to have instancing support added to it. We are working on some instructions on how to do that.
It was the shader that came with it that turned purple.
I honestly didn’t even look for options, just figured automatically it wasn’t supported yet lol.
I see the options for it now, ticked the instance thing and the purple went away, it did however go invisible. Just assuming gotta check the docs out and just mess with it a bit…
Appreciate it everyone! So excited
EDIT: Yeah I can’t seem to figure out how to remove the invisible mode.
I created two new layers, put an albedo and normal map on each and add them to the terrain, even trying to paint, I see the brush, just nothing is visible.
a) Does terrain shader building will be supported like in unreal by graphs? So devs could build terrain shader in shader graph? → Layered material node, layered blend etc… This would give alot because we could change whole meaning of each layer/material in shader. Epic features would comes from users creativity and they would be able to set any feature to any layer themselfs.
b) Does terrain will support shared material → baked array so in fact it would support every amount of layers in first pass.?
If you are using HDRP or LWRP, you will need to update to at least version 4.0.0 (preview) to get the new terrain shaders. You may have to enable ‘advanced->show preview packages’ in the package manager in order to see it.
We actually have a terracing tool in the tool pack we are working on – it is much more controllable than trying to use 8-bit quantization to achieve your terracing effect.
Holes – We’re working on it!
Collision – I’ll have to add this to our list of things to look at. Are you wanting a mesh or a heightmap export? Or some kind of stand-alone Terrain collider component?
NavMesh – I’ll add this to our list as well. Nothing currently planned.
@ChrisTchou : One thing actually, how is the performance for terrain destruction in runtime? Such as, putting a crater from a nuke or an asteroid kinda thing. (Obviously not a million miles big), but ya get my drift.
Being we’re talking about features, a simple feature to do just that might come in handy, not just for that sort of stuff, but perhaps for people who want to make level editors for their game(s). A runtime terrain editor would be nice feature (obviously that can be done later down the road). I’d rather this be very performant and have the real necessary features now.
Appreciate your support mate! (Perhaps you can make this an official post for new terrain system) to post help questions here, I didn’t see any, that’s the only reason I made a new one.
@ChrisTchou - we’re using Houdini’s new workflows at the moment - just trying things out.
One thing that would be totally beyond valuable is the concept of actual layers of height, so we can do broad changes with the unity brushes, then finer work on other “height” layers.
Or we could paint big broad changes on height A, finer local changes on height B and import some kind of erosion on height C.
And being able to pick the order of these, and the blend mode like photoshop would be incredibly empowering. So often when painting a terrain, you erase the local changes when making big moves. This would easily fix it and is a common workflow shared among most painting packages and even zbrush in kind.
(Also using the word layer for splatmaps wasn’t the clearest terminology…)
On a headless server I need an accurate collider that I can raycast against and that can use physics materials to interact with server-side rigidbodies in simulations. Nothing visual but it would be derived from a normal terrain and exportable to a separate project that may not have the original terrain. A scene in a server project / build only needs NavMesh and colliders…no mesh renderers.
I know that Terrain’s improvement work is at the beginning but I want to ask one thing, does Terrain’s vegetation system (specifically grass and details), which overloads too much, have plans? Like the same as the GPU Instancing of Terrain Core?
Another one I would like in the future is to be able to make shader modifications or create a custom shader (HDRP) in the same way that we modify the build-in shader, things like TextArrays. CustomTextChanneling, ColorMaps, Wetness, Anti-tiling … which are usually more individual features for projects but can still be implemented by dev from changes in the shader. I say this because I have my custom terrain shader in the old pipeline and would like to reimplement it / update it in HDRP but still get my features.