[RELEASED] U2DEX: Unity 2D Editor Extensions

Hi there @vjj, I'm sorry to hear you're having some trouble with U2DEX. I'll do my best to touch on all of your points.

Values for the grid size shouldn't be less than 1, in most cases, so it's actually clamped at 1. Unity doesn't handle very, very small numbers like that too well (especially with gizmo rendering) as you've seen first-hand. Generally speaking, when doing a 2D game you should be using a scheme of 1 pixel = 1 unit to get crisp rendering. If you're trying to use a grid size below 1 I'm curious as to why you're working with such a small scale.

That would be because at a pixelPerMeter setting of 10,000 you would be rendering something close to a few million grid lines! Pixels per meter reference the 1 pixel = 1 unit measurement I mentioned above, setting it that high is very, very unusual. The Editor isn't very responsive when rendering lots of gizmos, and a couple million lines at that resolution would definitely qualify as "a lot"!

By changing the grid scale you cut down the number of grid lines rendered by quite a bit. The Unity Editor could handle rendering the grid lines now.

Clamping the grid size is enforced when the any value in the Grid Inspector is changed. You're seeing your grid size being clamped by U2DEX here.

That would be because pixelPerMeter works roughly like gridSize/pixelsPerMeter. So a grid size of 1 and pixelsPerMeter of 100 would give you the result of 0.01. Your massive pixelsPerMeter value was simply too large, and the return value was being clamped at 0.01 to try and avoid low-number floating-point errors.

The grid square issue is due to having your gridSize at 0.01 and the gizmos clamping to un-even values. As for your raycasting and runtime issues, U2DEX doesn't operate at runtime (it's purely an Editor Extension) so I'm not sure what's going on there.

I'd be interested in hearing the issues you had with snapping. I would wager that they're due to the impossibly small gridSize, though.

You're not crazy, but having your game scale so small that you need a gridSize of 0.01 to operate is definitely something I would consider "unorthodox", especially if you want clean pixel rendering. (Not to mention the floating-point weirdness you'll start to see down at the very, very low numbers)

As for something you can try, if you're very brave you can try and change U2DEX's clamping code to allow you to go down to 0.01. This isn't officially supported, but if you really want to give it a shot this is what you'll need to do:

1. Open up the u2dexGridInspector.cs file
2. Find the FixIfNaNOrZero method towards the bottom of the file.
3. Change all of the "1"s to whatever number you want to be the bottom of your clamp.

Disclaimer: I have no idea if this will cause issues with the current version of U2DEX. In all honesty, there will probably be edge cases as it wasn't designed for such small-scale work. You'd be much better off keeping the grid size at 1 or above, and that would be my official recommendation.

If you want me to take a look at your project and see if there's an easy way to make all of this work, feel free to PM me here, or email me, and we can work something out. I don't want to leave you out in the cold, so to speak!

 

Hi there, thanks for quick and detail response! I decided to give it another try. If I understand things correctly the root cause of all observed behavior is that I tired to use grid size less then 1.

So that made me question pixelPerUnit = 100 that I have on my tk2dCamera. I choose this value long time ago in the beginning of the project. Embarrassingly I don't remember why. Probably I saw a suggestion on the forum or most likely my assets where not showing up until I changed that to 100.

So when I set pixelPerUnit = 1 on both camera and U2DEX preferences and also have 1 as a grid size I think everything works beautifully! Is that what you would say recommended default settings? If so I have to redo scaling for all my assets as all of it is invisible at pixelPerUnit = 1 E.g. if I have a triangle 20x10 pixels I have to scale it to size 100 for it to appear normal size. Does that sound right to you? I know it is more of a tk2d question, but maybe you know...

Also with auto-snap enabled I can see how it is snapping sprite to the grid and often times I see values like this in position -7.071065 x 21.2132 For some reason I was thinking that when everything is equal 1 (pixelPerUnit, gridSize) that I would get whole number in the position, no?

Thanks!

 

Hey there @vjj, thanks for getting back to me! Once again, I'll try to touch on all of your questions.

Correct. Honestly, using a grid size less than 1 is rather unusual, as you tend to use the 1 pixel = 1 unit methodology I mentioned earlier. If the grid size is less than 1, then you end up with a fractional pixel per unit, which isn't ideal.

One thing I should mention is that U2DEX's pixelsPerMeter setting isn't tied to 2D Toolkit's. It's perfectly fine (and sometimes better) to have separate settings for U2DEX and 2D Toolkit (as, if I recall, 2D Toolkit's PixelPerMeter setting affects quite a bit of the 2D Toolkit experience).

Great! I'm glad to hear that it works correctly with a grid size of 1. I'm not sure I would say that 1 should be your default, but 1 should definitely be the minimum. Usually, the grid size should represent something close to the size of your sprites. So, for example, if you're making a game where a lot of your sprites are 64x64, your grid size could also be 64x64, and you'd have a grid that closely matches your art.

Make a backup first! But, yes, if you designed your assets for your very, very small pixels-per-meter setting you will likely have to scale them in Unity, or resize them in the art program of your choice. If your current pixels-per-meter setting is 100 and you change it to 1 then you would likely have to scale things up by a factor of 100 to achieve the same scale as before (as you found out). I'm not sure if I would recommend setting the 2D Toolkit setting to 1 (as I'm far from a 2D Toolkit expert) but it may work for you. The pixels-per-meter setting tends to vary per game, and also depends somewhat on how far you have the camera zoomed in or out.

Depending on your grid size you can have fractional values. Generally you get integers (or clean half floats, e.g. 1.5f) but sometimes you can end up with fractional values depending on your object size and the size of the grid. You can always try to set a position manually to clear the values (e.g. set the position to -7, 21).

No problem! One thing I do want to mention is that a grid size of 1 is still rather small. Generally you would see sizes more in line with 32x32, 64x64 or 128x128 depending on the size of your artwork. It's not a problem, but I thought I would mention it.

Also, you don't have to use the Pixels Per Meter setting in U2DEX. In fact, in your case, you may be better off disabling it, as setting it to 1 is pretty much the same as having it off.

 

Hi, sorry I'm back with the same issue again. I tired to remember why I choose to use pixelPerMeter = 100 in tk2dCamera and I remembered that it has something to do with unity physics. I found on tk2d forum http://2dtoolkit.com/forum/index.php/topic,3498.msg20148.html#msg20148 where the author of the framework says: "2D physics in unity is speed limited. If you want to use 2D physics, use 100 pixels per meter or somewhere around there." Yeh, I use 2d physics and ended up using pixelPerMeter = 100 value for both tk2dCamera and my sprite collection.

The problem is when you add U2DEXGrid to the camera that has above configuration even the gridSize = 1 produces giant squares. I can change that by matching pixelPerMeter = 100 in U2DEX preferences but this brings me to square one and a slew of issues for when the grid size is less than 1.

I made a simple project with 1 scene and 1 sprite on it and no physics or anything else. I will send it to you over PM. Can you please take a look when you have time? I disabled pixelPerMeter in U2DEX preferences so that you can see "giant squares" issue i'm talking about.

Thank you.

 

Sure thing, I'll take a look shortly! Thanks for creating a repo project!

 

Hey @vjj, I just finished taking a look.

I don't really see anything wrong with U2DEX. The grid cells are definitely a bit large, but not unusable.

Unfortunately, there isn't really anything you (or I) can do to make the grid much smaller than 1. At that point, each line's position becomes very small float numbers, which end up with floating-point errors (as you saw with the uneven grid cell size earlier).

If you want your 2D Toolkit Pixels Per Meter set to 100 you could change the Zoom Factor on your 2D Toolkit camera to follow suit. You could:

1. Resize your sprites to a larger, more normal size.
2. Set your camera's zoom factor to 0.01
3. Use U2DEX with a grid size of around 50

Doing the following should solve all of your problems, and display exactly the same within your game view. I'm not sure if it's feasible for your project, but I can't really think of anything else.

Sorry that I couldn't come up with a "magic bullet" solution. Let me know what you think of the zoom factor idea!

 

Ha, setting zoom factor to 0.01 might actually work. I will need to tweak some things around. The sprites are normal size I can just change Pixels Per Meter = 1 in Atlas settings and it will be normal size. I will play around with this more.
Thank you for the idea!

 

No problem! Good luck!

 

Just finished running our usual gauntlet of compatibility tests, and I'm pleased to say that U2DEX looks to be fully compatible with Unity 5.2 (at least based on the current beta). If you're brave enough to be using the beta in a production environment, U2DEX won't hold you back!

 

We've just shipped U2DEX v1.33 to the Asset Store team!

You can read more about it in its forum thread here, and if you've purchased it from our itch.io page you can grab it right now.

For those of you in production environments that need this release immediately, feel free to get ahold of us either via a PM or email.

I'll also update everyone when it's up on the Asset Store, which should be in 5-10 days.

 

U2DEX v1.33 is now live on the Asset Store!

New users will get the newest version automatically, while current users may have to download the update through the Asset Store.

 

Hi,
I just bought your asset and it works really nicely. I was wondering if you have plans to add some type of utility to build tilemaps faster. While the snap to grid makes lining tiles up easy, this tool would be even more helpful if instead of having to drag tiles individually, we could paint them on with brushes.
Thanks and great job.

 

Hey there, @MetallimaN! Thanks for buying U2DEX -- it's great to hear that you're liking it!

As per your question, there are currently no plans to include a tilemap editor (as that's a pretty big undertaking, and a bit outside the scope of U2DEX). Instead, a built-in, native tilemap editor is actually planned for Unity 5.4 (here's the roadmap, and here's its feedback page), so U2DEX will do its best to support that when it's available.

I know it's not exactly the answer your were hoping for (sorry!) but the Unity Tilemap editor is actually coming along very nicely. If you have Unity Pro you can get access to the 2D Beta builds if you need it immediately.

Hopefully that answers your question! Feel free to drop back in if you need something else!

 

U2DEX is 50% off for the day! Now's a great time to jump in if you've been waiting for a sale!

 

U2DEX's 24 hour sale is roughly halfway over! Time's running out to grab it at half-price ($7.50)!

 

Hi,
Just bought U2DEX and I have a quick question.

Just did some quick tests. I used snapping function to put some sprites on the map then tried to play and move sprites during rumtime.
The sprites just kept being dragged back to their snap position because of snapping function is still working.

So, does this means I have to turn off snapping flag while running the game? (If the sprite needs to move.)
Thanks.

 

Hi there @solakila, thanks for buying U2DEX!

Snapping shouldn't alter any runtime code/positioning. To be clear, do you mean moving the sprite via the editor at runtime, or through game controls (controller, keyboard, etc.)? Snapping should most-definitely not be affecting any game controls (as it's an editor script).

It's a bit late here, so I may not get back to you tonight, but I'll get back to you as soon as I can.

 

Hi, thanks for reply.

Here's my scene setup.

A grid object and a simple sprite.


I attached rigidbody2d and a box collider with my own test script.




Test condition:
-Hit play
-Call BeginTestMove()
-Test object moves by TestMove(), using rb2d.MovePosition

And this test object just keep resets it's position while snapping flag is on.

Code (CSharp):

1.     void FixedUpdate()
2.     {
3.         TestMove();
4.     }
5.  
6.     public void BeginTestMove()
7.     {
8.         testMove = true;
9.     }
10.  
11.     public void TestMove()
12.     {
13.         if (!testMove || rb2d == null)
14.         {
15.             return;
16.         }
17.  
18.         rb2d.MovePosition(rb2d.transform.position + speed * Time.deltaTime);
19.     }

 

Hey there @solakila, I've been able to reproduce your issue (looks like something changed recently that broke the old Play-mode detection). Thanks for catching it!

If you want to PM me your email, I'll email you the fix to make sure it works for you as well.

 

Hi,
I have several problems with U2DEX.

In preferences the options that setup viewpoint grid disappears (and sometimes resets to its previous color) on every game run, claiming there are no camera grid component present. The only way to bring the options back is to select the camera (containing the component) in the hierarchy - until the next play-mode.

Another problem i have is that I setup per-tile grid and snapping (1 unit = 1 tile = 1 grid, snapping at 0.5 units). And i can't understand the intended behavior. When the snapped object(sprite or custom) is selected in the hierarchy its coordinates are reset to the closest snap point on every frame but when the object is not selected it moves freely. Is there a way for snapping to work only in edit mode and to be completely disable on play mode? My idea is to use U2DEX as a helper for tile/level editing, but some of those level objects are supposed to be "freely" movable/dynamic once in play-mode.

Sometimes when "Enable the U2DEX Inspector" option is just ticked ON my objects with sprites (child of the "main" character object) are moved to a different position the moment they are selected in the hierarchy. If I try to manually edit the coordinates of this same child/sprite object then the number I enter is modified by some coefficient and then stored in the inspector field. I fixed it by disabling the option and re-enabling it. It doesn't happen on every enabling of the tick.

Unity v.5.2.3, U2DEX v.1.33


Edit: Another thing i just noticed is that disabling "Enable the U2DEX Inspector" for some reason disables the snapping even if "Enable Snapping" tick is ON.

 

Hey @Nikaas, sorry to hear that you're having trouble with U2DEX. I'll try and address all of your issues.

If I understand you correctly, this happens when Play-mode is started (i.e you start Play-mode, and the grid area of the preferences gets flushed). Unfortunately, there isn't much that can be done about that. What's happening is that the grid options are really just grabbing the display options from the component (which has to be selected for the Preferences window to find it) and when Play-mode is started the link between the two objects (Preferences window and Grid component) gets broken. I can investigate and see if there's a workaround.

There was a change in some recent Unity patch releases that changed how the old Play-mode detection worked. The intended use is exactly how you outlined -- U2DEX is an editor tool and shouldn't be running in Play-mode. This issue has been fixed, but not released yet. If you want to PM me your email I'll send you the fixed file, so you can see if it resolves your issue.

I'm not quite sure what you mean here (I can't reproduce it). Would it be possible to get a repro project so I can see the issue in action?

Unless I'm misunderstanding, that's intended. When you disable (or untick) the U2DEX Inspector that essentially disables all of the advanced Transform functions of U2DEX. (i.e. U2DEX won't override the Transform Inspector anymore).

Hopefully that shed some light on what's going on. If you PM me your email I'll send you the fixed file for the Play-mode issue. Otherwise, I'll need a bit more information (and optimally, a repro project) for the third issue, as I can't reproduce it.

Thanks for using U2DEX!

 

I got it what's happening. I have composite objects where some of their child/parent objects are snapped to the grip and others aren't. After "Enable the U2DEX Inspector" is enabled I must select all child objects that are snapped so they to be updated to align to the grid before I edit any child/local coords. Otherwise weird things happen between world and local coordinates. Its not a bug, there is just no way around it.

Sent you PM with my email for the play-mode snapping fix.

 

Ah, I see. In that case, I would recommend having a top-most Parent object with Snapping enabled, so you can move your whole object hierarchy, but maintain the per-child-parent relationship. This would be a good time to use the "Applicable Classes" feature to enable the U2DEX Transform Inspector on your "dummy" parent objects.

I also responded to your PM!

 

That's what I did - i align the parent with a custom class and keep child on the intended non grid position. But if i select child with sprite it's moved from its intended position and aligned to the grid. Is there a way for you to add an option to disable sprite aligning or point me to code changes i need to make to disable it?

 

Couldn't you just disable the snapping on the child sprite-based object via unticking the Enable Snapping box on the object's transform? (That way you can leave Snapping enabled on the parent object, but disable it on the child objects)

Or am I misunderstanding the situation?

 

I didn't notice that tick. It's exactly what i want.

 

I currently have the U2DEX snapping feature enabled and applied to several classes in order to place objects pixel-perfect within my scene. Is it possible to snap while editing colliders? I'd like to move a collider point while editing the collider based on a certain increment, in my case, only 1 pixel at a time. If this is possible, what class should I apply it to?

Thanks!

 

Hi there @AssembledVS!

U2DEX can't interact with the individual collider points, unfortunately. If you have your colliders on a separate GameObject, you can still use the U2DEX Transform Inspector to control where the overall colliders are positioned, but you can't snap individual points.

It's been a while, but I seem to remember that holding Shift while editing points would snap them, using Unity's built-in unit metric (i.e. it most-likely won't match up with U2DEX's Grid), but I'm not sure if that still works.

Sorry about that!

 

You can create polygon collider using script or look here, it may help you.

 

Thanks. Yes, I can already control the positioning of the colliders, just not the points themselves. I'm not sure if Unity's snapping works for me, either, as I just tried it.

The link's solution seems like an interesting one. Thanks! Though it is odd that Unity doesn't allow such snapping or editing of points within the editor by default, as it seems like a trivial thing to implement.

 

We've just shipped U2DEX v1.40 to the Asset Store team!

You can read more about it in its forum thread here, and if you've purchased it from our itch.io page you can grab it right now.

For those of you in production environments that need this release immediately, feel free to get ahold of us either via a PM or email.

I'll also update everyone when it's up on the Asset Store, which should be in 5-10 days. I'd also like to thank @Nikaas for helping test this new version. Thanks!

 

U2DEX v1.40 is now live on the Asset Store!

New users will get the newest version automatically, while current users may have to download the update through the Asset Store.

 

I am having a difficult time snapping canvas objects to the pixel grid (for GUI). I have entered both Canvas and RectTransform to the "Applicable Classes." It seems to snap visually, but the positions are not rounded to nearest ints, as they are for all other non-canvas objects, and when I run the build, it is obvious that the objects are not pixel-snapped (fuzzy edges, float positions, etc.).

Does U2DEX work for canvas objects? I do not see an "Enable Snapping" option in the inspector for canvas objects as I do for all others.

 

Hey @AssembledVS!

I just took a look and it looks like RectTransforms don't play too well with U2DEX. The Applicable Classes functionality still works (i.e. it'll find the RectTransform class and attempt to hook into it) but there's some differences in functionality that U2DEX can't map snapping to easily.

Due to U2DEX supporting older Unity versions, I can't readily add 4.6+ specific code for this just yet (it would require a bit more than a couple version-specifc #ifs). The good news is that the next major version of U2DEX will be only for 4.6+, so I'll be able to investigate getting this supported at that time.

Sorry about the inconvenience! I've added it to the to-do list, but I can't promise anything until I've had a better look at the internals.

 

Thanks. I will overlay a pixel grid and position elements manually for now.

 

Hi again.

Is it possible to have two or more grids of different sizes in view at once? It would be helpful to break down my 32 x 32 pixel grid into smaller pieces, for example, while keeping the 32 x 32 grid. When attaching two U2DEX scripts to my camera, changing the size of one changes the size of the other, though color can be changed independently.

 

Hey @AssembledVS, I didn't get a notification of your post. Sorry! (Not to mention the whole new forum fiasco...).

Sorry for the (very) belated reply. Unfortunately, you can't do what you're asking. Since snapping it tightly coupled to a grid (and vice-versa) it's not possible to have more than one size of grid. That might be something to look into in the future, though!

 

Hey everyone, we just launched the free, open beta for our latest Asset, uTemplate! You can read more about it in its WIP thread, here.

With it, we've made some improvements to our internal, shared library of code (that all of our Assets use) so when it's out of beta U2DEX will be getting an update as well!

 

U2DEX v1.45 is now live on the Asset Store!

New users will get the newest version automatically, while current users may have to download the update through the Asset Store.

You can read more about it in its forum thread here.

 

There seems to be some problem with custom classes not being detected and the class list is not updating properly on adding/deleting.

 

That's certainly not good. I can't seem to reproduce it -- what version of Unity are you on?

 

Actually, I might have an idea of what's going on here, @Nikaas. I think I have a fix for your problems, please send me a PM with your email address and I'll send the fix your way ASAP.

 

The new version has moved u2dex into a DLL. When I purchased this asset I had access to the full source code. I like the idea with the DLL, but could you provide the source code with the package, too (maybe an additional zip file)?

 

@UnfinityGames : Sent you a PM.

 

Hi @Ruekaka! You are correct that U2DEX is now included in a DLL. This was for multiple reasons:

1. Unity's import process is extremely fickle in regards to .meta files, moving things around, etc. I have a lot of support emails coming in that are due to a bad import, and are usually solved with a simple re-import. With the DLL, this is much less likely to happen.
2. I wasn't a fan of sticking the required images in Editor Default Resources. It's the "correct" way to handle it, but it cluttered up the project root, as the folder can't be moved. Instead, the images are now embedded in the DLLs, which will give you a nice, clean project root as you can move the Unfinity Games/U2DEX folder anywhere in your project.
3. Shipping U2DEX as compiled DLLs drastically speeds up Unity's time spent compiling U2DEX's code on every Editor refresh.

Now, I understand that moving to DLLs can provide a bit of uncertainty, and after having seen other Asset Store developers come and go I totally get wanting a "Plan B" in case something breaks and I'm not around to fix it, so I want to explain how this is going to work:

• I've been supporting U2DEX for over three years now, and I have no plans to abandon it, or any of our other Assets.
• In the event that I do eventually stop supporting U2DEX, or any of our other Assets, all source code for the unsupported Asset will be published, for free and for everyone, under an open-source license.
• If you purchased U2DEX prior to version 1.45, and would like the source code for one of the older versions, I will send you the source code for that version. Source code is not being provided for versions 1.45 and up at this time.

Hopefully that clears things up!

 

Thanks! I sent you the new version. If this works like I think it will, I'll push it to the Asset Store team for review ASAP.

 

It looks like the new version fixes the issues brought up by @Nikaas. Thanks for bringing them to my attention, and for testing the fix!

U2DEX v1.46 has been submitted to the Asset Store team for review, so hopefully it's up in the next few days. If anyone needs the new version immediately, send me a PM here, or contact us via our website and I'll get you the new version.

 

O.K, thanks for the information.
I will send you a PM for the old sources.
Thanks.

 

I sent you an email with what you requested. Thanks for getting in touch!

 

U2DEX v1.46 is now live on the Asset Store!

New users will get the newest version automatically, while current users will have to download the update through the Asset Store.

You can read more about it in its forum thread here.