switching to open Subd?

Hi All,
there has been a new video on openSubD here.

To me it seems that it could have a lot of advantages to port Nvil to that system, especially as one has to move all content created in Nvil to some other program for postprocessing the mesh (UV's, Texturing, Animation, Rendering).

Every larger content-creation-program which has numerous workspaces aside from pure modelling certainly would probably have much more problems with adapting to this new system - as everything relies on the specific Catmull-Clark dialect used in that very program. For Nvil such a port of course would also mean an awful lot of initial work, but one would end up with very compatible geometry and a modern code-base with excellent performance also on highly complex geometry. Ideally such a robust Geometry Library might even free up Istonia's limited resources so that he could mostly concentrate on fine-tuning workflow.

Thoughts on this?

Here's a discussion in the Blender-Forum on that topic - they have issues with the particular open-source-license which was chosen, a problem Istonia certainly would not have.

anybody home? 

just seems like a lot of work, even know it would be nice, and as far as somehting to help moveing content around, i rather see some new exchange formate options like FBX and alembic first.

though this prolly would help performance, with things like adaptive tessellation that is has, and how it can automataclly subdivide by creases, so you dont need to go as high in hte subd levels to get good looks edges with creases as opposed to crease+support loops or just support loops

Hi Passerby,
in my layman's understanding support for fbx and alembic would - by far - not open up the same possibilities.

In my perception Nvil is in a quite exceptional position. It has an author who has used the last two years to gather a crazy knowledge in terms of Subdivision-Tool-implementation. He started off with little knowledge of actual user-needs and a totally differnt application in mind. Over just a short period of time the application got quite deep but deliberatly stayed small in overall scope.
However, I see quite a few aspects which get fundamentally in the way of Nvil's overall approach. The program uses too many sub-item-types internally. Deep customizing still needs very nerdy mentality. Lately a crazy lot of time gets used to make an old and questionable GUI-framework a tiny bit posher. Only looking at visual concepts some recent online-modellers come up with one can feel that this time might be poorly invested. One can see that the journey goes in quite another direction. One should watch out not to get tempted to pick low hanging fruits... I do mean well by saying so.

I think it was coolest to restart with the wealth of knowledge gained and with the most modern concepts in terms of geometry-handling, workflow, customization, gui and platform-support.
And to make this happen for as long as Nvil is relatively light, has relatively few, dedicated  users and is not yet commercial. Most other firms should have a lot more problems to make such a radical cut. I would purchase a license of Nvil in its current state to make such happen.

In terms of interchangeability of subdiv meshes between software packages, NVil might benefit from such underlying architecture. Here's some essay about just that from the Open Subdiv site.
http://graphics.pixar.com/opensubdiv/blevins_opensubdiv.html
Since NVil arguably won't be the last stop for most of the meshes being created with it, it would even be important, that what I see in NVil is what I get in other software packages, especially for semi-sharp creases.

However, I found this quote on the official website as well:

This codepath is optimized for drawing deforming subdivs with static topology at interactive framerates.

source: http://graphics.pixar.com/opensubdiv/overview.html

So it's optimized for static topology. Changing topology is everything NVil is about, though. But I still wonder, if the degree of optimization from OpenSubdiv would still pay off inside a modelling environment.

Currently, if I take a mesh into another program, I lose my creases. If I want to render the end result I would have to collapse the subdivisions and thus bloat the file sizes or risk a out of memory crash. Therefore, OpenSubdiv would be great. It would benefit to the interchangebility.

does openSubdiv provide a exchange format? since even with maya that has edge creaseing, or modo there is no possible way to maintain that edge creasing when exporting to dae, or obj they only 2 exchange formats that nvil supports. It only works on mayas own .ma and .mb formats and .fbx


also a thing newer versions of Maya have that is really cool is the crease set editor, it lets me predefine creasing values, or grab them from a already creased selection, and lists them and lets me apply them to future selections. The cool part is that it stores them as references, so if i changed say crease set 1, everything in the scene that i applied that too will change.

I simply assumed there was a file format somewhere in the libraries, but you're right, I can't find anything about that. But I did some further digging and found arguments against OpenSubDiv in editing software:

The problem with an editing app is that the step that "flattens" your HBR topology into tables takes too much time for interactivity. Traditionally, modelling apps like Maya or Modo work around this simply by refining a data structure (winged or augmented half-edges) and displaying an approximation on-screen (2 levels worth of subdivision). On the flip-side, our in-house software focuses on animation, not modelling, which is also part of why we have been focusing on play-back rather than editing.
Having said that, for OpenSubdiv to gain the ability to edit topology interactively requires us to solve 2 major problems :
- non-manifold geometry : half-edge data structures cannot represent non-manifold topology. I have been working on identifying solutions to this problem for the past 2 weeks.
- localized topological analysis : figuring out a way of locally updating our FAR tables. This i a very delicate problem...

Q: Is there a way to apply edits to a FAR mesh directly?

A: unfortunately not at the moment : the logic applied to generate these tables is fairly "non-trivial" : as mentionned above, it is one of our future integration goals.

Ideally you want to stick to HBR for as long as possible and only transit through FAR / OSD once your topology is stable.

You can read the whole thing here
So it's either low-performance, but unrestricted, or high-performance, but topo-locked.

These are not the droids you are looking for...

supporting a format that can exchange this data like fbx, and using a algorithm like pixar subdiv, should do that job, maya, and modo both use pixar's algorithm, and can exchange things with it all intact via fbx.

3ds max dosnt have creasing out of the box, but there is a 3rd party modifier that works just like mayas subd, and also saves to fbx for exchange.

I would love to see this. The creasing (especially with the newer improvements that modo/maya/mudbox don't yet have), the speed, the guaranteed results between different software...

In the Maya 2015 release OpenSubDiv is the standard smoothing algorithm, also for modelling. Their tools also work on the smoothed surfaces it seems. Catmull-Clark is there only for legacy reasons. So now OpenSubDiv should be sufficient for editing meshes, I guess. Could bring a needed speed boost to NVil.

IStonia, would you consider switching to OpenSubdiv for a better compliance with major market players? The sources have already been linked here (http://graphics.pixar.com/opensubdiv/docs/intro.html). As for creases, you could introduce an option of exporting them via text files. They can be easily parsed with Python in target programs (Maya, Houdini, etc.).
OpenSubdiv + MatCaps + NURBS curves could be a good feature set for Nvil 2.0.

Open sub'd version 3.0 has just been released.
http://graphics.pixar.com/opensubdiv/docs/intro_30.html

Would be cool to have open sub'd in Nvil. It seems a lot of 3d apps are heading that way so compatibility between them would be easier.