[OLD-FORUM-THREAD] Ultimate Terrains 1.0

When do you think this will make it into the engine?

 

@AmandineEntertainment

I've started working on generating towns which has uncovered a few problems when dealing with a large number of operations.

Once a large number of operations have been performed in a chunk additional operations performed in the same chunk in game by the player take almost a full second to complete and lock the main thread.

I thought it would be trivial to throw all of the operations on their own thread as terrain generation does not seem to run on the main thread. I tried the following, but all I get is the error below. Do operations have some dependency on the editor?

Code (CSharp):

1. System.Threading.Thread clearTerrainThread = new System.Threading.Thread(new System.Threading.ThreadStart(terrain.OperationsManager.PerformAll));
2. clearTerrainThread.Start();

It would also be nice to be able to "merge" operations somehow. In the case of clearing land for a house, if done by hand (One block at a time by the player), a 10x10x5 the chunk takes about a second to reload. If I do a single operation to clear the same size piece of land, the chunk takes milliseconds to reload.

Adding some sort of merge functionality probably wouldn't work for you, but if you could expose an API where I could access/delete operations I could figure it out on my end.

Thanks,
Conan

 

I'd like to suggest something related to the tree thing. I still haven't managed to get the trees working yet, and even if I do I think the current method will be a bit slow.

Is there any way you could add a system for randomly generating arbitrary structures into the terrain during generation? I'm not entirely sure how it would work, though.

There would have to be a way to specify what a structure is and the voxels it contains, as well as what determines how it gets placed in the terrain.

As long as it is editable by the player when it enters the terrain, is my only request.

But if a system you add wouldn't be any faster than the dictionary method, then I'll have to keep working with it.

 

Did you manage to get the dictionary method working? The author said that this filling should be put in the constructor:

Code (CSharp):

1. int treeHeight = 6;
2.  
3.     for (int i = 0; i < treeHeight; i++)
4.         arbitraryVoxels.Add (new Vector3i(x, y + i, z), trunk);
5.  
6.     for (int i = treeHeight - 1; i < treeHeight + 3; i++)
7.     {
8.         for (float j = x - 2; j <= x + 2; j++)
9.         {
10.             for (float k = z - 2; k <= z + 2; k++)
11.                 arbitraryVoxels.Add (new Vector3i(j, y + i, k), leaf);
12.         }
13.     }

However the constructor does not provide the x , y, and z coordinates. where do you exactly fill the dictionary and what are the coordinates?
About the combiner part, I think I got that setup correctly. Thanks.

 

@AmandineEntertainment

Can you provide us with an example on how you used RTP3? The triplanar shader included in RTP3 does not have the R,G,B,A channels for the voxel textures, however on your demo using RTP it seems that you managed to have it sorted out. The material I'm currently using is "reliefTerrainVertexBlendTriplanar.mat" and I can only assign details maps on it.

 

It's not possible because the whole chunk is only one single mesh. You'll have to handle these kind of voxels on your own. I think you can make it through a detail object.

@ghostboxer
This is a smart way for handling perlin worms. If you get it working it would be extremely nice to share it with others (or even publish it on the asset store, maybe some people would be interested for a few bucks). I think your problem is that your frequency is too low. Try with a frequency of 1 or even higher.

@gracks
It's hard to give a release date because I'm gonna be in holidays soon for a trip where I won't have any computer during 2 weeks and I won't be able to release it before. I'll let you know but I'm afraid the next update is going to be delayed and won't be there before the end of July. I hope you can work on other parts of your project until that.

This is a problem I'm aware of and I'm still thinking of the best way to fix it.
I have three main topics for next updates:
- improve operation system (and also give a better API to remove/undo operations)
- improve generation system to make it even more customizable
- improve details objects system because it's too basic for now
And beside that I have a lot of other things to fix/improve.
So don't worry I will treat this issue.

As I've said just above, improving generation is on the road map and this is part of it.

In the constructor you fill the dictionary with relative voxel positions so it's like if x=y=z=0

I'm not sure to understand, this shader of RTP3 uses RGBA channels to apply textures. Unlike the included shader, you don't have any texture with color(0,0,0,0) but for example with red color you'll have the first texture. Is the terrain completely black?

 

@Lelon
The material used with RTP and Ultimate Terrains is called ReliefTerrainVertexBlendTriplanar. There are instructions here: http://uterrains.com/docs/using-rtp3/
I was able to get it working just fine. The main thing is to remember the vertex colors determine which texture is used. So, when you set a vertex color (in the uTerrains panel) to red 255,0,0,0 (the last 0 is alpha) the texture (in the RTP material) in the 1st position will be used. Also, make sure you remarked the pramga defines (#define blah, blah) in the shaders mentioned in the instructions in the link above.

 

@Lelon
@boysenberry
Thanks for answering, I couldn't have said it better myself

 

@boysenberry Thank you, I have just seen that link a couple minutes before you posted it : )
@AmandineEntertainment What are the relative voxel boundaries? Like does it go from 0 to 40 on each side? In other word I think it should be the same as the chunk size. Is the chunk size fixed? If yes whats it's value?

 

Is there a way to have more then 4 textures in a material? RTP, the included material, or other?

Also, is there a way to "scale" voxel priority? I notice that if I have a strip of dirt voxels say 4 blocks wide with a lower priority than the grass around it, the grass texture completely covers the dirt.

The only way I can make the dirt visible is to set the dirt as higher priority, but then the reverse problem occurs.

 

There is no boundary in this context. I was talking about voxel positions relatively to the position of the tree (for example).
Chunks are 16x16x16.

It only depends on the shader, but with a triplanar shader you will rarely have more than 4 or 5 textures. You can still add more materials to handle more textures.

I'm not sure to understand how voxel priority would be scaled?
One way to get around that is to define another 'grass' voxel-type which has a priority higher than dirt and use it when you place grass on dirt.
grass1 -> priority = 1
dirt -> priority = 2
grass2 -> priority = 3

 

Is there a reason why you need to obfuscate the class and method names?

Its a real pain to debug exceptions thrown in your core code.

I can't even begin to guess what is causing this...

 

Hi everyone,

Sorry I wasn't online for a few days but this was for a good reason, my wedding was on Saturday
I'm of course very happy, this was a wonderful time for me, and I hope you'll understand I couldn't be active on uTerrains.
I'm gonna be in honeymoon during two weeks so I won't be there again, but after that, I'll get back to work on uTerrains to release the next version as soon as possible

I have some good news for all of you: I've thought a lot about the best way to improve the Operation system and I think I found something good. It's gonna be a lot easier to make what you want (ex: arbitrary shapes like buildings or trees) and it's gonna be possible to copy-paste any part of the terrain. Most of all, it should be a lot faster when you perform thousands of operations next to each other. The only inconvenient I see is that it will use a bit more memory than current Operations.
This will be the main improvement of next version 1.1f1.

@Conan Morris
I've already had bad experiences with some previous projects where my code was basically used to create a concurrent product (not related with Unity).. I don't want that anymore. I know most of people won't do such things but one guy is enough to stole my work. That's why I obfuscate the code.

The stacktrace of your error seems to be related to an internal error.. Nothing should be null there. Are you still getting this error?

 

Congratulations,

 

Great news all around (well except the part about someone ripping off your work). Congratulations on your marriage and I hope your honeymoon is amazing! I am sure I speak for most everyone when I say we're really excited about the progress on the Operation system!

 

Grass density does not work if set to anything besides 1.
Detail objects probability does not seem to be working properly, If I have a detail object with 2 different detail objects each set to 0.5 probability, only one appears.
EDIT: Also the detail objects like trees, disappear as the chunks LODs changes.
EDIT2: Can we also have a seed option for the different detail objects? because it seems that all the detail objects spawn on the same location following the same seed as the other objects...
Edit3: Can you also expose some sort of function to get the surface normal at a given voxel position? like 0 = totally flat surface, and 1 totally vertical surface. It would be useful for auto texturing purposes, instead of hardcoding it into the shaders directly.

 

Another suggestion (small thing) that might be helpful, is using foldouts in your inspector to make it more user friendly

 

Thanks!

Thanks! I'm back so I'm going to finish to develop the new Operation system. This is going to be a big change for uTerrains I hope it won't take too much time to finish it.

I'll look at it

It's because you have to set the second one to 1.0. I know it's not very intuitive and I should improve that.

I'm aware of this problem even if it should have been solved by last release.. but apparently it's not solved yet.

Sure, that's sounds like a 'must have'

Overriding the VoxelTypeFunction isn't enough for that purpose?

I had the same idea, next release will come with panels and foldouts.

 

I have a question regarding voxel priorities and the shader provided and with uTerrains.

I feel like I must just have something setup incorrectly, but I can't figure out what. Say I have three voxel types, "grass", "dirt" and "stone". My terrain is generated using simplex noise to be mostly grass, with patches on stone and dirt.

The problem I am having is the voxel with the highest priority completely overwhelms voxels with lower priority.

Lets say i have it setup like so: dirt priority = 1, stone priority = 2, grass priority = 3.

If I place a stone voxel on top of grass, the voxel shows up with a grass texture. I can even place a bunch of stone voxels, but if there is one grass voxel near, all voxels nearby will have the grass texture.

The only way I will actually see the stone texture is if I make a solid block of stone at least 3 voxels square, and this will just show a tiny patch of stone.

This issue doesn't seem to exist in your web demos, so I'm hoping I'm just missing something. I really don't know anything about how shaders work.

Thanks for your help,
Conan

 

@Conan Morris
This doesn't occur in the demo simply because I set the grass priority to the lowest. If your terrain is mostly grass then grass should better have the lowest priority so you can place other types of voxels on it.

 

@AmandineEntertainment

If a player places a rock on grass, I want to be able to see the rock. If a player puts grass on a rock, I want to be able to see the grass. As it stands, even if the player builds a 5 meter pillar of rock on grass, the whole pillar looks like grass.

Is this just a problem with the shader? I can buy another shader if that is the case.

If its not the shader is there anything I can do on my end to fix this, or is this completely dependent on uTerrain core code.

 

@AmandineEntertainment

If this is a problem with the shader, do you know if using the RTP3 shaders fixes this issue?

 

Reverse your priorities. Grass should be 1 instead.

 

@Conan Morris
Jason is right, you should reverse your priorities.

 

How does that help? If I reverse priorities then when a player places a grass block on rock, the grass block will look like a rock.

This also isn't as simple as grass vs rock. That is just a simplified example. I have many more voxel type than that, and it would be nice if all of them were visible when placed next to any other voxel type.

Reordering priorities may work fine for terrain generation, but not when the player starts to interact with the terrain. When a player places a block of X type, they are going to want to see a block of X type.

Again. Is this a issue with the shader? I can work with it if that is the case.

 

FYI. For anyone else having this issue.

Turns out that whatever code is blending voxel textures together (Shader or other) is treating air as if it has a texture.

The fix for me was to create an "air" voxel type with the lowest priority, and specifically assign all voxels with value > 0 to be air.

I can now place grass on rocks, and rock on grass.

 

It may be a resolution or brush shape issue. I am not using uTerrains, so I can't say, but maybe you can create a second uTerrain volume that holds textures/materials for outcroppings and give it a higher resolution than the main terrain. Then if a rock is placed (vs a grass/rock transition like a mountain), it goes into a 'detail' terrain volume and maybe you subtract a bit of volume from the grass to let the rock/boulder 'dent' the grassy area.

With a custom brush shape, you could perhaps taper the grass very tightly with one shape and make that transition area as small as possible -- like a squished hourglass.

 

I was about to tell you that. You're right, empty voxels are still voxels and their type is taken into account. I don't know if this is the best behavior. Maybe only 'inside' voxels should be taken into account. What do you think? Would it be more intuitive?

 

That's a tough call. Its more intuitive to not have "outside" voxels taken into account when blending textures, but it is also less versatile. That being said, not knowing about this was a serious problem. Perhaps the solution would be to change your pre-packaged combiners to explicitly set an air voxel with a comment stating why.

While this fixes the issue for me above ground. Do you know if there is any way for me to tweak how much a higher priority voxel will blend into a lower? If this is in the shader I can spend some time to learn how it works.

I'm finding it difficult to have realistic looking ore veins underground. Depending on the priority of surrounding voxels, they are either invisible or look massively larger than they actually are.

 

Thanks for sharing your thoughts. I'll think about this

Blending is handled by the shader. Voxel priority is used by C# code to select the right voxel-type and by consequence assign the right color to a vertex. The shader then uses vertices colors to apply textures and blend them together.

Even if they have a higher priority?

 

This is some of the most fun ive had with a unity asset, inspiring. All i can ask for is the grass density problem fixed and eventually a little more interplay between assets intended for unity terrain. If this system keeps this promise up, unity terrain can well.. shove it.

 

Oh i suppose one more thing, thinking about it, and sorry if its an obvious one, but i'm intending to create the initial 'authored' area initially with a heightmap and unity terrain because of the tools for making this look appropriate to real world phenomena (grabbing terrain with worldcomposer, sculpting with erosion brush etc), and this would be a largish area but then blend into more kooky procedurally generated 'infinite landscape' type with uterrain - while procedurally texturing things shouldnt be too hard although some pointers on things to make it easier (For eg, the above mentioned surface normal info.. im not a very adept programmer), the initial 'authored' area would be textured according to maps driven by the tools, in particular things like world machine or erosion brush where splats are generated.

Again, i dont know if this is obvious but would it be straightforward to take these maps into the generation along with the heightmap (flow, wear, sediment maps from erosion for eg) to create necessary voxel types, essentially automating the current workflow for getting pretty terrain in regular unity terrain but with an added bonus of the functionality of these types having volume and data - not just a texture?

 

@AmandineEntertainment

After playing with the shader I see that it is not the problem at all, and it seems to me the priority stuff is working as it should.

It's hard to say for sure since I can't see the underlying code, but my assumption now is that excluding a little blending on
the lower priority voxel (Roughly 50% of the lower priority voxel), the visible texture of a voxel type should be accurate.

So to elaborate on the issue I am having:

When I generate a vein of ore one block thick, ten blocks long. If the ore has the higher priority I can see it just fine, but when I interact with it using GetVoxelAt, the voxel return is usually not the ore, but the surrounding voxel type (Stone or grass).

What I think is happening:

When I interact with the terrain I fire a raycast at the terrain, get the coordinates of the collision with the terrain, then run GetVoxelAt on those coordinates.
- first issue with this is the implicate rounding I was doing was actually just truncating so it was very easy to get the wrong voxel returned
- I changed this by explicitly rounding which had much better results as long as I was always pointing near the center of the ore vein.

Given that you know the underlying code that determines which texture is visible and what GetVoxelAt is doing, would you have any suggestions that would help me with this?

 

Sounds definitely possible. If I understand well, what you need is a heightmap generator for terrain geometry, and a script that would take some splatmaps as input and create some voxel types programmatically. You want a custom combiner that also takes some splatmaps as input and place voxel types consequently. This way, you could use your usual tools and then use the splatmaps to "feed" uTerrains.
Or maybe I missunderstood?

GetVoxelAt basically computes a single voxel at given voxel world position and returns it. It seems to me that you are using it correctly (since you round the position instead of truncating it ). No if all you need is to know which texture is used on a triangle (the triangle returned by Raycast), you can simply look at the vertices colors of the triangle (and vertex submesh index if you have multiple materials).
Does that answer your question?

 

Thanks lazygunn it's nice to have some encouragements

 

I think what you suggested kind of had it, I dont know if the functionality is already there, of a sort - use a heightmap to create vertical scales and use other such images to apply voxel types with no height information, they'd just 'overlay'. It seems like it would make sense to have this in a single generator with each height in the terrain being created by the heightmap value and the voxel type taken from a map that would usually be used as a splat to set voxel type up. I'm not sure if I'm explaining well or I should just bugger off and make it so, I'm just a bit slow when it comes to code

 

I just purchased this asset recently. So far I like what i see! Although I was wonder if anyone had any insight on how to build a selector that has support for more than just one above and one below water level. This has worked great so far but I would like to be able to have a few biomes above water level (flat land, hills, mountains, etc). I tried looking at the code for current selector scripts but I cant quite figure it out. Any help would be greatly appreciated!

 

After looking at the code it came to me quite quickly and I feel silly for asking without properly investigating, I haven't tried working with biome selectors yet but have found myself capable of using heightmaps and using maps a bit like splatmaps for them, only question I have regarding heightmaps is the 'stepping' effect which I got a lot of in world composer if I used an incorrect resolution heightmap, or didn't use a 16 bit map. Tested both these things with uterrains but can't figure it, just a case of experimenting I think though, if anyone wants beauty shots though, this thing will get you them

 

I wrote a load then for this post and then realised really just needs a few hints on how to tighten up the heightmap generator - I would do this myself but I've spent all night trying and it's a shortfall of my abilities rather than this package so I guess I could ask

If there could be tinkering with the heightmsp importer to make its contribution based on intended scale over 1 pixel meaning 1 voxel that would be great, once I can scale uterrains heightmaps to reflect real world sizes i can use data sources like openstreetmaps along with road/building tools on regular unity terrains confident that they will pass across accurately when I'm done with them. This could also help integrate with easyroads and megasplines directly if you can provide a few analogous functions through which they can do their usual terrain operations on yours

One other question is the stepping from the heightmaps, I'm assuming I'm using the wrong code in the combiner bit if it's file format relate d can you specify bitdepth and resolution requirements for the heightmap?

Once I get the hang of writing my own generators and combiners this will be a staple I think - also I might add I'm working specifically towards a mobile target. But it's for the gear vr so quite high spec, when I get chance to test (hardware isn't here yet) I can let you know how it goes if you wish

 

I bought this asset yesterday and so far I'm loving it, thanks for making this. A couple of things:

1) Are there any tutorials that I could look at to better get this working? I've read through your docs, loaded the example scenes and followed the getting started video but I'm still a little foggy. For example my terrain comes out very mountainous and I have no idea why or how to fix that.

2) In the current version (1.05f) my terrain and the underwater biome are generating weirdly when I set it up as in the video. The issue is that the underwater biome is not joined with the surface so I'm ending up with a surface terrain that floats over the underwater section. I've watched the video through a couple of times and made sure the settings are identical but I still get this strange terrain generation. What might I have done to mess this up so badly?

Thanks

 

Do you have an email that I can contact you directly at?

 

Is this for limited terrain or can be unlimited :/

 

Its pretty much unlimited, I'm sure there are some limitations, but land will indeed generate around you as you walk for some time. You can also set a max size if you did want limited.

 

Sorry for the late reply. I had a lot of work to do and the good news is that the new operation system is almost working.
Let me tell you more about this brand new system.

Why uTerrains needed a new operation system?

The current operation system works well but it has two big issues:

• it is very complicated to create operations that produce arbitrary shapes such as a tree or a building.
• it becomes slower and slower each time you perform more operations next to each others.

What the new operation system will offer?

The new operation system fixes the two issues of the current one, but it has a bit more constraints.

• it is easy to create operations that produce arbitrary shapes because you basically just have to fill a regular grid with the operation you want to do on each voxel.
  
• it is fast and it is not affected by the number of operations. For those who are used to algorithms, it's O(1).
• but you are limited to:
  
  • you can replace voxel value or increment voxel value
  • you can replace voxel type
  • you can act on a voxel without any condition, or only if voxel value is lower than or higher than operation value, which is equivalent to taking the Max/Min between voxel value and operation value.

The good news is that it's a lot more powerful. The bad news is that you'll have to adapt your custom operations (if you created any) to the new system.

I'll let you know when it's ready for production.

@Silvers @lazygunn
It's quite hard to answer without concrete examples, but the next thing I'm gonna do is adding more examples in uTerrains package.

This comes from the different parameters of the generation modules. Try changing the vertical scale for example. The best is to try changing a bit some parameters one after one and test to see the result.

Be sure to have the same frequency values between your two different biomes (in the generator modules).

Like @Khaotic said, it is unlimited. Well, to tell the truth, you'll be limited by max integer & float values, that's all.

 

More examples would be ideal! At the moment it seem's a very powerful system which is user friendly and I really want to use but find myself lost often. With a million other things to do I can't sit still messing with values and stop starting to see what works - efforts with height map import took a while and that probably would have been easy for you. But to me.. lost.

A simple example of what I'd love an idea how to do: generate a single island of variable size and predictably parameterized values to change its theme, biomes contained and so on. There we have a true Worms sequel right there. So many ideas on things to do but unsure how to integrate

Say I use a terrain created in unity/wm as a basis so I can produce a very much authored city area in 3ds max based off the height map - but when I want this to be places in uterrains which would be ideal, matching it all in position and scale has proven difficult for me. All I need though really is examples. It's crazy you produce such a powerful system then such scant examples - show it off!

 

I agree, examples are too limited and too simple. Ultimate Terrains has the power to do a lot more. This is why I really want to take some time for making new examples and improve existing ones. I wanted to finish the new operation system first, because I found it to be a true limitation for uTerrains users, but as soon as it will be done, I will focus on examples and tutorials.
And then, after that, I'll focus on a new details system. To give you an idea, that should be the next 3 releases:

1. new operation system + editor GUI improvements
2. new examples & generator modules & operations
3. new details system

 

Thanks for the news, looking forward to it!

 

I have a few questions about Ultimate Terrains, I am really interested in the potential of the system

1. Will there be stronger RTP3 integration? To take advantage of really beautiful terrains
-Mesh geometry blend


2. How many textures can one terrain utilize?

3. If there is a limit on amount of textures will there be an ability to create more than one terrain in a scene at a time and terrain stitching to create a bigger map?

4. What information or how would I output information to be able to create a representation on for example a server that could be used to determine collision with an object? For example making a server that can read maybe a simplified version of that map that can be used to define boundaries or areas that you would be able to access in a cave? I am mainly curious as what would be the most efficient way to calculate that information outside of unity.

 

Thanks for the reply - so far I haven't been able to get the under biome to connect to the surface biome but I'll play around with the settings and see what I can get working.

 

Probably, but it's hard to give you a date for that. Maybe some other uTerrains users are already working on this?

As it supports multiple materials, the answer is as many as you want. But remember that materials do not blend between each others unless you disable the "duplicate vertices" option.

For now you cannot make it work outside of Unity, but I will provide an API to be able to generate chunks and get their raw mesh data (ie. vertices and triangles) without using Unity at all. This is on the road map but you'll have to be patient because I already have many things to do before that

Could you send me a screenshot of your biomes (biome window)?