Thanks @stevebaer , it’s worth mentioning I was running grasshopper definitions while this first occurred/I noticed it.
That being said, I’ve not been able to directly reproduce the issue in a new file from Grasshopper so I don’t know if it’s related or coincidental at this time but I’ll continue to watch and report.
Is there a way to “manually refresh” or reset the viewport capture?
EDIT:
In this video you can see that I reproduce the behavior when printing Technical Display Mode to Vector Rhino PDF, Raster PDF (Despite the other lineweight issues) does not show the lines coming through the building.
Even if I set the curves to “SendToBack” they still are printed/drawn in the foreground when printing Technical Display Mode.
You can see in the video that Shaded Display Mode occludes the curves as intended and Technical Raster also does, but Technical Vector has all curves showing through regardless of moving their draw order.
If you ask me, those are two completely different issues.
But, yes, I’ve been meaning to file this one for the past few months now, so, thanks!
→ RH-79091 Print: Technical mode with HLR does not clip curves
As for that first one in this thread, I can see the same in your file but I can’t reproduce that from scratch. Also, as you say, when you simply create a new detail, this doesn’t happen anymore. Additionally, this isn’t even limited to technical viewports, I see the same in your file when I set those details to Shaded and Rendered (with edges shown):
Simply unlocking those details, making them active, zooming to extents and then zooming back into the area you want, clears this up (done with that upper detail in the following picture).
It’d be interesting if you could find a way to create a detail in this state. Was Grasshopper involved in creating the details? As this issue landed in a “Printing Bug”, how is printing involved?
-wim
I believe you are right yes, half of the issue in the beginning of this post is related to the curves showing through though. All the curves coming through the house were generated in Grasshopper and baked to the Rhino model but in testing, such as the box test file, it appears to be related to curve objects themselves and nothing directly to do with Grasshopper (as far as I can tell)
Perhaps this is something to do with Grasshopper baking the curves dynamically and the viewport not refreshing properly upon each bake. I need to do a box test with the grasshopper script to see if I can reproduce for you all.
Okay, great, thank you, that will be my workaround for now!
I do have python scripts used to generate the details, layout sheets, and title blocks but those were not in use here.
These viewports were created manually and then the Rhino model was adjusted (by moving points, lines, etc. that influence the GH script) and then the result of the GH script gets baked to the Rhino doc.
The object types getting baked include Lines,Curves,Text Entities, Dimensions, Leaders, Polysurfaces/Breps, Surfaces, Blocks, Hatches, etc. (almost every geometry object type actually)
Also regarding the YouTrack I think it is worth noting that Leader objects are not properly occluded either. I haven’t tested with dimensions or other annotation objects but Curves and Leaders both do not occlude in the Technical Display mode when Vector output is set.
Thanks for following up on this @wim, I forgot how important Technical display mode was for my workflow until I had issues with it
I’m trying to understand what you are saying, seeing, doing, but clearly failing? I’ll take this one step at a time, and you tell me where I go wrong, please.
I open “20231129_R8_Raster_Printing_Bug.3dm”.
This opens with layout “A3.2” visible in the viewport.
The issue with “things looking like wireframe” is only visible in two details on layout “A3.1”, so I make that layout active.
I activate the top detail.
I select the roof and the walls (i.e. 2 objects) and run Invert.
The command line says that 132 curves and 1 surface are selected.
From having looked that that model before, I know that the surface is the little one at the top of the roof on the right. It looks like all curves are on a plane that is perpendicular to the current view.
I run Hide, and, just for good measures, run SelAll.
Do you agree that there are no curve objects visible in those two details?
As far as I can tell, it’s “simply” the camera of the two details on that layout that is messed up, and I would like to understand how they get into that state. As long as we don’t know how they got messed up, there’s nothing to solve here.
Is this the only file in which you see this (very specific) issue? There are two such details on a single layout. Is one a copy of the other?
-wim
I think I’m having the same problem with Rhino 8 for Mac.
When I draw something with 2D lines on the back, and I use “Pen” shading style, I’m OK in the wiewports and in layout (the back 2D lines remain non visible.
In the PDF produced using the PDF printer provided by Rhino, i can see the 2D lines through the 3d geometry
As a last thing, i checked the “shade objects” box on the PEN settings, and now I cannot uncheck it
I had the same problem at a certain point on Rhino 5, which is the version I’m coming from, and many of the files showing the issue, were made on Rhino 5.
Nonetheless, I can’t afford to copying and pasting into a new file, because it would be an enormous amount of work
In attachments some screenshot of the problem
I can’t share the file for copyright reason, in case of necessity, I can make one for the specific purpose.
Chiming in here – having read through the thread, I thought I might be able to offer an example that at least clearly shows part of the problem, namely hidden lines “showing through” in technical view. I’ve also noticed that in some cases, exterior (non-hidden) lines are being incorrectly rendered as “hidden”:
No grasshopper, no python here. The fridge is a mesh, everything else is nurbs. Display mode is Technical with the lineweights and colors modified slightly (hidden lines in grey).
Here’s a closeup to show what’s happening – the hidden lines are being rendered “above” the rest, and the corner edge of the cabinet should be black, but isn’t:
Yes, that’s correct @samface . I agree, I need vector .pdfs for my outputs. I had to manually hide all the lines coming through my model for the last deadline I had. That was… painful haha.
Hi, are there any updates on this issue?
Please set it to “high priority bug”, so that we can finally use Rhino for serious professional work.
Thanks!
There are a couple issues tracked here, with RH-80895 & RH-78688 still open and marked In-Progress. Is this in regard to one of the open or closed issues. Thanks
