Edit widgets getting worse


#1

These 2D rotate and lift lower widgets from the '80s are getting worse.

Still impossible to select an object from any distance due to the rotate objects smothering the entire object.
THE ROTATE WIDGETS ARE UNNECESSARILY BIG. Still, this has been being reported ad-nauseum for months.

Impossible to rotate an object on the floor because the ground plane rotate widget is hidden under the floor.
The widgets used to show thru objects but now they are obscured behind stuff.

Lift/lower widget is 90 degrees out from viewer at certain angles, cant be seen without turning, this double arrow is side on and invisible to the user unless they turn. this arrow needs to be visible from all 4 points, not just 2.

Steps to reproduce: spend any amount of time inworld and actually try to do anything with entities.


#2

Though some effort was done to get the editing widgets z-ordered in front of everything else, it was not enough - there are still a few cases where they get hidden. Also, the editing UX is not conducive to easier or faster editing than several other long existing approaches. I have to be honest here to say that the current editing architecture is a big regression from well working ones, like the SL model, or even Blender. Moving up/down should be a keyboard modifier. It needs to be consistent with how physical objects are presently moved: X/Z by default then X/Y (Y is vertical movement in HF) when shift key is pressed). The editing widgets need to scale with camera distance from the object else they end up too small fro a distance and far too large up close. It al needs an architectural review and cleanup.


#3

One of the reasons we wrote the editing system in JavaScript, and not in the C++ code directly, was to allow 3rd party developers to easily modify it and change the behavior to be more to their liking. I encourage you to play around with it and make changes to see if there is a better way to present the user interface.

Note: we haven’t actually made any changes to the grab handles in several months. So, I don’t see how it’s getting worse. I think instead this is a case where some aspect of the content you’re editing is different enough that the logic in the edit UX behaves in a manner that’s less desirable.


#4

This is possible because I am working inside buildings now and may not have noticed this issue before but I thought I remembered being able to see the handles behind objects in the past, now they are obscured, maybe its always been this way. Maybe it feels like its getting worse because its just not getting any better after time.

I agree people will modify and improve the js eventually, but at this early point most people are just coming to grips with how everything works, and will take some time before users begin to understand and develop these tools. In the meantime we just need a stable sensible starting point. Im sure we dont want people coming in thinking they have to fix stuff before they can use it.


#5

I think I should be able to click a loaded script in interface and have it open to inspect.
I thought I’m not a scripter but ill try to open the edit.js and see what makes it tick mess with it and see what happens

But I ran into a " i dunno how to see the script" I know @thoys made the script editor thing, but it would be nice to link the 2 things together


#6

I always save the script to disk if i use one from high fidelity and use notepad++ to view it. But , i keep a up to date or just load a new GIT from high fidelity so i have all the examples on disk.


#7

The edit handles are meant to be drawn in front of other objects - right now this seems to be broken on the rendering side.

Regarding the current implementation tools, I think there are some benefits to it, but there are clearly large downsides, particularly in the ability to edit objects that are far away. We haven’t made any major changes to edit.js in months, but now that I have more time you should be seeing updates over the next few weeks.

Ryan


#8

Yes, in the far away case, the editing widgets all collapse into themselves making it nearly impossible to select them reliably if at all. But, the problem also exists when large objects are very close. In that case the widgets are enormous. The other anomalous behavior is of the vertical movement widget which acts more like a 3D object than a 2D sprite. It means that when the camera is rotated one can get an edge on view of it, and since it has nearly zero thickness it too cannot be selected on certain camera angles.

[Edit] Since there are eyes finally on this problem, consider adjusting the local z-speed when moving an entity (forward/back relative to the avatar’s camera) to depend on the camera’s elevation angle. This will stop that really annoying fling-entity 10 miles away problem. Something like:
spd = k + sin(local_cam_elevation)^2


#9

It also would be nice to color the handles so you can see which direction you need to move something. It’s now hard to see what direction is X or Z