Home General Discussion

Autodesk, Pixar and Open Subdivs

Bellsey
polycounter lvl 8
Offline / Send Message
Bellsey polycounter lvl 8
Tomorrow, Tuesday 16th, we're hosting a webinar with special guests, Bill Polson, Dirk Van Gelder, Manuel Kraemer, Takahito Tejima, David G. Yu and Dale Ruffolo, from Pixar Animation Studios’ GPU team, to show how Autodesk and Pixar are working together to build technology with stunning real-time results and how real time display of subdivision surfaces helps artists be more productive, and how this code is open source and engineered for ease of integration.

OpenSubdiv is a set of open source libraries that implement high-performance subdivision surface (subdiv) evaluation on massively parallel CPU and GPU architectures. The code embodies decades of research and experience by Pixar.

The webinar page has different links depending on what general time zone you're in, so be sure to choose the right one. Webinar will be in English only.

Here's a link to the webinar: Join Pixar Animation Studios, to learn about the OpenSubdiv Project

The webinar page has different links depending on what general time zone you're in, so be sure to choose the right one.

Webinar will be in English only.

Replies

  • oglu
    Options
    Offline / Send Message
    oglu polycount lvl 666
    there is a youtube version now...
    [ame="http://www.youtube.com/watch?v=xFZazwvYc5o"]Meet the Experts: Pixar Animation Studios, The OpenSubdiv Project - YouTube[/ame]
  • artquest
    Options
    Offline / Send Message
    artquest polycounter lvl 13
    Wow that looks amazing! I can't wait for this tech to arrive. I wonder if this could be used to improve things like dnyamesh. So as you sculpt you dont ever have to worry about your resolution or polygons getting too stretched it's all just handled in real time automatically. That would be awesome.
  • Joopson
    Options
    Offline / Send Message
    Joopson quad damage
    artquest, check out sculptris. It does pretty much what you're saying.
  • Neox
    Options
    Offline / Send Message
    Neox godlike master sticky
    wow 3000 verts, thats really gonna slow down your engine ^^

    no but seriously its a pretty cool tech, seems not to mess up uv breaks with displacement.
  • ZacD
    Options
    Offline / Send Message
    ZacD ngon master
    I like their attitude about creating standards, I wish autodesk would do that with things like normal maps.
  • Bellsey
    Options
    Offline / Send Message
    Bellsey polycounter lvl 8
    ZacD wrote: »
    I like their attitude about creating standards, I wish autodesk would do that with things like normal maps.

    How do you mean? In terms of technique or specific file formats?
    This is easier said then done, and in some ways and this is just me talking here, should it really be up to Autodesk to define the standard?
    We're not the only software vendor out there.
    Autodesk have a 'standard' format in FBX, but many people can reject it, just because it's Autodesk, and not because of any real technical reasons. So it can be hard in driving adoption sometimes.

    Personally when it comes to file formats, I'm more of a fan of things like OpenSudivs, Alembic, Ptex and OpenEXR (which works with Normal Maps), as you can get buy-in from different areas of the industries.
  • doc rob
    Options
    Offline / Send Message
    doc rob polycounter lvl 19
    Turbosmooth Pro uses elements of OpenSubdiv, I believe. It's a great modifier. It seems like it should have been an acquisition for Max 2014.

    Ptex is very interesting but it requires dense geometry, which we tend to avoid in-engine. I'm not sure when it will find an application in real-time tech.
  • artquest
    Options
    Offline / Send Message
    artquest polycounter lvl 13
    Neox wrote: »
    wow 3000 verts, thats really gonna slow down your engine ^^

    no but seriously its a pretty cool tech, seems not to mess up uv breaks with displacement.

    Since it's view dependent I think within the next few years it probably wont be an issue anymore. I don't think we'll see any of this stuff in games for the PS4 and new xbox but I think in maybe 2-3 years PC games will start breaking into this tech. They already use DX11 tessellation in some cases. I imagine having this as standard tech would avoid a lot of headaches around making sure your in-game heightmap doesn't break on the mesh it's applied to. (for anyone who has worked with displacement maps you know what i'm talking about!)
  • Bellsey
    Options
    Offline / Send Message
    Bellsey polycounter lvl 8
    Though I can't speak for the project and Pixar, if anyone was on the webinar that I hosted, during the live Q&A we had with the Pixar GPU team, they said that they have already been talking to a number of interested parties about the technology and implementation. Sony, Microsoft, Unity were all mentioned, so there is real interest, however even though there are 3D packages (Autodesk or not) that already have Catmull-Clark for subdividing, you don't just drag&drop this stuff in. The implementation has got to be done right, so it's of real use.

    As for Ptex, yes you do need dense geometry, but no more than what people are already doing when creating game sculpt meshes and extracting their various texture maps. You can generate Ptex files from the high mesh and apply them to a lower mesh. In many ways its more efficent, because of the texel relationship.
    Check out Manuels demo here:

    http://youtu.be/YNgy2CYEvfI

    The slight downside at the mo, is that you need to work in quads, which isn't how game meshes are often produced/rendered. It's no impossible, just trickier, but I don't think this will be an issue for long before someone gets over this.

    The key here is that when you take the method of Subdivs and combine it with Ptex files for diffuse, normals and vector displacements (forget standard displacement), then you can get very very good results.
  • Neox
    Options
    Offline / Send Message
    Neox godlike master sticky
    Bellsey wrote: »
    How do you mean? In terms of technique or specific file formats?
    This is easier said then done, and in some ways and this is just me talking here, should it really be up to Autodesk to define the standard?
    We're not the only software vendor out there.
    Autodesk have a 'standard' format in FBX, but many people can reject it, just because it's Autodesk, and not because of any real technical reasons. So it can be hard in driving adoption sometimes.

    Personally when it comes to file formats, I'm more of a fan of things like OpenSudivs, Alembic, Ptex and OpenEXR (which works with Normal Maps), as you can get buy-in from different areas of the industries.

    maybe its in 2014, but are the tangent bases of your 3 major apps in any way synched? In max the tangent base of renderer and viewport are not even synced and need a 3rd party plugin (3point) to be fixed.
    Maya so far delivered the best normals to be used in maya and was synched into plenty of productions i worked on including huge titles such as Halo 4. So with Max, Maya and XSI under your belt, you surely have the power to set some standards and make the normalmap creation easier for plenty of productions.
  • EarthQuake
    Options
    Offline / Send Message
    Bellsey wrote: »
    How do you mean? In terms of technique or specific file formats?
    This is easier said then done, and in some ways and this is just me talking here, should it really be up to Autodesk to define the standard?
    We're not the only software vendor out there.
    Autodesk have a 'standard' format in FBX, but many people can reject it, just because it's Autodesk, and not because of any real technical reasons. So it can be hard in driving adoption sometimes.

    Personally when it comes to file formats, I'm more of a fan of things like OpenSudivs, Alembic, Ptex and OpenEXR (which works with Normal Maps), as you can get buy-in from different areas of the industries.

    He's probably referring to the fact that Maya and 3ds Max, for instance, use completely different tangent basis' for rendering normal maps(I'm not talking about the swizzle/handness here) this means that if you bake a normal map in Maya, and try to render it in Max, you're going to get bad smoothing errors from the bi-normals and tangents not matching, and vice versa as well.

    Until recently 3ds Max didn't use the same tangent basis for its baker/offline renderer and its realtime shaders, hence the need for something like 3point Shader with quality normals mode. I'm not sure this is even completely fixed in the latest versions of Max.

    Maya in general has done a better job of keeping normal maps compatible internally within Maya at least, except for the latest versions where weighted normals are on by default and break normal map display in the viewport.

    Though Autodesk certainly isn't the only company out there that has issues with normal maps and tangents, most apps do it a little differently and most game engines do it a little differently as well. However, the fact that Autodesk owns Max, Maya and XSI, gives you guys a great platform to implement a standard tangent basis, more so than any other software or game developer.

    We are in the process of implementing various tangent basis options for the next version our realtime renderer, Marmoset Toolbag and we're going to have to support at minimum 3 different tangent basis standards, Maya, Max, and Xnormal / Blender (Mikktspace, open source). If we want to match common game engines, we'll probably have to add another 3 types as well. While Mikktspace is an interesting choice as it is open source and completely documented, without the support of Autodesk it has very little chance of every becoming a standard. This is why you guys are in a great position to do something about it.

    Now, before you shoot me a response explaining the problems of switching the tangent basis in all of our software, and what that would do to backwards compatibility etc, you really don't need to do that at all. You would simply need to add a dropdown with a user selectable tangent basis list to the RTT window in max, Transfer maps options in Maya, with a selectable tangent space. Say if you decide on some universal format, or just stick with Maya's method as a universal format or something of that nature, very easy to do and won't break anything for users who don't want/need it.

    The biggest benefit to an Autodesk supported tangent basis standard would simply be having you guys support one method, as well as having clear and concise documentation for how to implement it into 3rd party apps/game engines. Maya's tangent basis is actually documented quite well in the help system, but to learn anything about Max's, you have to dig through blog posts (1, 2).

    PS: Graham, I just want to say that it's great to see Autodesk guys having a presence on Polycount.
  • Bellsey
    Options
    Offline / Send Message
    Bellsey polycounter lvl 8
    I get what you mean now.
    Tbh, I don't know if we will standardize and I certainly can't provide information on any future intention either.

    As far as I can tell, Maya/Softimage are generally ok and are very similar. I can't speak for Max as it's a package I don't really know. It always has been slightly different as it uses stuff like Smoothing groups.
    Hell, even after all this time it still thinks Z is up, lol :)

    Conforming things across the three packages always sounds easy, but can be trickier than people think. One can seem like a simple task, can take longer than envisaged. This is mainly due to three different code bases that have been developed upon over many years.
    However where possible we do try and see if we can share stuff, or use common methods/techniques across the three. For example, the poly reduction in Maya 2014 has been replaced (thank god:)) and replaced with the same algorithm that Softimage uses.

    I know that in FBX, there is an option to transfer the Tangent and Bi-Normal information with an asset, which I have used and seems to work.
  • EarthQuake
    Options
    Offline / Send Message
    Bellsey wrote: »
    Conforming things across the three packages always sounds easy, but can be trickier than people think. One can seem like a simple task, can take longer than envisaged. This is mainly due to three different code bases that have been developed upon over many years.

    Sure, of course it will not be trivial to implement one rendering technique in three different apps, however I think if Autodesk looked into it, the amount the code varies between the different tangent basis calculations is pretty minimal.

    If AD has any interest in looking into it, I can get you in touch with engineers that understand the issue quite well.

    Dealing with the pitfalls of various discrepancies between modeling apps, or even inside modeling apps when it comes to normal map baking can be a huge drain on productivity for game artists, especially the less technical artists who do not really understand the issue, so I think it would be very productive to work towards some sort of solution there.

    Oh, and not to derail any further: The opensub-divs package looks excellent, we're very excited about this at Marmoset, as we were looking into writing our own sub-d system, so its something we'll be checking out for sure.
  • SHEPEIRO
    Options
    Offline / Send Message
    SHEPEIRO polycounter lvl 17
    EarthQuake wrote: »
    Oh, and not to derail any further: The opensub-divs package looks excellent, we're very excited about this at Marmoset, as we were looking into writing our own sub-d system, so its something we'll be checking out for sure.

    think that goes for the rest of us too... looks like mana from heaven on multiple fronts, rendering, production, and could possibly be the start of a nice unified system to LOD things...
  • gray
    Options
    Offline / Send Message
    its great to see some serious movement again in surface research. i think most of the large players have become complacent with subdiv surfaces because "it works" in off line renderes. but there are shortcomings in other domains. while its great to see feature adaptive real time rendering with displacement that is not the issue that is causing the surface representation fragmentation. the lack of hierarchical subdiv with editing IS the problem. not just hierarchical subdiv. hierarchical subdiv with editing. this is alluded to but not demonstrated in the videos. this is a bigger problem then just display so it will take more time. but this better be in the pipeline for open subdiv. without this open subdiv will not prevent the fragmentation and will be relegated to a neat rendering trick that has no impact on the proper pipline where artists do there work. until there is an api for hierarchical subdiv with editing and it is implemented in maya, mudbox and other software you will continue to see fragmentation.

    a slightly more technical explanation of the same material.
    http://vimeo.com/55032699
Sign In or Register to comment.