Anaglyph Stereo on Macbook Retina GT750M

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…



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)


Third party kernel extensions

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

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

Appearance settings
Antialiasing: 0x
Mip map filtering: None
Anisotropic filtering: None


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).

Thanks for looking into this! Any advice on how to use the bug tracker? I’m getting a permissions problem…

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.

Ok, that makes sense, I can access it now. Just to update, I also tested the latest WIP on a 2010 Macbook pro non-retina, and saw the same behavior.

1 Like

Any updates on this? It isn’t working on 5A713 either.

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.

Hi fjurious,

We’re not seeing this in current builds of Mac Rhino. Are you still seeing this problem with the latest WIP?

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.