Block display bug

Blocks are not displayed correctly in Artistic/pen mode - see video and example file.
rhino 5 mac-block display bug.mov (5.3 MB) pohled_ulicni 3D.3dm (2.3 MB)
Software information

Software versions
Rhinoceros version: 5.0.2 (5A865)
IronPython version: 5.1.2015.131
Language: en (MacOS default)
OS X version: Version 10.10.5 (Build 14F27)

Plug-ins
/Library/ScriptingAdditions/Default Folder X Addition.osax/Contents/MacOS/Default Folder X Addition
/Users/mliko/Library/PreferencePanes/Default Folder X.prefPane/Contents/Resources/Default Folder X.bundle/Contents/Resources/Cocoa Patcher.bundle/Contents/MacOS/Cocoa Patcher

Third party kernel extensions
at.obdev.nke.LittleSnitch (4246)
com.karios.driver.DuetDisplay (1)
com.logmein.hamachi (1.0)
com.parallels.kext.usbconnect (10.2.2 29105)
com.parallels.kext.hypervisor (10.2.2 29105)
com.parallels.kext.netbridge (10.2.2 29105)
com.parallels.kext.vnic (10.2.2 29105)

Hardware information

Computer hardware
Hardware model: iMac11,1
Processor: Intel Core i5 CPU 750 @ 2.67GHz
Memory: 12 GB
Architecture: Intel 64 bit

Video hardware
Graphics: ATI Radeon HD 4850 512 MB
Memory: 512 MB
Screen size: 2560 x 1440, 1200 x 1600
Displays: iMac (109dpi 1x), SyncMaster (98dpi 1x)

USB devices
Apple, Inc: Apple Keyboard
Apple Inc.: Built-in iSight
Apple Computer, Inc.: IR Receiver
Tablet: PTK-840
Apple: Internal Memory Card Reader
Apple Inc.: Bluetooth USB Host Controller

Bluetooth devices
Apple: Apple Wireless Trackpad

OpenGL information

OpenGL software
OpenGL version: 2.1 ATI-10.0.35
Render version: 2.1
Shading language: 1.20
Maximum texture size: 8192 x 8192
Z-buffer depth: 24 bits
Maximum viewport size: 8192 x 8192

Implementation settings
Use texture compression: No

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

This is a known bug (MR-2029). Thanks for reporting…keeps the pressure on.

It’s been over 2 years now…

What kind of pressure are we talking about here. If this has been a known bug for over 2 years on the windows version, then how, did it make it into the Mac version?

Really?

Rhino 5 for Windows and Rhino 5 for Mac share a large portion of the display code. This is not meant to excuse anything.

@jeff can explain further what it will take to get this fixed.

It’s actually been known longer than that… It just hasn’t taken any sort of priority to get fixed. For two main reasons:

  1. All kinds of discussions have been going on about true vector output and display (like Make2D stuff), so making any changes to technical modes would be wasted effort.

  2. Making technical modes work correctly with Block objects would require an entire rewrite and restructuring of how things are currently done…given the latter reason, that again would be wasted effort.

The problem:

Technical modes are 100% pure trickery. They do not consist of any geometry, vectors, lines, what have you. The “effect” is achieved by using the existing geometry to populate depth buffers and color buffers and using the information collected to generate the results in pixel format. Generating some of that information can be a costly operation, and therefore much of the information is cached on the objects and recalled for immediate usage on each frame. Regeneration of the information is done only when it’s absolutely necessary. This helps keep frame rates higher.

Block instances are not objects, they do not contain any geometry, they are simply shadowy reflections of the Block definition, consisting of only a transform. When you see an instance of a block in your viewport, it’s not really there, it’s just a rendered transformed version of the block definition. Therefore, there really isn’t anything to cache the technical information on… You can’t cache it on the definition, that would be worthless, you can’t cache it on the instance (because that’s currently a limitation internally), and since the technical information is view dependent, you also can’t cache some version of the tech info and then transform that…it just doesn’t work that way.

That being said, I’m hoping to get many of the shortcomings with Technical modes solved in V6, but until the more important issues are taken care of, and until we have a clear road map on 2D vector support, I’m afraid this takes lower priority.

Lastly, Technical modes were initially not designed to be working/modeling modes, they were purely for visual effect. It was intended that users shift into Technical mode, spin things around, and then shift back out to a working mode. That, unfortunately is not how things have evolved… So normally I would just tell you to explode your blocks when in a technical mode, then undo the explode when you leave the technical mode…but I have a feeling you’ll tell me that you use Pen mode as a true working mode, in which case my suggestion won’t work.

Thanks,
-Jeff

1 Like

this cannot be true :shocked

Jeff,

Thanks for the explanation. I guess I’ve been assuming that, since this issue didn’t exist in Rhino4, it would be a simple fix. Fortunately, there is a simple workaround, and life goes on.

We don’t really work in technical mode, but we use it in detail views on our layout pages combined with pictureframes to make our presentation drawings. If we had to use Make2d for this stuff, work would drag to a crawl. So, yes, we really do rely on the technical modes.

It would be nice if this was fixed, but in the overall scheme of things, it’s a pretty small blip in a system that works incredibly well. Jeff, thanks for the trickery!

Jim