Godot: 3D Workflow Issues

Created on 8 Apr 2019  路  12Comments  路  Source: godotengine/godot

There has been a ton of great work on the 3D side of Godot. There are still a few things that really limit the speed of the workflow.

  • Accidentally selecting the collisionshape or mesh of a rigidbody or kinematic body instead of the parent. I don't know what the solution would be though. There might be instances where you would want to be able to select the child (perhaps the player is holding a weapon or item). This is one of the areas where the node based structure seems to slow down workflow.
  • Inability to scale a parent of a collision shape, or scale a rigidbody. Having to change the extends of a collision shape and scale the mesh separately is tedious. Being able to scale one item and scale all of it's children is intuitive and user friendly.
  • I would love to have an editor option to put the transform at the top of the inspector. I reference it more than any other item in the inspector.
  • The ability to snap to vertices of other meshes. This is a huge time saver when laying out a level. Again, the node based system might make it a challenge since the mesh we are moving isn't always the parent node, and so we might snap the mesh to the correct location, but leave the parent and collision shape behind.

I love the coding experience in Godot and the UI system works great, but the workflow for 3D just feels like I am fighting against it rather that it working with me.

discussion enhancement editor usability

Most helpful comment

I understand that the items in the inspector are organized by node inheritance, but having the transform so far down and collapsed by default makes getting to it cumbersome. I realize that it isn't perfect for every workflow, but I would like to have an option to move (or pin?) the transform to the top. This is especially important since selecting items in the viewport often selects a node you didn't intend to click.

On a side note, I still think the transform takes up more space than it needs to:
image

All 12 comments

Can you talk in detail about?:

I would love to have an editor option to put the transform at the top of the inspector. I reference it more than any other item in the inspector.

I understand that the items in the inspector are organized by node inheritance, but having the transform so far down and collapsed by default makes getting to it cumbersome. I realize that it isn't perfect for every workflow, but I would like to have an option to move (or pin?) the transform to the top. This is especially important since selecting items in the viewport often selects a node you didn't intend to click.

On a side note, I still think the transform takes up more space than it needs to:
image

Would it make sense to add another panel (similar to the node inspector) that only shows certain properties if they're available? Such as translation, rotation_degrees, scale, etc.

Something like this:
godot_transform_panel

In far most cases, you don't want to use transform as-is, and just use the gizmos and stuff, so having it all the time visible does not make much sense. If you _really_ want this, you could make an add-on very easily and put it in the asset library.

What I thought for a while that could be done is either a button or an option in the menu to "flip" inheritance, so base classes are first, in case you are editing a lot the base class and not the derived ones. In this case, it will just look like Unity, which has them backwards.

The problem with using the Gizmos in 3D is how easy it is to select the wrong node of an item. I would prefer to use the gizmos, but it's not always user-friendly, and without snapping to meshes, it's sometimes hard to be as precise as you want.

@turtletooth reduz mentioned doing the inheritance in reverse order is quite easy. Do you think trying a build of it with that would help?

Reduz also wants more evidence it is a problem.

https://github.com/godotengine/godot/blob/a20235aeb02c0c9e5ce58c0236f88a19865d571c/editor/editor_inspector.cpp#L1456

Change:

"object->get_property_list(&plist, true);" to "object->get_property_list(&plist, false);"

Note the scripts property is in the wrong place, but it's a cool proof of concept.

NoVOhGX

@fire Thanks for looking into this. I'm not sure this is actually any better since there is still so much noise around the transform, such as the Node settings and the Matrix in the transform.

I think that all of this is just struggles with the Node based system of Godot compared to a component based system such as Unity. In a component based system, you never have to worry about clicking the wrong node in the viewport - each object is all one thing. Whereas in Godot, unless you sub-scene everything, it's very easy to get mixed up in the child nodes. The same goes with the inspector - in a component based system, it's not bound by an inheritance based structure that adds noise and complexity to the interface.

There is so much I love about Godot- I just think some user experience needs tweaking. I get that it will never be a component based engine, but surely there are things that can be done to make the workflow smoother.

Whereas in Godot, unless you sub-scene everything, it's very easy to get mixed up in the child nodes.

This might be related to the inability to lock nodes and/or make their children non-selectable in 3D, both of which are already possible in 2D.

@Calinou: Isn't there a PR for locking in 3D?

Just want to throw my hat in the ring on this, I'm for having the transform at the top too. One of my biggest issues with the inspector is the lack of consistency in placement of the classes. The order will always be the same, but the placement would be different. So, some nodes, the transform would be closer to the top (because the inheritance tree) and other times, it'll be way down, or sometimes in the middle. This creates a fairly jarring experience for me personally. Like @turtletooth, I use the Transform the most so far (I actually just stayed up all night from (9:30 PM to the current time of 8:05 AM. This is GMT - 5 by the way) exclusively working in the 3D section.

@fire & @reduz I for one would appreciate an option to at least invert it. As it appears that I interact with base classes more frequently.

image
@Duroxxigar can you contact me about making a proposal for inverting the properties?

Was this page helpful?
0 / 5 - 0 ratings