In 2020.2 we’ve streamlined our 2D menu items so they are now displayed in neat top-level menus for object and asset creation. We’ve also added menus for some of the features added more recently.
Important Note:
These new menus originate from the 2D Sprite, Tilemap and other 2D packages. If these packages are not installed, the menu items will not be displayed.
As part of this change, the deprecated Sprite Packer Window menu item has been removed. If you still require the window, you will need to add your own menu item with the following sample code:
using UnityEditor;
using UnityEditor;
public class SpritePackerMenu
{
[MenuItem("Window/2D/Sprite Packer")]
static void LaunchSpritePackerWindow()
{
UnityEditor.U2D.Sprites.Obsolete.ObsoleteSupport.ShowSpritePacker();
}
}
We have also upgraded our built-in 2D assets to 256x256 white textures with light grey outlines. These should be better for white boxing and prototyping levels as well as gameplay. These replace the previous 2D white 4x4 texture.
We want your feedback!
Let us know how the new 2D menus and assets work for you. Tell us what works and what doesn’t and what we might have missed.
Hey, just wondering. Why must the 2D packages be installed in order for the menus to appear this way? The new menus display seems a lot more intuitive and it would make sense for it to be that way in the base installation.
We can actually create UI mock-ups quickly with these … unlike the 4x4 versions lol both have there place though, as those versions are appropriately tiny for build size.
Hey DoctorShinobi!, thank you for pointing out that they are more intuitive!
The new menus in the base installation from 2020.2 should appear this way if we create a new 2D project. Does yours look like this?
Something worth noting is that if we install additional preview packages such as 2D Tilemap Extras from the Package Manager, we will also see additional menu items such as Tiles and Brushes from this newly installed package i.e. The menus get expanded with the newly installed package items.
They are not available by default because they are technically still preview packages. In other words, they are still in the early stage of development and not yet ready for production. These are great for testing purposes though and for us to gather feedback for better improvements. Hope this clarifies.
Problem
Isometric game here. These 2D changes are not very useful for this kind of project. From my vantage point, this adds one extra menu to navigate before I still need to replace the sprite with a decent prototype sprite.
Suggestion
What might be universally useful - for top-down / platformers / isometrics - would be allow us to change the default sprite for the Editor under Edit > Preferences > 2D. For me, that would mean an isometric box of the correct size/proportions for my game. This might also have an additional advantage where secondary textures are concerned: if I have the choice of sprite, then it will fit into the scene a bit better (e.g. NormalMap) before the final sprite is resolved.
Specifics
If set, “Custom Sprite” would show up at the top of the list. If not (or if assigned asset deleted), it wouldn’t show up in the list.
Hey Lo-renzo! You made some good points there. I did a quick mock-up based on your suggestions. Just to check, is this what you meant? (See attached image.)
I’m also curious about the point regarding the added advantage when secondary textures and NormalMap are used. Could you elaborate a little on that? Thank you!
[quote=“suxiangting, post:7, topic: 807030, username:suxiangting”]
Just to check, is this what you meant? (See attached image.)
[/quote]Yes, that’s exactly what I was thinking.
[quote]
I’m also curious about the point regarding the added advantage when secondary textures and NormalMap are used. Could you elaborate a little on that? Thank you!
[/quote]If I supply a custom sprite, then the SpriteRenderer would be populated with that sprite, so I’m assuming that the custom sprite would pull the Secondary Texture info as typical sprites do. That would mean that if there’s a NormalMap / Emission / whatever associated with that Sprite then the SpriteRenderer would correctly display it.
As a result, if someone is mocking out a scene where lights affect NormalMaps then that custom sprite would be way better to prototype with because it will respond to the scene’s lighting as intended. For my isometric box sprite, that means that I can put a few boxes down, adjust the SpriteRenderer’s color, and it’ll fit into the scene until the time where it’s appropriate to replace it with the final, non-prototype sprite.
This definitely sounds like a much smoother/ pleasant workflow and seems like an interesting proposal to the team too.
I’m curious as to what are your current workarounds to these limitations of using preset diamond sprites of standard size/proportions? It would be lovely if you have a quick screenshot too.
On a related note, we would love to hear where do you prefer your Sprite Shaders(Sprite Lit/ Unlit Graphs) to be parked at so that it’s most intuitive for you or best speed up your shader creation process.
Would it be:
Option 1: Within the Shader Menu together with the other Shader Graphs shaders Option 2: Relocated into the 2D Menu
I think it makes more sense for it to be Option1. If the rest of Unity was reorganizing their categories, i’d probably go for Option2, but since i’d always look for shaders in the shader section with the way everything is laid out currently, it should be there.
[quote=“suxiangting, post:9, topic: 807030, username:suxiangting”]
I’m curious as to what are your current workarounds to these limitations of using preset diamond sprites of standard size/proportions?
[/quote]The diamond sprite is the wrong isometric projection so it’s entirely useless. If it were the correct projection, it would only be useful for marking floor spaces b/c it has no volume (i.e. not an isometric box).
The workaround is to copy/paste a prefab. That’s not terrible.
Now that I’m thinking about it more, here’s an alternative suggestion to take into consideration. Prefab Wheel. The goal here would be maximize usefulness to prototyping, since that sounds like it’s the rationale for the new square/capsule/diamond/etc sprites.
Above is pictured weapon wheel UI found in many FPS games. Instead of weapons, however, the user supplies prefabs to the wheel. 1+ prefabs = maximum flexibility. The “Quick Prototype” shortcut (Ctrl+Shift+D for example) opens the wheel. Once a prefab is clicked, it’s placed under the mouse’s position at the time of triggering the shortcut, and the new instance is selected in the inspector for quick adjustment. The workflow: user points mouse where they want the new prototype to appear, uses shortcut, selects which prefab from wheel, and ta da it’s there. This basically allows the user to have several prefabs on hand for rapid deployment into the scene: there’s no need to sift through the Project folders.
By having custom prefabs for prototyping, it’s more flexible for whatever game type and may be useful further into development beyond just boxing out a level. So, I would solve my isometric problems by having two prefabs: isometric box and isometric floor. Just simple gameobjects with SpriteRenderers. But because user can supply full prefab, it’s more flexible than either Custom Sprite (earlier suggestion) or the current solution (square/capsule/diamond/etc sprites). Like TilePalette, the Prefab Wheel itself is an asset, allowing for switching between different Prefab Wheels for different scenes / contexts.
Oh! This definitely seems like an interesting train of thought! I really like this idea of having a customisable wheel/ radial menu that houses multiple prefabs. Well, this seems like a good robust solution that extends the functionalities beyond that one Custom Sprite suggestion.
I also like the idea where we can update the Prefab Wheel with different sets of prefabs for different scenes.
Thank you Lo-renzo! Let me bounce this off with the Editor team.
Thank you and I believe it’s for the same reason as Ofx360?
[quote=“suxiangting, post:14, topic: 807030, username:suxiangting”]
Thank you and I believe it’s for the same reason as Ofx360?
[/quote]I prefer Option 1 because I hate 3-deep menus for any menu I use regularly. If it had like 8 items in it then it would be acceptable because it de-clutters the 2-deep level, but here that’s not the case. Also my thought process is usually, “I want a shader… let me find the kind” rather than “I want to do some kind of 2D thing.”
So I’m just curious and I’m gonna sneak in another Menu Polling here. This time for the Lights Menu (in the Hierarchy Menu).
Can I presume that your preferred choice to place the 2D Lights (for both of you) that seems most intuitive or best speed up your lighting process would be Option 1 too?
Option 1: Within the LightsMenu together with the other non-2D lights. Option 2: Relocated into the 2D Menu.
I would also be curious to hear otherwise from anybody too.
Yup, Option 1 would be what i would intuitively expect and want. And also yeah, i think it would be a lot faster to access the lights in Option 1 than Option 2
I keep opening 2D to look for them there, before I realize that I’m in the wrong place and have to go to lights, so I’d like to have them there.
Ideally, we would be able to just remove all of the 3D stuff from the menu altogether when working in a 2D game. So no 3D objects, no 3D lights, etc. In that case I’d want to have the lights in their own category (ie as now, but without the 2D-> foldout)
Ideally we’d be able to fully customize the create-> menu, but toggles for “show 2D objects” and “show 3D objects” would go a long way.
