Curve block - performance

Rhino Rhino for Mac
1

Hi!
I am surprised how extremely bad impact on performance has using blocks. I would think that blocks should boost the file in terms of performance and not the opposite?

I tried small test in attached file which contains 400 simple curve blocks.

Testmaxspeed:

with block - 64.5 sec, 1,5 FPS
blocks exploded to curves - 1.72 sec, 58.4 FPS

Why is that? This is a massive deterioration… @stevebaer?

Rhino 6 SR26 2020-5-12 (Public Build, 6.26.20133.11312, Git hash:master @ 10b580fee7870325629eca090ae239be3537f6bf)
License type: Commercial, build 2020-05-12
License details: Cloud Zoo. In use by: HALLSTEIN ()

Apple Intel 64-bit macOS Version 10.15.4 (Build 19E287) (Physical RAM: 16Gb)
Mac Model Identifier: MacBookPro14,3
Machine name: newyork
Language: en-NO (MacOS default)

AMD Radeon Pro 560 OpenGL Engine (OpenGL ver:4.1 ATI-3.8.24)

OpenGL Settings
Safe mode: Off
Use accelerated hardware modes: On
Redraw scene when viewports are exposed: On

Anti-alias mode: None
Mip Map Filtering: Linear
Anisotropic Filtering Mode: Height

Vendor Name: ATI Technologies Inc.
Render version: 4.1
Shading Language: 4.10
Maximum Texture size: 16384 x 16384
Z-Buffer depth: n/a
Maximum Viewport size: 16384 x 16384
Total Video Memory: 4 GB
Graphics: Radeon Pro 560
Displays: Color LCD (258dpi 2x), LG UltraFine (173dpi 2x)

Graphics processors
Intel HD Graphics 630 (1536 MB)
Radeon Pro 560 (4 GB)
Color LCD (1680 x 1050)
LG UltraFine (2048 x 1152)

USB devices
LG Electronlcs Inc.: LG UltraFine Display Camera
3Dconnexion: CadMouse
LG Electronics Inc.: USB Controls
LG Electronics Inc.: USB Audio
Apple Inc.: Apple T1 Controller

Bluetooth devices
Broadcom: Magic Keyboard

Third party kernel extensions
com.f-secure.XFENCE (2.0.47f2) EEF14535-1870-3C34-BEE1-F9EAD35C633D
com.3dconnexion.driver (1.1.0) 94E8C49C-EDED-3526-88BE-E7207560C0D2
com.f-secure.kext.nke (2.0.13f1) 711549F9-1823-3796-8209-0793938090FE
com.f-secure.kext.fsauth (1.0.5d1) 82AD7A11-7E6E-31C0-8A45-309DFCA2105A
com.logmein.driver.LogMeInSoundDriver (411.12.27) FE647994-3A1E-30F6-ACD1-B5684A63EB43

Third party plugins
/Library/Frameworks/3DconnexionClient.framework/Versions/A/3DconnexionClient
/usr/lib/swift/libswiftCore.dylib
/usr/lib/swift/libswiftCoreFoundation.dylib
/usr/lib/swift/libswiftCoreGraphics.dylib
/usr/lib/swift/libswiftDarwin.dylib
/usr/lib/swift/libswiftDispatch.dylib
/usr/lib/swift/libswiftFoundation.dylib
/usr/lib/swift/libswiftIOKit.dylib
/usr/lib/swift/libswiftObjectiveC.dylib
/usr/lib/swift/libswiftXPC.dylib
/usr/lib/swift/libswiftCryptoTokenKit.dylib
/usr/lib/swift/libswiftos.dylib
/Users/petrtuma/Library/Application Support/McNeel/Rhinoceros/MacPlugIns/maxwell_rhino.rhp/libmwdotnet_native.dylib
/Applications/Maxwell Render 5/libmxcommon.dylib
/Applications/Maxwell Render 5/libcudart.10.1.dylib
/Applications/Maxwell Render 5/extensions/wireframetexture.osx.mxx
/Applications/Maxwell Render 5/extensions/LensExtensions.osx.mxx
/Applications/Maxwell Render 5/extensions/MaxwellCloner.osx.mxx
/Applications/Maxwell Render 5/libboost_date_time.dylib
/Applications/Maxwell Render 5/libboost_system.dylib
/Applications/Maxwell Render 5/libboost_filesystem.dylib
/Applications/Maxwell Render 5/libboost_iostreams.dylib
/Applications/Maxwell Render 5/libboost_thread.dylib
/Applications/Maxwell Render 5/extensions/xritebrdf.osx.mxx
/Applications/Maxwell Render 5/extensions/MaxwellProcedurals.osx.mxx
/Applications/Maxwell Render 5/extensions/TiledTexture.osx.mxx
/Applications/Maxwell Render 5/extensions/MaxwellHair.osx.mxx
/Applications/Maxwell Render 5/extensions/MGrassH.osx.mxx
/Applications/Maxwell Render 5/extensions/MGrassP.osx.mxx
/Applications/Maxwell Render 5/extensions/MaxwellGrass.osx.mxx
/Applications/Maxwell Render 5/extensions/SubdivisionModifier.osx.mxx
/Applications/Maxwell Render 5/libmwglew.dylib
/Applications/Maxwell Render 5/libmwtbb.dylib
/Applications/Maxwell Render 5/extensions/MaxwellSea.osx.mxx
/Applications/Maxwell Render 5/extensions/MaxwellScatter.osx.mxx
/Applications/Maxwell Render 5/extensions/AssetReference.osx.mxx
/Applications/Maxwell Render 5/extensions/MaxwellVolumetric.osx.mxx
/Applications/Maxwell Render 5/libmwtbbmalloc.dylib
/Applications/Maxwell Render 5/extensions/MWObjectAlembic.osx.mxx
/Applications/Maxwell Render 5/extensions/MaxwellMesher.osx.mxx
/Applications/Maxwell Render 5/extensions/MaterialModifiers.osx.mxx
/Applications/Maxwell Render 5/extensions/TableBrdf.osx.mxx
/Applications/Maxwell Render 5/extensions/rfmeshes.osx.mxx
/Applications/Maxwell Render 5/extensions/MaxwellParticles.osx.mxx
/Applications/Maxwell Render 5/extensions/rwmeshes.osx.mxx
/Users/petrtuma/Library/Application Support/McNeel/Rhinoceros/MacPlugIns/maxwell_rhino.rhp/libmxdotnet_native.dylib
/Users/petrtuma/Library/Application Support/McNeel/Rhinoceros/MacPlugIns/Twinmotion Direct Link 2020.rhp/libDLRhinoNative.dylib
/Users/petrtuma/Library/Application Support/McNeel/Rhinoceros/MacPlugIns/Twinmotion Direct Link 2020.rhp/libPolygonCruncherSDK.dylib
/Users/petrtuma/Library/Application Support/McNeel/Rhinoceros/MacPlugIns/Twinmotion Direct Link 2020.rhp/libSyncData.dylib
/Users/petrtuma/Library/Application Support/McNeel/Rhinoceros/MacPlugIns/Twinmotion Direct Link 2020.rhp/libomp.dylib
/Users/petrtuma/Library/Application Support/McNeel/Rhinoceros/MacPlugIns/Twinmotion Direct Link 2020.rhp/libc++.1.dylib
/usr/lib/log/liblog_network.dylib

Rhino plugins
/Applications/Rhinoceros.app/Contents/Frameworks/RhCore.framework/Resources/ManagedPlugIns/RhinoCycles.rhp “RhinoCycles” 6.26.20133.11312
/Users/petrtuma/Library/Application Support/McNeel/Rhinoceros/MacPlugIns/Twinmotion Direct Link 2020.rhp “Twinmotion Direct Link 2020” 1.0.0.0
/Applications/Rhinoceros.app/Contents/PlugIns/NamedSnapshots.rhp “Snapshots” 6.26.20133.1002
/Applications/Rhinoceros.app/Contents/PlugIns/RhinoBonusTools.rhp “Rhino Bonus Tools” 6.26.20133.1002
/Applications/Rhinoceros.app/Contents/PlugIns/RhinoLabsTools.rhp “Rhino Labs Tools” 6.26.20133.1002
/Applications/Rhinoceros.app/Contents/Frameworks/RhCore.framework/Resources/ManagedPlugIns/GrasshopperPlugin.rhp “Grasshopper” 6.26.20133.11312
/Users/petrtuma/Library/Application Support/McNeel/Rhinoceros/MacPlugIns/maxwell_rhino.rhp “Maxwell for Rhino” 5.0.6.2
/Applications/Rhinoceros.app/Contents/PlugIns/AnimationTools.rhp “AnimationTools” 6.26.20133.1002
/Applications/Rhinoceros.app/Contents/PlugIns/PanelingTools.rhp “PanelingTools” 6.26.20133.1002
/Applications/Rhinoceros.app/Contents/Frameworks/RhCore.framework/Resources/ManagedPlugIns/Commands.rhp “Commands” 6.26.20133.11312
/Applications/Rhinoceros.app/Contents/Frameworks/RhCore.framework/Resources/ManagedPlugIns/RDK_EtoUI.rhp “RDK_EtoUI” 6.26.20133.11312
/Applications/Rhinoceros.app/Contents/Frameworks/RhCore.framework/Resources/ManagedPlugIns/BlockEdit.rhp “BlockEdit” 6.26.20133.11312
/Applications/Rhinoceros.app/Contents/Frameworks/RhMaterialEditor.framework “Renderer Development Kit” 6.26.20133.1002
/Applications/Rhinoceros.app/Contents/PlugIns/RhinoRender.rhp “Rhino Render” 6.26.20133.1002
/Applications/Rhinoceros.app/Contents/PlugIns/Displacement.rhp “Displacement” 6.26.20133.1002
/Applications/Rhinoceros.app/Contents/Frameworks/RhCore.framework/Resources/ManagedPlugIns/RhinoDLR_Python.rhp “IronPython” 6.26.20133.11312

1 Like
2

Blocks improve file size and memory use, but not display - you still have to show the same thing on the screen. There are also some problems with how the display needs to be calculated for blocks, so in V6 in any case it’s generally slower than for discrete elements (IIRC). Some of that has been addressed for V7 (also IIRC).

3

So basically what you are saying is, that block will be always problem in terms of display performance? I do not know how far the improvements go in R7, but this difference was quite unexpected :slight_smile:

4

Please give V7 a try if you get a chance.

5

Hi @stevebaer

I tried and I got an even worse result.

with block - 76.5 sec, 1,3 FPS
block exploded - 31.3 sec, 31 FPS

running this: Version 7 WIP (7.0.20133.12126, 2020-05-12)

6

Hi @petumatr, did you try the same scene in V5? From my experience, I’m pretty sure that the same file will be way faster in V5. As I mentioned in a few other posts, performance in V6-V7 is really really slow compared to V5 as if something is wrong with the new versions.

7

Hi,
not yet. I will give it a stab :slight_smile:

8

Heisann -

I’m not seeing an attached file, could you post that?
(mainly wondering if you are talking of 400 different block definitions or 400 instances of the same block definition - but having a file that we can look at would probably help anyway…)
-wim

9

Hei!

Damn, my fault, sorry… here it (hopefully) is.

curve block performance.3dm (3.3 MB)

10

Just tested your file on my old MacBook Pro 2013, as I’ve been experiencing lately, V5 is considerably faster than V6 and V7.

V5 Testmaxspeed= 13.87 seconds
V6 Testmaxspeed= 35.15 seconds (2.84fps)
V7 Testmaxspeed= 31.84 seconds (3.14fps)

2 Likes
11

Hi @jespizua, thanks for testing! Well, that just confirms what you said. Is this MacBook Pro with Nvidia card? It is interesting you achieved a better result than on my newer one MacBook Pro 2017.

In this case @wim it is one definition - 400 copies.

12

Hi @petumatr, yes it has a Nvidia Card indeed. It’s really hard to believe how badly are AMD cards behaving compared to Nvidia…
I’ve just read that 10.15.5 has been released, so maybe Apple has improved any of the current graphic drivers issues.

But what I can not understand is why V5 has more than 2X better performance that V6/V7?

2 Likes
13

Yep, that’s not very nice…

Philip

1 Like
15

The developer has the model and is aware of the issue.
Thanks

1 Like
16

Thank you John for taking this issue seriously.

My problems with R mac v6/7:

  • 2d drawing performance
  • material editor / texture editor (laggy and unresponsive)

Rhino is a great piece of software and we all love it. That’s why we want to help in making it better.

2 Likes
17

If your implying that we have not been taking display performance seriously, you are mistaken.
We are frustrated with the general display performance of Mac Rhino and very much so with curve drawing.
I’m not directly involved in this customer/developer support and testing. I hear a lot of general grumbling about how difficult it is to deal with Apple and how opaque they are compared to Windows development. Part of that is the huge difference in the size of the development community.
I’m not at all saying we have given up, but the going is slow, complicated, and mostly on our own. OpenGL techniques that work well in Windows may not work nearly as well in Mac, for no apparent reason.

1 Like
18

Also just wanted to share, that I and a lot of my colleagues are really appreciating the progress and new features that are being developed with the new Rhino Mac versions, as well as the work that has been done so far.
Sad to hear, that many parts/features of Rhino are cumbersome to develop on macOS. Hope this will improve with time / new APIs or sth.
Wishing you guys some good work and I am trying to be as helpful as possible! :100:

1 Like
19

that is why i say it would be best to focus on metal right now and leave all that intermittent interim experiments aside which everybody is suffering on. it has been said that is not easy and needs some restructuring, but was announced that this has to wait till version 8 minimum, even though some parts are being prepared for version 7. if it is anyhow possible i would highly put my vote focusing on metal.

really the performance along with some hick ups held me back updating to version 6 all along. even things like simple zoom in an out (with the mouse wheel) are so sluggish on version 6, that i feared you guys will lose it completely at some point…

1 Like
20

Just another example of Apple going its own route and throwing out standards like OpenGL which could be used cross platform. So then all the development for OpenGL on the Windows side is useless on Mac and a whole parallel development path and the associated costs needs to be made for Metal - just so Rhino can run on Mac. Who is going to pay for all that? Answer - mostly Windows users, as they represent the bulk of Rhino licenses…

21

@encephalon totally agree with you! As OpenCL has been deprecated, it is clear that sooner or later Metal will have to be implemented.

That’s also true… On the other side, it seems that the core of OpenCL is already pretty old and much more performance is achievable with a new API like Metal. But yeah, that is only my very humble understanding of the situation.