New quad-remesher retains input Nurbs surface layout

Zbrush has had an excellent quad remesher for years, but with their newest release they have once again improved it considerably. With previous versions of their mesher one could already create good SubD-Cages from Nurbs input. Now their ZRemesher even respects existing groups of polygons (polygroups) found in the input mesh. As Zbrush can identify UVs in Nurbs-derived meshes, one can therefore force the Mesher to create a SubD control mesh which inherits the surface-layout of the Nurbs model.

This addition could turn out immediately useful for those who want the cleanest possible meshes from Nurbs geometry for rendering and at the same time want to use existing UV’s for material assignment.


The most interesting aspect, I think is something else: Retaining Nurbs surface-borders in control cages, as demonstrated by Pixologic might serve as a foundation for a repeated conversion back and forth between Nurbs and SubD.

Right now conversion from Catmull Clark mesh to Nurbs is a one-way street, as automatic, unguided surface creation from SubD leads to very heavy, no more human-editable polysurfaces. Output which makes surfacing specialists shudder and question the whole point (also of Limit-Surface based) SubD: ‘Why at all bother, if one needs to remodel the whole thing anyway (before I can modify it) ?’

Typical Auto-Surfacing result (Autodesk Fusion here). Output isn’t suitable for further (meaningful) Surfacing operations. But even assuming that would only want to punch a precise round hole into this auto-surfaced body – one at that point cleary could no more reconvert this ugly thing back to SubD.

If one could convert polysurfaces to Catmull-Clark meshes which retain the surface logic of the Nurbs model one could turn every Nurbs model to clay. Even without adding or removing faces one could freely reshape the geometry (in a Cage-Edit on steroids fashion) and convert the result back to Nurbs. It was even ok if the converter failed creating high quality surfaces / surface matching in very challenging areas – but one would at least end up with human editable geometry, that may get further refined.

Users however, who convert a polysurface to a surface layout retaining cage and go further by adding and removing geometry could help the Nurbs converter, by assigning polygon groups to modified model sections – Zbrush even creates these automatically (but one may freely change the assignment later).

Face addition to the control cage, marked by polygon-groups.
These groups might aid a Nurbs converter create human editable Nurbs also from altered portions in the SubD-model.

Thoughts anyone?

6 Likes

I admittedly posted this one over the weekend, but I thought that the keywords quad mesh + subD and some colourful pictures were sufficient to attract some attention ;o)

I’d be glad, if developers had a look before this one vanishes down the Discourse feed – @dale @dalelear @piac @DavidEranen come to my mind.

Thanks, Holger

Hi Holger,

thanks for posting this. I think creating these clean meshes is more important than ever. Especially if they can be generated with automated/explicit inputs, as compared to the manual approaches of ‘painting direction’ like 3DCoat and Silo and all the other hippie software has.

Repeatable, explicit approaches matter for one reason: Grasshopper. We could then create computational solutions that get rebuilt with good mesh flow to further do more computational things.

Besides the usual suspects you mentioned I’d like to hear what @DanielPiker and @brian think of prioritizing something like this. I think the current quad-mesh open-sauce plugins they are offering are a nice gesture, but nowhere near useful for us.

Hi @hifred ,

You’re right - what they’re doing in ZBrush is amazing. It’d be lovely to have something like that in Rhino - though we don’t actually have a technical idea how ZRemesher is implemented, and the difference seems to be why it’s so much better than everyone else’s. What we know is that ZRemesher is faster and better than everything else - we just don’t know how it manages to be that way. We’ve tried following several other papers on the subject, and as @gustojunk says we’ve got something that’s:

Thanks for your comment, Brian. I think where Pixologic (makers of Zbrush) is particularly good at is hiding complexity, establishing robust defaults and yup – incredible speed optimization. The whole program seems to be coded in quite unusual ways. One aspect of this is, that Zbrush doesn’t utilize the graphics card at – it runs entirely from the CPU. That’s why they can be quite bold in their hardware recommendations


That being said – there’s other programs with similar remeshers which reach very good results as well, such as 3DCoat. The process runs slower and requires more skillful users for good results, but it’s clearly usable. 3DCoat’s implementation is at least in parts based on the papers used in McNeels Create Quad Mesh Plugin.

What I can see here is certainly not missing skill. But papers which describe general principles and programmers with little time for an experimental side-project, who lack the knowledge what a useful software-implementation could even look like. Pixologic obviously sits in a very different niche and they know that remeshing problem quite a bit better.

Obviously I wasn’t asking for a similar Mesher built into Rhino 7. I rather wanted to invite you to think about possible new roles of the mesher, inside a program which will at some point convert SubD geometry to Nurbs.

It would at least not take me long to find equally harsh statements as Gustavo’s by automotive surfacing specialists posting in this forum who don’t see any value in SubD as its Nurbs-converted output is bad beyond repair.

oh God… I should really hire an editor to soften up my written posts.

I think in the meantime we need to make T-shirts of this…

and I’ll be sending some more “I’m sorry cookies” to Brian.

G

2 Likes

How about making a Rhno GoZ plugin to do round trips to Zbrush for remeshing? Is this still a supported thing?

http://docs.pixologic.com/user-guide/zbrush-other-programs/goz/about-goz/

IMHO, with over 30 years in automotive design and development, there is absolutely no need for an apology. The basics are to tell it like it is with no personal defamation or downright insults and I think that’s exactly what you did. The recipient needs a thick skin and appreciation for the criticism. It all goes toward a reliable, customer-pleasing and safe ( in the case of automotive) product. If the product kills people it’s not good. In the case of software it’s probably the developer that gets killed, at least if he/she goes to user meetings. :wink:

The main objective for a company, after staying in business, should be to do a surprising and delightful job of meeting customer expectations, not the other way around. That can only be done if the customers make their expectations clear. Otherwise most companies will put their efforts into pleasing themselves via their own imagined ideas of customer expectations.

@gustojunk You are one of the few McNeel customers who has sufficient experience in this area and the ability to clearly express your hard-won opinions to guide McNeel, so I say Thank You.

1 Like

Haven’t you heard of employee poaching? All it takes is $$$. :laughing:

A|W, all,

Just for those that don’t know, I was being a bit sarcastic. I consider the McNeel team a great bunch, and no matter how much I complain, I never forget that using their software and support is a huge part of the success of our business. This gives us the ability to employ increasing more people and get to have fun doing what we do.

I’ve developed really strong friendships with many of them, so yeah it might sounds that we are a bit harsh and silly with each other but It’s all just having a bit of fun. Same in this case the comment for Brian: a man of many talents and a sucker for sweets.

G

Thank for bringing this up.
I would also love it if a Rhino GoZ plugin were to be considered.
In free organic Jewellery design the combination of ZBrush and Rhino is the best joint solution I found.

And then, [in the wish list for the wished-for Rhino GoZ,] if it is possible, can we have the option of bring Rhino curves into Zbrush.

Akash

1 Like

GoZ is still a thing, yes. But I could not see a good business point for Pixologic to support Rhino with this quick Export Import plugin.

That being said: It’s very easy to create a script which writes a a mesh to some transfer folder. Zbrush can automatically pick these up, any change in the input mesh appears in Zbrush right away. The other way round it’s easy too, Zbrush oversaves the temp-file and you get a popup in Rhino that there’s updated data waiting. Even I have written and shared a crude version of this in the past, but Pixologic
regularly breaks things as they rename system folders with every update. Also there may be scaling issues, with geometry not centered at the origin, but this sure is solvable by a real programmer.

Somebody also published a univeral Quick Exporter, which supports all sorts of mesh programs for hassle free mesh transfer – but I couldn’t find it right away. Maybe someone else remembers its name?

As a general note: Bringing the mesh I showed my first post into Rhino would not work with all its features. Rhino can not deal with polygon groups and therfore splits the mesh into submeshes along the patch borders. It may get joined back to a single mesh though.


Polygroups are split at borders, when imported to Rhino

A any rate, it is already today nicely doable to bring Rhino geometry into Zbrush and also back, even without GoZ or other Clipboard Exporters.


My central point for this thread was was another. Using the SubD cage and its polygon groups as a permanent link between the SubD and Surface version of a model: For repeated conversion. For such, I’m afraid one needed a native quad mesher, that is as good as the one in Zbrush and yet a bit more…

I totally get your point Holger, I side-jacked your topic to see if at least a GoZ alternative might be appealing for some. And yeah GoZ it’s a thing that needs to be updated. Other softwares like Modo, Cinema4D, Maya update it regularly.

Poly groups is something that should be supported by Rhino. Most exchange formats like .FBX .OBJ support them. Just like Ngons. I’m not sure people are McNeel even know much about poly groups. Maybe it’s not hard to implement?

I can not believe that letting Polygroups survive Import to Rhino was a mayor thing. One surely also could read other interesting stuff, such as sets of coordinates for each vertex in the model (shape keys).

SubD would open up the chance to have countless valid shape-variations stored inside a model and
one could even seamlessly blend between them (so far for my side jacking).
2019-03-12_14h06_24
Source

The problem is, that one needed commands + GUI to access and control this data. And access for 3rd party developers and documentation … I’ve bugged @tim a few times in the past though :o)

I don’t know Holger, I think Shape Keys In polygons are as confusing and useless as weighting CVs in Nurbs. This is as UI nonsense as when Maya thought editing subDs at multilevel of subdivision was exciting and useful. I heard someone at McNeel in this century saying the same thing about multi-level editing: I almost had a stroke. I was too speechless to even tell him it was a horrible idea.

Sometimes we have to be the voice of regular users and make sure that the esoteric stays where it is: the darkest wishes of geek modelers.

I know, I know… there’s 137 people in the world that fine this stuff extremely useful. But we digress…

G

PS: (Please no, I don’t what to hear from any of you why you find CV weighting extremely useful)

1 Like

I get this, but I think we’d sure like to hear from anyone else with a bunch of experience in Sub-D and Nurbs modeling that can set down their opinions in a reasonably clear way.

PS: I, too, have a lot of respect and admiration for what the folks at McNeel have accomplished and think they’re pretty world-class.

You’re talking about shifting vertices, upon subdivision in mesh-approximated SubD I guess?

This shouldn’t happen altogether with Limit Surface based SubD, as implemented by McNeel. There’s just two states: Control cage and the smooth version. Cage-vertices stay where they were.

Hi Holger
just one thing regarding this point you have made. I totally agree with you here, but perhaps someone in Mcneel may want to do a rhino GoZ. as mentioned in the the snapshot below, Pixologic offer their free SDK for that purpose.

with thanks
Akash

1 Like