It happens all over the place.
Graphics problems are just piling up…
Once again, you haven’t sent anything we can use to reproduce the problem.
Please send a 3dm file and the specifics we need to see the problem.
I noticed that too here every now and then (or at least it seems to be related), and this time I can reproduce it with the attached simple file:
Without instruction, are you seeing these line ends that extend too far when wheel zooming only?
Assuming so, I’ve tried it on your “yucky” file and on Gijs’s file (DupEdge) and so far I can’t reproduce it.
Does this happen in one particular viewport or all?
I am running an on-house SR12 build and Steve has been working on curve display related problems. Some of these fixes are in the SR11 release candidate and some are in SR12.
Are you guys running SR10 or SR11?
Another thing to test is if turning off GPU tessellation in the OpenGL options page has any effect. Disabling it will slow down the V6 display but if it stops the problem, then it would be good for the developers to know that.
I’m testing this on a Windows 10 (1709) Surface Pro 4 running an Intel Iris 540.
I’m seeing all sorts of dis-pleasing artefacts :
-Curve ends that are supposed to meet but don’t
-Block instances that get highlighted when they shouldn’t
-Dimension arrows that grow to elephantine proportions
They might not be related, but they all add-up to bring a very unpleasant user experience.
I’m running SR11.
The only thing that “seems” better for now is that I have access to text/dot/user properties edit dialogs, but maybe it’s just a fluke.
I can’t explain why you’re seeing those problems and I’m not.
Can you please run SystemInfo and paste the results?
Did you try the GPU tessellation I asked you to try?
Did that make any difference for the curve ends?
I don’t have any ideas yet for the Block highlighting or big dim arrows.
I see this here as well - https://mcneel.myjetbrains.com/youtrack/issue/RH-49776
It was a fluke indeed.
Some time after a file is open, some dialogs just go blank.
15 years of using Rhino gives me the impression that silly bugs being are being sqwished and coming back after some time in an endless cycle, but there is very little in terms of real innovation or even catching up with modern CAD technology.
All I get when I stress this out is “Well why don’t you just get a refund and stop nagging already ?”.
Typical response by entitled folks from an employee-owned company sleeping on its laurels.
Un-acceptable from a consumer’s perspective. Specially one who has allowed you to sell so many licences during these 15 years.
Yes, well it is also the case that, like married couples, some customers and their software suppliers evolve in different directions over time. At a certain point one must decide if the relationship is worth preserving, despite how much has been invested in the past by both parties.
Also, like couples, one partner’s judgement of the capacities and progress of the other partner is not always objective.
In other words “Well why don’t you just get a refund and stop nagging already ?”
No, not at all. Simply that an evaluation must be made, and if it is decided that the relationship is worth preserving, that there will be efforts and concessions (read things that “just have to be lived with”) that need to be made on both sides. Or if they simply can’t be lived with, a separation is probably the best option.
Unlike a couple in a one-to-one relationship, the relation of a software company to its customers is one-to-many, which complicates matters. It’s not always possible to satisfy all partners.
Here at least it seems to happen in the perspective view I posted, at certain camera angles. It happens on the vertical lines as well when I rotate the camera around the object.
But it also happens in orthogonal views (less noticable because the lines jump only a pixel instead of angled like in the perspective
Just checked this on the mac 6.12.18331.12056 and 6.12.18338.15016 beta and here happens the same (Macbook Pro 15" with Radeon Pro 450)
Pascal was able to reproduce the problem and added a bug report.
Looks like after all there has been some innovation that makes Rhino useful and relevant for you.
Bugs will always be there as the software evolves and properly reporting and helping to identify them is your best best to have them fixed. At times it is frustrating but continued heavy criticism of the entire software and the company each time you report may be unnecessary.
Jarek, Grasshopper was developped in the beginning in secret by David ; he wasn’t even hired for this.
It’s a blessing for McNeel, because it’s the only thing that makes Rhino relevant today for me and -I suspect-for a lot of people too.
As for the bugs… Man ! How long have you been on this boat ? They just keep patching it up and it starts leaking elsewhere, and repatch the same old stuff over and over again.
Damn, this is so frustrating, and all the while, requests of old remain ignored.
Quite the opposite is true. It is about time users shook the coco tree, specially after 7 years of waiting for a lame Rhino 6.
It is because I want Rhino to survive that I say things as they are, hoping that McNeel will wake up.
True, but you have to give everyone there credit for recognizing its potential, supporting and developing it to this point and beyond… But I agree, GH must have been and still is a huge popularity and relevance booster.
I have mixed luck with some of the bugs and requests, but in general many of them, I have been finding and reporting, are being fixed over time. I know it is tedious and frustrating to spend time to document the bugs, provide the examples and step-by-step instructions, but in many cases I realty think the devs. can’t reproduce or understand the problem. So I found the time invested in communicating problems well spend for the problems and additional features to be done.
As long as we stay productive - I’m with you on this one!
See you on the next one.
Good point Mitch, but it’s even more complicated than than. Software are people too. I see my (one of the many) relationship to Rhino also a a one-to-many since there are so many people doing work at McNeel.
Then I also date other softwares too so there’s a bit of a messy many-to-many and so-many-more thing going on.