Ferr2D Terrain Tool

No change, still a small gap between cap and body. Strange.

 

Which version of Ferr2D do you use?

 

Ferr2D v1.0.7
Unity v4.5.1f3

 

Mhm, did you try to tweak the Edge Splits and Fill Split Values?
Did you check "Split Corners" ?

 

Yes, I think I've tried to fiddle with all kinds of properties. Maybe I've set up the texture wrong or something?

 

Did you? I thought the screenshot you posted was from the Ferr2D Example and it's setup is right.

 

Yes, you're right. The screenshots is from the included example. The only thing I changed was to activate the smooth path. So, not the texture then. Hmm....

 

Have you tried to reproduce it?

 

I had similar issues in the past, but if it's not not the texture-setup, then (un)checking or tweaking the variables solved it.
Would you be so kind and post a screenshot of the Inspector of the selected Terrain with the Gap?

 

New screens with attributes and steps to reproduce.

Setup:
OS X v10.9.5
Unity v4.5.3f3
Ferr2D Terrain Tool v1.0.7

Steps to reproduce:
1. Started Unity.
2. Created a new project (2D setup) and imported all of the included files in Ferr2D.
3. Opened the Scene "Ferr/2DTerrain/Examples/4 - ExampleLayering2"
4. Zoomed in a corner near the center.
5. Switched Smooth Path on and off.

 

Yeah, now I could reproduce it. Mhm. This is weird. I swear we had a similar issue and we could solve it with unchecking "Split Middle". This is really weird.

I guess we have to wait till @koujaku shows up :/

 

I've been using Ferr2D terrain for the levels of my current project 'Staying Together'. I had a few collider related issues here and there but overall my experience has been super positive.
Here is a gameplay preview

And here's a timelapse of me making a level if you want to see this plugin in action

 

Ha, love your setup! We're also using Ferr2D, 2DToolkit and 2DPC. I played the Webplayer demo a while ago, I think you posted it in the 2DPC topic. Liked it very much. Keep up the great work!

 

Hey @aRainyDay! I posted a fix for that here: http://forum.unity3d.com/threads/ferr2d-terrain-tool.204436/page-7#post-1580916. I think that should solve what you're seeing! If it doesn't, let me know, and you're always welcome to try out the beta for 1.0.8, which definitely has that fixed =D

And @TheValar, that's beautiful! I love it =D Thanks so much for sharing!

 

@koujaku I'm not sure if you are interested in any feature requests at the moment but I have a thought after using this a lot for my project. It would be nice to have the ability to "stitch" two terrains together. Often times I would design parts of my level separately and notice after the fact that they could be part of the same piece. I would have to decide which one to keep and then "trace" over the second piece manually, then delete the redundant one. I imagine this could probably be done automatically. Only difficulty I would foresee with it is getting the combined order of the vertices correct but hey maybe that's not a problem for you.

Also I know this was mentioned earlier but multi-selection of "nodes" would be a godsend

And while I'm on here minor bug report. If you have snapping enabled in preferences and you try to you smooth path at the same time it basically crashes Unity. I don't see any need for smooth path if you are using snapping so maybe disable it?

 

I'm always interested in feature requests~! I like the merge idea, I have no good idea how to do it yet, but I'll add that one to my to-do list! n_n

Multi-select is actually done already, and will be available with the next update, as will a vastly improved snap system~! It snaps to global coordinates, local coordinates, or relative coordinates using more standard ctrl-to-snap shortcuts~

 

Hey Koujaku are you having beta tester for the 1.0.8? i would love to try the new version!

 

Yeah! Send me your invoice number to [nick.klingensmith at simbryocorp.com] and I'll pass it along~

 

@koujaku Found an issue yesterday with Ferr2d Terrain. I wouldn't call it a bug really, more of a current limitation that may not be obvious.

I'm currently trying to get some performance gains for mobile so I tried to change the import settings to limit my terrain texture size to 512 (originally 1024) for specific platforms. When I did this the "mappings" for the Ferr2d material got messed up. It would be cool if the system could compensate for changes in texture size by properly scaling the "mappings".

 

I believe something similar got mentioned a while back, and I do actually have it working in the beta version, so long as you don't rebuild the terrain after changing the max-size!

 

Just picked this up, and it looks great so far. Is there a way to randomize the fill tiles at all? I'd just like to know before I start designing tiles. Thanks!

 

There's no way to randomize the fill texture at all, unless you're doing perhaps some fun shader stuff! That's usually where people start adding extra surface detail with decal style sprites, much like TheValar's time-lapse at around 3:40~

 

Spiffy! I can definitely make that work. Thanks for the super quick reply!

 

It seems that Unreal Engine 4 is gonna have a similar tool than yours very soon:
https://forums.unrealengine.com/sho...-for-4-3-Preview&p=93512&viewfull=1#post93512
https://trello.com/b/Kl9Pjqfn/paper2d-tasks

 

Yeah, I've seen that! I was pretty pleased they actually mentioned Ferr2D specifically, right up alongside UbiArt and everything n_n (That's a point of pride for me)

I've been considering bringing Ferr2D to Unreal if I ever find the time or incentive. I've reached out to them a little, and didn't get a whole lot of encouragement from them. In theory, Epic is actually kinda local to where I live, but they've always been pretty aloof and unreachable in-person for my experience. I'll reserve serious judgement on their engine architecture until I get to tumble with it a little more, but my early impression is that it's still sitting on an old and outdated core, and I'm not looking forward to working with it.

I also haven't seen any more recent screenshots of their Paper2D terrain stuff. If it stays looking the way it is now, I could pretty easily beat the pants off it~ And if I do port it to Unreal, it'll give me a chance to write Ferr2D from the ground up again, which would give me a great opportunity to overhaul a lot of things for the better, and bring that back to home sweet Unity.

But that all depends on time and stuff n_n I'm crammed as is.

Also, thought I might post some pics, as long as I'm posting. Been taking a break from the heavy stuff and just working on fun things, so here's a screenshot of what may eventually become paint-able terrain! The idea is that it uses a grid of integers, or an image essentially to define terrain regions. It scans the regions out, and creates a Ferr2D path for each one, using the integer as a material index! Right now, I'm just pulling from a grid of Perlin noise, but later I'll tie it into Ferr Blend/Paint so it'll be trivial to interact with


Not the prettiest yet either, but I only worked on it a few hours to get here, so I'm ok with that~!

If it ends up being fast enough, you could use it for digging, explosions or destructible terrain~ We'll see! It won't be in 1.0.8, too many small details there, but it's still fun to think about.

 

Hey there

So I recently purchased Ferr2D but it seems completely broken on my end. Here is what I do. Brand new project. Import Ferr. GameObject> Ferr Terrain> Create physical 2d terrain. I pick the Mossy Terrain Material. I see this (Which doesnt look right to begin with):



Then if I click anywhere or try to interact with it, it breaks and all I am left with is this:



And at this point I can't do anything. Can't add more points, etc.

Any suggestions?

 

Heyas! It looks like you're on the other side of the terrain! By default, the shaders don't cull, since they don't need to, so you can see the backside of the terrain, only with the fill overtop the edges! If you absolutely need to edit from that side, you can rotate the terrain 180 on the y axis.

I'm not sure what's going on with the path points though, that looks a little weird and unusual. What's your inspector/object hierarchy look like?

 

I figured it out. In my editor preferences/Ferr preferences, I had one of the 'beta' or 'testing' options switched on. (Snapping? I think?). That was causing new terrains to break when I spawned them. Worked well if I toggled the option after I spawned the terrain

 

This is super cool stuff. Two Thumbs Up.

Edit: forgot to ask about release date for 1.0.8 will this be soon ?

 

Extremely soon! I gave a few people beta #3 earlier this week~ I've got a few small things I'm tying up, mostly documentation stuff, and then I'll be submitting it for approval! I'll post the change log here when I do submit, so you'll know =D

 

Found a bug today. If you use Sprites instead of Textures for the Fill element the Sprites get strangely deformed. This happens if you rename the Sprite element or if you load a project with Ferr2D the first time on a different System.


To reproduce it simply change one of the fill textures to Sprite with Sprite Mode Single and change it´s name.
Not a problem for me just wanted to let you know.

 

@zorrar, The "Sprite" Texture Type switches Wrap Mode to "Clamp", which is likely the root cause of what you're seeing (it's a little difficult to tell from your shot, but I believe that's what's happening). The texture used for the fill material must be in the "Repeat" Wrap Mode in order to work properly.

While I wouldn't mind changing the settings on the texture itself automatically, I kinda feel that's overstepping the bounds of what a plugin should do on its own. If people disagree, I would love to know!

 

Great Work.

 

While I would generally agree with your sentiments there koujaku, I still feel like ease of use is the most important thing to the end user -- it's what makes this plugin so amazing and useful when laying down terrain! I feel like the proper route for a tool in general is focusing on ease of use *first*, then stability and modularity, then finally new features and better aesthetics -- this is the right way to go for a tool built for its users. Regarding eases of use however, if you allow users to set preferences somewhere about your system modifying their materials automatically (among other things that make the tool easier to use for *most* people using your tool), that, along with fair warning, would easily be enough for those who don't want those feature(s) active. Even those people who would disable it would also still appreciate the *option* to have it automate things like this if they ever decide they wanted it for a future project.

Speaking of features, I second two requests that have been previously mentioned (but perhaps forgotten?) :

1) using 2 *different* endcaps on the *inside* bottom-left and *inside* bottom-right corners of a block of complex terrain (and also *inside* top-left and *inside* top-right too -- this is the only thing preventing your new feature from looking its best imho -- I've done a lot of pixel-based tiles and tilesets in my day and these are the only things with terrain your system currently cant really do on its own convincingly enough without a lot of extra help from the artist and/or level-designer.)

2) grouping (or "bridging" as it was mentioned before) 2 separate terrains together (with the same basic settings) by using the select tool around nearby similar path points in each terrain (i.e. allowing the user to both "bridge" and "weld" path points in separate compatible terrains, which would let users effectively "combine" 2 terrains into a single terrain object -- [like you might do with nearby vertices in a 3d modeling package]). The way to do this (imo) would be to make sure at least 4 path points were selected (2 points on each of the two terrain objects), and if more is selected on one terrain object, the same number would need to be selected on the other terrain object. Obviously this would only work while selecting 2 objects and would fail if more (or less) than two terrain objects were selected (without a bit more work I would guess). Either way, terrains would be a LOT more malleable so that they would "just work" as seems to be the mantra of our beloved Unity.

And my own suggestion for easier tileset setup:

3) letting a user set ONLY the initial x,y coordinates on their image for each parts' UV coordinates, so they would only have to remember **a particular width and height** from that initial location which your system would calculate on its own to help the user out of having to remember all the x/y locations for ALL the parts on different images. If your image parts were built around a grid of 16x16, you would simply need to remember 0, 16, 32, 48, 64, etc. for tile 1, 2, 3, 4, 5, etc. respectively, to cover you for both vertical and horizontal axes. Currently, without this system, the only way for me to do this step is to go into my art program, dig up the numbers of each side of each part (and depending on your art program, this can be fairly-tedious or stupidly-tedious) and write each value down, hoping you don't misread something while trying to hurry through it in your art program, and then take a ton of time to set it all up, hoping you don't misread a number in the process *again* while inputting it into Unity and mix some part's x or y value up with another part, etc. etc.

Your system is the system that made me want to learn Unity, so I want to see it at its best! I want your system to take ALL the tedium out of setting up 2d game environments -- kinda like the UbiArt engine did for Ubisoft employees -- but your system would do that for everyone. I'm sure someone else can figure out the lighting/shader side of this thing (and maybe even share it with us!), but these 3 features (which should be simple to add) are sorely needed to add the final touch of polish and functionality Ferr 2d needs to be cemented as the sweetest plugin out there for 2d users.

 

Yeah, I focus on automagic so much that I completely forgot you even could ask users that sort of thing! Thanks for the reminder there =D I just added a few quick checks to the material editor that will ask the user if you want to switch repeat mode on. (Just found EditorUtility.DisplayDialog, pretty sweet =D)

This is still top of my wishlist, and has been for a while. I'm a little reluctant to implement it using the overlapping edges method. If I do inside elbows, I would really prefer to do it as a seamless edge strip, which would improve visual quality tremendously around corners. That does involve a significant amount of work, and could easily introduce a fair number of breaking changes to the material system. I have a lot of thoughts in this area that I haven't entirely sorted out just yet.

It might not be as large a deal to do inside elbows with the overlap method, I just need to come up with a good way to do it. I'll try and revisit this problem with 1.0.9

This one's also still on my to-do list =D Not for 1.0.8, but probably 1.0.9. In addition to this, I'd also really love to carve out areas from the inside of terrain objects! I don't think anyone has explicitly asked for that, but I know it would be useful =D

The trouble here is that the materials are quite simply very complicated to do perfectly. I often do things like adding extra padding to the edges to prevent harsh cutoffs, and completely non-grid based stuff too. It's definitely more complicated than I'd like, and I'm always trying to come up with a way to simplify this particular problem without sacrificing too much control! While I could go for a grid based solution, I often do something similar in Photoshop already through their grid tools. But I actually haven't seen many grid-based Ferr2D materials from real artists, (this is my personal observations, so, y'know) they don't seem to think that way very often. I kinda feel like that's the wrong direction to be traveling in. My current end goal for the material editor is to take a collection of separate edge images, and put them together on an atlas automatically with the correct padding.

I'm actually really thrilled you think that way =D And I really think you'll enjoy some of the new stuff that's coming in with the next version! I do have big plans for doing a good 2D lighting system, that's actually one of my stronger skills, I just need to find the time for it! After I finish this update and my next two plugins, I'll probably be hacking away at that again. I do actually have some semi-working prototypes of a 2D lighting system already~

 

Thanks for your quick response, and I am glad to see that you're interested in some of my suggestions!

Regarding suggestion #3, I think I probably misrepresented my idea somewhat. I'm not after a grid-based solution to this issue (to be honest, an atlas combined with what you're doing now is much better imho). All I was attempting to suggest was simply a variable input box that was more straightforward, though no less exact. For example, if the left side of the bounding box of your part was 32px into the image, and your right side of the same part's bounding box was 64px into the image, you could, as a user, input 32px for the width, and your plugin could add that width (internally) to the initial 32px to get the 64px coordinate for the right side of the box. Does that clarify it a bit more? This is something I could see easily making it into the next release. It's just swapping two absolute variable inputs in the editor for two relative ones -- that relative number can be added internally based on what's input by the user as the width and height for a part at some x and y coordinates. This simple change would make me want to throw all kinds of images together as an artist since I'd only have to remember 4-6 numbers for the top-left coordinate of all my parts -- and their roundabout sizes -- instead of 19+ *exact* numbers. Because of this painful process, the current way, for the artist and level designer, is very off-putting and tedious to work with. D:

And as for the inside corner issues in suggestion #1, your position is very understandable -- I would rather implement it the best I could too if I were in your position. But, at the same time though, as a user who needs to ship his game ASAP, I would rather have a poor solution to a problem like this than no solution at all... I think automatically adding in the corners as extra geometry overlays for these parts floating above the terrain points -- as terribly unoptimized as it might be -- would be a better solution than having nothing at all to fix the issue until you have time do it right, which may end up being longer than anyone expects. That said, even a temporary 'hack' sort of 'fix' for this issue is better than nothing at all. As an artist, I would prefer my visuals to *look* correct -- even if they're unoptimized. If you didn't fix the issue from your end soon enough, my game has to be shipped anyway. So now I would have to manually go in to each corner that didn't look right and manually drop in some graphic to cover up those corners, or spend hours tweaking my graphics until they look like they work for both outside and inside corners too. Once again, you could give the user an option here as to whether or not to use these extra corners. In my own case, I would absolutely use these (optimized or not) because visuals are the priority for me, and the faster I can get quality-looking visuals implemented, the better -- that's why I use your system!

Despite whether or not you have the time to implement these soon, I'm definitely still glad these are in the pipeline for 1.0.9 regardless. I'm willing to wait for further features, but these two things are so much more important imho. As stated before, ease of use is my priority -- and that goes from setting up, all the way through workflow and implementation, down to tweaking and modifying afterwards to achieve a satisfactory result. Suggestion #3 will help setting up and suggestion #1 having *some* type of implementation -- preliminary or not -- will help to achieve a satisfactory result for the end user (not perfect of course, but satisfactory is good enough when you need it now but have no real alternative).

I can get by with what we've got so far, and, personally, I can easily wait for all that other stuff -- but to be able to input coordinates for my textures more easily *and* have visually-pleasing corner cases taken care of automatically -- THAT is a godsend for an artist like me.

Thanks for all your hard work man! Even as it stands now, your plugin still rocks the socks off everything else out there dude!

 

Cap offset isn't working for me. Changing the value does nothing. Pretty weird... what could be wrong?

 

@awesomedata, I uhh, feel a little dense right now, I don't think I'm quite getting it yet. The material editor currently uses an x, y, width and height, so, top left and relative size, which sounds to me like what you're describing already? I feel like I'm missing something here.

I'll do my best to get inside elbows working with the overlapping edge method soon(ish). Maybe I'll do a release after 1.0.8 just for that by itself! This current version has taken me a lot longer than I hoped for, I'd much rather get back to smaller increments more frequently.

@fidelsoto, yeah, I made a pretty silly mistake with that bit. I made a post a while back with a fix for it:
http://forum.unity3d.com/threads/ferr2d-terrain-tool.204436/page-7#post-1580808

Also guys, I'm gonna be gone all weekend now. No wifi where I'm headed, so I won't be able to reply to anything until Moday =D

 

Wow, I guess I had a *really* old version still installed from when I tried learning Unity sometime back! I upgraded recently and hadn't seriously dug into your plugin again before I found this topic -- I was just going off of what I remembered and simply took a peek at the documentation and videos to refresh myself prior to finding this topic! I had assumed the tutorial videos & documentation on the basics of setting up the advanced materials were still valid since there was no note on a new version of the material editor on either the videos or documentation. Apparently I was citing that old documentation instead of actually digging into the engine again myself! Really sorry for the confusion man! Great job on the (new to me!) material editor! WAY better than I was even hoping for! I wish I would have been keeping up with this! I would have come back to Unity much sooner!

Also, I know others aside from myself will greatly appreciate your efforts in releasing a smaller update that includes elbow joints! You might want to put up screens/videos of the new material editor somewhere too! I particularly like the draggable size and placement features there! I think it really would help you sales-wise, not to mention helping others see just how cool and easy-to-use this plugin is!

Once again, thank you for your time and the consideration of your users in making this the best plugin it can be dude! I'm really looking forward to future updates!

 

I just submitted 1.0.8 for approval like, a few minutes ago, I have no idea how long it'll take, but I'll let you know as soon as it gets approved! In the meantime, here's a video of me using it, and the change log! =D

+Path Terrain
-Added per-node path scaling
-Added scene toolbar for improved UI experience
-Added a parallax edge tilt option
-Added lightmap UV support
-Added sharp collider corners option
-Terrain objects now use a single draw call on terrain objects that only use 1 material
-Added options for 2D Sort Layer and Order in Layer
-Default values are now editable in preferences for PPU and Smoothing
-Terrain collision mesh now updates while playing if modified in the editor
+Path
-Added multi select and edit
-Improved snapping (Ctrl is now snapping, delete is attached to Alt)
-Added smart snapping, for snapping to other path point axes
-Improved path point handle movement in non-2D views
+Shaders
-Added lit shaders + Lighting demo scene
-Added wavy shaders for underwater or wind effects
-Added tinted unlit shaders
-Improved unlit shader performance
+Editor
-Faster build time due to improved component finding
-Better prefab mesh saving
-Bug fixes and small improvements to the material editor
-Textures can now be resized without destrying the atlas
+Demos
-Added a blob shadow component
-Better loop seams on demo materials
-Added FerrLib logo

I should also be working on a few new tutorial videos this week, so if you have any requests, now is the time to throw 'em out there =D

 

WOW! This new version definitely brings A LOT of new cool features to an already awesome tool! Thanks mate!

 

Wow, the new update is simply awesome! Thank you very much!

 

Hey guys! The new 1.0.8 update just went live on the asset store, so go check it out, and let me know what you think =D You can read a little extra about it here on the new site: http://ferrlib.com/#Ferr2DRelease108



It's kinda funny to think the last update was almost half a year ago, but that just means I put a lot of effort into it =D



I also just made a -ton- of video tutorials for the new version, including that one transparency trick Unity does for those perfect edges!

The whole list of them can be found here:
http://ferrlib.com/page/Ferr2D_Terrain_Video_Tutorials

 

Hi. I have been following Ferr2D for a quite a while now and decided to buy it a few days ago. This tool is the best and I'm loving the new light shaders btw.

I'm having an issue though and it might not be Ferr2D related but here goes anyway. When I'm trying to move a physics-based object across smoothed Ferr2D terrain using rigidbody2D.velocity = new Vector2(5, rigidbody2D.velocity.y); it seems to get stuck sometimes. The higher amount of Edge Splits and Fill Splits (more smoothness), the more frequent my object gets stuck. It doesn't matter if I use Interpolation or not; nor does changing collision detection modes (discrete/continous) help. My hacked solution atm. is to 'nudge/bump' the object out of place with a small amount of force, whenever I detect that motion has stopped. Any idea why this happen?

I'm curious what else you have planned for the future of Ferr2D. The ability to specify stretches of terrain that hold animated grass and other decorative objects, so you don't have to go do it by hand afterwards, is a feature I would die for. I have a few other ideas, but that one is definitely at the top of my wishlist Santa.

Keep up the good work.

 

Hey! Your trouble with the colliders seems to be just sharp corners getting stuck at the verts. It's not a Ferr2D specific problem, I just double checked, you can see the same thing with normal polygon colliders.

My recommendation is to avoid sharp corners at the movement sides of your colliders! Use a circle collider, or a polygon collider with a few extra points to round down the corners. But you should probably avoid box colliders entirely!

I do have some plans for a more flexible edge system, so you'll have regular direction based edges (left, right, top, bottom), as well as extra override only edges. I should also be able to separate them into completely separate materials as well, so you'd be able to apply wavy shaders to specific edges. I haven't started working on this yet, but it'll probably be a good thing to toss in as long as I'm doing the inner elbow stuff!

 

I switched from a polygon collider to a circle collider and that fixed the problem. Silly colliders. Thanks

Do you have some hints or guidelines to the proper use of Edge Splits and Fill Split. Right now I'm running Edge Splits = 8, and Fill Split at the default (1).
Is is better to reduce the amount of Edge Splits and turn down Fill Split, or what do you recommend?

 

The defaults are my recommended settings =D But I'd say it very much depends on your materials! Wider edge segments would probably do well with extra edge splits~ If you do use extra edge splits, I would also recommend you turn up fill split (equates to less splits on the fill) to reduce the complexity of your colliders.

There's no firm or fast rule though, if it looks bad to you, turn it up! If it looks better than you need, turn it down. If it gets too slow, or too large (data size), turn it down~

 

Hi there maybe this has been asked before, but does ferr2d work well with 2d toolkit?

Thanks.

 

It works perfect, yes.

 

Hi , we finish our game with your Ferr2D asset. It works perfectly, we are very satisfied with the asset, it was very helpfull for us.
This is the result:
Android: https://play.google.com/store/apps/details?id=com.Indibit.hcf&hl=it
iOS: Coming soon (I will put the link later).