SMTD Sanity Checker Dialog - flicker on dialog re-size. A .NET Form would not do this. We have found that by using a .net form for various GUI’s, which also have a re-size capability, the ‘flicker’ issue is almost completely removed which makes for a much nicer user experience
SMTD RGB Colour of the “Scene File Submission Option” initially displays for a ‘nano-second’ the original wrong colour (blue) before the RGB colour values are set. I think the creation of the colour box at the beginning of the dialog loading on screen needs to also be updated, so we don’t get this colour flicker as the SMTD GUI loads up and reads in the override colour setting.
Tile Assembler Jobs - Machine Limit being set to “1” which is incorrect for multiple RE’s in 1 job to be assembled. Not sure why this happened? Maybe a bug?
“Remove Filename Padding” should be disabled for Tile Assembly based still frame rendering, as sometimes the artist may render a single frame which is NOT on frame “0”. Therefore, by stripping the padding, the Tile Assembler code is getting confused. I’m thinking we should have a general sanity check for this issue? Alternatively, the Tile Assembler code needs to handle this situation better?
FR - Worker Threads - Sanity Checker. Please could we have the ability in the core Sanity Checker code to run the individual Sanity Checks as background threads, populating the ListView as their results come back. I think this would be a fantastic addition and also allow studios which have a lot of Sanity Checks in place to gain a permanence improvement! (checks > 80!)
Not this close to release.
You wanted it resizable. It is now resizable.
Set it to the desired size and stop resizing
I will try to do this for the next release after 5.1…
Will investigate and fix if it is trivial.
Sounds dangerous. MAXScript wasn’t designed for multi-threading, regardless of the DotNet Worker availability. See 1.
Will log for the next round.
I am leaving 3 and 4 to Ryan to decide, not my code.
The blue color you saw was the default color of the progressbar used as a color indicator (0,0,255). I set the default to gray (white*0.75) so it is not so obvious.
At the time of opening the UI and before the ON … OPEN DO() Handler has been evaluated, the state of the lamp is not known yet. I could figure out the color earlier, but it would complicate the code a lot for what is a cosmetic issue. I hope that setting it to a neutral color will be less problematic. If you are still not happy with it, I will look again.
Thanks Bobo!
I have implemented a private sanity check for issue #4. #1 - We just had a play in a .Net form and by using anchor points we were able to stabilise the flickering during a resize, but of course, this would require the Sanity Checker dialog to be in a .Net form.
Thanks,
Mike
Hey Bobo,
Another last minute thought.
Would be good if the Sanity Check “Run Checks Now!” button had a “right-click” function to reset the Sanity Check dialog to its original, default size and positioned it somewhere close to the SMTD. Just in case a user throws it off to a secondary monitor, which then later gets moved to the ‘other’ side in the screen resolution setup in Windows.
Thanks,
Mike
Not necessary, since the Sanity Checker is sane enough to move itself to the other monitor if that ever happens.
Just like most other tools we write, it checks the size of the desktop and moves into the active area in case the last stored settings are out of bounds.
Same is true for SMTD itself - try to move it outside the desktop and see what happens next time you launch it…
I wouldn’t, I have too much respect for Grant as programmer to give him any code.
Random fact, we shared a house during my first 2 months at Frantic in Winnipeg.
