Im testing the new subd command and stuck in brigde 2 Subd-Objects with different edge count.
How could i merge these two objects without holes? Or how could i get same edgecount for the two objects?
subd.3dm (595.0 KB)
You are facing a general limitation of Subd modeling here (applies in any app). There’s no way to cleanly sew together patches with different resolution. Some programs don’t even offer bridging under these conditions. Those that do need Triangles/Ngons which cause very bumpy transitions and other errors.
In this case one should rebuild the topology to make their border-vertex count match: Either by adding or deleting edge-loops on the parts in question.
Thanks. Could you guide me direction how to rebuild the topology to make their vertex count match?
Im struggle on the way how to merge vertex to get a equal count
Both parts are scan-data and the subd was created using the Quadmesh command. Is there a way to force the quadmesh to be equal-counted? The topology doesnt need to be exact to the data. Im more interessted in a fast but not exact way to transform scandata into a editable object.
I have to admit, that I don’t know the RH7 SubD tools well yet…
But a quick test to to delete an Edge Loop lead to a gap in the SubD cage (instead of the expected manual decimation ). Maybe @wim or someone else from staff could check if there’s already a YT-item for this?
Right now the most efficient way to deal with your geometry would be building a cage manually – outside of Rhino (can be done in free Blender or in a great variety of other mesh editors). You can simply build the faces of the base cage across the gap in your scans or (if that is in order) only build one shell and mirror it over.
When finished with the cage you can import it to Rhino and convert to SubD.
Here’s another approach that’s possible now in the latest v7 WIP…
5 Likes
Thanks for demonstrating these tools, Brian! That said – with the topology being that arbitrary and uneven in density one can really only change the boundary from one flavour of irregular to another.
While very old and geared towards mesh based SubD editing I still like the CG-Guerilla-Clips for their explanation of SubD-basics. The same fundamental rules do also apply for Limit Surface based SubD, as in Rhino. A similar guide with some basic topology rules would sure help a lot of Rhino-users, new to SubD!
Here’s the CG-Guerilla-Clip about problems with irregular base-meshes:
1 Like
Thanks for the link! I agree some of that info will relate to working with subd in Rhino 7. FYI @theoutside @Trav I like the drum interludes 
I watched the subd basics vid too which has some useful tips.
My hope is that the QuadRemesh feature can help simplify a lot of the topology knowledge needed for traditional box modeling. Lack of LOD and the ability to make subd from curves using regular Rhino commands as well as converting untrimmed NURBS srfs to subd will make for some different workflows for sure. It’s a good idea to think about topology rules for these as well. Thanks again!
I am sceptical in this respect, Brian. Poles (extraordinary points) in bulged surfaces always cause smoothness issues – they may occur in all quads geometry already, but Triangles and Ngons do the same job. Obviously one may deal with lack of precision in concept models, but I think one will not be able to use the full potential of limit-surface based SubD with irregular cage-geometry.
If one lofts or sweeps adjacent SubD faces with non matching border-vertex positions one will pay with total loss of editing options across the boundaries. The attached image shows two lofted SubD-faces. Due to their density / border-vertex mismatch one can’t do anyting about the transition area – while one can massage the transition into any shape with matching layouts. Modeling that way to me meant not at all using what is great about SubD.
Using non-Catmull-Clark layouts for SubD also had consequences for file-exchange: One could not losslessly push files over to mesh-modellers, which use Subdivision Levels (possibly in order to use a tool that’s not yet available in Rhino). Such meshes would look terrible when subdivided elsewhere, especially as creasing won’t travel along with the file.
Also with non Catmull Clark-Layouts one would lose a lot of the elegance when unwrapping SubD geometry: That is when the 2D representation is the flattened mesh-cage ➜ and not an auxiliar Rhino-Render-Mesh. With Low Res + symmetrical meshes one may UV very efficiently and every change in the model is automatically reflected in the cage (as opposed to Surface Models where every model-update means having to redo the UV’s).
Clean, symmetrical faces…
…result in nice and managable UV’s, which reflect every model change
Image Source
1 Like
Very much looking forward to this, Brian! Should be quite advantages.
As for trimmed surfaces: the ‘untrimmed’ requirement has always been a unfortunate hindrance. Any potential breakthrough to permit operations on trimmed surfaces (sub-d and/or other prohibited operations - e.g. merge surf) would represent a significant advancement to modeling workflows.
Worthy of investment if ever deemed potentially doable, IMO.
I totally agree @hifred clean quad mesh geometry will make clean subd geometry in Rhino as in mesh based modelers. We’ll try to make sure all the editing tools needed to clean up meshes or existing subd are available and you’re right, this will be a new area in which to educate users. The QuadRemesh tool is something that may help some users in some cases create cleaner geometry but indeed it is not going to solve all possible issues. Knowledge is still important.
1 Like
You can give the ToSubd command a try now on single srfs or use the subd output option on commands like Loft or Revolve for instance now in the v7 WIP. For trimmed srfs, try QuadRemesh on it to make an all quad mesh version of it and convert to subd in one step. This may help if you are trying to convert a polysrf with trimmed srfs to subd.
Hi Brian,
my posts contained some feature requests – could you please add them to the list?
- Use SubD-Cage instead of a classic Rhino render mesh (obviously at higher SubD-Levels) for viewport display (➜ of SubD-objects)
- Use the same mesh for unwrapping (user may choose the viewport displayed SubD-Level on the flattened mesh but edits the vertices of the unsubdivided cage).
Doing UVs that way would have great advantages over UVs on surface models: Any topology-changes would immediately get reflected in the UVs – one therefore could start working on materials and mapping while still developing the model (whereas one with Nurbs models has to start UVing from scratch, upon model changes / surface replacement.
Yeah, these tools are super impressive – but they are rarely able to create cages for manual modeling. Output is too Hi Res and often topology-wise not ideal for further manipulation. Run on a patch within an existing model, a remesher would need a lot of context information – what’s the structure of the adjacent mesh? Zremesher at least (the quad-remesher in Zbrush) is mainly used to improve the quality of texture baking from High Resolution models, not in order to create cages for SubD-Editing.
Good low-res cages for manual modeling imo should rather get created by hand, possibly on top of an existing, ruleless mesh. I find retopology tools which let you create a Low Res network a lot more effective for this particular task.
Thinking of SubD in Rhino and using any combination of imported and converted meshes and surface tools with output=subD and subD-converted Nurbs-patches I see a very tough challenge to make this all play well together. The fundamental idea of SubD – I find – is dropping the so familiar concept of patch based modeling: One rather needs to create a single piece of flesh with a consistent internal structure.
A model which – if it had a Nurbs-equivalent – was made from just one surface.
Here we have one of the classical limitations of SubD: mismatched loop count.
Abraham Maslow once said: “I suppose it is tempting, if the only tool you have is a hammer, to treat everything as if it were a nail.”
…every SubD modeling program out there has had this problem because all they have is a SubD topology: their hammer.
I think this highlights the need to have a blended input/output between various topology types available in Rhino.
I think what makes sense here is that BlendSrf works with history and SubD edge loops as input. So you can make a perfect blend, when you intent is anything except downstream to other CCD apps like Maya/Max/VR pipelines (where you need SubD only, but like Holger pointed out there’s problem here already since Rhino is not using Catmul Clark)
I think one may generalize this sample to what will always happen if two or more SubD patches are created, without information on ‘how to fit things together’.
I think RMA should first encourage box-modeling and poly by poly modeling. These strategies both make it harder to create stuff that doesn’t match – and they teach topology-fundamentals on the fly.
That’s a very small market. More like a waste of time. Especially if you are focusing on people modeling things for design/prototype/build.
There’s also a ton of mature products that do this right now, and every time they tried to enter the design market they hit a brick wall.
I was referring to novices trying to get their feet wet with SubD modelling. Here I think one should stick to proven workflows and can’t find this a waste of time.
I consider this rather a consequence of rigid topology constraints in SubD modelling and not of the chosen approach to build and shape a mesh cage.
1 Like
I was too.
I think they are interrelated.
One of the strongest value propositions of Creo and NX’s SubD integration is the fact that you can match and managing continuity between Nurbs and SubD edges. Then you can you make each part based on the topology it needs (or it has, ifs it’s a part you don’t own or control) and properly bridge between them.
G
ESSENTIAL!
Creo
Fusion
http://help.autodesk.com/view/fusion360/ENU/?guid=GUID-73BF7A68-D707-4687-9E07-285BA7E0387F
I think I understand what you are after, Gustavo and I’m not against it. I just don’t see any of this coming to Rhino in near future. Right now Rhino can not even maintain upright continuity-conditions between a set of surfaces while manipulating them. The highly expensive tools you mention had these capabilities on Nurbs geometry for many years – long before one finally made them available inside a hybrid Nurbs-SubD workspace.
But hey – even if I was wrong and such solvers would come tomorrow – I think it made sense to first teach some SubD-basics, to those who are about to get their feet wet with a new modeling paradigm.
Thanks for the feedback on texture mapping. I also hope unwrapping subd will work that way. I have filed https://mcneel.myjetbrains.com/youtrack/issue/RH-50789 regarding the inability to unwrap subd currently. I added your comments there.
If possible, please make a separate topic on the forum here showing a specific issue you’re running into and I’ll make sure the bug or request is filed. Thanks!