Hi All, I’m posting about a problem with the stereo viewport modes on the latest WIP update.
The setting for anaglyph viewing appears to have no effect on the viewport. I think this may have worked in a previous release, and definitely on an older Macbook Pro. The setting for the hardware shutter 3d seems to shift the view right [so looks like that may be working, tho I don’t have the monitor to test it], and this seems to be the case for all the Display Modes.
Would appreciate any thoughts or information. Or whether this just hasn’t been totally implemented yet…
Thanks!
//
Below is the OpenGL readout, in case this is similar to the antialiasing problem with retina displays.
//
Software information
Software versions
Rhinoceros version: 5.0 WIP (5A693)
IronPython version: 5.1.2015.131
Language: en (MacOS default)
OS X version: Version 10.10.1 (Build 14B25)
Plug-ins
None
Third party kernel extensions
None
Hardware information
Computer hardware
Hardware model: MacBookPro11,3
Processor: Intel Core i7-4850HQ CPU @ 2.30GHz
Memory: 16 GB
Architecture: Intel 64 bit
Video hardware
Graphics: NVIDIA GeForce GT 750M 2048 MB
Memory: 2048 MB
Screen size: 1920 x 1200
Displays: Color LCD (295dpi 2x)
USB devices
Apple: Internal Memory Card Reader
Apple Inc.: Apple Internal Keyboard / Trackpad
Apple Inc.: Bluetooth USB Host Controller
Bluetooth devices
None
OpenGL information
OpenGL software
OpenGL version: 2.1 NVIDIA-10.0.43 310.41.05f01
Render version: 2.1
Shading language: 1.20
Maximum texture size: 16384 x 16384
Z-buffer depth: 24 bits
Maximum viewport size: 16384 x 16384
Implementation settings
Use texture compression: No
Thanks for bringing this to our attention. It ought to be working, but can see that it’s not. We will investigate…if you want to track progress, please use this bug tracker item (MR-1383).
Apparently that particular bug report is not made available to the general public. That’s probably just an oversight. @dan? Just for information, some older reports can be closed because they contain information identifying users but that shouldn’t be the case here.
It should be public now. We default to private and have a double-lock setting just in case (some bugs have personal info or attached files that may be sensitive). Sometime we (ok, I) forget to unlock the second lock.
I understand that you might feel that 14 days is a long time and that this is important to you but @jeff has quite a bit more than just this on his plate. Perhaps you can make a case why this particular issue should be moved to the top of the pile? If a developer gets more insight and feedback from users as to why things are critical it might help in the process of assigning resources.
The stereo works perfectly in the latest WIP! Thanks so much for working it out.
And sorry if I sounded unappreciative in my earlier post. You guys do a really amazing job taking care these issues.