CGTalk > Main > General Discussion
Login register
Thread Closed share thread « Previous Thread | Next Thread »
 
Thread Tools Search this Thread Display Modes
Old 04-26-2013, 04:13 PM   #76
CHRiTTeR
On the run!
 
CHRiTTeR's Avatar
Chris
Graphic designer extraordinaire
Belgium
 
Join Date: Feb 2002
Posts: 4,381
Quote:
Originally Posted by mustique
Dynamic tesselation yes, but I guess they wouldn't want an open standart to be dependent on DX11, since it would be only usable with Windows. That would make no sense for all those linux based studios.


Yes, you're right. I guess i meant hardware tesselation... ill correct it, thanks for the pointer.
 
Old 04-26-2013, 10:19 PM   #77
Nemoid
This IS a cow
 
Nemoid's Avatar
Nemoid
Illustrator, Comic book artist, Storyteller
Italy
 
Join Date: Mar 2003
Posts: 2,470
Opensubdivs are fantastic this is a great technology advancement, and even more important is that they are open source so they can be adopted from many packages. This is great.
From what i read v 2.0 will be out for siggraph so they arent 100% ready yet,and this is basically why autodesk didn0t implement them yet in Maya.
Now what i'm more wondering is how this will affect sculpting especially in Zbrush, since the model of subdivision it now uses is not the same, i believe is more similar to common subdvision method, and this is why it does support quads only and produces millions of subdivided quads.
But i believe they'll find a solution, for example with a sort of converter to opensubd subdivided version once the mesh is sculpted to maybe project details.

What i also don't understand is if the pixar method of subdivision, while efficient on obtaining a smooth shape with way less polygons, would be useful as a subdivision model for sculpting purposes.
if its like that, then Mudbox could be able to get this subd method natively and transfer better details with maya or Max back and forth.
__________________
Nemoid | Illustrator | 3D artist
.::Creating for you::.
www.lwita.com
 
Old 04-27-2013, 09:20 AM   #78
mustique
Expert
copywriter
 
Join Date: Jul 2002
Posts: 2,016
I'm not quite sure what people expect from Zbrush and what is meant by "compatibility with opensubdiv" in Zbrush. (other than the lack of ptex)

AFAIK exported diplacement maps for pixar style subd's are fine if you take care of the UV smoothing (disable it) when you subdivide in ZB. You can locally subdivide your mesh in Zbrush if you need the flexibility of hierarchial subd too.

So do you mean that the whole subdivision algorithm in ZB should obey to open subdiv rules, just so we can sculpt on billion poly meshes? Well first we don't need that much polies and second, Zbrush isn't designed around an OpenGL view concept, which allows ZB to have the unique tools and power it has.

You want OSD style edge greasing in Zbrush? What for? Just create in zbrush and retopo in a modelling app that has it. Long story short. Other than the lack of ptex, HOW AND WHY DO YOU THINK ZBRUSH NEEDS TO CHANGE to make good use opensubdiv?
__________________
"Any intelligent fool can make things bigger, more complex & more violent..." Einstein
 
Old 04-27-2013, 12:10 PM   #79
ambient-whisper
Gone travelling :D
 
ambient-whisper's Avatar
CGSociety Member
portfolio
Martin Krol
Pixomondo
Canada
 
Join Date: Mar 2002
Posts: 4,631

if Zbrush could sculpt on billion poly meshes properly it would open a lot of doors for sure. More environment stuff would be done in it. But a large part of the poly limit today is mostly being limited by the fact that zbrush is not a 64 bit app. It used to be that zbrush would slow down and and you'd run out of ram around the time when the mesh was barely workable anymore. Lately however, its like driving a race car into a wall. I get very fast performance and then hit the inevitable ram limitation wall. sucks. I doubt that open subdiv would change much for pixologic though. ( dont read that as not being needed, just that its not a disaster in its current form ). Having them implemented the same way across all autodesk apps, houdini, cinema, modo would be quite nice though. It would mean that all of those apps would render geometry exactly the same. The way the uv borders are handled would be standard and therefore the geometry could be moved from app to app and you would get predictable results everywhere.

Crease support is quite different though. Thats the only questionable thing that might be hard to support industry wide.
 
Old 04-28-2013, 01:06 AM   #80
earlyworm
car unenthusiast
 
earlyworm's Avatar
Will Earl
craftsperson
Grizzly Country, Canada
 
Join Date: Mar 2005
Posts: 1,685
Quote:
Originally Posted by mustique
I'm not quite sure what people expect from Zbrush and what is meant by "compatibility with opensubdiv" in Zbrush. (other than the lack of ptex)


Consistency and flexibility through the pipeline would be nice.

No more displacement or texture artifacts on your rendered geometry is also cool.

Quote:
Originally Posted by mustique
AFAIK exported diplacement maps for pixar style subd's are fine if you take care of the UV smoothing (disable it) when you subdivide in ZB. You can locally subdivide your mesh in Zbrush if you need the flexibility of hierarchial subd too.


Zbrush's method of subdividing UVs (hard borders, smooth internals) does produce artifacts, especially around border edges which have additional edges cut in to create hard corners. I'd rather extract displacement in a program which supports a better method of subdividing UVs and not worry about artifacts at all.

Quote:
Originally Posted by mustique
So do you mean that the whole subdivision algorithm in ZB should obey to open subdiv rules, just so we can sculpt on billion poly meshes? Well first we don't need that much polies and second, Zbrush isn't designed around an OpenGL view concept, which allows ZB to have the unique tools and power it has.


The fancy GPU stuff is nice but more importantly, OpenSubDiv is more about the method of subdividing a mesh than anything else. It's perfectly possible for programs that just want to use the SubDiv algorithm to not use a single line of the GPU associated code.

You seem to be imagining this involving some huge fundamental rethink and/or rewrite of Zbrush. We're talking about the code which subdivides the geometry, not a complete rewrite of Zbrush to incorporate some GPU code which is designed for programs which can't easily handle the amount of polygonal geometry that Zbrush already can.

Also Pixar incorporated Zbrush/Mudbox UV smoothing a few years ago as an option. So Pixar is already able to smooth geometry exactly like Zbrush/Mudbox currently does.

Quote:
Originally Posted by mustique
You want OSD style edge greasing in Zbrush? What for? Just create in zbrush and retopo in a modelling app that has it. Long story short. Other than the lack of ptex, HOW AND WHY DO YOU THINK ZBRUSH NEEDS TO CHANGE to make good use opensubdiv?


For it to make sense for a pipeline to adopt the hierarchal or edge-creasing features in OpenSubDiv relies on consistent and broad support among modelling, texturing and rendering applications used within that pipeline. Introducing a retopology step into the type of models that use edge-creasing sounds like a waste of time, especially when it's for models which just need a small layer of sculpted detail added to them. It'd be better to stick with cutting in additional edges to create hard edges.
 
Old 04-28-2013, 09:01 AM   #81
beaker
Meep!
 
beaker's Avatar
CGSociety Member
portfolio
Deke Kincaid
VR Pipeline Supervisor
DD
Los Angeles, USA
 
Join Date: Apr 2002
Posts: 8,540
Send a message via ICQ to beaker Send a message via AIM to beaker Send a message via MSN to beaker Send a message via Yahoo to beaker
Quote:
Originally Posted by RockinAkin
I was disappointed to see the Autodesk 2014 software lineup didn't incorporate OpenSubdiv yet.
Version 1.0 release is way too late to include in a new release of a software coming out today. Most software companies need to not only implement it in their software but QA it and make sure it doesn't cause other bugs throughout the software. I'm sure we will start seeing it in commercial packages over the next year.

Look at other open technologies like ptex, alembic, open color io, field3d, partio, etc... Even at their fastest they took 6 months before they showed up in packages. Some took 2-3 years before they showed up (ptex), others still haven't seen full adoption. Actually even ptex/ocio/alembic still only have partial adoption.
__________________
-deke
 
Old 04-28-2013, 11:15 AM   #82
bcoka
Veteran
portfolio
-
United Kingdom
 
Join Date: May 2012
Posts: 38
Quote:
Good for Pixar. How do I get it?

That’s the nice part. You likely already have the technology available to you. For one OpenSubdiv is open source and all the licensing for the technology is available for free as well. Also, if you use Maya, you have access to all this already. Maya uses the exact same algorithm Pixar uses since Maya 5.0 and now also has the GPU implementation through Viewport 2.0.


This quote is taken verbatim from fxguide.com, in the article covering Day 2 at FMX 2013. As someone who's spent the better part of last winter trying to get the (at the time) awfully messy github nightlies to compile in hopes of maybe running the tech in Maya, I find it very strange that the above statement is true.

Can somebody confirm this? Maya 2014 highlights the Crease Set Editor as a new feature, while simultaneously discarding subdiv primitives from the menu, so I assume something is going on in this regard, however I'm not sure my GPU is doing any special acceleration when I switch to Viewport 2.0 and toggle the smooth preview. Certainly adaptive subdivision still isn't there, and almost certainly the distance between the camera and object has no effect on the subdivision.

Can somebody with more understanding of the matter shed some light as to whether or not OpenSubdiv is in fact part of Maya already? Is it safe to assume they'll incorporate more of it in a future 2014 Service Pack, at least for Maya?
 
Old 04-28-2013, 01:19 PM   #83
oglu
Christoph Schädl
 
oglu's Avatar
portfolio
Christoph Schädl
Austria
 
Join Date: Mar 2003
Posts: 3,243
Quote:
Originally Posted by ChocoBob
while simultaneously discarding subdiv primitives from the menu, ..


thats a different tech... subdivision surfaces in maya are not the pixar ones... its an old tech...
Quote:
Subdivision surfaces are a unique surface type available for modeling in Maya that possess characteristics of both polygon and NURBS surface types.


they are gone in maya 2014....
opensubdiv is working with polygons...
__________________
...
 
Old 04-28-2013, 08:34 PM   #84
RockinAkin
DivideByZero
 
RockinAkin's Avatar
portfolio
Akin Bilgic
Modeler / Generalist TD
USA
 
Join Date: Mar 2002
Posts: 2,644

Quote:
Originally Posted by ChocoBob
Can somebody confirm this? Maya 2014 highlights the Crease Set Editor as a new feature, while simultaneously discarding subdiv primitives from the menu, so I assume something is going on in this regard, however I'm not sure my GPU is doing any special acceleration when I switch to Viewport 2.0 and toggle the smooth preview. Certainly adaptive subdivision still isn't there, and almost certainly the distance between the camera and object has no effect on the subdivision.

It seems to me like adding the Crease Set Editor and removing the old style subdivision surfaces from Maya are the first steps of Autodesk preparing to implement OpenSubdiv... which is certainly good news. As far as I know, no other parts of OpenSubdiv are in maya yet.
__________________

AKIN BILGIC
Modeler / Generalist TD
CGGallery.com

Last edited by RockinAkin : 04-29-2013 at 03:05 AM.
 
Old 04-28-2013, 10:13 PM   #85
wancow
A Noid
portfolio
Christian Holm
Livermore, USA
 
Join Date: Nov 2009
Posts: 208
Quote:
Originally Posted by ChocoBob
Can somebody with more understanding of the matter shed some light as to whether or not OpenSubdiv is in fact part of Maya already? Is it safe to assume they'll incorporate more of it in a future 2014 Service Pack, at least for Maya?


According to Neil Blevins of Pixar, it is not yet part of Maya, but edge creasing is functionally the same as with OSD.
 
Old 04-29-2013, 12:43 AM   #86
earlyworm
car unenthusiast
 
earlyworm's Avatar
Will Earl
craftsperson
Grizzly Country, Canada
 
Join Date: Mar 2005
Posts: 1,685
Quote:
Originally Posted by ChocoBob
This quote is taken verbatim from fxguide.com, in the article covering Day 2 at FMX 2013. As someone who's spent the better part of last winter trying to get the (at the time) awfully messy github nightlies to compile in hopes of maybe running the tech in Maya, I find it very strange that the above statement is true.


Maya's SubDs have a very similar feature set. But neither it's native SubD primitive or Polygon in smooth mode are using the exact same mathematical operations, subdivision rules or options available as what Pixar have.
 
Old 04-29-2013, 10:26 PM   #87
cgbeige
Expert
 
cgbeige's Avatar
portfolio
Dave Girard
Opinions are mine. You can't have them.
San_Francisrococo, USA
 
Join Date: Jul 2005
Posts: 7,002
Quote:
Originally Posted by mustique
Dynamic tesselation yes, but I guess they wouldn't want an open standart to be dependent on DX11, since it would be only usable with Windows. That would make no sense for all those linux based studios.


Considering that Pixar and every other major studio is Linux-based, I doubt it will be limited to the DirectX viewport 2. That DirectX viewport is strictly designed with game developers in mind since companies developing for Windows/XBox 360-720/PS4 are all using DirectX and need previs tools. The DX11 support means they don't have to write their own viewport plug-in, which most have done in the past.
 
Old 04-29-2013, 11:18 PM   #88
shehbahn
Expert
 
shehbahn's Avatar
 
Join Date: May 2004
Posts: 375
Quote:
By the looks of it even pixar themselves dont hava a 'final' version yet.


And hopefully there never will be : we have been working on this technology for the past year or so, but we are adding a lot of functionality as we are constantly running into new problems and discovering new solutions. In the past month we have landed a major feature that we call "batching" : this is the idea that if you have a large number of meshes that you are going to draw for every frame, you want to "batch" the GPU processing to amortize driver calls (same principle as VBOs). I have also been busy adding the first elements of our "computational" API : the ability of evaluating random locations on the limit surface. OpenSubdiv is framework for us to share a cornerstone algorithm, it's not just a one-off code-dump of a finished product.


Quote:
It looks like it does some adaptive subdividing by using hardware tesselation, which is awesome (been waiting for years for this since gpu's offer harware tessellation).


Correct : we released the "feature adaptive" algorithm in December 2012 and it indeed does leverage hardware tessellation. Paired with camera-dependent LOD, this allows for sub-pixel geometry to be displayed on the screen and lets you apply displacement maps with the same kind of visual quality that you get out of PRman (youtube ). As mentioned in other posts: if we could replace the geometry-based brushes in Mudbox & ZBrush with a texture-based system, GPU streaming would allow virtually unlimited amounts of detail (or maybe Mari could implement sculpting...)

Quote:
Dynamic tesselation yes, but I guess they wouldn't want an open standart to be dependent on DX11, since it would be only usable with Windows. That would make no sense for all those linux based studios.


GPU tessellation is a feature that has been available since DX 11 as well as GL 4.x : all our code, including the barbarian demo, runs on Linux & Windows (not so much OSX though).


Quote:
Can somebody with more understanding of the matter shed some light as to whether or not OpenSubdiv is in fact part of Maya already?


Guessing this might have come from Bill Polson's FMX presentation, then he is probably referring to the fact that Pixar has been working closely with Autodesk to make sure that the existing code in Maya matches the results seen in PRman (PRman is the mathematical backbone of OpenSubdiv, via the Hbr layer code). In other words : it is not using the code in OpenSubdiv, but Maya's native code produces (mostly) the same results. The caveat here is that it is impossible to test an infinity of topological combinations, so this means that the most obvious stuff has been fixed, but someone might eventually trip over a particular case that we have not seen yet. For that past few years it's been "good enough" for the studio to model with, including very extensive use of semi-sharp creases.

In the long run, ideally we would want to replace the original single-thread CPU-based subdivision code in Maya completely, but OpenSubdiv is not ready for that yet (there many fascinating details such as non-manifold topology and localized updating that have yet to be figured out). Which is not to say that you won't see some OpenSubdiv-based workflows in the not too distant future either...

On the same note, features such as semi-sharp creases and boundary interpolation rules were added (or fixed) at Pixar's request, then rolled into the commercial code-trunk. The crease-set editor feature in the video linked above is another example of Pixar's collaboration with Autodesk' (although i cannot give any specific details as to when it will show up). This is not an entirely new pattern, but in this case we also had to deal with patents and the fact that the fully feature Catmull-Clark algorithm is a rather complex beast and that it was counterproductive for everyone to re-invent it.

Quote:
I wonder if it will end up being integrated in games...


Hopefully : we have had pointed conversations with several game engine developers. Here is another hint of what may come.
 
Old 04-30-2013, 03:36 PM   #89
RockinAkin
DivideByZero
 
RockinAkin's Avatar
portfolio
Akin Bilgic
Modeler / Generalist TD
USA
 
Join Date: Mar 2002
Posts: 2,644

Quote:
Originally Posted by shehbahn
Correct : we released the "feature adaptive" algorithm in December 2012 and it indeed does leverage hardware tessellation. Paired with camera-dependent LOD, this allows for sub-pixel geometry to be displayed on the screen and lets you apply displacement maps with the same kind of visual quality that you get out of PRman (youtube ). As mentioned in other posts: if we could replace the geometry-based brushes in Mudbox & ZBrush with a texture-based system, GPU streaming would allow virtually unlimited amounts of detail (or maybe Mari could implement sculpting...)

Thanks for the first-hand information! The prospect of realtime displacement-based sculpting in Mari is a VERY interesting prospect I really hope to see one day!
__________________

AKIN BILGIC
Modeler / Generalist TD
CGGallery.com
 
Old 04-30-2013, 03:36 PM   #90
CGTalk Moderation
Lord of the posts
CGTalk Forum Leader
 
Join Date: Sep 2003
Posts: 1,066,480
Thread automatically closed

This thread has been automatically closed as it remained inactive for 12 months. If you wish to continue the discussion, please create a new thread in the appropriate forum.
__________________
CGTalk Policy/Legalities
Note that as CGTalk Members, you agree to the terms and conditions of using this website.
 
Thread Closed share thread


Thread Tools Search this Thread
Search this Thread:

Advanced Search
Display Modes

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

vB code is On
Smilies are On
[IMG] code is On
HTML code is Off
CGSociety
Society of Digital Artists
www.cgsociety.org

Powered by vBulletin
Copyright ©2000 - 2006,
Jelsoft Enterprises Ltd.
Minimize Ads
Forum Jump
Miscellaneous

All times are GMT. The time now is 12:12 AM.


Powered by vBulletin
Copyright ©2000 - 2016, Jelsoft Enterprises Ltd.