[zparrish]

I'm throwing this out there as a potential bug since I haven't thoroughly tested this by rebooting and seeing if it persists. When I try using the eyedropper color selection tool in the Color Picker, it doesn't allow me to sample color from anywhere on the screen. To make it even worse, it gets my mouse pointer stuck in the eyedropper sampling mode. In this state, the arrow buttons on my keyboard don't function so I can't even manually kill the MXED process (although all other keys appear to work). The Escape key doesn't cancel the mode either.

The ONLY way I found to cancel the sampling mode is to press CTRL + ALT + DELETE to force Windows to hijack my desktop theme with its Administrative Menu. I tried all sorts of things from trying to switch programs, minimize all apps (WIN + "D"), launch a command prompt via WIN + "R", and even deal with the Task Manager directly by pressing CTRL + SHIFT + ESC, but with the keyboard arrow functionality dead, those avenues are dead ends. CTRL + ALT + DELETE was the only way I could get it to "snap out of" the sampling mode.

Again, it's possible its just me. I'm running Win7 x64 Enterprise SP1 with a Quadro K5200 GPU (driver version 361.91) on 4 monitors with Maxwell 3.2.1.4. I'm also using a customized variant of a standard theme (non-Aero based) for compatibility with Autodesk products. I just thought I'd pop this out there to see if anyone else experiences the same issue.

Also, is the color sampling tool supposed to let you sample any color currently on your screen, regardless of which app that pixel is rendered by (kind of like doing a quick "Print Screen" of the whole desktop and letting you sample any existing pixel)? If not, that would be really handy.

Thanks everyone!

[zparrish]

Just to follow up, I did test this again after a few reboots and it doesn't appear to lock the mouse anymore. It does however only let me sample pixels "owned" by the MXED editor window and dialog boxe(s). A "print screen" approach would be really handy so I could sample colors from anywhere on my desktop display though. I would imagine that's a bit tricky to code in a single source code base for compiling out to different platforms though.

I suspect the problem happened as the result of a Windows RDP connection being made to my workstation. Whenever I RDP into my workstation, it will "squash" the desktop display and window states to fit the display settings of my RDP client. Upon actually logging back into my workstation directly, my window states and locations are all different, so it aggressively manipulates the desktop for RDP purposes. It also disables hardware acceleration and uses the CPU to generate the display for the remote RDP client. I know the newer nVidia drivers mention that they support hardware acceleration over Windows RDP now, but I'm not convinced its actually working. Admittedly, I haven't spent much time configuring that since I rarely work remotely, but it's still just one more piece to complicate the issue.

So, in short, if you RDP to your Windows based workstation that runs Maxwell, then make sure you physically reboot when you get a chance to correct some potential display related functionality issues with the MXED editor.

Thanks!

[zparrish]

This issue was caused by initiating an RDP connection to the machine running MXED. I fixed it by upgrading to Microsoft RDP Protocol 8.1. I was previously running RDP Protocol 7.1 from the workstation in question. Thanks!

[burnin]

Thank you for sharing

[numerobis]

I can say that i have the same problem since v3.x (Sketchup and Max) without a RDP connection...

http://www.maxwellrender.com/forum/view ... 07&t=42453

[zparrish]

That's very interesting Numerobis! I just tried your approach by launching 3ds Max and then invoking MXED from the SME. When I do that, the problem is definitely back. I tried this in 3ds Max Design 2015 and 3ds Max 2017. If I launch MXED directly, it works normally, even after I experience the issue when I launched it from Max's SME.

So let's map out what's happening here. When MXED is invoked from the Max SME, a "lock" is placed on the SME until MXED is closed. I don't have any experience writing applications natively for Windows, so I don't know what actually allows that dependency. If RDP Protocol 7.1 could initiate a similar issue, I wonder what process graphically RDP uses to lock the console UI and relay the RDP UI for the session. Perhaps its a similar process "under the hood" of Windows when spawning dependent processes (I'm totally guessing on this one).

Do you have the same problem when running MXED directly or just when invoked from 3ds Max and SU?

Thanks Numerobis!

[zparrish]

Just on a hunch, I went into:

"Computer" -> Properties -> Advanced system settings (Left Nav) -> Advanced (Tab) -> Performance -> Settings -> Visual Effects (Tab)

and told it to "Adjust for best performance", but the problem persisted when launching MXED from Max's SME. I was hoping it would have narrowed down the culprit.

[numerobis]

Do you have the same problem when running MXED directly or just when invoked from 3ds Max and SU?

No, MXED standalone and MXED in Studio is working.

[zparrish]

Prerequisites:
Windows 10 x64 Enterprise
3ds Max 2017
Maxwell Render 3.2.1.4
Maxwell plugin for 3ds Max 3.2.9

Comment:
I started trying to segment my 3D content tools from my web developer tools by doing a dual boot scenario. I figured it would make it easier to troubleshoot problems like this if my application stack was more "pure".

At any rate, I just tested this on Windows 10 and the problem appears to be gone. After the OS installation, the only other apps that I installed were 7-Zip, Google Chrome, and the MS Office 2016 suite provided by Office365. Then, I installed Maxwell and tested the Color Picker with no issues. I then installed 3ds Max 2017 and the Maxwell plugin. I launched 3ds Max, made a new Maxwell material, and launched MXED from the 3ds Max material editor and it all worked just fine!

I did notice a slight difference in the eyedropper functionality on Windows 10 vs Windows 7. On Windows 10, the mouse pointer is smart enough to know when it's mode is locked to specific floating windows. When I'm in the eyedropper mode and I hover off the MXED windows, the pointer turns to a busy symbol (a spinning circle). On Windows 7, it wouldn't change form until I clicked a spot to sample.

I'm going to start installing the rest of my applications and see if the eyedroper sampler breaks at any point. I'll summarize my findings in a response post. Thanks guys!

[zparrish]

I just finished with the "finishing touches" of my program stack and have not seen the eyedropper get stuck even once. Here's a list of the applications I installed after my last post:

Turbosmooth Pro
Quad Cap Pro
Quad Chamfer
Creative Cloud Desktop App
Photoshop CC (2015)
Illustrator CC (2015)
Spotify
Acrobat Pro DC
Premiere Pro
Media Encoder
After Effects
AutoCAd 2017
Arc Replacer
Revit 2017
3ds Max 2017 SP1
AutoCAD 2017 Hotfix 3
Connected to Domain
3Dconnexion (Space Mouse Pro)
Headus UVLayout
PolyTrans by Okino
Inventor View 2017
CyberPower PPE
Bulk Rename Utility

I tested the color sampler after each program listed was installed to see if I could find a culprit. If nothing else,now I have a fresh clean OS install!

If by chance I forgot about a plugin, install it later, and the problem comes back, I'll be sure to post it. Thanks guys!