Ferr2D Terrain Tool

Hi, I am having an issue with lights in Ferr using vertex light: when a light source is close by a tinted fear surface, the light is too intensive, within a short distance it's too dark; a standard legacy vertex shader has a smoother reaction to light. Does anyone know how can I balance the shader reaction to light?

Edit - I start realizing the problem might be in the tessellation of Ferr mesh...

 

Yeah, the current version has some pretty long triangles that just don't work for vertex lighting. The next update will work just fine with it though =D (See http://forum.unity3d.com/threads/ferr2d-terrain-tool.204436/page-17#post-2113959) Vertex lighting is a much better solution than what I've got in there currently, so I'm looking forward to having that available for everyone~!

 

I've been trying to make a hard edged material, but it's quite the struggle to line it all up.

Do you think it's possible to create terrain like this with ferr2d, especially if I want the front side to be completely based on the fill, as I'll use a repeatable texture for it.



I feel like you need some padding on the edges that is overlapping the fill, to cover up edges.

For example, take the bottom left front corner, if I like my cap, it needs to be so precise otherwise there's some fill sticking out the back of it.

And when you fix one edge, the other gets issues, etc.


Am I missing a good workflow? or is it just generally hard to get this terrain to work with ferr. (or is ferr perhaps not suitable for this?)

 

It should indeed be quite possible! You'll have to be fairly precise to get it right, and might need some transparent parts on the side. You might also be a little locked into 90 degree corners too. I'll see if I can put together an example material when I get home today!

 

Let me start by saying that I (like everyone else here) am absolutely in love with this asset! Thank you thank you thank you!

I'm here because I was wondering if I could get some help with procedural mesh generation at runtime.

I did some digging in the code, but alas I'm not quite clever enough to figure it out.

Is there an example somewhere that I didn't see, or could you point me in the right direction of what and how I need to edit variables in the scripts exactly?

Thank you in advanced~!

 

@Sezerza: I'm actually doing some procedural mesh generation, and here's how I handle it:

Code (CSharp):

1.      
2.         void CreateIsland(List<Vector2> points, Component prefab)
3.         {
4.             // Object pool function to spawn a prefab instance - just a premade Ferr2D terrain game object.
5.             var instance = prefab.Spawn(Vector2.zero) as Transform;
6.  
7.             var path = instance.GetComponent<Ferr2D_Path>();
8.             var terrain = instance.GetComponent<Ferr2DT_PathTerrain>();
9.  
10.             // Randomize pixels per unit to create a little variance in the look.
11.             terrain.pixelsPerUnit *= Random.Range(0.9f, 1.1f);
12.  
13.             // Assign the previously created points (made by walking the borders of a randomly filled grid) to the Ferr2D_Path component.
14.             path.pathVerts = points;
15.  
16.             // Create vertex scales with random values for even more cool randomness.
17.             var vertScales = new List<float>();
18.             for(var i = 0; i <= points.Count; i++)
19.             {
20.                 vertScales.Add(Random.Range(0.85f, 1.35f));
21.             }
22.             terrain.vertScales = vertScales;
23.  
24.             // Tell the path to update its dependants, in this case the PathTerrain component.
25.             path.UpdateDependants(true);
26.  
27.             // Generate random colors for every vertex on the mesh using some Perlin noise (LibNoise)
28.             var colors = terrain.MeshFilter.mesh.colors;
29.             var verts = terrain.MeshFilter.mesh.vertices;
30.             for(var i = 0; i < colors.Length; i++)
31.             {
32.                 var color = new ColorHSV(((float)(noise.GetValue(verts[i]) + 1f) * 360f) % 360f, 0.2f, 1f);
33.                 colors[i] = color.ToColor();
34.             }
35.             terrain.MeshFilter.mesh.colors = colors;
36.  
37.         }
38.  

 

@luminance Ahhh, thank you so much! I was simply missing the UpdateDependents at the end of my test script. Seems to be working perfect now!

However, now I'm on to the next problem. How do I set what type of side a point is? (top, left, right, bottom) via script? I looked through and didn't see anything readily accessible to change them. Is this the tangent array of the mesh maybe?

 

@jerev, I made this with my current build, so the inner corners might be a bit tough to pull off right in the current builds. But the big trick here is the cap offsets, just set the cap offset for each side to -0.5! Everything else should pretty much be business as usual.

A few limitations there, the purple part there is the fill material, so it doesn't go the whole way up the edge everywhere. It's also only going to work well with right angles at the corners (may have limited success with angles in the body though!), since the cap offset makes it so there's zero overlap.



Here's the edge atlas I used for it. It could be a lot clearer, but it's a lot more straightforward when you're actually making it!



@Sezerza, the edge overrides are stored in Ferr2D_PathTerrain.directionOverrides, should be pretty easy~!

 

Ah of course, so blatantly named and I still overlooked it. Thank you!
However now that I'm playing with it (and trying to make all directions override to top by iterating through the array with a for loop, I get an error. (UnityException: You can generate UVs only for meshes with vertices inted.)
I have about 60 points, and looping through all gives me the error.

EDIT:
Seems that the issue is setting all points to Top makes her angry..? So just having 1 point be something else fixes it. Not a big deal for what I'm doing now, so just a heads up for anyone else trying to do that.

Also is there a way to make segments that do not have edge caps on them?

 

@koujaku, Thanks a lot for your time and effort in doing, proving this, and the tips.

I guess I'll just need to be smart about my textures for the right and bottom edges. The angles is not an issue as I was aiming for 90deg ones anyway.

Thanks again!

 

I too wish to use A* pathfinding in my project, but I don't understand where to put this code.

 

Just chiming in to say: keep up the great work! This package is wonderfully generic, and is still performing incredibly well in my game. Props for doing this, and I look forward to your package growing.

koujaku:
If sales are starting to stale out from your end, I think myself and others would be willing to throw in for addon packages, sort of like what's available for nGUI in order to keep development moving. With that said, if you ever go that route and throw out one of those lifetime subscriptions to all content, I'd pitch in in an instant.

 

Hi Koujaku,

Will there be any support for Bezier curves in the future? I am trying to get smooth collision, and the current implementation can produce quite rough surfaces.

I've hacked in support for the new 2D Edge Collider
Could you add this with Flags to Enable disable it to the next release?
It produces much smoother collisions.

Code (csharp):

1.  
2. //Added to Ferr2DT_PathTerrain.cs in RecreateCollider2D()
3.  
4. EdgeCollider2Dedge2D = GetComponent<EdgeCollider2D>();
5. if (edge2D == null)
6.  {
7. gameObject.AddComponent<EdgeCollider2D>();
8. edge2D = GetComponent<EdgeCollider2D>();
9.  }
10.  
11. List<List<Vector2>> segs = GetColliderVerts();
12. if (segs.Count > 1)
13.  {
14. List<Vector2> newVerticies = newList<Vector2>();
15.  
16. for (inti = 0; i < segs.Count; i++)
17.  {
18. for (intj = 0; j < segs[0].Count; j++)
19.  {
20. newVerticies.Add(segs[i][j]);
21.  }
22.  }
23.  
24. edge2D.points = newVerticies.ToArray();
25.  }
26. else
27.  {
28. List<Vector2> newVerticies = newList<Vector2>();
29. if (segs.Count > 0 && segs[0].Count > 0)
30.  {
31. for (inti = 0; i < segs.Count; i++)
32.  {
33. for (intj = 0; j < segs[0].Count; j++)
34.  {
35. newVerticies.Add(segs[i][j]);
36.  }
37.  }
38.  }
39.  
40. edge2D.points = newVerticies.ToArray();
41.  }
42.  

Thanks!

 

@Omi, thanks! I'm doing a couple other tools that will tie into Ferr2D, so no worries there =D If people are interested in creating additional addons, I've always been open to conversations about that~ Would love to see more Ferr2D stuff on the asset store!

@oneuglyrobot, thanks for sharing the code! I'm looking at adding a couple of the new collision features for the next update~ Also, are you using the "smooth path" option? Is that not working well enough for you? I'd love to know what the issue there was.

And I'm curious how many of you guys are using 4.x still? 4.3? I'm thinking it's probably too early to drop 4.6, but even if I can drop 4.3, it might be a nice improvement for meeee~

 

I'm trying to make a cave like game using your Unity 5-"beta package" in Unity 5.1.x. I'm using a closed terrain type and stuff is working out great at the beginning but when reaching around 50-60 vertices Unity freezes for 3-5 seconds each time and at 70-80 vertices those freeze times are 5-10 second and it just keeps getting worse and worse with freezing times over a minute eventually.

I'm using Smooth Path on the terrain if it makes any difference.

The question is if something is miss-calculating in the "beta package" making it freeze when having over 50 vertices, I really can't see that 50-60 vertices should be that extensive amount of vertices or is it?

 

@koujaku You can have a look at this topic here to look at the usage of Unity versions: http://forum.unity3d.com/threads/unity-version-usage-might-be-useful-for-package-devs.250891/

This might give an idea if you should support specific versions or not

 

@BTStone Wow, thanks for that link! Pretty surprising, but definitely useful =D

@Thoor, Shouldn't be that slow, does it do that for you in other versions? I haven't been able to open my development project in 5.1 yet, keeps crashing on load, and I haven't had the time to figure out why yet. That's on my list for this weekend though, so I may have a better idea then!

 

@koujaku With versions of Unity I can only speak for 5.0.x and there the problem were the same. In regards to Ferr2D versions I'm gonna try the Asset Store-version with Unity 4.6 this weekend to see if there's a difference. Thanks for the quick reply!

 

Please do not drop support for 4.6! My dev partner and I are using F2D as our primary terrain tool for our game, and we plan to stay with 4.6 for the next year or so until we complete our game. We'll share the details of the game when we go public with the project in the late fall/early winter. You will be excited! Thanks again for the world-class tool and support.

 

The issue was maybe more of a physics issue where a ball rolling down the slope would occasionally hit the 'edges' of the poly collider generated. I found with the edge collider it doesn't hit these edges.

 

@mrwogs, after seeing the graph @BTStone posted, I decided I'll just keep 4.3 support around for the time being. I don't remember any significant relevant improvements in 4.5 that would justify switching to that, and I'm not about to drop 20% of the user base jumping to 4.6! I did finally get rid of some lingering 4.2 code though =D (man, that felt good).

@oneuglyrobot Thanks! I'll try and keep an eye out for that then!

 

Hey! Still looking to try to get A* pathfinding in my project with Ferr. See my above post. Thanks a bunch!

 

@CSharpMin Heyas! Sorry, open up Ferr2DT_PathTerrain.cs, and look for these lines:

Code (csharp):

1. //sw.Stop();
2. //Debug.Log("Creating mesh took: " + sw.Elapsed.TotalMilliseconds + "ms");

You should find them at the end of the Build method, right before the GetMesh method. Add the code from the above post either immediately after, or immediately before those lines! Hopefully that helps =D

 

@koujaku I tried out my project in Unity 4.6 with the Asset Store Ferr2D-version and it worked like a charm so i guess the issue is with Unity 5.x and/or your Ferr2D-Unity-5-version. Not quite sure how this helps you out though Do you have en ETA on a final version for Unity 5, not sure if I should revert to Unity 4 or wait for a final version for Unity 5.

 

Hi, anybody knows why, when I use a Ferr2d shader on a sprite and I prefab the sprite, the prefab preview is empty?

 

So the ETA on 1.0.9 is actually... today! It went live overnight, and it's featured in the I Love 2D sale! (they finally convinced me to give the sales a try~) I'll write a more detailed post later today, but it's been a long night for me already. So enjoy, let me know what you think, and if you have any trouble with it! =D

@Alessandro.Previti, what versions of Unity/Ferr2D are you using? Any error messages in the console? I'll dig deeper this evening as well =D

 

New version! \o/ <---(happy me with arms raised up)
That is awesome, going to download it now!
Koujaku, I updated with a version you sent me not long time ago, I receive no errors, it doesn't even show me the cube icon, just an empty preview, if I switch to default sprite shader I get a proper preview.

 

I installed the update, I receive a gazillion of errors, my project imploded.. what..the..
Edit:
I deleted all the fear files and reinstalled, after the third time everything worked fine, most probably not a Ferr issue but Unity magic.

 

Hello,
I tested the new version.
Just a little problem, 2d physical material seems to be not apply.

No other problem for now.

Thanks for this update

 

So with this version, you'll definitely want to delete the old Ferr folder before installing. It -should- run even so, but the handle images end up in the wrong folder and don't display correctly. I wouldn't be surprised to see other issues related to upgrading without deleting crop up too. Other than that, should be great, everything is still backwards compatible and all that =D

@RedDuck, Hmm, I'll take a look a that this evening! You can also add a collider to the terrain, and Ferr2D will use the one you've added instead of generating its own. Might behave a little better?

 

Yes it's working when i created one polygon collider manually. Strange ...
Thanks.

 

Hi Koujaku. This might be a strange question and I'm not sure if this could be can be useful to anyone but me. I was wondering if there is a way to turn a terrain into a sprite... I wouldn't know where to start with this, but it could be useful for manipulating the terrain (and maybe for prefabs). I recently saw this asset: https://www.assetstore.unity3d.com/en/#!/content/18125 and the terrain destruction would be a great feature to include in some games. In any case, hope you are well and I'm keep up with this great tool.
Tahnks!!

 

I actually looked into this briefly a while back, but ultimately, Ferr2D will never work with that plugin, sorry! They're two very different systems, and memory cost for converting Ferr2D objects to sprites would be completely insane~ I do however have some destructible stuff in the works! Not terribly soon, but eventually for sure.

 

Yes, I thought so... hopefully you can come up with a good solution. I think it will make this asset even more incredible.

Other thing, I'm wondering if it would be too hard to implement multiple edit of terrains (when you select more than one in the hierarchy to be able to change properties of all the terrains at the same time) I don't know if this is just me but I tend to use many "Islands" and to experiment with tint, shaders, shape, but this would be specially useful for offsets. Maybe is just me and is no big deal, but it could be nice if it's not too hard to implement.
Thanks Again!

 

Hi again! I wanted to ask another thing. I've been trying to use particles to simulate weather, and I want to create a rain effect. The problem is that unity does not supper 2d particles physics (particles won't collide with 2d coliders) I was wondering if there is a quick and dirty way to generate both, 2d and 3d colliders (maybe a low-res collider to improve performance?). This may not be very useful for anyone else (and hopefully unity will add support to 2d particles collisions) but if is not very hard I would like to know which would be the best way to implement this.

Thanks once more!

 

I've been wanting to add multi-terrain edit to Ferr2D, but it's never been up high enough on my list. It is on my list though =D

It's not hard to get Ferr2D to try and generate both 2D and 3D colliders, but Unity won't allow both on the same GameObject. You'd basically have to generate child GameObjects for the 2D and 3D colliders in the RecreateCollider methods, and attach to those instead.

 

@koujaku I'm having some trouble with the edge direction overrides. It doesn't look like you can add an override for the last point in a path. Is there some technical reason for this? I'm attempting to override the direction for my levels because they're composed of multiple terrains lined up together, like so:

 

Ohhh, man. That's a bug that's so old, it never made it onto my Trello board! Well, it's certainly there now!

With path stuff, the closing segment is always a big source of pain o_- I'll check and see if I can find an easy solution in the near future, but in the meantime, you can usually shift the path around to a point where it's generally not an issue. Sorry about that one!

 

Argh. I just updated/imported 1.0.9 into my project and it gave me a bunch of errors.
I do have the Puppet2D Plugin in that very project and there are apparently some namespace/classname issues:

 

Hmm, seems we both use poly2tri for triangulation! Hopefully they're the same version o.o Just delete poly2tri from one of the plugins, and it should be alright? If deleting from one still throws poly2tri related errors, try deleting it from the other. And if neither of those work, let me know!

In Ferr2D the folder is:
Ferr/2D/Scripts/poly2tri.cs

It looks like in Puppet2D, that folder may be:
Puppet2D/Scripts/Triangulation

 

I deleted it from Ferr2D. Terrains are displayed right and I can edit them the way I want to. For now everything seems to work. Just out of curiosity - what should happen if it's wrong?

 

No worries. Unfortunately it might be a bit tricky to shift the path around on the fly because I'm procedurally generating all my terrains, but I can always fall back on that at some point.

 

Another thing: When I use a Terrain and check "Create Collider" and add nodes to the terrain the Collider doesn't update with the form of the Terrain. It updates it's form when I unselect and select it again.
And this seems not to be an issue of the deleted scripts (poly2tri) since I tested it also in a new empty project with only Ferr2D imported.

(I also wrote you a mail Nick with another small issue! )

 

@koujaku I'm creating lots of terrains on the fly, and I'm wondering about how to optimize the mesh building process, or perhaps time-slice or offload it somehow (though I don't think much can be done there). Splitting terrain up into multiple smaller chunks is probably the best bet, but I'd like to get your thoughts.

 

@luminance, stick to as few verts as possible! A bunch of smaller objects should be much faster than one large one for sure. Also, avoid features like path smoothing and the new fill verts stuff, as both can add in a significant number of extra verts. If you must use smoothing, reduce the quality of it as far as you can! I also feel like LibTessDotNet was faster, or at the very least, lighter on memory allocations, so it might be worth considering switching back to that as a very last resort.

Yeah, that does make it tricky with procedural o_- I'll have to focus more on procedural next version for sure!

@BTStone, huh! I'll have to check for that collider thing. Is that happening 100% of the time for you?
Also, my major concern with poly2tri conflicts would be different versions, or custom modifications. poly2tri looked to be fairly stable as far as versions go, and I don't have any modifications to it. And you would -probably- know right away if there was a problem, compiler errors or whatnot, so you should be just fine. If it -is- a different version, you might get different performance during terrain creation, but that's probably the worst you might see =D

 

Yep, as for now it happens 100%

Ah, I see. No, Unity didn't throw any errors. But I'll keep an eye on that.

 

@koujaku, thanks so much for your help so far. I've added the code as you've suggested, I'm still trying to get Ferr2D working with A* pathfinding project. Looking at previous posts, I'm not sure my problems are the same as @Jossesito experienced. I'll describe my situation in detail, and hopefully you can help me localize the problem.

I'm making a 2.5D game where X is Left/Right and Y is Up/Down. The Z stays at 0 for gameplay elements, including the main Ferr2D which has a 3D collider.

The problem is when I create an A* grid, it completely ignores the colliders from Ferr2D, making all ferr2d objects walkable nodes. Even when I force A* to rescan during gameplay, it still ignores Ferr2D colliders. Any idea what I might be missing? Is it even possible to register collisions with Ferr2d meshes using A* pathfinding project (the free version)? Maybe it requires the paid version of pathfinding project, and that is how Koujaku got it to work.

I could draw box colliders around the Ferr2d terrain elements, specifically for A* use. But it kind of defeats the purpose of having the great built-in colliders from Ferr2d.

I have no problem creating objects with box colliders that work, so I'm pretty sure, I have my grid set up correctly in A*.

Any ideas?

 

Whats the feature list for 1.0.9?

 

Hello, I need to paint vertex colors on a Ferr shape, anyone knows how could I do that, if not vertex, at least per fear point?

 

Here's the final changelist for 1.0.9

+Terrain
-Added inner elbow caps (uncheck simple in material editor)
-Added split fill feature, which adds verts to enable vertex lighting and vertex painting
-Added EdgeCollider2D support
-Added UsedByEffector toggle
-Colliders will now update with the terrain whenever a collider is present
+Shaders
-Added lit wavy shader
-Updated shaders for Unity 5
+General
-Ferr2D is now directory independant
-Improved handle control and performance
-Switched triangulation library to poly2tri
-Removed legacy code for Unity < v4.3
-Removed JSON support
-Updated FerrCommon
+Bug fixes
-Fixed component tracker occasionally collecting duplicate items
-Fixed a bug where empty edge materials would occasionally cause crashes
-Fixed a bug with snap settings going crazy on first time use

Big features I'd like to highlight are the split fill feature and the inner elbow caps! The split fill will allow for vertex lighting, which should be -way- nicer, since you can have 8 dynamic lights in your scene, they're fast, and you can use Unity's standard vertex-lit shaders! It will also give the brave some room for vertex painting, if they've got a tool for that, but currently, Ferr2D doesn't preserve color when the terrain is modified (that's coming in the next version!)



And inner elbows at long last! This has been on my list for quite a while, and I accidentally released it a little early during the beta. Evidently it wasn't as hard to implement as I thought it would be, so I just added it in oficially! I really need to put together some better art for this feature (I'll try to get some good ones for you guys next version =D), but here's a few samples of things you can do with the inner elbows~ You can find them by un-checking simple in the terrain material editor!



Also may start working on a FAQ or something. Probably well past due for that. And I'll try and get around to a video sometime soon for these features, but I may be stretching myself a little thin, we'll see =D

I do have plans for creating a separate asset that does a whole pile of vertex light baking stuff, so that'll integrate quite well with Ferr2D (and SuperCube), allowing for -huge- numbers of lights in your scene, which will be pretty darned exciting =D That's probably the next asset you'll see published from me. It's either that, or my vertex painting tool! Not 100% sure yet.