Split off interior rendering posts to keep this thread clean
I installed V6 a few days ago and I had a lot of trouble with random crashes. I think it may have something to do with the AutoSave.
The location of the AutoSave file in V5 is here: C:\Users\ [YOUR USER NAME] \AppData\Roaming\McNeel\Rhinoceros\5.0\AutoSave\RhinoAutosave.3dm
However, the location of the Autosave in V6 is here: C:\Users\ [YOUR USER NAME] \AppData\Local\McNeel\Rhinoceros\6.0\AutoSave\RhinoAutosave.3dm
Note that the root changed from “Roaming” to “Local” between V5 and V6. I went to look for a backup in the “usual place” in the “Roaming” root, as I used to do with V5, and in the “Rhinoceros” folder of that root there were three folders, one was labelled “5.0”, one labelled “6.0” and a shortcut labelled “App Data”. There was no “AutoSave” folder in the “6.0” folder (the old AutoSave folder was there in the the “5.0” folder). When I opened the “App Data” folder and then the subsequent folders, I kept going in a loop bringing me back to the same place over and over. I deleted the “AppData” shortcut in the “Rhinoceros” folder of the “Roaming” root and so far I had no freezes. I found the backup in an AutoSave folder in the new location in the “V6” folder of the “Local” root. So, I suspect that this change from “Roaming” to “Local” may be the culprit.
Hello - thanks, I’ve asked the developer to have a look.
I am still getting some random crashes and I am still more and more convinced that it has something to do with the AutoSave. However, strangely, the AutoSave files are not saved in the AutoSave folder. While looking for something else in the Recycling Bin, I found a pile of AutoSave files there. In other words, for some reason, the AutoSave function saves the backup files straight to the Recycling Bin. This is something that needs some attention.
yes it seems autosave files are in the recycle bin, had a few crashes again yesterday when using layouts, hopefully there will be some upcoming fixes
more crashes today, about 5 in total, has cost me at least a couple hours of work
thinking of reverting back to V5 for now
I had a few more crashes today. Some of these crashes happened while I was also using Skype - I often use “share screens” with another caller in order to show artwork how I draw it. So, I think that there must be some kind of “clash” when the video card is under the strain of running both Rhino and Skype. I was using the same computer with V5 and it never ever crashed, it was rock-solid stable. V6 seems to be really delicate.
It must be something to do with V6, not the computer. The computer is quite capable, here are the specs:
Rhino 6 SR2 2018-3-6 (Rhino 6, 6.2.18065.11031, Git hash:master @ cd4fa1dcdec31cb58baacef0855771173af7196f)
Windows 10.0 SR0.0 or greater (Physical RAM: 32Gb)
AMD Radeon™ R9 270 (OpenGL ver:4.5.13476 Compatibility Profile Context 188.8.131.529)
Safe mode: Off
Use accelerated hardware modes: On
Redraw scene when viewports are exposed: On
Anti-alias mode: 4x
Mip Map Filtering: Linear
Anisotropic Filtering Mode: Height
Vendor Name: ATI Technologies Inc.
Render version: 4.5
Shading Language: 4.50
Driver Date: 6-27-2017
Driver Version: 184.108.40.2069
Maximum Texture size: 16384 x 16384
Z-Buffer depth: 24 bits
Maximum Viewport size: 16384 x 16384
Total Video Memory: 2 GB
C:\Program Files\Rhino 6\Plug-ins\Commands.rhp “Commands”
C:\Program Files\Rhino 6\Plug-ins\rdk.rhp “Renderer Development Kit”
C:\Program Files\Rhino 6\Plug-ins\AnimationTools.rhp “AnimationTools”
C:\Program Files\Rhino 6\Plug-ins\RhinoRender.rhp “Rhino Render”
C:\Program Files\Rhino 6\Plug-ins\rdk_etoui.rhp “RDK_EtoUI”
C:\Program Files\Rhino 6\Plug-ins\rdk_ui.rhp “Renderer Development Kit UI”
C:\Program Files\Rhino 6\Plug-ins\NamedSnapshots.rhp “Snapshots”
C:\Program Files\Rhino 6\Plug-ins\RhinoCycles.rhp “RhinoCycles”
C:\Program Files\Rhino 6\Plug-ins\Toolbars\Toolbars.rhp “Toolbars”
C:\Program Files\Rhino 6\Plug-ins\3dxrhino.rhp “3Dconnexion 3D Mouse”
C:\Program Files\Rhino 6\Plug-ins\Displacement.rhp “Displacement”
Did you elect to send in the crashdumps?
No crashdump file was generated. Maybe a “crash” is not the right word for what happens? What I mean by “crash” is that the screen goes foggy and stays foggy. Last time I left it in that state for about one hour (it just happened that I had to do something else at the time) and it still did not get out of that state. When this happens, no commands work so I have to shut down the software from Task Manager.
That would be a ‘hang’. What are you doing when this happens? Using Raytraced or something else?
You may want to try out the latest release candidate for 6.3. In
Help > Check for Updates... set the update frequency to Service Release Candidate:
I mainly use “shaded” and “ghosted”.
I had another “hang”, but worse, just now. I was on Skype and I had an .obj file open in Rhino. I was not sharing screens in Skype, it was just a conversation with video. I tried to rotate the object, in “shaded” mode, and the whole screen went pixelated, then it went black and then I had to restart the computer. So, whatever this is, it related to the video card. I thought that an AMD Radeon R9 270 with 2 MB RAM was enough, at least it worked perfectly with V5, never had a “hang”.
Thanks for the suggestion, I will try the 6.3 version of the software.
If you are up for it perhaps you could next time on such a hang try to manually creat a dump file in the task manager and send it to us with www.rhino3d.com/upload - paste a link to this discussion in the comments area for the upload. It will be a large file, so you could zip it before sending.
If you don’t have such an entry in the context menu then don’t bother finding it elsewhere
It just might help us figure out where the hang happens.
Thanks in advance,
I uploaded the crashdump file to dropbox and I emailed the link to the email address on the “upload” page. Please let me know if that reveals anything.
Hello - I see your upload - thanks.
@RaduB - it looks like the upload to our site failed. Can you message me your Dropbox link?
link sent by PM
@RaduB it looks like the hang occurs in the driver. Could you ensure ReLive (Raptr) is disabled before starting Rhino again?
If that doesn’t work please update to the latest AMD driver - the most recent one seems to be https://www2.ati.com/drivers/beta/win10-64bit-radeon-software-adrenalin-edition-18.3.3-march18.exe
When you do update the driver elect to do a clean install, make sure you don’t install ReLive. Just the drivers for the devices the installer finds.
Let me know if these steps help.
Thanks for the advice. I did a clean install and reinstalled the AMD software. I uninstalled the Raptr software - I think that was a leftover from the original Catalyst AMD software, which was later replaced in updates.
So far I had no crashes while using the Rhino software on its own.
However, the crashes continue while using the Rhino software with Skype, with shared screens. But this time, the crash is different, more global. First the mouse cursor cannot click anything, the keyboard is unresponsive, then after a short while the mouse cursor becomes frozen. Because the keyboard is unresponsive, I cannot bring up the Task Manager, so I cannot get a crashdump. Also, because none of the input methods work anymore, I have to do a hard shut-down and restart. So, it seems that I cannot use V6 and Skype on shared screens anymore. This was a very helpful tool. I think I may have to revert back to V5.
@Radub, hrm that doesn’t sound good at all. You probably could try reinstalling the older driver you had - so that at least your machine wouldn’t become completely unresponsive: https://support.amd.com/en-us/download/desktop/previous?os=Windows%2010%20-%2064
Not sure what to check further. I suppose you have already applied all possible Windows updates?
I just checked, Windows is up to date.
I think I will give the current version of AMD driver another chance. The latest version of the video driver seems to be more stable when using V6 on its own. The problem with Skype was present with the previous version too, but, on top of that, the previous version also hanged when using V6 on its own. So, we are halfway there, V6 appears to be stable on its own now. The problem occurs when using V6 when sharing screens via Skype.
Ok, so some progress. Perhaps you could test some other screen sharing services too?