[Bf-committers] GSoC Proposal: NURBS

[Jonathan deWerd]

On Mar 17, 2014, at 7:36 AM, Ton Roosendaal <ton at blender.org> wrote:

> Hi Jonathan,
> 
> I have seen people work on this topic in the past 10 years, yet nobody could deliver something more usable than what I did in the 90ies... what is still in Blender now. And what I consider not usable either.
Ah, so you did write the original NURBS code! Yes it is really too bad what happened to the 2 previous efforts to improve it. I haven’t been able to contact Emmanuel or Laurynas. Any insight onto what prevented them from merging? Did they just never get their code to a stable state that would be a net feature addition?

> For me then the logical question is this: why even bother about Nurbana? That code is also from the 90ies, it is unsupported for 15 years, and I rather only accept a GSoC project from someone when he/she can become a reliable maintainer for it.
The only reason to use nurbana is to take advantage of estone’s efforts. He got within throwing distance to 1 of 2 “big picture goals” my proposal mentioned (namely, .3dm import/export). He posted links to working binaries supporting curve trimming (the holdup for openNURBS, which gives .3dm import/export), so I know he wasn’t exaggerating about the progress. However, given that they’re MIA and you understand the inner workings of the current NURBS implementation, I tend to agree it might be wiser to ditch the old nurbs branch and start from trunk. There could be nasty structural bugs in the nurbs branch.

As for becoming maintainer, I do have the mathematical background to debug issues, understand the literature, and plan+code an eventual transition to T-Splines (or whatever we decide on). It’s the responsibility that I’m worried about. I would need to put out fires and do the occasional migration, on top of gradual long-term work (which I could adapt to my schedule and would not be a problem). It doesn’t sound too bad but I don’t have a good feel for how demanding the “putting out fires” part would be. Then again, I have to take on responsibility some time, and this is not a bad way to do it.

It’s easier to say “yes” to maintainer responsibility if I code from trunk rather than rebasing nurbana, since in that case I’ll be familiar with all the code.


> Alternative: check on what we need to do for our Curve/Surface object and tools and make a plan of action what to code?
Sure, I can adapt the proposal relatively easily to include specific features from the nurbs branch rather than grouping them under “rebasing nurbana". Most of the “small features” I proposed were actually based on the current build, so this will largely involve deleting references to nurbana :)

> Or: ditch this whole NURBS thing, it's ancient, it very hard to make usable and far too technical for artists. Everyone's using hybrid methods (using subsurf approach) now. I know Adesk bought the T-spline, but something similar would be great to look into.
Yes, it looks like artists have moved to Catmull limit surfaces (if they ever heavily used NURBS at all). CC surfaces are superior to NURBS (but not T-Spline) in terms of topological refinement. I’ve seen the opensubdiv demo, very impressive!  But CAD people still need NURBS compatibility. I know B-Splines are a subset of Catmull surfaces, but are rational B-splines a subset of Catmull surfaces with weights / sharpness factors / something? In any case, I’m pretty sure nonuniform rational B-splines aren’t a subset. We’d have to implement something like this to be compatible with NURBS: http://dl.acm.org/citation.cfm?id=1138455

That’s doable, but it may be easier and better to implement an unpatented T-spline data structure (I think I found one, but I haven’t digested the patent and the new paper enough to be sure) or perhaps another “NURBS+” surface, like the “extremum point NURBS” that interfaces well with poly meshes (haven’t read about it yet, terminology or details might be off). If you’re willing to let me have a “literature week” in the GSoC I can make a big matrix with all the options. I can’t have the matrix ready by Friday when proposals are due, however, and I still consider NURBS interoperability a constraint, since that’s the angle my personal motivation comes from.

Next-gen Surface + NURBS import/export + itch-scratches (“small features”) + key tools (chamfer/fillet, maybe even booleans)

is quite possibly too much for a GSoC.


> NURBS is also something you can bedtter hide 'under the hood' and then make great tools for artists to help them modeling. If you look at Rhino or Maya you can see how they handle it. Which is: tools, tools, and tools. Not technology.
Agreed 100%. This is my weak spot: I’m a math&code guy, I have yet to learn which NURBS tools are the most useful for artists (I use them to prove things about “next-gen” finite element methods, I haven’t used them to build anything). Know anyone I could ask for advice on prioritizing tools? Rhino has a nonexpiring demo I can play with (export expires, but I don’t care about that) and I get a free copy of Maya as a student, so I can learn, but I do not yet have enough experience to do more than guess at a plan. My guess is what you saw in the proposal:

Simple features:
  Enable edge selection in NURBS edit mode
  Enable Ctrl-R = Loop Cut&Slide in NURBS mode
  Loft / Sweep generators
  Make “Part” command try to preserve edges
  Fix the display so that the surface occludes the control mesh for “Solid” viewport shading
  Fix the labeling and documentation of “weight” property
  Fix the display of “weight” property to halt proliferation of bold x-ray magenta lines everywhere
Algorithmic features:
  Good Snap Functionality (e.g. cursor/selection to nearest point on curve)
  Fillet/Chamfer
  Intersection Curves
Stretch features:
  Booleans




> Or, just adding B-spline surfaces (like LW, etc) would make Blender surfaces so much more usable…
I haven’t used LW’s B-Splines and their demo is time-limited. Do they just have really good tooling? My understanding was that B-splines are a strict subset of Catmull-Clark limit surfaces.

Do they have good NURBS booleans? Because that would be a killer feature, hopefully one that is documented by an expired patent :)


> I miss this kind of insight or analysis in the proposal. Are you really familiar with the technology? With subsurf, t-spline, nurbs, and all these parametric curve families?
There was no analysis in the proposal, I was arguing purely from popular demand. Nevertheless, I’m mathematically familiar with tensor product Bezier, Rational Bezier, and Nonuniform Rational Bezier (NURBS) surfaces. I am not mathematically familiar with Catmull-Clark limit surfaces or T-Splines, except in a broad shallow sense (e.g. CC somehow defines B-splines to approximate a mesh and T-splines alter the recursion topology of NURBS). I have only skimmed the T-Spline and Catmull-Clark literature. I shouldn’t have a problem becoming familiar with them before the GSoC. It also shouldn’t take too long to survey other modern NURBS derivatives. There appear to be a handful but not an overwhelming number.

I hesitated to propose next-gen surfaces because NURBS interoperability is a requirement of mine and the time requirement for NURBS interop is a function of the next-gen surface we choose. It’s a 2-week task for TSplines (curve cutting is the rate limiting step) but might be 1-month for enhanced Catmull surfaces.  Roughly

1-week: literature review / decision matrix / decide on next-gen surface type
1-month: implementation of data structures, tessellation, blender import/export, testing
2-week: NURBS import/export (I require this feature)
remaining time: a time-permitting subset of the feature list above

Is this reasonable?