Pen / Technical / Artistic modes display random lines over model aftew few minutes work and Rhino.app needs to be restarted.
Initial view (restarted app):
and display glitches after few minutes of work
Hi Jan -
In a quick test here (5 minutes or so), I’m not running into this one. Can you post or upload a model that shows this behavior on your machine?
-wim
https://dsc.cloud/6758bd/display-glitches-test-file.3dm
and video:
https://dsc.cloud/6758bd/mlk-2023-09-06-at-9.30.15.mov
these look related Wip technical view print bug
still present in Version 8.0.23251.10306, 2023-09-08
no changes in Version 8 BETA (8.0.23271.13234, 2023-09-28)
@wim still not fixed in the latest beta (Version 8 BETA (8.0.23278.13004, 2023-10-05). See video:
Pen, Artistic etc. modes are completely unusable after few minutes of work.
1 Like
Hi Jan -
It looks like this issue is limited to Macs running on Apple Silicon, which is why I’m not seeing this here. We have reproduced it on a developer’s machine and this issue is filed as RH-77570 - Random wires with Technical Display
-wim
We think we have this fixed now. The fix will be in the next Rhino 8 beta which should be available tomorrow. Thanks
Thank you for your amazing work! @wim @stevebaer @dan
Now some lines are not hidden by polysurfaces in technical / Pen / Artistic display modes. See attached video:
Please post a sample 3dm file if possible. Thanks
@mlkplk
This is not related to Rhino Beta, your lines have a DrawOrder Value, please run the command ClearDrawOrder to fix the issue.
I don’t think DrawOrder commands should be working like this, including display inconsistency between Shaded and Technical/Pen etc. modes.
DrawOrder features are described in man page here:
Yes, and that’s the point. It seems that something happened with your CAD imports that is causing this issue. Once I cleared the draworder, your file was working fine.
I noticed that these lines show up whenever there is SSAO shadows (Arctic, Artistic, Pen)
Running this script will show you that some of your linework has a large margin of values in the draworder, for example the 3D object you have has a value for the display order is to be 0, while the linework is close to -200 (means it is way behind it) . This is probably causing the technical glitch for both V7 and V8.
import Rhino
import scriptcontext
def main():
# Prompt the user to select an object
go = Rhino.Input.Custom.GetObject()
go.SetCommandPrompt("Select an object")
go.Get()
if go.CommandResult() != Rhino.Commands.Result.Success:
return go.CommandResult()
obj_ref = go.Object(0)
obj = obj_ref.Object()
if not obj:
print("No object selected. Exiting.")
return
# Get the display order value of the object
display_order = obj.Attributes.DisplayOrder
# Report the display order value
print("The display order value of the selected object is: {}".format(display_order))
# Call the main function
main()
Okay I was able to reproduce the issue on a very simple scene file to find the root cause of the issue.
1- This Behavior is caused bu a combination of 2 factors:
a) The Linework has a Value for the Rhino.DocObjects.ObjectAttributes.DisplayOrder that is not 0
b) Use Advanced GPU Lighting or / And SSAO
2- This Behavior Applies to Rhino 7 as well as the PC version.
To Reproduce the issue:
1- Create a simple box with a line behind it.
2- Set the Display Order for the line to be -1 using the script below:
SetDisplayMode.py
import Rhino
import scriptcontext
def main():
# Prompt the user to select multiple objects
go = Rhino.Input.Custom.GetObject()
go.SetCommandPrompt("Select objects")
go.GetMultiple(1, 0)
if go.CommandResult() != Rhino.Commands.Result.Success:
return go.CommandResult()
for i in range(go.ObjectCount):
obj_ref = go.Object(i)
obj = obj_ref.Object()
if not obj:
print("No object selected. Exiting.")
return
# Set the display order value of the object to -10
obj.Attributes.DisplayOrder = -1
obj.CommitChanges()
# Redraw the view to see the changes
scriptcontext.doc.Views.Redraw()
# Call the main function
main()
3- The Results will be like the below:
is it the expected behavior? Obviously no, but it is tricky to track.
also,
can happen for shaded mode once you enable shadows
1 Like
Thanks, @tay.othman!
Confirmed on M1 MacBook Pro in v7 and the latest v8 BETA.
- Create new file
- Create solid
- Draw line and use BringToFront command on it.
this is the intended behavior, what is not intended is if you send the line to the back and still showing up in the front.
I think Draworder is intended for objects (hatches, curves, points, annotation) in the same plane (eg 2D orthogonal views).
“Real” 3D geometry / position must always have higher priority than drawordered hatch somewhere in the background.
eg. we are using hatch fill to mask some “old” geometry in 2D etc. and draw new one over the background coloured hatch fill. It’s quite misleading have distant hatches in the front of 3D view ignoring basic perspective visibility
This feature is crucial for mixed 2D/3D layouts.
2 Likes