Even roundtrips of meshes between more than two mesh apps are often unproblematic, even in old textbased exchange formats like obj. That is why I found smart to give best possible passive (=import) support for SubD-geometry a focus. That way Subd inside of Rhino could be very helpful already with just a super basic set of native editing tools.
Rhino currently can’t interpret various widely used concepts in exported SubD-geometry, such subobject groups (e.g. polygroups), multiple material assignments and multiple uv’s – essentially every sort of logical grouping inside fully welded meshes.
There are areas though which typically cause problems in exchange – one of them is weighting (creasing of edges). There’s no way to transfer this information from one app to another, unless one uses openSubD, which was discussed earlier on in this thread. Before using this standard even the various SubD apps Autodesk develops couldn’t exchange creasing information with each other.
Another area that causes problems is shading trickery, Some apps allow assigning groups of subobjects common smoothing angle properties (Smoothing Groups, Hard Edges). These may not be read properly by other programs, because this feature either doesn’t exist at all or is hooked up slightly differently. This feature is important is Low Poly modelling, as needed for Games – probably not what most Rhino users are planning to do next, at least in Rhino.
I would be happy to share files with you, however I can’t do it until Monday when I’m back in the office.
The big issue I see in translation is how other modelers handle edges. Typically in Sub d you are either adding edge weight, and this only translates if you freeze the mesh or if you add additional edge loops to sharpen an edge. To the best of my knowledge there are no crease options for sub d in modo, not sure about Maya or Max. I do know this, if it’s quads it translates very well.
Now Modo has an export plugin called sub d to nurbs and it works very well but it ceases to be a sub d model once it’s exported. They also have a plugin called cad loader which does a pretty good job of converting a nurbs surface into a quad mesh but it’s not perfect. As you know there is no clean way to turn a nurb model into. A mesh model.
I thought I should post some samples.
Most files are saved in .obj format, it supports the presented features.
This cube is as basic as it gets. Rhino loads it with no issues.noPolygroup.zip (501 Bytes)
That’s exactly the same cube, just with some subobject grouping applied – here it’s polygon-groups. When imported to Rhino the cube gets split up along group borders. With Join one may reassemble the box, but then groups are lost.polygroups.zip (521 Bytes)
The same, non uv-mapped cube this time with different diffuse materials assigned to some faces. Rhino retains color information but again rips the mesh appart. Upon joining the sub-meshes zones of separate material assignment are gone. differentMaterials.zip (930 Bytes)
The cube from with one UV map / channel assigned.
It imports fine as one piece and the UV-map is retained. singleUVmap.zip (1.1 KB)
This file uses two separate UV sets for side faces and top and bottom faces.
Obj as an old format officially seems to support just one UV set, but some programs can read >1 UV-channel existing inside obj’s. Additionally there’s fbx and .dae in the zip, which officially can. Rhino can’t deal with this concept, it splits the mesh along UV-borders, UV meshes are stacked. moreTan1UV-Set.zip (11.2 KB)
The next example (without image) uses an alternative approach: UV Tiles or UDIM. The idea here is to distribute UV’s onto more than just a single UV-grid. It comes into Rhino as several pieces and with UV’s stacked. The zip contains obj, dae and fbx. uvTiles.zip (11.1 KB)
Here is a second somewhat more complex example, it wasn’t created by me - the idea here is that the left half of the face occupies one UV grid, the right one uses a second grid. UDIM-head.zip (323.6 KB)
The mesh modelling apps I use can exchange files with these properties pre-existing in a file, so that one could create polygroups inside program A send the file to program B to unwrap based on these groups and finally apply materials and render in program C with all properties still intact.
Here’s a very simple crease test. It includes three different types of creases. Sharp (around the circular hole), semi-sharp (outer edge) and a gradient from sharp to uncreased at the equator. Of the programs I have and which offer edge weighting none uses open SubD. On import of that creased basemesh / cage into any other SubD- application that weighting information is lost, the geometry smoothes evenly when subdivided.
That’s no surprise:
The source app let my vary crease weights, other programs I have only know creased and uncreased but nothing in between. In case one doesn’t use openSubD (which among many other thing aims to establish a standardized behaviour here) I can not imagine how one could support reading weighting info from various sources - and even write it back to files appropriately… especially as most mesh formats used for file exchange can’t deal with creasing at all.
Today one may use the proprietary format .ma to retain creases when exchanging between Maya and Zbrush, but apart from this private negotiation between Autodesk and Pixologic the air gets pretty thin: fbx, alembic maybe, seemingly even an extension of obj (but this is only between programs which already use open subD.
Someone who uses Modo or Maya could open the uncreased basemesh I provide in the zip, apply similar open-subD creasing to it and upload it here as fbx or alembic to see if it is of any use for McNeel.
I actually think one could come pretty far with a quite simple alternative approach, without openSubD, without actually storing subdivision levels inside the file, just with the formats Rhino already supports. But before going into that it would be great to see that I’m not just talking to myself…
Here’s the files, the (unweighted) basemesh and the HiRes mesh at SubD level 4. crease-test.zip (168.2 KB)
This video illustrates perfectly the problem with the current workflows between Modo and a Nurbs program (Solidworks or Rhino):
…You have to covert your organic model to nurbs patches BEFORE adding any detail and you will be blindly making that commitment to a form. So you CANNOT make any form changes to that handle with those Solidworks details in place (round button in a recessed pocket), you can only edit the detail, not the handle. In Solidworks you can at least update your history three with a new basic handle to replace your originally imported one. In Rhino will you have any editability?
If the only problem you are trying to solve is complex surfacing and modeling those workflow works. But if you want to make these tools part of your design iteration, this rigid and perfectly linear workflow is a complete pain in the ass and it’s the same thing that every other CAD vendor is chasing. I’d love to see if McNeel can solve the design iteration problem, not just the modeling one.
I think your absolutely right Gustavo, and yes everyone is trying to bridge this gap. But so far, for me, Modo has made the best attempt yet to close the gap. Not perfect to be sure, but a lot better than what we have had in the past. Unfortunately there is such a difference in how you model hard edges, bosses and cut lines in Sub Ds compared to nurbs (you already know this better than the rest of us) that I have a feeling we are going to be seeing only a hybrid solution for some time.
I too would LOVE to see McNeel be the ones to solve this problem. What we really need a is a third option, what I mean by that is a third modeling option that sits somewhere in between nurbs and Sub D that can easily be transformed into either type. I know, its Unicorns and Rainbows and I am the LAST person to have any say in the technical side of this. But from my narrow understanding of all this it seems that the struggle has always been to convert one to the other but they talk two completely different languages.
As for what they are doing here so far, I think they are just playing with the idea and it wasnt really supposed to be a public discussion just yet. But, since the cats out of the bag so to speak we may as well see where this could go.
Hey @gustojunk, @FilmDesigner, could one of you in Modo quickly create some creases on the low res cage I shared at the bottom of my last post and post it in fbx or alembic, so that RMA can have a look?
Hi Dale, I’bee been thinking about this hard problem you made me aware of: quickly, robustly and accurately. …if this goes as most of the other technical challenges I usually phase I bet you could give us two out of the three? …if so, I think it would be great to have some VisualBooleans or PreBooleans that happen quickly and [somehow] robustly so we can get a sense of where things will intersect as we move/tweak the intersectors (any combination of organic SubD and primitives).
I know this could get very tricky when you have multiple operands (more than 2) colliding with each other, but maybe even having a 2-operand-only solution would go a loooog way to solve the broken workflow between SubD forms and Nurbs details that I mentioned earlier today in this topic.
Expectations: Even if the results are sooo bad that we can’t even output as clean STLs, still it would be a huge time saver seeing some preview in OpenGL, rather that realizing your form is too small, or your hole is too big and you need to start over, everytime. …I guess that’s the biggest drag of Rhino I see around here and why people don’t fully adopt it for design: [almost always] any changes means a remodel. This is the biggest disincentive to fine-tune a design.
So in the meantime, I’m blaming you guys at McNeel for all the badly designed products our there: you make it too hard to make design changes so we go “fuck it, good enough, it’s done!” (…mmh, maybe I should be thanking you for this instead of complaining?)
I imported the files into an app which can read both fbx and allembic + supports openSubdiv (Maxwell-Studio). In theory one now could simply re-subdivide and tell the program to read the creases and the shape you saw in Modo appears. Well, one can see that something controls the subdivision, but the shape isn’t quite there yet :o).
This is super exciting! I use a SubD workflow about 30% of the time and enjoy T-Splines. But having an integrated option into V6 or the following release will be fantastic!
