Open aaronfranke opened 3 years ago
IMHO option that defaults to off. I can see situations when it would be useful...
IMHO option that defaults to off. I can see situations when it would be useful...
My issue with adding new features that are disabled by default is that very few people will discover the setting in question, and therefore use the feature. It's likely that the feature will end up underused and with bugs that nobody discovers before months (if not years).
My issue with adding new features that are disabled by default is that very few people will discover the setting in question, and therefore use the feature. It's likely that the feature will end up underused and with bugs that nobody discovers before months (if not years).
I think that tutorials are a better way to handle it. We can make official tutorials too on Godot's YouTube channel, to coincide with the release that adds the feature.
It's nice when a feature is self-discoverable, but in professional software it's often a luxury as there are many people with many different approaches. This particular feature looks circumstantially useful, but likely not that good by default.
I like your idea that the new gizmo should be attached to the side of the screen in the direction of the object. Maybe we can show a small icon by default instead and clicking on it will toggle the feature on?
People say they are confused by the teleport; well, instead of the teleport.. you could have a "fast, smooth float" to the position, with the 2D line extending to the offscreen object. That would solve the 'confusing' part, and people would know the gizmo is connected to an off-screen object in a much more natural fashion without the teleport. I would make the extending line partially transparant though.
The primary use case for something like this, is object and kit bashing levels with larger, modular pieces. If you have small enough pieces on the screen; it's easy to keep the gizmo in sight, but if you're working with larger art pieces like big walls, fences, houses, or other modular components with pivot/center points far away from where you have to visually align... this sort of gizmo is super helpful.
One of the challenges of having it near the edge though, over the center; what happens if the mouse leaves the viewport?
Additionally, there is an option that Nvil has for this gizmo that may be useful to Godot. Below the viewport, there's a drop down menu for the orientation of the gizmo. You can set the gizmo to "always on object", "auto" (which is where it teleports when the object is off screen), "parent of the object", "center of object", "pivot point of object". So, you can kind of adjust how your gimbal behaves... for your specific world editing case.
As I said, it's circumstantially useful, definitely for large levels with large pieces. Maybe attach to the side of the screen or a 2D line as @LillyByte suggests? Because the jump to the middle is def confusing.
@Calinou
My issue with adding new features that are disabled by default is that very few people will discover the setting in question, and therefore use the feature.
@LillyByte
Additionally, there is an option that Nvil has for this gizmo that may be useful to Godot. Below the viewport, there's a drop down menu for the orientation of the gizmo.
That is what i mentioned in my previous PR comment. If this is implemented with the ability to be turned on/off it should be easily accessible (like the switch between global and local space for example) and not be hidden between hundreds of editor settings. But i also think it should be off by default, because most people don't need this and if you are coming from other 3D software (i never heard of Nvil before) this is pretty weird (but also useful 🙂).
That is what i mentioned in my previous PR comment. If this is implemented with the ability to be turned on/off it should be easily accessible (like the switch between global and local space for example) and not be hidden between hundreds of editor settings. But i also think it should be off by default, because most people don't need this and if you are coming from other 3D software (i never heard of Nvil before) this is pretty weird (but also useful 🙂).
Yeah, various modeling packages offer it, since it makes position editing a way easier and more efficient. It's one of these simple, unassuming features that you don't realize you want or how much impact it can have until you're actually using it... without realizing it. :D
Though, it's definitely an artist usability tool, more than anything else though. If you're not a heavy art person, you probably wouldn't appreciate it as much as someone creating detailed 3D levels.
this is a pretty good addition IMO.
It has already been mentioned, but a dotted line towards the object would probably help with the overall clarity
I updated the PR (https://github.com/godotengine/godot/pull/48307) with a line that is drawn between the object and the gizmo. Hopefully when the object is off screen, what happens with the gizmo will be more clear. Please let me know what you think.
Things still worth discussing (I suggest testing the PR before giving more feedback):
If people can potentially find this feature annoying, we can add an option to disable it. I'd like to gather more feedback on this first though to avoid a potentially rarely-used setting. This feature should be harmless worst case in situations I can think of.
The behavior of snapping to the center vs slowly moving to the center vs stopping at the edge of the screen.
Personally I don't like long transitions, and coding it would be more complex than the code of the current PR. I think it's probably fine as-is. It can be done if it's desired though.
I don't think sticking to the edge will work as well as people are thinking it will. If the gizmo is located at the bottom-left corner of the screen, then the left and bottom sides of the gizmo won't be on the screen. I guess we could stick it to the edge with some margin to fix this, but this would also add complexity that I'm not sure is worth it.
The feature was removed, but I have remade the pr and had some testing done.
Describe the project you are working on
A 3D game in Godot that has objects that need positioning using the transform gizmo.
Describe the problem or limitation you are having in your project
If the center/pivot/origin/etc of the object is not visible on screen, the gizmo currently isn't visible either. In some other prorgrams, the gizmo is always on screen. For example, @LillyByte uses Nvil which does this.
Describe the feature / enhancement and how it helps to overcome the problem or limitation
The proposed feature is that, in cases where the gizmo currently is not on screen, the transform gizmo would be moved to be somewhere on screen. This can be helpful when trying to position an object when the center isn't on screen. For example, a character whose origin/pivot/etc is in the middle, but your camera is pointing at the feet that you're trying to align with the ground.
There are some open questions about where exactly to put the gizmo, if it should be put in the middle of the screen or on the edges. One argument in favor of placing the gizmo on the edges is to avoid teleporting the gizmo to the center, however there would instead be weird behavior if the gizmo was directly behind the camera.
Another question is if there should be a line pointing to where the object is. This makes sense, although I'm not sure what would be the proper way to do this inside of the 3D editor (should we use a 3D line, if so how? Or a screen space Line2D?).
There is also an open question about whether this should be a setting, as some users may not desire this functionality. If so, what should be the default setting?
Describe how your proposal will work, with code, pseudo-code, mock-ups, and/or diagrams
Here is my work-in-progress implementation: https://github.com/godotengine/godot/pull/48307
https://user-images.githubusercontent.com/1646875/116612981-27f1fb80-a906-11eb-8fe7-a226bcef8ae7.mp4
If this enhancement will not be used often, can it be worked around with a few lines of script?
No, it's part of the 3D editor.
Is there a reason why this should be core and not an add-on in the asset library?
It can't be, it's part of the 3D editor.