Question Is this a bug?

[vamplayer]

If we right-click (lift finger) then move the mouse immediately, the scene rotates a small amount. If we wait for a bit before moving then it stays still.

I'm trying to do some precise mouse actions with quick clicks, moves, and releases, and this [bug?] is very annoying.

Has anyone noticed this?

 

[ZRSX]

On Desktop, you have to maintain the right mouse button pressed while moving your mouse to rotate. As long at you maintain your right-click on, you can wait all you want before moving.

 

[vamplayer]

The issue (bug?) that I was trying to describe might not have been understood from my post so please let me try to describe it again.

It is not about wanting to drag to rotate. Imagine you have a lot of enemy objects on screen and you are to right-click them to destroy them as quickly as you can. If you tried this, you would notice that the scene rotates micro distances every time you do a quick right mouse [down-lift-move], which is not wanted and not supposed to happen. How else are you supposed to destroy them quickly then?

The issue is more about the correct (expected) behavior of the right mouse button in VaM. When we lift our fingers, the scene should not move any amount when we move the mouse, even when we want to move it (the mouse) immediately after lifting the fingers.

 

[ZRSX]

Imagine you have a lot of enemy objects on screen and you are to right-click them to destroy them as quickly as you can. If you tried this, you would notice that the scene rotates micro distances every time you do a quick right mouse [down-lift-move], which is not wanted and not supposed to happen.

I understand that this is not what you wanted, but this is what is supposed to happen.
Precisely because it's the behavior of right-clicking in VAM. If you slightly move the mouse while right-clicking, it'll rotate the scene.

This is the expected - thus correct - behavior. You are the one trying to bend it to do something else: VAM wasn't originally made to be a FPS

What you can try is to use Embody. There is an option to prevent camera rotation by the user; maybe it could cover your need.

 

[vamplayer]

Thanks for the suggestion regarding Acidbubbles' Embody. I will do that.

However, I would have to disagree that it is correct and supposed to happen.

The example I gave was just an example. It could just have been a plugin that uses the right-mouse button to click to do something (not too much to ask in this example right? )

The default right-mouse-button's behavior is:
-when NOT held down, nothing should happen
-when held down, moving the cursor should rotate the scene

So if the finger has already been lifted, we don't expect the scene to be moving at all.

Now, you could try to argue and say we move the mouse a few microns before lifting. However, that is ALWAYS true so it does not apply as a reason. The programmers always have to find ways to compensate for things like that.

I wish Meshed could chime in and confirm that it could be fixable.

 

[ZRSX]

The default right-mouse-button's behavior is:
-when NOT held down, nothing should happen

Nope. The case "when NOT held down" simply doesn't exist.
The right-click behavior is: "starting looking for mouse movement when clicked, rotate the scene accordingly, and stop when click is released". Whether it's for 0.001s or if it's held down.

Anything you'll try to build with right-click button will conflict with that. You can't ask VAM programmers to plan for every single plugin that could be built in the future. Their core feature is working as intended: sorry but you should be the one to compensate
So either use Embody, or study Embody's code to add the part that blocks the camera rotation in your plugin.


As for a fix, even it was a bug (and it's not; it is the way VAM is built), you can forget about it: https://hub.virtamate.com/threads/1...fixed-now-that-focus-has-shifted-to-2-x.6128/

 

[r5k]

you're probably moving the mouse ever so slightly while right clicking.

a simple test to see if this is the case would be to lift the mouse off the surface, then press and release right button.

 

[vamplayer]

First of all, you need to know what a click is. In fact, if a programmer has never "compensated" and set the allowable micro distances the mouse moves without registering it as a move in the first place, there can never be a click at all unless it's done by code and not our naturally shaky hands.

I've even used some more time observing the default right-mouse's behavior, by just doing this releatedly:

*** STEPS TO REPRODUCE THE ISSUE
with right-mouse
[click, move, click, move, ..,] slowly but gradually faster and faster.

At first, the scene stays still, but you'll notice after a certain speed, the scene starts to rotate tiny distances.
***

These unwanted tiny scene movements happen _after the click_. Yes, after the click, and that's when our finger is already up in the air.

I don't even think this has anything to do with VaM setting the allowable distance (before registering a click) too small or anything. In fact, VaM does a right-click just fine and correct, evident by the fact that if you click and not move _right away_, the scene stays still as expected.

So it seems like it is probably caused by the physics system, when and where things are being updated. So whatever the cause might be, it is still an issue, even if you are too focused doing "the intended usage of VaM " to realize that it is an issue. It could make a product feel glitchy and unpolished.


I accept that it is unlikely for a 1.x fix but maybe other experts on the subject could share their ideas about this, and not just us two

As for the solution to what I was trying to do, being able to switch on and off the right-mouse button's default behavior from script would be great. I also need to add that this is different from trying to "undo" the movements to make it seem not moving, as depending on where we put the undoing code (update(), fixedUpdate(), ...) it causes some other problems.

 

[vamplayer]

@r5k
It's seemingly not about whether we move slightly while doing the click though. It's after the click happens. There's a tiny time window _after_ a right click, when moving the mouse (without any button held down) results in a scene rotation.

Could you please do the "step to reproduce..." from my previous post and let me know what you think?

 

[3rdStoryline]

The reason this occurs, is because when you hold down right-click to move around, you are actually moving a camera in VaM. That camera is just like any other Atom, or object in the scene. When you press down right-click you are changing the parent settings for the camera, and temporary taking control of the camera and moving it. So if the scene has a lot of scripts doing similar things, or is overtaxed with Physics requests, as both of these are calculated by your CPU, its going to slow down the time it takes to complete the request. Think of it like this, if you have a bunch of things making changes to other objects in the scene, or making other calculations of objects, they all get put in a to-do list. This list normally gets completed very quickly, and constantly over time. But your right-click function (because of it changing setting of an in engine item (ie. the camera)) it also gets put in that list, so a quick release of right click while moving the mouse will continue to control the camera until the Parent setting gets switched back to the Hold function( which is its default when you aren't' pressing rightclick)

To put it simply, this is input delay. As VaM only runs on a single core, if you have too many scripts/physics or anything else taxing that core, you will now experience this delay. This happens to me when I have a really heavy Scene, or a lot happening in a scene physics/script wise. If this happens when the scene is empty for you, then i'd try disabling/turning off other background programs, one at a time, until you find the culprit. If you use google chrome (while using vam) with hardware acceleration on, turning that off cud help. That or sadly, upgrade your processor to one with superior single core performance in comparison to your current. Really the only powerhouse option atm is one of the 12th Gen i9's.

PS: if you have razer synapse installed. burn that crap off your computer. That software has given me loads of issues over the years.

 

[vamplayer]

Thanks for the detailed explanation. From your input, I now know where and when it happens, but unfortunately still don't know why it happens.

So, the question now is why does VaM take so long to toggle back from a holding to a default not-holding status of the mouse buttons? Taxed CPU? But...

This is what we have so far:
-I think I could rule out the mouse or its driver.
-I use a trackball mouse and can do a total independent and precise click with no movement involved "while" clicking.
-It happens even in an empty scene (with no person atoms in it)

Again, a simple test for anyone who is interested in trying to see if the issue happens for them is:

*****
In desktop mode, in an empty scene with "Toggle Targets" on so we could tell when the scene is rotating, use right mouse button and do this:

-Click (i.e., finger down on button then release finger)
-Wait for ~1 second
-Move the mouse
-Click again
-Wait for about half a second
-Move the mouse
-Keep on doing but just wait less and less each turn...
*****

When waiting time is about a second or more, the scene should not move. But after the wait is about half a second (in my case) or less, the scene starts to rotate small distances.

 

[vamplayer]

Thanks to @3rdStoryline who pointed me in the right direction with his detailed post, I have finally found the culprit that had been bugging me through out most of my Vam playing career lol, causing the right mouse button delay.

It was a driver for a gyro mouse that I no longer use. I did go through the task manager before but somehow missed it.

So, to answer my original question, it is not a bug (unless you have seriously over taxed your system as what @3rdStoryline said.)