Surfaces mode material window / assinging issue

VergilUa commented 6 years ago

When brush is selected in hierarchy in surface mode, any attempt of assigning material via small "o" button (one that opens material selection window) will result in brush deselection if any brush in scene view is between button and window.

Re-selection of brush in hierarchy automatically hides material assign window, which makes material assigning really frustrating.

Steps to reproduce:

Create any model with brush inside;
Select brush via hierarchy;
Go to "Surfaces" mode;
Click on the "Select Material" button;
Move cursor across any brush in scene while"Select Material" window is openning (w/o holding mouse button);

Expected result - selection stays on the brush; Actual result - surface of the brush auto-selects when "Select Material" window shows up, resetting previous selection.

Note that this only happens during Select Material window loading. If I don't move mouse while it's loading, it doesn't deselect brush as intended.

RealtimeCSG v.1.516, Unity 2017.3.0f3

LogicalError commented 6 years ago

I tried reproducing it, but I didn't see anyhing weird happening .. maybe I'm not understanding this It would really help if you recorded the behaviour you see and send it to me so I can see what you're seeing (you could use gifcam http://blog.bahraniapps.com/gifcam/ for example)

VergilUa commented 6 years ago

Here's an example. You can see that sometimes brushes surfaces are inactive when switching from "Object" to "Surface" mode, but the actual brush is selected beforehand.

It also selects background brushes when moving cursor while "Select Material" window is loading. Sometimes it simply deselects the brush, if there isn't any brushes in the background.

No button was held during mouse movement

test

Here's another one: If I wait for material windows to load, then it's not going to select anything wrong. But if I move cursor, then it either selects background brush, or nothing at all.

test_2

I guess this might be related to how Unity's Editor GUI events are handled.

LogicalError commented 6 years ago

Interesting .. I'm not seeing that in 1.517 (version I'm working on) .. maybe I fixed this somehow? I'll see if I can reproduce it in 1.516. In the meantime, can you try if this also happens when you first dock the helper window (by clicking on the x) and then try to change the material? Also, you can change the material by dragging the material on brush, either in the scene or in the inspector, or on the material in the surface window.

VergilUa commented 6 years ago

Yeah, I'm unable to reproduce it, if it's a docked version of a window.

Also, you can change the material by dragging the material on brush, either in the scene or in the inspector, or on the material in the surface window.

That's what I've been doing before, but I've never tried using docked version instead, since UI is a little bit less convienient.

LogicalError commented 6 years ago

What about the docked version of the surface window is less convienient? Is there something I can improve there?

VergilUa commented 6 years ago

I guess there's too much empty space.

Mode selection buttons are too small and they're visually merging with other elements. Using bigger size and filling whole row for the button might be a better solution. (Since there's plenty of space)

Material selection could be separated from the label and moved to the next line, that would allow to decrease required space of the window.

Tooltip window appears too fast, some delay would be great.

Also, some visible separators between would be great (inbetween sections instead of empty spaces or with it), especially in "Generate" mode.

Following applies to left/right docked variant of the window only, since top/bottom is completely unusable, due to how fields arranged (it would require scrolling, which is a waste of time);

But all the above is just my thoughts and subjective opinion.

LogicalError commented 6 years ago

Ok, thanks for the feedback :)

LogicalError commented 6 years ago

I added ticket #266 for the last thing you mentioned. I'm not able to reproduce the first problem you mentioned, let me know if this is still an issue for you

damagefilter commented 5 years ago

Hi. I've got a repro for this issue. Here's a gif. Had to shrink it a little but I think it shows what's happening. rtcsg_surface_selection_bug_smaller

Select a surface
Open the Material Selector and quickly move the mouse over another face
The other face gets selected after the material window is done initialising.

I'm on Unity 2018.4.x (bless you guys for LTS verions). And the latest RCSG from the asset store.

Also: The work around with docking the window still works.

damagefilter commented 5 years ago

I've been fumbling about with the debugger a little and here's what I found. Maybe it helps a bit.

The issue is: There's a mouseUp event being fired with the surface editor in scene-view mode. That causes the selection to update in EditMode.Surface.HandleEvents:1407

This event is not fired when:

The editor is in a floating window or docked

So here is my theory...

When in scene-view-mode, the editor is handled by the SceneViewEventHandler.

Opening the Material Editor has a delay to it. It will block the thread that is processing the events, while it's loading.

During that time the event queue will halt.
You move the mouse out of the editor rectangle.
The next MouseUp event is registered to be happening in the scene viewport, event though the mouse was clicked in the editor window. But it doesn't expect such long delay so it uses current mouse position for the event.

That causes the selection to update. It thinks it was a normal click and has to update its selection.

SlimeQ commented 3 years ago

@damagefilter theory is correct I think. I am getting this behavior on 2019.4.8f1, does not happen in the docked/floating view.

LogicalError commented 3 years ago

Hmm, ok, I guess I don't have a large enough material collection to have a delay for that window to open ... which makes it hard for me to fix

damagefilter commented 3 years ago

I "fixed" it by throwing better hardware at it.

When I reported the issue, I was working on a laptop. This has an i7 alright (and a GTX 1070) and I never used it on battery only but I suspect that, due to it being hardware in a laptop, it was weak enough to cause the material window to load slower, causing a longer lock. Maybe this also is connected to the drive the project was on. Mine was on an SSD but my current one is much faster. So I can imagine if you had it on a HDD it would work towards producing the initially described behaviour.

Conversely, I think this can be reproduced on either mobile or somewhat older hardware.

LogicalError commented 3 years ago

I think I might have a fix, but I can't verify it. I'll finish things up later today, after work

LogicalError / realtime-CSG-for-unity

Surfaces mode material window / assinging issue #234