Loading...
> >

"Jumping" viewport problem is driving me insane! (EDIT: SOLVED, fix on page 1)

12357

Comments

  • Richard HaseltineRichard Haseltine Posts: 96,968
    Richard Haseltine said:
     
    JD_Mortal said:

     

    The mouse issue is becoming MORE prevelant as the software gets bogged-down now. They need to fix that, but they really also need to treat the perspective view as an actual camera, or replace it with a camera called perspective, so it can be undone and have settings and manipulation, beyond the mouse, like any other camera. That at-least, gives us a temporary fix, which works 100%, as this issue becomes a 100% occurance. Plus, it resolves a hand-full of other issues, related to the inability to control the perspective "camera", that is invisible, but present.

    The whole point of the Prspective view is to have a view that isn't tracked for undo, so that you can use it while posing etc. without wasting undo steps and so that when you do undo chnages in a pose afterexamining it you won't also move the  viewport. If you don't want that behaviour tell DS to create a default camera (in Edit>Prefrencs>Scene) and use that instead.

    And for those interested, Rob does havea  couple of script samples showing how to create a scene node that will drive the views (chnages to the node would be undoable):

    http://docs.daz3d.com/doku.php/public/software/dazstudio/4/referenceguide/scripting/api_reference/samples/elements/post_load_view_proxy_create/start
    http://docs.daz3d.com/doku.php/public/software/dazstudio/4/referenceguide/scripting/api_reference/samples/elements/post_load_view_proxy_link_properties/start

  • AlienRendersAlienRenders Posts: 790
    edited March 2018
    Richard Haseltine said:
    JD_Mortal said:

    This didn't work for me. Not when using IRAY preview mode, which it made worse.

     

    However, it does confirm that the issue is Daz's processing of the mouse-input, and directly narrows it down to the "first input response". Now all they have to do is fix that chunk of code, and discard the first chunk of mouse-input after every click-drag.

     

    This has to do with the "mouse input capture stream". Apparently, it first positions the mouse at that 1/5th-screen-left and 1/3rd-screen-top position, then it disables the cursor, then it starts spewing-out various values, relative to the screen, and the running-app window, as the mouse NOW moves up/down/left/right... until you release the mouse, then it returns the mouse to the location where it was, when the program requested the "capture".

     

    Daz seems to be reading that "capture" value, and applying it, instead of using it to "neuter" the stream of values. (Subtracting that value from the values the buffer is spewing-out, to yield the movement delta.) Thus, it first shoots off into oblivion, then, with the corrected delta, it continues motion. However, when the values are the same... (not moving the mouse for a second), the delta is subtracted from the delta, making it 0, and no erratic movement is seen. (Which is what the dealy with AutoHotKey is trying to simulate. Which fails if you have a slow computer, and the mouse data has not begun rolling-out within 100ms, or if you are just using a highly taxing laggy component, like live-updates in the IRAY preview window. That slows input past the 100ms time. Any more, and it is just a hindrance.)

    That's an awfully definite statement for someone without access to the code.

    Well, you don't need to have their code to know certain things aren't done right. In fact, it's easy to prove that what JD_Mortal is saying is 100% accurate. Going even further, I can tell you what the line of code looks like that is incorrect and even how to fix it.

    Try this... open DAZ Studio but make sure it's not maximized. Move the app to the right of your monitor but still fully visible. Now left click on the rotate overlay icon (in the top right of the viewport) and while holding down the left mouse button, also right click. You'll see your mouse cursor re-appears somewhere else on your screen. It's supposed to appear in the center of the window. But there's bug in the code that sets the mouse position relative to the screen instead of relative to the window. Right there, we know that's a bug. I've confirmed that the offset from the top right of the monitor is exactly half the window size.

    Now we get to the question why would this matter? It's just offsets right? Well, yes... sorta.

    After you move your mouse, DAZ Studio recenters your mouse cursor (or what it thinks is the center). So in most cases, this works fine because as mentioned earlier, it's just adding an offset.

    But here's the problem. Windows queues messages. So it's possible to get multiple mouse move events before the app responds to this. Since mouse moves are usually very small increments, it usually won't be noticeable that there is a bug here. The first mouse move will be processed normally, then the app will recenter the mouse. Then it will process the next mouse move. But this one will now be processed as having moved much futher than it did in reality because the recentering happened between the two mouse moves. Again, the user will likely not notice, or if theye do, it will be a minor jump.

    However, what happens if the LBUTTONDOWN event and the first mouse move event are queued before the app was able to process the mouse down event? Then you get a very bad situation and this is what people are experiencing. The cursor position given by the first mouse move is the location of the rotation overlay icon because the app hasn't centered the mouse pointer yet. So delta will now be HUGE. And this is what causes the app to rotate the view which appears as a "jump" (or if you use the pan icon, then it will truly jump). If the app is fast enough, this won't happen. But with iRay starting up as soon as you click the mouse button, delays are much more likely to happen. Now you can see why the script mentioned above works. It stops the app from getting that initial bad mouse move event. But if the delay is longer than what that script is told, it'll still happen.

    And even if the app centered the mouse correctly, it still wouldn't fix the problem since the postion between the overlay icon and the center of the window is very large. In the code, it looks like the mouse is centered after the mouse down event. And indeed it is. But the problem is that there's already a mouse move event in the queue. The fix is simple. Remove any mouse move events from the message queue after processing the mouse down event.

    BTW, I've used Microsoft Spy++ and have confirmed that the cursor is occasionally not recentered in time. I'm a developer and am responsible for maintaining the mouse handling code in our 2D and 3D view in our app at work.

    I will submit a ticket and explain the fix. The fix can be explained in a couple sentences. Hopefully they'll take a look at it.

    edit: Ticket submitted along with instructions on how to fix it.

     

    Post edited by AlienRenders on
  • brettnucklesbrettnuckles Posts: 86

    Wow, good work AlienRenders! Everything you said matches up with my experience exactly. I also noticed that in addition to the jumping viewport, the mouse cursor itself jumps very briefly to a specific spot on my screen. I can also confirm that while my script works for me in general viewport navigation, if I try to navigate while in the iRay preview then I still get the jumping. Your explanation seems spot on. Hopefully it's addressed promptly by Daz. 

  • ImagoImago Posts: 4,904
    AlienRenders said:

    Well, you don't need to have their code to know certain things aren't done right. In fact, it's easy to prove that what JD_Mortal is saying is 100% accurate. Going even further, I can tell you what the line of code looks like that is incorrect and even how to fix it.

    Try this... open DAZ Studio but make sure it's not maximized. Move the app to the right of your monitor but still fully visible. Now left click on the rotate overlay icon (in the top right of the viewport) and while holding down the left mouse button, also right click. You'll see your mouse cursor re-appears somewhere else on your screen. It's supposed to appear in the center of the window. But there's bug in the code that sets the mouse position relative to the screen instead of relative to the window. Right there, we know that's a bug. I've confirmed that the offset from the top right of the monitor is exactly half the window size.

    Now we get to the question why would this matter? It's just offsets right? Well, yes... sorta.

    After you move your mouse, DAZ Studio recenters your mouse cursor (or what it thinks is the center). So in most cases, this works fine because as mentioned earlier, it's just adding an offset.

    But here's the problem. Windows queues messages. So it's possible to get multiple mouse move events before the app responds to this. Since mouse moves are usually very small increments, it usually won't be noticeable that there is a bug here. The first mouse move will be processed normally, then the app will recenter the mouse. Then it will process the next mouse move. But this one will now be processed as having moved much futher than it did in reality because the recentering happened between the two mouse moves. Again, the user will likely not notice, or if theye do, it will be a minor jump.

    However, what happens if the LBUTTONDOWN event and the first mouse move event are queued before the app was able to process the mouse down event? Then you get a very bad situation and this is what people are experiencing. The cursor position given by the first mouse move is the location of the rotation overlay icon because the app hasn't centered the mouse pointer yet. So delta will now be HUGE. And this is what causes the app to rotate the view which appears as a "jump" (or if you use the pan icon, then it will truly jump). If the app is fast enough, this won't happen. But with iRay starting up as soon as you click the mouse button, delays are much more likely to happen. Now you can see why the script mentioned above works. It stops the app from getting that initial bad mouse move event. But if the delay is longer than what that script is told, it'll still happen.

    And even if the app centered the mouse correctly, it still wouldn't fix the problem since the postion between the overlay icon and the center of the window is very large. In the code, it looks like the mouse is centered after the mouse down event. And indeed it is. But the problem is that there's already a mouse move event in the queue. The fix is simple. Remove any mouse move events from the message queue after processing the mouse down event.

    BTW, I've used Microsoft Spy++ and have confirmed that the cursor is occasionally not recentered in time. I'm a developer and am responsible for maintaining the mouse handling code in our 2D and 3D view in our app at work.

    I will submit a ticket and explain the fix. The fix can be explained in a couple sentences. Hopefully they'll take a look at it.

    edit: Ticket submitted along with instructions on how to fix it.

    The problem is that this happens to sliders too... I don't know if it's related to the recentering issue, but often, when I move a slider in the Parameter tab, the value gets skyrocketed to six times the max value or gets plunged to six times the minumun value. I often work with limits off (like the 99% of the people here) and the effects are very noticeable.

  • brettnucklesbrettnuckles Posts: 86

     

    Imago said:
    AlienRenders said:

    The problem is that this happens to sliders too... I don't know if it's related to the recentering issue, but often, when I move a slider in the Parameter tab, the value gets skyrocketed to six times the max value or gets plunged to six times the minumun value. I often work with limits off (like the 99% of the people here) and the effects are very noticeable.

    I wonder if the regular viewport jumping is more common than the slider jumping. Because I've experienced viewport jumping for a year but never once encountered slider jumping, despite using sliders all the time.

  • FletcherFletcher Posts: 63
    Wow, you guys are way too smart to playing with these cyber paper dolls! You kinda need some kind of PHD to be using this thing. What I do notice is that the latest windows update have made things much better. Hardly ever jumps in the iray preview window anymore. However, on my laptop, which does not have a GPU, it's completely unusable. 10 second or more mouse movement delay. I used to be able to fix this by loading the latest Intel display driver but it did't work this time. I also saw that there was an Intel driver update on my fancy desktop that went in with the Windows update. Can this be a problem even if I have a gpu card?
  • IceDragonArtIceDragonArt Posts: 12,548

    Just saw this.  I've noticed this more and more recently and its happening on both my pc and my new laptop.  Will be interesting to see if they fix this, as its extremely annoying.

  • brettnucklesbrettnuckles Posts: 86
    IceDragonArt said:

    Just saw this.  I've noticed this more and more recently and its happening on both my pc and my new laptop.  Will be interesting to see if they fix this, as its extremely annoying.

    Curious if you tried the AutoHotkey script as a temporary fix? This issue was so annoying it almost made me quit Daz altogether but the AHK script basically solves it in my case.

  • SkydogHexSkydogHex Posts: 71
    Imago said:
    AlienRenders said:

     

    The problem is that this happens to sliders too... I don't know if it's related to the recentering issue, but often, when I move a slider in the Parameter tab, the value gets skyrocketed to six times the max value or gets plunged to six times the minumun value. I often work with limits off (like the 99% of the people here) and the effects are very noticeable.

    This! This is the main problem I have. I do have the jumpy screen deal but I've taught myself to go slow and mostly it's managable. But the slider issue is pure hell. If I drag a slider, I never know what I'm going to get as a result, no matter how slow I do it. Additionally, at least half the time after trying to do a small change by draging the slider, DS will lose the entire selection, and drop back to the base figure, meaning I have to go back and reselect the body part, fix the new parameter and try again. It got so frustrating recently, that I took a two week break from using Studio. Now I try to manually type in the number I wish to change. And on rare occasions, the mouse dissapears completely from DS when dragging a slider. When that happens I have to do an Alt-F-S to save my work, close DS and reopen it. Adding more frustrations and slowing down my work flow.

    I've updated DS and my mouse drivers. I am considering changing from a wireless to a wired mouse to see if that helps any.

  • shoei321shoei321 Posts: 113
    edited March 2018

    I just wanted to chime in on this thread and confirm that this issue is unfortunately very real, and severe enough to have caused me to shelf DAZ until there is a fix.   The problem occurs much more frequently when DAZ is under load, e.g. a large scene with lots of dynamic/auto-follow geometry that needs continuous recalculation.   

    A great way to reproduce the issue is create a scene with a DAZ figure wearing a lot of conforming clothing/hair/props/etc, then set a body part to follow the camera via the Look At property, then pan the camera around the scene.   I notice the mouse jumping issue immediately and frequently under these conditions, presumably because the event pipeline is quite busy with all the geometry recalculation activity.  

    I'm also a software career developer, and AlienRender's proposed explanation of the issue sounds quite likely to me.   The AutoHotkey bandaid fix in this thread unfortunately didn't work for me.

     

     

     

     

     

     

    Post edited by shoei321 on
  • RFB532RFB532 Posts: 94
    shoei321 said:

    I just wanted to chime in on this thread and confirm that this issue is unfortunately very real, and severe enough to have caused me to shelf DAZ until there is a fix.   The problem occurs much more frequently when DAZ is under load, e.g. a large scene with lots of dynamic/auto-follow geometry that needs continuous recalculation.   

    A great way to reproduce the issue is create a scene with a DAZ figure wearing a lot of conforming clothing/hair/props/etc, then set a body part to follow the camera via the Look At property, then pan the camera around the scene.   I notice the mouse jumping issue immediately and frequently under these conditions, presumably because the event pipeline is quite busy with all the geometry recalculation activity.  

    I'm also a software career developer, and AlienRender's proposed explanation of the issue sounds quite likely to me.   The AutoHotkey bandaid fix in this thread unfortunately didn't work for me.

     

     

     

     

     

     

    Using a Space Mouse will bypass the "Mouse Jumping Issue". Also be sure to install the Space Mouse Software and lower the speed settings because the defaults are way too fast. Ultimately it would be great to have the mouse Jumping issue fixed because it's helpful for fine tuning your view port view, in combination with a Space Mouse.

  • ImagoImago Posts: 4,904

    Space mouse? DAZ Studio supports that?

  • Richard HaseltineRichard Haseltine Posts: 96,968
    Imago said:

    Space mouse? DAZ Studio supports that?

    I believe it does on Windows, I'm not sure about Macs.

  • RFB532RFB532 Posts: 94
    edited April 2018
    Imago said:

    Space mouse? DAZ Studio supports that?

    Yes, surprisingly it works amazingly well in Windows 10/Daz 3D (Not sure about Mac) All the veiwport issues with the Jumping Mouse don't happen when using it.(ie. Pan, Zoom, Rotate issues)
    Post edited by RFB532 on
  • ImagoImago Posts: 4,904
    jason.lin22 said:
    Imago said:

    Space mouse? DAZ Studio supports that?

     

    Yes, surprisingly it works amazingly well in Windows 10/Daz 3D (Not sure about Mac) All the veiwport issues with the Jumping Mouse don't happen when using it.(ie. Pan, Zoom, Rotate issues)

    Uhm... We should find out if it depends on the mouse's hardware or if the magic is done by its drivers! I checked the product... It's a nice piece of stuff, but 150$ is a bit too much for me right now!
    Especially because I already own an 80$ vertical laser mouse...

  • ForceXForceX Posts: 52
    jason.lin22 said:
    Imago said:

    Space mouse? DAZ Studio supports that?

     

    Yes, surprisingly it works amazingly well in Windows 10/Daz 3D (Not sure about Mac) All the veiwport issues with the Jumping Mouse don't happen when using it.(ie. Pan, Zoom, Rotate issues)

    Very cool device. I can see this being quite useful. I suspect it works with out issue because the device is constantly updating. We get the viewport jumping after a OnMouseClick event detection that triggers a view movement/rotation that can result in dirty values. So what ever is happening during the first part of the click event that causes these errors does not apply to this device because it is always sending vector updates and daz is always listening for these updates from the device (it’s not a conditional update).

  • SkydogHexSkydogHex Posts: 71

    I purchased a $29 steelseries wired mouse from walmart over the weekend and have been using it the last 3 days. It has solved all my issues in DS. No jumping viewport and I can drag sliders all day with no problems. I don't know why it works, just that it does ;)

  • brettnucklesbrettnuckles Posts: 86

    That's pretty interesting SkydogHex. I will say that I've tried at least four different mice of varying pice and quality, two wied and two wireless, and none alleviated the jumping issue for me at all. Still very interesting to hear that this particular model seems to work...

  • ImagoImago Posts: 4,904
    SkydogHex said:

    I purchased a $29 steelseries wired mouse from walmart over the weekend and have been using it the last 3 days. It has solved all my issues in DS. No jumping viewport and I can drag sliders all day with no problems. I don't know why it works, just that it does ;)

    You installed some kind of driver included in the package or simply let Windows install default ones?

  • SkydogHexSkydogHex Posts: 71
    Imago said:
    SkydogHex said:

    I purchased a $29 steelseries wired mouse from walmart over the weekend and have been using it the last 3 days. It has solved all my issues in DS. No jumping viewport and I can drag sliders all day with no problems. I don't know why it works, just that it does ;)

    You installed some kind of driver included in the package or simply let Windows install default ones?

    I let Windows install the default ones. 

  • RFB532RFB532 Posts: 94
    SkydogHex said:
    Imago said:
    SkydogHex said:

    I purchased a $29 steelseries wired mouse from walmart over the weekend and have been using it the last 3 days. It has solved all my issues in DS. No jumping viewport and I can drag sliders all day with no problems. I don't know why it works, just that it does ;)

    You installed some kind of driver included in the package or simply let Windows install default ones?

    I let Windows install the default ones. 

    Could post a link to the mouse you bought?
  • TKATKA Posts: 27

    Been facing this same issue and it's hammering on my patience. It has almost fully affected my decision to refrain from renewing my PC+ subscription and I am going to stop spending for assets in the Daz store until this is fixed.

     

    I want to add that the issue can still be recreated using the simple test @AlienRenders posted. And as others have noted, the more the viewport gets saturated with polys, the worse the viewport navigation gets. 
    I also want to add that I only started seeing this problem in Daz after I upgraded to Win 10 a few months ago, after the Jan 2018 meltdown/spectre rushed job botched patches) left my Win 7 system unresponsive. Never saw this issue in Win 7 and I'm using the same set of hardware from before. 

    And I am Not going to install a 3rd party software only to try and add a band-aid fix to a software problem the Daz team should fix from their end. I expect at least so much from Daz, that they would fix the issues in their own software when they can keep the daily sales/releases going on like clockwork. So the OP needs to change the title, since google's SEO isn't smart enough to read the caveat that this isn't in all fairness an actual fix but only a mekeshift remedy.

    So the OP should change his/her title 

  • mrinalmrinal Posts: 641

    I agree what has been posted on the first post is merely a workaround, not a solution or a fix to the problem being discussed. The title of the post should reflect accordingly.

  • AlienRendersAlienRenders Posts: 790

    The ticket I issued has been closed. It says they sent my comments to the devs. But I haven't heard anything about it since. I will issue another ticket as this is getting quite ridiculous. They haven't even fix the centering bug.

  • marblemarble Posts: 7,449

    Apart from (or rather, as well as) the problems listed here, I've been getting increasingly frustrated with the unwanted drag & drop action that happens quite often when I click on something in the Scene panel (Tree View). At first I thought that it must be unconscious hand movement on my part but I know for sure now that it isn't - I've been purposefully careful and it still happens and then I have to go searching for where it has dropped (and thus parented) the object I clicked. This is allied to the other spurious mouse behaviour of multiple selections when I only want to select a single object or bone. 

    I should add that I use the mouse without a problem in my 2D photo editor (where I need to be very precise) as well as in other apps, particularly the web browser. Only DAZ Studio has this problem. 

  • nickalamannickalaman Posts: 196

    It might actually be fixed, but remeber that studio has no been updated since December. That's six months.

     

     

  • ImagoImago Posts: 4,904

    I'm starting to think they are "ignoring" the issue because they are about to release DAZ Studio 5, that will work properly since the beginning.

  • Richard HaseltineRichard Haseltine Posts: 96,968
    Imago said:

    I'm starting to think they are "ignoring" the issue because they are about to release DAZ Studio 5, that will work properly since the beginning.

    That's a lot of supposition.

  • ImagoImago Posts: 4,904
    Richard Haseltine said:

    That's a lot of supposition.

    Yes, I know...

  • dramenondramenon Posts: 52

    Good to know I was not the only one, I reported this myself last year (I think.) 

    And @imago I am with you on this, otherwise.... angry

Sign In or Register to comment.