[uTerrains] Ultimate Terrains - Voxel terrain engine

So I totally bought UT despite some issues I saw in the demo that include the following (mainly issues with weird UV/seams and non-manifold geometry):



The last (two) images are what concern me most -- it seems like this can happen almost anywhere. Way off in the distance seems to be affected too (mostly with seams). I'm not sure if this is what's causing the distorted flowers above, but I'm hoping this uv issue was fixed in the 4.0 version (I haven't had time to test), since the demo was 3.0.

I read somewhere that this method of voxel generation has issues with non-manifold geometry. I wonder if there's any way to mitigate that? I really love the flexibility of this system -- I bought it with faith that these issues will be addressed at some point.


For now, is it possible to "stamp out" seamless tiled meshes based on voxel generation? -- For example, if I generate a huge worldmap terrain, can it be "chopped up" into more manageable "mesh" terrains by uTerrain so that can be streamed in/out by something like World Streamer? I can re-texture the terrains myself, but the UV generation must still be correct at least.

 

@awesomedata
The issue you are seeing on the last image (as well as the second) is indeed complicated to solve in a generic way. Actually, the issue comes from the distance field which is has some discontinuities. It will be easier to solve that kind of issues in the next update by adding some filters to smooth the top of sharp relief like this.
The first one is actually also a distance field problem. Different noises would improve the result.

I really have a lot of work and a lot to do. Please be patient, this is unfortunately not my full-time job so I can't always develop as fast as I'd like. I would love to make it my full-time job, and this is also why I'm working in parallel on another project. This would dramatically improve my development speed! But it's far from being possible for now.

Many people ask for this, but this is actually not a good idea because you would end-up with waaaaay too many vertices in your scene (because you wouldn't have the LOD system with static meshes).

 

Thanks for the feedback -- I can stand behind that idea.
My artist-eye gawks at these images, but my programmer-brain knows your tool isn't inherently flawed. I do expect a lot out of this tool, but I know there's still work to be done. Patience is definitely something I can do. Thanks for taking the time to put this awesome tool together in the first place.

Your LOD system is awesome -- but keep in mind that, as an artist, I'd rather sacrifice it for artistic freedom and control if the choice came down to it.
That's why I think this tool hasn't caught on more.
People are trying to understand how to integrate this into their current art workflow/pipeline, which means they don't have an awesome LOD system to rely on in the tools they currently use for artistic freedom and control -- UT isn't too far behind in that area; as far as I can tell, UT just needs tools or workflows to better supplement scene authoring and vertex-painting to help them achieve similar looks as other tools.

The major issue with most of us artists is that some things in Unity require access to the mesh -- for example, manually painting verts (to put certain kinds of ground-cover in particular areas) using something like Polybrush so that we can work with certain shaders. Also, placement of ground-cover and rocks/boulders/houses/etc. need to be done in scene-view too. To help with scene authoring, perhaps a temporary "display" scene that can be modified (and transferred back over to voxels) would be better and let us keep the LOD system? Editing a large world gets tedious without an overview of what's going down in certain areas of that world.
Also, floating point issues (physics/animations) happen after about 3000 units. Which is why stuff like World Streamer exists -- it moves the entire world. D:

 

@Amandin-E i get that you dont want to eta for the path finding, but is there anyway you could maybe release an early access not fleshed out version that only does what you have shown or something?

Ive seen other assets do this with pre launch tests you could buy into with the understanding that its early, and they seem to usually go well

And id love to be able to start messing with it soonish rather then months down the line

And even without full collisions with everything, theres still stuff we could make within that scope in the mean time for funsies

 

I have problems with the changes in the editor mode and runtime, I load the runtime but not the editor and i need them, could you clarify what I'm doing wrong ?, and sorry for the poor English, I speak Spanish u.u

 

I own Voxeland and MapMagic and its not even able to compare to Uterrains.

 

I'm still waiting for this latest update, it would really be nice to have access to.

 

I ended up grabbing uTerrains, though I've not yet really even fully explored it, what was better over Voxeland/MapMagic though? Just for reference it's always interesting to read the comparison, as they are generally hard to come by when it comes to similar Unity assets people either own one or the other and you can only go by reviews etc.

 

once the pathfinding stuff comes out uterrains will be the only one you can realistically make a game in

since with destructable voxel terrain unitys navmesh doesnt really work

 

really it doesn't? VoxelPlay which I am also using seems to use the Unity Navmesh pretty well including when breaking/making terrain, I would think the Unity Navmesh is one of the better ways. I bought A*star Pathing asset thinking that his asset would provide a better solution, and it does have various different pathing solutions but it came out to be that Unity's newer Navmesh just worked better with realtime changes it does it pretty fast, also the scale of a terrain was another problem. Shame really I'm not sure I'll find a use for that A*Star pathing asset now, its also not really integrated in any voxel framework so you are reliant on collides for it to work and making it work yourself.

 

Biomes in uterrain is far better

 

oooo would you mind sharing how you got navmesh to work, im pretty desperate for a way to have enemies moving around

 

I would like to know this as well

 

Maybe miscommunication, I use another asset called VoxelPlay purely cubes no smooth terrain, navmash support was built in. For uTerrains afaik so long as mesh colliders are generated for the terrain changes, then getting Unity's navmesh stuff to work isn't so hard, not that I've tried looking at that.

 

@Amandin-E

Speaking of colliders -- are you planning to integrate the new per-scene "physics world" features into uTerrain?
For example, if I go too far past where the floating point issues start in the world, physics starts to get pretty wonky there. Having physics worlds could definitely help with these issues.

 

I have had no issues with physics and I have walked in one direction for a long, long distance

 

it would be cool if we could do it in reverse and move the world around the player instead of the player around the world to avoid this

no idea if its even possibly tho

 

You can not do this because of how the chunk loader does chunks, I just tried. I found the best Floating Point Precision Error happens, even in the best of games like Minecraft.

Layered coordinate system would be a good solution. You have to take those layers and recombine them into each objects' transform relative to your camera's position before each render. Realize though that there will be precision loss when converting objects positions that are very far from the camera but it wont matter because they will be too far away to notice and the precision will be preserved in the layered coordinate for if and when you move closer to that object. Is would create desync issues in a multiplayer environment though.

I have not had any precision issues using uterrain yet though and I have walked for hundreds of chunks in a single direction. I put a coin in my keyboard and walked for 8 hours in one direction and when I came back I was still walking.

 

This is true -- maybe some version of a physics world is already implemented in some way?

Unfortunately animation and vertex positioning definitely doesn't survive the long trek. They begin to wiggle after a bit thanks to floating point precision issues. D:

My solution (so far) would be either a separate camera specifically for uTerrain, or to reposition all loaded objects (including the voxel terrain) back to the origin point after a certain distance -- but I'm not entirely sure this would be a successful solution. Anyone else tried moving uTerrain back to the origin? Does it work decently / not hiccup when a lot of chunks are loaded? How about a separate camera? Seems like that method might be prone to shadow errors though. D:

 

Hi there, it's nice to see more and more people sharing their thoughts on this forum thread

Just wanted to let you know the other thing I was working on is almost done and I'm going to be able to focus on uTerrains again. Things should move faster. I improved my shader skills thanks to the other project and I'm going to be able to include a triplanar PBR shader that supports 8 textures in one pass in Ultimate Terrains. Not as good as MegaSplat or RTP3, but far better than the existing ugly shaders.

I know all of you are waiting for the next update. I am too! I know this is frustrating to wait, but I promise I'm doing my best, taking into account that I also have a full-time job... and a 10 months baby to take care of!

About the floating point precision issues, I think the best would be to implement a floating origin. At some point, when the player is too far away from Unity's origin, the world (player, terrain, objects, etc) would be translated to stay closer to Unity's origin. Internally, uTerrains would keep track of the true world origin.
The downside is that all your scripts would have to take this into account (I mean, if you created some spawners or stuff like this).
What do you think?

What is the issue exactly? Changes made in the editor are loaded while changes made at runtime are not?

 

I'm fine with the current shader and just support for the other third triplanar party shaders, and I know you mentioned earlier that you had a patch for CTS shaders, so I just feel like if that patch works with CTS then I'm good to go with a better terrain shader. Of course if the new triplanar shader isn't much work to do by default for uTerrain then sure, but I'd rather see your time spent on tooling/brushes/features etc and bug fixes ofc.And the path finding issue, have you seen if Unity's navmash realtime updating can be made to work with uTerrains?

Also is it possible to have completely empty chunks? like if I made a large cube, can the bounding area be checked by uTerrains before generation to see if it should create chunks or if the 'large cube(s)' assigned to blocking terrain chunks from being generated in those areas blocks it? Would be a useful alternative to not being able to have multiple instances of uTerrain being used in patches etc. The reason I see it being useful is using uTerrains as sort of hybrid, and obviously I don't need massive chunks of uterrains geometry that isn't even seen as its being covered up... if you see what i mean.

 

I have actually been using Amplify Shader Editor for my Triplanar shader

 

This sounds like it would create unpredictable bugs

 

I have used UTerrain Successfully with both CTS and MegaSplat so I don't see the issue ?

 

I think this will create issues with people like myself who use 3rd party infinite world spawners

 

What having chunks that don't get created? I don't see how, other voxel frameworks have supported doing so, I'm sure this does aswel I'm just asking because I haven't had time to really look into what is supported etc.

 

If you supported something like GPU Instancer (and maybe Vegetation Studio / Pro) for spawning and World Streamer for streaming scene loading/unloading, this could definitely be viable.

An easy way to go uTerrain.World.getOrigin to grab the actual (current) origin of the world would definitely be useful.
Maybe adding a list of layers and tags that will be translated with the world origin (or excluded from translation -- or both) would be best, in case users don't want some layers or gameobjects to be transitioned to the new origin.

The only other issue with a floating origin is with streaming scenes loaded asynchronously (with something like World Streamer).
For example, at some point, I will have to unload and load new groups of gameobjects located around the world. If the world origin suddenly moves on me to someplace different than the scene itself expects it to be when it is loaded, bad stuff could happen. Maybe an option to use World Streamer's origin as uTerrain's origin would be good?

 

Interesting idea. But I would expect that to make the terrain "bumpier" without necessarily creating hard edges (in my Cubiquity example, the low poly look had nothing to do with making it bumpier - all the vertices and polygons were in the exact same place as when it was smooth. They simply had hard edges between them to create the illusion of low poly).
This is uTerrains at 0.5 blockiness:


This is 0.5 blockiness with "duplicate vertices" checked (slightly closer, but no cigar):


When I was looking into it, I learned that meshes with hard edges achieve their hard edges by simply not sharing vertices between polygons. Each poly has its own three verts. Its neighbouring poly has three separate verts (although two of those verts will occupy the exact same location as two of the verts of its neighbouring polygon, but they aren't the same verts being shared by two polys, just separate verts occupying the exact same coordinates). On a hunch I went straight to where the "duplicate vertices" checkbox in OctreeNodeVertexData.cs is used to check if it should duplicate certain vertices, and commented out most of the checks. For example:

Code (CSharp):

1. public int DuplicatedEdgesVerticesIndexes(int edge)
2.         {
3.             if (duplicateVertices) {
4.                 /*if (!isUsedEdgesVerticesIndexes[edge]) {
5.                     var iv = edgesVerticesIndexes[edge];
6.                     if (iv != -1) {
7.                         isUsedEdgesVerticesIndexes[edge] = true;
8.                     }
9.  
10.                     return iv;
11.                 }*/
12.  
13.                 return Duplicate(edgesVertices[edge]);
14.             }
15.  
16.             return edgesVerticesIndexes[edge];
17.         }

That had an interesting effect, but didn't quite work (I could only notice the effect by putting a shiny material on to accentuate the edges):


Looks almost nothing like my previous attempt in Cubiquity and that classic low poly look in Astroneer. So at this point, I'm trying to find exactly where I need to intervene to ensure polys all have their own separate verts and don't share verts.

 

Ok, i understand better what you need. I think you need 3 things : duplicated vertices AND normals computed independently for each triangle AND some flat shader.
Duplicate vertices checkbox gives you the first one.
For the second one, there is a trick: if blockiness is >0 then normals are computed by triangle, so you can set blockiness to 0.01 to achieve this for example.
For the third one, of course, you’ll need your own flat shaders.
Let me know if that gives the right result.

 

@Amandin-E any update on pathfinding?

 

@Amandin-E there is still some issue concerning performance. I noted that UltimateTerrains causes lags on main thread. I think thats a thread-context-change issue when CPU usage goes to 100% (it does even on a 6-core 8th-gen i7).

* Maybe you can use UnityJobSystem or ComputeShaders to do that work in future, but I know thats a bigger project.
* For now it helps reducing the thread count. This drastically reduces lags and improves max camera speed. Cores-1 threads is too much, as the competition between main thread, unity job threads and system threads causes lags.
* It may help to low-prioritize LOD0 and recheck if still needed on calc. This would just leave LOD1 visible when moving into LOD1 area when no CPU is available to calculate. Not calculating LOD0 when no CPU is available should drastically improve performance(200-300%?) without much impact on visuals, as LOD1 is sufficient at fast moving (better than lags)

 

Thanks for the info. Not much of a shader guy so I pulled this one from the internet:
http://www.shaderslab.com/demo-90---flat-shading.html

And that seemed to work pretty well:



But that seems to be all down to the shader because it looks exactly the same even with 0 blockiness and without duplicating vertices.

This is a quite good solution, but it does have some drawbacks:
When reading about how these shaders work, apparently they take the normals of the three verts for each face and average them out, and they have to do that for every face, so people were saying that this is actually more computationally intensive than just having separated polys in the mesh in the first place (although, judging from the profiler, I didn't see a huge difference in performance).

The other drawback is that if I could have achieved this effect on the mesh side then that would have freed me up to use any shader I wanted, but now it seems I'm going to have to learn how to code shaders if I want any different effect (for example, if I want there to be a specular, or to actually use textures, because that shader I pulled from the internet can only do 1 colour per face, so there can't be any texture on a face).

So I think I'm still going to do some poking around to see if I can find a way to do it mesh-side (if you have any more suggestions let me know). And if you are making a triplanar PBR shader for the next update of this asset, maybe consider including a "low poly" mode or version of that shader.

 

Yeah, wow, that flat shader looks so drab and bland when I compare it to other shaders used on low-poly cubiquity voxels:



It would certainly be convenient to have my pick of shader to apply. I'll maybe keep trying to separate the polys. Let me know if you think of any low-hanging fruit to try in that respect.

 

If you're going to do up shaders may i suggest shaders for LDRP and HDRP? It might be better to do that rather than looking at backwards support for the older pipeline?

 

Did UTerrains support Vegetationstudio ?

 

@Amandin-E think this will become an urgent problem soon. uTerrain doesn't seem to work with Unity2018.3 under LWRP

 

How did you get the CTS shader working?

 

I just applied it to the material

 

Uterrain works on Untiy 2018.3 and 2019.1

 

Have you tried Amplify Shader Editor, it works incredible on uterrains.

 

This requires Heightmaps, Uterrains don't use heightmaps.

 

@ProtoPoly perhaps my wording was a little bit inappropriate. What I meant was: While it works with the default 3D Pipeline, it doesn't work the the LWRP (terrain appears pink).. Perhaps getting a sense on when LWRP/HDRP will be supported will be useful

 

New render pipelines will need more work. It’s completely different. I will dig into it but this is not my top priority right now.

@ProtoPoly and others, thanks a lot for helping other people on this forum! It really helps and make me win some time.

I need to fix a few bugs in the editor scripts concerning the node based biome configuration but I’m pretty close to have something testable. I will send the beta to some of you in a few weeks (probably around Christmas).

 

You do know I am willing to test sooner, feel free to mail me or discord me.

 

fyi this wasn't any help to me at all, I get you apply the material, the question is the cts materials have a completely different mapping of texture inputs than the uTerrain triplanar shader, which one did you lite basic advanced, in the uTerrain Top texture slot, which one would that be in CTS likewise for Sides texture, Red/Green/Blue/Alpha channel etc

If direct CTS support could be added that would be great.

 

I use ASE (Amplify Shader Editor) on a Default Rendering Pipeline and Triplanar Shaders and I have done Intensive PBR Blended Shaders using MegaSplat VIA ASE (Amplify Shader Editor)

http://www.megasplat.com/integrations.html

 

Voxel Engines require Triplanar Shaders, this can not be avoided, and to be honest, CTS is a material map based system and does not hold ground on such a powerful terrain engine. You will not find any voxel engine that supports CTS.

Edit: https://freetutorial4u.info/cts-complete-terrain-shader-version-1-1-0-jul-14-2017-unity/

Looks like CTS is working on supporting Triplanar, if it has not already done so, please contact CTS support on Triplanar shaders rather than expecting the terrain developer to meet the needs.

Edit: https://assetstore.unity.com/packages/tools/terrain/cts-complete-terrain-shader-91938

released Oct 3, 2018

Per Texture Control:
- Albedo, Normal, Smoothness, Roughness, Height, AO;
- Near and far tiling - reduces tiling;
- Tinting - matching & seasonal variation;
- Brightness - texture matching;
- Smoothness - reflection & wetness;
- Height blending - relative texture heights;
- Height depth - relative texture depth;
- Triplanar - no more terrible cliffs;
- Detail strength - use it as needed;
- Geo strength - use it as needed;
- Snow amount - control snow cover;
- Snow / Water - angle, height, hardness;
- Snow / Water tint - vary color by usage;
- ColorMap strength - near and far;
- ColorMap masking - controlled maps;

Please do your research and make sure your updated before making feature requests.

If you have any further shader issues then I recommend you get yourself Amplify Shader Editor

https://assetstore.unity.com/packages/tools/visual-scripting/amplify-shader-editor-68570

If you are thinking that Shader Graph is a suitable replacement for ASE, you are severely mistaken.

 

@ProtoPoly thanks! Agree with you on the doing our own research bit.

@Amandin-E currently I understand you're working on a bunch of different features (pathfinding, new shaders, fixing bugs with biome and maybe even some filtering stuff?). Do you think you could provide a Roadmap on what you're working on next and where you're taking this? Won't hold you to a timeline or even expect one.. but I think it will give people a sense of where you're going with this asset and what your priorities are. Alternatively you could drive priorities through a poll or something. Your time is limited and getting the community to vote might give you the most bang for your buck?

 

I already know CTS supports triplanar shaders, jeez you're not actually helping at all btw.

 

Hello, is there a Discord server for this asset?