Daz 3D is part of 
Connect
DAZ Productions, Inc.
7533 S Center View Ct #4664
West Jordan, UT 84084
Licensing Agreement | Terms of Service | Privacy Policy | EULA
© 2025 Daz Productions Inc. All Rights Reserved.
Comments
This is my guess and there is absolutely nothing anyone but daz can do about it. DAZ check your code where the mouse input gets updated or the camera orbit gets updated when using the transform cube. I bet somewhere the vectors are getting either zeroed out or there values are inheriting another value by accident.
As has been said, this issue is not just a DS issue. It may be that DS is more vulnerable to whatever the underlying cause is, and it's concievable that Daz might be able to reduce that vulnerability in some way, but neither of those statements are proven and it certainly can't b asserted that this is simply a DS bug.
Sorry I have a hard time believing the issue is anything other than a DAZ issue. Epically when multiple people using a multitude of different hardware setups are reporting the same problem. If it is a Windows input API issue then there would be problems in all aspects of Windows and other applications. Even if it’s an external dependency that has changed its still DAZ responsibility to update and maintain compatibility.
Just like with any code base, things that have worked fine for years can be broken and overlooked because of their past performance. In this case we are dealing with an object (code term) in this instance it is the currently active viewport camera that happens to have a rotation, Euler Angles, or Quaternion. These are elements that are not influenced by external variables such as a hardware or graphics drivers, ect. These are code management variables whose values are determined by the software. Such as this overly simplified example for a single axis of rotation:
////////
float speed = 2;
float TempAngleX = ActiveCamera.Rotation.x + (InputDevice.x * speed * TimeBetweenLastFrame);
ActiveCamera.Rotation.x = TempAngleX;
////////
Not too much in the way of external influences there. The only thing we have is the input device and the time between frames.
It’s either the way DAZ is calculating the final rotation value, the way it is listening to input devices, or the way it determines time.
I’m simply suggesting places to look is at any method or function that controls the active viewport camera rotation (using any of the above methods) when using the cube transform widget. If Euler Angles are used then perhaps the function that wraps the Euler values between 0-360-0, which could be another place to look. Or the OnMouseClick Event when the mouse is hovering over the Cube Transform Widget, because something is causing the code driven camera to spin.
These things happen all the time, its fine. Developers start working on something, trying out different ideas, inject new lines of code and some of them get forgotten about then oops, something is broken that has worked fine in the past.
As I’ve seen mentioned “We haven’t changed anything.” Is ignorant at best; as updates are released all the time so something is getting changed. Just saying it’s worth a look and to not investigate is arrogant.
In reality does this problem bother me? No, Sure I swear at my monitor every time it happens but I can live with it. What does bother me is some of the responses to not only this but other problems where there appears to be a “What Ever” attitude towards some of these reports. Before you say they give DAZ Studio to you for free so deal with it. I say not to me they didn’t, Yes I paid $260 for DAZ 4 Pro very shortly before they started giving it away for free. So I would hope that when a bug report comes in from me or anyone else that they would at least take a look.
PS
I'm not mad or upset I just like to debate. So please don’t take anything I say personally.
I use Max, Zbrush, Modo all the time and have never experienced this issue. Heck I've been using Max since R3. I can also say from the countless hours I've watched others use these applications that I have never to my recollection seen this occur. For myself this is an issue I have only experienced in DAZ. Software only does what it is told to do. If that wasn’t the case then I could just turn on my computer and things would happen without my direction.
Out of curiosity for those of us that are experiencing this issue in DAZ, what direction does you camera tend to snap towards. I believe mine always snaps to a rotation that is looking up.
Edit: I searched for issues regarding Max & maya viewport rotation problems and any issues appear to be fixed by disabling features within the application it self. So by isolating / preventing code from running they were able resolve the problem till autodesk issued a proper fix.
The above was based just on a quick search I did on my phone. I have not extensively searched this. But the top results all appear to have found a solution within the application of issue and because I do not have issues with thes programs I won’t spend any more effort researching them.
As shown in the gif I posted when I started this thread, my camera always snaps higher, so that with each snap I'm looking more down onto the top of my character. I'll also say that I use Blender, Maya and Photoshop on a daily basis on this same computer and have never once encountered a jumping cursor in any of those programs, but the issues is constant in Daz even through a fresh clean reinstall of Windows 10 where Daz was the ONLY piece of software I installed.
Yup I feel your pain :)
I started using an actual camera instead of the default viewport to navigate the scene just so it would register in the undo system and I can restore the camera when this happens.
I've been fiddling with creating an Autohotkey script that forces the mouse movement to freeze for a few milleseconds whenever you press Alt+Click. The reason being that it's possible to avoid the cursor jumping by Alt+clicking, waiting a second, and then moving the mouse, but it's difficult to remember to always do this manually so you still end up with jumping. Well, I'm happy to report that after much trial and error I've finally got it working!... with an annoying bug that I can't seem to fix. The problem is that the script causes the File menu in the top left corner of Daz Studio to flicker on and off when you Alt+Click, which is visually annoying. The workaround is to use Ctrl+Click instead, which is sort of uncomfortable after so many years of using Alt+Click to move the camera in Daz Studio and having the muscle memory built up. Still, I worked all last night in Daz Studio without a single camera jump, after months of frustration from this issue. What a relief!
Anyone interested in the script? I can post it along with basic setup instrucitons for Autohotkey if you're not familiar with that, either later tonight or tomorrow night depending on whether I have time.
@brettnuckles
I almost threw Daz in My Desktop trash bin, but I persevered.
Yeah I tried the pause then click method, it's extremely difficult to do every time. If you get the time please share how you did the Autohot Key fix they would be good to know.
Another possible slightly expensive solution (and it takes some practice) is a Space Mouse.
I've been testing my Space Mouse Pro for the past couple of days, and have not seen any issues with the viewport jumping so it seems promising (I hope it continues to work with the next Daz update). One issue I noticed is that each viewport move gets logged into Daz's undo memory (which is a pain) but better than nothing.
I imagine you could get by with just the Navigator for less money: https://www.3dconnexion.com/products/spacemouse/spacenavigator.html
You also need to install the Space Mouse Software and lower the settings down as low as possible, because the default is set too fast/sensitive in Daz.
I actually solved the Alt menu issue I described above! Turns out it was very simple, I just needed a little help from the AutoHotkey forum. This easy-to-install script completely fixes the jumping issue by forcing the mouse to freeze in place for 100 millisecond (0.1 seconds) after whenever you Alt+Right Click or Alt+Left Click in Daz Studio. It is only in effect in Daz Studio so it won't affect your other programs you might use. The freeze is basically imperceptible in my opinion -- you will barely even notice, but it's there.
Instructions:
1) Download the program AutoHotkey at https://autohotkey.com
2) Go to your Documents folder on your PC
3) In the Documents folder, select the file Autohotkey.ahk and open it with notepad. If there isn't one there already, create a simple text Notepad document (right click > New > Text Document and name it Autohotkey.ahk.
4) If you use the default viewport controls of Ctrl+Alt+Click to navigate, open the document and paste the following into it:
SetTitleMatchMode, 2
#IfWinActive, ahk_exe dazstudio.exe
~$^!LButton::
blockInput, mouseMove
sleep, 100
blockInput, mouseMoveOff
return
~$^!MButton::
blockInput, mouseMove
sleep, 100
blockInput, mouseMoveOff
return
OR if you're like me and have remapped the viewport controls to Alt+Click instead of Ctrl+Alt+Click for ease of use, use this code insteaad:
SetTitleMatchMode, 2
#IfWinActive, ahk_exe dazstudio.exe
~$!LButton::
blockInput, mouseMove
sleep, 100
blockInput, mouseMoveOff
return
~$!MButton::
blockInput, mouseMove
sleep, 100
blockInput, mouseMoveOff
return
5) Now you want to set it so this script starts automatically whenever you boot up your PC, so do this:
-Hit WindowsKey+R on your keyboard
-Type Shell:Startup into the text field and hit enter.
-Paste your Autohotkey.ahk document in here.
And there you go! Please let me know if anyone has any questions. I am wondering if maybe I should make a new thread to alert everyone to this fix?
#
Brettnuckles, THANKS for figuring out a fix. Do you know if the autohotkey fix will work when just using the viewport controls i.e. not using the Ctrl+Alt+Click keyboard shortcuts?
I have a modification for the script that I think will work for that but I'm not 100 percent certain. I will test it when I get home from work tonight and report back :)
Okay so I *think* this script will work for using the navigation buttons in the top right of the viewport without jumping. Fair warning though that it freezes the mouse movement for a few milliseconds ANY time you left click inside Daz (as opposed to just when you alt+click or alt+ctrl+click). The freeze is so short that it's not really noticeable in general though. Also warning that I only tested it for a minute and I can't guarantee that it will stop the jumping when using the navigation buttons every time. I CAN guarantee that the other scripts work perfectly when using alt+click or alt+ctrl+click however.
SetTitleMatchMode, 2
#IfWinActive, ahk_exe dazstudio.exe
~$LButton::
blockInput, mouseMove
sleep, 100
blockInput, mouseMoveOff
return
To be honest it's kind of hard for me to imagine why you'd rather move your cursor all the way up to the top of the screen and click on a tiny button instead of just alt+clicking anywhere. But hey, to each their own.
Thank you brettknuckles for the additional script!
In general I would have to agree that keyboard shortcuts are better, however, after going through so many graphics apps in my time, and still learning more, sometimes it is just easier to click a button.
Thanks so much for the fix brettknukles !
I have one too. I don't use the mouse to look around because it is so clunky. I think the problem is something that could be fixed but PC's have too many different hardware configurations in windows. Daz Studio has builtin Connexion Space mouse driver support. This is probably why I have not encountered this problem. I use my spacemouse to run my 3D Programs so it just did not click it might be an I/O problem for just mouse users. I like my space mouse so much I bought a 2nd one just in case the first one broke. If you have a laptop with this viewport stuttering problem>> I would take my machine to someone or a computer store that sells the space mouse and see if this fixes the problem for you. If it does then this is a nice solution for you and it does indicate ethier a windows mouse problem or a gui problem inside the windows OS.
How you remapped them? I can't find anywhere the right option! I serached the whole "Actions" list but nothing!
Open that window up where you set keyboard shortcuts. See that long list of "Actions" that you can edit? Ignore that and look below it down at the bottom of the window. You'll see a dropdown with viewport controls that you can edit. Check out this image and look to the bottom right:
https://www.daz3d.com/forums/uploads/FileUpload/68/7f606c68eb997afd89ee12ff724097.png
Oh, boy! The were so visibile that I totally missed them!
Thanks a lost!
Remapped the keys and tried the script... Well, now I get the jumps 100% of the times I click! Until now I got those jumps just once in while...
What's wrong?
Hm seriously? Oh my, that's really odd. Do you get jumps when using the Alt+Ctrl+Click script? In other words, if you use the standard script and don't edit your viewport controls from the default. I've tested both scripts extensively on my machine and they work flawlessly for me, I haven't seen a single viewport jump in a couple of weeks now. Is anyone else seeing jumping while using the AutoHotkey script?
I had to bring the delay from 100 to 400 to have it "working".
Lower values like just 390 makes it happen again...
The delay is really high, but at least I don't have to "hunt" the camera position again. Somehow it works! (.-.)
Geez that's really odd. I guess that points to the fact that the jumping issue varies with individual hardware and/or software setup on the user end. I've tried many values for the delay and have never seen it cause jumping at all, let alone 100 percent of the time.That really sucks that you have to set it so high. But at least it's maybe better than the alternative. Daz really needs to look into this issue and find a fix!
It's not just the viewport for me, some times I get crazy sliders too...
For example, I click to slighly move the head of my char to the right... An suddenly he gets his head rotated 6 times!
Wow interesting. That's terrible! I've never seen that. So clearly whatever causes this bug affects your system in a more exensive way. C'mon, Daz!
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.)
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.
That's an awfully definite statement for someone without access to the code.
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.
So are you saying it DOES work in a normal viewport mode, but doesn't work when you're doing IRAY preview mode? Or am I misredaing and the the script doesn't reduce jumping for you at all in any mode?