My experience with slow running was depending on the size of the file and not on the Rhino5/Rhino question. For a drawing for a specific battery design (1,4 GB file size ) it requires about 50 seconds to be opened. In addition there was no smooth rotation of the object possible any more, it was jumping from one position to a next (uncontrolled) position. I found two ways to improve the situation: 1. To use as many blocks as possible (which reduces the file size drastically) and to clean out every unnecessary detail (non needed points, lines, and every auxiliary construction support). In my special case I can imagine to reduce the file size to less than 300 MB accelerating the process considerably.
I’m using the described laptop mainly when teaching with simple models. And even then it is what I would call embarrassingly slow. I’m surprised to see that there are relatively little complaints about V6’ speed.
I’d say there are quite a few threads about this but, yes, it seems to be very hardware-specific.
The developers are still working hard at finding optimizations so please continue to check for updates.
i have probably 3 unresolved or lets say officially unacknowledged topics regarding that alone collected over the past several month, here the most recent.
hmm i am not convinced that this is true, there are 3 different specs in this thread already, actually since i had the honor to try 2 different specs there are 4, and mac users are always rather rare in complaining, since there are naturally also fewer. some may also not have time, maybe simply keep working in 5 or dont perceive the performance issues, why ever. i am not claiming it has nothing to do with specs at all but there seems to be a certain tendency obvious…
i am not using rhino 6 which is running on evaluation at all at least not really, due to this performance problems, rhino 5 is still installed and i am not motivated to buy rhino 6 in this condition… Rhino 6 was at some point faster in some regards still slower than 5, but with some recent updating it got actually even worse…
@stevebaer or @jeff i am not sure what to say more, i am happy that i am not the only one experiencing problems, but as long as you guys dont see anything nothing is going to be done, or whats the conclusion from all this?
exactly, this is what I am worried about too. I agree that this is not just hardware specific. I think developers are aware that this is the case and I hope they are just keeping it silent until (if ever) the cause of the slowness is found.
And for this I am afraid you are also not the only one. I think McNeel should send a poll to its customer base to investigate if this is a wide spread issue and people are just not complaining because they don’t use V6
i am ok with waiting, as long as i know that something is being investigated at all. honestly it came a bit as a surprise for me, when Rhino6 for mac got released, it seemed a bit overly sudden. also i am theorising that McNeel may be aiming for a simultaneous windows/mac 7 release, hence the current drawbacks for us?
i dont want to sound like a dig (again) and i can only point out that i seriously love this tool and i would help anything i can to get the performance on par and hopefully exceed rhino 5 performance, but right now Rhino 6 for mac seems more like a beta version, even more than Rhino 5 for mac was before it got released.
I think and I can confirm that R6 performance is a bit painful issue, even though many had been improved, there is still unused potential. But I dont know how realistic it is since Rhino seems to be tuned mainly for nvidia cards.
I think it’s more like the other way around, that is Nvidia card drivers are more tuned for CAD applications than AMD/Intel drivers are (they are more tuned for gaming apps). That seems to be the case for Windows applications anyway, I do not know how AMD/Intel drivers work on the Mac side. Add to that the fact that Apple is going “Metal”, so their OpenGL support may no longer be given all that much attention to.
Better Comp or Laptop = an extra 200-300$
Waiting on an update and your ocmputer to load = alot of stress and wasted time
Take the matter into your own hands and do what you can with what you got.
We don’t “tune” Rhino’s display for any specific GPU. We do have a handful of workarounds for known driver bugs and there are several that we have to work around on Mac which has been personally pretty frustrating.
One of the known bugs is with respect to AMD and Intel drivers going into what seems like an emulation mode when enabling tessellation shaders for wire drawing. This performance is so bad that we just disable tessellation shaders all together on these GPUs and switch to an alternative technique for wire drawing. We have submitted a sample for repeating this bug to AMD and am hoping to hear back on if there is something that can be done to improve this situation. These same computers running Windows (and Windows drivers) do not exhibit the issue at all and work just fine drawing tons of curves on the screen using the tessellation shaders. This is OpenGL which is cross platform code and there are very few differences between the Mac codebase and Windows hen it comes to display.
I hate to make this look like finger pointing, but at the moment I need to rely on feedback from the GPU companies to figure some things out.
not at all, I’m glad that you make clear that something is not working well at the mac side. And at the same time this makes the choice for me even more easy to get rid of this macbook and look for a pc replacement. I really like the machine, the screen and the trackpad quality, but in Rhino v6 it’s a total disaster at the moment.
what if you just skip the pain in trying to jump hoops and focus on metal right now instead, does that sound unrealistic? if i count 1 and 1 together that would make a win win as far as i understand it. or maybe that would leave a few old laptops mine included behind… so maybe a bad suggestion. i dont know i just hope you find a solution.
It does sound unrealistic for Rhino 6 and Rhino 7. Switching to metal is a massive task and will come with its own new set of pain points
yes that is clear, you pointed out version 8 may be realistic before, its ok for me. but maybe till then i can only suggest not to make any experiments and just use what has worked in 5, what would that really lose?
It would also be a massive effort to switch the display back to what was in V5 with Rhino 6. V5 was based on legacy fixed function OpenGL 2.1 and we switched to OpenGL 4.1 core profile based on recommendations at the time.
yes that would not make sense i agree, then rather use that effort into the future, get the code tweaked a bit that we can work and then maybe just a bit sooner and even if its heavy -> metal for some 7.3000282837 service release whatever, who cares about the numbers anyway as long as it works then, at least IMHO.
+1 for transparency and clarity, thanks…(eases wtf factor)
I was running the 6 beta on a 2010 MAC and saw no problems.
This can be anything. But what it comes down to is that most if not all the MacBooks that have issues are the later builds with amd graphic cards.
What are the specs of this system and did you notice any difference in performance between rhino 5 and 6?
OK lock n lol baby, you guys have tweaked something with the latest update and its BLAZLINGY FAST. come and get a hug for it!!!