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
[ame="http://www.youtube.com/watch?v=xFZazwvYc5o"]Meet the Experts: Pixar Animation Studios, The OpenSubdiv Project - YouTube[/ame]
no but seriously its a pretty cool tech, seems not to mess up uv breaks with displacement.
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.
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.
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!)
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.
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.
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.
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.
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.
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...
a slightly more technical explanation of the same material.
http://vimeo.com/55032699