Better layout design for physics constraints

Hello!

I come here to ask for any suggestions for a better layout design of a physics constraint node that I am creating. This node has a selection option to select the type of constraint, based on which other options/variables are populated.

All options look good, however, the “Spring” option has 6 Vector inputs and this makes the node long and non-design friendly. Any suggestion on how one might improve the layout, in this case, would be helpful.

Below I share some images of this node for different opions, including the “Spring” option.

Fixed:
Capture0

Piston:

Spring:

3 Likes

Hm, maybe you can create a custom vector socket that doesn’t show direct inputs. It would be less flexible but that is a hell of a node^^

Yes, it is one hell of a node :sweat_smile:

I think I will use a vector Array as an input socket. But I somehow need to specify the order in the node. Is it possible to render simple text just above the input in the node?
For example:

Linear upper limits[X, Y, Z]
Linear lower limits[X, Y, Z]
Angular lower limits[X, Y, Z]
Angular upper limits[X, Y, Z]
1 Like

Not above each input I’m afraid. You could change the socket label if that helps.

1 Like

What if we make subtypes?
After selecting Spring, a drop-down list will appear indicating the combinations or simply the number of input parameters. If the node is completely “opened”, then it will be a little longer because of these options, but if everything is not needed, then it can be shortened.
Or split the node into several nodes, the child nodes will have parameters, and settings can be added to the main node via trust and the Dynamic type.

3 Likes

@E1e5en Thanks,

I like the sub-types with the split idea more. Since the constraint can be properly split into different types.

I understand what a Dynamic type is, but I don’t understand what a “via trust” means.

2 Likes

It would be correct “through child”. My mistake, sorry

1 Like