When connected Mesh Container to a subd, it returned the base mesh, now it returns subdivided mesh of that subd. Seems like there is no way to get the base mesh.
I need to rewrite many of my definitions, if this is an error please correct it.
I am using the latest RC of R8(Windows).
Rhino 8:
Rhino 7:
Seems like the subD - mesh conversion in Rhino 8 is a 4 level subdivision.
subd_mesh_conversion_problem.gh (10.0 KB)
The âSubD Control Polygonâ component has the correct mesh output.
Never knew this, thanks!
Is this a mistake or will this be the new normal?
SubDFromMesh Density 0 subdivides once. It would be nice if it didnât subdivide, similar to how weaverbird does it:
System Info
Rhino 8 SR12 2024-8-24 (Rhino 8, 8.12.24237.22001, Git hash:master @ 11f7607be80095edf34125493562a8e350ec3f22)
License type: Commercial, build 2024-08-24
License details: Cloud Zoo
Windows 11 (10.0.22631 SR0.0) or greater (Physical RAM: 128GB)
.NET 7.0.20
Computer platform: DESKTOP
Standard graphics configuration.
Primary display and OpenGL: NVIDIA RTX A5000 (NVidia) Memory: 22GB, Driver date: 7-23-2024 (M-D-Y). OpenGL Ver: 4.6.0 NVIDIA 560.76
> 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: 7-23-2024 (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: 7-23-2024
Driver Version: 32.0.15.6076
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\packages\8.0\NVIDIADenoiser\0.4.3\NVIDIADenoiser.Windows.rhp âNVIDIADenoiser.Windowsâ 0.4.3.0
Rhino plugins that ship with Rhino
C:\Program Files\Rhino 8\Plug-ins\Commands.rhp âCommandsâ 8.12.24237.22001
C:\Program Files\Rhino 8\Plug-ins\rdk.rhp âRenderer Development Kitâ
C:\Program Files\Rhino 8\Plug-ins\RhinoRenderCycles.rhp âRhino Renderâ 8.12.24237.22001
C:\Program Files\Rhino 8\Plug-ins\rdk_etoui.rhp âRDK_EtoUIâ 8.12.24237.22001
C:\Program Files\Rhino 8\Plug-ins\NamedSnapshots.rhp âSnapshotsâ
C:\Program Files\Rhino 8\Plug-ins\MeshCommands.rhp âMeshCommandsâ 8.12.24237.22001
C:\Program Files\Rhino 8\Plug-ins\IronPython\RhinoDLR_Python.rhp âIronPythonâ 8.12.24237.22001
C:\Program Files\Rhino 8\Plug-ins\RhinoCycles.rhp âRhinoCyclesâ 8.12.24237.22001
C:\Program Files\Rhino 8\Plug-ins\Grasshopper\GrasshopperPlugin.rhp âGrasshopperâ 8.12.24237.22001
C:\Program Files\Rhino 8\Plug-ins\Toolbars\Toolbars.rhp âToolbarsâ 8.12.24237.22001
C:\Program Files\Rhino 8\Plug-ins\3dxrhino.rhp â3Dconnexion 3D Mouseâ
C:\Program Files\Rhino 8\Plug-ins\Displacement.rhp âDisplacementâ
C:\Program Files\Rhino 8\Plug-ins\SectionTools.rhp âSectionToolsâ
subd_mesh_conversion_problem.gh (24.5 KB)
Hi -
It looks to me that the output of the MeshSubD component in Rhino 7 is the same as in Rhino 8, no?
Weâre afraid that changing the behavior of that component at this point might cause problems for all existing Grasshopper definitions that use this. As you say, the SubDPoly component returns the undivided control net of the SubD.
-wim
Ok for the mesh conversion but how about subdivision level 0. That shouldnât subdivide anything.
Hi Martin!
What youâre after is the SubD control net which you can get from the control polygon as youâve mentioned. The ToMesh is always going to be based off of the Smooth SubD and not the control polygon. This is where it gets confusing since Level 0 âsmoothâ is definitely different than Level 0 control polygon.
I just donât agree that level 0 and level 1 does the same.
I know, its confusing when you compare it directly to catmull clark subdivision levels.
That Mesh from SubD component is doing exactly what the Mesh dialog does in terms of Level 0. Itâs always based on the smoothed mesh and the control net is referenced separately.
However, I am seeing what you are saying about 0 and 1 producing the same results⌠that definitely shouldnât be the case. Let me dig into that more and see whats going on. It could be that 0 just returns level 1. Perhaps we can sneak the control net in there when that happens.
Weâre going to update the SubD to Mesh component to allow the 0 index to return the SubD control polygon.
Many of my definitions have meshing logic like this:
Subd objects->Mesh Container->Weaverbirdâs CatmullâClark subdivision(at least level 2).
If Mesh Container returns many times subdivided mesh, the definition will be unexpectedly heavy, even difficult to open.
I didnât even test this, but this is not a solution.
Same here.
Can we have an official statement about this? @Trav
Have you really changed things so now all old definitions using this will break?
Type A to Type B cast (mesh to subd) and back Type B to Type A (subd to mesh), should not mean such a huge difference.
I added the quote to my post it should be clear now what I was referring to
I posted about this issue separately, so Iâm joining this thread. Can we get a response from @Trav or @wim why was this changed between 8.9 and 8.11?
Not sure if you saw it alreadyâŚ
In the third topic about this problem @Trav posted this:
I see the Mesh component now returns the same number of faces again.
Whatâs the state of the 0 and 1 density request? I canât see anything in the youtrack link:
Hi Martin -
Perhaps you need to turn on the comments?
=>
Also, from the component:
-wim
Weird now I see all the commentsâŚ
I see the conversion now works as expected in Rhino 9 WIP
Will this also be available in Rhino 8?