OpenSubDiv Testing and Discussion Thread
wancow
Posts: 2,708
Okay, I've been testing OpenSubDiv (OSD) edge creasing.
And I'm thrilled by it...
I have discovered one thing interesting. If you have your subdivision level set to 1 (4 quads per polygon), it appears that all edge creasing settings, 1-5, are identical. The top image below shows this. The subdivision is at level 1. The upper left vertex and the lower front edge are each creased, left to right, from 1-5. I see no difference in the resulting polygon position in any of those.
But with higher subdivision levels you will see differences, such as what show in the lower image in which the cubes are Subdivided to level 5 (4 to the power of 5 quads per polygon) with edge creasing, left to right, to levels 1,2,3,4,5 on the bottom edge and the upper left corner.
The tools for edge creasing are in the Tools Tab with Polygon Group Editor selected.
Daz 3D is part of 
Connect
DAZ Productions, Inc.
224 S 200 W, Suite #250
Salt Lake City, UT 84101
Licensing Agreement | Terms of Service | Privacy Policy | EULA
© 2024 Daz Productions Inc. All Rights Reserved.
Comments
Okay, here's another test. This one was to see what it looked like with the corners and the verts creased to levels 1-5. The bottom edge is so set. I like the subtlety of the creases... I just wish I could get the same subtly at lower subdiv settings, but that may not be possible...
Did you try rendering those? The division parameter, as far as I am aware, controls only the viewport preview.
I did not render those... but I will now... give me a little bit.
I simply did NOT think to render. Here's the results.
This is as SubDiv Level 1!!!! Same Vertexes ad the first set of renders are selected, but only four quads per poly. On the left, the top left poly is set to a weight of 1 as well as the bottom edge. On the right, both are set to 5.
WOW... WOW...
I wanted to get this up, I originally put it on my DA Blog, but it's relevant, so I'll repost it here:
For those of you who are unaware, and I'm sure there are more than a few, OpenSubDiv (OSD) http://graphics.pixar.com/opensubdiv/ is about to become the new subdivision standard (there really wasn't one before) in the 3D Industry.
It's being pushed by three giants: Pixar, AutoDesk and Microsoft. AutoDesk owns and produceds AutoCAD, 3DStudioMax (3dsmacks), SoftImage (XSI) and Maya. In other words, it owns a huge chunk of the high end 3D application industry, the other two need no introduction from me. So don't bother to argue with me: OpenSubDiv is about to become the standard, and any software that does not implement it will be rendered obsolete
Neil Blevins http://www.neilblevins.com/ is a professional 3D and 2D artist who has worked for Blur Studios as a jack of all trades artist and a Modeller/Animator for Pixar Studios. He is proficient in 3DSmacks, Maya, Mudbox, ZBrush and other 3D Aplications and Pixar chose to publish his blog on OpenSubDiv on the official OpenSubDiv website: http://graphics.pixar.com/opensubdiv/
The following blog is by Neil Blevins, who graciously allowed me to re-publish it.
________________________________________
Pixar's OpenSubdiv Initiative, And How It Can Help You
By Neil Blevins
Aug 26th 2012
Back in 1978, Ed Catmull (now president of Pixar animation studios) and Jim Clark (founder of SGI and Netscape) came up with the Catmull-Clark subdivision method. This was a method for subdividing polygonal geometry (and subdividing any associated Uv sets) into smooth surfaces. Later, in 1998, Tony DeRose (now Director of R&D at Pixar) created a method for defining crease values on edges and vertexes as a way to allow for hard edges on a smooth surface. The method has in many ways revolutionized our way of modeling over the last decade, replacing nurbs as the go to method for modeling in the film industry.
The problem was this. While the base subdivision method from 1978 was freely available, the creasing, texture evaluation, and some other aspects were patented and available for license. But instead of licensing the technology, every major 3d package decided instead to either avoid these features or create their own versions when implementing subdiv surfaces, versions that were incompatible with everyone else's subdivision method. This wasn't a huge deal at the beginning, since maya folk tended to stay in maya, and 3dsmax folk tended to stay in max. But in today's modern pipeline, there's a lot more asset swapping between packages, especially between sculpting packages such as mudbox and zbrush and the major 3d apps. All of a sudden, all of those incompatible subdivision methods weren't talking to each other, and moving an asset became an exercise in frustration (and artifacts).
(Image Examples on the Neil Blevin's Original Blog: http://graphics.pixar.com/opensubdiv/blevins_opensubdiv.html )
In the last few years, Pixar has worked with a number of major 3d packages to adopt the full catmull clark method, and programs like maya, mudbox and modo have become completely compliant, and hence, it's far easier to move assets between those 3 packages.
At this year's Siggraph, Pixar has announced the "OpenSubdiv" initiative. This will release to the public in open source fashion, a subdiv library that can be integrated into any 3d package. This is the actual code that Pixar uses, all of it, and the license terms include a free license to all the patents. So if adopted, this free subdivision method can be implemented by all of the major 3d packages, sculpting packages and renderers, and we'll finally be able to move our assets between any of these packages without worrying about subdiv incompatibility. In some cases, it will even let people use subdivs where they couldn't before, because their package's implementation wasn't up to snuff.
If you're a programmer, then the actual Open source may be of use to you here: https://github.com/PixarAnimationStudios/OpenSubdiv/
But if you're an artist, there's an important way for your to participate as well. The ability to seamlessly move subdivs between 3d apps will only happen if those applications implement OpenSubdiv. And that will only happen if the community demands it from their software. So I highly recommend to contact the people behind your favorite applications and ask them to incorporate this method in their software. And I mean everyone: 3dsmax, maya, xsi, houdini, zbrush, mudbox, vray, arnold, etc. Make sure that everyone knows that the public wants this, and having compatible subdivision surfaces will allow more people to use their software, and will allow their software to be used in facilities that could never use it before.
With your help, we can finally put these days of incompatibility behind us, stop worrying about fighting our software, and worry about making great art instead. A huge thanks to all those at Pixar who helped make this happen. Now it's your turn to take the next step.
(Copyright 2012 to Neil Blevins)
________________________________________
After having read this blog, I managed to contact Neil and quite giddily emailed him a gushing note about how those of us who use D|S are getting OpenSubDiv implemented and those of us using the DAZ Studio 4.5.2.40 Beta get to play with it.
Neil's idea is clear: we need this for a more transparent pipeline and a smoother work flow. Geometries should be predictable from the first polygon to the last, and OSD will give us this.
For my part, there is no doubt in my mind that OSD is about to become the goto standard in the 3D industry, it's just a matter of how long it will take. Thank goodnes MY favourite platform is well on its way to getting that done! Is yours? I'll just leave you with two words from Neil Blevins: "Demand It!"
Keep and eye on that same blog on Neil's Website as he has indicated that any news he has on this topic will be updated there: http://www.neilblevins.com/cg_education/opensubdiv_intro/opensubdiv_intro.htm
Hi wancow...
Great idea starting this thread... :-) and for getting permission to re-post that article...
I had read it back in Sept - Oct sometime, and it's good information for those here wondering what the to-do is on Open....
It's great news for those that have or work with all of the "high-end" or pricier software and even better news for those of us that use Daz Studio.... ;-)
The bad news though, is that for those of us that use Blender in our workflow, OSD will not be available as it currently stands... :-S The license used by OSD is not compatible with the GPL version of Blender... but there is a ray of hope, the heads at Pixar really want OSD in Blender and are trying to work out a way to make the licensing work. The BF is waiting to see what they come up with....
In the mean time though, Blenders SubD is very similar to OSD, mainly just the crease weights are not as good and it lacks some of the other OSD goodies... but it is workable...
If I have time latter tonight, I will run some tests on a few SubD meshes I have in Blender and see how well they translate in DS in their original low poly forms...
nicci... :)
blender to D|S tests will be UBER helpful!
I've heard the same about the licensing issue with GPL causing problems for including OpenSubDiv in LuxRender as well. So if they solve it for Blender, then hopefully the solution also works for LuxRender.
What about Ptex? I would have thought it was the same license, but there is Ptex for Blender. Or is that done by someone else and not 'official'?
Is there a definitive thread that discussed the GPL issue with the Microsoft license that Pixar used for OSD? Or at least a summary somewhere of what the issue is?
All I know about PTEX is what it does, and that it was developed by Disney. I don't know that Pixar was ever involved with it.
It appears that, unlike OpenSubDiv, it is not an open standard, but that Disney retains full rights to it: http://ptex.us/
I guess I assumed that Disney really meant Pixar, since they own Pixar. And Pixar would be their main 3D animation branch.
Hi...
There are several threads in the various Blender forums discussing the issues... sorry I don't have links ATM... and I don't confess to fully understanding all of the various license types and issues, but basically Blender uses GPL v2 and the provisions of that are not compatible with MPL... GPL v3 is compatible with MPL but it is not possible for Blender to change to v3
Ton even discussed it in some posts in some threads, and that he has talked to those in charge at Pixar about the issues, it's now up to Pixar to find the solution....
As for PTex in Blender... that was a side project by the developer of Cycles back in 2010... his initial builds only had it working in the 2.5 viewport using OGL and it completely replaced the vertex paint feature for his tests.... he never got it incorporated into the BI renderer and abandoned the project we he began Cycles development full time.... also I think the license problem came up too...
You could try a google search of the BlenderNation blogs or BlenderArtist forums for more info on the license issues with OSD as those two had the most relevant discussions on the specifics of the GPL and MPL...
nicci... :)
That may be true about Pixar being their main animation branch, but I don't think Tangled was a Pixar production, and that was the first major film to use it.
I don't understand the problem. All Pixar has to do is issue a special licence to Blender... haven't they thought of that yet?
Hi...
I don't understand the problem. All Pixar has to do is issue a special licence to Blender... haven't they thought of that yet?
When Pixar gave their presentation at Siggraph, the presenters went to the Blender booth shortly after and they were all eager to get things rolling... the license issue was one of the first things discussed and the folks from Pixar were pretty confident in being able to make some kind of exception for Blender...
move forward a few days.... Pixar informed the BF that they were having discussions on the matter... ( code for - the lawyers have problems with it )
The biggest problem is that Pixar is only part of the equation... Microsoft R&D played a big role in the developed of the OSD platform and the license is handled by Microsoft through MPL ( Microsoft Public License )
So bottom line is, no matter how much Pixar want's OSD to be available to Blender, if Microsoft say no then it's a no....
nicci... :)
OH! Microsoft... hmmm... I did not know that part...
Okay, I looked up the issue and I think I understand why it's a problem.
GPL or General Public Licence is basically for public domain software. Anything that has a GPL is. MSLP is not. It is designed to work with commercial software, thereby making them incompatible.
I cannot imagine AutoDesk, Pixar or Microsoft deciding to throw what they developed into the public domain. Blender is going to have to bend in order to get it... maybe via plugin or converter.
A single exception for Blender isn't very helpful, either. There is a lot of GPL software out there that would still be left out, like LuxRender.
Something tells me that a plugin could be made for anything OpenSubDiv so that LuxRender could read it. Blender isn't just a render engine, it's a suite, which would require it be able to edit OpenSubDiv. There's a huge difference there.
Hi...
That's not right... GNU GPL is not public domain, that would mean nobody owns it... GPL is for "free software", meaning free for the user to use and distribute as the wish, provided that they do so within the terms of the GPL... buy providing access to all of the source...
The MsPL does basically the same thing, but were the problem apparently comes in is that the FSF ( the publisher of GNU GPL ) believes that it is not strong enough to protect software that is under the GPL... and to correct what I posted before about GPL v3, I guess the FSF has now decided that that's not compatible with MsPL either...
But from all the articles I've read about the compatibility issues, it seems to me to be all about the FSF (Free Software Foundation) wanting to insure that GPL software is protected from lawsuits and court actions stemming from patent and copyright claims... to date they have been pretty successful to that end... and I guess the very brief wording in the MsPL leaves a legal door somewhat open for lawyers to exploit...
On the OpenSubDiv license page they do acknowledge the issues with the open source communities, and they do say, quote
I will also correct what I said before about Microsoft having a say in it, because also according to the license page, it was Disney legal that chose the MsPL...
Anyways, there still hope that one day OSD may find it's way into Blender and other open-source 3D software if the communities are large enough and really want it...
nicci... :)
So right now the only common interchange format that has extensions for supporting the vertex edge weights is FBX? Googling OpenSubDiv and plymesh didn't come up with any hits. Plymesh is easily extensible, but Pixar needs to define standard property names to use in plymesh so plymesh tools are consistent when reading/writing them. (My main interest is, of course, LuxRender, which uses plymesh for its primary external mesh file format.)
I wonder if the Studio SDK has been updated to allow plugins to access the vertex edge weights so they can properly export them to other renderers like LuxRender when/if they gain support for OpenSubDiv. Although in current released versions of Studio, when you retrieve the mesh for a SubD object, it gives you the fully calculated SubD mesh, not the base mesh. So exporting to LuxRender, for example, wouldn't actually need to know about OpenSubDiv as the mesh is pre-computed. It just means the mesh files are larger.
Hi...
A single exception for Blender isn't very helpful, either. There is a lot of GPL software out there that would still be left out, like Lux.
That's true if Lux were to support OSD directly... meaning that OSD object data is written in the scene file and Lux interprets the info during rendering...
The way around it is that the exporter, like Reality or Luxus, reads the OSD data and converts it to the regular Lux scene file...just as they do now when dealing with Genesis SubD... the downside to this method is that Lux doesn't benefit from OSD at all...
nicci... :)
I would ask the Reality and or Luxus developers about that...
Yes, as of now, it would be up to Pret-a-3D and Spheric to extend exportability of OSD meshes to Lux... and depending on levels of sub-division, the mesh files could be quite a bit bigger...
I do believe that FBX is currently the only fully integrated cross-platform format, but obviously DSON (.duf, .dsf) supports it... and the beta DSON importer for Poser supports it... so I don't see why other formats that are extensible couldn't also support it...
But then the license issue again comes up in regards to Lux... the Lux scene files could not contain any script code from OSD and remain compliant with GPL... this is the main reason Blender doesn't fully support FBX files...
nicci... :)
Actually I believe that when you convert the SubD mesh, it turns that sub-division into real mesh...meaning more polys...
The benefit of OSD incorporation into the software can be seen by your examples, very few levels of SubD are needed to create very smooth renders... because the renderer also supports OSD...
For Lux to have that same benefit it would have to directly support OSD, otherwise the baked mesh from the exporter has to turn all of the SubD mesh into real mesh...
nicci... :)
when you render, my understanding has always been that either the meshes get backed before or during render. Baking OpenSubDiv meshes would give you the same number of polygons that you would have if you didn't bake it at render time. The difference is that catmulclark would bake more polygons, and OpenSubDiv would bake fewer.
Hi...
Yes I do believe that's correct, but were the difference comes in is whether the renderer supports OpenSubDiv... 3Delight does, but Lux does not...
So for D|S you can use few sub-divisions using OSD and 3Delight will render it looking like a high poly model... but if you send the low poly or low SubD mesh to lux, it won't look as smooth because it lacks the sub-division that OSD provides...
I know that Lux supports sub-division, but in order to take advantage of the creasing some level of pre-baking of the SubD into real mesh will probably be needed... but that will be for the experts to figure out... ;-)
nicci... :)
edit: BTW - I'm really enjoying the topic... it's allowing my brain to work on something other than the normal of my day job.... ;-P
although I just remembered I said earlier that I was going to do some OSD tests on some of my Blender projects... %-P
I saw a presentation on Ptex and OpenSubDiv quite a while back, when OSD I think it was, was first being announced. Now it could be my memory is playing tricks on me or that I misinterpreted what was being said but I had gotten the impression that Ptex and OSD were separate but 'joined at the hip' so to speak as in two sides of a coin. That is, the two together would bring about this revolution in 3D compatibility. From what's been said here, I get the impression that the licensing is totally different between them and this joined at the hip concept would only be true under very restricted circumstances, as in when using specific software. Can anyone clarify this?
Gedd, the liscensing will be an impediment toward implementation of OSD, but will only affect the end user in that it may not be available to them in certain software. What I'm seeing with Blender, for instance, is that it'll probably get OSD through a plugin modeller. I can't imagine any other solution for them.
Great discussion. Very enlightening...
Just for the sake of clarity for those reading this thread I would like to make a correction (sorry, nicci).
The Blender Ptex development was by Nicholas Bishop, and put on the back burner in favor of his baby, Sculpt in Blender. He was working to implement dynamic sculpting to his sculpt module. He is the original author of the sculpt module which was originally a stand-alone open-source program named SharpConstruct.
I've never seen any evidence of him helping on coding of Cycles, nor believe he would have the time (with all his ongoing projects).
Hopefully, he will get back to coding Ptex at some time in the future now that he has finished Dynamic Sculpt (for the most part), and find a way to implement it alongside of Vertex Paint and not a substitute for it.
If not, or if no other coder takes up the challenge, it looks like we will have to purchase 3D-Coat to (Ptex) paint. Unless, by some miracle, DAZ is secretly working on Hexagon 3, and is implementing both Ptex and OpenSubDiv (we all can dream) to work in tandem with DAZ Studio.
Regarding licensing, I don't really follow the licensing all that closely, but I was wondering if the Blender issue has anything to do with the fact that "we the people" purchased the right for the software to become open-source from NaN. Since it was a fund raising venture of such magnitude, I wonder if licensing was locked due to some sort of non-profit entanglement.