[OLD-FORUM-THREAD] Ultimate Terrains 1.0

There is the getting-started tutorial here: http://uterrains.com/videos/
Documentation here: http://uterrains.com/doc/
And there is all the contextual help when mouse is over the different parameters in the inspector, plus the 3 example scenes with a working terrain entirely setup.
If you need more specific help, don't hesitate to ask your questions here: http://uterrains.com/questions-answers/

 

Hey Amandine,

I would like the player to be able to tweak uTerrains generator parameters when they play the game. Do you have any suggestion on how to go about doing this? Right now the terrain generates automatically when the scene loads. Is there a way to delay this, and/or pass parameters into the biome generators and combiners?

- Conan

 

I am planning on doing the same or similar and was thinking about posting a similar question. If nothing else I would imagine exposing settings that would allow for changing the seed(s) so if they want to keep a seed(s) they like to replay a given terrain that would be a good start. The other things are size limits, so that if they pick say a small, medium or large world I can tweak the x,y,z limits to fit their selections.

 

does your voxel engine allow psysics like if you take the bottom of something it crumbles

 

@AmandineEntertainment

I was wondering if you could explain this a bit for me. I poked around a bit, and couldn't find any references to Vectori3i or Vector3iComparer. It looks like these are classes you've created. I'm guessing you override Vector3 to make it serializable, but I'm not that familiar with c# yet.

I am working on persisting my world, and synchronizing across a network. In order to do this I need to serialize uTerrain operations as well as all my game specific objects.

I'm assuming terrain.OperationsManager.SerializeOperations/DeSerializeOperations will work for uTerrains, but I still need to keep track of a 3D world for everything else.

With your suggestion I would like to create a

Code (CSharp):

1. Dictionary<Vector3i, VoxelExtraInfo> worldStuff = Dictionary<Vector3i, VoxelExtraInfo>(new Vector3iComparer())

where each VoxelExtraInfo will only contain serializable data. I'm not entirely sure what passing a Vector3iComparer in is doing though. I'm also unsure if this would be serailizable or why it would be faster.

Thanks,
Conan

 

@Conan Morris @boysenberry
You can delay the terrain generation by disabling the Ultimate Terrain component in the inspector and then enable it later. However this won't let you change terrain parameters because they are loaded in the Awake method which is called regardless the script is enabled or not.

A good workaround would be to disable Ultimate Terrain component, let the terrain initializes itself in the Awake method, then reset it and finally call Awake and Start methods manually when you want it to start:

Code (CSharp):

1. // disable Ultimate Terrains component in the inspector, then when you want to start generation, do that:
2. uTerrains.Reset();
3. // => change params values as you want here
4. uTerrains.Awake();
5. uTerrains.Start();
6. uTerrains.enabled = true;

If you want to stop the terrain again and clear it:

Code (CSharp):

1. uTerrain.enabled = false;
2. uTerrain.Reset();

And start it again:

Code (CSharp):

1. // => change params values as you want here
2. uTerrain.Awake();
3. uTerrain.Start();
4. uTerrain.enabled = true;

This is basically what is done by the UltimateTerrainEditor.
To change params values, just use uTerrain.Params to access them and modify them.
About generators, you can access them through GeneratorModulesComponent (which is just below the UltimateTerrain component in the inspector, on uTerrain object) by using Biomes / BiomeSelectorSerialized / M2DValuesGeneratorSerialized properties, and in each biome, M3DValuesGeneratorSerialized / MFinalCombinerSerialized.
I think that's it. You should have everything you need

No, at least for now.


@Conan Morris
About Vector3iComparer and Vector3i.
Yes I created them for uTerrains. To be serializable, a class just has to be marked with [Serializable] attribute, and then all its public serializable fields will be serialized.
Just so you now, Vector3i looks like this:

Code (CSharp):

1. [Serializable]
2. public struct Vector3i
3. {
4.     public int x;
5.     public int y;
6.     public int z;
7. }

As you can see, this is a 'struct'. In other words, this is what we call a "value-type" in C#. Some famous value-types you know are for example "int", "float", "Vector3", "Color", etc.
Problem with value-types is that when they're used as keys in a dictionary they have to be boxed to be turned into objects. Boxing/unboxing is bad because it's a performance killer.
The way to prevent it is to provide your own comparer so C# won't need to box your keys anymore.
This is better explained here: http://stackoverflow.com/questions/26280788/dictionary-enum-key-performance

For example, uTerrains' Vector3iComparer looks like that:

Code (CSharp):

1.     public sealed class Vector3iComparer : IEqualityComparer<Vector3i>
2.     {
3.         public int GetHashCode (Vector3i v)
4.         {
5.             return v.x ^ v.y << 2 ^ v.z >> 2;
6.         }
7.        
8.         public bool Equals (Vector3i v1, Vector3i v2)
9.         {
10.             return     v1.x == v2.x &&
11.                 v1.y == v2.y &&
12.                 v1.z == v2.z;
13.         }
14.     }

This basically tells C# to use it to compare keys instead of boxing them. You'll find a lot about this on the internet
Don't forget to override GetHashCode and Equals methods in your struct too.

 

To everyone,

You may have encountered some critical bug when performing operations (like digging a tunnel) and then moving: some big holes appear in the terrain. This is a bug introduced by v1.0f3. It has already been fixed in the upcoming v1.0f4, so don't worry
As this is a critical bug, the update is going to be published very soon.
BTW, the v1.0f4 will also fix an issue with the PlayerTransform that isn't updated if it's changed during game. Perfs are a bit improved too.

 

Hey @AmandineEntertainment Is this possible with uTerrain?

 

@blueivy
Yes it is! Get a look at my answer above

 

I bought Ultimate Terrains and started testing it. It looks very promising and has noticeably better performance than other procedural terrain generators I've tried, but there's an occasional hitch that lasts ~300-500ms. The hitch happens on average every 90 seconds or so. I'm on a high-end PC and I don't think it's a cpu/memory/etc issue on my end. Is this hitch known?

 

Thanks for buying uTerrains!
No this is unknown.. and weird.
Could you profile it to see what's causing the hitch? Is it the garbage collector? Or maybe some physic stuff? Or some script?
Does it happen with the example scenes?
Does it happen when you build your project (standalone executable) and play with it?

 

@AmandineEntertainment

I"m trying to serialize my uTerrains operations for network synchronization and persisting changes, but I can't seem to figure out how to do it.

I see there is a UltimateTerrainst.OperationsManager.Serialize/DeserializeOperation().

The Serialize takes an OperationsHandler, but I can't find any way to associate an Operation with a OperationsHandler.

The Deserialize takes a json string, but it returns void.

Could you provide an example on how to use these? I want to serialize operations before I perform them so I can send out an RPC call telling every client including myself to perform the operation.

 

@Conan Morris
I realize the Operations API isn't good enough currently.
Just so you know, Deserialize is void because it deserialize and add the operation immediately to the pending queue. However these methods should actually stay internal and I should add two public methods to Serialize an IOperation and deserialize a string that returns an IOperation. I will definitely add it to the next update.
Thanks again for your excellent feedback!

 

@AmandineEntertainment

Thanks for that.

Also, less critical at the moment, but is there a way to perform operations on grass/details. I would like to be able to chop down / plant trees etc?

 

Hey, first i'd like to say how impressive this looks and actually answers a lot of issues i have with environment creation so im very interested in a possible purchase, but i do have a few questions first. Obviously using voxels is very versatile and on top of that you have very impressive draw distances which makes this so attractive as, i'm thinking, a complete replacement for my use of unity terrains. Ive built up a collection of assets over some time that integrate with unity terrain in one way or other and some of them have really become mainstays, or will do eventually, and i guess i'd like to know how well i can adapt these for use with this asset. In particular id refer to assets that deform or arrange the terrain - in one case there is World Composer, as while i think Terrain Composer might be far too specialised to unity terrain (i may be wrong and i will ask the creator abut this), is the functionality of Wold Composer transferrable to this - that being deforming the surface to downloaded elevation data and applying satelite imagery appropriately - im aware this works with RTP (Which im very enthusiastic about) but would consideration need to be taken for the alignment of the colormap and suchlike?

Assets like mapity allow openstreetmap data to be downloaded and aligned with terrain, would this be an issue? And i suppose something fairly important to some plans regard assets that deform terrain to match a path - in particular, EasyRoads3D and MegaSplines, two great assets where being able to match terrain height can be fairly important - would this create difficulties or could equivalent functionality be appropriated? Thankyou for your time and again grats on a great looking tool

 

Just played the demo and loved everything about uterrains keep up the good work!

 

Just as an FYI I've begun a conversation with the publisher of EasyRoads3D to try and get it working with uTerrains. It's a really versatile road generation system that currently works with Unity Terrain. He thinks it would be possible to use it with uTerrains by using the height info available from uTerrains and is willing to help a bit with getting the Unity Terrain dependency removed. I will update more as I start work on it.
I plan on using it to generate trails and rivers if I can get the two working together properly.

 

Not for now. I will think of a way to have better interaction with details objects. I have to work on this anyway because there is a bug I have to fix.

@lazygunn
I understand your need to integrate your tools (and the ones you bought) with uTerrains. I've never tested World Composer, but from what you say, I think this would be possible to write a generator module to build the terrain from World Composer data. I can't be 100% sure as I don't have it but I don't see why it wouldn't be possible. I think I'll buy it one day just to give it a try.
More globally, all assets that affect terrain's relief should be usable with uTerrains by making specific generators. Do they output some heightmaps? What kind of data do they produce?

Thanks!
The demo has been updated yesterday and now uses v1.0f4 that fixes a lot of bugs. (v1.0f4 is pending for review on the asset store).

This is an excellent news! If you need help don't hesitate to ask. If you write a module or something to make it compatible with uTerrains I'd be glad to include it in uTerrains package if you agree. Or maybe the author of EasyRoads3D will want to include it in his package?
Anyway, let me know if you manage to do something and don't forget I can help

 

I'm glad to tell that v1.0f4 has been submitted yesterday and is currently pending for review.

Release note:
- Fix critical bug when performing operations and then moving: some big holes could appear on the terrain. This bug was introduced in v1.0f3.
- PlayerTransform can now be changed at runtime.
- Improved API to serialize/deserialize operations.
- All terrain initialization is now done in Start method instead of Awake so you can programmatically change some param values in your own Awake methods.
- Fix issue when destroying mesh in edit mode.
- Fix issue on terrain destroy to properly stop all threads and clear all memory. You can now switch scenes without any issue (see the new online demo on www.uterrains.com).

This is already the third update since the first release of Ultimate Terrains 6 weeks ago. More and more people are using it and from what I read in the feedbacks most of you like it There's still a lot to do, and I'm more motivated than ever
Thanks to all of you!

 

Sounds like some really useful upgrades (and fixes). It's really motivational to see how active you are with your asset as well.
It made the difference for me. Even after I purchased uTerrains I was still contemplating using Terrain Composer for generation. I figured it was already being used in production situations so I'd have a better chance getting to market using it. Seeing how much you've done to improve your product and how well you've listened to your audience made me change my mind though.
I am confident I will be able to use your product to bring my game to completion as well as provide a better product/experience for my audience.
So once again, thank you, and keep up the excellent work!

 

I agree with everything you said. Excellent support! @AmandineEntertainment

 

I would like to use this asset to make a whole Voxel Planet.
The planet can be rendered differently (simple textures) from orbit so I don't actually need a spherical map.
What I need is to be able to set a finite map (not infinite) that would eventually render the first chunk again so players can walk around the planet.
For instance, we can have a total of 100 chunks around the planet. You start at chunk 0, you go forward and when you get to chunk 99, the next one would be 0 again.
If you start at chunk 0 and go backwards, you actually get to chunk 99.
Same thing must be valid for both axis.

Also, what do you use as the offset to define which chunk is generated ?
Is it the main Camera's position in world coordinates or can you set it manually somewhere independently of the position of the camera ?
If you use the world position of the camera, then there would be a floating point precision problem when going very far and everything would vibrate...
I actually have a script to always reset the player to the origin and move everything back so I can seamlessly travel huge distances without any precision problem whatsoever.

Will it work with your asset ?
Thank you.

 

We are currently looking at this asset for our game and have a couple of quick questions of what is possible.

We are building a world that is scaled to real world data using WorldComposer (I read the answer above about possible compatibility) and we also use TerrainComposer to modify the splat maps and terrain textures when we use RTP to assign the terrain textures. We were wondering if using WC heightmap data with some TC textures/outputs (not using the terrain tiles themselves, just the textures that can be exported from TC) would allow us to define the voxel textures and biomes for tree/grass placement.

We also are using BuildR to make some of the buildings on the levels and would love to see an EasyRoads3D integration as that would let us build entire towns procedurally and then serialize them for save/load. We want our world to evolve over time through some code based tools and not have to involve a lot of artists in the process except to create the assets and let the code place things, so voxel terrain would be a fantastic addition.

 

@boysenberry @blueivy
Thank you very much for the kind words!

@kzaurckichz
For now I'm using world position of the player. Floating precision issue might not occur with terrain because chunks have positions dividable by 16 (if you let 1 unit per voxel) so you can go far far away before encountering problem. But I understand in some cases you need to replace the origin of the world.
This is something I may add in a near future even if it's not a top priority for now. Unfortunately, I'm not sure your script can work with the current implementation.

@CaptainMurphy
I haven't tested all of these assets, so I can't promise it works, but theoretically, you can use any kind of input data as long as you can implement your own biome-selector, voxel-combiners, and generator modules.
To my mind, nothing prevents you from writing a voxel-combiner that would choose the voxel-type from a splat map.
Just keep in mind that RTP compatibility has been tested with the vertex control triplanar mapping shader.

 

My one concern with RTP is blending between multiple terrains. Do the voxels allow for having two different terrains blend over each other so if we do something like a beach that ends near a rocky section that we can have the sand in between the stones as they overlap each other (one of the biggest advantages of RTP).

If we export heightmap data from something in a single channel that would allow to have the voxel terrain match it, correct? I am imagining that your generation object is using a texture being generated/calculated at some point or at least using the x/z coord of something like a simplex/perlin to make the chunks so we could feed in that heightmap data to replace it. Could it be done so that we have the ability to change the scale at which the generator 'sees' the heightmap data? That would let us change the scale of the world rather easily and just inject some simplex or perlin to fill in the blank spots based on the biome.Then we would be able to have players able to determine how big/small they want their world to be which can completely change the dynamic of the game.

For biomes I am envisioning multiple RGB images that align with the heightmap outputs so we would be able to generate the biome based on x/z info of channels. With the overlap of a biome would they both apply and could we vary the application of the biome info based on the strength of the channel data (stronger color = more density).

I know we could write these items ourselves once purchased, but these types of features would really set apart this product from others that we are evaluating.

 

being able to mark the height much like you can unity terrain, and have few ft surface before any noise algorithm kicked in would brilliant basicaly - sculpting via wc or easyroads (or both) as a surface layer, out of the box would be marvelous

 

One of our artists and I were going over this and our thought was to allow a texture map to control the noise being applied that aligned with the terrain heightmap. That way we could define the zones that needed noise added and those that it should leave alone, sort of like the biome but disconnected from that system.

 

I was looking through some of the Q&A's on the site and came across this one:
http://uterrains.com/question/about-ultimate-terrains-generation/

So I have thought of a reason that we might want to load more than one terrain in the scene and that is simple if you want to use multiple cameras to see further than 8km. To give an example, our game will have 20km view distance and we are using two cameras. One is the player short range that has about ~4k view and everything is high detail, the second is still only ~4k but shows a smaller scale version of things. The cameras are overlaid to give us 20k+ draw distance so we can see islands in the distance as they rise out of the horizon and eventually switch over to the detail version when they get closer.

 

I've been keeping an eye on smooth voxel solutions for Unity for a while and this is the first that seem really promising. (I'm speaking as a regular Unity user here, not in my capacity as a Unity employee.) While some other packages have claimed to have proper LOD support I haven't seen it convincingly working, and this is also the first that clearly demonstrates the sharp features of dual contour voxels. Nice!

I have a few questions:

• Could you go a bit more in detail with how edges between different LODs are handled? From this image from the first post, it looks like only the middle part of chunks can have lower triangle density far away from the camera, while it looks like the density increases to full density near the edges of chunks? So if two adjacent chunks are both of low LOD, do they still have a high-detail edge between them, or can the edge be as low detail as the chunks themselves? Ideally I would hope the latter of course, like explained on this page for example. As I understand it, one of the advantages of the dual contour technique is exactly more straightforward handling of edges between different LODs.
• Do you have a strategy for handling floating point precision errors far away from the world origin? What I would need for an nearly-infinite style game is that meshes have their local origin close to the mesh vertices and use the transform position to position themselves at the proper place in the world. This way I'd be able to periodically move the entire terrain close to the world origin. I don't mind doing this work myself; it just requires that the generated meshes by the system don't all have their local origins at the world origin, because then I wouldn't be able to work around it.
• Can I control from code when chunks are created for the first time and recreated at higher or lower level of detail? My game has procedural level design and I'd generate voxel data based on that. Chunks of terrain can't be generated before the underlying calculations are ready.

I fully understand if some of these requirement are a bit more control-heavy than the framework is designed for. I just have to ask, since if it does allow this level of fine control, then it could very likely be a great fit for what I want to do.

 

Hi,

Thanks for great answers to my previous questions. I've got a few more, if you don't mind, because this looks so good

• Multiple materials with biomes sounds like an extremely nice feature. Is there a limit to how many materials or biomes I can have?
  
• Would it be possible to base the terrain shape on a pre-generated heightmap? Or maybe even combine it with some runtime generated noise for details? My guess is that this could be done through a custom-made generator script, but please correct me if I'm wrong.
• I'm interested in very large viewing distances. Is it possible to scale the entire terrain in Unity so that it stretches for, say, 20k units in both direction, and then adjust the LOD settings so that you still get decent resolution up close but much lower resolution far away for a decent framerate?
  
• I'm guessing there are no traditional splashmaps, so I can't paint roads as textures, but would have to do them as meshes, is this correct? Edit: Actually now that I think of it, maybe roads and rivers could be made as biomes?

 

Someone mentioned that doing authoritative multiplayer with uTerrains is not possible currently, since the system can only generate terrain for 1 player.

Will there be support for authoritative, server-side terrain generation for numerous players soon?

Thanks!

 

I was wondering if you would mind putting it in the to-do list to add some more examples of using the different generators and combiners you provide. I am pretty new to using noise patterns for terrain generation and things like Heterogeneous Multi Fractural Generation (or Multi Fractural anything for that matter), Voronoi 3D, Single Cube 3D, or even Lazy Combiner don't really make a lot of sense to me yet.
I did searches on those subjects and when I find information its usually either very specific to a given application, like brain scans, or texture analysis or something even less related to what I would like to do. So I really don't have much to go on besides trial and error, which can be very frustrating with noise when you don't have a sane example to work from.
I did try my hand at trying to use the heightmap generators as well and am only coming up with a flat surface, so I don't really understand how to use them either.
What I would like to do is to be able to build a large island ringed by mountains surrounding a rectangular valley with a small opening at one end that I can use as an entry point to the valley in the mountains.

So far, I have been failing miserably
I know if I knew how to use the generators better this would be easy (or at least easier).
I have a lot of other things I need to begin work on that I can't until I get this part right, so any help would be much appreciated.

I just found this: http://freespace.virgin.net/hugo.elias/models/m_perlin.htm
Its helping quite a bit for Perlin noise, which is a start.

 

It seems like he's away from a computer at the moment. The last time he was on the forums was the date of his last post.

 

Hello everyone and if someone can tell me how I should create a form for the ground floor and then put houses and rest because the document will be the construction of a module but then I find no explanation other to get there give me a hand with

 

Hey there,

Sorry for piling more on (since there's a lot you haven't addressed yet). I posted on your support website with Pre-Sale questions (I'm not sure if you even got that). However, I went ahead and bought it anyway because I have another use for this asset even if it doesn't work for my main project. However, I'm still very much interested in getting it working for my main project.

As I said there, my main goal is cubic terrain (the way Minecraft does it). It seems this isn't extremely well supported, as the main point of your engine is to generate smooth terrain. However, I did see the part saying that it supports Minecraft-like terrain and thought it would be great if I could use it that way.

So my thoughts/questions as of right now are:

1. I'm unsure of how to change the actual view range of the terrain through script. I tried reducing the number of chunks in the LODs, but only received warnings saying there weren't enough chunks. I would prefer to allow the player to have control over the view range displayed.

2. Is there a way to use a texture atlas for blocks? This makes sense if the terrain is cubic, but may not make sense for smooth terrain (I'm very unfamiliar with the smooth terrain approach). However, I'd like to be able to add a lot of voxel types that can have different textures on each block face, while not murdering my computer with an insane amount of draw calls.

3. Am I forced to use the LOD system? Does it even make sense for cubic terrain? Any lesser-detailed cube isn't really a cube anymore, and I want cubes. I've been able to make my terrain cubic by setting all allowed errors to 0 and setting LOD count to 2, but I would prefer not even using the system at all.

4. I notice that when the terrain loads, it can take 20-30 seconds (with 2 3D noise generators and a ridged-multi 2D generator). However, during this time the player is sitting there unable to move in the air. Wouldn't it make more sense to generate a few chunks where the player is, let the player move around and do things, and continue generating the remaining surrounding chunks in the background? That would mean far less waiting time at the start.

5. This one may be silly... I cannot figure out how to actually set a block to 'air' to remove it.

6. Any plans for non-unity lighting and physics? Currently, the only darkness you get where light is blocked is from shadows. And I'm unsure if there's a way to allow blocks to propagate light outward... also, mesh colliders are really slow! Especially when the entire LOD has them enabled... could we have more specific control over where they appear? Example: only the chunks directly surrounding the player's chunk could have them, instead of 100s of chunks.

Beyond this, your engine looks very promising and I greatly look forward to what the future updates will bring. Keep it up

 

Wow! I see a lot of questions have been posted during weekend
That's very encouraging to see more and more people being interested.

You should not have more than one terrain at a time with uTerrains. This wouldn't make sense because terrains are infinite and can be completely different from one region to another thanks to biome system.
That said, I'm not a RTP expert, I think you'd better ask to Tom if the triplanar shader (vertex-control) supports this.

There is already an heightmap generator module that takes an heightmap as input. I think this will be easy for you to start with this one and maybe improve it to suit your needs exactly.
Adding more modules and improving the existing ones is on the road map

As I've just said, you can use the heightmap module as a good start point to make a biome selector that would act like you want.

I agree! It's on the road map (not sure exactly when I will do that, but I will for sure).

Seems pretty smart, but I wonder if this is suited for uTerrains. Having more than one terrain will have a performance cost I think. Sounds quite risky to me.

Thanks!

You're right, only the middle part of chunks can have lower triangle density when we use properly connected seams. Higher LODs don't have to compute high-detail edges. They only need to compute the edge with their level of detail. The attached PNG schema will be more clear. Chunk borders are in blue, vertices on edges are in red (this is just a general schema, in reality there are twice more vertices).
As you can see, chunks with higher LOD adapt themselves to suit the edge of the lower LOD. In other words, a single chunk can have edges of different LODs.

Meshes do have their local origin close to the mesh vertices. Chunks positions however are world-positions. This doesn't prevent you from doing what you want, but the best would be to be able to tell uTerrains to change its internal origin. This is something I'm already aware of. I will add this in a near future.

You can control when chunks are created for the first time by disabling uTerrains and then enabling it when you want, but you can't control when chunks will be recreated later. It's entirely determined by the player position. But I realize this would be quite easy to add 'Pause' and 'Resume' methods that would allow you to tells uTerrains to wait before recomputing chunks. This will be done in the next update

No, no limit. (for materials, there is the Unity's limit of course, which I think is 65536).

This is entirely possible and there is even an heightmap module already

Currently the limit is set to 8192 as I thought nobody would need more, but that is something I could increase if you need.

You could generate rivers and roads from modules I guess, even if it may be quite difficult. Some people are working on making a module to be able to generate roads on terrain from EasyRoad3D data. I think this might be interesting for you.

Actually, I don't see why it is not possible. The terrain will always generate on client side, but the server can control every generation parameters and decide which operations are performed. Isn't it enough for an authoritative server?

@boysenberry
Yes this is something I have to do (I realize I have tons of things to do! )
I recommend to get a look at the libnoise website if you want to understand noises better.

That's right, I was away

You could do that thanks to the flatten operation, or you could create a biome that generates flat areas. I will add more example in the docs but please allow me some times because I have so many things to do

 

Thanks for answering! I think it's good that you don't work over weekends.

If it's not too much work, I'd love if you could increase the maximum viewing distance That's my main concern at the moment. Best would be if we could set it per project. Not sure what the theoretical limit is, but if possible I'd be happy to be able to set it to extreme numbers, just to experiment. I don't mind if the resolution gets much worse, because in my project I likely want to sacrifice resolution for greater viewing distance, even if it leads to holes or similar.

I'm mainly after just scaling the terrain, so I believe that means scaling the chunk size rather than adding more chunks, but ideally we could control the number of chunks as well (although I would guess that raising the number of chunks might affect performance drastically).

 

I feel your pain, noise is very hard to work with, and very much a trial-and-error experience. From I can see, you need much more control than pure noise, so I think your best bet is to generate a heightmap using a variety of techniques. Maybe identify the mountain ring by checking the distance from the the center of the map, so that it shapes like a circle, then let pure noise decide the mountains themselves. Checking the distance from the center would also help you to fade out the edges to make it an island. Then create the opening using some form of pathfinding. And finally let the heightmap control the terrain shape using the heightmap generator. I'm planning to use a similar approach myself to get more control, although I'm not that far down the road yet. I'm also pretty sure biomes in uTerrains could help out a lot, so you might want to consider generating a biome map also.

 

I would like to add to my previous response: would a tri-planar shader be too expensive for cubic terrain and should I be using something else, or is there a special reason I should use tri-planar? I suppose this also goes with my question about textures and atlases.

Thanks in advance.

 

Hi would having multiple players be a problem with uterrain? I have a coop game where I need the ability to switch to the pov of different players.

 

You can adjust the view range by changing the LevelCount (in Params). This is the number of LODs that must be computed by uTerrains.

I think you can achieve what you want thanks to Voxel-type functions. This allow you to set the color of a vertex depending on its normal. Then the shader will render different textures depending on the vertex color. Typically you can have a different texture on the sides of a block than on the top of it.
But I don't think you'll be able to use atlas for blocks. If you need more than 5 different textures, I'm afraid you'll have to use different materials... unless you write your own shader that exactly fits your needs?

Currently you cannot disable it completely. I'll add it to the road map though.

This isn't possible in uTerrains because chunks are computed completely independently in different threads in a "random" order. I can't be sure chunks next to the player will be the first ones to be computed. This allows me to have drastically improved perfs but the initial loading time can seem bigger, I agree.

You mean how to "delete" a block? Get a look at the dig operations. Basically, setting the voxel value to a positive number will mean that it's outside (ie. 'air').

I choose to use default Unity lighting system and physics to integrate better with Unity. I think it's better to use standard stuff.
You can already choose what LODs will have a collider from the inspector (Max LOD with colliders). I hope this is good enough for you.

Thank you very much! As you can see, there's still a lot to do, but don't worry I'm working hard

Yes someone else asked for that too, so I guess I'll increase the maximum number of LODs.
But if you don't mind about sacrificing resolution, you should better increase the voxel size instead. If you set it to "2" instead of one, you'll get a terrain two times bigger without any performance cost. (look for "Size of a voxel in Unity's world" in the inspector).

I think it doesn't make a lot of sense to use a triplanar shader with cubes, but this means you would probably need to have control over UV coordinates which is currently not the case. I'll see if I can add some control over it in the voxel-type functions.

Currently this isn't supported, and this would be something hard to support. To be honest, I won't have time to look into this in the next few months :/ I can't promise you anything about this.

 

Just what I was looking for. Thanks!

 

Now that I have answered to everyone (unless I forgot someone), a little word to all of you:

First of all I wanted to say thank you to everyone for being interested in Ultimate Terrains!

I also wanted to tell you I'll do my best to implement feature request as quickly as possible, but I have to ask all of you to be comprehensive and patient. Sometimes in my answers I say that something is missing and will be added in a future update. Don't worry, when I say that, it means I've already added it to the TODO list, so I won't forget it. But this can take time. I know this is frustrating for you, so again, I'll do my best

It is very encouraging to see that more and more people are happy with uTerrains. I'm also very glad and grateful to see Ultimate Terrains is rated with 5 stars on the Asset Store. This is extremely important for me, and this is why I'm so motivated.

 

I think I've figured out most of the initial generation issues I am up against in so far as my last post goes anyway. I still haven't implemented it entirely, working on that now.
Basically I started developing a biome selector approach. I am defining, for starters beach, mountain and valley biomes, using a combination of player supplied sizes (e.g. small, medium, large) with plotting ellipses to select their ranges.
I imagine heightmap usage, as was suggested (thank you @Sir Spunky), would probably be a cleaner approach, but I am still having difficulties getting them going. What would you suggest I use for heightmap generation, right now I am relying on GIMP and am still fumbling with the drawing/painting tools.

 

The old favourite for Unity terrain, Worldmachine, might be helpful to you here, although i just grabbed a very promising looking asset called Limestne for terrain generation - you could create a heightmap with either of the aforementioned, load ity as a terrain in normal unity terrain to touch it up, export it and then use that for your heightmap id guess

 

I do have Terrain Composer and can generate a real nifty island using its tools, even has an example. I guess I can start from that. Then, rather than using what is promising to be a rather complex setup to get elliptical circumferences figured out, would I just grab values off of the heightmap for biome selection? I am not exactly sure how to go from a large heighmap of the island to accurate biomes. I am still researching the ellipse formulas and stuff like Epitrochoids and Hypotrochoids for creating realistic edges and shapes to the island. A leap for me still is underastanding how to put the formulas I am finding on wikipedia to use, e.g.:
http://en.wikipedia.org/wiki/Epitrochoid
http://en.wikipedia.org/wiki/Hypotrochoid
http://en.wikipedia.org/wiki/Ellipse#Circumference
I think by taking the procedural approach I will be able to give my clients/players of my game, more bang for their buck, allowing for reseeding, the map, etc.
Does anyone know of examples of the above that are more specific to using in a video game setting. I could see a lot of these formulas being used all over the place, so I would imagine there are even libraries that handle most of the heavy lifting by now. I am still a little green in the 2D/3D geometry departments, unfortunately.

PS @AmandineEntertainment I am very happy with your progress and hope requests don't make you feel like I am not happy with what you've done so far. What you're doing with your product is hugely impressive, keep up the great work!

PPS I did find this here:
http://stackoverflow.com/questions/12176174/plotting-an-elipse-in-3d
But I am going to need to change what its doing a bit to get what I need for biome selection.
I am going to open a ticket for this in the answer forums to see if I can find a Unity best practices approach for finding out whether something is inside or outside a given ellipse, if anyone is interested like this and I'll update with a link to the thread if I get an answer.

 

Ok, that sounds perfect.

Sounds good.

Right, ok. I have my own chunks that are also based on player position (as well as other things) and I really would need to be able to call methods myself to create or destroy specific terrain chunks, or upgrade or downgrade specific chunks between different LODs. The thing is, the player may have moved from A to B and be moving back towards A. But the chunks (of my own system) around A take some time to generate, so if I can't control when the terrain chunks are regenerated, they could spawn before the volume data they depend on is ready.

Furthermore, it's not as simple as just player position. For example, if the player is about to teleport a long distance (outside of the current terrain), what I do for my own chunks is generate them around the new target position without destroying the ones around the current player position yet. Only once the new area is ready is the player teleported, and only after that may the chunks around the old player position be destroyed.

Is there any chance to provide a lower-level API for handling the terrain chunks where I can plan it according to my own logic instead of the predefined logic included with uTerrains?

 

Thanks for the information, very helpful. It definitely sounds quite promising. I'm still a little confused about the textures, though.

You say that if I need more than five textures, I would need multiple materials. Do you mean that any block can have up to five textures making its faces, but that I need a new material for each block?

I wasn't sure if it's possible to put that many textures on a block, or if I can only put one on top and then another on all the sides and bottom.

I'm fine with using multiple materials but I hope that you'll add ways to reduce draw calls in the future.

Also, one last thing: you said that you load chunks that way for performance reasons. But if doing it the way I suggested would lead to much faster load times in the eyes of the player (would get on the terrain and able to play much faster), wouldn't that be worth it?

The main reason I'm saying this is because I would like to support the ability to link multiple worlds together. That is, the player could enter a new world from the current world. Or, I would like to support the ability to have world types, where each type is compromised of a different set of biomes. And the player could change the current world's type, which would mean loading a whole new world.

Although I'm not actually sure if this is even possible... I'm hopeful . Edit: this does seem to be possible, based on your response to my thread on your support site. Good to know.

In either case, I'll be sticking with your engine because it looks so promising and I can't wait to see how it turns out in the future!

 

If you don't mind, I'd like to add a few things I realize I should have mentioned:

Yes, but the lowest I can get to is 2, which produces something like 16x16 chunks of terrain from what I seem to count (or close to that). And I may want a smaller amount even. The player may not have a fantastic computer.

This means having 100s of mesh colliders active. Or, in other words, every visible chunk for me has a mesh collider (since I prefer not to use further LODs). Seems like far more than should be required...

 

Ok, I better understand your needs.
Ultimate Terrains' logic is basically:

Code (CSharp):

1. // What's basically happening in UltimateTerrain's Update method
2.  
3. isGenerating = false
4. if (player moved && !isGenerating) {
5.     isGenerating = true
6.     start generation of new chunks in threads
7. }
8. when (all chunks have been generated) {
9.     hide/delete all old chunks
10.     display all new chunks
11.     isGenerating = false // => get ready for next generation
12. }

What you need is to disable UltimateTerrain component to prevent default Update method from being called and then use these 3 functions (which don't exist yet, but I can add them in the next update):

Code (CSharp):

1. void StartGenerationAround(Vector3i chunkPosition) {
2.     if (!isGenerating) {
3.         isGenerating = true
4.         start generation of new chunks in threads
5.     }
6. }
7.  
8. bool IsGenerationDone() {
9.     return true if all chunks have been generated
10. }
11.  
12. void ApplyGeneration() {
13.     if (isGenerating && IsGenerationDone()) {
14.         hide/delete all old chunks
15.         display all new chunks
16.         isGenerating = false // => get ready for next generation
17.     }
18. }

From what you told, I think it would suit your needs. It will be difficult, if not impossible, to provide a lower-level API without compromising threads synchronizations and internal (and critical) behaviors.