what?! really?!
When installing Rhino 7:
I’m still working on getting Rhino 8 WIP to run on wine, but I recall that it was reaching out to baidu, as well.
However, after installation you can run it offline.
This seems perfectly normal. The gravatar call is for my account, google is if you’ve associated your mcneel login with google, and I’m assuming baidu is the same as google.
It’s normal these days given complexity of desktop applications. I haven’t used any of these methods though (just email and passwords).
A few more notes regarding multiGPU setups (e.g. laptop with both an integrated Intel and a dedicated Nvidia GPUs) wine (or one of its components like dxvk) seems to choose Nvidia card by default.
To use Intel card I removed these files on KDE/X11:
/usr/share/X11/xorg.conf.d/10-nvidia-drm-outputclass.conf
/usr/share/glvnd/egl_vendor.d/10_nvidia.json
/usr/share/vulkan/icd.d/nvidia_icd.json
Presumably you could adjust them with environment variables as well.
If you are on Arch add them also to NoExtract entry in /etc/pacman.conf (space separated without the leading slashes) to prevent the package manager from reinstalling them.
A lot of medium-size scenes run pretty smoothly just on Intel GPU, so for laptop users this may be useful.
Run on iGPU:
wine Rhino
Run on Nvidia (Prime render offloading):
env DRI_PRIME=pci-0000_01_00_0 __VK_LAYER_NV_optimus=NVIDIA_only __GLX_VENDOR_LIBRARY_NAME=nvidia wine Rhino
You may need to adjust the first variable with the correct PCI address of your card (get it with lspci command). You may try __NV_PRIME_RENDER_OFFLOAD=1 as well.
On KDE/Wayland for some reason I didn’t have to remove vulkan’s icd file.
The reason why X11 can still be useful for some users may be lack of support for simultaneous displaylink and multiGPU support on most wayland compositors (KDE, wlroots). But this may be a niche use case.
2 Likes
I’ve previously mentioned slow startup times on wine (~40 seconds) compared to windows (~12 seconds). This might have been caused by incoherent caches - constant testing and deleting .wine directory must have caused some inconsistencies. Now after using Rhino for Nth time without major changes to .wine folder startup times are the same as on Windows (~12 second).
People said the same thing about OS X for years.
1 Like
At current state Rhino 8 isnt working.
I try to install it but it stucked at installing the EdgeWebView Version 116.x.x.x. You can jump over it by terminat the install of the WebView but logically rhino will not start without it. I also have tried to install the WebView manually but the version 116 is stucked as well. Newer version of WebView could be installed without problems but i think they are not notice by rhino.
So at the moment i think we need to wait if mcneel will update to an newer WebView or wine is fixing the problem with the old version (there is no bugreport about it at the moment so this will be just luck)
If using netcore you need to point wine to the path of the Windows-DotCore installation via “DOTNET_ROOT=/home/xxx/.wine_rhino8_dev/drive_c/Program\ Files/dotnet”
I dont know if/ I dont think WebView is the only problem but it is the first i found and without fixing i could not check if something other is wrong.
4 Likes
1 Like
I just noticed that Plasticity is available on Linux. 
EDIT: Fun side effect regarding Linux though (not that McNeel needs any more bug reports, since they have more than a decade of backlog to go through still)…
7 Likes
@atelierkirchhof if I’m reading this correctly this issue has been reported 2 months ago to wineHQ, but there seemed to be no update since then. Other users are experiencing this as well.
It’s a real shame and as pointed out makes you really wish McNeel kept backwards compatibility for .3dm format across the versions, otherwise you risk losing access to your work without a backup windows (virtual) machine.
I dont know if/ I dont think WebView is the only problem but it is the first i found and without fixing i could not check if something other is wrong.
Very relatable, in other words we don’t even know yet what we don’t know to get it to work. If only Rhino was open-source 
…
what’s with that random asianometry plug 
? I love his channel, but is there some context?
No. That would imply that no new object types etc. could be invented in succeeding versions. There is no such thing as infinite backwards compatibility.
3 Likes
Backwards compatibility is compatibility with older versions of the software, Rhino does that. One of the problems that may arise is having to keep legacy code around and maintained.
Backward compatibility - Wikipedia
What you probably mean is forward compatibility. That’s more problematic an usually only done in a major release or a small number of major releases: Forward compatibility - Wikipedia
Hope this doesn’t come across as nitpicky, just want people to understand as this took me a while as well.
No, it does not directly. It allows you to save a file in older version format so that it can be successfully opened in that version or later.
No, I don’t believe so.
A forward compatible design can process at least some of the data from a future version of itself.
I’m pretty sure they didn’t design Rhino 1.0 with provisions for reading files from Rhino 8.0 25 years later. Nor did they design Rhino 1.0 to make sure the files it produced could be opened in V8.0.
More likely is that each succeeding version of Rhino has provisions for reading older version files. The basic .3dm format hasn’t changed all that much I believe, but new geometry types and other elements have been added in every new version that previous versions wouldn’t understand. Rhino probably just reads the file header, sees the file is from a later version, stops reading and throws up the warning message.
This should be the case, tested when using Grasshopper human plugin, using import3dm in Rhino7gh can read rhino8 files
That is because the latest rhino3dm is built against OpenNURBS of Rhino 8, so it understands.
Hope this doesn’t come across as nitpicky
Not at all, you are right and I take that back - “forward compatibility” would stifle innovation for Rhino for many practical reasons as @Helvetosaur mentioned. There are programs however (inkscape AFAIK), which would still open future releases of their standardized files (e.g. svg) or at least their still recognizable portions. It would throw warnings about unrecognized objects, but it would still try to read as much of it as it can.
I don’t know enough about serialization and development of complex computer graphics software to judge what consequences this would have on a program like Rhino, so take it just as a wishful thinking of some lone Linux user
As a Windows 11 user (since 3.0) --I am disappointed with Windows 11. For me, there was no improvements. For me, Windows 11 is not as stable as W10.
The better Windows versions were: 3.11, WFWG, 95, XP, 2000, 7, and 10.
I would rather use Windows 10 than 11.
- Bluetooth still rots on Windows 10/11.
- Group by was likely put there for AI and not humans.
- Dread what MS will do with AI.
- Windows event logs still sort slow. (With 3900x/NVMe Gen 4 SSD/32GB RAM.
- Windows still boots slow.
- Windows does not shut down unless you make a custom icon and/or set the mode. Otherwise it suspends.
- Windows 11 Start Menu cannot sort programs into categorizes like W10 could.
- Windows 11 user cannot set a low power mode while plugged in.
- Why ever does it take so long to bring up the right hand menu, for like turning on Bluetooth?
- Important system menus are buried deeper and deeper. If I wanted this that, I’d buy a Mac.
- “Show more options” ruined the desktop contextual menu.
- Cannot bold the desktop font.
4 Likes