Ferr2D Terrain Tool

Are your objects overlapping? If so, try shifting the z-value of your duplicates. If that's not it, could you elaborate a little more?

 

Is this going to replace the vertex color tinting that comes with the asset by now?

 

After changing that line in Ferr2DTCommon.cginc I didn't notice any change. What's supposed to change?, when changing the vertex color it still tints the terrain instead of applyind a solid color on top to simulate fog.
By the way, the terrain works fine with fog! but I would love to have that control too, because I have a huge scene and I have fog, it works great with far terrain, but I would love to override it by coloring myself some terrains that are near the camera.
THANKS!

 

I have a problem with my inverted closed mesh:

[[[
Ferr2D_PathEditor:UpdateDependentsSmart(Ferr2D_Path, Boolean, Boolean) (at Assets/Ferr/2D/Editor/Ferr2D_PathEditor.cs:256)
Ferr2D_PathEditor:OnSceneGUI() (at Assets/Ferr/2D/Editor/Ferr2D_PathEditor.cs:189)
UnityEngine.GUIUtilityrocessEvent(Int32, IntPtr)

Mesh.uv is out of bounds. The supplied array needs to be the same size as the Mesh.vertices array.
UnityEngine.Mesh:set_uv(Vector2[])
Ferr2D_DynamicMesh:Build(Mesh&, Boolean) (at Assets/Ferr/2D/Scripts/Ferr2D_DynamicMesh.cs:71)
Ferr2DT_PathTerrain:Build(Boolean) (at Assets/Ferr/2DTerrain/Scripts/Ferr2DT_PathTerrain.cs:334)
Ferr2D_Path:UpdateDependants(Boolean) (at Assets/Ferr/2D/Scripts/Ferr2D_Path.cs:55)
Ferr2D_PathEditor:UpdateDependentsSmart(Ferr2D_Path, Boolean, Boolean) (at Assets/Ferr/2D/Editor/Ferr2D_PathEditor.cs:256)
Ferr2D_PathEditor:OnSceneGUI() (at Assets/Ferr/2D/Editor/Ferr2D_PathEditor.cs:189)
UnityEngine.GUIUtilityrocessEvent(Int32, IntPtr)

Failed setting triangles. Some indices are referencing out of bounds vertices. IndexCount: 68946, VertexCount: 0
UnityEngine.Mesh:set_triangles(Int32[])
Ferr2D_DynamicMesh:Build(Mesh&, Boolean) (at Assets/Ferr/2D/Scripts/Ferr2D_DynamicMesh.cs:72)
Ferr2DT_PathTerrain:Build(Boolean) (at Assets/Ferr/2DTerrain/Scripts/Ferr2DT_PathTerrain.cs:334)
Ferr2D_Path:UpdateDependants(Boolean) (at Assets/Ferr/2D/Scripts/Ferr2D_Path.cs:55)
Ferr2D_PathEditor:UpdateDependentsSmart(Ferr2D_Path, Boolean, Boolean) (at Assets/Ferr/2D/Editor/Ferr2D_PathEditor.cs:256)
Ferr2D_PathEditor:OnSceneGUI() (at Assets/Ferr/2D/Editor/Ferr2D_PathEditor.cs:189)
UnityEngine.GUIUtilityrocessEvent(Int32, IntPtr)

]]]

Is it really a limitation for my level/mesh? It's not ever as big as I wanted to...
Any ways to avoid this for closed inverted mesh? Can I split it with Ferr2d tools?

Step1 (before error):

Step 2 (an error):

 

You may need to re-import the shaders for this to update properly, but I double checked the change, and it'll do what you're looking for But yes, it does replace the tinting functionality, to do both at the same time, you'll need slightly more extensive changes.

 

Yeah, this is a Unity limitation, no meshes over 64k verts! You could change the spacing of the Split Fill option, space the verts out further, or you could manually set the Invert Fill Border so the edges don't go out as far, both of those will drop your vert count quite nicely!

I also don't generally use inverted fill for large environments either. A better solution is to use chunks of regular terrain objects, with decoration objects or something else to cover seams. This is actually much better for Unity, as it creates smaller, more performant colliders, and discards a lot more offscreen verts!

 

Hi!, there is something that is bugging me over Ferr2D, don't know if it's a bug or not. But I have a Terrain Material that, don't know why, it loses the reference to the fill material, like almost every 15 minutes. So I click a Ferr2D Terrain made with that Terrain Material and the fill is gone and I have to link it again and then edit the Ferr2D Terrain to have the fill from "none" to "closed" again, over and over.
Why is this happening?

Thanks!

 

Hey @Lars-Steenhoff , did you solve this in the end? I've been grappling with this for a couple of hours and it's driving me insane. I can't even find patterns to it so I can't narrow down a cause! I tweak z-positions and z-offsets off various things, and they appear fixed for a bit, but then break again. Sometimes it happens when things overlap, sometimes when the don't. I've got two materials that both do this, but when I switch one to the other, it seems to fix it, in both cases, but then they're the wrong materials!

I don't know if this is a bug, or something I just need to do differently with the new updated materials. I've used Ferr2D for a couple of years and never experienced this until updating. Any help would be super appreciated!

 

@koujaku It's just occurred to me I can share a unitypackage. I hope it replicates the issue on your end! Here's the link: https://drive.google.com/drive/folders/0B0lkBhU8VzuCaXZjSE45RWc2Smc?usp=sharing

 

Thanks for the package! This definitely helps pinpoint things

Here's a little primer on Sorting and Transparency!

So first things first! When using transparent materials, (as you are, and I do recommend you use opaque materials on the fill material for reducing overdraw and increasing performance) Unity sorts from back to front, and relies entirely on sort order for everything! Nothing is written to the z-buffer, since you can't with transparent objects. This can lead to flickering and incorrect order artifacts when sorting just isn't enough!

The problem is that sort order is based completely on the distance from the camera to the origin of the GameObject! There's two different methods for calculating this distance, one is the perspective method, straight up 3D distance, and the other is orthographic distance, or distance along the camera's view axis (In most 2D contexts, this is simple distance along the Z axis). The editor always uses perspective sorting, and you'll see a lot of popping in the editor that you won't see in-game! And that's because Ferr2D forces orthographic sorting, regardless of what camera type you're using!

The issue with perspective sorting in this case, is that distance from the GameObject origin is not a good approximate on large complex objects, like Ferr2D terrain objects. Ex: A camera at (x:0,z:-10) 2 objects at z: 0, a large terrain at x: 4, and a character at x: 2. The character sorts as closer to the camera. But if the player moves to x: 6, the terrain now sorts as closer! Clearly incorrect in a standard 2D context, and this is why you see lots of flickering in the editor.



Using orthographic sort solves this problem, but now there's another problem! Everything at z: 0 has the same distance, how do you sort that? Unity typically solves this by using the Order in Layer property, but if you haven't changed that, then it's undefined what order things get drawn in. Personally, I will nudge things on the Z axis to get the sort order that I want, since this is much easier to visualize in the editor. It's easier to look at the scene in 3D rather than checking every object's Order in Layer property.

I'm uncertain why you're seeing this issue now and not earlier! Perhaps Unity changed their sorting algorithms recently, or perhaps you've been getting lucky? Maybe something I changed made z-artifacts more obvious? Either way, I was able to eliminate flickering from the scene using the techniques mentioned above. I definitely recommend checking your scene in 3D, float around to the side and check your Fill Z Offsets! You've got half of 'em negative, and half of 'em positive. In your case, I'd probably recommend 0.05.

Hope that helps!

And @Shigam, I haven't seen that problem before! Have you got any error messages accompanying it, or other details?

 

I have my unity editor set for Metal rendering, it may be a bug in metal, because the issue also happens when I exported to apple tv on metal.

so its not only an editor issue.

And the strane thing is that if i make a couple of ferr objects from the menu, just new ones they dont have the flickering issue.

only duplicates.

I see some release notes for unity beta 3
that mention z fighting fixes on metal.

https://unity3d.com/unity/beta/unity2017.3.0b2

 

Hi @koujaku ! Thanks for the quick and very informative response!

Interestingly, as soon as I switched the fill texture to Ferr/Common/Unlit Textured Vertex Color, all flickering instantly disappeared and has not returned! Unfortunately thought this means I don't have Draw Order anymore ("Layer properties won't work properly unless your shaders are all 'transparent"), which our game relies on heavily. Is this an either-or situation? I know I can arrange things on the Z, as you mentioned, but we're attempting to use parallax camera (I say attempting as we've seen a few hurdles already!), so would like to avoid extra z-distance if possible.

Thank you

 

Hey @Lars-Steenhoff , I don't know if you got any further with this, but I'm still struggling through it! Like you, I found that if I created a new terrain it works fine, but if I duplicate it, then the flickering starts. It all still seems to be very random though, as I was able to seemingly fix it only to find it broken again the next time I opened Unity.

I seemed to be in a situation where either:
1) Ferr2D was going to flicker, changing z-positions wouldn't fix that, BUT Draw Order worked

(Both shaders set to a Transparent one)​

2) Ferr2D wouldn't flicker if the z-positions were carefully set BUT Draw Order is broken

(Edge shader set to a Transparent one, Fill a non-Transparent one)​

This is a change that seems to have happened in Unity between 5.3.3 and 2017.1, as our project works fine in the old Unity with an old version of Ferr2D, but as soon as we open the project into 2017.1, the flickering starts. Updating Ferr2D didn't fix this.

Now, I know naff all about shaders, I'm a non-technical 2D artist, but since it seemed to be a shader issue I've been trying lots of combinations, and I've finally found one that works for me:
Edges - 2D Terrain/Unlit/Textured Vertex Color Transparent
Fill - 2D Terrain/Unlit/Tinted Textured Vertex Color Transparent
(This solution is perhaps inefficient as it requires fills to be set to Transparent, but it's the only way I could find to eliminate flickering while keeping Draw Order).

Sidenote: @koujaku , is there any documentation about which shaders to use in which situations?
2D Terrain/Unlit/Textured Vertex Color Transparent
Common/Unlit Transparent Textured Vertex Color
These are the same words in a different order but I see their code is quite different!

 

Any way to easily lock everything to right angles while creating the terrain?

 

Hello !
I have realized that the ferr2d Terrains take up a lot of space within our scenes (a 5MB scene goes down to 2-3MB without the ferrs), and I'm guessing that this is due to the mesh information...
Is there a way not to store the mesh information in the scene, and to have it generated on scene start ? we have over 70 levels, and would be able to save a lot of space on the build that way.

 

@koujaku just a quick question. Ferr2D is supporting consoles?

We are considering to bring a game made for Steam, IOS and Android to console. The mentioned game is using Ferr2D, will it be compatible with consoles platforms ( PS4, PSVita, XOne, Switch...) ?

 

@aeonphyxius No aparent reason it shouldn't work on consoles. That being said I can confirm it works on PS4 and PS Vita, although you have to slightly edit the Ferr2D shaders for the PS4, if you want to use these shaders.

 

That z-order thing is a little perplexing, I can certainly get around it with some of the tricks I mentioned, but it does kinda look like the recent Unity versions may have changed something subtle too! I'll definitely be looking more closely at this.

You can hold down Ctrl while moving verts for grid snapping, or you can turn on Smart Snap in the scene top bar to get them to automatically line up with eachother

If you add a call to Build() in the Awake function of Ferr2DT_PathTerrain, you should theoretically be able to empty out the mesh from the MeshFilter component! You'll have to empty that out anytime you make an edit, as editing will rebuild the mesh again, but you might be able to write a script to make that a bit easier.

 

Hi!
I have a problem that don't know why it happens. But my terrains are constantly losing the reference to the fill material and I have to always re add the fill material to the terrain, and then put the terrain type to close again in the inspector. Why is this happening?
Thanks!

 

Is it possible to add a separate physics material for walls? This would be a huge thing for people using 2D physics, (character getting stuck to walls if friction isn't set to 0).
ps. You wouldn't want to add this material to your character because it will start to slide down angled floors.

 

I don't currently have this feature, but it's definitely on my list! This requires having either multiple sub-objects, or multiple collider components, which hasn't been part of Ferr2D's workflow so far. The way I do things like this right now, is check the terrain's collision normal and edge override to determine what sort of behavior to use.

Do you have any extra details here, errors in the log or an unusual setup? It's not something I've seen before!

 

Hi!, no we don't have any other prompt on the log or anywhere else. But it seems to happen when we load a scene or when we hit play a few times. Then the ferr2D terrain asset lose the fill material reference and because of that all the terrains in the scene that uses it change the fill from closed to none.
It is happening to all of the new terrain assets we've created. The first ones we created with earlier versions have no problems at all (even though they've been updated with Tools -> Ferr -> 2d Terrains, etc)

 

Do you mind sharing a bit of code? I'm pretty new with Unity (that's why I felt Ferr2D was such a perfect tool).

 

Alright, I've fiddled with this a bunch, and haven't had any luck with reproducing it. Dug through the code and nothing jumped out at me either. Does this happen in a blank project with just Ferr2D in it? And could you send me a project where this happens consistently?

Here's some code!

This is a method for getting the surface information based on collision data:

Code (CSharp):

1. Ferr2DT_TerrainDirection GetSurface (Ferr2DT_PathTerrain aTerrain, Vector2 aPoint, Vector2 aNormal) {
2.     Vector2 pt  = aTerrain.transform.worldToLocalMatrix.MultiplyPoint(aPoint);
3.     int     seg = aTerrain.Path.GetClosestSeg(pt);
4.      
5.     if (aTerrain.directionOverrides[seg] == Ferr2DT_TerrainDirection.None) {
6.         // no override on this segment, normals will be more accurate when it comes to corners and such.
7.         if (Mathf.Abs(aNormal.y) > Mathf.Abs(aNormal.x)) {
8.             if (aNormal.y > 0) return Ferr2DT_TerrainDirection.Top;
9.             else return Ferr2DT_TerrainDirection.Bottom;
10.         } else {
11.             if (aNormal.x > 0) return Ferr2DT_TerrainDirection.Right;
12.             else return Ferr2DT_TerrainDirection.Left;
13.         }
14.     } else {
15.         return aTerrain.directionOverrides[seg];
16.     }
17. }

And this is how you would use it in a collision event!

Code (CSharp):

1. private void OnCollisionEnter2D(Collision2D collision) {
2.     Ferr2DT_PathTerrain terrain = collision.transform.GetComponent<Ferr2DT_PathTerrain>();
3.     if (terrain != null) {
4.         Ferr2DT_TerrainDirection edge = GetSurface(terrain, collision.contacts[0].point, collision.contacts[0].normal);
5.          
6.         if (edge == Ferr2DT_TerrainDirection.Left || edge == Ferr2DT_TerrainDirection.Right) {
7.             // wall collision!
8.         }
9.     }
10. }

 

Hey guys

I'm seeing a weird behaviour where the last point of my path meets the first point in a closed path:





So as you can see there the curve from the first point to the second point doesn't behave the same way as the rest of the path, and there is a gap in the fill between the first and second point.

If I do not close the path this doesn't happen. This also doesn't happen if the path is not smooth

Any idea what's going on here and how to fix this?

 

Alright, I've got a fix for this! Should be pretty easy to update, I'll include it in the next update too

In Ferr2D v1.12, change these lines:

Code (CSharp):

1. #683 Ferr2D_Path.SmoothSegment(tList, tScales, fillDist, false, out tList, out tScales);
2. #1199 result.AddRange(Ferr2D_Path.SmoothSegment( Ferr2D_Path.IndicesToList<Vector2>(path.pathVerts, list[i]), aSplitDist, false));

to this:

Code (CSharp):

1. #683 Ferr2D_Path.SmoothSegment(tList, tScales, fillDist, list.Count<=1, out tList, out tScales);
2. #1199 result.AddRange(Ferr2D_Path.SmoothSegment( Ferr2D_Path.IndicesToList<Vector2>(path.pathVerts, list[i]), aSplitDist, list.Count<=1));

Should fix that particular bug!

 

Hi @koujaku, thanks for that super quick reply!

I just gave that a go and the fill problem is definitely fixed, but the weird curvature bug is still there. Like this:



This is a perfectly square path, and notice the bottom left where the paths close the curve is a bit strange still

 

Hey @koujaku

Noticed another thing too - after applying those 2 changes you suggested, this introduces a couple of new bugs:

Bug 1:


This is a FillType None path that is Not Closed, however as you can see the Colliders are behaving as if the path is closed.

I have confirmed this is caused by the 2 line changes as I've tested the same behaviour without those changes and the colliders do not close in default Ferr 1.12 code

Bug 2:
The second bug is that none of the other FillTypes except for None and Closed actually work anymore. If I set the FillType, FillType just becomes None no matter what, and Closed is tick on Ferr 2D_Path if you choose Closed. Skirt and the other options does nothing and the value sticks to None

 

Yeah, ok, looks like that solution needed a little more thought. There's a lot of edge cases in this area of the code, looks like I'll have to dig a little deeper there! I'll mess around with a few things and see what I can come up with!

 

I don't know if this has come up for any other people, but I get this weird behavior when dealing with 2d edge colliders and fill type "none". It comes up when the ground direction changes. Collider from point 1 should go to point 2 right. And from 3 to 4 but they decide to go to the end of current direction or something.

 

Thanks, it was really useful !
I was able to significantly reduce the size of a scene by removing the mesh from the meshfilter at save, without harming the looks of the scene while working.
Here's the code, if anybody should need this.

Code (CSharp):

1.  
2. using System.Collections;
3. using System.Collections.Generic;
4. using UnityEngine;
5. using UnityEditor;
6. using UnityEditor.SceneManagement;
7. using UnityEngine.SceneManagement;
8.  
9. [InitializeOnLoad]
10. public class SceneEditorManager
11. {
12.     static SceneEditorManager()
13.     {
14.         EditorSceneManager.sceneSaving += OnSceneSaving;
15.         EditorSceneManager.sceneSaved += OnSceneSaved; ;
16.         EditorSceneManager.sceneOpened += OnSceneOpened;
17.     }
18.  
19.     public static void OnSceneOpened(Scene scene, OpenSceneMode mode)
20.     {
21.  
22.         Ferr2DT_PathTerrain[] paths = GameObject.FindObjectsOfType<Ferr2DT_PathTerrain>();
23.         for (int i = 0; i < paths.Length; i++)
24.         {
25.             if (paths[i].TerrainMaterial == null)
26.             {
27.                 Debug.LogError(paths[i].name + " : no terrain material", paths[i].gameObject);
28.             }
29.             else
30.             {
31.                 paths[i].Build(true);
32.             }
33.         }
34.     }
35.  
36.     public static void OnSceneSaving(Scene scene, string path)
37.     {
38.         Ferr2DT_PathTerrain[] paths = GameObject.FindObjectsOfType<Ferr2DT_PathTerrain>();
39.         for (int i = 0; i < paths.Length; i++)
40.         {
41.             paths[i].GetComponent<MeshFilter>().sharedMesh = null;
42.         }
43.     }
44.  
45.     public static void OnSceneSaved(Scene scene)
46.     {
47.         Ferr2DT_PathTerrain[] paths = GameObject.FindObjectsOfType<Ferr2DT_PathTerrain>();
48.         for (int i = 0; i < paths.Length; i++)
49.         {
50.             if (paths[i].TerrainMaterial == null)
51.             {
52.                 Debug.LogError(paths[i].name + " : no terrain material" , paths[i].gameObject);
53.             }
54.             else
55.             {
56.                 paths[i].Build(true);
57.             }
58.         }
59.     }
60.  
61. }

 

By the way, another addition I would suggest/request, that we often use, is an option to reset scales and orientation of a ferr.

Simple code, but would be easier if the option was included.

Code (CSharp):

1.  
2.     public void ResetScales()
3.     {
4.         if (vertScales != null)
5.         {
6.             for (int i = 0; i < vertScales.Count; i++)
7.             {
8.                 vertScales[i] = 1;
9.             }
10.  
11.         }
12.     }
13.  
14.     public void ResetOrientations()
15.     {
16.         if (directionOverrides != null)
17.         {
18.             for (int i = 0; i < directionOverrides.Count; i++)
19.             {
20.                 directionOverrides[i] = Ferr2DT_TerrainDirection.None;
21.             }
22.         }
23.     }
24.  

 

I don't know if this has been brought up already but I'm having quite a few issues with the 3D collider mesh generation. Particularly around corners in meshes. I have had two classes of bugs, one of which I've narrowed down to a particular case. In this case, it's using a closed fill type terrain, and only generating colliders along the top, with smooth path turned on. Adding left or right (depending on where the corner is, though I've only seen this on the left side of the colliders) fixes these errors but for these terrain types I am allowing the player to jump up through the colliders so I don't want the left and right edges generated. Changing the terrain type to skirt also fixes the issue. For most of my use cases this is fine, but it would be nice to see a fix.

The other problem could possibly be in my code so I can't be sure, but it might have something to do with the normals because (very rarely) I just clip through the terrain. I'm using a kinematic rigidbody and querying with rigidbody.SweepTest() so I can't be 100% sure this isn't on my end but it is otherwise rock solid, especially on other types of colliders.

 

Hi @koujaku !
I'm without a computer at the moment( minr stopped working) but there is something I would like to request if it isn't already and I didn't notice.
Is it possible to add composite collider support?
sorry for bothering

 

Ok, I think found the problem and is our fault (unless is there a way to override it haha)
The thing is that because I'm lazy I was duplicating the first terrains we've already set up, because all of our terrains use the same set up inside the terrain editor with ferr2D (setting up size of tiles, number of tiles, height, left, up, down, corners, etc); So in order to not have to set up all the terrains over and over again (all use the same set up) I was duplicating them in the explorer (ctrl +c -> ctrl +v) and then I changed the name of the "new" terrain file and handed it the new materials I created. I think then, there are problems with IDs and references with the files inside thems.
So I created a new terrain from scratch (right click -> create -> ferr2d -> terrain material) and then handed the new materials and it doesn't lose the reference when we change scenes in the editors, or close and re-open the project.
Could it be that?
Don't know how Ferr2D handles internally the terrain files, so I don't know if duplicating them create problems or not, instead of creating always new terrains files.

 

Hi, FrozenBotsStudio!

I use you code and the size of my scenes has decreased from 80 mb to 40 mb!
But android apk size doesn't changed=( Maybe Unity generate a mesh at compile time?

 

Hi! Yes the thing I realized afterwards is that in the process of building, all scenes get opened and the code in OnSceneOpened gets run as well. I'm not not in front of my code but I had to add some thing like if (!buildpipeline.isbuilding) to that part of the script.
Also, don't forget to build the ferr in the ferr2dt_pathterrain script on awake or start, since we're not in the editor anymore it has to get built somehow.

 

Seams in block dungeon

It is convinient and flexible to make a dungeon not as one single big terrain, but from many samll modular terrains, like this:



As you can see side edges are great at sides, but pretty ugly in inner parts of block. I would like to handle this problem somehow better, as placing props each time over seams.

The most simple solution for me would just 4 boolean switches in inspector to turn on/off drawing of edges. Like setting "fill type" to fill only closed does. Unfortunately it controls all 4 edges at once. I am trying to find out, where the edge drawing actually happens, but it is not so obvious where exactly in Ferr2DT_PathTerrain it happens.

So my questions are:

1) How to disable drawing of one side edge?
2) How would you approach this seams problem?

 

Could someone please explain how the elbow caps work? (inner left cap, inner right cap.) The documentation hasn't been updated to include this info. When I tried it out, all it seemed to do was replace the normal cap. I'm using Unity 2017.

 

Hello @koujaku !
I am interested in your asset. Can you kindly let me know if I can customize the height of the Edge Object ?
Currently I am using an older version from a client's project and I can't find a way to reduce (scale down) height of the Edge Object. No matter how wide the Image for edge Material is, the edge is just way too thick.

I even tried your scale tool
http://ferrlib.com/img/ferr2d/Ferr2DScalePoint.gif

But the problem with the scale tool is that I can't just retain the scale. Whenever I add a new point the scale just goes back to the huge one.
see here https://media.giphy.com/media/3ohjUZD6VhKsoBc6go/giphy.gif

Does it has to do anything with compatibility ? I am on Unity 5.6
I just need to know if it is really possible to altogether scale the edge down.

 

@adnanpk I think you're looking for the setting in the inspector called "PPU" (pixels per unit). That will allow you to scale the edge widths per terrain.

 

Thanks allot for your help but PPU isn't available for default textures. I mean when in inspector you choose Sprite then you can see but for Images imported as default textures doesn't have an option

 

PPU can be found on the Terrain script itself

 

Hey @koujaku any update on this bug? It's still really killing us

Also, I seem to be getting lots of crashes caused by Ferr2D:

It can happen anytime, e.g. entering Play mode, adding a Prefab which has Ferr2D on it, or loading a scene with Ferr2D on it.

Here's the full Editor.log:
https://pastebin.com/dPDBPdUZ

 

That's right Koujaku but this effects the whole terrain. I am looking for modifying the edge only.

 

It's a little tough to tell from your GIF, but if only one of your edges is the wrong size, and PPU doesn't solve it, it's quite possible that you just need to change your source texture! Doing all your scaling with extreme vertex scale will result in some rough aspect ratio stretching. If that's not it, could you share more details with what you're trying to do?

 

I have some relevant news I've been sitting on, I'm hoping it resolves sooner rather than later! But in the meantime I'll show you some of the stuff I've been working on.


Lots of Bezier curve related work, and a completely new path system!


And arc corners that work with the Bezier curves!

It's quite a lot of good stuff, and it'll solve a ton of my old path problems, but it's also quite a big change! This path tech is likely to arrive first in Ferr3D, ( https://twitter.com/koujaku/status/951953986088677376 ) which I'm putting a lot of work into right now, and am hoping to wrap up this month. After that, I'll definitely be revamping Ferr2D to use this tech too!

When it goes in, you'll get better curves, better colliders, less distortion, the last of the closing segment bugs will be gone, and probably a whole pile of other things too!

 

Thanks for the update @koujaku looks like some pretty impressive and promising things coming. I've also been wanting some more control on which points are smooth and which aren't, so that's great!

Any thoughts on the crashes though? This is another thing that's killing us at the moment, as Unity is crashing every few minutes now. Using 2017.3 now but this has been happening in any 2017.x version we've been using

 

Your crashes are odd, I haven't seen that issue before, and am not sure what would cause it. I'll probably need a few more details on the context. Also, line numbers don't seem to match up, what's on line 810 of your Ferr2DT_PathTerrain.cs, and have you done significant modifications to Ferr2D? Do you get the same issues with a plain install?

 

Hey @koujaku
just out of curiosity - did you ever had the chance to fool around with Unitys SmartSprite feature which is pretty similar to Ferr2D? It was once available as experimental build, not anymore, although they're still working on int. If you had the chance to look into it, what were your thoughts?