[OLD-FORUM-THREAD] Ultimate Terrains 1.0

Alright, sounds good. Does the engine automatically split the textures within a chunk to be able to display more than 5 textures? If it does, do these textures (multiple submeshes) blend between eachother or would I see a hard seam in those cases?

As for the perlin/simplex case, like twobob said, the speed between simplex and perlin in 2 and 3 dimensions apparently doesnt really matter (maybe even perlin is a bit faster, but appears to have more grid-like artifacts than simplex)

 

Thanks for your replies and info!
With the implementations of Perlin and Simplex I have, there is a noticeable performance difference between them (simplex is better). I will have to find a better implementation of Perlin noise if I want to use it instead of Simplex. For this reason I will keep using Simplex for now but I keep that in mind. This is in the todo list.

Textures of the same material will properly blend together, both inside chunks and between two chunks. The only case where textures won't blend is when you use different materials and enable "Duplicate vertices".

 

I don't know where you need it - Last time I did it was on the gpu, looks like someone beat me to that punch with unity though, for ref https://github.com/ashima/webgl-noise

 

Thanks for the link I'll get a look at it, but I need it on the CPU.

 

The first update of uTerrains has been sent for approval:

• Fix issue with 'Graphics' namespace compatibility.
• Fix future potential compatibility issues by moving all monobehaviors into UltimateTerrains namespace.
  CAUTION: for some reasons, this breaks the Unity deserialization process of existing uTerrain objects. So if you started to customize some parameters of your terrain, you MUST IMPERATIVELY MAKE A FULL BACKUP of your project before updating. You will then be able to create a new terrain and set your values manually. I know this is really annoying, but this should never happen again!
• New feature: possibility to choose between properly-connected-seams and skirts (or both) to connect chunks.
• New feature: possibility to duplicate vertices (ie. one vertex has only one triangle) to fix texture stretching issue.

More to come in future updates

 

Picked it up as well.
I'm impressed by the loading time (less than 10s on my core i5 (quad core) / Geforce 780 / 8GB of RAM for a 8k terrain). For such a big voxel terrain I expected at least 30s... or even more.
Keep up the good work!

 

Great! Thanks!
I keep working on the second update don't worry.
Yes, perfs are very important for a voxel terrain engine that's why I pay a lot of attention to computation time and optimization.

 

Good to know
Just downloaded the update. The new feature to duplicate vertices is great! From what I've tested until now, uTerrains keeps its promises. It's fast, reliable, and it looks like we can really generate anything we want.. even if I hadn't enough time to test every possibilities yet.
Is something planed for the next update already?

 

I made your web demo (simple no trees) do bad things in the console.


I was destroying floor at the time.

There are two errors there. 1st was at load time. 2nd was whilst destroying.
It continued to work but thought I should report.

Is the obfuscation intentional, or a very mangled string?

 

@twobob
Thanks for your report!
I think this happens because uTerrains tries to load some file which is forbidden in a webplayer (just so you know uTerrains also offers the possibility to load from Resources instead which is not forbidden). This is a bug I've already fixed in the upcoming update (1.0f3) where uTerrains was trying to load something even if loading was disabled.
I'll test it again to be 100% sure this is about the same bug.
Yes the obfuscation is intentional, which doesn't prevent me from debugging as I know what class matches with obfuscated string.

@clerok
Thanks for your kind feedback Clerok! Yes indeed you can generate anything you want as you can create your own generator modules and operations.
Next update (1.0f3) will come with bugs fix (like the one above) and a few improvements:

• Remove some artifacts on the terrain due to float precision.
• Remove some bigger artifacts on the terrain by forcing the octree to split itself when needed.
• Voxel Types can now be customized with 'VoxelTypeFunctions' that allows you to choose the vertex color depending on the vertex normal (so you can specify a texture on sides and another on tops for example).
• Small optimization by converting a recursive algorithm to an iterative algorithm which is better for the stack.
• Maybe more...

 

cool beans. err... is this a dll release then?

 

Yes it is (but it's C# so it's compatible with everything). I will probably make another license with sources one day but this will be more expensive.

But again, this shouldn't be a problem for users because you can still deeply customize everything. Only the core of uTerrains is in a dll. All generator modules, biomes selectors, combiner modules, voxel type functions, and operations are included with sources. This mean you can create your own scripts to control terrain generation. The code which is in the dll should have never been modified in any case.

 

You're welcome!
Looks great!

 

Why is it so slow when continuous editing is enabled? It slows to about 5 fps even with minimal LODs and a limited map size.

 

@Leanimal
In the current version of uTerrains, real-time editing in made exclusively on the main thread. When you perform an operation, the chunk(s) affected by this operation need to be rebuilt. It takes about 15-20ms to build a chunk, so if the operation affects 4 chunks (that's just an example), the total time needed is about 60-80ms, which leads you to a low frame rate. Number of LODs and map size won't change this.
The solution is to make things happen asynchronously. This feature has already been planed and is going to be done soon in an update. The inconvenient of an asynchronous operation is that it does not guaranty to be done in a single frame, but the advantage is that it won't affect the frame rate (almost). So I'm afraid you will have to wait for this feature but don't worry it's a top priority.

 

I love the Terrain generation tools provided. Very customizable, and once you get the hang of it, easy to use. Just got a few questions about interacting with the terrain hopefully you can answer.

1. When I am interacting with the terrain, I would like to know what material (VoxelType) I am interacting with (Eg. If I'm hitting "stone", "iron" or "dirt" with my pickaxe). I see the following method in the DigCube script. The voxel object appears to have the information I'm interested in. Is there a way to get an instance of Voxel at a specific unity position?
   
   public virtual bool Act (int x, int y, int z, Voxel voxel)
   
   
2. I would also like to add more information to the voxel (eg. hitpoints/health) so I can keep track of damaged voxels. I assume this is not currently possible at the moment though.
   
   
3. When digging a hole by removing single unit size voxels I am seeing a lot of graphical artifacts. Is this what you are working on in the next patch?

I looked at a lot of different voxel terrain generators. So far I'm quite happy with my choice. Looking forward to updates.

 

Thanks Conan!

1. You're right, the voxel contains the information you want. So I guess what you need it a method that looks like terrain.GetVoxelAt(Vector3 position). Am I right? I will add it to the next update because there is no such function for now. Just so you know, voxels are not kept in memory for a long time, so if you call this function for a position where the voxel has been removed from memory, it will be computed on the fly. This is very fast for a single voxel.

2. I understand what you need. Unfortunately as I said just above, voxels aren't kept in memory for a long time and it's not possible to guaranty that a voxel will still exists when you need it.
Fortunately, you can do it without using the uTerrains' voxel object. My advice is that you keep the health of a voxel in your own array/dictionary/whatever.
For example, you can create a Dictionary<Vector3i, float> that would contain the health at a given position only if it is different than the default health value (in other word, if there is no entry in your dictionary at (x,y,z) then it means the voxel at (x,y,z) has full health).
This way you can keep track of the health (or anything else) of a voxel at any position in the world independently from uTerrains. This is clean, and this is actually the only way to go with it.

3. I've fixed several artifacts issues in the upcoming update, but this may not be entirely solved in 1.0f3. I have a lot of features and improvements to do so it's hard to give a deadline, but in any case I prefer to make small updates regularly and frequently than big updates each 6 months.

I'm glad you're happy with your choice. I'll do my best to make all customers happy!

 

Thanks for the quick reply.

1. Yes. That is exactly what i was hoping for.

2. Thanks for the suggestion. This will work.

Can't wait for the update!

 

@Conan Morris
BTW, if you create a Dictionary with Vector3i as keys, don't forget to use the Vector3iComparer like that:

Code (CSharp):

1. new Dictionary<Vector3i, Whatever> (new Vector3iComparer());

This will make it much faster, preventing boxing/unboxing, and this will also make it compatible with AOT.

 

First, I want to say thank you for such a great product! I've tooled around with 2 other voxel based unity assets and your is by far the best, imho.

Currently I am setting up terrain generation and am having a couple issues.
I looked through your examples and rtfm and think I have a decent understanding of why I am having issues, just not how to solve them.

First, using the first person controller you provided (with a platform to prevent Y axis movement during map generation) worked fine (once I removed all of the conflicting first person controllers I had polluting my namespace).

Problem is, its using a Unity 4 FPS controller. When I switch to using the U5 controller I start having issues. In and of itself it wouldn't be an issue except the U4 FPS Controllers are in JS something I would prefer to avoid using if I can. Also, I have built some of my own behaviors into a C# FPS controller I built based off of the U5 controller.

So far I've noticed 2 issues with the U5 FPS controller, the camera seems to be sunken just below the horizon and intermittently I've noticed a continual sink, not entirely like falling through the landscape, more like perpetually sinking deeper into it.

I've tried the stock U5 FPS controller and my own homespun version with not much success.

Have you been able to use the U5 controllers with terrain?

Again, very impressive. I look forward watching your wonderful asset mature and am glad to have gotten my own copy.
Keep up the great work!

PS Handling water is going to be a big deal for me, even if its not voxel based, at least initially. I saw in your demo you had unity water in the water biome; was it procedurally generated? I was thinking if there is a way to get the dimensions of the biome edge it wouldn't be two hard to script a water mesh to fit, what do you think? Also, with terrain deformation being a part of what I plan on exposing to the player, how would you suggest handing deformations around water? And lastly, do you have plans for getting a voxel water solution in place sometime down the road?

Thank you in advance,
Boysenberry Payne

 

Hey Amandine,

I was wondering if you could elaborate on how Voxel operations are applied (Updating a specific voxels value and/or voxesl type).

I've noticed that whenever PerformAll() is called, the chunk is regenerated, and ever operation you performed on the terrain is replayed. Please let me know if this is not correct, or if there is a way to "perform" and operation without replaying all previous operations.

I'm planing on adding the ability to slowly remove a voxel by changing its value incrementally. So my question is :

If I performed 100 operations on a single voxel, would all 100 operations be replayed every time the chunk was regenerated, or what only the latest operation be replayed.
​

I can't think of a situation where any but the latest operation would need to be replayed.

Thanks.

 

Thank you very much @boysenberry !

I can't test it right now but I will. This is obviously something important. I'll let you know when I have more information.

Actually I just added water as a plane at y=0 and told uTerrains to switch biome at y=0 too so when y<0 the 'under water' biome is used. There is no other interaction between the water and uTerrains.

I'm not sure to understand what you'd like to do?

Not for now. This is something very complex and there are plenty of things I'd like to do before thinking about that. Maybe in the future, but I can't promise.

This is correct. It happens because voxels are not kept in memory. This means that the chunk is re-generated from scratch and the only way to be sure to get the same result is to replay all operations on it.

Fortunately, a new cache system is coming with the next update (v1.0f3), which will prevent uTerrains from doing that, but only for chunks that are next to the player (it's not possible to keep all voxels in memory at any times).

I'm also thinking of a way to avoid the need of replaying operations even for chunks that are not in memory anymore, probably by saving the cache on disk, but this won't be ready for v1.0f3.

 

@boysenberry
I've tried with both FPSController prefab and RigidBodyFPSController prefab of Unity 5 and I'm not able to reproduce your behavior. I have no issue on my side, everything seams to be working fine when I add the player builder to the character (with or without the "Keep player above ground" option enabled).
What is your version of Unity? Did you use the Unity 5 prefabs (from the 'Characters' package)?

 

Perhaps a way to clear/delete all operations from a specific voxel? If I make several hundred opperations to a voxel, then eventually turn it into air, I don't really care what happened to it before.

It seems to me that the only thing you can do to a voxel is change its value or voxeltype. If this is the case, then only the last thing you set those values to would be relevent. You seem to suggest that this is not the case. What other opperations could you perform on a voxel that I'm missing out on?

 

Awesome asset! The reason why i got it is because i'm not skilled enough myself to make my own so bare with me as i ask a noobie question,

I've noticed when playing around with the biomes that the placement of the biomes for me anyways is very black and white, As in "biome is placed on top or on bottom" Is there a way i can make (or if this feature is not already included possibly for the next few updates?) 'Areas' in which i could assign biomes to, For example Area A has a rare probability of spawning and has the assigned biome of B.

Areas = Assign a biome, Assign Details to that biome in that specific area, etc.
Biomes = Same system as it is now

Not sure how long this would to implement into the engine so i'm just going to leave it here as a suggestion. NOTE if this can be already done in the biomes editor to some degree and i'm just not fully understanding how it works let me know. (Maybe a custom module is what i'm looking for... If that's the case that's great, But i think for a future update making a 'Area' variable would make it easier for noobies )

-Cheers from Canada

 

@Lechado

I think I can answer this one. You would have to write your own biome selector (Or wait for another to be written). Writing your own wouldn't be too difficult though.

The "AboveAndBelowBiomeSelector" is as simple as the following. It selects one biome if the y coordinate is less that your vertical cut plane, and another if not.

Spoiler: Above and Below selector

Code (CSharp):

1.  
2. using UnityEngine;
3. using UltimateTerrains;
4.  
5. public class AboveAndBelowBiomeSelector : IBiomeSelector
6. {
7.    float yCoordinate;
8.    short aboveBiomeId;
9.    short belowBiomeId;
10.  
11.    public AboveAndBelowBiomeSelector(float yCoordinate, short aboveBiomeId, short belowBiomeId)
12.    {
13.      this.yCoordinate = yCoordinate;
14.      this.aboveBiomeId = aboveBiomeId;
15.      this.belowBiomeId = belowBiomeId;
16.    }
17.  
18.    /// <inheritdoc/>
19.    public short GetBiomeId (int x, int y, int z, float[] values2D)
20.    {
21.      return y < yCoordinate ? belowBiomeId : aboveBiomeId;
22.    }
23. }
24.  

In order to do what you are asking probably wouldn't be too much more difficult but you would have to provide a "Noise" function of some sort. You could use simplex noise similar to how the generators work. You may want to google simplex noise to get an idea of the kind of biome disbersment it can provide.

Spoiler: Two Biomes, one more rare than the other

Code (csharp):

1.  
2. using UnityEngine;
3. using UltimateTerrains;
4. using UNoise.Graphics.Tools.Noise.Filter;
5. using UNoise.Graphics.Tools.Noise.Primitive;
6.  
7. public class AboveAndBelowBiomeSelector : IBiomeSelector
8. {
9.    float frequency;
10.    float secondBiomeThreshold;
11.    HeterogeneousMultiFractal noise;
12.  
13.    public AboveAndBelowBiomeSelector(float frequency, float secondBiomeThreshold, float seed)
14.    {
15.      this.frequency = frequency;
16.      this.secondBiomeThreshold = secondBiomeThreshold;
17.      noise = new HeterogeneousMultiFractal ();
18.      noise.Primitive2D = new SimplexPerlin (seed);
19.    }
20.  
21.    /// <inheritdoc/>
22.    public short GetBiomeId (int x, int y, int z, float[] values2D)
23.    {
24.      if( noise.GetValue ((float)x * frequency, (float)z * frequency) ) > secondBiomeThreshold)
25.      {
26.           return 1;
27.      }
28.      else
29.      {
30.           return 0;
31.      }
32. }
33.  

I believe noise.GetValue always returns a value between -1 and 1. Depending on the value of secondBiomeThreshold you pass in, this could produce smaller "blobish" shaped biomes surrounded by the main biome.

Note: This code might not work as is, and you will have to write the UI class for it (AboveAndBelowBiomeSelectorSerializable), but that should be simple if you just look at the existing ones. You should probably also pass in the biome IDs instead of hard coding them.

 

Hi,

This looks really promising and well-done! Probably the best voxel solution I've seen so far. I've got some challenging questions if you don't mind me asking:

1) Do you notice any lag while new terrain is generating? I tried to build a procedural terrain generator using multiple built-in terrain objects, but each time I modified a terrain I would get dropped frames because of the mesh collider updating. Do you have the same problem?

2) Do you ever get any holes or visible seams in your terrain due to LOD issues?

3) I saw you mention a "biome" feature, but I'm not sure exactly what it does. Basically, what I'm interested in is to be able to have one area of the terrain to be of a "forest" type, with maybe 3-4 forest textures blended on it, and another area be of "mountain" type, with different mountain textures on it, and a third area be a "swamp" type with its own set of textures, and so on. This would basically mean I could have a much larger set of textures than what would normally be allowed. Do you have some sort of solution for this?

I know these are all very difficult issues to solve, and I don't expect you to have solved them all yet. The project seems very promising regardless.

Thanks and keep up the good work!

 

Thank you for your prompt responses.

I will start a new project tonight and see if that corrects my issues with the first person controller. I was using the default Unity 5 (5.0.0.f4 Personal) FPSController. I have a bunch of assets in the project I was testing out uTerrains in and each one likes to re-include the default Unity assets, so maybe something got squashed along the way.

UPDATE: I just setup a new project and tested the Unity 5 first person controller and it worked just fine. Thanks for the help on this!

On my earlier post about water, basically I am trying to figure out how to use the standard unity water to good effect in my terrain. The problem I have had so far is getting the water to keep to the edge of the terrain during deformation. If I have just one large water plane then it will show up in places 'unexpectedly' and all on one level (way too predictable). So, I am working on figuring out a way to get the water mesh to deform along with the terrain so that it will stay in the depression created for it(or altered for it), seemly filling it all up. In my game I plan on using water to quench thirst, etc, so it needs to be available. Also, having it all show up only on y <= 1 doesn't make sense for me either, so I'll be tweaking how the water biome shows up (hopefully tying the u5 water mesh in with the biome creation/alteration scripts.)

If you have any ideas or suggestions on how to implement that, I would love it.

Keep up the great work, and thanks for looking into the first person controller issues for me. Now that I know it works for you I don't mind debugging and figuring out what's wrong on my end.

PS I have a couple questions about the Coefficient of error (on surface and chunk borders) as well as the Max distance to be 'near the surface'. First, the error on surface is a whole number and the error on chunk borders is a float, why; also what are they for? Secondly, How does max distance to be 'near the surface' effect things? If my understanding is correct the value equates to the distance of the voxel and the level of detail, so that the greater the distance (i.e. the closer to one it is) the greater the detail, e.g. the terrain will be more granular in its appearance. Is that right? Also, If I am noticing artifacts between biomes would this effect that?

Thank you,
Boysenberry Payne

 

@Lechado
I couldn't have said better. @Conan Morris gave you the right answer (thanks btw).
I would have use Simplex noise or Perlin noise though. I think this is more suited to define some areas (ridged multifractal produced more "sharp areas").
In any case, keep it simple. The biome selector must be as simple and as fast as possible, otherwise it will slow down the all generation.

@Sir Spunky
Thanks!
1) There are mainly 3 difficulties to avoid lags:

1. Doing too much things on the main thread (this is solved by multithreading)
2. GC. When the garbage collector is executed, all threads are temporally stopped (including the main thread). This is solved by handling objects in memory in a clever way, so the GC is almost never called and when it is, it stays very fast.
3. Collider. Yes you're right, this is definitely a cause of lag and there is no way to avoid that completely, but uTerrains split itself into several small chunks. The collider of each chunk is fast to compute and uTerrains ensures that there is only a limited amount of chunks that are updated in a single frame (1 by default).

2) Normaly no. LODs cracks are handled either by properly connected seams or skirts (or both), it's up to you (just enable or disable it from the inspector). However if you set the acceptable geometric error to a hight value, the terrain may have holes.

3) Biomes handle exactly what you expect. The number of textures is limited by the shader, but uTerrains supports multiple materials so you shouldn't be limited. Be careful though: if you enable "duplicate vertices" feature (to avoid texture stretching) then the different materials won't blend together automatically.

I understand what you want to do. Seams hard. Would you be able to modify the water shader so you can make it become transparent in some places? I know there are some people around there who have already done that for boats for example (the water plane becomes invisible inside the boat). I think with the same kind of trick you could be able to figure out something. I have no better idea for now.

These are good questions and I should make a doc about that.

Coefficient of error on surface allows you to tell uTerrains: "hey, you found the surface of the terrain so now you don't need to be so accurate. You can accept a bigger geometric error because it's sure there won't be holes.". This is useful for making things a bit faster and produce less polygons.

Coefficient of error on borders allows you to tell uTerrains: "hey, I really don't want to have holes in my terrain so you must be very accurate on chunk borders.".

The max distance to be 'near the surface' produces less effects. Basically, it tells uTerrains that if a voxel is 'near the surface' (ie. its absolute value is lower than the max distance), it must ensure that it found the surface. This can avoid holes in some cases.

A lot of artifact issues have been fixed in the next update (1.0f3 - coming soon!). This might solve your problem.


Thanks to all for your feedback and your interest in uTerrains!

 

You're right, but in any case it means that I need to store the final value of the voxel. I can't just store only the last operation because the operation could be doing something like "value = value -0.1f".
This is the next thing I'll be working on because this is one of the things I need to do to make real-time editing faster.

 

I suspected it might be something like that. Not an urgent thing for me, but would be nice eventually.

FYI. After the issues you are solving in 1.0f3. The next larger issues I'm seeing are:

1. Chunk regeneration speed when moving to a new LOD. I'm not 100% sure what is causing this, but it is reproducible on your demo if you crank the walk speed of your first person controller to 15 or 20. If you walk in one direction fast enough you can walk into the next LOD before it regenerates. When you start placing blocks, you can see that the colliders are added instantly, but sometimes it takes 10-20 seconds for the mesh to update. You end up with an invisible block until the mesh updates.
2. I've started generating large underground caverns (They look great, and it was really easy with your tools). The problem is that light appears to be getting through cracks in the mesh. I've made sure I've added seams, and even skirts to the chunk boundaries, but light is still getting in. Perhaps this is also a LOD issue?

Again, I'm loving this product. Looking forward to 1.0f3 and terrain.GetVoxelAt(Vector3 position).

 

This is a limitation of voxel terrains: it doesn't update fast enough for a player moving too fast. But I'm working on performance improvements all the time so it will get better and better (1.0f3 is already coming with some nice optimizations ).

I was not aware of this problem. Thanks for reporting this! Will look at it.

I'm glad you're happy with uTerrains!
Don't worry, GetVoxelAt is ready.

 

I'm glad to announce the v1.0f3 of Ultimate Terrains (currently pending for review).

This update comes with a lot of improvements and bug fix.

Performance is significantly improved. Loading time has been reduced by more than 10% and LODs are updated a lot faster when the player moves. Operations computation time has also been divided by 2 or 3 when the new cache system is enabled (but it needs more memory). Also, some people that were getting some lag sometimes should not get it anymore (especially when they test the standalone/webplayer/etc build of there project).

Here is the release note:
- Big optimizations and performance improvement.
- Add a new cache system allowing to keep some data in memory. This increases performance and divide by 2 or 3 the time needed to perform an operation, but it can take a big amount of memory. Add MaxLevelWithCache parameter.
- Possibility to compute voxel-types color dynamically through VoxelTypeFunctions. Vertex color can now depend on the vertex normal. CAUTION: you will loose your old voxel-types colors with this update, so remember them before updating.
- Add uTerrain.GetVoxelAt(Vector3i voxelWorldPosition, bool computeGradient) function to get a voxel anywhere in the world. The PlayerBuilder component has been updated so that when you right-click you get some information about the voxel you are targeting.
- Add seed parameter to simplex noise.
- Fix miscellaneous bugs.

The online demos will be updated soon too.

 

Awesome! Can't wait to test it!
Vertex color depending on normals is definitely something I needed. Thank you so much for making this great product!

 

Thanks for the kind words @clerok !
Indeed this new feature is very useful to set different textures on sides/top when you use RTP3 for example.

 

Would it be possible to get a demo of doing that or an example scene maybe? Obviously if there are more pressing issues I'd rather you focus on them.

Also, I am starting to look into AI path finding type stuff and saw the thread about you leaving that for now, which is fine by me, I'd rather you stay focused on what you know will bring the engine to its fullest expression. What I was wondering was if you'd had any experience with existing solutions and if so are there any solutions you'd suggest looking into?

Again thanks for the incredible work, I can't wait to update!

Boysenberry Payne

 

@boysenberry

I've been playing around with the free version http://arongranberg.com/astar/.

I've got it "working" by attaching a GridGraph to my AI object (The GridGraph follows the AI), then rescan the grid intermittently as the AI moves.

I've had quite a few problems though, and I'm not sure a "Mesh" or "Grid" pathfinding system is going to work that well in an environment that is so variable.

Issues I haven't been able to solve yet:
- Rescaning a 50x50 grid takes 100-200ms and completely locks the main thread
- You can only choose one height above the surface to search for walkable ground. So you have to choose between the grid being able to see an uphill slope, and the grid recognizing that you can go under an archway or in a cave.
- Getting the AI to search a grid other than the first one generated

I'm trying to work it out so that I can place multiple grids at different locations and heights, but haven't had any success pathfinding to them.

When the grid works, the pathfinding is great. I expect I'll have to compromise though, and build my own obstacle avoidance system as a failover when pathfinding isn't working.

 

It would seem like the best choice after looking around a bit myself as well. The only other free path finding assets I could find worth mentioning were these:

http://angryant.com/path/download/
https://github.com/jorgenpt/unity-utilities/tree/master/PathMoveable

I will give it a whirl as soon as I am able and report back my findings.

 

@boysenberry @Conan Morris
I'm interested if you find something cool to use with uTerrains. I'm afraid I can't help you on that for now as I haven't tested any path-finding system. Please let me know!

 

V1.0f3 is available! Happy update!

 

So far everything is wonderful. I am running into an error in the scene view editor:


Destroy may not be called from edit mode! Use DestroyImmediate instead.
Also think twice if you really want to destroy something in edit mode. Since this will destroy objects permanently.
UnityEngine.Objectestroy(Object)
VTHSjNHbjyQqnwLNmNIndNnCdLZg:YIDSWXNggStFfSFvCDzOgLwMCxvY(Mesh&, Int32&, Bounds)
UltimateTerrains.ChunkComponent:QAZYJQcQtWAXTZJpmGdTMqNJaGY(Boolean)
PoHkoAFPTaIHriIIBLqNtLKXlnH:usBopdadAYSKZkbTmFcwixToxJv(Boolean)
PoHkoAFPTaIHriIIBLqNtLKXlnH:QAZYJQcQtWAXTZJpmGdTMqNJaGY(Int32, Boolean)
UltimateTerrains.UltimateTerrain:TeieilqwBbbxJbSezhRbsmBRJajO()
UltimateTerrains.UltimateTerrain:Update()
UltimateTerrainsEditor.UltimateTerrainEditor:OnUpdate() (at Assets/uTerrains/UnityEditor/Editor/UltimateTerrainEditor.cs:340)
UnityEditor.EditorApplication:Internal_CallUpdateFunctions()

Not sure if its something to be concerned about or not, so far it doesn't seem to be effecting my ability to view the terrain.

PS It looks like you did a whole lot in this update, very nice, thank you!

 

@boysenberry
Thanks for the feedback. This isn't dramatic but could lead to some memory leaks in the editor. I'm gonna fix this.

Yes there's quite a lot in this one. Thank you for supporting this product and giving feedback!

 

So I decided to try out Apex Path for my path finding solutions. I will let you know how it works. The main thing is it does realtime raycasting grids, allowing for handling the voxel terrain. As far as I am aware right now, the only limitation is the nav grids can not overlap vertically, e.g. so path grids will not work in a cave situation where the map overlaps itself. I believe this limitation exists in the only other alternative I've found as well, A* Pathfinding Project Pro.
From what I could tell in the forums, A* Pathfinding Pro has a few more features, but isn't put together as well as Apex. I picked Apex because of the support and comments I read on how well the code was put together.

I will let you know how it works for me as I use it.

 

Thanks for the feedback!
Yes please let us know if you figure out something. Everybody will be interested!

 

Was curious, there is a sale on the uPhysics asset today and I was wondering if you thought it might be able to speed up terrain generation or not. That is if you have a moment to check it out. I posed the question in the forum here: http://forum.unity3d.com/threads/released-uphysics-uphysicspro.210855/page-7 towards the bottom of the page.

The author of the physics package had this to say:
"Short answer, yes it COULD work with Ultimate Terrains. However, to give a more accurate answer I'd need a bit more of information as of how the system works. Are the voxels accessible as actual meshes? Is the terrain only accessible as a huge mesh? How do you access the data of the tool and what data do you access?

Those are critical questions. I guess you currently generate a physical behaviour by assigning a mesh collider to some kind of data which gets generated by the tool. In that case it wouldnt be a problem to just exchange that mesh collider with the one of uPhysics. Tho, this requires an actual TriMesh collider which is once again content of v2.2. Unfortunately. I guess I have to write this way to often...

As of terrain generation, uPhysics might only speed up the collider generation of the terrain, not the actual terrain generation itself.
Additionally, with uPhysics you have always the chance to implement a special collider ontop of an existing one. The source is included so you can optimize for your corner cases as much as you wish. "

Do you think it would make sense to purchase it and see what it can do?

PS I ended up purchasing the asset to speed up some of the other physics related calculations I was depending on the Unity Engine for. I am guessing once the TriMesh colliders are released I will not be able to replace the unity colliders in uTerrain very easily, right? Its a useful package for other things, but I was thinking it would be nice to get as much out of it as possible.

Thanks again,
Boysenberry Payne

 

@boysenberry
Sorry for answering too late! I think you did well buying this asset. Sounds like a good product.
I'm not sure we would get any benefit from using it in uTerrains instead of the Unity's physic system because it would probably have to be computed on the main thread anyway (in uTerrains). I prefer to keep things simple (KISS principle), at least for now. But I keep that in mind

 

I figured that was probably the case. At least this will get some of the other physics related crunching off the main thread and leave it for terrain rendering.

 

Hey Amandine,

Thanks for the update. Loving the chunk caching, and getVoxelAt.

I've recently added multiplayer to my game, and I've run into an issue with the terrain generation. With multi-player, I now have to spawn my characters at run time. uTerrains won't generate terrain unless it has a player transform attached to it, so I created a dummy transform and switched it to my real player in "OnTerrainLoaded" using:

terrain.PlayerTransform = myPlayer.transform​

This appeared to have worked, but I then found that my LOD's weren't updating as I walked around. Even though the unity editor shows my new player transform in the uTerrains player slot, it seems uTerrains is still updating based on the dummy transform I used at generation time.

I got around the issue by setting my real player object as the parent of the dummy, but I imagine there must be a way to associate my player with the terrain correctly. Any idea how I can do this? Perhaps terrain.PlayerTransform= isn't working as it should be?

Thanks,
Conan

 

@Conan Morris
This is something I haven't thought about! Using a dummy transform and switching it to your real player with terrain.PlayerTransform = myPlayer.transform is the right thing to do.
The issue comes from uTerrains because it caches the transform in the Awake method and then never updates it. This is an easy fix. I will fix it for 1.0f4 that should come soon because I've fixed some bugs concerning operations too.
Thanks!

UTerrains interacts with the Unity's collider only when the chunk is getting created (during post-building phase), and chunks are small enough to make the MeshCollider update very quickly. Except from that, I think all phys'x stuff is happening internally in Unity's C++ threads or even on the GPU. I think uPhysics may be a great thing for a lot of stuff but I'm not sure it would improve uTerrains performance noticeably. But I keep that on mind anyway

 

I can't work with this. Is there any tutorial?