It looks like Blender is always drawing the arrows at the same size over the object and not scaling them when the user is zooming in and out. Would that be a solution for OpenMW-CS too?

I think adding keybindings for move, scale and rotate as I mentioned earlier would be very important for usability. I'm also missing a way to open the "property window of a selected instance" (=edit record) faster than looking through the instance list and opening it from there. Maybe also with a keybinding or by right-clicking on the instance in the scene view and "edit record".

It looks like Blender is always drawing the arrows at the same size over the object and not scaling them when the user is zooming in and out. Would that be a solution for OpenMW-CS too?

Yes it does, I mentioned this too. A lot of 3D editors do this because the user may operate at very small or big scales, i.e. working on tiny details or large scenes. It also implies the arrows have to be rendered in front of everything, like an Xray (so that they can't get hidden in big objects). This behavior is necessary in general 3D editors but can be also visually confusing.

In OpenMW CS you only ever have loaded one cell and never work on extremely small things (am I right?), so we know the user will work at some more or less given scale. This allows for the arrows to be part of the scene, get bigger/smaller depending on zoom/selection etc. So we have a choice and someone should probably test what feels better.

It looks like Blender is always drawing the arrows at the same size over the object and not scaling them when the user is zooming in and out. Would that be a solution for OpenMW-CS too?

I did try that at one point and remember not thinking much of it. Unfortunately I can't remember all of the reasons why, since that was quite a while ago. Perhaps I should test it again with the transparent markers. Anyway, in blender specifically, you only have one marker that is always at the pivot point, which is why it works. When you have multiple markers as we do in the editor, then it can cause confusion since you lose the ability to perceive depth by drawing the markers over everything.

I did try that at one point and remember not thinking much of it. Unfortunately I can't remember all of the reasons why, since that was quite a while ago. Perhaps I should test it again with the transparent markers. Anyway, in blender specifically, you only have one marker that is always at the pivot point, which is why it works. When you have multiple markers as we do in the editor, then it can cause confusion since you lose the ability to perceive depth by drawing the markers over everything.

1) Doesn't it already get confusing right now when you have several markers? Mabe we should also use the pivot point or only draw the marker of the last selection.

2) How are you supposed to move an object, when one axis of the marker is hidden in other objects like in this case? That's happening quite often when you work with wall pieces.

Another topic, but also important: The rotation also uses the individual pivot points of objects instead of a mutual one.
Scale also does that. (no picture)

Another topic, but also important: The rotation also uses the individual pivot points of objects instead of a mutual one.
Scale also does that. (no picture)

The editor is not fully implemented yet. Drag selection is something else that remains to be implemented. Regarding the pivot point, do we want the option to choose between shared and individual centers? How useful would that be? A single marker certainly has its advantages. It's reduces the clutter. With transparency it also allows for drawing over everything else, which increases the usability of the marker. Another advantage is that you can tie the movement of the marker to the movement of the mouse, to allow for more dynamic precision. For multiple markers, you are not forced to look at a single location to click on the markers. Are there other advantages? It would be good if we had some insight into why they were first implemented the way they were before making a final decision.

I think adding keybindings for move, scale and rotate as I mentioned earlier would be very important for usability. I'm also missing a way to open the "property window of a selected instance" (=edit record) faster than looking through the instance list and opening it from there. Maybe also with a keybinding or by right-clicking on the instance in the scene view and "edit record".

There will be more keyboard shortcuts later (probably each with an associated item in a button context menu, so the user doesn't have to look up the shortcut in the manual or the settings). But that is really a different task.

In OpenMW CS you only ever have loaded one cell and never work on extremely small things (am I right?), so we know the user will work at some more or less given scale. This allows for the arrows to be part of the scene, get bigger/smaller depending on zoom/selection etc. So we have a choice and someone should probably test what feels better.

Sorry, but this statement is completely wrong. You can load multiple cells at once and even modify instances in multiple cells at once. You regularly work with very small things and very big things.

It looks like Blender is always drawing the arrows at the same size over the object and not scaling them when the user is zooming in and out. Would that be a solution for OpenMW-CS too?

I did try that at one point and remember not thinking much of it. Unfortunately I can't remember all of the reasons why, since that was quite a while ago. Perhaps I should test it again with the transparent markers.

Not 100% sure either, but I think there were usability issues either with very small instances or when zoomed in very closely.

Anyway, in blender specifically, you only have one marker that is always at the pivot point, which is why it works. When you have multiple markers as we do in the editor, then it can cause confusion since you lose the ability to perceive depth by drawing the markers over everything.

A single marker at the pivot point is something that we could try. I don't think we need to offer both options, but we would need to test the single marker option first before deciding that this is the way to go.