Ferr2D Terrain Tool

I think we can wait for it

Btw, after tying the plugin with my S***ty programmer art it looked and worked just fine!

 

how does this run on mobile,this tool looks great and im really interested,i found this purley after finding this video http://www.youtube.com/watch?v=y-chi097uV4&feature=youtu.be at the 8.02 mark, then typing in 2d in the asset store

 

First I have replaced your blob by mine... then I have tried with this monkey ! And it's very funny to see him jumping from platforms to walls.



6R

 

It actually does pretty well on mobile! I've kept everything pretty fast, but you will run into fill rate issues if you use too many layers, especially if you have large transparent edges. I'd probably recommend 2-3 layers max on mobile for decent performance. The demo scene I play with on my tablet has 5 layers at the bottom of the room, and that'll drop the framerate on it noticeably when they're all visible.

v1.0.6

OK! So I submitted version 1.0.6 to the store a moment or two ago, pending approval. I didn't get as much done as I wanted, but the 4.3 stuff is pretty important now that that's out, so I figured I'd expedite a little! Nothing should break with this update, I had to bend around a few things to make sure that worked out, but you should be fine! Just be careful about mixing 3D and 2D collision systems, it just doesn't work!

Biggest thing on the list is going to be the 4.3 support! Unity 4.3+ will default to using the 2D colliders, with the option to switch back to 3D colliders. Pre-4.3 will continue to just use the 3D colliders as is.

Also, I do like their new undo system, it's way more streamlined and straightforward! So undo will work perfectly well in 4.3 now too.

I've added in a JSON parser and ToJSON and FromJSON methods to all the important classes, which is cool~ The JSON parser is pretty sweet as is, should work flawlessly for the terrain stuff. I've still got a few features I want to add to it, but I'll probably publish it separately for free later too. I know they're a dime a dozen, but ones with nice interfaces can be hard to find sometimes.

And a new demo scene! It's small, but it does demonstrate procedurally updating the terrain object during run-time. It's super simple, not much involved =D

Here's the full changelog:

+Added 4.3 support for the new 2D Physics system
+Added 4.3 support for the new Undo system
+Added a new example scene demonstrating how to make real-time edits to the terrain
+Added a cool JSON parser, improvements still in line for this later
+Added JSON save/load to Ferr2DT_PathTerrain, Ferr2DT_TerrainMaterial, and Ferr2D_Path
+Path Terrain
-Added option to switch between 3D colliders and 2D colliders when using Unity 4.3+
-Added a slider to adjust how Ferr2DT stretches texture segments
-Added AddAutoPoint method for inserting points easily to the path, see the new example scene for reference
+Path
-Tweaked handle size to work slightly better in orthographic view, more work on this due later

Also, it looks like Ferr2DT was featured on the front page today *excited* so thanks everyone for that =D P6r, that monkey, man! I burst out laughing when I saw that, that's amazing!

 

koujaku, Do you use Mesh or Sprite Renderer?

 

Hi Koujaku,

After installed Unity 4.3 I have a issue on my ground platforms. If on the ground I not have add more points the character go fine, otherwise when the character go beyond the first extra point fall down. Before the unity update this was go fine.
Thanks in advance

 

It's a MeshRenderer! This is very much a vector based solution. I haven't looked too closely at the SpriteRenderer component yet, but I doubt it would be a terribly suitable match for what the tool does. Any particular reason you're asking?

I sent you a PM, lets see if we can figure it out!

 

i just examine tools that i like. i am not sure if 100% Unity 2D system compatibility means using 2D collider, 2D rigibody and Sprite Renderer. i am looking if mesh rendere cause some problem using with Unity 2D system.

 

Using the MeshRenderer is no problem for the new 2D stuff, you aren't required to use the sprite renderer! You can mix and match 2D and 3D graphics seamlessly, which is nice =D

The biggest thing with the new 2D system is that 2D physics and 3D physics don't interact at all, so a 3D MeshCollider isn't going to stop a RigidBody2D from falling in the slightest. The current version of Ferr2DTerrain, 1.0.5 only has a 3D MeshCollider, but I do have an update pending approval, 1.0.6, that includes support for the 2D PolygonCollider, which is all you really need to get it working with the rest of Unity's new 2D stuff!

 

Thanks koujaku for the update for 4.3 and for your comments.
Here is an example with a (crazy) frog, funny too with your system (staying on the ceiling, on the sidewalls,... !!!



6R

 

koujaku do you plan to increase price? if assets are not urgent, i wait daily sales for buying them

 

I don't plan on increasing the price for this one. I also haven't submitted to the daily sales program either. I might yet, but probably not soon.

If I do 2D lighting stuff, or anything else with major functionality like that, I'll probably release it as a completely separate package, rather than bundling it in with the Ferr2D Terrain Tool and increasing the price!

 

do you mean 2d light like this?

http://forum.unity3d.com/threads/142532-2D-Mesh-Based-Volumetric-Lights

 

Nah, those are nice, but more like the Rayman stuff. Not so much point light sources, but more atmospheric and mood effect sort of lights.

 

Pls do the lights assets, it's something I'm looking for

 

is it this Rayman?

http://rayman.ubi.com/legends/en-gb/home/

 

If it was robust enough to justify being a separate package to buy I would definitely be interested in purchasing.

Thanks for another great update to the Terrain Tool as well!

 

PM sent...
6R

 

I think the lighting should be an entirely different package, otherwise the price of this goes up, which for those of us who own it its great, well, except for some who might own it but not want the extra stuff like lighting. The packages would be pretty different from eachother so I think releasing them as seperate entities would be a good way to do it honestly. I'm personally sitting here ready to force feed you money the instant you start working on the lighting stuff, if.

 

Nick, if I may, I have a couple of suggestions to make your toolset even more suitable for rapid prototyping.
I've implemented these myself by extending your code, but not as efficiently as a talented programmer would do (as yourself), so I'll just share the ideas:

1. Option to recreate colliders in Play mode. I'm making a fast-paced 2D-game and this is an immensely useful feature for me. I just add/remove points during live Play session (new Mesh is created at each position change on MouseUp), test the level out and when done, save all of my changes with a button in the Editor. Makes Unity behave just like UBIArt framework (regarding dynamic collision mesh update), which is very convenient.

2. "smoothSphereCollisions" option switch in the "Create Colliders" section of the GUI for a created MeshCollider. Trust me, this is a very important feature for sphere-based collisions (CharacterController capsule including), considering how much PHYSX sucks at collision and angle detection on close to flat angles and on polygon edges. It makes mesh collisions a little more stable.

3. Since MeshColliders suck quite a deal in Unity (Hi PHYSX!) I've set up a (very slow and unstable) function to create very thin box colliders between sections of the sprite mesh. The idea is - box colliders aren't poly-based, but rather internal implicit objects, they don't glitch when it comes to collisions. I'm creating a series of GameObjects between each two points with box colliders. My implementation is terrible, but it shows that such collisions are much more stable. Just something to think about.

And a couple of questions/nitpicks:

1. Is it me or does the Vertex color shader you supply with Ferr2D miss actual vertex color setting in the GUI?

2. An option to display actual angle of a slope created could be useful, I think. I mean something like this for each in-between two points: Vector3.Angle(vectorFromPointAToPointB, Vector3.up) floating as a label between two points, on a line between them. Just an idea, I haven't implemented it yet, ran out of time for experiments =)

Cheers

 

Excellent ideas! I've never actually used the smoothSphereCollisions option before, and truthfully, didn't even know it existed! Thanks for pointing that one out to me~ I'll make sure both of these are in the next version.

I've been using "Continuous" Collision Detection for my objects, and haven't had any issues with that so far. Admittedly, I don't use a lot of physics objects in my scene, so I don't know if that solution scales at all. However, a couple of people now have mentioned wanting box colliders as an option, so I probably will add that in as well.

Since it's vertex color, that data is provided through the mesh, rather than through the material. That's accessible on the PathTerrain component with the GUI there. I have a shader in one of my other projects that does include a material color as well, I can include that in the next version as well, it's just extra shader instructions is all~

I can probably add that angle thing in to the preferences as well, could be a nice addition. What exactly would you be using it for though?

 

First, I'll say "you're awesome" one more time =) Thank you.

I can probably add that angle thing in to the preferences as well, could be a nice addition. What exactly would you be using it for though?

For example, my character can perform wall-sprint up the wall when running, but only if delta between his current surface and the surface he's hit is less then, say, 30 degrees. Also there are lots of state switches dependent upon the angle of the surface - steep surface sliding, edge grabbing and that kind of stuff... That's why seeing angle values between points would be the tits. I could probably do it myself, but don't have the time currently. I'm sure others will eventually find such an option useful when they start developing a really complex character controller state machine and mechanics.

BTW, you probably wouldn't believe me, but CharacterController works quite well for such a mechanic. You can't achieve the same with a RigidBody controller. Just thinking out loud.

Back to the topic though...

Thank you for the vertex explanation, I'm such an idiot, should've looked at the actual shader first =) Come to think of it, using vertex color is a good idea for faking lighting, I'll try it out, thanks!

I've been using "Continuous" Collision Detection for my objects, and haven't had any issues with that so far. Admittedly, I don't use a lot of physics objects in my scene, so I don't know if that solution scales at all.

I can't really speak for the physics, since I only use CharacterController for maximum precision and I let me tell you: PHYSX MeshCollisions suck at angles 0-1 degrees, because contact point normal on poly edges jumps 0-12 degrees. If you're curious, create a flat Unity plane with a mesh collider, put CharacterController onto it and move it slowly watching OnControllerColliderHit hit.normal. You will be surprised.

 

Very Cool Project.

Question: I have bezier paths that are created by another package at run-time. Can Ferr2D use these paths ?

edit: What functionality of the API can be used during run-time.

Cheers.

 

Hey man,
Can I see a 2.5D demo?
Thanks.

 

Totally makes sense now, I'll keep that in mind when I'm coding it~ I also haven't actually used the built-in CharacterController, I've so far just rolled my own using Rigidbodies and manual calculations! Is it actually worth it? I'm a little of a control freak when it comes to player controls, so the idea of working with a black-box character controller scares me a bit.

Ferr2DT does not work with other path packages. As far as I know, there's no standardized model for paths in Unity, so it isn't terribly likely to happen in the future either, sorry =/ It shouldn't be all that hard to dump out a list of points from the other path system, and put it into the terrain procedurally though.

You should be able to do everything the editor can do, during runtime. Since the editors require pretty much full access to the terrain/path objects, everything pertinent is marked as public. I've tried to keep the code pretty well comment doc'd too, so intellisense should give you a fair bit of info there.

Technically, all my demos are 2.5D. Could you elaborate a little more about what you're hoping to see?

Demo, just in case you didn't see it

Each terrain object is going to be flat on the Z-axis, but it does generate 3D colliders for interacting with regular 3D objects. You can move 'em anywhere you like along the Z-axis, which can be used to achieve the parallax effect you see in the demos, but could also be used for various lighting effects and such. Hopefully that begins to answer your question?

Thanks guys =D

 

Me too! I'm also a control freak, that's why I specifically use CharController just to get collision data and restrict movement each frame (not each FixedUpdate()!, every single movement is described by vector maths. The benefit of using the CharacterController component (not a set of sub-par CharCont scripts Unity is bundled with) is that it doesn't use physics at all, it's doing collision detection internally and this is awesome, because my game doesn't use Time.deltaTime, but rather a fixed delta approach (1/60 or 1/30 depending on screen refresh rate) much like the one you'll find in Rayman Origins or Legends. I've even rewritten some of the standard methods not to use a global timer (Lerps, smoothDamps, timers...). It means that the game will never twitch/stutter or whatever and even if FPS drops it will just slow down much like a terribly unoptimized Rayman Fiesta does sometimes.

And physics uses detaTime approach internally, you can't change that. AFAIK.

Absolute precision and predictable behavior of the character (well, as much as Unity will allow...) each frame is the key here. =)

To be fair, it's quite limited when it comes to interacting with physics, and if there was a physics-independed RigidBody kinda thing, I'd use it. But alas...

BTW, I've stumbled upon several issues and had a couple of ideas about Ferr2D. I'll post them soon.

ADDED: When I say total precision I mean that if you try to Transform.translate a Rigidbody into a 45degree wall it will start going along the wall slowly, by transferring some "energy" into Y-movement. If you do the same to the CharacterController with its slope limit set to zero, it will stop immediately upon contact. Also, Rigidbody tests for collisions only during physics update and in many cases can go through the collider if you move it via transform, which seems like the only way to move it in Update() if necessary. So many issues. Not mentioning the fact that it depends on frequency of physics update, which is a performance killer. Please don't tell me you move yours with AddForce =) Sorry for the offtopic.

 

Hi Nick,

I'm back with more nitpicks and notes:

1. Scaling meshes created with Ferr2D. Yes, yes, I do understand that you place points in global space, but just an FYI, this is what it looks like if you parent Ferr2D mesh under a scaled down GameObject or scale the mesh directly:

Before:



After:



I tried this because I needed to change scaling of textures used in the game without changing the assets directly, so I changed tiling in the material settings and this happened:

With UV tiling = 1:



With UV tiling = 2



Now that's understandable, because TerrainMaterial had been set up with unchanged tiling in mind.

So this is what I did - I found the TerrainMaterial and went into the EdgeMaterial:



And found out that it didn't acknowledge tiling:



What I did then was dividing all TerrainMaterial values by UV scaling value (2) including offsets, making them twice smaller. And it worked!



But the editor still shows the texture as if it's wasn't tiled in the material settings:



So I propose to add a "UV scale multiplier" field to automatically recalculate all values entered by the user internally for times when you need to change scale of tiling (or, if you want to be really fancy - separate multipliers for U and V, changing all vertical and horizontal values respectively =)

 

Ok, moving on:

I was wondering if this could be avoided:



So it would look like this:



What I mean is that it would be cool if there was an option to UV-map the mesh continuously and not on a point-to-point basis. Then you'd be able to set as detailed of a collision surface as needed without using two meshes and having bad-seams and squashed textures problem.

Next:

When you toggle "Use left/right/top/bottom" the settings get reset. That's really inconvenient:

Before toggle:



After:



Cheers

 

Oh, snap. I just discovered the "Pixels Per Unit setting". Never mind my yammering about UV scaling then, sorry =)

 

were creating new textures for use in "ferr" and would like to add inverted corners, as when the wall meets the floor instead of using the top caps.
Would greatly help to improve the quality of terrain.

Cheers

 

allow various caps on each side and change it at will with something like the black dots you already implemented to change textures would be very good.

Thanks

 

Hi, koujaku, I just bought this tool, and I´m pretty amazed with what I can do with it. Thanks!
Here are some screenshots of my early tests:

I just noticed some things I would love to see in a future update, and want to know if they´re possible or not:

1) A sprite generator to break the patterns - In Rayman there´s always some objects placed in front of some problematic spots on the terrain. Of course I could use separated quads with a material for each one, but I would love to generate the quads the same way we generate a terrain: by placing the four corners where I want, and do not care if the scale of the object will generate another draw call, but meshes and uvs are handled by the editor... if theses decorative elements are in the same texture that the border texture, it will not generate another drawcall...
So to do that, would be necessary to add decals to the material editor (actualy there´s only top, left, right, bottom, and the respective caps). What I imagine is a section in the material editor that I could enter the number of decals, and map each one of them on the texture.
Then, would be possible to add a decal by: GameObject --> Create Ferr2D Terrain --> Create Decal.
On the GameObject I would select the number of the decal, or let it be random.
This would be a great addition to this toolset!

2) Since the material editor is pixel-wise, there´s some problems when the import settings are changed... If I change the resolution of some texture, that breaks the terrain material... would be better if internally the system stores these numbers as percentages instead of pixels? If the texture compression changes will this break too? For example? I´m working on Android, using ETC and RGBA16, when I build to Apple, It will use PVRTC, and the images changes from Power Of Two to Squared Power Of Two...

Again, Thanks for this great Tool!

 

Just bought this today and it's awesome! One question:

When I assign a Physics2D Material to the terrain in design mode, it does not show up on the generated collider in play mode. Am I missing something here?

 

It's a bug! Sorry about that~ In Ferr2DT_PathTerrain.cs, there's a line that looks like this (Line ~385?)

if (physicsMaterial != null) GetComponent<PolygonCollider2D>().sharedMaterial = physicsMaterial2D;

And it should be this instead:

if (physicsMaterial2D != null) GetComponent<PolygonCollider2D>().sharedMaterial = physicsMaterial2D;

This was kinda my thinking with the basic sprite component that I included with the project, although I haven't quite fleshed that out entirely. You wouldn't need to have it as part of the terrain system, since you could just reuse the same material and just grab specific UVs from it. You should have the same number of draw calls, plus you have the option to use whatever system you wanted with it. I'm still trying to decide how far inside the scope of this project that actually is now, especially with the recent release of 4.3.

It actually does store as UV coordinates, I only display as pixels for ease of defining regions. In my experience, UV coordinates have always been a little weird when Unity resizes to fit powers of two, and Ferr2DT will mess up when that happens. It's possible my shaders are ignoring some of the UV stuff that Unity will sometimes do, I still haven't exactly got the strongest grasp on Unity's shader system. I'll look into this to see if there is an elegant solution, but in the meantime, I'd recommend sticking to power of 2 textures (something I always recommend anyhow).

Also, I love how you're using it, looks great!

This is definitely a big one on my list, improved corners are pretty important to me too! It's just going to be a pretty big change from the current setup, so it could take me a bit to get that in.

When I get the smoothing stuff working properly, I think I can get this to look a fair bit better. Especially if smoothing is turned on. Also, I'll see if I can get the settings in there to stay for the "Use X" toggle. Not a big one on my list, but it'd be nice to have =D

And I think some of those scaling problems you were having might be related to some of the resize issues k3pp was having, so I may look a little at that regardless, but I'm glad the PPU stuff worked out for ya~!

 

Wow!! That´s enought for my needs! I didn´t know about the sprite component! There´s some editor like the terrain material, or it´s just that UV numbers?
Anyway it solves my problems! Thanks!

About the Pixels X UV coordinates problems, I´m already using PoT textures, but my problem is when I have a terrain material already mapped and working perfectly, and I change the texture size. For some reason, the terrain material breaks up and I have to re-do the slicing of the texture...

 

Hi. I'm thinking about buying this asset but i have few questions:

1. Can i use Rigidbody 2D's and Sprite Renderers with this?
2. Does this support mobile phones? Maybe a stupid question but one different asset did not support mobiles and I was kinda disappointed.

Thanks!

 

It's unfortunately very bare bones, so UVs, and native Unity UVs at that, which are very confusing (to me at least). I do intend to extend this later, but it's not high on my priority list until I can figure a good way to do -really- cool stuff with it.

I'll put this on my list. I have a sneaking suspicion this may be a little tricky, but we'll see.

Yes, absolutely! That was the major purpose of the recent 1.0.6 update =D Ferr2DT uses the new 2D polygon colliders so it can properly interact with 2D physics.

I built it with mobile in mind, so yes it does. Just keep in mind that by it's nature, these terrain components can be a little pixel fill heavy. 1-2 layers of terrain should be about right for mobile, 3 might be pushing it a bit. My Kindle Fire HD starts giving out around 5 layers. Now when I say layers, I mean terrain on top of terrain on top of terrain... not chunks next to eachother. Those are fine =D

 

Ok, Just to Ilustrate what´s happening:

This is the wood in the background of my second image, in my first post.

The image was rendered (yeah, it´s a 3D render) in 4096x2048.
In the import settings of the texture I firstly used 512x256. Did the terrain material slicing, and when I was testing, the resolution is´nt enought. So I changed the import settings of the texture to 1024x512.

The mapping remains in the resolution of when it was mapped, and did´nt adapted automatically.

I know it can be tricky to solve, so I just wrote to explain better, and maybe helpe a little!
Thanks again!

 

I was thinking of using your plugin as level editor for other platform with JSON export, but not sure if I'll be able to parse everything.

Could you share what is exported in JSON? JSON file example?

 

Hey koujaku!

We've been having a blast using your tool, but there is one issue that we've run into that's causing our artists to tear their hair out in frustration!

It appears that textures are displayed on screen in the Ferr2D Material editor at their native pixel size, which for the most part is fine. However, when using a texture that is larger than the current screen resolution it gets very difficult to work with the tool. Would it be possible to allow us to resize the window and then have scrollbars to look around the textures in the instance that they're bigger than the set window size?

An example that's come up is our artist is trying to work on his 720p Cintiq, however the texture being worked on is 1024x1024, which means it's much wider than the screen. He has to get really creative with adjusting where his main screen is relative to this one so that he can drag the tool around to see the different parts on the tablet. Likewise we noticed that when using a larger texture ( such as 2048x2048 ) the tool doesn't seem to display much of anything at all!

Thanks!

 

Here's a quick JSON file for ya, it's nothing terribly complicated.

Code (csharp):

1.  
2. {
3.     "fill": "Closed",
4.     "fillY": 0,
5.     "fillZ": 0.2,
6.     "splitCorners": true,
7.     "smoothPath": false,
8.     "splitDist": 4,
9.     "pixelsPerUnit": 32,
10.     "stretchThreshold": 0.5,
11.     "vertexColor": "FFFFFFFF",
12.     "createCollider": true,
13.     "create3DCollider": false,
14.     "depth": 4,
15.     "surfaceOffset": {
16.         "0": 0,
17.         "1": 0,
18.         "2": 0,
19.         "3": 0
20.     },
21.     "colliders": {
22.         "bottom": true,
23.         "top": true,
24.         "left": true,
25.         "right": true
26.     },
27.     "directionOverrides": [
28.         "Top",
29.         "None",
30.         "Top",
31.         "None",
32.         "Top",
33.         "None",
34.         "Top",
35.         "None"
36.     ],
37.     "path": {
38.         "closed": true,
39.         "verts": [
40.             [-12.33898, -5.637882],
41.             [-12.80495, 3.053585],
42.             [-21.28229, 4.144641],
43.             [-21.72445, 14.81662],
44.             [-4.104484, 14.01831],
45.             [-4.344388, 3.969534],
46.             [15.07276, 4.638058],
47.             [14.86952, -5.023991]
48.         ]
49.     }
50. }
51.  

I see what you mean there. I'll see what I can do about that!

I've got a pretty big list of features from everyone right now, so I'm going to be dedicating a bunch of time to patch these in next week!

 

Can the terrain objects created by Ferr2d be animated like normal gameobjects? like moving up and down, rotating, and scaling?

p.s. I still don't own this asset but I just released my current project so once I get my first payment from Google I'm grabbing this thing for some experimentation! (also if I get some money for Christmas). I CAN'T WAIT!!!

 

I´ve done a quick test, and works. I´m using unity 4.2, so I´m using 3d physics, and since Ferr´s terrains uses mesh colliders, sometimes, a simple collider can cross the other while using animation... I believe it will work better with 2D physics in 4.3.

 

Hi, koujaku!
Here I am, with another crazy Idea! hahaha!
Here´s the deal:
It´s Possible to add to each joint a "size"?
I believe the image talks better than my text:



I was playing Rayman Jungle Run, and the borders have an accordion-like effect, where in one section the ground is larger, and in other section the ground is narrow. It gives a very organic look tho the overall level design.

If it´s possible, can we have a color tint for each terrain vertex too? maybe a checkbox to enable advanced settings... even if they are´nt in the 3d window, and only in the inspector...

Please let me know what you think about this!

 

Cool thanks for checking that out for me!

 

OMG, this is such an awesome idea that I have to second it!

I can already see it this way: each point you add to the mesh has some kind of a "Scale" property, which determines how each section of the mesh gets , well, scaled, when drawn point-to-point. Interpolation between points can pretty much be just linear, i think it'll still work fine. And you could change this scale value by holding shift and scrolling with the mouse wheel: up to make it larger or down to squash it.

 

Thirded! This would be awesome.

 

Also have a request for a shader that supports lighting and shadows, in addition to the vertex color - is this even possible?

Even if that's a second package, I'd buy it right away.

 

Another option would be to be able to rotate the 'points' as they are now (or joints, whatever you might want to call them), since rotating 2D objects does give the illusion of depth somewhat, I think scaling would work really badly on areas with say grass, because it'd be really obvious the grass is being 'squished' so to speak, rotating is something I can imagine would work a little nicer.

 

If you mean rotating along the X axis so that the mesh tilts inward ... I don't think that would be very good. I can see a bunch of issues with that, especially clipping through other layers behind it. Even if you dont have background objects, the top "edge" mesh would likely clip through the "fill" mesh.

It would also mess up the normals, which maybe doesn't matter for most, but I'm using this with default shaders for lighting currently, and I imagine that wouldn't go over well.

Would definately try it out though if it was incorporated.

I think scale should work fine, as long as you do things like grass in moderation.