Godot: Node2D Scaling Handles Gone

[avencherus]

Windows 64-bit v3.1.alpha.custom_build.4b6846a

Started doing some node work in 3.1, and just noticed that the scaling handles are gone from Node2D. This makes certain tasks very tedious. Is this a bug or is there a new option, or change?

3.0 - This can be very handy for manipulating root transforms.

3.1 - Am I missing something?

Position2D seems to also suffer from this too, possibly many others. I suppose I like that it seems easier to select nodes by clicking, but now a lot of manual entry for scaling is needed.

Am I missing something?

Thanks.

[swarnimarun]

I think child-locked Node2Ds should be the only ones to have it cause otherwise, it will be a problem scaling the sprites and other children.

[groud]

That was done on purpose because a lot of people were complaining about wrongly rescaling nodes that were not meant to me rescaled. You can still manipulate the scale via the inspector.

[eon-s]

Nodes like Sprite should have it enabled.

I guess Sprite, AnimatedSprite and... something else needs easy scaling on 2D? Polygon2D and Line2D too, probably? (all these who draw something, since scaling use to be just for visuals)

[ghost]

@groud In my opinion it makes it much more difficult for those who know what they're doing. Do you have a link to previous discussions on this topic? I'd be interested to know more about the decision.

[avencherus]

@groud I see, I would hope that at least the functionality could be restored as an easy to access option from the tool panel. It is very very time consuming to punch in decimal guesses over and over to fine tune something from the root. I guess just imagine removing the feature altogether and then only allow scaling from the inspector text fields. This means that any scene that you make using a Node2D as a root, cannot be introduced and easily scaled on your canvas. You have to break away from drag positioning, and hunt down the scale input and use trial and error, return to dragging, repeat.

@Noshyaar Definitely agree, would like to know more about how this was decided. It seems unusual to me that it was decided that mouse scaling wasn't needed at all for certain nodes in the service of a greater good. It would've been nice if an option was at least left behind on the toolbar for those who use it heavily in their workflow. Just imagine trying to drag in and resize any asset scene that has a Node2D as a root. At the moment I'm inclined to think it is a bug, because this is the behavior of an Sprite with an empty texture. I sort of suspect that this behavior is bleeding over to any CanvasItem that doesn't have pixels being rendering.

[groud]

Believe me, we had a lot more complains with the previous system than we have now. People were complaining about wrongly selecting the node2d instead of the sprite, as the rectangle used to select node2d made no visual sense.

On my side, I plan to add a new scale mode to solve this problem. Probably a simple gizmo, similar to what we have in 3d.

[ghost]

Good to know that new scale mode is coming. I personally would appreciate it if the previous version was kept in for the time being.

[groud]

I think it won't happen, the new system still solves more problems than it creates. But I'll make this a priority after some bugfixes.

[avencherus]

@groud Thanks for checking back on this. I do appreciate that it is error prone, and node locking is probably not good enough. I have been on the receiving end of this problem many times, so I have no doubts of what you're saying. X)

The issue I'm having is that drag scaling was removed entirely, with no option. I would be very grateful if you added something, please let me know if you do.

A tool or mode with a modifier hotkey that enables mouse drag scaling (much like how the rotation option currently works) would be super welcome.

I just tried out some of my old workflow, recorded my work to see how fast I could create the same levels using scenes with roots of Node2D in 3.1. It takes me roughly 3 to 5 times as long to fine tune the scalings of my sub-scene assets. Much of our work is done with 2D nodes as roots in any given asset scene, so laying out level designs in next project in 3.1 is going to see a remarkable drop in productivity.

[nobuyukinyuu]

I know that with 3.0, I always have to lock the root Node2D in a scene because it can get in my way and the handles don't really make sense for this use case. (Always having the lock on screen is annoying, too.) If you have a node extend Node2D that needs handles, and if there's not an option for an extending class to re-enable them from a script or editor metadata, there probably should be.

As far as it being an editor setting, I can't imagine many use cases where people would want Node2D to ever really have these types of handles, since scaling and such typically apply to sprites and non-sprite objects which use its bounds to affect the canvas (such as screen-space shaders) are probably better handled by a Control like ColorRect..

If the node handles are being locked when it's a subscene of a larger scene, that's another matter, but a node-specific editor hint ala _edit_lock_ might still be preferable to an editor-wide setting.

[ghost]

I can't imagine many use cases where people would want Node2D to ever really have these types of handles

If your character consists of several body parts as different sprites, using generic Node2D to group them for easy transformation (e.g. changing facing direction) is very common. A transform handle would be useful, but doesn't need to be a bounding box.

[avencherus]

As far as it being an editor setting, I can't imagine many use cases where people would want Node2D to ever really have these types of handles

@nobuyukinyuu Both I and my partner use them that way quite frequently. It is very handy to have Node2D or Position2D as containers for sprite parts in puppet characters. This makes for quick and easy transforms to the composited set of pieces. In this use-case, once it is setup, we turn on the ignore selection of child nodes, and operate strictly on that Node2D/Position2D. It may be possible in some cases to work around this by having it as a sprite with a pivot as origin.

However, this applies also to nodes like KinematicBody2D and StaticBody2D. If I want to get back this functionality of resizing sub-scenes quickly and easily, I have to use a textured Sprite as the root, then the children are physics bodies. Those will have the scripts, that generally expose useful export vars. Now these will be a node deeper, requiring that the scene is right clicked and expanded.

Here are examples at least of the difference between 3.0 and 3.1.

[eon-s]

I like the idea of a modifier+handles like the 3D ones.

[groud]

I'm working on something like that, almost functional :

[avencherus]

@groud Awesome! X) Thanks so much for lending your time and expertise here, super grateful, and looking forward to this.

Had some questions if you don't mind.

Will it have uniform scaling and still interact with grid snapping options?

What are your thoughts on stuffing another modifier hotkey for it in the select mode (it looks a bit cramped wanted to know if you might have ideas)? I have found it to be very nice in Godot to have some ability with a mouse to quickly do all three from a single mode. I really like and would prefer these gizmos on 2D nodes without texture for scaling, and would be fantastic to get at them temporarily with a modifier key as well.

And something else came to mind as I was writing this. When canvas items with texture are children (Sprites), would it be possible or functional to add some sort of combined sizing rectangle around them? (There probably are some wrinkles about how much space around the origin would be added as a margin for the new handles to not intersect.)

I'm sure 3D modelers would be at home with gizmo, but it's a thought aimed at 2D artists, since most tools they're familiar with use a transform rectangle. I'm imaging something like this. Very curious what you think, and if there is even a smooth implementation of such a thing?

[groud]

Will it have uniform scaling and still interact with grid snapping options?

Uniform scaling can easily be implemented, I'll add it. Grid snapping wont work with those handles.

What are your thoughts on stuffing another modifier hotkey for it in the select mode (it looks a bit cramped wanted to know if you might have ideas)?

It is a good idea, but I fear like we're going to lack modifiers keys. Maybe we will have to go for a blender-like scheme, by using normal keyboard keys (like g, b, etc...) ?

And something else came to mind as I was writing this. When canvas items with texture are children (Sprites), would it be possible or functional to add some sort of combined sizing rectangle around them?

This was proposed by #20080, it's a good to have feature but quite difficult to implement. I'll give it a try someday, but it's not a priority. If this is implemented, the grid snapping could work in that case.

[avencherus]

@groud Cool, thanks for the reference topic.

I had made a temporary plugin at least until these changes go live. I found that holding ALT and using the mouse wheel wasn't a terrible solution.

Mouse Wheel Scaling Tool 1.0.zip

I see you got a PR up quite swiftly! It is looking great. I'm going to try to cherry-pick the commit from your fork tonight and check it out. Thanks again for this.