[uTerrains] Ultimate Terrains - Voxel terrain engine

@peanutgallery you are lucky, the next update will fix some issues where vertices are outside of their intended area, making artifacts just like these.
Hopefully, this will be enough to fix your problem

 

@BradZoob
You can find the new documentation about saving/loading here: https://uterrains.com/doc/#Loading_terrain_changes

That's what you'll get with v3.1 that is currently pending for review

 

Annnnnnnnd, it's done. V3.1 is available on the asset store.

 

i just updated to the new version, and occasionally if i dig and build in the same area for a bit i sometimes get black faces now

by any chance do you have any advice on how to fix this?

 

i found a way to reproduce it, if you hold your mouse steady and do a bunch of box add brushes in a row

and then delete them again without moving the mouse

some bits will be left behind

and if you edit near them parts, certain faces from the left over bits will turn black

 

All right, I'm going to fix this. Thanks for the feedback!

 

Thank you

 

The terrain definitely seems improved but I'm still getting some really weird areas... Examples:

 

Version 3.2 is now pending for review, and should fix the "black triangles" issue.

@peanutgallery Would it be possible that you send me your shader and ideally your terrain configuration so I can fix those problems? I think this is due to bad normals and/or tangents.

 

Looking forward to update, ty

 

Sure can! I just sent you a bunch of images with my setup. Hopefully you can figure out my problem

 

Has anyone tried to test this with a MacOS build target?

I'm looking at switching my current voxel terrain system over from Cubiquity (it is 4 years old and deprecated after all) to a newer maintained system. I need to be able to support MacOS machines. One of the reasons for the switch to a new engine is 10.13 High Sierra and 10.4 Mojave have become increasingly unstable when trying to load the libCubiquityC.dylib critical for reading/writing VDBs.

I see LibNoise.dll and Newton.Json.dll in the plugins. I'm assuming the LibNoise is used for random infinite terrain generation and could be switched for a different library, or just ignored? I see in the Newton Json documentation that it supports Mono environments, and with some quick searching even Mono Mac (with some work). I'm guessing you use this to read/write/serialize the JSON "chunk" files. Would it possible to use Unity's built in JsonUtility for that?

 

@joferjoe @peanutgallery V3.2 is out, could you please confirm that it fixes the black triangles issue?

@TwoBentCoppers It is 100% compatible with Mac Os as I'm developing Ultimate Terrains on my MacBook pro most of the time! So you don't have to worry about that.

Newtonsoft is used to serialize operations (ie. modifications) and it's needed because the type information must be included in the json which Unity does not. But don't worry, it's a fork of Newtonsoft that makes it 100% compatible with Unity, including platforms that require AOT compilation.

 

Yeah it seems to work perfectly now thanks a bunch

 

Really liking this update, it seems faster yet again, and no matter how much i spam add / dig / flatten i cant seem to make any weird geometry or holes

 

And sold! Now to refactor my current apps to uTerrain.

 

hello @Amandin-E

i would like to know how these tools performs on mobile? (is there an android demo?)
am interested in creating meshes using voxel tools, but at the end i want these meshes to be static in build.. am not interested in the whole digging/dynamic aspects during runtime or gameplay.

any insight would be helpful!
also does the tool have away to store all voxels in scene in separate asset file?
so just in case something goes wrong in scene.. i can recover from the stored file

 

I gave it a shot, still having issues -- I sent you a private message with screenshots.

 

Mobile platforms are not officially supported and not tested. There is no provided tool for exporting meshes as it would generate too many vertices without LOD. What you could do, is create a very small terrain with only LOD 1 and save generated chunks manually (as prefabs). This should work on mobile.

You cannot save raw voxels in a file, but there is no need for that. If you want to backup a terrain all you have to do is a backup of your scene as well as StreamingAssets/uTerrainsData directory.

OK thanks I'll look at this. Note that the next update will focus on adding new operations and generators, so the fix for your issue might come later.

 

Hi.
I want to import an fbx file to this terrain engine. I want this model to be deformable. Is it posible, or can it be done easly?

 

Woo! will do some playing with it this weekend, thanks!

 

This is doable, but not easily. Generating a distance field (voxel values) from a mesh is not easy unless you are good at math and programming. I may add this feature in the future, but I have a lot to do before that.

You're welcome All feedback that allows me to improve the product is very welcome and I'll always try to take it into consideration if I have enough time.
BTW, if you like it, feel free to rate/review uTerrains on the asset store. Good reviews are priceless

 

@Amandin-E I haven't tested it again recently so it might already be fixed, but i remember having unity crash occasionally when i was trying to use multiple terrains and being able to affect them all.

And it'd be really cool if you could use multiple volumes in the same scene as it would allow for level transitions to have both areas in memory at once, and you could even have a smaller in between volume for a cave or something

And you could even go further and have every wall in a house its own volume so walls are destructible for example

Or make a bunch of mineable rocks that all look unique out of small volumes

 

@joferjoe It's not a good idea to use multiple terrains in the same scene for performance reasons and memory usage (which can explain crashes). You should use multiple biomes on a single terrain instead. Why exactly do you need to have multiple terrains?

Also, I'm not sure to understand what you mean by "volume". If you create some walls with blocky voxels you can already destruct them. I probably misunderstood your point

 

Your asset seems to perform better the more limitations to the space you provide it.

So for the wall example i was thinking, if the wall was like only a 3 blocks deep and then like 8 blocks wide it would perform far better then a huge infinite world with just them blocks active.

And for the multiple terrain example i thought splitting the map into bits and then having visual separators to unload areas you cant see would be good for memory management and draw calls too.

 

Hello!

thanks for the amazing asset - I'm really looking forward to seeing it evolve into a friendlier tool but performance wise I can see it is amazing already.

I would like to ask a few questions to see if I can make this work under the context that I want it to:

I would like to be able to change the seeds of the biomes in realtime and have the terrain regenerate as needed. I understand this can't be used in game play as the action takes time to generate the terrain, however that is not really an issue.

One of the reasons I want this is because I'd like to be able to press a button change a seed on a script and have that seed affect the generators in the biomes that I have set up - as opposed to having to go into the biome window and modifying the parameters through the editor. I believe for a tool which holds procedural generation at its core, it would be convenient to not be forced to do all of this through the editor - and by reading the documentation I was not able to find solutions to my scripting questions as to how easy this would be to implement or which functions to call and etc.

Could you please elaborate on which classes should be modified in order to be able to achieve this result? I want the same type of controls for the grass parameters however once I gained access to them through code by getting the VoxelType from the VoxelTypeSet data, and modify it after generating the terrain, it seems to no longer have influence on the grass. Once again I understand modifying the grass would require to regenerate the meshes however I simply wanna be able to control this through script as opposed to being forced to do it through the editor. I do not mind implementing a loading screen behind it however it is essential to me to be able to script these features. Particularly, at this moment I really need to modify the color of the grass in realtime according to the randomized color on the ground (based on a substance designer file) and I simply can't do it because once the grass is generated the baseColor and dirtyColor of the GrassParam instance on my Ultimate Terrain instance, seems to no longer control the grass that has been spawned.


If you can't provide a way to do all of this already through functions such as "ChangeGrassColor()" or anything like that that i might be missing, could you please guide me as to which classes I would need to look into and modify myself to be able to generate this based on a seed that I choose at runtime? I'm not the greatest programmer but I have even written my own marching cubes Terrain and octrees so hopefully I'll be able to figure it out without bothering you about it once I know where to look into.

Once again, thank you so much for the brilliant product, and I hope the documentation gets better over time because your product deserves it!


Thank you

 

Hello again,

Unfortunately I've been having some more issues while trying to work with Ultimate Terrains & RTP.

I understand that you only developed Ultimate Terrains and not RTP. However I did see several times that you recomended to use a better triplanar shader with your package as yours was not as great. Particularly I saw you recommend RTP 3 several times, so after buying your package I decided to buy RTP too, to compliment it since I remember from when I coded my lacking voxel terrain implementation just how bad it looked without proper shaders.

It has been a bit of a struggle dealing with RTP. There is no tutorial online by either the developers behind RTP nor Ultimate Terrains about how to properly integrate these assets together. I don't mind this particularly much, however since you seriously encourage your clients to do so, it would be good if we could get a better documentation as to how to get it working together. I find myself having a 40 dollar shader that doesn't really work well with UTerrains right now (at least according to the integration process described on the UTerrains documentation), and unfortunately I have better shaders for other uses so I'm not sure I'll be using that RTP package for any other purpose.

I'll describe some of the problems I'm having with the RTP integration and UTerrains in general:

About RTP (in UTerrains)...:

1) The documentation says there's a need to comment a few lines (UV Blend stuff) on the RTP standard shader to utilize them together. When I did this, I found myself having a shader that simply didn't work; when commenting, terrain would simply not have a material associated to it at runtime. This is a bit annoying because basically there was no need to comment these lines - as a matter of fact just using the shader and unticking the UV Blend bool field was enough to utilize RTP with UTerrains. I unfortunately spent quite a few hours to figure this out on my first attempts to build terrains.

2) Parallax Occlusion Mapping and Parallax Mapping seem to be so minimal on the terrains generated. The effects become quite irrelevant even with minimal tiling. This is unfortunate as these effects really make everything 10 times better looking. I've tried using the RTP with a few objects that weren't procedurally generated and they seem to behave much better with the shader themselves - however for some reason many of these features are lost when integrating with Uterrains.

3) RTP mentions on their tutorials that it is necessary for the RTP Lod Manager to be on the scene to compile the shaders or some weird thing like that, I'm guessing, according to the features that you decide to utilize.
OMG, I don't know what is going on here... I understand the functionality of a 40 dollar shader package should be expected to be this high, but I wasn't expecting to spend so much time figuring a shader out when I saw on the UTerrains documentation that I only had to comment two lines to make it work together - it certainly was never this simple.
Unfortunately, I suspect part of the "workarounds" I've had to perform around RTP integration with UTerrains are breaking my build.I cannot generate a build if the terrain is utilizing the RTP shaders - the terrain seems to simply not generate on the build (I would imagine the materials are once again "null" but I haven't checked on a dev build).




It does not seem to me that RTP integration is very straightforward with UTerrains. I'm sorry but I'd be very happy if you could offer some support here because I'm on a deadline and I've already spent a few more days than I should have on this.

I will proceed to try to build with different materials, materials that have shaders that I've coded myself. I'll report on whether this allows me to generate the terrain on the build once I know the answer to it. [This has been updated and the proposed fix did not work]




About UTerrains:

1) Documentation needs more work. I'm sorry to be persistent on this subject, but one of the reasons I've spent days working on this is because every day feels like a tweaking day. I have found myself spending hours on steps of the generation such as figuring out how the noise is affecting my terrain, and how to utilize the Biomes. There isn't much info on the documentation as to point out in which directions one could go about building complex terrains. The examples only feature terrains with one single material utilizing the triplanar shaders. This is not good as eventhough the functionality for Biomes is there, documentation on how to implement it is not good enough to do much about it, and the examples are not good enough to indicate how to do so on our own (by reading scripts on the example scenes that show how to go about the process). I've managed to do so at this point however it took me a while of playing around.

2) Building the terrains takes quite some time as there is no way to reduce the level of chunks to, for example 1. It would be great to be able to only generate a few chunks quickly and particularly through the press of a UI button or at least a call to a method. Being able to do both of these things would improve ease of use dramatically at the begining steps, and particularly for someone who just bought the asset and is only starting to figure it out.
I think it is important to remark that generating the terrain can take some time, not much but enough as to become very frustrating when in order to modify the frequency of a noise by just a tad bit to see if it looks right, one must stop the game, and press the play button again - often, seeing differences on the terrain can take up to a minute sometimes. When you're tweaking small details, having to wait 3 minutes inbetween each iteration of what is to you, simply a "number" (such as the value of the frequency of the noise, or etc), is not designer friendly at all. It would be great to be able to have a single chunk terrain which generates quickly if anything, so we can prototype the noise features fast and reliably and only after getting the noise looking right, apply it to a bigger map.
I can understand that some noises are meant to be used over several chunks, and therefore having a single chunk could be missleading in comparison to the actual result when applied to several chunks - big mountains won't be evident and such. however.... being able to analyze the "micro details" quickly, would be amazing.



3) I think I read somewhere your next update was going to focus on Operations, Biomes and Generators implementation so that you would have more presets to offer and such. This would be greatly appreciated as the few available are very simple and not really usable for more than simple demonstrations. I would seriously encourage some youtube videos - particularly given how UI dependent the workflow for UTerrains is, it would be nice to be able to see the screen instead of having to read documentation. At least for the beginning steps - I'm not saying you need to make tutorials on how to code generators and biomes, but a slight intro to how to deal with them would be good. And a slight intro to how to use UTerrains and its features in general would be even better.




To finalize:

I can dream thanks to the potential offered by your asset. I can imagine what you can build with it as a developer - as it seems to be a very nice tool. It seriously seems so. However I strongly feel not many people other than you (the developers) understand how to work with it properly as of today. It is a bit frustrating as it is evident the juice is there, it's just kind of locked behind bars for the time being.

I am sure this will get better with time, as I've read you're working on getting more documentation out and I'm really happy about it, but I hope it'll come soon.

I would love to use U Terrains as the foundation for my games and ultimately be able to extend it as much as needed to fit my designs, and I see a lot of potential for this on the little that I've been able to grasp from working by myself and figuring stuff out by reading your code. The documentation was good to give me a 10-20% boost at the start, but unfortunately most things had to be figured on my own. It is that little fact which holds this asset a little below it's actual value.


I know this is a really long post and may sound mostly like a negative one - however I believe if you read my previous post you should know already that I am happy with the potential that I see.

As of right now, I don't think I'd be able to setup scenes like the ones you've shown on your demos by myself. And even on your demos, I don't think you ever featured a terrain with biomes distributed procedurally, which naturally would make all even better looking - and particularly since we know the functionality is there I think it would be great if we could get some help as to how to set them up.

Anyway, I really hope you will be able to help me clear some of the issues I'm having right now so that I can keep on moving forward with my project. I will soon report a few bugs I've found through Unity directly (I see you have a "report bug" menu - I'll use that) and I hope to be hearing from you soon - I am very excited as to what the future holds for this project of yours and wish you the best of luck on improving it.




EDIT: After swaping the RTP shaders on the UTerrain for my own shaders and building, the result is the same: Build does not contain terrain (or at least it does not generate or render). Any clarifications ASAP as to why this is happening and how to actually build with the procedural terrain would be very appreciated. Thank you.

 

hi,

Can i check if this works with CTS [https://assetstore.unity.com/packages/tools/terrain/cts-complete-terrain-shader-91938]? Also can I use other assets to place buildings and stuff on top? Say maybe Easy Build [https://assetstore.unity.com/packages/templates/systems/easy-build-system-45394]?

Seperately how would you compare uTerrains vs Voxeland?

Thank you!

 

@EnriquePage91 thanks for all this feedback, really appreciated!
I'm not home and I'm on my phone right now so I will take time to fully answer to you later. You can indeed create a terrain programmatically, I will explain it and add it to the documentation. Thanks for pointing it out.

@Mohamed-Anis
CTS is not compatible yet. But I'm discussing with its author to see what we can do. I'll check Easy Build and we'll let you know.
I tried the demo of Voxeland. It's a nice asset. I'd say that Voxeland is easier to use, but less deeply customizable and less powerful in terms of draw distance and real-time editing. However it comes with a better shader. That's just my opinion and I don't know Voxeland very well so maybe I'm wrong on some point.

@all
I'm working hard on the next update. It will add more operations and generators, but also strong improvements again.
In the end, it will be a major update (v4.0) because there will be some breaking changes. Almost all floats have been replaced with doubles so you will have to update your operations and generators if you implemented some by yourself. Dual contouring will also preserve sharp edges better. Terrain size will be up to 130km (instead of 8 today) which will be useful to render planets.
More to come... Please be patient and you won't be disappointed (hopefully!).

 

You can change every terrain parameters at runtime indeed, but as you said, terrain will have to be re-generated from scratch and you will need a loading screen.
The classes you have to look for are:

• GeneratorModulesComponent: this is a monobehavior attached to the same gameobject as UltimateTerrain. You can get it with GetComponent() for example. It provides methods to set the Biome Selector, the 2D value generators, the 2D Master and the list of biomes. All of them are scriptable objects.
  
  
• Biome: this is a ScriptableObject that can be created programmatically, and holds the 3D Master, 3D value generators and the Final Combiner. All of them are scriptable objects too. You can add/set new types for each of them, or get them and change their parameters (you will have to cast them to be able to do that).
  
  
• Grass parameters are accessible through the GrassParam field of VoxelType, which are contained in VoxelTypeSet (see SerializableVoxelTypes property), which itself is retrievable through the "VoxelTypeSet" property of UltimateTerrain. I know this might look over-complicated, but this structure is actually very logical.
  
  
• DetailsParam (array) and TreesParams (array) and all other terrain parameters can be found in Param class, which must be retrieved through "Params" property of UltimateTerrain.

For these changes to take effect, you must restart the terrain. You can do it by reloading the scene, or programmatically:

Code (CSharp):

1. if (terrain.IsStarted) {
2.     terrain.Pause();
3. }
4. terrain.Reset();
5. terrain.Start();

I realize the Start method of UltimateTerrain is actually private. I'm going to change it right away and make it public for the next update. In the mean time, you can safely make it public by yourself by editing UltimateTerrain.cs.

Thank you very much! Making it easier to use and improving documentation are really going to be the priority

 

@EnriquePage91
I'm sorry you get so much troubles with RTP3 integration. Honestly it should really be simple. Are you sure you are using ReliefTerrainVertexBlendTriplanar material? UV Blend should not need to be disabled. And did you change the vertex color of your voxel types (to red for example)? I will try the process again on my side, maybe I forgot something essential in my documentation.

I agree, the learning curve should be improved. I want to add more complex examples in the next update, as well as generators/combiner that are more user-friendly, like "Canyon generator" or "island", or "mountains", etc.
This will be the starting point for a better documentation.

This is an excellent idea! Thanks for this! Maybe it won't be ready for the next update but in all cases I will definitely add this feature.

And again, you're right. I know I have to make some video tutorials. I'm running out of time, but I have to do it. I think I will do this just after the next update.

Thanks I will do my best to improve all of it quickly, but I'm doing it on my free time so I can't give you any ETA. Anyway, I'll keep working

What do you mean by "Build does not contain terrain"? Do you get an empty scene? Or a black terrain? Do you have any error in the logs?

 

I am considering buying this asset, but I am not sure whether it allows me to put some parameters on newly created terrain. I would like to for example, put some snow on terrain, and then remove it after a period of time when it's sunny or some other set conditions (like it is very hot).

Would that be possible?

 

The snow is a shader feature. You can add snow to terrains made with Ultimate Terrains, but you will have to use a shader (a material) that is able to render snow. RTP3 does this for example.

To be clear : yes, you can, but you will need to get/buy some terrain shader that does it for you. The shader included with uTerrains can't render snow the way you want.

 

Thanks, another question, does each voxel of terrain have a set of parameters?

If I were to submit a raycast and it hit the terrain, I would be able to know whether it's snow, rock, grass etc?

 

You can create as many voxel types as you want and retrieve them with a voxel raycast (provided by uTerrains).
However, about the snow, keep in mind that the shader is responsible for rendering it and it is not correlated with the voxel type. I mean that if you create a voxel type "snow" and a voxel type "grass" for example, and place them on the terrain, then it won't change over time. The fact that there is snow or not is purely visual and won't be reflected by the voxel information.

 

Hello everybody,

Some fresh news of future update v4.0!

I'm currently working on improving/adding new operations. This is the main topic of the next update which will be a massive change.

I added a feature that allows to automatically merge operations when possible (for example, a big dig-sphere that completely overrides some other smaller operations will actually "eat" them). This will save performance.

The new operations I have already implemented are:

• Parallelepiped (any direction)
• AxisAlignedParallelepiped (replacing "DigCube" and "AddCube")
• Sphere (replacing "DigSphere" and "AddSphere")
• Cylinder (any direction)
• Capsule (any direction)
• AdditiveSphere (kind of continuous addition of voxel values within the range. Can be negative.)

Also, Ultimate Terrains now preserves sharp edges a lot better, meaning that when digging/adding cubes, the corners will be really perpendicular. Maybe it will be even possible to create perfect walls with it.

Finally, I replaced almost all floats by doubles (and Vector3 by Vector3d). This basically improve performance (yes I know, it's counter-intuitive), precision, and will allow to handle better infinite worlds with floating origin (floating-origin isn't ready yet and won't be in the next update).
So, if you created your own generators and/or operations, you will have to update them (basically, replace floats by doubles).

Of course, all of this takes time, so please be patient.

 

This sounds great

By any chance could we have some kind of smoothing / sharpening operations too

Blocking out a level with primitives then being able to smooth down paths and sharpen up cliff faces would be lovely

 

Also what does Parallelepiped mean?

 

I'm working on a smooth operation. Will add sharpening too

https://en.m.wikipedia.org/wiki/Parallelepiped

 

Please! This would make happy many people!

 

Is there a way to paint on terrains rgb values for the shaders to show different textures without adding or subtracting, just painting it on?

 

The right way to do this is actually to change the type of voxels you want to affect.
The next update will come with a Paint operation that does just that.
In the mean time, you could do it yourself easily. For example, copy paste the DigSphere operation (the script) and remove the lines where it changes the voxel value. Just let the line where it changes the voxel type. And you're done

 

Coming in the next update :

• More accurate dual contouring
  
• New operations
  
• Improved generators
  
• Lower memory use
• Better overall performance (generation time may be up to 2x faster!)
  
• New "hot reload" feature in the editor to quickly see how biomes configuration changes affect the terrain
  
• Bug fixes

Development still in progress

 

New update looks great! I saw you were pIanning a new update so i found myself itching to drop my input for it or possibly next(future) update;
I myself (and apparently others) have had difficulty using the Biome generator in its current state for anything commercial which is troubling because i understand that the biome system itself is the heart of this generator, That being said it's not very "user friendly" so im glad we're getting small changes in the biome area- although i have tried all of the Terrain systems on the asset store over the years and yours is definitely most potent for power but lacks the user friendly usability especially for frequent changes to the terrain which most major terrains need, (a lot of tweaks)
and puts it more in the "good for hobbyists" league while holding back its potential for being the #1 on the asset store, (seriously hope this is not too much of a bash im really just being honest and i hope the author accepts constructive criticism because i truly do love this asset).
Perhaps its just the editor itself or the "node" system or the fact you can really only have biomes "stacked" out of the box, (unless, you are a programmer which i as an environmental artist am not, as well as many others looking for a third party asset instead of programming it themselves are probably leaning towards customizing pre-built systems to their needs)
That being said again i love the asset ive owned it since it's initial release, but going forward i really do hope you consider implementing a biome creation overhaul it would really fix and polish this beauty from a hobbyist to a commercial product in my humble opinion.

Heres an example of what i mean by "biome customization" that's much more user friendly, and still holding power, i mean really it's just an extension of whats already there so i can't see this being a massive change but it would be massively improving what you've already got and opening up potential for future clients as well as existing ones.

obviously not asking for a fast response or any guarantees but would love to hear your opinion on this and what we could expect in the future for uTerrains and it's biome creation, cheers!

-David

 

@DJ_Design
I totally agree with you, and your are not the only one to give this feedback. Basically, uTerrains has a lot of power and potential, but isn't user-friendly enough to be a top product.
This is true for both Biomes editor and Editor Tool.

I'm going to work on this as I understand it's the key to make uTerrains a better product.

However I don't promise all of it will be there for the next update (4.0). I prefer to improve it iteratively.

In the first time, I'm going to improve 2D/3D generators and Combiners so they will be more user-friendly and more "high-level", but I won't change the biome workflow editor.
In a second time, I'm thinking of providing high-level biomes that override the default biome editor window to offer high-level configuration. For example, imagine a "Mountains" biome where you could just change the heigh, width, sharpness and local perturbation of mountains, without seeing the underlying generators nor combiner.
From there, you could still open the classical biome editor window by clicking "Advanced settings" and you could still deeply customize the biome, but once this is done, you wouldn't be able to go back to the easy interface.

With the same spirit, I'll offer higher-level biome selectors to simply place biomes with perlin and/or altitude.

Anyone will still be able to implement their own generators, combiners and selectors (I think this is very important for programmers), but at least non-programmers will have access to high-level configuration.

About the Editor Tool, I would like to make something more similar to the standard terrain editor tool.

 

Hi there, I'm interested in this asset that seems the best voxel terrain for Unity at the moment, but I have a doubt: i tested the playable demo, and I see that there is stuttering every now and then.
It seems to me that this is due to LOD generation: when I saw LODs changing in the distance, the framerate took a hit. I'm not on a snail machine either, being on a i5 CPU.

Now, while this is ok for a FPS and many other games, it's absolutely unacceptable for a racing game, which is what I am working on.
Not criticizing your work here, just asking if there's a way to overcome this problem.

However, as I don't need real time generated infinite terrains, I would pre-bake the meshes, but I would need them working with LODs of course, for the whole tracks, and this should cut away the realtime terrain and LOD generation problem.
But how much memory would it take a terrain of about 16384 units sides x 2048 units of height with a resolution of 2 units in memory? Is it feasible this way?

 

Yes indeed, speaking with my programmer hat on.

I'm still in the middle of code review so I can get my brain wrapped around what uTerrains is doing, but I'm getting closer to integrating it back into my existing projects. Of course I'm likely an edge case since I'm replicating real world locations with a lot of variation in their sub-surface aspects. Soil/rock layers are the reason why I needed voxel terrain over "simple" Unity terrain. Getting all that information to combine together correctly in Cubiquity took me a while the first time.

 

I don't like to make promises to avoid disappointing people, but the next update fixes a big bug that led to "pool leak" and consequently a lot too much allocation and garbage collection, which is generally what causes stuttering.
Also, it puts a lot less pressure on GC collections as Voxel is now a struct without any reference field, meaning the GC won't have to scan them anymore.
Maybe this will completely fix the stuttering issue you encountered. I will let you judge by yourself when the demo will be updated.

However, generally speaking, I'm not sure a voxel terrain is very well suited for a racing game because as you said, it needs to be very reactive even at very high speed. If you really need it, you'll probably have to choose a lower resolution (like voxel width = 2m or 4m instead of 1).

Ultimate Terrains used to have a bake system. I figured out it was actually faster to generate the terrain than loading baked data! And as you said, you need LOD, so it cannot be static.
So... don't expect big perf improvements by doing this.

Ultimate Terrains doesn't handle it this way. The size of your terrain won't have a major impact on the memory it needs, simply because uTerrains keeps almost nothing in cache (at least in the coming v4). Expect your terrain to take about 1GB in memory (less in v4).
To answer your question, if uTerrains kept all voxels in memory, it would take 16384/2 * 16384/2 * 2048/2 * 32 (approx byte count taken by one voxel) = 2200GB. I think nobody has 2TB of RAM on their desktop at home

 

Well I know that all that data is stripped by using octree (if I'm not mistaken), but still, if you increase the complexity of the scene, memory use increases as well and an estimate is always possible.

However, it would be nice if you kept an eye on my needs while you work on v.4. Maybe someone else would use the solution for other products that need stutter free framerate.
If you manage to find a solution for the stuttering, working at 2 meters resolution, I would surely buy the asset. 8 Km visibility are sure enough.
But at 4 meters resolution... that's a bit too much to cover with vegetation to hide the edges... it would need so much tall vegetation that it would slow down everything by overdraw and also introduce game design problems.

I know that voxel terrains have never been used for racing games, but this is a particular racing game, and this type of terrain would be great for what I want to do.
In reality, I've always considered elevation based terriains extremely limited, and couldn't wait for a real, affordable, usable solution of voxel terrains.
Unluckily, the game I'm working on needs a bit of performance more than what we still have at the moment... but maybe you will manage to clean it up more and push it in.

Mmmmhhh I also wonder how can it be faster in generating meshes at runtime than using ready ones and only deciding which LODs to use based on distance... could you give me two words on this?
Also because, I'll need to work manually on the world, to build the track, I can't leave the generated world exactly as it is, so the voxel engine should not only calculate noise etc. in voxel generation, but also booleans etc... Can't understand how real time generation is faster than ready stuff. Always thought ready stuff is a problem because of memory consumption.

 

Hopefully, the v4 will really solve this issue. I haven't stressed it enough to give you a definitive answer but I will let you know. I'm quite confident.

Baked data was actually slower to load from disk and deserialize (a lot slower). I was using protobuf. I could have done better of course, but I decided to don't spend more time on it as I wasn't seeing a big potential. There were too many meshes versions to hold in memory anyway (there are a lot of combinations with different LODs and LODs transitions).
Apart from that, I agree that if you don't consider the initial loading time and the memory usage, the terrain updates would be faster.