◆◄ 2.5D Terrain (3D mesh from 2D curves) ►◆

Hi all,
I have just relased my asset which helps you spice up 2.5D games with some sweet 3D terrain.

Asset Store | Manual



How does it work?
Easy: you draw a 2D shape and from it this tool generates a 3D mesh and PolygonCollider2D for you. Best just watch the video

Features:
● 3D Mesh from 2D Splines (with holes)
● 2D Collider Generator
● Procedural Foliage Generator
● Full Source Code included









Link: Asset Store | Manual

In case you wonder what you can do with it. Pretty much all the levels in this game (forum link) have been made using this tool.

 

hi, I purchased the asset 2.5D Terrain you developed.
There are amazing ideas for 2d and 2.5d game scenarios, and I'm having some trouble. Since I'm using a vertex-shaded shader, I want the model to generate a higher number of uniform meshes. This way I was able to do vertex painting.
Whether in the new development plan, it is possible to adjust the parameters of the number of generated model meshes in the three axes of xyz.
Figure 2 below is the effect diagram of the expected grid generated by me.

 

Hi,
thank you for using the terrain tool. I see so you want to have a mesh with uniformly distributed vertices to get some higher "resolution" for vertex painting. It's an interesting idea yet at the moment it's not easy to do as the tool right now does try to do quite the opposite (reduce vertices as best it can). Also you would run into trouble quickly with areas of high curvature. No quick feature I am afraid. I am currently busy with other stuff but I'll put it on my "things to think about" list, no promises though.

However, it should be possible to do even with the current tool. From the top of my head here is how I would approach a quick solution: The asset already has the ability to add custom vertices (it's described in the manual). You could absue this and just add a ton of them via code to increase resolution. So the steps would be:
1) Generate the mesh as you are doing now.
2) Generate a 3D mesh collider from the mesh.
3) Do some raycasts in a regular grid from every side and record the hit positions.
4) Add each recorded position as a custom vertex.
5) Generate again.

I think that should work, though I am not sure how performant that will be.

 

thanks geo
Yes, the vertex shader needs more points of "resolution".
I will try the method you said, but my code level is very low. It can be very expensive to add points one by one.
However, I think that if you can increase the grid distribution, it is also a way to expand the various requirements of the generative model. It would be really great to have these parameters. More meshes means that you can do a lot of terrain height changes and adjustments, which is a very efficient way to build levels.

 

I think adding the points won't be the main problem (it's just a list) but am just not sure how the clipper and tesselation libs will handle this many internal points (not something I have testes). I also noticed the points method will only work for the sides. The middle part is not effected by that but it can be changed via code too.

Look into MeshMiddleSegment.cs. There you will find 4 points (p0 to p3). In between those 4 points two triangles (tri1 and tri2) are made. There you can add as many tris betwen those 4 points as you want. This would be an easy way to increase the middle resolution. The sides may be tricky though (there you would need the points I mentioned).

Here is a quick sketch showing what I mean (you could increase the subdivision of these middle patches in MeshMiddleSegment.cs). The middle is just an endless loop of these p0-p3 quads.


Hope this helps.

 

sorry i'm here again
Yes, I would like to increase the amount in the middle of the mesh, so that I can freely make various changes to the ground vertices.
I've tried to understand this part of the generative and cyclic process, and I admit I've failed, not knowing enough about this part.
Modified the number of segments, etc., resulting in an array error, etc.

 

Hi,
I have been able to take a quick look. Here is a version which at least allows you to increase the middle resolution on the z-axis. There is no UI so you will have to just change it in code, like this:



Just replace the file with the one I attached and change the zDivisions parameter.

Hope this helps
Anything more elaborate would require more time and I can't do it right now (sry).

 

Thank you very much for the help of geo. This terrain plug-in is the best one for 2.5D in my opinion. I will study and add an adjustable parameter of zDivisions to the interface. Go and understand your improved code writing.
Now the resolution can basically be adjusted to a suitable distribution. ^-^

 

_geo__ Hello, forgive me for asking again. The zDivisions parameter can increase the free editing of the vertex resolution requirements. Can the zDivisions parameter be added to the Terrain25D interface and become an adjustable parameter?

 

Hi,
I have just submitted a new version which includes this feature. I will be available withing the next couple days depending on how quick the Unity reviewers are

I have also found a small bug in the script I posted previously. It's now updated.

 

Cool,I'll test it right away!

 

When I was using ordinary uv, I found that the sampling distance of the latter segment was stretched, maybe it was my operation problem? Can _geo__ verify it?

 

From what I see the part that is streched is not the middle segment but a front or back segment. Those always have their UVs projected along the z-axis. That's why it looks streched.

While making the tool I had to decide whether to strech the UVs to keep them seamless or to implement a (surely flawed) alogrithm to assign UVs even to curved curfaces (that's called unwrapping). I decided to prefer seamlessness over streching (so they are seamless but they do strech). This usually works fine if the bevels are sufficiently tilted. In your case they are very flat and thus the streching is very visible.

I know that does not help you much and I am sorry. My recommendation would be to reduce the "bevel widths" and instead increase the middle width. That way the effect if much less visible.

Maybe I can improve that in future versions but I am not sure when or if I will get to that.

Here is an illustration of how it works:


What you can do is to change the axis of projection from z to y in MeshFrontSegment.cs like this (~ line 250):

Code (CSharp):

1. // Change these lines:
2. /*
3. uvPoint03D = this.transform.TransformPoint(new Vector3(p0.x, p0.y, 0));
4. uvPoint13D = this.transform.TransformPoint(new Vector3(p1.x, p1.y, 0));
5. uvPoint23D = this.transform.TransformPoint(new Vector3(p2.x, p2.y, 0));
6. */
7.  
8. // to this. This now projects from y axis instead of z.
9. uvPoint03D = this.transform.TransformPoint(new Vector3(p0.x, p0.z, 0));
10. uvPoint13D = this.transform.TransformPoint(new Vector3(p1.x, p1.z, 0));
11. uvPoint23D = this.transform.TransformPoint(new Vector3(p2.x, p2.z, 0));

That will give you this result:

As you can see this will fix it if viewed from the top but messes up the sides. If you are only interested in the top view then it may be a usable fix.

I hope this helps.

 

Well, I understand.
But let me show you the parameters. I am currently using the middle section to increase the width, and the front and rear sections are closed. But 1 grid behind the middle section, this grid will have uv stretching. Do you see any problem with this?

 

Hm, okay, that looks like a bug. I'll check it.

UPDATE: Okay there indeed was an error in the code. I had to fix a little more than expected.
Here is how the fixed version looks like. Notice that the tiling starts at the front and ends at the back for irregular middle widths. In previous versions the behaviour was undefined so it may have looked differently.



I have attached the patched Middle Segment class. The update is now in review. Thank you for reporting this

 

hi _geo__, nice weekend
Looking great so far! The irregular middle width doesn't seem to be a problem, I will try to test to see if there are other problems.

 

UPDATE v1.3.0
* I've finally added 3D Collider support (should be available in a couple of days)

Asset Store | Manual

How to generate a 3D Mesh Collider?

Since we need a 3D mesh BEFORE we can create a 3D Mesh collider we have to wait for the
MeshGenerator to generate one for us. That’s why the 3D collider options are part of the Mesh
Generator, not the Collider Generator.

If you enable the „Add 3D Collider “ option on the Mesh Generator (scroll way down) then you
will get a 3D collider based on the 3D mesh.



Enjoy

 

Hi _geo__. Long time no see, old friend
I think I have some new ideas, because for our 2D terrain, it is likely that we need some occlusion effects such as rocks, mountains, and plants on the edge of the terrain to form a better visual depth of field experience.
Is it possible to randomly generate various elements on both sides of the middle curve, similar to these plug-ins, which can randomly generate various elements, such as rocks, mountains, and trees, at the edges of the terrain. In this way, the curved terrain can be quickly derived, and at the same time, it can also modify the rocks on the edge of the terrain, or other random elements, enriching the visual effect and natural feeling.
This is a small suggestion from me. I wonder if you are interested or might try this random element generation function?

I want to buy your 2.5D bike racing & character template with ragdoll physics and prepare to try some other physics tests

 

Hi,
I think the rocks should be doable with the current Foliage generator already (random spread).

I don't think something as regular as the poles are doable out of the box since the placement of objects is based on random rays.

However I have quickly done a test with a randomness slider.

You can download it here if you want to give it a try:
https://kamgam.com/unity/2.5DTerrain-v1.3.0-foliage-randomness.unitypackage

Here is a quick setup I tried for the poles (notice the "randomness" slider is set to 0).


If you increase the randomness a bit you will get a blend between the ordered and the (old) random behaviour:





Please let me know if this worked for you. If yes then I'll ship it with the next update.

How to use the foliage generator is described in the Manual here: https://kamgam.com/unity/2.5DTerrainManual.pdf

 

_geo__ Great!
I will update the version of unity, wait a moment to test it, and try to see the parameters.
I think this way, when making some horizontal platform games, it is easy to generate various effects of depth of field vision and occlusion functions, because our terrain system is mainly developed for 2D and 2.5 users.

 

I tested it, and there are some doubts about the parameters
In the Generate Single Set: panel, Middle Delta Front moves towards the Z axis. When I adjust the value, the element will move from the edge to the center line. When it is close to the center line, the element will disappear completely. When the value is larger, it will Appears again, as if there is an isolation zone around the center line unable to generate elements?

 

Hi,
yes I admit the foliage parameters take a bit getting used to.

By default the objects are not place in the middle (around z=0). To place them in the middle too enable this option:


By default the middle is a wide as you have configured it in the MeshGenerator (front + back = total middle width):


So by default no objects are placed between z = -1f and Z = 1f. You can turn this off with the "Place in Middle" OR you can define an overlap the allows objects to partially move into the middle. This you can do with this:


The middle front and back delta are added as they are to the z position of the objects so "back" should be negative and front should be positive if you want to push them outwards, like this:



There are limits for how far the objects will be place in Z +/-. These are configured with these:

I have set them to 100 which has the same effect as disabling the limits.

I will have to add a section on this to the manual as even I myself get confused at times after not using it for a while.
Hope this helps.

 

UPDATE: I have now updated the manual with how the foliage generator will work in the next update. I have removed the "Depth Limit Front/Back" and replaced them with a split version of the "Middle Width Overlap".

The Manual now also describes all the "Spread" parameter with images.

Newest patch:
https://kamgam.com/unity/2.5DTerrain-v1.3.0-foliage.unitypackage

 

Got it sir! Now that I roughly understand the role of these parameters, very perfect element generation, including density, spacing and arrangement.
When I was testing some vegetation or different rocks, I guessed whether some self-space changes could be realized. In addition to the size and volume changes of the elements themselves, a restriction on the three axes of the proportion of the element's own space could be added, so that Different forms of rocks are produced. There is also the axis of rotation. I see that there are Rot Y Variance In Deg and Rot Z Variance In Deg, but it seems that Rot x Variance In Deg is missing.
For example, I will give you a screenshot of this part of the parameters in the picture below. If there are some adjustable changes in the element's own space, then the effects of rocks and various irregularly arranged ruins can be presented naturally.
I think after almost these implementations, basically all the required basic variables should be satisfied.

 

New patch (apply over the previous one) ;-)
https://kamgam.com/unity/2.5DTerrain-v1.4.0-foliage.unitypackage

 

When I was testing the Middle Width Overlap Front variable today, I was unable to achieve the desired movement of the Middle Delta Front. I could offset the generated element along the Z axis and move it from the front to the back for generation. However, I currently tested the maximum value of 30. It can't produce any changes. Is it my fault?

 

Hi,
overlap is meassured RELATIVE to the center point (z = 0), so - is outwards for both, + is inwards for both. This is due to historic reasons. This parameter was initially intended to allow a little overlap into the middle. Now it can also take negative values to push things out.

I think maybe you have pushed the front part to the back with +30 which would not make sense to the tool. Maybe I should clamp that to middle width.

I have added a graphic on this to the manual:


To be honest, I am still contemplating the naming of the settings here as I myself find them not very intuitive, yet I have not yet come up with a better one. + I don't want to change it now to retain backwards compatibility.

Hope this helps.

 

Yes, I also understand what you mean about the Middle Width Overlap variable. I could use Middle Delta to move along the Z axis to the back limit edge until it disappears. The advantage of this is that I can let the Trees1 layer generate a range of 1 Rocks, and then let the Trees2 layer generate vegetation of range 2. This is a great parameter for various range generation ideas like this. Not sure if it can be retained or adjusted?

 

I see, hm, maybe I should add a front/back/both option to allow chosing where to generate. That way you could easily make as many sets as you want for one side only.

I think I'll also bump the limit (30) to maybe 100 for the overlap.

 

That's right, because of different scene styles and the depth of field of the far and near Z-axis lenses, we may need to generate different elements at different positions and ranges on different layers. Although the Middle Width Overlap value is 30, the upper limit of element movement is OK 100% reach the other side, or even disappear. I think it will be easy to adjust.

 

hi _geo__ We're generating elements, are we making any progress?

 

Hi, at the moment I have not scheduled any update work on the terrain generator as I usually wait a bit for multiple reuqests to accumulate (sorry).

I think you should be able to emulate the behaviour of front and back options by setting the depth limits accordingly. That way no prefabs will spawn if the limit is below the starting depth (if that's what you want).

Hope this helps

 

hi _geo__. Okay, I will try the depth limit method and hope that subsequent functions will be more convenient and perfect.