Antialiasing on the rendered image looks bad and somehow the surface edges don’t have the surface color. They seem to be rendered in white color despite having a setting ‘color by object’…
PS: Not sure what’s different but I copied some of the content to a new file and hit render again. The color problem has vanished. Antialiasing is still bad on the rendered output (left) vs viewport (right).
Windows 11 (10.0.22631 SR0.0) or greater (Physical RAM: 1.3e+02Gb)
.NET 7.0.14
Computer platform: DESKTOP
Standard graphics configuration.
Primary display and OpenGL: NVIDIA RTX A5000 (NVidia) Memory: 22GB, Driver date: 12-1-2023 (M-D-Y). OpenGL Ver: 4.6.0 NVIDIA 537.99
> Accelerated graphics device with 4 adapter port(s)
- Secondary monitor attached to adapter port 0
- Windows Main Display attached to adapter port 1
Secondary graphics devices.
NVIDIA Quadro K2200 (NVidia) Memory: 4GB, Driver date: 12-1-2023 (M-D-Y).
> Accelerated graphics device with 4 adapter port(s)
- There are no monitors attached to this device!
OpenGL Settings
Safe mode: Off
Use accelerated hardware modes: On
Redraw scene when viewports are exposed: On
Graphics level being used: OpenGL 4.6 (primary GPU’s maximum)
Anti-alias mode: 8x
Mip Map Filtering: Linear
Anisotropic Filtering Mode: High
Vendor Name: NVIDIA Corporation
Render version: 4.6
Shading Language: 4.60 NVIDIA
Driver Date: 12-1-2023
Driver Version: 31.0.15.3799
Maximum Texture size: 32768 x 32768
Z-Buffer depth: 24 bits
Maximum Viewport size: 32768 x 32768
Total Video Memory: 23028 MB
Rhino plugins that do not ship with Rhino
C:\Users\martinsiegrist\AppData\Roaming\McNeel\Rhinoceros\8.0\Plug-ins\KeyShot9RhinoPlugin (ecfe8d1f-876a-460f-aa5e-3dd816936811)\1.4.0.0\KeyShot9RhinoPlugin\Rhino 7\KeyShot9RhinoPlugin.rhp “KeyShot9RhinoPlugin” 1.4.0.0
C:\Users\martinsiegrist\AppData\Roaming\McNeel\Rhinoceros\packages\8.0\NVIDIADenoiser\0.4.3\NVIDIADenoiser.Windows.rhp “NVIDIADenoiser.Windows” 0.4.3.0
C:\Users\martinsiegrist\AppData\Roaming\McNeel\Rhinoceros\packages\8.0\IntelDenoiser\0.6.7\IntelDenoiser.Windows.rhp “IntelDenoiser.Windows” 1.0.0.0
C:\Users\martinsiegrist\AppData\Roaming\McNeel\Rhinoceros\packages\7.0\EleFront\4.2.2\ElefrontProperties.rhp “ElefrontProperties” 1.0.0.0
I believe the edges, curves etc in the wireframe channel are territory of @jeff . Rhino Render (Cycles) doesn’t do such line rendering, that comes from the display code.
You have to understand what’s really going on here…
The AA in the display is all done on the entire frame buffer result via “multisampling” frame buffer objects in the underlying graphics engine (i.e. OpenGL, Metal)… In other words, all wires, all surfaces, all anything/everything get sampled together for the final result… That’s not what happens for raytracing results (and can’t) because the raytraced results are being done by a completely different type of rendering engine.
So what Rhino does is it provides the portions/parts that a raytracer can’t render via a transparency mask, which then gets applied to the final result via post process…which is why you can turn them on/off without having to re-render the entire scene again.
Given that, my guess is that the post process is not doing a very good job with the mask data when blending it with the final render results, (or the mask data is bad, but I’m pretty sure I provide all AA results as proper alpha values).
I would have to dig into what the post process is doing with these masks to see, but this is probably better suited for @DavidEranen as a first responder…
Something you might want to try is ViewCaptureToFile on a Raytraced viewport… In that case, the wires will be “fused” with Cycles’ output results in much the same way they are in other display modes…and the results should look better than the post process mechanism.
That sounds like a temporary workaround. My current task is to render hundreds of stills for a video animation. I want to render at a certain image size (1920 x 1080) or higher if really necessary.
Named views are all set and ready for a batch render.
I guess I’d need to activate one Named View after another in a floating viewport and then ViewCaptureToFile…
This isn’t possible without a lot of work and added features. I would recommend creating “real” geometry from the edges and then re-rendering. DupEdge will get you the edges as real curves, and then apply Curve Piping to them with appropriate thickness, and then render.
After you pipe the curves, use ExtractRenderMesh and join all the meshes into one disjoint mesh with Join. Delete the curves or disable the render mesh piping on them as well. You’ll then have one mesh object for all the piped edges and the display will fly as will the transfer of the data to memory when rendering.
